June 2014 - Mobile-l - lists.wikimedia.org

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 02 Jul '14

02 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

Fwd: Results of mobile spike to investigate Knockoff-Tassembly templating system
by Ryan Kaldari 30 Jun '14

30 Jun '14

The Mobile web team finally dedicated some time to investigating Gabriel's Knockoff-Tassembly templating system. Specifically, I was tasked with answering the questions at https://trello.com/c/lYfyzs8A/6-spike-explore-knockoff-templating. The results of my investigation are at: https://www.mediawiki.org/wiki/Requests_for_comment/HTML_templating_library… If anyone has comments, feel free to reply with them. Ryan Kaldari

1 0

mobile non-app feedback
by Jeremy Baron 29 Jun '14

29 Jun '14

Hi, Often mobile tickets need more knowledge of mobile and awareness of the state of things than I can offer. And they often are neglected in tech-issues. (I think more than other kinds of tech issues?) Are you interested in only MobileFrontend issues or also Vector/Monobook on mobile devices? Options: * we could forward stuff to mobile-l (sometimes without even bothering to search bugzilla) * we could get a template like we already have for wikitech-l referrals to tell people they should be mailing mobile-l instead * maybe we could get mobile people paying attention to OTRS? (especially because you're already using OTRS for the apps. speaking of apps, do you reply to those tickets at all? I sent a few in myself) -Jeremy

4 3

Re: [WikimediaMobile] Fwd: Blurry text on iPad
by Florian Schmidt 29 Jun '14

29 Jun '14

Hello Jeremy! For me, that seems to be normal for desktop sites on mobile devices (that's one of the plusses to use MobileFrontend :P). For example see the Nexus 7 Screenshots from Wikipedia and another website (on the other website you see the difference between the "normal" font size (very little and blurry) and a bigger font (better to read)). If you zoom the site in the browser, the font is much clearer and bigger, so better to read, so on Android tablet, I think on iPad, too. Wikipedia Nexus 7: http://i.imgur.com/Iaf8SvK.png Other website Nexus 7: http://i.imgur.com/miUxm2O.png Normally the user will be automatically redirected to the Mobile optimized site (MobileFrontend) with an iPad, so, if he want to see the desktop site, he must opt-out with the link at the bottom. P.S.: Sorry Jeremy for sent this mail twice, in first mobile-l wasn't added :) Kind regards Florian Freundliche Grüße Florian -----Ursprüngliche Nachricht----- Von: mobile-l-bounces(a)lists.wikimedia.org [mailto:mobile-l-bounces@lists.wikimedia.org] Im Auftrag von Jeremy Baron Gesendet: Sonntag, 29. Juni 2014 03:13 An: mobile-l Betreff: [WikimediaMobile] Fwd: Blurry text on iPad 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. _______________________________________________ Mobile-l mailing list Mobile-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l

2 1

iPad bugs we need to fix in VE
by Juliusz Gonera 25 Jun '14

25 Jun '14

There are three important bugs that need to be fixed in VE before we can move it to stable for tablets (specifically iPads). The first two were added by me just today. The third was reported in May by Rummana and for some odd reason had Jon assigned to it, although he has never worked on it (I removed him). Following Roan's suggestion I recorded videos on iOS simulator to illustrate what is happening in each case (thanks to Monte for letting me use his Macbook with up-to-date Xcode). https://bugzilla.wikimedia.org/show_bug.cgi?id=66999 https://bugzilla.wikimedia.org/show_bug.cgi?id=67002 https://bugzilla.wikimedia.org/show_bug.cgi?id=65326 Let us (the mobile team) know if you need any help with those. -- Juliusz

1 1

"Article" versus "Page" in iOS
by Adam Baso 25 Jun '14

25 Jun '14

I was going to resubmit the patch below by updating the W0 and sidebar verbiage, but I noticed the word "article" is used in lots of other places. Okay if I make the changes in the other places for the actual string values on the righthand side of the = operator? I don't really care to touch the lefthand side keys of the messages at this point. -Adam On Wed, Jun 25, 2014 at 7:05 AM, Siebrand (Code Review) < gerrit(a)wikimedia.org> wrote: > Siebrand has posted comments on this change. > > Change subject: Update W0 flourishes based on UX feedback for MVP. > ...................................................................... > > > Patch Set 1: > > (1 comment) > > > https://gerrit.wikimedia.org/r/#/c/141852/1/wikipedia/en.lproj/Localizable.… > File wikipedia/en.lproj/Localizable.strings: > > Line 16: "zero-charged-verbiage-extended" = "Loading other articles may > incur data charges. Saved articles stored offline do not use data and are > free."; > > Currently, the app sidebar says "Saved articles". Should the sidebar say > "S > Yes, please use page consistently.

7 8

New Android alpha/beta update
by Bernd Sitzmann 25 Jun '14

25 Jun '14

Today's update to the Alpha and Beta[1] versions of the Android app includes the following changes: - Added option to refresh Saved Pages. - Improved styling of Login and Create Account screens. - Improved handling of Random pages. - Updated translations/internationalization. - Numerous bug/crash fixes. We're getting very close to the production 2.0 release. So, please continue to put the app through its paces! We want as much of your valuable feedback as possible. Bernd [1]: https://play.google.com/store/apps/details?id=org.wikipedia.beta

2 3

Signing off on iOS stories
by Tomasz Finc 25 Jun '14

25 Jun '14

Brion, Can we create a build that just has https://trello.com/c/Afq8I3Ly/32-3-complete-implementation-of-event-logging… https://trello.com/c/ZYLna46S/14-3-bug-65108-ios-app-links-to-sections-don-… for sign off? Monte needs some more time to https://trello.com/c/Io6a0jEi/24-3-onboarding and we need to close out the the above mentioned stories or move them over. thanks --tomasz

1 0

[Apps] Mobile time with Lila
by Dan Garry 25 Jun '14

25 Jun '14

Hi everyone, We just met with Lila to show her the app. In short, she approves! Full speed ahead! :-) I took some notes on the things she was suggesting in the meeting. Here they are: http://etherpad.wikimedia.org/p/LilaAppNotes We'll work these into the backlog. For now, we all know what we've got to do! Thanks, Dan -- Dan Garry Associate Product Manager for Platform and Mobile Apps Wikimedia Foundation

2 1

[Apps] Release time set for Android
by Dan Garry 24 Jun '14

24 Jun '14

Hi everyone, So that the Communications team has a baseline which they can operate from, we've set a specific time at which the APK for the Android release will be pushed to the store. We'd already agreed on the date, 25th June, but now we've set a specific time: 9am (SF time) on Wednesday 25th June. The Communications team is aware that, in order to be fully accessible, the app must still then propagate through Google's servers and that we have no way of knowing how long this will take. But guaranteeing that we will at least push the APK at a set time removes one of the variables from the equation for them. Thanks! Dan -- Dan Garry Associate Product Manager for Platform and Mobile Apps Wikimedia Foundation

4 7

Selenium_user blocked on English Wikipedia
by Chris McMahon 24 Jun '14

24 Jun '14

