Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

A lot of ink has already been spilled over the reasons why the infamous useragent string should not be used for browser parsing, and giving a message to the user that they have to upgrade their browser or the site will not work. The main arguments are:

  1. Browsers can spoof the string, so it is not trusthworthy.
  2. The string is a total mess with no good defined structure
  3. It's lazy to deny features or access to your site because you don't want to support/test on browsers other than chrome.
  4. You can't change people's behaviour, they will not upgrade because you say you.

Good. Now I'm in a situation where I might think the use of the useragent string is more legit, and I'd like some input. We're a small company that offers a software product. That product requires a web application to do certain stuff. We currently only support recent versions of the major browsers. That means IE9 or opera are not fully supported. When a user of our product logs in on our web application, they will get a warning (not a pop-up, just a message) saying their browser might not support all features. The reasons why I believe this warning does not suffer from the problems stated above and is in fact a "nice to have" warning right before you log in, is:

  1. In corporate environments, people usually stick to default non hacky settings. Spoofing a useragentstring has no gain, only pain? so the string will almost always be correct.
  2. Parsing of the useragent string is very easy if you want to know if its a recent version of a major browser. I don't need to check the device or special browsers.
  3. This is not a question of being lazy. We only have the time to develop the application for platform x and Y, and if you use another platform, we cannot sell our product to you. We want to be 100% confident that what you buy is usable and tested.
  4. Companies know the requirements of our product before they buy it.

Are there any serious flaws in my reasoning? Or maybe other reasons why using the useragent string will cause the message to appear (or not appear) inappropiately? Will this damage the credibility of our product if it is deemed "unprofessional" or "insulting" if we reject someone's browser?

share|improve this question
1  
my favorite "this browser is not supported" message was from an application that only supported firefox 3.6 and above, which totally broke when firefox switched to using whole version numbers instead of dot releases. –  smcg Apr 25 at 20:34
4  
Your fourth item may be complicated by the fact that the people who buy the product have a certain idea of requirements that are far from the reality of the department where the product is going to be used, and people in the department that has to use the product shake their heads about the absurd requirements agreed to by the people who made the buy-or-no-buy decision. –  O. R. Mapper Apr 25 at 22:07
    
The problem is that in some major browsers the User-Agent string is a big lie. IE saying “Mozilla”… It looks like a joke. –  Nicolas Barbulesco Apr 26 at 20:04
    
related question : ux.stackexchange.com/questions/53430/… –  Alex Aug 5 at 13:40

3 Answers 3

up vote 26 down vote accepted

If you are in a corporate setting, then you have control over your users. There are various ways you can lock them down to what browser they are allowed to use, whether its through an Image, Group Policy, Firewall settings, etc. Now, by you, I obviously mean those in the company that have the permissions to do so.

However, if you don't want to jump through all those hoops and want to detect what browser they are on and proceed accordingly, the best practice has been for some time now to use feature detection, not user agent sniffing.

My favorite resource is Modernizr by Paul Irish and team.

In his article, Taming the Lawless Web with Feature Detection, Jonathan Sampson states the following:

Don’t Gamble With Bad Practices

Sniffing a browser’s user agent string is a bit like playing Russian Roulette. Sure, you may have avoided the loaded chamber this time, but if you keep playing the game you will inevitably increase your chances of making a rather nasty mistake.

The navigator.userAgent string is not, and has never been, immutable. It changes. It gets modified. As browsers are released, as new versions are distributed, as browsers are installed on different operating systems, as software is installed in parallel to the browser, and as add-ons are installed within the browser, this string gets modified. So what you sniff today, is not what you will sniff tomorrow.

Have a quick look at a handful of examples for Chrome, Firefox, Opera, and Internet Explorer. Bottom line is that you can’t be sure what you’ll get when you approach the user agent string buffet. As is immediately clear, the above approach would not even match version 12 of Opera consistently with its variations.

So, have I thoroughly convinced you that sniffing is bad? And have you sworn it off as long as you shall live? Let me give you something to replace it; something reliable that will nearly never let you down – feature detection.

Go With What’s Reliable

