Mobile-l July 2014

mobile-l@lists.wikimedia.org

46 participants
74 discussions

Re: [WikimediaMobile] [Wikimedia-l] Thank you Mobile team
by Tomasz Finc 30 Jul '14

30 Jul '14

And for those wondering who all is on the mobile team you can find them here https://www.mediawiki.org/wiki/Mobile_web/Team Congrats to the team for their success. --tomasz On Fri, Jul 11, 2014 at 3:47 AM, Àlex Hinojo <alexhinojo(a)gmail.com> wrote: > +1 > > I've been doing wiki workshops for Amical during last couple of years and > since 6 months ago or so I ONLY train newbies with the visual editor. My > role on the workshop now is reduced to explain how extra features are done. > > So kudos to the mobile team. And I know is not perfect. Is just wiki ;) > > > > > 2014-07-11 10:16 GMT+02:00 Pierre-Selim <pierre-selim(a)huard.info>: > >> 2014-07-11 10:06 GMT+02:00 Pine W <wiki.pine(a)gmail.com>: >> >> > While we're talking about technology issues on WIkimedia-l, I'd like to >> say >> > that now that I've worked my way over a few speedbumps with mobile >> editing >> > I'm happy with the direction that mobile editing is going, so thank you >> > Mobile team. >> > >> >> +1 >> >> I also want to add, that I'm happy with the Visual Editor. It's not >> perfect, but for basic editing it works just fine. I've had very nice >> feedback from new user during training on how Visual Editor works. >> >> >> > >> > Pine >> > _______________________________________________ >> > Wikimedia-l mailing list, guidelines at: >> > https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines >> > Wikimedia-l(a)lists.wikimedia.org >> > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, >> > <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe> >> >> >> >> >> -- >> Pierre-Selim >> _______________________________________________ >> Wikimedia-l mailing list, guidelines at: >> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines >> Wikimedia-l(a)lists.wikimedia.org >> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, >> <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe> >> > _______________________________________________ > Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines > Wikimedia-l(a)lists.wikimedia.org > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>

1 0

Preliminary iOS media playback in mobile view
by Brion Vibber 30 Jul '14

30 Jul '14

