Skip to: Navigation | Content | Sidebar | Footer

Weblog Entry

Detect This

November 12, 2007
Browser error message

Reason #429 why your browser detection script needs to be trashed.

On Greg’s say-so, I thought I’d check out the Starbucks card designer. Mixing up my morning coffee with creative UI design seemed like a winning combo.

After waiting a couple of seconds through an unskippable Flash intro (who still does this?!), I found the button to “Get Started”.

Except rather than actually doing that, I was stopped dead in my tracks by an error message that my “Browser version does not meet minimum requirements”.

I’m using Camino, which is of course functionally similar to Firefox. If they were testing for features rather than parsing browser strings, I wouldn’t have received this message. So even though it’s entirely likely my browser of choice is capable of treating the site the same as Firefox, they’ve locked me out. No “I know I’m living on the edge, let me continue anyway” link in sight.

Normally when sites do this to me, I can happily live without their service and just go somewhere else. Today I happened to have Safari loaded at the time and I was still curious, so I dumped the URL into the address bar. Another browser, another error message.

Keep in mind that Safari was listed as a supported browser. This error message tells me I don’t have cookies enabled. Except, I do. Suspecting a frame, I viewed source which revealed that the white area is pulling a page from an extrenal site into a frame that presumably runs the card creation app. (Who still does this?!)

The actual issue stems from the fact that Safari allows me to specify if I want to accept cookies with the options “Always”, “Never”, and “Only from sites I navigate to”. The latter is clearly the only sane choice for users who stop to think about it (and for all I know, it could be Safari’s default behaviour). So the framed third-party application was denied cookie access, and clearly they have no fallback position for cookies being disabled. And I was shut out once again.

Okay, so what can we learn from all this? Your browser detection script better not be testing for specific versions of specific browsers, because there are too many out there, and they’ll all (finally) updating rapidly enough that your script will be out of date in months.

If you absolutely 100% cannot launch without some sort of message to users who choose a different browser than you’ve tested in, do not lock them out. Throw up a warning message to cover your bases. I, the crazy non-standard browser user, can take it. But let me proceed anyway. This is literally 5 seconds worth of work, what justification is there for not including a link that will let me do it?

The cookie problem is a bit more complicated to tackle, especially for a third party service provider, but we do know about server-side sessions and APIs now. There are ways around it.

Otherwise, you’re just foiling your copywriter:

Error message in Camino

djbaxter says:
November 12, 13h

Interestingly, I have even had trouble using IE7 to access the Microsoft Update site. They seem to think I’m using a browser for a Mac. I had to use the MS User Agent String Utility to spoof IE6 to get access to the site.

November 12, 13h

I have been having some trouble with Safari and Cookies not enabled as-while, I wonder if it is a bug?

November 12, 14h

I hope you learned a valuable lesson from this: Don’t drink at Starbucks.

November 12, 15h

By coincidence, I ran into the same kind of excessive-cleverness this morning: a customer-satisfaction survey. It started with a “Do not use the back button” warning and got worse: a naïve attempt to prevent a question from being submitted twice also meant that each time their servers failed to respond (often) there was no way to re-send the request without using Firebug to reset a JavaScript variable. A single server-side check would have saved a few dozen KB of JavaScript (really!), not locked out Safari users and made their service significantly more reliable.

Granted, it was an outsourced survey host but it’s still pretty embarrassing since the survey was for a company which used to bill itself as the dot in .com…

November 12, 15h

Yeh, who does intros anymore? It wouldn’t be so intrusive if it wasn’t about 15 seconds in length before you could actually click on something (or 30 if you let the whole animation play out.) And this is designed for coffee drinkers! Maybe they figure you’ll end up using it before getting your fix… ;)

November 12, 15h

I find it interesting that i also came across the same issues with Safari browser

Rick O says:
November 12, 16h

(One of the error messages that a recent app of mine spits out is “Sorry, you need a browser that’s not as old as your mom.” So I may be a bit biased here, but…)

Just to play devil’s advocate –

