Mobile Web

As Anil points out, there’s a bunch of interesting stuff coming down the road for web development. I always skew these things somewhat however. I’m apparently a “non-standard platform user”, so I don’t really get all the excited about new and exciting things until I see them actually working on my preferred systems. I use Linux and I use mobile devices. They’re certainly not majority stakeholders yet if you look at your server logs today, but in general the numbers tend to be moving up for both. The last few months have been a rollercoaster ride, especially from the mobile end. There was a lot going on that I thought signalled great things for the interface between the general web and the mobile web. First and foremost is AJAX.

When I first heard about the use of AJAX for websites I was happy. I thought to myself, “Nice. Monolithic site designs based around layout for desktop systems tend to suck when you try to view them on mobiles. If the website interface is decomposed into smaller structured requests mixed together in the client browser then it should provide an opportunity for creating a mobile version that just mixes that data together in a different way.” I was thinking the effect would be something like a web service opening up an API in general. The information locked in HTML pages could now be requested in bits, and every site that used AJAX would become almost “automatically” a provider of a rich API into it’s data. This hasn’t been the case however. I’m going to leave alone the part where somehow “and XML” turned into “and JSON“, cause I don’t want to start a fight about S-expressions. Ahh, another format to parse. If it weren’t for formats explosions and parser writing I would almost never get to use the stuff I learned during computer science classes, so of course JSON is good. The problem is that in order to get AJAX based applications to perform well they tend to be written to implementations and not specifications, and JSON is a symptom of that. That’s just the reality of writing applications, if they don’t work well they don’t get used. And writing an application which is both based in specification and works around problems with implementations tends to require more depth than the normal implementor has (or wants).

That’s a problem for us mobile folks really. We’re the underdogs so far, and we need to prove that this whole mobile thing is going to kick ass. No one’s going to take our word for it until we can show it to them, or they can discover it on their own. What really concerns me is that reading the seemingly well received and accurate list that Anil has for desktop web work and the scope document that the W3C has drafted for their mobile web working group it doesn’t seem like these lists were prepared by people from the same planet, let alone people working in the same technological area. The question should not be “how can we properly tell people how to make content for mobile devices?” That’s a loosing question right off the bat. It didn’t work with WAP, it ain’t gonna work now. What we need to be doing is figuring out how we can get mobile devices to interact with the same services that the desktop systems interact with. The mobile web is a living system, it’s evolving. The desktop web is also evolving, probably more rapidly than the mobile web because of the sheer volume there. The question is not how do we provide cut points of functionality and additional restrictions and guidelines for usage. The question is how do we get the both of them to evolve in the same direction so that at some point there is no difference? That’s the real endgame. Not cross-compatability, but the elimination of the need for there to be a crossover at all. And that requires a longer term view. Aiming at the target as it exists today only ensures that it will have moved by the time you complete the task. This will not work.