Today I took a stab at combining ogv.js JavaScript-based media playback with MobileFrontend by adding a loader shim to TimedMediaHandler on the 'mobile' target (the rest of TimedMediaHandler's desktop support code is not loaded, so the UI is mobile-specific but very bare-bones). Demo page can now play back audio and video in iOS 7's Safari in mobile mode as well as desktop mode: * https://ogvjs-testing.wmflabs.org/ The TMH+ogv.js patch in progress: * https://gerrit.wikimedia.org/r/#/c/145756/ The mobile loader code checks for any <audio> or <video> elements and asks them if they canPlayType() on any of their available sources, so it only loads if non-native playback is actually required. (So for instance it disengages on Android Chrome which can play Ogg Vorbis audio and WebM video, or in theory in Safari if you have locally enabled MP4/H.264 files.) It needs more work to check for browser compatibility, sufficient JavaScript engine speed, etc, but I find it encouraging that it works so far. :) Some thoughts and questions: * Currently ogv.js gets loaded if any audio/video elements are present that require it to play, even if they don't get played. I can delay the loading to when 'play' is clicked fairly easily. * [[Media:]] or other direct file links, often used for pronunciation markers in Wikipedia articles, are not picked up by this system. Need to extend things a bit to detect clicks on such links and display a player instead of just downloading the file. Same problem occurs in Safari and IE on desktop mode. * Should we show the video in an overlay like the mobile media viewer for images, instead of playing inline? This is a good place to add additional controls to reach file info details, as with images. If so should I try to extend the same overlay code in MF or create a near-lookalike that lives in TMH? * If so, that should probably be used for *all* mobile browsers, using the native playback when available instead of loading ogv.js... * Should we have a manual resolution switcher, as on desktop? (Controlling source selection via code could also fix a problem with Android being unable to play Ogg Theora videos, to force it to WebM which does work natively.) * On iOS, should the source selector offer to launch higher-res and WebM videos in the external VLC app? 360p is about the limit of good performance in ogv.js on current A7-based iOS devices, and slower models max out at 160p if they can even handle that. -- brion

2 1

Disambiguation + page issues styling
by Dmitry Brant 29 Jul '14

29 Jul '14

Hi Vibha / Dan, Here are some screenshots of the new disambiguation styling changes (along with Bernd's page-issues changes)! The way it works: it searches for the first "hatnote" in a page, which usually contains a disambiguation link, and transforms it into a "Similar titles" button, but *only* if the hatnote contains a single link. What this implies: - Hatnotes with more than one link will not be transformed (e.g. https://en.wikipedia.org/wiki/James_(name) ). - Only the first hatnote is transformed (e.g. https://en.wikipedia.org/wiki/Santa_Claus ). And here's the APK: https://releases.wikimedia.org/mobile/android/wikipedia/scratch/wikipedia-2… -Dmitry device-2014-07-29-183937.png <https://docs.google.com/a/wikimedia.org/file/d/0BzcksMsMNpY1UWR5YUh1ZXdqUEk…> device-2014-07-29-184016.png <https://docs.google.com/a/wikimedia.org/file/d/0BzcksMsMNpY1NkFZcHctM3RSc0U…> device-2014-07-29-184041.png <https://docs.google.com/a/wikimedia.org/file/d/0BzcksMsMNpY1VnRscGtrYXU1Um8…> device-2014-07-29-184108.png <https://docs.google.com/a/wikimedia.org/file/d/0BzcksMsMNpY1V2VTNHdiekk1Qms…>

1 0

Re: [WikimediaMobile] Flag Icon
by Dmitry Brant 28 Jul '14

28 Jul '14

Yay, that looks awesome! (+mobile-l) On Tue, Jul 22, 2014 at 4:46 PM, Vibha Bamba <vbamba(a)wikimedia.org> wrote: > OMG this looks great! And so fast :) > Two small changes > > 1. The flag and message should be top aligned > (let me know if the canvas are is getting in the way for this) > I can provide a flag icon in a 24 dp focus area with no padding. > > 2. The date when the template was added needs to be on its own line, no > parenthesis. All caps in color #555, 2-3 types sizes smaller than the > description (I can provide an exact type size value if I know the > relatives values) > > Thanks! > Vibha > > > > > ---- > Vibha Bamba > Senior Designer | WMF Design > > > > > > > > > On Tue, Jul 22, 2014 at 1:33 PM, Bernd Sitzmann <bsitzmann(a)wikimedia.org> > wrote: > >> Vibha, >> >> Thank you for the flag icon. Attached you can find some screen shots for >> the page issues dialog for your review: one with light theme, another one >> with dark theme. Let me know what needs to change, while I'm working on >> getting the flag image to show up in the WebView. >> Now looking at some real-world page issues I see that maybe the original >> name "article issues" is not so far off since most of the issues seems to >> mention the word article instead of page. >> >> pageIssuesLight.png >> <https://docs.google.com/a/wikimedia.org/file/d/0BxUyJSM66jQvZUk3Uy1VWEVLX1E…> >> >> pageIssuesDark.png >> <https://docs.google.com/a/wikimedia.org/file/d/0BxUyJSM66jQvWUMwcHdXeW02bHc…> >> >> Cheers, >> -Bernd >> >> >> On Mon, Jul 21, 2014 at 6:07 PM, Vibha Bamba <vbamba(a)wikimedia.org> >> wrote: >> >>> This is consistent with wikifont. >>> It is set in a 32 dp canvas with 24 dp focus area. >>> Please lmk if you see any issues :) >>> >>> >>> ---- >>> Vibha Bamba >>> Senior Designer | WMF Design >>> >>> >>> >>> >>> >>> >>> >> >

4 9

[Zero + Mobile Web] Lower-end device audit: notes + your input needed!
by Maryana Pinchuk 28 Jul '14

28 Jul '14

On Friday afternoon, Juliusz, Dan Foy and I sat down to test the mobile site on a few lower-end phones and browsers. Specifically, we looked at en.m.wikipedia on a Nokia not running JavaScript and a higher-end Samsung phone (Juliusz's) running Opera Mini. Some issues we may want to figure out/fix at some point in the near-to-medium future, in order of priority: 1) Using screen size detection to decide whether to serve certain features to lower-end devices results in some unexpected issues, like the watchlist star showing up in landscape mode but not portrait mode on Nokia no js. More pressingly, the search field frame doesn't show up on Opera Mini on a higher-end phone, despite the fact that it's a no-JS experience (and has no placeholders in the search field, making the search area weirdly blank and confusing). According to Dan, the Opera Mini + higher end Android phone combo is pretty common in the developing world, so we probably need a better way to handle it. There's an open bug on this here: https://bugzilla.wikimedia.org/show_bug.cgi?id=64926 2) Another issue with Opera mini not showing placeholders: the login and create account forms appear blank, so it's pretty much impossible to figure out what to enter into each of the fields. Bug here: https://bugzilla.wikimedia.org/show_bug.cgi?id=68758 3) The watch/unwatch workflow in no-JS mode is pretty wonky: when you tap the watch star, you get taken to a separate page (which has the article title at the top, making it look sort of like the article is broken/missing) that tells you you're now watching the article, but the star doesn't change state and there's no way to get back to the article without using browser/device back. # 2 & 3 point to a larger issue, which is whether login is really worth it for these users, if pretty much all they can do is watch/unwatch articles and look at changes to them – the watchlist features might be more confusing than beneficial, especially in the suboptimal way they're now implemented, and the Mobile Web team doesn't really have the time/bandwidth to improve them at this point. I'm leaning toward suggesting that *we remove login/account creation entirely on no-JS devices and Opera Mini browser* and only revisit it when we can build a robust set of features that meet clear end-user needs – but I'd be interested in hearing what you guys (Zero + Mobile Web) think, and how we might test to figure out what these user needs are. The full notes from our testing are here: http://etherpad.wikimedia.org/p/Lower_end_devices_checkup -- Maryana Pinchuk Product Manager, Wikimedia Foundation wikimediafoundation.org

2 1

Re: [WikimediaMobile] lazy-loading spike results
by Jon Robson 28 Jul '14

28 Jul '14

Wait... I'm not convinced by this. I'm not convinced you measured the right things. How exactly did you measure this? Did you include the HTTP response time? I struggle to believe that non-lazy loaded pages could ever be faster and that the improvement was on a half second. Can you post more details on the tests you ran? Really you should be looking at numerous things, namely: 1) Time from user request (refresh page) to being able to read the content (DOM content loaded) - e.g. time the HTTP request takes when just using the api and just using HTML 2) Time the JavaScript loads and the page becomes interactive (with a lazy loaded page this will always be 0s and on a non-lazy loaded page this will always be more as the entire HTML, JS and CSS has to be loaded) cc'ing mobile-l On Mon, Jul 28, 2014 at 11:39 AM, Maryana Pinchuk <mpinchuk(a)wikimedia.org> wrote: > Thanks, Kaldari – I've changed the description in this card[1] to reflect > your recommendation. Unless anyone objects, we'll remove lazy-loading > entirely in the next sprint. > > 1. https://trello.com/c/fFoRlvxl/3-5-remove-ajax-page-loading-from-alpha > > > On Mon, Jul 28, 2014 at 11:00 AM, Ryan Kaldari <rkaldari(a)wikimedia.org> > wrote: >> >> I did a spike on the effects of lazy loading pages on save. I tried a >> variety of different articles and did at least 10 tests in each mode. >> >> On stub size articles, lazy loading resulted in a half-second improvement >> in page loading on average. On larger articles, there was greater variation >> in lazy-loading time and the averages were virtually identical >> (non-lazy-loaded time was actually 0.15 seconds faster on average, but this >> was not statistically significant). >> >> So basically, lazy loading results in a small improvement for small >> articles and no improvement for large articles. Given the extra maintenance >> required (we have to keep maintaining virtually all of the lazy loading code >> for this specific use even if we don't use it elsewhere), and the frequent >> bugs that arise, I would still favor removing this feature. >> >> Ryan Kaldari > > > > > -- > Maryana Pinchuk > Product Manager, Wikimedia Foundation > wikimediafoundation.org