What about browser-lock for non-JS features? If you have a site that simply doesn’t run without a relatively sane CSS implementation, what are you to do? Are you going to spend an insane number of hours hacking javascript replacements for browsers that don’t support :hover for anything but hyperlinks? Or double-coding CSS to work around a broken box model? Or making twice as many images because a browser puts ugly grey backgrounds on alpha-channel PNGs but the GIFs look like crap? How do you feature-test for those kinds of things?

(Yes, I know, the second one is probably not too difficult to detect with javascript, and the first is hackable with behavior files, but if you’re nitpicking then you’re missing the point.)

We can all pray at the altar of Graceful Degradation and Progressive Enhancement, but surely there must be a line in the sand somewhere, right? At what point do you throw up your hands and say “the design *IS* integral, and it’s not worth my time to make your browser do what it should have done right in the first place”?

I’d also assert that there is a quantifiable benefit for browser-lock instead of warn-and-proceed-with-caution: support costs. No matter how many times you say “you are unsupported”, people are going to call you up and waste your time trying to get you to support them. Some will even go so far as to lie to you and tell you they are using Browser X, when really they are in Browser Y, because the warning on their screen says “You should use Y instead of X”. So when they get half-way into the app and something breaks, they are going to call you and try to get support, because they want the end product, not excuses about how parts work and parts don’t. Whereas if you just shut them down completely from the start, not only are they less likely to call and try to finagle support out of you, you can state with confidence “you wouldn’t get that error message on Browser Y, only on Browser X”.

Not that I don’t agree with every point you made, of course. Just trying to widen the box a little.

November 12, 17h

I hope you were nice enough to let Starbucks know about their problem?

Dave S. says:
November 12, 17h

#Rick O - Thanks for the opposing viewpoint, you make some valid points.

Drawing a line in the sand is a reality, you obviously can’t support every browser ever made, and there are certainly diminishing returns in supporting browsers beyond a handful of those currently popular.

But I would question the actual support costs of letting users choose to proceed with an unsupported browser; without numbers it’s anyone’s guess if those costs outweigh the cost of flatly denying users. My gut tells me no.

Emma says:
November 12, 17h

Mostly unrelated to your post, but I’ve noticed that I can’t read your blog through my RSS reader (I use and read blogs integrated into my friends page there) anymore, because all of your images are being replaced by an anti-hotlinking placeholder. I’m quite disappointed by this, because I probably won’t have the inclination to click through without the lure of the pretty pictures. I don’t do much in the way of design, web or otherwise, at the moment, so I’m probably not a huge loss, but I just thought I would let you know.

Kevin says:
November 12, 18h

I found it interesting that the Camino screenshot linked to download pages using the version number in the text of the link. I decided to see what version you could actually download at each of those links, and it so happens that they are IE7, Firefox 2 (but version three will be on that same page whenever it releases), and the Safari 3 Public Beta (not instructions on how to download an install a non-beta version).

I checked the page in Safari, and it did work for me, even with the cookie preference “Only from sites I navigate to” which is odd.

So then, I checked the page in Firefox without JavaScript (via Web Developer Toolbar) and I saw this: Clearly they are using JavaScript for all their detection needs, so they can’t even tell if I’m using an “allowed” browser or not. And the “Instructions for Enabling JavaScript” are not links. So they didn’t check their pages wihtout JavaScript either.

Mau says:
November 12, 18h

Why am I not surprised that the website is running ASP?

Meerasedai says:
November 12, 18h

One of the most frustrating (but similar) situations that I have found myself in involves applying to medical schools with AMCAS’s primary application system. The only acceptable browsers according to their system is Internet Explorer and Netscape. Well, I wasn’t willing to use those two browsers (nor was I willing not to go through the process!) so I used a Firefox plugin to trick them into thinking I was using IE. Guess what: there was no problem in using the application from Firefox! WHY would such a large organization pay for a website that employs this sort of garbage?

Casey Glass says:
November 12, 18h

“Suspecting a frame, I viewed source which revealed that the white area is pulling a page from an extrenal site into a frame that presumably runs the card creation app. (Who still does this?!)”

Starbucks sell coffee, that is their area of expertise. They aren’t in the business of printing customised cards, so it appears that they’ve sourced a company that does just that to handle the personalised card design application for their website. In addition to this they would need to source the card stock, printing and delivery that follows the card designing process.

