Published in Web Development on Tuesday, April 19th, 2005
I don't think that I am alone in the world when I say that my primary browser is Firefox. In fact, my secondary browser is Opera (quickly gaining on Firefox), but I surf everyday with Internet Explorer. Do you?
A while back I had the pleasure of meeting a very prominent web design/ development blogger. We sat around over a coffee (my third on the day... Zap!) and discussed many issues, but one thing that was discussed was the issue of Quartz and Cleartype. This designer confessed to me that indeed, they didn't test their sites/designs/mockups often enough without font smoothing.
This came to me as quite a surprise. If 95% of site visitors are using Windows, with the majority of those visitors not using Cleartype, how could you not design, develop and test in a non font-smoothing environment?
I can hear people laughing as I type this; spend an hour programming or coding sans font smoothing and you eyes begin to scream. But this doesn't dismiss the issue.
This post was written up a long time ago, but I finally polished it up and published it after reading Marc Hedlund's post on Signal vs. Noise, "Some notes on the building of CodeZoo". In that write-up, he states:
I'm starting with Macintitis because I first learned this general lesson in 1994, but apparently not well enough. Apple has succeeded in getting most of the CodeZoo team to switch to Mac, and as a result we spent much of our time reviewing the site during development through Mac browsers and Mac monitors. Of course, that's stupid -- most visitors to CodeZoo have not yet made the switch. As we got towards launch, we found that the site is terribly broken in older versions of Mozilla/Firefox on Linux, which is a more important platform for O'Reilly than for many other sites. Dumb, dumb, dumb.
I have been guilty of the same, I am afraid, though mostly post-launch. In one example, a site was launched and changes made every so often, two or three times a week, and checked in all of the browsers and environments (so I thought). Imagine my surprise one day when I browsed to a site in IE 5.0 and found that one of the 'widgets' was displaying some extra unplanned whitespace. This wasn't anything drastic, but is was unprofessional.
Since that day I make it a habit to fire up IE 5.0 and 5.5, turn off the Cleartype and browse teh intarweb. Things act and feel different in IE, and as much as I enjoy the look and feel of Opera and Firefox, it's important to know just how my clients sites feel in IE.
Derek takes it even further, asking the following in a post where he discusses browser elitism:
For example, highlighting the current form field with a :focus pseudo-class is not just a “cool†thing - it actually improves the usability of the form. If it makes the form more usable, shouldn’t we be providing that usability enhancement for everyone, despite what we might personally think of the browsers that the bulk of our users might actually be using?
The comments in that post were quite revealing, and surprising, to me. Derek has written a second post today, Browser Elitism Part 2, where he asks some great questions, like What gives us the right to consciously and specifically deny a better experience to a user?
"You're fired".
That is what I would hear if I told a client that his several thousand dollar website contains enhancements geared towards helping 5% of the market share, that I could have provided these features to the rest of his visitors, but... But what?
Let the debate rage on, but I am of the opinion that adding behaviour to a website with Javascript is okay, and evening the distance between IE and others by using behaviour is a good idea. Adding behaviours that increase the usability of a website for Firefox users and not for IE users is very shortsighted, given that for the majority of websites out there, the dominant browser is Internet Explorer.
In addition, I'll say that we have a duty to browse the internet with Internet Exporer, to know just how users experience the internet. Consider it user research.
Sitepoint's web devlopment books have helped me out on many occasions both for finding a quick solution to a problem but also to level out my knowlegde in weaker areas (JavaScript, I'm looking at you!). I am recommending the following titles from my bookshelf:
I started freelancing by diving in head first and getting on with it. Many years and a lot of experience later I was still able to take away some gems from this book, and there are plenty I wish I had thought of beforehand. If you are new to freelancing and have a lot of questions (or maybe don't know what questions to ask!) do yourself a favor and at least check out the sample chapters.
The author line-up for this book says it all. 7 excellent developers show you how to get your JavaScript coding up to speed with 7 chapters of great theory, code and examples. Metaprogramming with JavaScript (chapter 5 from Dan Webb) really helped me iron out some things I was missing about JavaScript. That said each chapter really helped me to develop my JavaScript skills beyond simple Ajax calls and html insertion with libs like JQuery.
Like the other books listed here, this provides a great reference for the PHP developer looking to have the right answers from the right people at their fingertips. I tend to pull this off the shelf when I need to delve into new territory and usually find a workable solution to keep development moving. This only needs to happen once and you recoup the price of the book in time saved from having to develop the solution or find the right pattern for getting the job done..
Comments and Feedback
Not a fan of Progressive Enhancement then?
I do not test for IE5 or IE5.5, these browsers are archaic and far too small a minorty to worry about. I would also susspect users of these browsers are more than used to new websites breaking for them. Tough cheese.
If you always design for the lowest common denominator, you never progress. The aim is to progress, but do it in such a manner that those less capable browsers get the experience they always have, and newer ones get a better experience. It's that or just never embrace new functionality because you can't bolt it on to a long dead browser. Easy choice.
There you go. The decision you make should be based, like many things in webdesign, on your baseline browser (or baseline "whatever is accessing your site").
You can progress, you simply set some levels, for example "When Browser X drops below X% market share, we will no longer support it". Progression will happen slowly, but that's life if you're not Flash.
Progressive enhancement is good, but if you look at the cases that Derek is outlining in his articles, some of them are enriching the user experience, and doable on IE given the right tools. If your IE marketshare is big enough, do yourself and them a favor and build a better user experience.
As always, know your audience. In the Linux example you give, if as a developer I know that many users will be on that platform, I'm sure to have a check in early versions of Gecko, and Konquie. Early on. On the other side, if the audience is the average employee in a medium size Japanese corporation, IE 5.5 will be high on the list.
And I'm all for progressive enhancement. Backporting it to older browsers depends. It might be nice for the user to have that focussed input field have some different background-colour. It might be disturbing (as in not helping the user experience), if that user isn't used to see that kind of things. And then comes the performance issue. Dean's IE 7 is very nice, but doesn't speed up things, esp if you have other scripts running.
We recently had that very discussion with a client, rather websavy and FF user himself. Then the secretary had a look. Gone where the little add-ons for IE. Performance won. (story simplified for the sake of my laziness, but you knew that.)
Way to catch the flipside Philippe. That, in a way, was what I was getting at with the first part of this post: surf with IE and "feel" your sites like 90% of the audience would. Then make your decisions.
There is a balance here somewhere and it depends on our audience.
First, "everyday" is an adjective. You mean you use IE every day.
Second, the enhanced experience for "5%" of your audience – and that must be a pretty unpopular site if 95% of its visitors use IE/Win – comes at essentially zero development cost, seeing as how it involves CSS selectors IE doesn't understand anyway.
Why the dudgeon, 54·11?
Hey Joe,
Thanks for the correction.
I agree with you, that it is zero development cost, that was never my issue. Come to think of it, being able to do these things with CSS sort of opened my (our?) eyes to these things (label rollovers, for example). What I have a bit of trouble with is doing it for such a minor few. If it benefits the user, why not use it for all of them?
In addition, I found that the IE experience is so different than the Opera or Firefox experience, for example, that we need to spend some time with it to appreciate what people go through on the sites we build.
If we develop (many hours) in Firefox and test (a couple of hours) in IE, we never really get a good idea what a user goes thru on our sites.
I have no idea what this site is like in Lynx.
54-11: Hmm, I'm a cyclist, and 54-11 is a 'grail' gear ratio for me. And apparently 54-11 is "A sign in genealogy for divorced", which I sort of loosely follow towards the whole separation of (style, business logic) from (structure, presentation logic) etc etc ;-)
I enjoyed the Browser Elitism article because it actually made me aware of this issue of creating a more usable site for 5-10% of the market. This is OK for personal sites, especially web developer related because non-IE traffic is more in the 50-60% range.
I am guilty of applying pseudo classes that only work in non-IE browsers both for personal sites and for work sites. This is bad and I am glad the issue has been raised.
Depending on my target audience, I try to check a site in as many browsers as possible, including as many versions of IE as I can. Thanks to running multiple versions of IE as stand-alones, I can do this with ease.
Not checking your site in IE 5/5.5 is NOT OK for a clients site, it is still a very commonly used browser.
Hey Mike, your form element hover effects don't work in IE...tsk tsk ;)
Haha, funny stuff - Consider this place a playground ;-)
Come to think of it, I don't have any form element effects! Ahh, the :active stuff... Now I see it... Caught in the act :)
D'oh! :active, not :hover! I knew that.
My primary machine is a G4. I have 2 older Win machines that have MSIE 5 and 6 installed and no Quartz. I use all the usual workarounds so the Win users see the best approximation of my experience but it's still depressing as hell to see my 'beautiful' work looking like ass on Windows and I always wonder why someone would choose that. Someone really should take all of Microsoft's upper management out and slap them silly for the mediocrity they foist onto the world.
"You're fired." That is what I would hear if I told a client that his several thousand dollar website contains enhancements geared towards helping 5% of the market share, that I could have provided these features to the rest of his visitors, but… But what?
But it would cost a few hundred extra dollars to make up all the javascript?
I am currently developing a web-based database front end. Curvy corners,
:activeon the forms, all sorts of good stuff in there. No javascript workarounds to get it in IE. And why not? For one thing, client probably won't see it because they'll test in IE. For another thing, why would they care if you threw in an extra 3 lines of CSS?I did put in some javascript to make drop down menus work in IE, but that's because it affected the usability of the site, not just the aesthetics. Those other things are like getting a discount at the hotel because you've got a AAA card. They're not going to kick you out of a hotel for not having one, but you get rewarded if you do!
the point is that though we may end up using firefox and think its our primary browser its not that way actually.
Numerous applications under the cover end up using the IE control someway or the other.
As for security issues, firefox has to still grow up for its vulnerabilities to be exploited. It would be on par with IE in terms of bad security soon as more people start using it.
Michael wrote:
If it would cost a few hundred extra dollars, then you are probably in one of two situations:
1. You need to get someone in there that can script the solution in half an hour (tops) - especially for small items such as we are discussing.
2. The interaction is likely complex enough that it belongs in a DOM-based behaviour layer anyway.
Michael also wrote:
Rounded corners? no problem - aesthetics. But highlighting the active/focussed field? That sounds like a usability enhancement to me, and in my mind (as you may have guessed) is something that everyone should get.
I never use cleartype, it just looks wrong to me - my eyes never scream, I like the blocky lettering. I think when you start testing for nuances such as cleartype you are becoming unhealthily obsessed ;)
But wheres the cut off point, its the same old issues - as technology improves the benchmark is raised yet there will ALWAYS be people using old technology - i say targeting 90% of users is better than designing for 100% which means those expecting a mucho fabuloso experience are let down (and we'd lose clients and such because our designs wouldnt be cutting edge enough) i use echoecho.com for stats and trim off anything below 10% - call me heartless but isnt firefox free? whats the excuse
It's not necessarily advisable to ignore almost 10% of our users, at least not for a company.
There's just some delay when to (broadly) use new technologies. If you once respect "archaic conditions", you will join the regular cycle again and will also progress - just some months or years later.
(I don't want to judge this - I also rule off sometime -, I only want to notice it.)