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