I think it’s unfair to give Starbucks a hard time just because they chose to deliver a product that is built, maintained and hosted by people who are specialists in that line of business.

I will admit that using an IFRAME doesn’t make for a perfectly integrated “view source” experience, but this is exactly the kind of situation the IFRAME element was created for.

In my experience, there are some CMS’s that make the integration of 3rd party applications so ridiculously convoluted that sometimes there is no other feasible way to complete the project on time and within budget than to use IFRAME’s to integrate applications into a website.

I think that if the HTML elements are being used in the way they were intended (not being employed in a convoluted manner e.g. tables for layout), there are no security risks to the site or user, and the finished application meets all the user and business needs - then I don’t see why using a hosted application through an IFRAME should be looked down upon.

I concur with you on the detection script issue. Being a Camino user myself, I cringe every time I come across one (Who still uses these?!) - but I bet (or hope) that they have a good reason for using them.

November 12, 21h

Who still sends e-cards?

Rachel says:
November 12, 22h

Dustin: silly wabbit! It’s a Starbucks prepaid card, not an e-card… but yeah, does anyone send those?

Mezzoblue, I like your idea for some creative fun… I’m not a huge Starbucks fan, but I’ve always loved the idea that they’re cards are customizable.

Nic says:
November 12, 22h

What about this one: I picked up a problem with a radio button list on my bank’s online banking site where the radio buttons didn’t line up with the labels. A quick logout in Firefox and retest in Internet Explorer confirmed my suspicions that it worked fine in IE. So I reported it to them, suggesting that they may want to fix it since it was basically a simple markup issue. Here is their reply:

“Kindly note, the structure and platform of the Internet banking website was primarily written for the Internet Explorer browser. It makes it more safe and secure because of the encryption and security provided by Internet Explorer. However, another recommended browser is Netscape as they a built on similar platforms.”

Internet Explorer is recommended for *security* reasons! Whatever.

Ole says:
November 13, 02h

Aw, but string parsing is so much fun :)

November 13, 04h

As a long-time Opera user, I have to say that this style of script writing isn’t news! On bad days I’m quite sure it’s typical and widespread. You have my sympathy and understanding, though.

Opera’s worked around this problem by having switchable user agent strings. I just found something similar for Camino, but haven’t tried it since I don’t have a Mac:

November 13, 08h

There’s only one time when user-agent detection is better than feature detection: When you’re trying to work around bugs in specific versions of a browser. For instance, Safari treats Javascript and CSS very differently than the other ‘good’ browsers (I suspect it’s related to their desire to be the fastest of the browsers), but it’s also a slippery target to get a handle on. It’s not like you can say, ‘if(document.all)’, so some direct UA detection is sometimes required.

The real complaint is sites that practice browser lockout based on an exclusive list of supported software. I’m always a little irritated when I have to open my company’s bug tracking software in Firefox because Opera (which is an entirely-competent browser) gets stopped at the door. I guess what really irks me is that IE6 and 7 are–of course–supported perfectly, despite having obvious flaws, merely because they’re more popular.

Douglas Crockford once asked the following question, “If a web browser is defective, causing errors in the display or performance of the page, should the page developer struggle to hide the browser’s defects, or should the defects be revealed in hope of creating market pressure to force the browser maker to make good? By which approach is humanity better served?”

November 13, 08h

I noticed something similar to this on none other than Yahoo! I was using my linux live cd one time and went to their site and got a friendly message stating my browser sucks. Regardless I changed my user agent string and low and behold their home page was a bit screwed up.

Dave, you do have to admit that you make up a very, very small population of the web using Camino.

I usually just use Internet Explorer on a standard monitor with a standard resolution. It’s best to create websites using the same stuff everyone else uses but it doesn’t mean we should forget about all the other browsers out there.

Mark says:
November 13, 11h

“Starbucks sell coffee, that is their area of expertise. They aren’t in the business of printing customised cards…”

True enough but they should be involved in what gets displayed on their site and of course bears their brand. This should have been tested, audited and rejected and it is Starbucks job to make sure their site is up to par not the 3rd party. If they can’t code to certain standards then find someone who can.

Very nice article btw.

David Robarts says:
November 13, 17h

I pretty much always have Camino spoof Firefox to avoid such troubles.