Hi, In the MobileFrontend test suite is a build that targets the production English Wikipedia. On several occasions over the last few months rogue tests from that build have created test pages in production. This happened again yesterday, and as a result, I removed en.m.wikipedia.org from all the Mobile browser tests [1] and Zeljko has deleted the MobileFrontend build that targets production completely, so this should not happen again. However, as of this morning and because of these test pages, the Selenium_user is blocked indefinitely on English Wikipedia [2]. I am inclined to continue to have Selenium_user blocked in production, I think it is a good idea. If you have any reason to use the Selenium_user in production, please let me know in the next twenty four hours or so. Thanks, -Chris [1] https://gerrit.wikimedia.org/r/#/c/141463/ [2] https://en.wikipedia.org/wiki/User_talk:Selenium_user#June_2014

1 0

Idea: scale wide tables to fit instead of scrolling
by Brion Vibber 23 Jun '14

23 Jun '14

Currently we handle wide tables on mobile by making them horizontally scrollable. This lets you pan around in a big table to see the whole thing, BUT you can't see it all at once. This is also a little annoying for things like info boxes that are only *slightly* wider than the screen, and can make it hard to actually navigate a complex table since you can't see the header cells and all the data cells together. I was wondering if there was any interest in the idea of scaling tables to fit the display width instead -- then allow pinch-zoom and panning within the entire article if it's a really big table and you can't read at the initial zoom level. This should be accomplishable using CSS transforms in modern browsers & apps... thoughts? -- brion

1 0

Fwd: Android Sign In & Register Screencaps
by Yuvi Panda 21 Jun '14

21 Jun '14

Moving to mobile-l :) ---------- Forwarded message ---------- From: Adam Baso <abaso(a)wikimedia.org> Date: Sat, Jun 21, 2014 at 3:03 AM Subject: Android Sign In & Register Screencaps To: mobile-tech <mobile-tech(a)wikimedia.org> Dmitry and Bernd and I were talking a bit about Sign In & Register visual design patterns. I was going to send them some iOS screenshots I had taken a while back, but remembered stuff is a little different in the Android apps versions - not a ton, but enough. Here you go. Sort by Title. https://drive.google.com/a/wikimedia.org/folderview?id=0BxJX28FKLm78djFiWG9… Here were the iOS mocks I saw for Wikipedia. Monte is iterating on this with Vibha and Moiz, I think. https://trello.com/c/sc5ytNdC/85-design No doubt there's a dance involving screen real estate, soft keyboard up/down considerations in light of screen real estate, careful labeling & icon-ing of progressive actions and keyboard buttons, and prevailing style(s). Plus in our case we don't do third party authentication at the moment; not sure if "anonymous" third party authentication (e.g., *Wikipedia user = LikesToEmail (third party authenticated user sequence number 1234567890)*) will ever be an option . I know this is mostly obvious stuff, just thought I'd share some screencaps in case others hadn't seen them. -Adam

2 1

New Android alpha/beta update!
by Dmitry Brant 21 Jun '14

21 Jun '14

Today's update to the Alpha and Beta[1] versions of the Android app includes the following awesome features: * Saving of pages for offline reading (complete with images!) * Find-in-page functionality * An improved and streamlined page editing workflow * Miscellaneous bug/crash fixes Please continue to put the app through its paces! We want as much of your valuable feedback as possible. [1]: https://play.google.com/store/apps/details?id=org.wikipedia.beta -- Dmitry

5 5

Tablet mobile redirect issues with iPad?
by Brion Vibber 20 Jun '14

20 Jun '14

I've been poking at Wikipedia with my iPad and have found that I don't always get sent consistently to the mobile site as expected since the recent updates... especially when switching languages or following links from the portal page or web searches. Not sure if this is just because I have stray opt-in/opt-out cookies on various languages from various previous browsing or if there's something funky. Steps to reproduce: 1) Open Safari and go to https://www.wikipedia.org/ portal 2) Click "English" 3) see that I'm on the desktop site, logged in 4) Click "Mobile view" link to force back to mobile site 5) Manually go back to https://www.wikipedia.org/ 6) Click "English" again 7) ...see that I'm on the desktop site again, still logged in or 1) Follow above procedure up to getting on English mobile site 2) Go to a random article 3) "Read in other languages", pick a language like Czech or Galician 4) find I'm back on the desktop site in that language Can anyone else reproduce this or have I just messed up my cookies? -- brion

2 2

[Apps] Summary of meeting about analytics on the apps
by Dan Garry 19 Jun '14

19 Jun '14

Hi everyone, Brion, Yuvi, Dario, Oliver and I met to discuss the state of the analytics instrumentation in both the iOS and Android apps. We decided that our current instrumentation in the apps collects the appropriate information for us to be able to crunch core metrics (e.g. number of users, number of page views per user per month). A full list of the metrics we checked we collected appropriate data for is given in this summary of the meeting <https://docs.google.com/a/wikimedia.org/document/d/10UyOXmAP4dOzy_yZU7RCQDs…> . Thanks! Dan -- Dan Garry Associate Product Manager for Platform and Mobile Apps Wikimedia Foundation

1 0

Re: [WikimediaMobile] [Wikitech-ambassadors] Deployment of tablet redirect to mobile interface (action needed)
by Federico Leva (Nemo) 19 Jun '14

19 Jun '14

I get reminded of https://xkcd.com/1174/ : "less information and a dumbed-down interface", "I like the tablet and desktop being the same", "Wiki for kiddies", "Mobile version sites are limited". https://blog.wikimedia.org/2014/06/17/wikimedia-sites-get-a-new-look-on-tab… Importance of data increases: I reiterate my question, for which I had no answer. Federico Leva (Nemo), 15/06/2014 09:09: >> Will someone be monitoring the effects [if any] on editing activity >> and number of active editors/new [10+ edits] editors? >> > > [...] I asked about effects of this change, not > about totals. And I add another question: is it technically possible to configure this switch per-wiki? Nemo

4 5

Fwd: VE on Android tablets
by Juliusz Gonera 18 Jun '14

18 Jun '14

