How user agents should have been

One major pain in the rear for web developers –especially mobile ones– is finding the capabilities of a device. For cellphones there is WURFL, however this solution has its own problems and it’s slow. For other types of devices, like desktop browsers, embedded systems ones or gaming devices, there is no way to detect what they can do and what they can’t. Here is how user agents should have been required to be:

A cellphone example (sorry for the bad formatting):
Nokia:Cellphone; java:MIDP-2.0; platform:Series40-3.01; model:7260; browser:UP.Browser-7.2.6; res:176×220; abilities:CSS-2,XHTML-MP-1,WML-1.3.1,HTML-4.01,ssl.js-1.1; media:svg,jpg,png,gif,mobile-flash-1.0; language:en; other:[up to 64 characters where the device can clarify more if required];

A desktop example:
Apple:PC; java:jre-5.0.4; browser:Firefox-2.01; model:Macintosh; platform:MacOSX-10.4.9; res:1024×768; abilities:CSS-2,XHTML-1,HTML-4.01,ssl,js-1.3; media:svg,jpg,png,gif,bmp,mid,wav; language:el; other:flash-9,quicktime-7;

An embedded example:
Nokia:Embedded; java:none; browser:Opera-9.0.2; model:770; platform:Linux-2.6.18.3,Maemo-2.2; res:800×480; abilities:CSS-3,XHTML-1,HTML-4.01,ssl,js-1.2; media:jpg,png,gif,mid,wav; language:fr; other:none;

There is no reason to actually require listing of external plugins (e.g. quicktime or flash), only what the browser itself can do by default. The above information is enough to get your content optimized for each reader, and it’s super important information for mobile web developers. Sure, you don’t get info if a specific attribute or CSS property is supported, but you get a good idea about how to layout or direct your content to.

On a related note, today we celebrate the first time in history where a Nintendo Wii Opera browser hit the mobile version OSNews. (update: oops, I meant the DS) :)

Post a comment »

KCorax wrote on August 19th, 2006 at 5:48 AM PST:

I’m in the web mining business myself, but our scripts generally trim down the info. Why would all this be usefull ? You can get quit a bit of info with a local js file and postback to your server. Most aware sites do this + a 1sec mandatory redirect in order to know more about the client.

However the resolution info is a bit useless especially for large display users who always keep their windows smaller (between 1024 and 800). Since you can get the actual window size with the js i mentioned you can do a postback and customize the user experience accordingly, then attach to the resize event and redraw with the next request etc etc


This is the admin speaking...
Eugenia wrote on August 19th, 2006 at 5:53 AM PST:

KCorax, for MOBILE and EMBEDDED web developement this info is paramount. The resolution info too. Between 120×120 and 240×320 it’s a world away. More than it is between 800×600 and 1600×1200. And JS only works with 5% of these kinds of browsers. So no, JS, CSS and XHTML is not the answer in the non-desktop world. Plain HTML (and WML) is. But in order to offer the best possible version (exactly because these are buggy and half-implemented browsers), the info I request to be in the user agent is very important in order to offer a consistent look and functionality.

No, this info is not too important for desktop browsers, but it is super-important for everything else.


Ludovic Hirlimann wrote on August 19th, 2006 at 6:09 AM PST:

Aren’t all those information provided in the HTTP Get command ?


This is the admin speaking...
Eugenia wrote on August 19th, 2006 at 6:57 AM PST:

Nope. Very little info you get with GET.


KCorax wrote on August 19th, 2006 at 7:27 AM PST:

Ok I get what you mean, but still the solution I proposed covers desktop clients. I see the need for the extenstions you suggest, still I think that they belong to some w3c specification not the http protocol itself.

Browsing with a pocket device is a dreadfull experience, and developing content for them is even more frustrating. I think that this won’t be solved with more specifications – Even if you had all this info what would you do ? Write an xslt to create a custom page for each client ?

Maybe a public petition with special full page mentions to blacklisted devices that have crippled browsing features, to help make the public more aware.


turn.self.off wrote on August 19th, 2006 at 7:34 AM PST:

sadly the user agent string is stuck in the stone ages.

even the latest ones id themself as a variant of the mosaic/netscape browser.

maybe you should mail some sort of suggestion to the w3c as i guess they would be the right group to regulate this.


This is the admin speaking...
Eugenia wrote on August 19th, 2006 at 7:45 AM PST:

Actually, you don’t need many different versions. For example, for the mobile version of osnews, I only need to make 3 checks for 3 different buggy mobile browsers and slightly modify some specific html tag. I do NOT need different versions of html. But in order to do these small checks, I need to be able to find out let’s say, if the Nokia S40 browser is from 2nd or 3rd Edition of the OS. My suggestion of the advanced user agent allows for this information to be extracted, while currently there is no way to know which version of the S40 browser you get hit from. And the 3rd Edition browser has a terrible bug when you have more than a pre-determined amount of text in a table cell…

Blacklisting browsers is not the way. For 95% of the code I use, all these mobile/embedded/text-mode browsers are all compatible. It’s that extra 5% mileage that I need to have more info in order to make sure that ALL my readers are getting a consistent experience.


Comments are closed as this blog post is now archived.

Lines, paragraphs break automatically. HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

The URI to TrackBack this blog entry is this. And here is the RSS 2.0 for comments on this post.