Philippe says:
November 14, 05h

Dave, have you considered contacting the webmaster of that site ?
You can always point to .
Sometimes that works out quite well (the people in charge are eager to improve their site); and sometimes, the answer is better left unsaid.

I never spoof my UA string (Camino) and, well, some sites have lost sales.

Ian Adams says:
November 14, 10h

@Neal Grosskopf: What does it matter what the market share is for Camino? In terms of rendering and javascript handling, Camino is identical to Firefox. Besides, wasn’t the whole point of having standards-based browsers supposed to be that we could start coding our web sites using standards? It’s 2007 (almost 2008!) — there’s simply no excuse for browser-sniffing anymore.

Isaac Lin says:
November 14, 22h

The problem is if a site developer isn’t going to implement graceful enhancement, odds are good that stuff will break horribly in some way for browsers that lack the required capabilities, and this will lead to support issues (even if the specific problematic areas are identified – users often don’t read warnings). So though I agree browsers shouldn’t be blocked from accessing a site, I don’t think providing a “use at your own risk” link would adequately avoid support problems. Testing with browsers that lack the desired capabilities should be performed so the resulting issues can be evaluated.

A potential pitfall is that users may not be able to correlate any shortcomings in the site with their browser’s configuration or lack of feature support. For example, for the longest time, when I visited the site for an organization I belong to, I used to think that it just didn’t put much information up – I didn’t realize that without cookies enabled, the site failed to display most of its content. (The site design has since been changed.)

November 15, 18h

In the spirit of treating cool applications as progressive enhancements, I prefer to simply remove such content based on user abilities, instead of giving an error message (though it sounds like your experience and that of some of the others was the result of some flaw in the scripting).

It is very difficult, though, when trying to provide for all. Not everything is possible. And as Rick O. asked — “surely there must be a line in the sand somewhere, right?” — it is true, there has to be. It really boils down to how the application’s designer deals with these things that separate the men from the boys, so to speak.

Locking out users is not a good method of dealing. A user shouldn’t be locked out, but rather they should just be given what they can use. I don’t like requirements up-front, nor do I like them as a result of failing at something I’m informed I can do. Not to say I can’t be informed (or led to believe), it just needs to be done more informatively I guess. Such as seeing a subtle message on a site that I am fully enjoying with what I’m using informing me that other functionality — added cool stuff — does exists but I will need this-or-that.

November 16, 01h

I guess the real question then is not why it has happened but ‘will they fix it?’

Or will this company tell Starbucks that its just a few peripheral Camino whiners making a big deal about nothing much at all.

I don’t begrudge Starbucks at all for making a mistake but I would be disappointed if they fell into the osterich stance and ignored the issue. It will be interesting to see if anything changes - I’m assuming someone has brought this to their attention?

I’m a weak soul though myself and would probably have just opened up IE or Firefox and plugged away without remorse - oh I am soooo shallow when it comes to cool experiences lol. :)

November 16, 05h

I know this problem all too well. it’s my job at Opera to get these kind of messages removed from web sites (even for none Opera browsers). They are still far too common, and even from companies that should know better.

November 16, 12h

@Ian, I guess I was just stating that if you use a browser that few people use, don’t expect it to work perfectly on every site out there. It’s the unfortunate truth of the internet. I totally agree that browser sniffers are lame.

November 16, 14h

I think its probably one thing for your more obscure browser not to work because it was overlooked and not tested for - but to choose exclusion is a bit harsh.

One would think by now businesses would be particularly aware of the importance of letting customers in the door. But then again they may hire a big angry bouncer to stand at the door of their physical book store, for example… now that would be worth a photograph!

November 17, 19h

I doubt Starbucks picked it’s gift card provider on whether they had an API for customization (I’m assuming the company that does the custom cards fulfillment is the same that does all of their other mass-produced ones).

I can’t believe I’m defending Starbucks.

November 20, 15h

Back in 1998, I wrote a series of articles about programming in JavaScript for a Dutch magazine. I remember explaining why you should test for object capabilities rather than browser versions –hard to believe that there are *still* people, apparently, who don’t “get” such a simple concept! As for the cookie problem, that’s slightly harder, as you say, but still perfectly solvable…

