Message saying "your browser is not supported" in corporate environment?

Question

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?

Answer 1

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;
}

Answer 2

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.

Answer 3

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.