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
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
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>
>>>>
>>>
>>>
>>
>
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
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
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
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.
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