Getting to the Mobile Web
The post yesterday was actually just half a thought: The mobile web sucks right now. The second part of the thought is: why is that? I've been trying to think of all the reasons that there aren't more mobile web pages out there. You see I think most of the people in charge of websites agree that they should mobilize their offerings. They can easily think of reasons why people would want to have acess to their stuff, but they're not sure how to proceed because there's so many alternatives.
Let's look at the common practices about mobile web development:
The Parallel Mobile Universe: This is the first thing I think every site tries first. Mobile development is started just like regular web development: you check out an existing page out there and copy it until it works on the mobile phone that's sitting in your pocket. You give this version of your site an alternative mobile URL and think you'll maintain it in unison with the PC version. This never happens of course. Drill into Amazon.com's mobile site and you can see that the images are broken as just they've forgotten to bother updating the mobile version.
The cracks in this plan start to show up pretty quickly. Not only do you forget to maintain the separate web, but people start complaining rather quickly that the version you created for your mobile phone gives their mobile phone errors. After some swearing and denials, you finally "fix it", i.e. make the page have the absolute minimum possible formatting and functionality so it works on even the crappiest browsers (read: Motorola phones). And then you forget about it. I think most of the mobile sites I've seen fall into this category.
The Magical Server: But then there's the sites that are *serious* about the mobile web. They've got their data locked away in a database anyways, so reformatting for the mobile phone should be easy. It's just a matter of creating new templates for all the different phones out there. This should be straight forward, right? The mobile client hits the server with a bunch of headers about its capabilities, and your server - having a complete list of every phone ever created and all the functionalities and quirks - dynamically reformats the content on the fly for each type of mobile browser that hits it. You'll have one URL for every browser in the world and it'll "just work." Perfect!
Yep. This dream lasts such a short time, it's incredible. First, mobile clients lie. They pretend to be all sorts of things they aren't (like Netscape 4.0 compatible). They also have formatting quirks, odd page-size limitations and outright bugs. There are a pretty standard set of mobile browsers out there (Nokia, Motorola, Openwave, NetFront, etc.) but each phone is still a world unto itself. If you try to use something like WURFL, an XML database of various handsets, you'll soon discover that the list is incomplete at best, and Euro-centric at worst (where's all the CDMA phones?). Even with tons of development time and effort (remember you still have to massage the data and images for display on a phone) you only are able to support a percentage of the phones available, but even then the level of effort to get there is huge. There are also scalability issues: the most scalable sites are static. The more logic you have to process for each page request means you have to have more and more hardware and software resources on the back end as well. This excludes a lot of smaller sites and anyone else who isn't willing to put those resources into this right now.
This works, except for the fact that the percentages of phones with this sort of browser over the next five years is going to be tiny. In the U.S. right now, around 2% of the internet-capable phones out there are smart phones. Over the next five years, the percentage will rise signifcantly, but the majority of phones will continue to be non-smart for the forseeable future. If you want to limit the access of your site to only those users with smart phones and the patience to navigate your web-oriented site on their mobile phones, then you're all set. No need to do a thing. Or better yet, you can include a "handheld" CSS and just let the mobile browser figure it out.
I have to admit this is attractive to me as I've been using a Series 60 phone for two and half years now and mostly use Opera or Netfront to do my browsing. But honestly, if you were going to throw up a website which was supported by say advertising, then give it up. There just won't be enough of these browser out there any time soon. And you annoy every one else as well. How do you explain to your customers, "Our site is mobile, but only on a certain handset using a certain web browser." You can't. It's like going back to the bad old-days of IE-only web pages.
The Mythical Custom Client: Okay, so the whole web-standards thing is obviously broken completely and unrecoverably. Who says the system that works on the PC is the best solution for the mobile phone anyways? Hell, there's like 600 million Java phones out there right? So why don't we control the whole interface! Who needs all this bloated, non-standardized markup crap anyways, we can create a whole app in Java and just port it from phone to phone! There'll be no latency because we can download information "in the background" and the interface will be much more compelling because we can "control the UI and as an added bonus we'll create lock in for the user since we'll control all the access from the app!
Yeah, this doesn't work either. The list of Java handicaps are numerous. From flaky implementations, to the sandbox, to flaky network connections, to the horrible standard UI, memory limitations, etc. It's fine to implement Tetris, but if you want to create an alternative browser-style application you're dreaming. The "Mobile Java Portal" been tried before numerous times - do you use it on your phone yet? No. Why? Because they suck.
The Hopeful Alternative: Ahh, but we don't have to use Java! Flash will save us! No latency, background loading, nice graphics! That's the ticket! Or wait, SVG! Yes! Web standards *and* vector graphics all rolled into one! Hooray! Or wait, RSS! That's all we need just a custom RSS reader. No, no, wait. The carriers were right, all we need is MMS! Or hell, you can do everything you need to do in SMS! 160 Characters for everyone!
Yeah, you get the idea. Flash and SVG are far from ubiquitous (and will remain so), MMS is brain dead and though SMS is an incredible platform it's not the best medium for information retrieval.
The Mobile Web Solution: So what's the answer? Well, I don't know. I have some ideas, but they're all just theories right now. I do know that we've finally reached some level of XHTML standardization on the client side which is a good thing. It's not perfect, but it's a lot better than WML. I also know that expecting the web server to do everything magically not only cuts out all the independant developers and websites out there, but also most companies that can't justify mobile web access as an important cost-center just yet. But even if you had all the money in the world, it's impractical to think that you can keep a complete and up-to-date list of every mobile browser on the planet and dynamically format your content for each one. It's also impractical (from a business sense) to expect everyone to walk around with smart phones and advanced mobile browsers. The development effort for a custom client is too high, and alternative content formats like Flash won't reach critical mass for several years out.
So even though in my last post I was bitching about the lack of the mobile web, there seems to be real reasons that there isn't more effort in that area. I think most developers/companies are paralyzed by the choices in front of them, none which seem particularly great at the moment. Here's my initial thoughts on how to start, and honestly I'm not sure if this is right, just my gut feelings:
Web and mobile are going to be different worlds for the forseeable future, so we might as well embrace this fact. So what I'd do is make an alternative area for your mobile content right away, but do it with an eye towards maintainability and findability. Creating a new mobile template for db-oriented data is actually a good idea, but just one version and watch your content lengths, image sizes and external links. If your mobile site links to another site, it better be accessible via a mobile phone as well.
Actually the industry in general could use some standardization on this front. A pro user needs to know that they can get a mobile version of the site just by changing or adding to a URL. Websites start with "www." by convention, right? There's no reason for mobile sites not to start with "mobile." or have a sub directory like /mobile/. This stuff isn't for the super-newbies, who will most likely navigate to a URL via some other link, but it's for the thought leaders and experts who end up helping everyone else. Then if you think about it, if I want to link from my site's mobile version to your mobile site, all I have to do is change the URL in a predictable way and I'm all set.
Along these lines, I think auto-redirecting or other magic isn't a great idea because it breaks this whole idea of permanent URLs. Maybe on the front page you can give a choice like Yahoo does (go hit yahoo.com on your mobile and you'll get a prompt for the regular or mobile version), this may be a practical solution until people get used to the mobile web, but I don't like it - it doesn't help promote the mobile web as an entity to itself. (Though this end result of an alternative mobile web may not be a good idea, I'm not sure). In general, I think we all have to accept that a URI is a link to a *whole* page - design and content - not just the content itself. Sorry W3C, but thinking that a page's formatting and its content can be perfectly separated is a dream. The mobile web more times than not needs to alter the content of the page (again: text length, image sizes and external links at the bare minimum), and this isn't going to be done via CSS.
More thoughts: When designing for the mobile web, don't aim for the lowest or highest functionality. If you decide that you want as many mobile users as possible (who doesn't?), then the best you can do is aim for the 20% of the handsets that naturally represent 80% of the market. Be prepared to have a list of phones which work, and which don't work, and then publicize them. The goal is to make the mobile version of your website as easily maintainable as possible: Either the phone works, or doesn't work. If you stick to web standards, you can support a decent subset of phones now *with compelling content* and simply wait for the older buggy phones to get replaced. Making a different version of your site for each different mobile browser out there just is a rabit hole that will lead your site deeper and deeper into complexity and headaches. Yes, it's nice when a mobile browser hits a site and it "just works." But more times than not that doesn't happen anyways. Figure out the phones you want to support, and then give them a standard mobile version. Remember that mobile phones are changed out on average every 20 months. So even though the T610/T616 was super popular last year, I don't even think about it now.
So there you have it, stop waiting and go mobile! :-)