Hi, there is a list of proposed URLs for testing mobile browsers:
http://meta.wikimedia.org/wiki/Mobile_Projects/Browsers_support_status#URLs_...
As you can see, the focus is put on interoperability. Localization and scripts are left aside because they have their own QA table at http://meta.wikimedia.org/wiki/Mobile_Projects/Language_support
Any opinions?
-- Quim
On Tue, Apr 12, 2011 at 3:54 PM, Quim Gil quim.gil@nokia.com wrote:
Hi, there is a list of proposed URLs for testing mobile browsers:
http://meta.wikimedia.org/wiki/Mobile_Projects/Browsers_support_status#URLs_...
As you can see, the focus is put on interoperability.
A good start! Couple quick notes:
- since we don't serve SVG images directly in pages, the SVG page test can be deferred (we send rasterized PNGs to all browsers; if we start sending some images as raw SVG, then testing will need to be started for compatibility)
- video and audio will probably work on very few mobile platforms for now
It looks like playback is actually _totally busted_ right now as we're passing through part of the markup for triggering the embedded players, but none of the player logic... so you get a thumbnail and a "Play" button that doesn't do anything. :(
If player logic gets added in, actual playback _should_ work on Android and Maemo/Meego, but probably not much else, due to limited support for Ogg Vorbis & Theora.
I'd probably also recommend organizing the test browsers into at least a couple tiers, maybe:
* Tier-1: iOS Safari, Android default browser * Tier-2: Blackberry, Opera Mobile, Opera Mini, Firefox Mobile (in most cases should work great, but it's not widely used) * Tier-3: everything else?
Tier 1 are the default browsers on the two most popular smartphone platforms, and make up the vast majority of mobile hits. Ideally, everything should work pretty consistently.
Tier 2 covers the most important ones that should still be pretty high quality: Blackberry is still popular; Opera Mobile and Mini cover a fair range of platforms and are popular on some; Firefox Mobile is available on Android and should usually work well for us without much manual work. Stuff should work, but we expect these to be minority usages.
Tier 3 would be the catch-all: nice to work, but some are going to be hard to test and some might not be well maintained.
-- brion
Thanks for the feedback!
http://meta.wikimedia.org/wiki/Mobile_Projects/Browsers_support_status#URLs_... edited: SVG use case removed and I added 'complex info box' and 'SMS gateway donation' use cases.
Anything else missing?
On Tue, 2011-04-12 at 16:56 -0700, ext Brion Vibber wrote:
- since we don't serve SVG images directly in pages, the SVG page test
can be deferred
True & done.
- video and audio will probably work on very few mobile platforms for
now
I know well :) but I think this is a way to let vendors know that there is indeed a need to support Vorbis and Theora, and point them to the devices that actually provide that support out of the box.
In some devices those codecs won't be supported out of the box but maybe there is an app or a procedure to get them running that we can link to from that page.
It looks like playback is actually _totally busted_ right now as we're passing through part of the markup for triggering the embedded players, but none of the player logic... so you get a thumbnail and a "Play" button that doesn't do anything. :(
In fact in the device I'm using I don't even see a 'play' icon but an "?". I didn't do any serious testing but I found the player "behavior" inconsistent in different pages. Anyway, defining the use case will help us highlighting the problems, also in the server side.
If player logic gets added in, actual playback _should_ work on Android and Maemo/Meego, but probably not much else, due to limited support for Ogg Vorbis & Theora.
There are third party apps for iOS and Symbian that claim Ogg support and apparently they work. The user still has the option to click on the link to the original file page, and download the full file. Not nice but at least possible, for starters.
I'd probably also recommend organizing the test browsers into at least a couple tiers, maybe:
- Tier-1: iOS Safari, Android default browser
- Tier-2: Blackberry, Opera Mobile, Opera Mini, Firefox Mobile (in
most cases should work great, but it's not widely used)
- Tier-3: everything else?
Instead of reminding that you are missing the Symbian ;) I will suggest a different approach: let's try to put the "boring" work in the shoulders of the mobile vendors. Wikipedia is a top site, and they test their browsers against top sites. If there are problems with Wikipedia browsing they want to know, preferably while developing the trunk version, months before that code gets pre-installed in millions of devices.
The good news is that a big bunch of those browsers have their official maintainers, testers and product managers sitting somewhere in San Francisco Bay Area, few miles away from the MWF headquarters: Apple, Google, Nokia, Palm & Mozilla. Opera and the Samsung Bada team have also offices here, and Microsoft has anyway a good connection with the WMF. Not sure about Blackberry, but if we get a mild success with the mentioned players it should be simple to arrange a mildly successful meeting with them.
A few successful visits can save you a lot of community testing, since those teams have a bunch of URLs they test regularly and everybody know that mobile users love Wikipedia. The community involvement is of course welcome, but hopefully mobile browser will "just work" soon, and we can concentrate all that feedback and help in our own apps, doing something more than browsing. Following your Tier approach, I hope to have 1 & 2 covered basically by the good QA practices of those teams, with good marking and collaboration with the owners of those devices in the Wikimedia community. The rest can be based on demand & problems found, just like Wikipedia works. :)
-- Quim