User Agent Accuracy Affects User Experience

In my last post, I developed a new definition of quality: a positive user experience. As with many of the other definitions of quality, this depends on context of user expectation. Users of poorly designed intranets, for example, will have a positive experience with minor improvements. Apple and Nokia have a higher standard to achieve.

One quality problem in the mobile industry notorious with developers is user agent strings that lie. A device might claim to handle a larger web page than it actually does, might claim to be a different device, might neglect to define certain values, and so forth. As a result, a web site causes the device to crash, an application that should work doesn't, images are the wrong size, softkeys work unexpectedly, and many other problems.

I saw this problem back in '99 with devices from several manufacturers. One device claimed it could support 1492 bytes, but could only support 1300 and would crash with anything larger. One device provided its maximum size in hexadecimal where every other device provided the number in decimal. The list goes on, and the entire device description repository industry (such as WURFL, Volantis and DetectRight) is an answer to the problem being even worse today.

The end customer then sees applications and web sites that do not work quite right or perhaps not at all. Developers who struggle to deliver a good user experience eventually discover that they can not trust the user agent string, and then turn to a device description repository. The cost of delivering a mobile application escalates, and the user experience degrades.

In the scope of designing, building, and debugging a phone, these errors are tiny. On the other hand, finding the errors and fixing them is very easy. These problems arise due to a combination of industry players. Device manufacturers do not attend to the problem under very tight production schedules. Operators, if they find the defect at all, assign such non-operating bugs a very low priority. Anyone who has worked in commercial grade software development knows that the low priority bugs never get fixed. (Apple's broken search engine is an example of this)

While the customer sees that the web site is of low quality, some of the problem rests in the hands of the browser provider, device manufacturer, and operator. In the past, at least in the U.S., the operator was blamed. More and more now, the web site provider is blamed.

Operators and device manufacturers need to do a lot more to support developers. After all, operators' revenue comes from device usage, which is driven in part by good applications. Device manufacturers can expect to upsell to better devices and retain customers who have a good experience with web sites and applications.

A brief list of low-cost ways of supporting developers:

1. For each device, invest the 1 hour of QA and 1 hour of development to make the user agent correct.
2. Designate a person to provide accurate data to existing device description repositories.
3. Use that same person to monitor the quality of the data in existing device description repositories.

Hi. Interesting post. You seem to be starting from the assumption that if a user agent string is sufficiently accurate, it can contain enough data so that the web developer can code a site to deal with device differences as a result. Therefore the absence of consistent user agent string data (making the quality of the information extracted unreliable) pushes the developer in the direction of a device information repository.

I should declare an interest. I work for Volantis, and was one of the original designers of the Volantis Framework (now Volantis Mobility Server).

I/we have consistently taken the view that the complexity of the resulting site, if wishing to deal with a large number of devices, becomes a significant issue. We don’t really see ourselves as a device repository provider so much as a framework provider, and one of the first things we decided was that the framework required a reliable device repository. The framework permits a single web page (or the equivalent page logic) to be built for all devices, and for it to be stored alongside all the design variations one might wish. It’s something like the separation of markup from CSS, if you then divided the styling element to also include page layout, form factors and media manipulation as well as “regular” styling. The framework then combines all this with the information that it has about the device (which can be dynamically updated for new devices) and generates both the appropriate markup and the stylesheets (if the device supports them), as well as making appropriate transformations of media (such as image transcoding).

If we had thought we could get away with not having a device repository for this, we would. But we’d still have built a framework. As it happens, we end up tracking about 650 device attributes, of which at least 150 are used by the framework to optimise or avoid bugs in the device software implementation (not identification, more typically rendering defects). You can also make device related decisions within the page definition (if it has a QWERTY keyboard present the following, otherwise make a simpler form, for example).

In other examples you mention – if you wanted to use the device’s memory specification to optimise the amount of data sent, you may be at the mercy of not knowing how certain items may be transformed at the back end. We not only sort this out, but also automatically break up the pages if necessary, either through automatically or as a result of the developer setting up policies around how it is managed.

And on screen resolution rendering (typically one of the main characteristics people want to consider) you need to bear in mind that the usable screen resolution is typically not the same as the actual screen resolution. So in some cases you may need both variables.

All of this may seem like a commercial, but the software is free and an open source version of it will be made available this quarter. You can get it from community.volantis.com

Best wishes
Mark

You are right, I did suggest precisely that. My bad.

I’m attempting to describe baby steps not for the likes of Nokia, but for the likes of AT&T and Samsung, to improve. If you read elsewhere on the site you’ll see that we do talk extensively about using DDRs; I’ve not yet looked at your since you’ve opened up.

Barbara,
let me plug our new device database called DeviceAtlas.

One thing that I think is important to note is that this is the first time that someone (dotMobi) could bring together a number of industry players to work together.
We already collect and make available data from public sources such as WURFL and UAProf and also from proprietary databases such as Vodafone and Nokia. We also already have agreements signed with TIM, Volantis, Argogroup and Zandan and we will make their data available shortly.

This is a sign that the industry is moving towards solutions that will still allow network operators and manufacturers to differentiate and developers to do their job without too much concern about fragmentation? Maybe I’m dreaming, maybe not.