Forwarding a list of bugs found by Rummana. ---------- Forwarded message ---------- From: Rummana Yasmeen <ryasmeen(a)wikimedia.org> Date: Tue, Jun 17, 2014 at 6:19 PM Subject: Re: [WikimediaMobile] VE on Android tablets To: Juliusz Gonera <jgonera(a)wikimedia.org> Hi Juliusz, I did some testing today on mobile VE with one of our Android tablets : Nexus 7(Android 4.4.2).There are some bugs around link inspector and other features. Though most of the bugs found in iPad are not reproducible here in Nexus 7, but there are many other different issues with it. I am sending you the list of reported bugs , let me know if you have any question regarding any bug :) Bug 66759 <https://bugzilla.wikimedia.org/show_bug.cgi?id=66759> - VisualEditor Mobile: For the first time in each edit session in Nexus 7(Android 4.4.2), Link Inspector gets auto-zoomed in,which looks like partial rendering of the UI Bug 66755 <https://bugzilla.wikimedia.org/show_bug.cgi?id=66755> - VisualEditor Mobile: Tapping at the end of each link, does copy-paste of preceding link text in Nexus 7(Android 4.4.2) Bug 66696 <https://bugzilla.wikimedia.org/show_bug.cgi?id=66696> - VisualEditor Mobile: Getting stuck inside Link inspector while trying to clear the link text when there was no match for it in the inspector Bug 66753 <https://bugzilla.wikimedia.org/show_bug.cgi?id=66753> - VisualEditor Mobile:Link suggestions are not appearing while trying to add link target from link inspector in Nexus 7(Android 4.4.2) Bug 65325 <https://bugzilla.wikimedia.org/show_bug.cgi?id=65325> - VisualEditor Mobile: Cursor appears over the toolbar in iPad Mini and Nexus 7 for Mobile VE Bug 66697 <https://bugzilla.wikimedia.org/show_bug.cgi?id=66697> - VisualEditor Mobile: Cursor jumps to the beginning of the article, irrespective of the position user trying to tap and put the cursor into. Bug 66758 <https://bugzilla.wikimedia.org/show_bug.cgi?id=66758> - VisualEditor Mobile: Tapping on Return while cursor is at the end of a text , deletes that text in Nexus 7(Android 4.4.2) Bug 66756 <https://bugzilla.wikimedia.org/show_bug.cgi?id=66756> - VisualEditor Mobile: Cannot save any edit in mobile VE for Nexus 7(Android 4.4.2) Regards, Rummana On Tue, Jun 10, 2014 at 11:24 AM, Tomasz Finc <tfinc(a)wikimedia.org> wrote: > Juliusz, go ahead and sync up with Rummana (cc'd) and find out what her > availability is. > On Jun 10, 2014 11:21 AM, "Juliusz Gonera" <jgonera(a)wikimedia.org> wrote: > >> She could test a bit on recent Chrome for Android. Let's hold off on >> Android Browser for now, it's a buggy and we can instead suggest that >> Android 4 users install Chrome. >> >> >> Tomasz Finc wrote: >> >>> Should we get Rummana to help us do any additional testing on these? >>> >>> --tomasz >>> >>> On Thu, Jun 5, 2014 at 4:35 PM, Juliusz Gonera <jgonera(a)wikimedia.org> >>> wrote: >>> >>>> I tried VE on the two working Android tablets that we have: Samsung >>>> Galaxy >>>> Tab 10.1 (Android 4.0.4) and Nexus 7 (Android 4.4.2). Samsung uses >>>> Android >>>> Browser and VE performs slowly and buggy there. Link inspector works >>>> better >>>> than on iOS but there are other small bugs like problems with some >>>> icons not >>>> being scaled properly or occasional rendering issues. Nexus 7 with >>>> Kitkat >>>> has Chrome as its default browser and everything works fine there, I >>>> would >>>> even say it works better than iPads. >>>> >>>> Kaldari is doing more research regarding which tablets should be >>>> redirected >>>> to mobile. >>>> >>>> -- >>>> Juliusz >>>> >>>> _______________________________________________ >>>> Mobile-l mailing list >>>> Mobile-l(a)lists.wikimedia.org >>>> https://lists.wikimedia.org/mailman/listinfo/mobile-l >>>> >>>> >>

2 1

Mobile revtags, redux
by Dario Taraborelli 18 Jun '14

18 Jun '14

Yuvi, Aaron and I sat down to review the implementation of revtags for mobile edits and we came up with the following proposal: Assumptions • we want to be able to expose whether an edit is from a mobile app or mobile web in MediaWiki as patrollers are filtering edits based on the source • we want to allow Product to have a handy way to select all mobile edits (regardless of whether they come from apps or mobile web) • we want a solution that is backward compatible • we don’t want to use tags to store additional metadata, such as platform or app version (which can be obtained from EventLogging instrumentation) Proposal Implement 3 distinct MediaWiki tags [1] mobile edit generic tag for all mobile edits mobile web edit tag specific to mobile web revisions mobile app edit tag specific to mobile app revisions Each mobile edit will get at least two tags. • run a maintenance script to remove spurious tags for mobile app account creations from change_tag and tag_summary • run a maintenance script looking for all instances of mobile edit without mobile web edit or mobile app edit and add tag them as mobile web edit This should be fully backward-compatible and allow flexible filtering by tag. Let us know if you have any question/concern. Dario [1] https://gerrit.wikimedia.org/r/#/c/139195/

4 5

New tablet-optimized mobile site now live for all tablet users
by Maryana Pinchuk 18 Jun '14

18 Jun '14

Today the WMF Mobile Web deployed a change to the default destination of users accessing Wikimedia projects from tablets – we're sending users to a new mobile view that's been optimized for larger touch-screen devices. You can learn more about this change here: http://blog.wikimedia.org/2014/06/17/wikimedia-sites-get-a-new-look-on-tabl… Please let us know if you're experiencing any issues as you browse Wikipedia or its sister projects on your iPad or Android tablet, and let us know what you think of the features and functionality. -- Maryana Pinchuk Product Manager, Wikimedia Foundation wikimediafoundation.org

1 0

[Apps] Biggest feature requests so far from the beta
by Dan Garry 17 Jun '14

17 Jun '14

Hi everyone, Since the Android beta release, we've been getting a lot of feedback about what people want added in. Here's an email listing some of those things, so we know what we've got to focus on. 1. Dark theme! A dark horse... no pun intended. By far the most requested feature. 2. Watchlist. The most requested feature from the editing community. 3. Searching within articles. Thanks, Dan -- Dan Garry Associate Product Manager for Platform and Mobile Apps Wikimedia Foundation

9 16

Wikipedia app release plan
by Yuvi Panda 17 Jun '14

17 Jun '14

Hello! 25th June is fast approaching, and we are on track to make the release with time to spare! Here's the proposed plan: 1. Release a final beta on Friday, 20th June. 2. Let people test the beta over the weekend, and up to 23rd. 3. Fix any bugs that pop up. No new feature work. Crashing bugs get priority. 4. Release on 25th! This means that any non-critical-bug fix has to be in place by this Friday. Is everyone ok with this plan, or does it feel like we are cutting it too short? Thanks! :) -- Yuvi Panda T http://yuvi.in/blog

2 1

Future of Windows 8.1 tablet app; support, unofficialize, or end-of-life?
by Brion Vibber 16 Jun '14

16 Jun '14

Microsoft sent me a report that our Windows 8.1 tablet app is having a crash-on-launch bug with today's featured articles; I've applied a quick fix and am submitting it to the Windows Store for update. This app was originally a prototype which I figured we'd rewrite if there was continued demand, but Windows 8/8.1 tablet apps just haven't taken the world by storm so far and we've not put work into it in a while... but it does have a non-zero maintenance cost picking up these little bugs. We may want to make sure we have an actual measure of its traffic usage before making a decision, but we don't think it's very high right now... A few possibilities: 1) Officially support the app for Windows 8.1 tablets, add support for Windows Phone 8.1, and continue to work on updating and improving the app alongside Android and iOS. 2) Transition it to an unofficial app "in-place", and I'll poke at phone support, media playback, and UI experiments on my own time. 3) Pick an official end-of-life date and kill it off entirely. If and when I or someone else want to make an unofficial version they can pick up the source and create a new app entry for people to download. Based on low demand and limited resources, I think we can safely throw out 1), so the choice is between 2) or 3). -- brion

5 5

Feedback about Android app from a blind user
by Yuvi Panda 16 Jun '14

16 Jun '14

Made me feel very happy, thought I should share :) > From the point of view of a blind Android user relying on Talkback, this > beta represents a profound improvement. Thank you, Wikimedia, for > getting accessibility right! > There are two defects you could clear up before releasing this app. > There are a couple unlabeled buttons in the U-I. > I have found nothing else to complain of so far! And, for that reason, I > expect to get much use out of this app. https://ticket.wikimedia.org/otrs/index.pl?Action=AgentZoom&TicketID=7609290 :) (We will fix the unlabeled buttons in the UI before release) -- Yuvi Panda T http://yuvi.in/blog

