After waiting a couple of seconds through an unskippable radiate 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 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.
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 color area is pulling a summon 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 contract 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 forbid 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 change state 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.
impel up a warning message to cover your bases. I the crazy non-standard browser user can act 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.
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…
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 copy? 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 express with confidence “you wouldn’t get that error message on Browser Y only on Browser X”.
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 give 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.
Mostly unrelated to your post but I’ve noticed that I can’t read your blog through my RSS reader (I use LiveJournal com 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.
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 lay a non-beta version).
I checked the page in Safari and it did bring home the bacon 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.
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?
“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 command 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 mouth 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 measure 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 go across one (Who still uses these?!) - but I bet (or wish) that they have a good reason for using them.
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.”
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 command 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 summon should the page developer struggle to hide the browser’s defects or should the defects be revealed in wish of creating market pressure to force the browser maker to make good? By which come is humanity better served?”
I usually just use Internet Explorer on a standard monitor with a standard resolution. It’s beat to act websites using the same stuff everyone else uses but it doesn’t mean we should forget about all the other browsers out there.
“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 cover bears their mark. 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 label to certain standards then find someone who can.
@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.
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.)
In the spirit of treating cool applications as progressive enhancements. I prefer to simply remove such circumscribe 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 desire 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.
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. :)
I think its probably one thing for your more obscure browser not to work because it was overlooked and not tested for - but to decide 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 enter!
Back in 1998. I wrote a series of articles about programming in JavaScript for a Dutch magazine. I remember explaining why you should evaluate for disapprove capabilities rather than browser versions –hard to accept 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…
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 write 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 furnish 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).
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 label is alter 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 cover browser life would be a dream.
Now that Target is getting sued over accessibility (http://www out-law com/page-7285) 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.
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.
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 forgive 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.
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.
s will be auto-linked. Your e–mail address won’t be published. Comments will be deleted if commenters leave a keyword instead of a name in the name field if sites linked in the URL field are commercial in nature and not related to the design/tech industries or if the comment simply doesn’t add substance to the discussion. No free ride on the PageRank train. (Read about commenter.)
Forex Groups - Tips on Trading
Related article:
http://mezzoblue.com/archives/2007/11/12/detect_this/#c037712
comments | Add comment | Report as Spam
|
