By Dr Paddy Byers
Following on from their comments, this blog explores the idea of .mobi in a mobile Ajax world
First, it is assumed that there is a clear divide between mobile sites and non-mobile sites; there isn’t. I have a mobile web browser on my PDA that fully supports DOM-compatible scripting and XMLHttpRequest – but I only have a small screen and only key navigation. And I’d like to be able to navigate sites one-handed if possible. Full desktop sites don’t work well for the obvious reasons – they have large images, they don’t fit well on the screen, they rely on mouseovers, etc – but plain mobile XHTML sites that are AJAX-free also don’t get the best from the platform. Ironically they are less mobile-friendly because they require full page downloads for simple interaction rather than the kind of thing we can do with AJAX. So, ideally I’d like the site to figure out what browser features I have (some mobile-like, some desktop-like) and give me the best experience. I can’t do this now – perhaps the w3c device independence activity will give us what’s needed – but in any event it’s absolutely wrong for those characteristics to be embedded in the domain name.
Note: The UAProf doesn’t indicate what scripting capability the browser has, and whether or not the browser supports AJAX. The issue is that AJAX(and other new web technologies) are not formally standardised from a UAProf perspective and in practice site authors need to code to take account of the specific characteristics of each browser. If the phone has a browser that isn’t recognised, the UAProf doesn’t give sufficient information for the site author to know how to target it most effectively.
Second, the clear trend in AJAX app construction is to migrate to fully symbolic URIs that represent elements of the application’s state. As well as using symbolic URIs to represent some internal state (and then using REST to manipulate that state), these symbolic URIs become the top-level URL for the site at any given time. There’s a good example of how this works in Christian Gross’ book where he gives the example of an airline booking application. For a given booking there’s a URI that references that booking which is representation-independent (ie doesn’t encode any particular view of the booking), lifecycle-independent (ie is valid for that booking at all states of its lifecycle) and is session-independent (ie there is no state that the application relies on in a session cookie or any other browser state). What’s more, the reference is fully device-independent in that the same reference could be entered into a phone browser and it would then take you to the booking application in whatever markup system is relevant to that phone’s browser. In principle, it’s possible to manipulate the same booking from multiple browsers simultaneously, including from the mobile domain.
.mobi, by contrast, foresees islands where these domains do not mix; at least, they don’t mix a the level of the URI. That’s just not where AJAX and mobile web services are going. What’s more, the mobile web apps that are most likely to be successful and make money are precisely the ones that successfully achieve this data convergence.
So where does that leave .mobi?