1 0

Re: [WikimediaMobile] [Wikitech-ambassadors] Roadmap and deployment highlights - week of June 16th
by Federico Leva (Nemo) 16 Jun '14

16 Jun '14

Greg Grossmeier, 14/06/2014 00:30: > Tablets will be sent to the mobile version of the project > websites. Previously they were sent to the desktop version. There is > a blog post and central notice drafted and ready to go out day of. Will someone be monitoring the effects [if any] on editing activity and number of active editors/new [10+ edits] editors? Nemo

2 3

git review issue (wmf/1.24wmf7)
by Jon Robson 13 Jun '14

13 Jun '14

The following patches https://gerrit.wikimedia.org/r/139278 https://gerrit.wikimedia.org/r/139379 are being sent to wmf/1.24wmf7 rather than master any idea why?

2 3

help with a commit?
by Chris McMahon 13 Jun '14

13 Jun '14

Hi Mobilers, Unfortunately the new toc.feature test is creating pages on enwiki. I made a commit to fix it, but for some reason when I do a regular git clone on the MobileFrontend repo I am not getting the master branch but the 1.24wmf7 branch instead. This commit really needs to be merged to master as soon as possible, but I don't know how to do that at this point: https://gerrit.wikimedia.org/r/#/c/139379/ -Chris

2 3

Re: [WikimediaMobile] help with a commit?
by Jon Robson 13 Jun '14

13 Jun '14

* every 2 weeks by this I mean beta labs and enwiki are always 1-2 weeks apart On 13 Jun 2014 09:59, jrobson(a)wikimedia.org wrote: The code in production changes every 2 weeks. It doesn't really justify regular Jenkins jobs. I could understand running them every Thursday on a deployment but that's about it.. On 13 Jun 2014 09:37, "Chris McMahon" <cmcmahon(a)wikimedia.org> wrote: I'd like to turn off browser tests in production, I don't think they bring much value. On Fri, Jun 13, 2014 at 8:12 AM, Jon Robson <jrobson(a)wikimedia.org> wrote: > Maybe it is time to consider turning off browser tests in production or at > least disabling the API URL variable on those servers to stop creation of > pages? > On 13 Jun 2014 08:10, "Chris McMahon" <cmcmahon(a)wikimedia.org> wrote: > >> >> Hi Mobilers, >> >> Unfortunately the new toc.feature test is creating pages on enwiki. >> >> I made a commit to fix it, but for some reason when I do a regular git >> clone on the MobileFrontend repo I am not getting the master branch but >> the 1.24wmf7 branch instead. >> >> This commit really needs to be merged to master as soon as possible, but >> I don't know how to do that at this point: >> https://gerrit.wikimedia.org/r/#/c/139379/ >> >> -Chris >> >> _______________________________________________ >> Mobile-l mailing list >> Mobile-l(a)lists.wikimedia.org >> https://lists.wikimedia.org/mailman/listinfo/mobile-l >> >>

1 0

Fwd: Page Styling Issues
by Yuvi Panda 13 Jun '14

13 Jun '14

Forwarding to mobile-l ---------- Forwarded message ---------- From: Vibha Bamba <vbamba(a)wikimedia.org> Date: Fri, Jun 13, 2014 at 6:25 AM Subject: Page Styling Issues To: Dan Garry <dgarry(a)wikimedia.org>, Monte Hurd <mhurd(a)wikimedia.org>, Moiz Syed <msyed(a)wikimedia.org>, Yuvaraj Pandian <yuvipanda(a)wikimedia.org>, Bernd Sitzmann <bsitzmann(a)wikimedia.org>, Dmitry Brant <dbrant(a)wikimedia.org > Monte and I have been recording Page styling Issues here - https://etherpad.wikimedia.org/p/App_Page_Styling Please add to this if you see broken styling. Include Article and Sections as necessary. Thanks Vibha ---- Vibha Bamba Senior Designer | WMF Design

2 2

Browser support for MobileFrontend
by Juliusz Gonera 12 Jun '14

12 Jun '14

Since our support table for browsers [1] is wildly out of date, we should come up with something better. Oliver generated some statistics for us from the last 30 days from logs for text/html requests (see attachment). I think we could divide browsers into Grade A and Grade B categories, similarly to desktop. Grade A would be full support, Grade B would be basic support for reading (non-JS version). Two additional suggestions: * Don't care about anything below < 0.1% * Drop support for JS for any problematic browser with < 0.5% (mark them as Grade B) I think coming up with a generic metric like "support last N versions of X and last M versions of Y" for all browsers would be hard because the browser landscape changes pretty fast. I'd rather reevaluate our support table every few months. For now, I propose the following: Grade A: * Mobile Safari 5-7 (that includes Chrome for iOS since it uses Safari's engine) * Android Browser 2.3+ (drop 2.3 to grade B as soon as it's < 0.5%) * Chrome for Android 18+ * Firefox for Android, latest version (since it's not very popular, but still a good browser) * IE Mobile 9+ (drop 9 to grade B as soon as it's < 0.5%) * Blackberry Webkit 7+ Grade B: * lower versions of browsers in Grade A * Opera Mini 4+ * NetFront 3+ * Ovi Browser 2+ * Nokia Browser 7+ When it comes to Grade B browsers, I don't think we should test on them very regularly, but accept bugs that come from their users. Comments? [1] https://www.mediawiki.org/wiki/Browser_support#Mobile_browsers -- Juliusz

5 11

[Apps] Dark theme discussion outcome
by Dan Garry 12 Jun '14

12 Jun '14

Vibha, May, Monte, Yuvi and I just met to discuss the dark theme work. For context, when we rolled out the Android beta, by far the most requested feature was a dark mode/night mode. The old beta had this, and people really loved it. For iOS, we've agreed to wait on implementing something, for two reasons. The first is that iOS already has a system-level setting for colour inversion which satisfies some of the user requirements. Secondly, users of this platform may not even want this feature, so it makes more sense for us to focus on page styling instead, which we agreed is not in as good of a state on iOS as it is on Android. For Android, we agreed the need is more pressing. May (who has some thoughts on the dark theming due to her previous work on the apps) will work with Vibha and Moiz to come up with a mockup for what kind of colouring we want to use. Then we'll start implementing this next sprint. This does mean that we won't have the dark theme at the time of the market release, but it'll be in shortly thereafter, so that's okay. Thanks everyone! Dan -- Dan Garry Associate Product Manager for Platform and Mobile Apps Wikimedia Foundation

2 1

Testing Knockoff
by Jon Robson 12 Jun '14

12 Jun '14

Sumanah poked me in IRC today to ask when we are scheduling time to give KnockOff / TAssembly a spin in MobileFrontend. Gabriel Wicke is looking for feedback...

3 8

Browser tests coverage in MobileFrontend stable (Result of spike 1687)
by Jon Robson 12 Jun '14

12 Jun '14

