I’ve been thinking a bunch about the mobile web in general (it’s the topic of the Mobile Monday meeting next week) and what I said a while ago about trying to merge the two currently distinct webs in particular. It was something that came up during Mashup Camp too. I don’t want better tools for people to make their content mobile with, I want better ways to work with content which automatically make it mobile. I want to run down quick what goes into that from the website developer side, folks who normally aren’t too into mobile but would I’m assuming like to support it if the cost wasn’t too high.
Details of what device the page is going back to has to be something that the developer can ignore. The default should be “it just works”. Most website developers have neither the time nor the desire to learn the nuances of the hundreds of devices out on the market. Also, the magic to make the website work on mobile devices can’t be something additional to do. It needs to be baked right into whatever the easiest/most common method of developing websites is.
So of course the question comes up of what exactly that magic is. I was starting to question if there had to be a single markup that goes directly to both desktop browser and mobile device. That could either be proxies between the device and the website (such as done by Skweezer or Google) or a single source generated in both desktop and mobile markup. The second option raises hackles right away cause that’s how WAP was supposed to work out. However I don’t want to count it completely out, given a different target markup maybe it could work. The proxy option doesn’t look too appealing either, with more and more websites relying on client side scripting and a dynamic document model.
A related question is if the HTML layer is really the right layer to target for compatibility anyway. The current techniques of website design apply a few “hacks” to get the browser to act not as an HTML renderer but as a scriptable application who’s widget set happens to be HTML and CSS description. So could we make life easier for the web folks by baking that behavior right into the next version of the spec (no more having to probe browser types to figure out how to get an xmlHttpRequest object, no more JSON to fake the browser into loading data from a third party) and at the same time making a “web application” something that a mobile device would find as executable as a browser does? I don’t know, but I’ve started thinking about it.
There’s also a question of how much coverage you could get with support for a couple of web services style APIs. With more standard support for RSS, the Atom publishing protocol, and OPML could somewhat generic mobile applications be built to allow access to the corresponding web applications? This would probably require some extra definitions of how the generic mobile app should interact with the specific site, and we have to assume that most people wouldn’t create those. But if the standard tools for creating web sites were driven off something that would be able to generate that automatically that would be a completely different issue.
So that’s the stuff I’ve been thinking about (and hacking around, hopefully I’ll be able to post some of the toys this week coming up), how can we make it so that people don’t have to “mobilize their service”. Everything starts out mobile and it takes effort to make it NOT work on a device.