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
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
I'm adding mobile-l to this as I think it is a useful discussion.
The plan is to move the nearby code into the Geodata extension. To do this
however we must remove the dependency on MobileFrontend code which is not
an easy.
Check out the Mantle extension. This isn't final but it will give you an
idea of a potential plan of action. This patch [1] will also give you an
idea of how we could do this.
[1] https://gerrit.wikimedia.org/r/129480
On 27 Apr 2014 23:58, "Prateek Saxena" <psaxena(a)wikimedia.org> wrote:
> Should we consider moving Nearby out of MobileFrontend and into its
> own extension?
>
> -prtksxna
>
This is mostly for Jon and Ryan since they're likely to be working on
other parts of references in VE in future or at least reviewing
corresponding code. I've just asked James how to set up references on my
dev instance and it's a bit more complicated than I expected. This might
slow me down on the first references story a bit. I'm posting what I
know so far so that others can update their dev instances.
First of all, for the Cite menu to show up even in desktop VE you need
to create MediaWiki:Visualeditor-cite-tool-definition.json page with the
following content (default for enwiki):
[
{ "name": "web", "icon": "ref-cite-web", "template": "Cite web" },
{ "name": "book", "icon": "ref-cite-book", "template": "Cite book" },
{ "name": "news", "icon": "ref-cite-news", "template": "Cite news" },
{ "name": "journal", "icon": "ref-cite-journal", "template": "Cite
journal" }
]
Now you have the Cite menu in the toolbar in VE, but the dialogs don't
really let you do anything. You need to use Special:Export/Import to
import those templates (Template:Cite web, Template: Cite book, etc.)
into your local dev instance. Unfortunately, those templates require
Scribunto. If you don't have Scribunto installed in your local instance,
it might be a good moment to consider a move to mediawiki-vagrant (which
is what I probably will do).
It will probably take me at least a couple of days to come up with
something for code review, but the sooner you get this working, the better.
--
Juliusz
Some of the graphs [1] on the report card are not rendering due to
what seems like some sort of EventLogging outage
When I query the database I get errors such as ""MySQL said: Table
'MobileWebEditing_7675117' is marked as crashed and should be
repaired""
Let's keep an eye on this...
[1] http://mobile-reportcard.wmflabs.org/#edits_daily-graphs-tab
Moving to mobile-l.
This is to have a way to conduct a wider amount of testing on iOS than has
been currently possible.
---------- Forwarded message ----------
From: Monte Hurd <mhurd(a)wikimedia.org>
Date: Wed, Apr 16, 2014 at 12:27 AM
Subject: Can iOS app be released to a couple small localizations intially?
To: mobile-tech <mobile-tech(a)wikimedia.org>
As Tomasz pointed out, it may not be possible, but it's worth looking in to.
Thoughts?
of relevance to mobile. .
---------- Forwarded message ----------
From: "Ori Livneh" <ori(a)wikimedia.org>
Date: 29 Apr 2014 12:10
Subject: [Ops] Cookie guidelines for developers (was: Incident: Large 5xx
spike)
To: "Operations Engineers" <ops(a)lists.wikimedia.org>
Cc:
Without X-Vary-On, we don't have a generic mechanism for web developers to
specify how cookies should affect caching behavior. This is actually OK,
because the introduction of new cookies ought to be extremely rare. Cookies
can wreak havoc on cache hit rates; they're bad for performance; and they
raise complicated legal and moral questions. I therefore propose making it
a requirement for developers that wish to introduce cookies to seek
permission by e-mailing this list. If there aren't any objections, I'll add
this requirement to the deployment guidelines.
_______________________________________________
Ops mailing list
Ops(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/ops