I ran an audit of the existing browser tests for MobileFrontend as part of a mobile team spike [1]. You can see the results here: https://www.mediawiki.org/wiki/Mobile/QA_Test_Audit_March_2014 Our coverage is actually not too bad, but there is definitely room from improvement. That said I have a big concern is around the organisation of the tests and how they are written and what is written - many of the tests could do with being reworded and a lot of them should probably actually be deleted. There is a lot of code duplication. When auditing I found tests scattered all over the place. This suggests that we could benefit from reorganising the file structure to be more logical, in particular features that relate to special pages should have their own folder (this is particularly useful for clarifying what tests the watch star and what tests the actual watchlist page - Zeljko / Chris is it possible to have subfolders in the features directory that contain features?). I would also suggest the following actions for improving our test coverage: * Add tests for error handling on login / account creation * Add tests for this page has issues * Improve tests for key editing and upload workflows * Add tests for Language variant support * Add tests for full text search support * Improve the existing watch star tests so they actually check the end result * Add test to check the user can close the left navigation menu * Add tests for logout * Add tests for reference overlay * Add tests for toggling * Add tests for Nearby in skins other than Minerva (mobile skin) * Address hygiene issues on https://www.mediawiki.org/wiki/Mobile/QA_Test_Audit_March_2014 [1] https://wikimedia.mingle.thoughtworks.com/projects/mobile/cards/1687

3 5

Re: [WikimediaMobile] Provisional iOS release date: 7th July
by Tomasz Finc 11 Jun '14

11 Jun '14

Actually cc'ing mobile-l this time instead of just saying it ... On Wed, Jun 11, 2014 at 11:56 AM, Tomasz Finc <tfinc(a)wikimedia.org> wrote: > CC'ing mobile-l to get this archived and for others to know that its coming. > > Dan, given that we can't easily ship a beta within the iTunes store > what will the mechanics of the release look like? > > --tomasz > > On Wed, Jun 11, 2014 at 11:48 AM, Dan Garry <dgarry(a)wikimedia.org> wrote: >> Hey guys, >> >> Vibha, Moiz, Monte, Brion and I just met to get a date together for the >> release of the iOS app. We arrived at 7th July (3.5 weeks from now, the end >> of the next sprint). Here's how. >> >> I asked the engineers and designers what they felt the dependencies were. We >> identified: >> >> Edit workflow refinements (current sprint) >> Onboarding (first time UX) (current sprint) >> TOC refinement (next sprint) >> Styling refinement (next sprint) >> General bug fixes and cleanup (next sprint) >> >> The first three are hard requirements; if they're not in, then we will delay >> the release. The last two are softer requirements, particularly since we can >> update the app CSS without pushing out a new release. >> >> It was a careful negotiation! Monte originally wanted an extra sprint of >> slack, but I managed to arrive at the two sprint number by assuring him that >> if something game-breaking came up then we'd delay the release. I think the >> user feedback is really important, so I think it's worth setting the goal to >> be sooner rather than later. >> >> The cool thing is, this means the iOS release will only be two weeks after >> the Android one. Woohoo! >> >> We're all happy with this date. I'm meeting with Katherine tomorrow to >> discuss what the best communications strategy for this is. >> >> Thanks, >> Dan >> >> -- >> Dan Garry >> Associate Product Manager for Platform and Mobile Apps >> Wikimedia Foundation

1 0

Funding for development of WikiTrack mobile app approved
by Ryan Kaldari 11 Jun '14

11 Jun '14

This is essentially an app that gives you a mobile-friendly interface for tracking Recent Changes, Watchlist Changes, and Contributions on Wikipedia projects. See https://meta.wikimedia.org/wiki/Grants:IEG/WikiTrack for more information. Ryan Kaldari

2 1

VE on Android tablets
by Juliusz Gonera 10 Jun '14

10 Jun '14

I tried VE on the two working Android tablets that we have: Samsung Galaxy Tab 10.1 (Android 4.0.4) and Nexus 7 (Android 4.4.2). Samsung uses Android Browser and VE performs slowly and buggy there. Link inspector works better than on iOS but there are other small bugs like problems with some icons not being scaled properly or occasional rendering issues. Nexus 7 with Kitkat has Chrome as its default browser and everything works fine there, I would even say it works better than iPads. Kaldari is doing more research regarding which tablets should be redirected to mobile. -- Juliusz

2 3

[Apps] Conclusions on abuse filter in edit workflow
by Dan Garry 09 Jun '14

09 Jun '14

Hi everyone, This edit concerns discussions that Vibha, Yuvi and I have had about the abuse filter today. As it is part of the edit workflow, these discussions took place to unblock the card. The abuse filter works just fine on both platforms, but the design leaves a bit to be desired. For those of us who are unfamiliar with the abuse filter, I've prepared a short write-up in this Google Doc <https://docs.google.com/a/wikimedia.org/document/d/1VIIQhkribQuJa-6ugm3XM5d…> that explains what the abuse filter is. Here's the outcome of the discussions: 1) The abuse filter stuff has been broken off of the edit workflow cards and placed onto its own card here. This unblocks the iOS card, and then the Android card is only blocked by waiting for the relevant design. 2) The interaction of the designs on iOS is good. The design restyling that's in the edit workflow changes card can take place, but the functionality can remain the same. This goes for Android too. Let me know if you've got any questions! Thanks, Dan -- Dan Garry Associate Product Manager for Platform and Mobile Apps Wikimedia Foundation

1 0

Sprint 33: The Final (Android) Countdown begins!
by Dan Garry 09 Jun '14

09 Jun '14

Hi everyone, Our final sprint before the Android release has come! Woohoo! There are a few blocked cards in Trello: 1. Edit workflow changes: This card is awaiting the Android design. I've followed up with Vibha and Moiz and the design should be available by the end of the day today. 2. Re-do buttons for progressive styling: I think Monte and Moiz had some discussions about this last week but I'm not sure what came of it. Monte, can you update the card? 3. TOC bar: Blocked on us making a decision about whether the TOC button should have a spinner or not. Did we reach a decision about this? 4. More menu: Blocked on me making a decision about what should go in the menu. I will do that today and note on the card. Thanks everyone! Dan -- Dan Garry Associate Product Manager for Platform and Mobile Apps Wikimedia Foundation

2 1

[Apps] Edit workflow refinements
by Dan Garry 06 Jun '14

06 Jun '14

Hi all, Monte, Yuvi, Vibha, Moiz, Jared, Howie and I met today to talk about refining the edit workflow on the apps. The statement of the problem is that user testing has shown that in the current workflow the preview step is not useful; people are not recognising that it is a preview, not recognising the edit summary box is there, and accidentally abandoning their edits because they think they've saved already. This is related to the fact that there are too many steps in the edit workflow. In particular, the call to action to "sign in and save" or "save anonymously" was basically ignored by everyone who tested the app. Our macro-level goal for the app is to get people to edit. Whether that's by signing in and saving or by saving anonymously isn't as important to us as *actually getting them to edit.* Our course of action is therefore multi-faceted: 1. For the MVP we're removing the call to action to sign in and save. Since people are ignoring it, it's not really serving any purpose in the current workflow except to bloat it. This drastically reduces the number of steps in the process. 2. We're flipping the edit summary box and preview around, so that when you make a change and click next you see the edit summary on top. This makes it clearer that your edit hasn't saved, it emphasises the canned edit summaries that users responded positively to in the testing, and makes the preview step feel more optional. We're also going to restyle this page slightly to make it clearer. The workflow for editing is now press edit > make change > press next > enter edit summary (and optionally view preview) > save. This makes the workflow much easier to use, and a lot clearer. I realise that my description above isn't great; Vibha and Moiz are going to create a mockup for it, and I'll share that on this list once we've got it. Thanks everyone! Dan -- Dan Garry Associate Product Manager for Platform and Mobile Apps Wikimedia Foundation

