Mobile-l June 2014

mobile-l@lists.wikimedia.org

43 participants
63 discussions

Low-quality images are live
by Yuri Astrakhan 16 Sep '14

16 Sep '14

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.

7 11

Tablet pageview data pre and post redirect
by Maryana Pinchuk 08 Jul '14

08 Jul '14

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

7 21

[Apps] Monthly retrospective notes
by Dan Garry 08 Jul '14

08 Jul '14

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

2 1

App Store Feature Requests
by Vibha Bamba 04 Jul '14

04 Jul '14

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

4 7

[Apps] New iOS release date 14th July
by Dan Garry 02 Jul '14

02 Jul '14

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

3 5

Congratulating the Wikimedia App team for launching the Native Wikipedia Android App
by Tomasz Finc 01 Jul '14

01 Jul '14

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

9 8

Fwd: Blurry text on iPad
by Jeremy Baron 01 Jul '14

01 Jul '14

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.

3 4

Live demo "Styleguide mobile" broken on toolserver
by Florian Schmidt 01 Jul '14

01 Jul '14

Hello together! I've noticed, that the online live stylguide for mobile on toolserver (linked e.g. from MW Mobile Team Page, section development guidelines: https://www.mediawiki.org/wiki/Mobile_web/Team#Development_guidelines) is broken: http://tools.wmflabs.org/styleguide/mobile/index.html Can we do anything to repair, or remove the link from MW page? :) Thanks for attention! Kind regards Florian

2 1

Removing the Watchlist icon on Opera / Lower JS Devices?
by Adam Baso 01 Jul '14

01 Jul '14

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

6 21

Getting Flow mobile ready
by Jon Robson 30 Jun '14

30 Jun '14

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

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

Mobile-l June 2014