Mobile-l May 2014

mobile-l@lists.wikimedia.org

39 participants
53 discussions

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

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

QQQuestion
by Monte Hurd 31 May '14

31 May '14

Is there a standard way to indicate in a qqq file that a particular translation should try to be as few characters as possible?

3 2

Fwd: [Wikimedia-l] Mobile Operator IP Drift Tracking and Remediation
by Adam Baso 30 May '14

30 May '14

FYI ---------- Forwarded message ---------- From: Adam Baso <abaso(a)wikimedia.org> Date: Fri, May 30, 2014 at 2:04 PM Subject: Re: [Wikimedia-l] Mobile Operator IP Drift Tracking and Remediation To: Wikimedia Mailing List <wikimedia-l(a)lists.wikimedia.org> Okay, the code is in place in the alphas of both the Android and iOS apps, and the server-side 2% sampling (extra header in HTTPS request sent once per cellular app session) is working. https://git.wikimedia.org/commitdiff/apps%2Fandroid%2Fwikipedia.git/8b4a0c3… https://git.wikimedia.org/commitdiff/apps%2Fios%2Fwikipedia.git/59cde497921… https://git.wikimedia.org/commitdiff/mediawiki%2Fextensions%2FZeroRatedMobi… Changes to event logging in the iOS alpha app (internal only at the moment, although repo can be cloned and run in the Xcode simulator) are coming pretty soon, and once those are in, we'll make one last tweak there to have the app not add the extra MCC/MNC header on that single request per cellular connection when logging is turned off in the iOS alpha app. That part is done in the Android app already. -Adam On Fri, May 2, 2014 at 1:16 PM, Adam Baso <abaso(a)wikimedia.org> wrote: > Federico asked if sampling might make sense here. I think it will work, so > I've updated the patchset. > > From a patchset comment I provided: > > "It's possible we may have situations where operators have not lots of > users on them accessing Wiki(m|p)edia properties, so we do run some risk of > actually missing IPs, even if exit IPs are concentrators of typically large > sets of users. That said, let's try a 2% sample ratio; and if we find out > it's insufficient, then we'll sample more, if it's oversampling, then we > can adjust the other way, too. New patchset arriving shortly." > > (I've since submitted the updated code for review.) > > -Adam > > > > On Thu, May 1, 2014 at 7:52 PM, Adam Baso <abaso(a)wikimedia.org> wrote: > >> After examining this, it looks like EventLogging is more suited to the >> logging task than debug logging and the trappings of needing to alter debug >> logging in the core MediaWiki software. >> >> EventLogging logs at the resolution of a second (instead of a day), but >> has inbuilt support for record removal after 90 days. >> >> Please do let us know in case of further questions. Here's the logging >> schema for those with an interest: >> >> https://meta.wikimedia.org/wiki/Schema:MobileOperatorCode >> >> Here's the relevant server code: >> >> https://gerrit.wikimedia.org/r/#/c/130991/ >> >> -Adam >> >> >> >> >> On Wed, Apr 16, 2014 at 2:20 PM, Adam Baso <abaso(a)wikimedia.org> wrote: >> >>> Great idea! >>> >>> Anyone on the list know if there's a way to make the debug log >>> facilities do the YYYYMMDD timestamp instead of the longer one? >>> >>> If not, I suppose we could work to update the core MediaWiki code. [1] >>> >>> -Adam >>> >>> 1. For those with PHP skills or equivalent, I'm referring to >>> https://git.wikimedia.org/blob/mediawiki%2Fcore.git/a26687e81532def3faba646…. >>> Scroll to the bottom of the function definition to see the datetimestamp >>> approach. >>> >>> >>> On Wed, Apr 16, 2014 at 12:47 PM, Andrew Gray <andrew.gray(a)dunelm.org.uk >>> > wrote: >>> >>>> Hi Adam, >>>> >>>> One thought: you don't really need the date/time data at any detailed >>>> resolution, do you? If what you're wanting it for is to track major >>>> changes ("last month it all switched to this IP") and to purge old >>>> data ("delete anything older than 10 March"), you could simply log day >>>> rather than datetime. >>>> >>>> enwiki / 127.0.0.1 / 123.45 / 2014-04-16:1245.45 >>>> >>>> enwiki / 127.0.0.1 / 123.45 / 2014-04-16 >>>> >>>> - the latter gives you the data you need while making it a lot harder >>>> to do any kind of close user-identification. >>>> >>>> Andrew. >>>> On 16 Apr 2014 19:17, "Adam Baso" <abaso(a)wikimedia.org> wrote: >>>> >>>> > Inline. >>>> > >>>> > Thanks for starting this thread. >>>> > > >>>> > > Sorry if I've overlooked this, but who/what will have access to this >>>> > data? >>>> > > Only members of the mobile team? Local project CheckUsers? Wikimedia >>>> > > Foundation-approved researchers? Wikimedia shell users? AbuseFilter >>>> > > filters? >>>> > > >>>> > >>>> > It's a good question. The thought is to put it in the customary >>>> wfDebugLog >>>> > location (with, for example, filename "mccmnc.log") on fluorine. >>>> > >>>> > It just occurred to me that the wiki name (e.g., "enwiki"), but not >>>> the >>>> > full URL, gets logged additionally as part of the wfDebugLog call; to >>>> make >>>> > the implicit explicit, wfDebugLog adds a datetime stamp as well, and >>>> that's >>>> > useful for purging old records. I'll forward this email to mobile-l >>>> and >>>> > wikitech-l to underscore this. >>>> > >>>> > >>>> > > And this may be a silly question, but is there a reasonable means of >>>> > > approximating how identifying these two data points alone are? That >>>> is, >>>> > > Using a mobile country code and exit IP address, is it possible to >>>> > > identify a particular editor or reader? Or perhaps rephrased, is >>>> this >>>> > data >>>> > > considered anonymized? >>>> > > >>>> > >>>> > Not a silly question. My approximation is these tuples (datetime, now >>>> that >>>> > it hit me - XYwiki, exit IP, and MCC-MNC) alone, although not >>>> perfectly >>>> > anonymized, are low identifying (that is, indirect inferences on the >>>> data >>>> > in isolation are unlikely, but technically possible, through >>>> examination of >>>> > short tail outliers in a cluster analysis where such readers/editors >>>> exist >>>> > in the short tail outliers sets), in contrast to regular web access >>>> logs >>>> > (where direct inferences are easy). >>>> > >>>> > Thanks. I'll forward this along now. >>>> > >>>> > -Adam >>>> > _______________________________________________ >>>> > Wikimedia-l mailing list >>>> > 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 >>>> 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

