Handheld CSS variants

For MediaWiki 1.14 I’m doing some refactoring of the CSS configuration to simplify some of the ugly and dupe code and to make things like adding handheld-friendly stylesheets easier…

An older experimental handheld CSS for MonoBook got trashed some time ago after complaints from some Opera folks that it just didn’t seem to work properly… so to experiment with this anew, I’ve added a site config option. By setting $wgHandheldStyle, you can now specify a custom style to use for browsers that think they’re “handheld” media. (These would normally exclude the regular stylesheet anyway, which is listed for “screen” user-agents.)

I’ve currently got it set on Wikipedia to specify the “Chick” style sheet, which is just an extra style variant on the MonoBook HTML, so fits rather conveniently.

Some bits of the HTML output for the curious:

<link rel=”stylesheet” href=”/skins-1.5/monobook/main.css?164″ type=”text/css” media=”screen” />
<link rel=”stylesheet” href=”/skins-1.5/chick/main.css?164″ type=”text/css” media=”handheld” />

You can preview it on-screen by adding &handheld=yes on the URL, just like &printable=yes for the print stylesheet.

I’m still a bit unclear on what devices actually support the ‘handheld’ media type, but I’m pushing for adoption of it with some device makers. :) Note that the iPhone/iPod Touch doesn’t grok ‘handheld’, probably quite deliberately since they want it to understand real ‘screen’ styles most of the time. You can make the iPhone (and Opera Mini in its new, fancier default view mode) use the handheld style by setting $wgHandheldForIPhone to true, which transforms the media types to use CSS3 media type queries on the screen size.

It’s a little funky-looking, but theoretically totally backwards-compatible. :)

Currently I’m not using this option live as the Chick style is still pretty awkward, and there’s no good way to disable the ‘only screen and (max-device-width: 480px)’ stylesheet if you don’t like it (well, other than adding UI and cookie crap).

So you can play with the handheld style on… Opera in “small screen” mode, Opera Mini in “mobile view”, and… anything else that you’ve found that I haven’t. ;)

OSCON reports: Open Mobile Exchange

Been here in Portland for a couple days for the start of OSCON, but still recovering from Egypt time… :D Some notes on the Open Mobile Exchange sessions…

A lot of the sessions told the same sad story. To make a long (sad) story short:

The good news:

Highly-capable “real web” browsers are here and becoming more widespread. WebKit, Gecko, and Opera-based browsers are shipping now on various devices or available for installation, and the Mozilla folks are working on a next-generation Gecko-based mobile browser.

Making the “mobile web” actually able to reach the real web is a huuuuuge boon:

  • People can reach sites that haven’t been optimized for mobile access (eg, 99.99999% of the web)
  • Mobile-targeted versions of sites can actually look good and be useful
  • Developers finally have a chance in hell of testing their mobile-targeted sites — the desktop versions of the browsers provide many of the same capabilities as the mobile ones, so you can preview faster and more reliably during iterative development.

The bad news:

Oh, where to begin! First, the bubble-burster:

  • Phones with good browsers are expensive! To reach those oft-touted billions who will own a mobile phone before setting eyes on a computer, we’re going to need the browsers in the $20 commodity phones, not just the $500 luxury smartphones.
  • Phones with good browsers are a tiny, tiny, tiny percentage of those out there today — even a tiny percentage of those shipping now.
  • To wit, for many years we’re going to see a lot of phones with no or crappy browsers.

Now, we can hope that Moore’s Law For Phones will push all the cool stuff into the commodity devices Real Soon Now, but I didn’t see anybody showing me evidence that it’s actually happening. Even the Symbian guys, who boast their OS runs “90% of the world’s smartphones”, realize they have only a tiny share of the total phone market.

We’ll consider this a “growth opportunity”. :)

The second challenge is that web apps today, while very capable with AJAXy stuff, have several major limitations:

  • No access to native device capabilities (camera, GPS, telephony)
  • No consistent system for offline functioning and data storage — you lose access to the world when your train goes in a tunnel or you get on a plane
  • Performance problems due to running JavaScript on top of HTML on a relatively slow, limited CPU

You can get around these limitations by writing native applications, but Here There Be Dragons.

  • Huge array of incompatible OSs, with
  • incompatible development models, and
  • incompatible application delivery formats

The “Linux mobile” people like the LiMo foundation are putting effort into standardizing some of the base software which should help with that, but honestly even us Penguin lovers hate that it’s virtually impossible to build a distro-independant package for the desktop and server Linux worlds. Do we really expect it’s going to be different for mobile Linux?

Even if that was solved, you still have to produce your Windows Mobile, iPhone, Android, and Java FX Mobile 2ME P2P WTF versions just for starters.