2 3

Android app user feedback and requests
by Dmitry Brant 06 Jun '14

06 Jun '14

Hey all, Here's an etherpad with an aggregate of what our users have been asking for, so far (since the beta release): http://etherpad.wikimedia.org/p/androidappfeedback -Dmitry

4 6

Mobile tags for Wikipedia android app
by Dario Taraborelli 06 Jun '14

06 Jun '14

This afternoon Dan and I reviewed how tags from the android app are captured in the change_tag and tag_summary tables. (1) We noticed that the “mobile app edit” tag is applied to recentchanges events that are not edits, but new account registrations: SELECT * FROM enwiki.change_tag WHERE ct_rev_id IS NULL AND ct_tag = "mobile app edit"; ct_rc_id ct_log_id ct_rev_id ct_tag ct_params 661123291 56899294 NULL mobile app edit NULL 661123407 56899301 NULL mobile app edit NULL 661124928 56899375 NULL mobile app edit NULL 661127933 56899610 NULL mobile app edit NULL 661128644 56899685 NULL mobile app edit NULL 661131626 56899908 NULL mobile app edit NULL 661133278 56899998 NULL mobile app edit NULL 661134572 56900072 NULL mobile app edit NULL 661140653 56900620 NULL mobile app edit NULL 661155198 56901558 NULL mobile app edit NULL 661155799 56901593 NULL mobile app edit NULL 661156983 56901659 NULL mobile app edit NULL AFAIK this is unusual behavior for tags and will create artifacts in tagged revisions unless people are aware that all these registration-related events always need to be excluded (it’s also confusing because the name of the tag explicitly refers to an edit). As suggested earlier [1], we should not track the source of account registrations via MediaWiki tags but via the ServerSideAccountCreation log. (2) edits made on apps should be stored with two separate tags: “mobile edit” and “mobile app edit”. The tags are correctly stored in the change_tag table with 2 records for each revisions, e.g. SELECT * FROM enwiki.change_tag WHERE ct_rc_id = 661110028; ct_rc_id ct_log_id ct_rev_id ct_tag ct_params 661110028 NULL 611585155 mobile app edit NULL 661110028 NULL 611585155 mobile edit NULL but when the tags are combined in the tag_summary table, the “mobile app edit” tag is lost: SELECT * FROM enwiki.tag_summary WHERE ts_rc_id = 661110028; ts_rc_id ts_log_id ts_rev_id ts_tags 661110028 NULL 611585155 mobile edit This should not be the case, the 2 tags should be concatenated in the ts_tags field, see for example this desktop revision with 2 tags: SELECT * FROM enwiki.change_tag WHERE ct_rc_id = 578489188; ct_rc_id ct_log_id ct_rev_id ct_tag ct_params 578489188 NULL 555564321 gettingstarted edit NULL 578489188 NULL 555564321 visualeditor NULL SELECT * FROM enwiki.tag_summary WHERE ts_rc_id = 578489188; ts_rc_id ts_log_id ts_rev_id ts_tags 578489188 NULL 555564321 gettingstarted edit,visualeditor I believe that neither (1) nor (2) is intended behavior for apps. Can you guys confirm and if so, can we fix this? Dario [1] http://lists.wikimedia.org/pipermail/mobile-l/2014-May/007150.html

7 10

[Apps] Discussions on apps: what do?
by Dan Garry 05 Jun '14

05 Jun '14

Hey everyone, Monte, Yuvi, Danny (PM for Flow) and I met today to discuss our way forwards with discussions on apps. The statement of the problem is that the apps currently don't surface discussions at all; both article talk and user talk are not made apparent to the user. This creates problems for power users and new users alike; power users workflows are built around discussions so we serve them poorly, and new users can't interact with anyone, which includes things like new users being unable to read vandalism warnings. Our solution needs to let people participate meaningfully in discussions, both on article talk pages and also meta-discussions (user talk pages, etc.) So the question is, do we do a styling pass on talk pages to make them easier to use on the apps and surface those talk pages, or do we just wait for Flow (for some definition of "wait")? We were leaning towards the former, but wanted to make sure we'd considered all the variables before proclaiming we had a solution. We discussed. We felt that waiting for Flow introduces too many unknowns; Flow will not be deployed to user talk pages for at least six months, which is a long time to wait to get discussions implemented. Even then, it may be even longer before we can reliably say "all discussions are on Flow". We can't afford to wait that long to serve the need for discussions in the app. *This email in a nutshell: Waiting for Flow is insufficient. We want to do a styling pass on talk pages to make them usable on apps.* Let me know if you have any questions! Thanks, Dan -- Dan Garry Associate Product Manager for Platform and Mobile Apps Wikimedia Foundation

4 4

Fwd: I have an issue on Mediawiki with MobileFrontend installed
by Max Semenik 05 Jun '14

05 Jun '14

---------- Forwarded message ---------- From: Deepak Gupta <deepak343(a)gmail.com> Date: Thu, Jun 5, 2014 at 11:38 AM Subject: I have an issue on Mediawiki with MobileFrontend installed To: maxsem.wiki(a)gmail.com Hi Maxsem, I have an issue on Mediawiki with MobileFrontend installed. I have set wgMFAnonymousEditing= true; But when I edit any article on the wiki page with mobile version of the skin, I am not able to save it. It says - "Error, edit not saved." However if I am logged in, there are no errors. But on the desktop version of the site, there are no errors. Can you please help me? Thanks, Deepak -- Best regards, Max Semenik ([[User:MaxSem]])

3 3

Apps page styling issues etherpad link
by Monte Hurd 05 Jun '14

05 Jun '14

Here's a quick link to a page Vibha and I started as a scratchpad for a list of page styling issues we've identified in particular articles. https://etherpad.wikimedia.org/p/App_Page_Styling Wanted to share this as an initial touchpoint for surfacing some small styling tweaks that may need to be made to MobileApp css files.

2 1

Syntax highlighting in Edit window
by Dmitry Brant 04 Jun '14

04 Jun '14

Hi all, This is something I've been tinkering with for a bit: https://www.dropbox.com/s/g9svwrlvf839z9f/device-2014-06-04-085320.png IMHO, the Wiki markup syntax can be quite daunting for new editors, and when editing articles with a lot of markup, the edit window can look like a cacophony of symbols. In lieu of a full-blown VE interface, I propose implementing a minimal form of "syntax highlighting" that will at least guide new editors on the usage of Wiki markup, and might even help experienced editors double-check what they're adding without requiring a preview. What does everyone think of this? -Dmitry

9 12

Wikipedia 2.0 Beta 1 Release Candidate
by Yuvi Panda 04 Jun '14

04 Jun '14

(actually Wikipedia Android 2.0 Beta 1 Release Candidate 1 Enterprise Ultimate Edition) Hello everyone! The rebooted Wikipedia Android app is scheduled to go out to the Play store as the Wikipedia (Beta) app[1] tomorrow (4 June 2014). All the patches we wanted merged have been merged, and I request everyone who can to test this on whatever device they have today and early tomorrow so we can have a happy beta release period. You can either download it from [2] or get it via the Play store's 'alpha' functionality[3]. Thanks everyone for making this happen! [1]: https://play.google.com/store/apps/details?id=org.wikipedia.beta [2]: https://releases.wikimedia.org/mobile/android/wikipedia/alphas/wikipedia-2.… [3]: https://lists.wikimedia.org/pipermail/mobile-l/2014-March/006642.html -- Yuvi Panda T http://yuvi.in/blog