Missy says:
November 21, 07h

Conditional CSS is something that really gets my back up. There is an awful lot to be said for semantic markup - keeping it simple (which does not preclude a complex design) means that most browsers will behave themselves without the need for separate stylesheets or browser-specific hacks.

Perhaps Starbucks feel the need to offer their users as many variants of CSS as they do coffee!!!

November 21, 18h

Rick O:

“So when they get half-way into the app and something breaks, they are going to call you and try to get support …”

Obviously, a decent (let alone a _good_) web app developer would have the skills and common sense to build the app so that whatever browsers are capable of entering the app are capable of completing it to the end; having something break halfway is just a sign of truly poor web development, and that’s not a case we should assume at all.

Progressive Enhancement is really the key answer here: provide at least a basic version that, if it truly CANNOT render/support your app’s intention, will at the very least give a message explaining why the user can’t see the (full) app, what it is they’re missing out on and where they can get a browser that does allow them to continue.

Beyond that, simply build the app so that functionality is added in the app in perfect parallel with that functionality being available in the browser used. That’s really all there is to it, and any good web developer will build the app that way (pending reasonable circumstances).

Support issues like you presented are very easily dealt with if the app is properly built: there’s not much you can do against people lying in any scenario, so being inaccessible isn’t a particularly great way to cover your bases. In fact, it may be the worst approach of them all, depending on the case — as you’re potentially setting yourself up for a lawsuit by doing so (in more and more countries).

Jaz says:
November 21, 20h

Nice article JS browser sniffing is pretty crap, I have to agree. I personally use server side detection as I validate my code to strict which throughs IE into quirks mode something they don’t plan on sorting out till at least IE8. I do this by testing the user-agent - moz. browsers get 1 IE (including Opera) get another. Then there is very minor changes for each one.

A little bit more work agreed but the code is clean and the changes to the other 3 are only a few lines + users like yourself don’t get locked out. I know it’s getting, if not already, outdated but I prefer the fact that -
1. Fewer bytes are going to the client.
2. Increased download time.
3. A very small bandwidth saving.

I’ll be stuck in my ways at least till IE8, if it supports the strict doctype that is, is the norm for IE users. If they could just fix that bloody browser life would be a dream.

Stomme poes says:
November 27, 06h

Now that Target is getting sued over accessibility ( and as you read the bottom of the page you see that the UN is getting involved and the UK has already made laws covering ANY public sites, the Starbucks out there (private companies who’s business isn’t normally webpages; businesses who hire “professionals” to do the work well) will start to worry more about accessibility– and browser choice is part of that. Expect more companies to grill their web-builders, expect more web-builders to get sued (or have court settlements), and expect problems like this to get more recognition as the disabled make their case (I would think any specific laws would mention browsers and browser choice).

I recently found a page written in some Vector Markup language for Microsoft only. The page is almost completely unviewable with ANY other browser. Their response to my question was, maybe we’ll look at it.

December 06, 15h

Sites that force users to be locked out based on their browser are like night-clubs where doormen turn you away for having the “wrong shoes”.

I have money to spend and the shoes on my feet or the label on my shirt do not limit the vast amounts of cash I was thinking of spending in your swanky club.

If these doormen tell me to leave due to my attire, I always see it as their loss. They didn’t deserve my attention in the first place.

December 20, 19h

I run about 70 web sites for newspapers using about 10 vendors.

Our main site backbone was developed by a group of idots I won’t name but when I asked them what browser they beta tested the sites in they replied only Firefox. They are fired. 90% of my audience is using some version of IE - and definitly not a lot of IE7. Just because web designers like other browsers is no excuse for the thinking process clearly taken in the community. Most people are on Uncle Bills machines using his browser and we on the business side don’t want to hear too much about why a site is 400 times the screen size on a MAC 8. Upgrades cost money out here.

February 09, 17h

How a big company like Starbucks allows a website to be designed with limitations to specific browsers is beyond me as they really cut off their own toes.

Yes, the Flash animation is cute and light and pretty - but does it sell what it says it does or does it aggravate more people than good and turns the customer away?

Have them build something that degrades well to old browsers, slow connections and people who HATE anything Flash getting in their way of spending money and leaving the store as fast as possible again.