Remember the bad old days? When Netscape, Opera, Internet Explorer 5, Mozilla et al caused constant headaches and wrangling over how the same site was going to be delivered to such a vast array of browsers and still look and function consistently? We cried, we wailed, we shook our fists at the devils for making it so bloody complicated. There’s only ONE specification you morons, why don’t you all follow it?
How self-satisfied and smug we all felt when enterprising souls like the Web Standards Project constantly campaigned for consistency, and the devils listened.
While the headaches of cross browser compatibility will never go away (software manufacturers will always have their whims) the playing field is so level at the moment that we’re pumping less and less into browser specific style sheets. In fact, we’re pumping less and less into style sheets full stop: in our recently launched site for the Royal Armouries for instance, we’ve only 390 lines in the core style sheet (including nice formatting, comments and line-spaces) and most satisfyingly, less than 39 lines of browser specific styles (in conditionally commented out style sheets).
Where am I going with all this?
Mobile development, that’s where.
Since we began working with mobile, there’s no doubt that the most frustrating, troublesome, and damn irritating aspect is that we’re designing for not seven or eight, but seven or eight thousand handsets all running their own quirkily tweaked version of a web-browser.
Let that sink in for a second.
As I’ve posted about before, some handsets (or some groups of handsets) exhibit the most peculiar behaviour, and dealing with that is hard enough, but when you combine it with font-size (and font-family for that matter) issues, enforced (or ignored) spacing and padding issues – I’m not even going to start with list-styling – and oh so many more bugs/issues … you’ve got what can only be described as a right, royal pain in the arse.
The two most common methods used for targeting browsers on the web is CSS hacks and/or conditionally commented style-sheets. These ancient and well-honed techniques serve us well, and have pretty much solved all issues we have with browser compatibility. Given that a fair chunk of mobile handsets don’t even understand style-sheets, and that many treat markup with a disdain normally reserved for estate-agents and traffic-wardens, and I’m afraid one has to conclude that things aren’t quite that simple.
The solution of choice for most development teams is the incredibly old school – but, like many old ideas, incredibly reliable – concept of user-agent detection. Every handset, like every web-browser, sends (in it’s HTTP header) a user-agent string, identifying itself uniquely. For example:
SonyEricssonK850i/R1CA Browser/NetFront/3.4 Profile/MIDP-2.1 Configuration/CLDC-1.1
If you went to the trouble of logging every possible user-agent, and listing that phone’s specific properties (supports xHTML/honours background colours set in CSS/etc) then you’d have something very useful.
Like all useful (and profitable) things, there are plenty of places that offer this service already, and for the Directgov mobile service (visit mobile.direct.gov.uk on your mobile phone to see it for yourself) we use an external web-service that provides us with all the details we need to redirect browsers to the correct version of the site (Techie note: one XML content source is powering several versions of the site via XSL transformations).
Of course, like any mission critical service, there’s a cost associated with accessing this data, but for those of you that don’t need the five nines (99.999%) uptime that comes with hosting the government’s mobile information portal, there a great new (beta) service that launched this week providing mobile handset detection for free. The self-explanatorily named folks at Handset Detection offer a web-service that returns a comprehensive list of parameters for any given user-agent, that you can use to filter content served to your visitors. It’s powered (primarily) by the fabulous open source project WURFL (Wireless Universal Resource File) a database of configuration details for every mobile device on the planet*.
Getting the information is the easy bit though, the tricky part is making your application smart enough to do something with it….
* In reality, it’s more like 90% accurate, but that’s pretty good for a database that big.
So far 2 people have argued with us about ‘The mobile minefield: Handset detection’. Read what they've said and then add to our woes using the form below.
Love what we’ve said? Think we’re talking nonsense? Don’t worry about being polite, just let us have it. We’re not afraid of telling you that you’re talking crap, so don’t be afraid of telling us the same.
Whilst developers have always struggled for client compliancy with hacks, surely there is a service like WURFL for web browsers which can provide a css parsing service based on the header returned by the browser? .Net has a component which does something like this but you have to tell it what to do in each instance.
I’ve heard about the Browser Capabilities Component of ASP, but I’d always thought it was a lot more intelligent than that.
As far as I know, there’s no comparable database to WURFL for regular web-browsers in the public domain, probably because you can use javascript or server side code to determine the most important capabilities of most major browsers - but that’s not to say it wouldn’t be useful.
The problems one faces developing for mobile handsets are generally massively fundamental, such as handset x plainly refusing to display a form element or honour colours, and as such it makes sense to build a discreet set of display/markup options for certain sub-sets of handsets.
I’ve heard of developers creating components that parse compliant CSS to add in hacks and workarounds for common issues (such as IE<6’s improper implementation of the box model) but I’m not sure that browser-detection and redirection/re-formatting is something that would be a progressive move in web-development.
That said, I think that in the not too distant future we’re going to be seeing a lot more detection going on for conventional web-sites so that users of what I can only assume is going to become an even more varied set of devices accessing the web (such as the new Asus Eee range of PCs) will see the appropriate version of a site without having to visit specialist URLs. Google, Facebook, YouTube and as I recently discovered, Amazon are all doing this already - it’s essential with them being service driven sites - but more and more it’s going to make sense to look at the way all sites are served up to users.