Minibrowser Thoughts
Okay, I've finally determined the best name for the integrated browser on modern mobile phones: a minibrowser. I saw it on a phone a week or so ago and it just made the most sense to me. WAP browser for WAP 1.x and "minibrowser" for XHTML-MP/WAP 2.0. This so much clearer and easier to say.
Let me spell out exactly what XHTML-MP is - it's a well-formed XML document (you have to close your tags) with support for only these elements: (From this helpful OpenWave overview): body, head, html, title, dfn, div, em, h1, h2, h3, h4, h5, h6, kbd, p, pre, q, samp, span, strong, var, a, dl,dt, dd, ol, ul, li, form, input, label, select, option, textarea, caption, table, td, th, tr, img, object, param, meta, link, base, (fieldset, optgroup, b, big, hr, i, small, style, start attribute on ol, value attribute on li, style attribute).
The markup is very straight forward and easy to grok quickly for anyone who's worked with HTML. The tags at the end in the parenthesis were added to XHTML-Basic for backwards compatibility with cHTML and also for embedded style support, which is important because of network latency. Basically when working with XHTML-MP, you just design to XHTML-Basic and then cheat every once in a while with a style tag or attribute. It makes it really simple to use. WML, by the way, is dead. Never to recover and XHTML-MP browsers, by result, have been branded WAP 2.0 browsers as well.
So... As I'm messing with XHTML-MP, I'm learning lots of things. First, there's little standardization among phone manufacturers right now for minibrowsers. And suprisingly most minibrowsers are *very* tolerant of non-perfect XML. They rarely check DTDs, almost never validate and like your PC browser, do their very best to parse and render whatever XHTML-MP or HTML markup you throw at them. Also, from what I've seen, WAP-CSS is supported, but only in a marginal way and the latency to download a linked-to CSS file means that the XHTML-MP sites I've seen include the style with each page, rather than have the style of the page "jump" because of the late-loading stylesheet.
I'm starting to generate some design theories as I develop pages as well, which can be summed up as: Long is good, links are bad.
The first part is somewhat controversial, as "long" means more data downloaded per page - which many mobile users are still pay for per KB - and some phones/networks have strict limitations on how large a page can be grabbed and rendered. But the fact is that latency on GPRS and CDMA 2000 1x networks is painful. It takes anywhere from 10 to 30 seconds to load a new page on a decent connection. Better to give users longer pages with more information so they they don't have to wait for their cellular network every time they view a new page.
The second part is related to network latency as well and is also based based on a mobile user use-case. For most PC-based websites, the links are at the top and the left, and when rendered on the phone, makes users have to scroll endlessly to get to their content. And many minibrowsers navigation is not very good, so you actually have to skip from link to link to move down the page, which could literally mean 40 button clicks to get to the meat of your data. The solution? A lot less links.
This is counter-intuitive for both Web developers and for old WAP developers. Much of the old WAP cards and pages was the menuing system. In fact, Vodafone Live! calls their WAP portal the Vodaphone Menu - because that's what WML was good for. But XHTML can express much more compelling content, but only if it doesn't piss off its users with slow loading data and unnavigable pages.
A great example of how *not* to design an XHTML-MP website is AT&T Wireless' mMode portal. It's *all* menus and lists of items on different pages. When you finally get to a site like CNN for content, they've cut up their pages as well into frustratingly short pieces. Those paying by the KB might definitely prefer this way of formatting pages as they won't have to pay for data they don't read, but in general if you design that way, no one will use the sites much because of how long links take to load.
I'm experimenting with this now, but I think that longer pages for those phones that support them, and judicious use of "menu" links and "#" anchors is the way to design for minibrowsers. Put all the links to the different menu items at the bottom of your page with a # anchor. At the top of the page is a single link to that anchor. This cleans up the pages considerably. Then don't be afraid to have long pages with different sections. Yes, initially the page will take longer to load, but now the user has more on their phone to read and interact with. Don't put just one game on one page, put 10 games. Don't put just links to news item titles, but include longish descriptions as well. Don't make the user hit the network unless they really have to.
And less links. LOTS less. No breadcrumb links, no long menus, no help, no "back" links, no "common" links like privacy policies, no "about" links, no search links. Put all of that stuff on a completely separate page linked to once with a link called "Menu" or "Home". Again, this goes against the whole idea of the web itself, but on a phone you almost always have to deal with links while navigating. They rarely "blend" like they do in normal web browsers - so unless you really need them, get rid of them.
That's the brain dump for now... your thoughts welcome.
-Russ