2 2

Android references bug - please reproduce!
by Dmitry Brant 28 Jul '14

28 Jul '14

We've been receiving a number of crash reports related to clicking on reference links in certain pages. [1] Unfortunately I haven't been able to reproduce the error, even when browsing the very same page as implied in the crash report. The only clue so far is that the issue seems to be restricted to Japanese pages. Would anyone with access to an Android device please try to reproduce this? Here are a couple pages mentioned in the crash reports: Try clicking reference #4 in this page: https://ja.wikipedia.org/wiki/%E6%A1%83%E8%8F%AF%E6%9C%88%E6%86%9A ...and reference #3 in this page: https://ja.wikipedia.org/wiki/%E3%83%90%E3%83%88%E3%83%BC Let us know if you get a crash from any of the above! -Dmitry [1] https://bugzilla.wikimedia.org/show_bug.cgi?id=68656

2 1

Summary on First Fold Styling
by Vibha Bamba 26 Jul '14

26 Jul '14

Some articles have beautiful images (See Picasso’s Rose Period) but take up an entire screen which delays the user from getting to the lead section. We will attempt to create a stable content areas for illustrative images that are critical to understanding the article while ensuring that the lead section is visible on first fold. Since both landscape and portrait images have to be examined, the team will take a stab at conserving vertical real estate by either cropping an image or horizontally stacking relevant images to create a collage of illustrative content. Click behaviors will ultimately be fairly close and consistent with media viewer. At this stage the key objective is getting users to the lead section and the info box. The objective of this exercise is to make better use of the space available on small devices. While users can flick and layouts can be adapted on desktop and tablets, mobile screens are small, hence choreographing a user's attention is important. ---- Vibha Bamba Senior Designer | WMF Design

1 0

[Apps] Suggested work for the Wikimania sprint
by Dan Garry 25 Jul '14

25 Jul '14

Hi everyone, The Wikimania Hackathon is coming up, and there's unstructured time after that. So you may be looking for things to do to help the team get ahead on its goals. Or, perhaps you've run out of story points in this sprint and you want to get a head start! Sprint 38 currently has a number of stories with agreed designs that have already been estimated. If you're looking for some features to get started on, that's the place to look! For iOS, there's lots of miscellaneous stories that were punted from the current sprint. For Android, there's the release management stuff and analytics dashboards stuff. :-) Dan -- Dan Garry Associate Product Manager for Platform and Mobile Apps Wikimedia Foundation

2 1

Android night mode
by Pine W 25 Jul '14

25 Jul '14

Thanks for implementing this. Glad to see progress continuing in Mobile. Pine

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

Mobile-l July 2014