The reduced quality images is now live in production. To see it for
yourself, compare original
<http://upload.wikimedia.org/wikipedia/commons/thumb/c/cb/Buildings_of_Bedfo…>
with low quality
<http://upload.wikimedia.org/wikipedia/commons/thumb/c/cb/Buildings_of_Bedfo…>
images
(253KB => 99.9KB, 60% reduction).
The quality reduction is triggered by adding "qlow-" in front of the file
name's pixel size.
Continuing our previous discussion, now we need to figure out how to best
use this feature. As covered before, there are two main approaches:
* JavaScript rewrite - dynamically change <img> tag based on
network/device/user preference conditions. Issues may include multiple
downloads of the same image (if the browser starts the download before JS
runs), parser cache fragmentation.
* Varnish-based rewrite - varnish decides which image to server under the
same URL. This approach requires Varnish to know everything needed to make
a decision.
Zero plans to go the first route, but if we make it mobile, or ever site
wide, all the better.
Good news, everyone!
Oliver ran some stats for us on where tablet users were landing (desktop
view or mobile view) a few days before and after the tablet redirect on
Tuesday:
Before the redirect, *13% of pageviews from tablets were hitting the mobile
site*, meaning a non-trivial chunk of users had opted into the mobile
experience even before we were serving it to them as the default.
After the redirect, *95% of pageviews from tablets were hitting the mobile
site*, meaning a fairly small number of users are opting out of the mobile
experience we're serving – smaller than the number of people who were
opting out of the desktop experience before the redirect :)
(Note that the total pageview numbers haven't changed significantly – the
slightly downward trendline in the past few days just reflects the normal
dip we observe toward the end of every week.)
So, tl;dr, it looks like we're serving the needs of the majority of our
users. Graph below, courtesy of our beloved British data analyst/road
warrior. We'll continue to monitor these numbers, of course, but the early
results look good – nice work, team!
[image: Inline image 1]
--
Maryana Pinchuk
Product Manager, Wikimedia Foundation
wikimediafoundation.org
Hi everyone,
The Mobile Apps team met for our monthly retrospective. With Tomasz out at
Google I/O, I temporarily filled in as scrum master in addition to my
product owner role.
The full notes are archived on mediawiki.org
<https://www.mediawiki.org/wiki/Wikimedia_Apps/imported/Retrospective-June_2…>
.
Action points from this meeting:
- We're suffering from device shortage. Dan will follow-up with Tomasz
(in his role as Director) about this. In particular:
- The designers would like more Android devices so they can
familiarise themselves with Android design patterns.
- We'd like the language team, a very mobile-heavy team, to have iOS
devices so they can diversify their own testing of the app.
- Dan uses his iOS phone and Android tablet for all testing. He'd
like iOS tablets and Android phones to be more available in the office so
he can test on more platforms.
- Product and engineering have felt kind of separated from design, and
vice-versa. We all think we can make refinements to break this divide.
Vibha is going to own this improvement, but we all agreed trying to get iOS
out of the door is higher priority right now.
- We're focussed on the current sprint very well, but our planning for
two or three sprints into the future is poor. I think the blame is on me
for this here. Dan is going to own improving the backlog even further so
the roadmap is clearer.
- We need to meet sooner rather than later to discuss the iOS release
and whether we're comfortable going ahead with it, and what our criteria
for whether it's "ready" are. Dan will set this up.
- We need to talk about how often we release. Yuvi will lead a
discussion on mobile-l.
Thanks everyone!
Dan
--
Dan Garry
Associate Product Manager for Platform and Mobile Apps
Wikimedia Foundation
Hi everyone,
I've started an etherpad to document relevant comments from the app store
reviews in order to manage user feedback.
https://etherpad.wikimedia.org/p/App_Store_Feature_Comments
Please paste comments directly without editorial in the relevant sections
if you would like to help out. Synthesis/ Analysis to follow.
Thanks!
Vibha
----
Vibha Bamba
Senior Designer | WMF Design
Hi all,
Vibha, Monte, Luis and I met to discuss the blockers for the iOS release.
As a group we identified the following things that need to happen before
the release:
1. Making the information in the footer link to the article history.
[Legal blocker, Brion working on this right now]
2. Add a Terms of Use link into the App Store description upon release.
[Legal blocker, Dan to do this]
3. Refine the More menu. i.e. product and design to decide what should
be in there, and what the prose should be [Dan and Vibha to work on this,
top priority card in for next sprint]
- Add links to privacy policy and terms of use [Legal blocker]
4. Auditing internationalisation. Try to switch to other languages.
[Dan to test]
5. ToC refinements [Monte, in current sprint]
6. Remove the "tap to hide chrome" behaviour [Monte, in current sprint]
Some of these, namely {1, 5, 6}, are being handled in the current sprint.
Some, namely {2}, are handled at release. However, {3, 4} can't be handled
in the current sprint.
Given the quarterly planning this week, and the four day week, we're
delaying the release, instead placing {3,4} as top priority issues for the
next sprint, and targeting 14th July instead.
Let me know if you have any questions.
Thanks,
Dan
--
Dan Garry
Associate Product Manager for Platform and Mobile Apps
Wikimedia Foundation
With the dust settling for our launch of the new native Android app in
the Google Play Store [1] I'd like to acknowledge the great work that
the team [2] has done and forward some of the reviews we've seen come
in. [3]
Here are some of my favorites
"Super, the bugs are out. Runs like clockwork. Class layout. Now again
everything tip top."
(Translated from German)
"I am glad that there are also pages in the app can be edited. The app
is really fantastic!"
(Translated from Dutch)
"Keeping it 100 This app is a great way to access Wikipedia and the
fact that it doesn't snoop all your information is really cool. I'll
support Wikimedia till the end."
"Perfect since the last update Native Android is always the better way
for an android app. Looks marvelous and awesome, gg :-)"
"Great! Since the latest update everything is much improved. No more
random crashes on start-up and the UI is much more pleasing to the
eye. Well done!"
"To have One of those applications that you put "default". Wikipedia
is always helpful and this app is a good summary of simplicity and
functionality"
(Translated from Italian)
"Simply brilliant From idea to implementation, a round good thing, a
walking stick for humanity on your way to unity."
(Translated from German)
And a healthy amount of critique that we're ready to take head on
"Very good I really like the current interface. What I totally
disagree is that they have placed the option of modifying entries from
Mobile. If there are already many people adulterating tickets from the
web version, the mobile version now since many people with nothing to
do will too"
And my personal nonsensical favorite
"Savage app! This app is totally SAVAGE bro! It will make your day
glow like a lemonade cooler and bring home the bacon, fry it up in a
pan! Now that's what i call SAVAGE!"
(Translating this is beyond me but I love the energy)
Thank You to Dmitry, Bernd, Yuvi, Dan, Vibha, Moiz and others for
getting us here.
We're all excited to see iOS go next.
--tomasz
[1] - http://blog.wikimedia.org/2014/06/25/revamped-wikipedia-app-now-available-o…
[2] - https://www.mediawiki.org/wiki/Wikimedia_Apps/Team
[3] - https://play.google.com/store/apps/details?id=org.wikipedia
Hi,
(see also my other mail just now on mobile non-app feedback in general)
In this case I searched bugzilla for ~5 mins and didn't see anything
relevant and so I forward here. Although, maybe I used the wrong
search keywords. (quicksearches were ":mobilefrontend summary:text",
":mobilefrontend summary:font" and ":mobilefrontend blur". and then I
realized of course this isn't MobileFrontend at all and tried again
with "ipad|ios font|text|blur")
I don't see the issue myself but I'm
not looking on an iPad. It may be valid or WORKSFORME or fixed but not
yet deployed.
At first glance this seems like Brion's kind of bug?
I just asked the user about the rendering with MobileFrontend. (I
guess they must have opted out because it's such recent feedback?
given the recent switch to redirect tablets also by default.)
-Jeremy
(obviously removed name and redacted screenshot a bit)
screenshot now uploaded instead of attached because list has a size limit:
https://i.imgur.com/oLFawll.png
---------- Forwarded message ----------
From: OTRS 2014062710022031
Date: Fri, Jun 27, 2014 23:00 UTC
Subject: Blurry text on iPad
To: "info-en(a)wikimedia.org" <info-en(a)wikimedia.org>
Just to report a bug - Since today, the text became blurry on the main
content area of the site while visiting wikipedia on a non-retina iPad
in portrait orientation (the top and sidebar remains sharp). You can
find a screenshot in attachment. This also happens while visiting
articles.
Juliusz suggested I email out details to mobile-l on the following.
The question arose during an Opera discussion today whether hiding the
Watchlist icon (which is the case on non-HTTPS supporting UX on Wikipedia
Zero) on mobile web in the page menubar (not the same as the flyout
"hamburger" menu) might make sense generally for <noscript> or lower JS
devices? The Watchlist star on the page menubar takes up a lot of space,
and as it's the only thing there at the moment (on en.m at least, icons
like Edit and Add Photo aren't shown), hiding that menubar icon would free
up some valuable screen real estate.
On <noscript> or lower JS devices (or browsers where RL suppresses JS due
typically to challenges around timing of Deferreds and the like), using the
Opera traffic as an example of such a browser, it seems like Watchlist
usage is sort of low (this is at 1% sampling resolution).
$ zcat /a/squid/archive/mobile/mobile-sampled-100.tsv.log-20140409.gz |
grep 'proxy=Opera' | grep 'action=watch' | wc -l
3
In other words, it seems users make it to the point of using the feature,
but only about 300 times per day total. Meanwhile, the Watchlist start
takes up valuable screen real estate for every pageview.
The usage of the feature is about 1/10 of the Opera usage involving
submission of the login form (a prerequisite of watchlist usage).
$ zcat /a/squid/archive/mobile/mobile-sampled-100.tsv.log-20140409.gz |
grep 'proxy=Opera' | grep -i 'Special:UserLogin' | grep 'POST' | wc -l
31
Which is about 1/10 of Opera usage of the login feature in any capacity
(GETting the form or POSTing the form)
$ zcat /a/squid/archive/mobile/mobile-sampled-100.tsv.log-20140409.gz |
grep 'proxy=Opera' | grep -i 'Special:UserLogin' | wc -l
331
Which is maybe 1/270 of an oversimplified "pageview" metric on Opera Mini,
using text/html response types as a rough guide.
$ zcat /a/squid/archive/mobile/mobile-sampled-100.tsv.log-20140409.gz |
grep 'proxy=Opera' | grep 'text/html' | wc -l
89403
The relatively low usage of the Watchlist feature is probably symptomatic
of the multiscreen flow on such devices.
-Adam
I've recently been planted from the mobile team into the Flow team to
get the code between these two teams more closely aligned and also get
Flow optimised and working on mobile phones.
I've constructed a list of cards in the Flow backlog under the list
heading 'Mobile' [1] which should set a path for us getting to a good
mobile experience. As a first goal I'm aiming to get Flow working
nicely without JavaScript in mobile. Most of the initial work will be
around polishing non-JavaScript workflows so they are less jarring.
It would be pretty trivial to simply enable all JavaScript and CSS on
mobile and get it up and running, but I suggest we use this as an
opportunity to improve on our track record of UI standardisation.
After polishing the non-JS workflow we should get Flow to a point
where it is using MediaWiki UI as much as possible and use this as an
opportunity to drive some development resources into MediaWiki UI.
There are various components that in Flow that should be polished up
and pushed into MediaWiki UI. We should polish these up as much as
possible, thinking about how they render in mobile, whether they are
important and get them upstreamed to core. Flow also ships its own
version of MediaWiki UI buttons (flow-ui-button). We will have to
standardise and improve MediaWiki UI where necessary before even
thinking of shipping these styles to mobile. MediaWiki UI is already
loaded on mobile so this would be an easy win.
Please let me know if you see any huge flaws in my approach or you
think there are any chunks of work I've overlooked.
Jon
[1] https://trello.com/b/HD0lBssr/flow-backlog
