Before we get in to mobile Ajax, it's probably worth reviewing the best practices for mobile web dev anyway. Mobile web is surprisingly close to web development in terms of technology; but the entire mobile experience is constrained by factors you just don't to worry about (as much) on the wired web.
Constraint one: teensy screens
My Nokia N70 has a maximum screen resolution of 176x208. The E65 I'm currently developing against is QVGA: 240x320 (yes, the smaller, horizontal, number comes first).
The fact that aspect ratio is portrait rather than landscape makes a lot of difference to the design of the page: you can't have a left hand nav, because there's no real estate on the left hand to put it in. When a vernacular three column web page is rendered on mobile the usual result is several screensful of top-nav, ads, left hand nav before you get to the content. The situation might be greatly improved if web developers put the content first in the document and decorated it with left nav etc using careful chosen floats. But they don't.
One approach that all mobile browser vendors try is to give you a virtual viewport that the page is rendered to. It's then up to the user to scroll around the screen and zoom in and out to get an overview. This is, to be frank, teh sux. You wouldn't want to watch a widescreen movie through a periscope; but most people are quite happy to watch the movie on a different aspect ratio when it's on TV. Movies were 16:9 and above and TVs 4:3 for years with no major conflict between creators and viewers; movie directors tended to stick stuff into the central safe area, and viewers learned that occasionally they'd just have to accept they could only see Clint Eastwood's nose. If web developers learned safe areas in the way that film and TV people did we would have less need for wholesale mobile repurposing.
Best practice one then is: design for the screen in hand and don't rely on the browsers rendering to stick all the information on screen.
Constraint two: fiddly nav
The Opera client on my N70 does a good job of dealing with links: by default the cursor jumps to only items on the page that are actionable. The S60 browser wants to be a computer and forces the user to use the four way joystick to mimic a mouse. Which means that some of the time you find yourself trying to get focus on a link that is about this size.
Best practice two then is BIG TARGETS. Actually that's a best practice for all interactive applications, web or mobile, but it's especially relevant for challenging environments like mobile. Most modern browsers react to onclick events on divs so why not make an entire div area active, with the a href included as a fallback for the minority who've actively turned javascript off?
Constraint three: awful networking stacks
The more I deal with the joy of TCP/IP over narrowband wireless the more I come to the conclusion that actually the wapforum guys were on to something. TCP/IP doesn't like dealing with laggy networks: it falls back into a conservative mode where it sends lots of little packets and acts suspicious without lots of confirming ACKs.
The upshot of all this is that loading a web page over wireless can take an awful lot longer than you'd think. The HTTP overhead can add 10 seconds or more to a simple request. The slightly counterintuitive result of this is that it matters less how big your images are, and more how many there are. A 400 byte piece of page furniture will load as quickly as a 3k equivalent, because the payload of the request actually executes quite quickly. It's the set-up and tear-down phases of the request that add time. 3G is particularly prone to this problem, which explains why "blistering 3G speeds" aren't.
Unfortunately, most mobile operators are run by engineers whose prime directive is to minimise network throughput, so mobile proxies tend to crush images into low quality JPEGs. This does sweet eff all for loading times, but gets them a gold medal for having "done something to enable the mobile internet".
So, best practice three is: no more than three or four images on a page. And make 'em big. (Tip: if you make an image bigger than it needs to be (say 320x480) and then scale it to the width of the screen you can ameliorate the effects of mobile proxies because the compression artefacts will be less visible. Not very nice for the user though.)
Constraint four: fragmentation everywhere
In mobile, no-one can agree on anything. Largely because they don't have to.
You're tied to the network your operator runs, the proxies they choose, and the choice of browsers is usually one. So there's no real competition to make anything better.
Typical example: Opera only renders CSS for a page if the CSS is presented to it with a media="handheld" attribute and value. The S60 Browser, on the other hand (because it thinks it's a computer), ignores any CSS in a "handheld" block. The same CSS works more or less identically on both browsers, but you have to waste your time doubling up. Putting both in - media="handheld, screen" works okay, but actually you probably want to distinguish between things with real screens (desktops) and the S60 Browsers, so you now need to do some server-side work to get the right look on each device. Thanks Nokia.
I'll be trying to tabulate the fragmentations I know about in future posts. Hope the above helps.
No comments:
Post a Comment