1 0

Repeating failing tests - any ideas?
by Jon Robson 03 Jun '14

03 Jun '14

There is a consistent failure on 2 tests in the Chrome build. Firefox build not effected. These tests both depend on the window size being >= 768px 1) Table of contents.Show table of contents on tablet 2) Toggling sections.Section open by default on tablet When run locally against beta labs they pass for me. Is there any known issues with cloudbees around browser window size manipulation? It's the only thing I can think that might be causing this issue. The step that might not be working as expected is: Given(/^I am viewing the site in tablet mode$/) do @browser.window.resize_to(768, 1024) end https://wmf.ci.cloudbees.com/job/MobileFrontend-en.m.wikipedia.beta.wmflabs…

3 2

Re: [WikimediaMobile] Android icons
by Tomasz Finc 03 Jun '14

03 Jun '14

CC'ing the mailing list so that we can have this archived. On Tue, Jun 3, 2014 at 12:50 PM, Bernd Sitzmann <bsitzmann(a)wikimedia.org> wrote: > Hi Vibha and Moiz, > > I think we should look at the icons a bit more for the full release. The > icon we have for editSave is from the Android Icon Pack > <https://developer.android.com/design/downloads/index.html>, which is > great but the other icons we have are much thicker, like the one for ToC. > So, for beta having consistency within the app is good enough, but > eventually we should get closer to the platform icon style. The Iconography > Guide for Android > <http://developer.android.com/design/style/iconography.html> also calls > for less opacity in the action bar icons. > > (1) Table of Contents icon: [seems very thick and fuzzy compared to the > editSave from Android Icon Pack below. I think it has too much padding and > by our code scaling it up to 48dp it becomes fuzzy. We should scale our > fake action bar icons to just 32dp BTW.] > > [image: Inline image 1] > > (2) editSave from Android Icon Pack: > > [image: Inline image 4] > > (3) our editSave icon: [too much padding --> seems too small] > > [image: Inline image 3] > > Here is the latter with the rest of the screen: > > > > > I also think that the *launcher icon* should either not have any rounded > border at all. At least, we should use a different icon for the action bar, > like shown here (using the same icon as in the search fragment: search_w): > > > > The Iconography Guide for Android > <http://developer.android.com/design/style/iconography.html> states that > the launcher icon should be a distinct silhouette. See also Android > Design in Action: Football Apps + Launcher Icons > <https://developers.google.com/live/shows/97567912>, you can skip to > minute 22, when launcher icons are covered. > Thank you, > Bernd >

2 1

Re: [WikimediaMobile] Android icons
by Bernd Sitzmann 03 Jun '14

03 Jun '14

Sounds great. Standing by. Any changes for the action bar home icon? Right now the real action bar's home icon (the W on the left) could look much better if it didn't have the border around it. Do you mind if I'd switch to the search_w icon for the real action bar home icon as well? (See the last image in my original message.) Thanks, Bernd On Tue, Jun 3, 2014 at 1:05 PM, Vibha Bamba <vbamba(a)wikimedia.org> wrote: > Hi Bernd! > Excellent points. All the inconsistencies will ironed out once we use all > icons from Wikifont. > While we reuse all the native interaction patterns on android, the > iconongraphy will be wikifont. > So this means we will not use default android icons. Where needed we can > replicate the shapes in a heavier weight which is consistent with Wikifont. > > Currently, > Previous/Back > Next > Share > Save > More > are in the wikifont. > > I'm talking to yuvi right now to export these into the appropriate size > folders for android > I'll ping you as soon as that is done. > > Thanks > Vibha > > ---- > Vibha Bamba > Senior Designer | WMF Design > > > > > > > > > On Tue, Jun 3, 2014 at 12:50 PM, Bernd Sitzmann <bsitzmann(a)wikimedia.org> > wrote: > >> Hi Vibha and Moiz, >> >> I think we should look at the icons a bit more for the full release. The >> icon we have for editSave is from the Android Icon Pack >> <https://developer.android.com/design/downloads/index.html>, which is >> great but the other icons we have are much thicker, like the one for ToC. >> So, for beta having consistency within the app is good enough, but >> eventually we should get closer to the platform icon style. The Iconography >> Guide for Android >> <http://developer.android.com/design/style/iconography.html> also calls >> for less opacity in the action bar icons. >> >> (1) Table of Contents icon: [seems very thick and fuzzy compared to the >> editSave from Android Icon Pack below. I think it has too much padding and >> by our code scaling it up to 48dp it becomes fuzzy. We should scale our >> fake action bar icons to just 32dp BTW.] >> >> [image: Inline image 1] >> >> (2) editSave from Android Icon Pack: >> >> [image: Inline image 4] >> >> (3) our editSave icon: [too much padding --> seems too small] >> >> [image: Inline image 3] >> >> Here is the latter with the rest of the screen: >> >> >> >> >> I also think that the *launcher icon* should either not have any rounded >> border at all. At least, we should use a different icon for the action bar, >> like shown here (using the same icon as in the search fragment: search_w): >> >> >> >> The Iconography Guide for Android >> <http://developer.android.com/design/style/iconography.html> states >> that the launcher icon should be a distinct silhouette. See also Android >> Design in Action: Football Apps + Launcher Icons >> <https://developers.google.com/live/shows/97567912>, you can skip to >> minute 22, when launcher icons are covered. >> Thank you, >> Bernd >> > >

1 0

MobileFrontend installhooks PHP_CodeSniffer
by Florian Schmidt 03 Jun '14

03 Jun '14

Hello all together! Maybe someone can help me? :) I have reinstalled my development system and so reinstalled MediaWiki and MobileFrontend Development Environment. After i installed git, gerrit and so on, i started to install tests. qunit and phpunit runs perfectly without errors and works fine. But now comes a little problem. After the first test commit, the script would install phpcodesniffer via composer, and there i had two warnings/errors: Skipped installation of bin dev-scripts/phpcs for package squizlabs/php_codesniffer: file not found in package Skipped installation of bin dev-scripts/phpcbf for package squizlabs/php_codesniffer: file not found in package Correctly the script except with message, that phpcodesniffer has to installed (make phpcheck says all ok). Now my question is: Am i to silly or somtehing else? After i changed the line phplint.sh to the new location of phpcs (vendor/squizlabs/php_codesniffer/scripts) the test works. But im unsure, if im right to only change the line of the localtion of phpcs and all is good. Can you ad hoc say anything to that? That would be extremly helpful for me :) You can contact me via this E-Mailadress, mobile-l and irc (#wikimedia-mobile FlorianSW). Big thanks! Kind regards Florian Freundliche Grüße Florian

2 1

Take-home messages from user testing
by Dan Garry 02 Jun '14

02 Jun '14

Hi everyone, So as you know I did some user testing a few weeks ago. Here's the messages I took home from it, and how I think we can address those. Most of these have been covered in meetings and in our planning for the next sprint, but I think it's still worth making explicit. *1) The preview step, as it stands, is not useful. *A lot of new users don't understand that they're being presented with a preview and think instead that their edit is already saved. Meanwhile, experienced editors are annoyed at not having the ability to choose when they preview like they do on desktop. For our MVP we're moving towards taking preview out as a discrete step, and also using text on buttons to make it clearer what actions are happening. *2) Searching and starting the edit workflow is really clear to people.* People know exactly how to search, what was happening, and that hitting the pencil let them edit the article. That's great. *3) People don't notice the edit summary box.* This is probably a sub-problem of finding the preview step confusing. When I pointed it out to people, they happily started using it, so it's not that they can't be bothered using the feature, it's just that they're not discovering it. We're going to look into ways of making the edit summary box more noticeable in combination with the work to resolve point 1. *4) When people are pointed to the canned edit summaries dialogue on iOS, they use it fluidly.* It was a big hit with people and they understood it instantly. This was such a success that I think we should look at getting it onto Android further down the line. Like I said, we're working on most of this stuff already. This is mostly just for posterity. Thanks! Dan -- Dan Garry Associate Product Manager for Platform and Mobile Apps Wikimedia Foundation