New Android Alpha release
by Bernd Sitzmann 30 May '14

30 May '14

We have an updated alpha version of the Android app available on the Play Store. If you'd like to opt in to get automatic updates of the alpha version, please follow these instructions:http://lists.wikimedia.org/pipermail/mobile-l/2014-March/00664… What's new in this release: - Newer styles. Stop using OpenSans, switch back to default font. - Not showing the edit screen for pages that the user cannot edit anymore. Bernd

1 0

Mobile App Retrospective notes are up on the wiki
by Tomasz Finc 30 May '14

30 May '14

The Mobile App team had their monthly retrospective yesterday. Notes, further discussion, and action items are below. https://www.mediawiki.org/wiki/Wikimedia_Apps/imported/Retrospective-May_30… Extra thanks to Kaldari, Juliusz, Max, and others for their help with mobile web style re-use. = Further discussion items = * 80/20 Rule. Would like to think about behaviors for us instead of traditional patterns +1.++++ [Vibha] * Would be great to have automated builds ++ [Bernd - Android, Brion - iOS] * Need more ios testers! [monte] * Who 'target user' is++++ [Dan] * Continued/detailed testing with Android 2.3/3/4/etc? (+1 +1 +1)+ [Dmitry] * iOS market release unclear++++ [Dan] * Developer and Product standpoint on standard vs custom [Vibha] Thanks team and all involved. --tomasz

1 0

App Alphas - Wikipedia Zero Features Screencasts
by Adam Baso 29 May '14

29 May '14

Colleagues in UX are looking for opportunities to add final polish for Wikipedia Zero related stuff in the forthcoming apps, but here are screencasts for the Wikipedia Zero experience in the alphas of the apps. Android: https://drive.google.com/file/d/0BxJX28FKLm78bmcyOEtzVkUyYlU/edit?usp=shari… iOS: https://drive.google.com/file/d/0BxJX28FKLm78blZLX0UwRHNCSms/edit?usp=shari… The Android screencast is a little clunkier because I was using tethering and shooting from the same device to get things working and so had to string some videos together. iOS is a little less clunky because, although I also needed to use tethering, I was recording with a simulator. -Adam

1 0

Android app typography changes
by Moiz Syed 29 May '14

29 May '14

Just had a meeting with Yuvi and we decided that we should keep the fonts consistent on android app with android mobile web for the time being, and not introducing another font (Open Sans) in the mix. The changes will take a few minutes of work, and Yuvi has already made a card for it on trello. The changes include keeping page styling consistent with mobile web on android using Roboto for text and using Roboto for app chrome typography too.

5 7

Re: [WikimediaMobile] A card for Reference display?
by Tomasz Finc 28 May '14

28 May '14

Moving to mobile-l@ --tomasz On Wed, Apr 9, 2014 at 10:29 AM, Kenan Wang <kwang(a)wikimedia.org> wrote: > Is this necessary for MVP? I'm concerned about our ability to hit our dates > and scope creep. > > > On Wed, Apr 9, 2014 at 10:12 AM, May Tee-Galloway <mgalloway(a)wikimedia.org> > wrote: >> >> On the design side, since Kaity is working on reference-related projects, >> she'll be helping me iterate from what I've done here. >> >> >> On Wed, Apr 9, 2014 at 10:04 AM, Yuvi Panda <yuvipanda(a)wikimedia.org> >> wrote: >>> >>> I just looked over our cards for the next sprint and backlog and realized >>> we have nothing for handling how references are displayed. Kenan can you add >>> a card to the appropriate location? >> >> > > > > -- > > Kenan Wang > Product Manager, Mobile > Wikimedia Foundation

4 3

svg images in bad position on mobile view
by Aaron Schneider 28 May '14

28 May '14

Bug sent: Bug 65856 - Chess picture in mobile view not displayed properly https://bugzilla.wikimedia.org/show_bug.cgi?id=65856

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

Mobile-l May 2014