Feature detection is the practice of giving the browser a test, directly related to the feature you need, and seeing whether it passes or fails. For instance, we can see if the browser supports the <video> tag by quizzing it on whether it places the correct properties on a freshly-created instance of the element. If the browser fails to add the .canPlayType method to the element, we can assume support isn't there, or isn't sufficient to be relied upon.

This approach doesn't require us to make any assumptions. We don’t couple poorly-scavenged data with naive assumptions about which browsers support which feature. Rather, we invite the browser out onto our stage, and we demand it do tricks. If it succeeds, we reward it. If it fails, we ditch it and take another approach.

The Work Has Been Done For You

You could be rightly freaked out about now, thinking about all of the tests you would have to write. You might want to see if localStorage is supported, gradients, video, audio, or geolocation. Who on Earth has time to write all of those tests? Let alone learn the various technologies intimately enough to do so? This is where the community has saved the day.

Modernizr is an open-source library packed full of feature-detection tests authored by dozens of talented developers, and all bundled up in an easy to use solution that you can drop into any new project. You build your custom download of Modernizr, drop it into your project, and then conditionally deliver the best possible experience to all visitors.

Modernizr exposes a global Modernizr object with various properties. You can test for the support of certain features simply by calling properties on the Modernizr object.

if ( Modernizr.video ) {
    // Browser supports the video element
}

Additionally, it can optionally add classes to your element so your CSS can get in on the action too! This allows you to make conditional adjustments to your document based upon feature support.

html.video {
    /* Woot! Video support. */
}

html.no-video #custom-video-controls {
    /* Bummer. No video support. */
    display: none;
}
share|improve this answer
3  
"you are in a corporate setting, then you have control over your users" = I have yet to work in a corporate setting where UX has any power over the employee browsers. In fact, one of the more awkward corporate situations I've been in where senior management decided to officially stop supporting IE6. Yet IT still hadn't upgraded the company computers to IE7 yet. :) –  DA01 Apr 25 at 16:48
    
This is also a good answer. Test for the features you want to support--not the browser. (and giving them a message saying some features won't work is certainly a fine idea, IMHO). –  DA01 Apr 25 at 16:50
1  
@DA01 - I think my statement implies that in order to lock things down via Group Policy, you would have to have access to Group Policy. It has nothing to do with UX. As far as corporate environments go, I've been in environments that have given me domain admin rights and I've been in environments where I wasn't even a local admin to my machine. –  Code Maverick Apr 25 at 17:05
    
Wouldn't it be great if UX did have some say on that, though? I can dream... :) –  DA01 Apr 25 at 17:07
    
@DA01 - It sure would be pretty cool. It would make my job SOOOOO much easier! =D I updated the first 2 paragraphs for you. –  Code Maverick Apr 25 at 17:14

Your initial reasons for not trusting the useragent found within the navigator object are correct. As an answer to your question, I'd like to append something to #1 & #2. The browsers often change the value of useragent.

In my current browser, the result of window.navigator.userAgent is:

"Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/34.0.1847.116 Safari/537.36"

So which browser am I running? Mozilla? Safari? Chrome? Right now I'm running Chrome v34. The other day, I did this in Chrome, and Chrome didn't even appear in the userAgent string. It's my understanding that browsers will often change this value to bypass sites that are trying to browser detect.

So my major concern would be the validity of parsing the userAgent string. But WhichBrowser often is accurate (I've had it show up incorrectly though before, but almost never).

Assuming you get an accurate result in your parsing, It wouldn't hurt the reputation much, if at all. Many in the corporate world are used to seeing strict guidelines of software or versions of software they're allowed to use. It sounds like you will be just displaying a warning letting them know that the product is not optimized for their browser. As long as it's just a warning similar to that, it should be fine. If you explicitly prevented them from accessing it via your browser - then it would cause problems.

share|improve this answer

Here Above is an example of good and reasonable UX on detection of a browser version that may experience problems.

It briefly describes the errant behavior, thus heading off a lot of requests for help. It basically says, "if you continue, you're on your own."

I continued BTW without difficulty. But had there been, I wouldn't have bothered to request help. I had been warned.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.