It seems to be everyone’s hope that native apps will “fade away” in importance as web apps become more capable.

But this is going to depend on the various browser makers and device makers agreeing on some things:

  • Sensible offline code & data storage. There’s motion on this with things like Gears and HTML 5 work, so I’m optimistic here.
  • Creating, then hopefully standardizing interfaces between web and native capabilities. This feels like a coming browser war… worst case is we can hope that JS libraries will abstract away the competing interfaces. Sigh.

So in the meantime, we’ll all make our pretty little web apps, churn out the occasional iPhone or Android or Mobile Linux app to use geolocation data or the camera or work offline, and wait for things to get better.

Oregon Trail

Ah, back in the U S of A… Will be here in Portland, Oregon for a few days for OSCON, now sitting in on the Open Mobile Exchange sessions.

What a difference a day makes

There couldn’t be any greater contrast between Cairo and Portland. The trees are green, the streets are wide and clean, the people are polite, and the cars aren’t trying to run me over. I even figured out the light rail system and got to my hotel for $2.05. Yay!

Will follow up more on Wikimania when I’ve had a chance to decompress and finish spooling out my notes.

Code slush for MediaWiki 1.13

I’m declaring a “code slush” on MediaWiki trunk for the next week or so, so we can concentrate on cleaning things up for making a 1.13 release branch, timed oh-so-delicately to approximately coincide with the Wikimania conference (coming up July 17-19).

I’d like to ask that new experimental features and giant refactorings that aren’t vital fixes be pushed back until after the branching; this’ll give us all a chance to make sure the release goes smoothly and that changes that are made get the attention they deserve.

It’s a-gonna be awesome! :D

Mobile format tweak

The HAWHAW library used for our Hawpedia-based mobile gateway does this cute thing where on a “grown-up” web browser it squishes the formatted output into a tiny rectangle, with a cute picture of a mobile phone around it.

This “simulator” mode makes it … sort of… look like an actual mobile device. But IMHO this causes more harm than good. Two main problems:

  • Unrecognized devices can end up being shown the simulator skin, often horribly misrendering it (like the Palm Treo at right — hopefully recognized since a few weeks ago)
  • It’s harder to actually get a feel for the variety of behavior on devices with different screen sizes. There’s everything out there from the tiniest cell phone to the iPhone to the Amazon Kindle reader’s big ol’ 6″ screen. There’s no way to resize the tiny rectangle, so you can’t estimate how things are going to feel on the medium screens.

I’ve now disabled this. With the simulator / “big screen” mode off, regular web browsers and unrecognized devices get pretty much the same output style that you see in things like the iPhone. It’s reasonably clean, and will properly scale and wrap with your screen size.

Conference season begins

Velocity
June 23-24 – Burlingame, California

Domas Mituzas, slayer of slow database queries and WMF board member, will be giving a talk on Wikimedia’s operations. Since we’re having a staff meeting here in San Francisco around the same time, the whole tech team will be out for the conference; come ’round and say hi!



Wikimania
July 17-19 – Alexandria, Egypt

Awwwww yeah



OSCON
July 21-25 – Portland, Oregon

I’ll be taking a detour through scenic Portland on my way back from Egypt to hit OSCON; I’m particularly interested in checking out the Open Mobile Exchange to get a sense of what’s going on in the mobile web & rich mobile app space.

Portland is the birthplace of Wiki, of course, so a pilgrimage is required. :) Hope to run into some wiki-friendly folks while I’m up there…

Wikipedia page size breakdown

Just for kicks, I cleared my cookies & caches and loaded up Wikipedia’s “Frog” article fresh to see what the breakdown of network bandwidth would look like…

645,947 bytes of data content are transferred, not counting any HTTP headers:

72.5% content images
10% JavaScript code
7.5% style sheets
5.5% HTML web page < the important stuff
4.5% UI images

This would take about 90 seconds to download on a 56kbit connection. It’s easy to forget what low-bandwidth feels like for those of us with broadband, but people outside cities may not have good broadband, and mobile devices are often stuck on pretty slow networks too. Compare regular Wikipedia against our mobile gateway on your mobile phone sometime; even a fancy browser like the iPhone’s will feel like molasses trying to load the full site, while loading things up lickety-split from the more minimal mobile gateway.

Fairly simple compression improvements could save 128kb of that:

  • 64k by gzipping JS and CSS files that are currently served uncompressed
  • another 64k through smarter compression of thumbnails (animated GIF optimization, use of JPEG for some PNG thumbs)

That would save approximately 18 seconds of download time for our hypothetical low-bandwidth user.

Details at mw:Wikipedia_data_size_test