I took a quick spin through Mobile Web Best Practices 1.0 today. Here are a few bits and pieces that caught my eye:
1.3.3 One Web
The recommendations in this document are intended to improve mobile experience of the Web on mobile devices. While the recommendations are not specifically addressed at the desktop browsing experience it must be understood that they are made in the context of wishing to work towards ‘One Web’.
As discussed in [Scope] One Web means making, as far as is reasonable, the same information and services available to users irrespective of the device they are using. However it does not mean that exactly the same information is available in exactly the same way across all devices. Some services and information are more suitable for and targeted at particular user contexts.
w00t!! Happy to see that explicitly in there. I still hear people talk a lot about there being different technologies for mobile and desktop delivery as if that’s just a fact of life that will never change. I don’t agree at all.
Developers of commercial web sites should note that different commercial models are often at work when the Web is accessed from Mobile devices as compared with desktop devices. For example, some mechanisms that are commonly used for presentation of advertising material do not work well on small devices and are therefore contrary to the Best Practice Recommendations.
It is not the intention of the MWI to limit or to restrict advertising; rather it is the intention that the user experience of the site as a whole, including advertising, if any, is as effective as possible.
Lots of talk about mobile advertising recently, I think this is going to be a hot area coming up. Hopefully someone solves it well without requiring everyone to sign over control of mobile advertising to some consolidated service. I would love to see a generic mechanism that provides for delivery, and a few networks serving it. I wouldn’t like to see carriers controlling inserting of ads into content using proprietary systems.
3.1 Adaptation Implementation Model
There is quite a wide spectrum of implementation models for content adaptation. On the one hand adaptation may be quite simple, and consist of determining the device type and choosing the most appropriate set of previously prepared content to match the device characteristics. At the other extreme it may be carried out in a completely dynamic way, with content formatted at the time of retrieval, taking into account not only statically determined properties, such as screen dimension, but also dynamically determined properties, such as the temporary attachment of a fully featured keyboard.
Slippery slope, device adaptation. It can lead to a kind of arms race, where site implementations over-assume the capability of a device and degrade the site mistakenly. So then the device manufacturer lies about the device in the request headers or identifiers to work around that mistake. Which the site implementors eventually have to work around to get back at the functionality being lied about. It doesn’t have to go this way, but so often it does.
I’m not saying that device adaption is a bad idea, but that implementation of those adaptations being in the hands of every implementor leads to a lot of burden on the site creator and lots of room for error. This is where server side tools that accept site descriptions at a higher level of semantic markup and map to concrete elements based on the inbound request could do a lot to help. Unfortunately those systems tend to be large, cumbersome, expensive setups themselves. Would be great if there was some good open source out there implementing those adaptations that everyone could pull from.