7 10

Proportion of mobile views to Italian Wikipedia
by Federico Leva (Nemo) 02 Jun '14

02 Jun '14

Do Mobile folks have some quick way to tell roughly what percentage of it.wiki pageviews comes from mobile, compared to 1 year ago or to the all wikis average? Checking just the visits to main page is also fine. Context: I want to reduce the long list of possible suspects for <https://meta.wikimedia.org/wiki/Research:The_sudden_decline_of_Italian_Wiki…>. Also, at Wikimedia Italia we digested the forecast by Tomasz that in 2015 mobile may reach desktop; we find such information very useful to orient ourselves in the modern landscape of Wikimedia projects. Nemo

2 1

last browser test build fails with undefined step
by Chris McMahon 02 Jun '14

02 Jun '14

I found a red Jenkins build with no test failures, the problem might not be immediately clear. In the logs I find this, which seems to be the cause of the build failure: Feature: Loading pages Background: # features/page_loading.feature:4 Given the page "Selenium page loading test" exists # features/step_definitions/create_page_api_steps.rb:42 Scenario: Page loads without ajax in stable # features/page_loading.feature:7 Given I visit a protected page # features/step_definitions/create_page_api_steps.rb:86 Undefined step: "The "Selenium protected test 2" page is protected." (Cucumber::Undefined) /scratch/jenkins/addons/ruby/ruby-2.1.1-x86_64/lib/ruby/gems/2.1.0/gems/cucumber-1.3.14/lib/cucumber/runtime/support_code.rb:145:in `step_match_without_cache' https://wmf.ci.cloudbees.com/job/MobileFrontend-en.m.wikipedia.beta.wmflabs…

2 1

FW: [Wikimedia Announcements] WMF Round 1 2014 Individual Engagement Grantees
by ENWP Pine 01 Jun '14

01 Jun '14

Forwarding for the benefit of those not on other lists. Individual Engagement Grants have been announced for topics relevant to mobile tech, research, and editor engagement. Congrats to grantees and I hope we see them on these lists. Consider applying in the next round, and visit IdeaLab to propose and discuss ideas! [1] IdeaLab is for everyone, even if you are not personally requesting funding such as if you have an idea and hope that someone else executes it. For more detail about grants funded see [2] Pine (IEGCom member) [1] https://meta.wikimedia.org/wiki/Idealab [2] https://blog.wikimedia.org/2014/05/30/new-grantees-fresh-perspectives-resea… Date: Sun, 1 Jun 2014 11:50:49 -0430 From: hahc21(a)gmail.com To: wikimedia-l(a)lists.wikimedia.org; wikimediaannounce-l(a)lists.wikimedia.org Subject: [Wikimedia Announcements] WMF Round 1 2014 Individual Engagement Grantees Today we're announcing the latest round of Individual Engagement Grantees. These grants from the Wikimedia Foundation support individuals and small teams of Wikimedians to experiment with new ideas aimed at having online impact.[1] This round, the IEG committee recommended and WMF approved 12 projects led by 16 grantees with countless volunteer participants from around the world. For the first time, Individual Engagement Grants are funding mobile app development, Wikipedia research, and projects aimed at improving Wikivoyage and Wiktionary. Introducing Wikimedia's round 1 2014 Individual Engagement Grantees: Making Telugu Content Accessible, led by Santhosh, funded at 104,000 Rupees.[2] Medicine Translation Community Organizing, led by CFCF, funded at $10,000.[3]Open Access Reader, led by Edward Saperia, funded at $6550.[4] Optimizing Wikimedia Category Systems, led by Paul J. Weiss, funded at $9750.[5] Promoting Wikivoyage, led by Tammy Bennert, funded at $600.[6] Pronunciation Recording, led by Rilke with participation from Ungoliant MMDCCLXIV and Infovarius, funded at ?1450.[7]Reimagining Wikipedia Mentorship, led by I JethroBT, Soni, and Gabrielm199, funded at $22,600.[8] Senior Citizens Write Wikipedia, led by Vojtěch Veselý with participation from Vojtěch Dostál, Václav Šulc, and Jan Sokol, funded at 160,000 CZK.[9] Tools for Armenian Wikisource and Beyond, led by Xelgen with participation from HrantKhachatrian and Mahnerak, funded at $7600.[10] The Wikiquiz, led by Addis Wang, Mys 721x, and Ericmetro, funded at $1070.[11] WikiTrack, led by Hari Prasad Nadig, funded at $2500.[12]Women and Wikipedia, led by Amanda Menking, funded at $8075.[13] You can read more about them all on the WMF blog.[14] To everyone who contributed to this round of grants with proposals, ideas, feedback and suggestions: thank you! The next call for proposals opens on 1 September - we look forward to seeing more of your ideas and engagement again soon. Sincerely, Harold HidalgoIndividual Engagement Grants Committee 1. https://meta.wikimedia.org/wiki/Grants:IEG 2. https://meta.wikimedia.org/wiki/Grants:IEG/Making_telugu_content_accessible 3. https://meta.wikimedia.org/wiki/Grants:IEG/Medicine_Translation_Project_Com… 4. https://meta.wikimedia.org/wiki/Grants:IEG/Open_Access_Reader 5. https://meta.wikimedia.org/wiki/Grants:IEG/Optimizing_Wikimedia_Category_Sy… 6. https://meta.wikimedia.org/wiki/Grants:IEG/Promoting_Wikivoyage 7. https://meta.wikimedia.org/wiki/Grants:IEG/Pronunciation_Recording_(Finish_… 8. https://meta.wikimedia.org/wiki/Grants:IEG/Reimagining_Wikipedia_Mentorship 9. https://meta.wikimedia.org/wiki/Grants:IEG/Senior_Citizens_Write_Wikipedia 10. https://meta.wikimedia.org/wiki/Grants:IEG/Tools_for_Armenian_Wikisource_an… 11. https://meta.wikimedia.org/wiki/Grants:IEG/The_Wikiquiz 12. https://meta.wikimedia.org/wiki/Grants:IEG/WikiTrack 13. https://meta.wikimedia.org/wiki/Grants:IEG/Women_and_Wikipedia 14. http://blog.wikimedia.org/tag/individual-engagement-grants/ _______________________________________________ Please note: all replies sent to this mailing list will be immediately directed to Wikimedia-l, the public mailing list of the Wikimedia community. For more information about Wikimedia-l: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l _______________________________________________ WikimediaAnnounce-l mailing list WikimediaAnnounce-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikimediaannounce-l

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

Mobile-l June 2014