Indulge me, if you will, in a little hypothetical. Consider the following scenario: you’re asked to design and develop a website for a big client. It’s a large company, with probably thousands of employees. A bank, for example, or a large pharmaceutical company. Or maybe it’s a government contract, or a big public sector player, like public transport or the electric or gas company.
What all of these clients have in common, is that 9 times out of 10 they’ll all be lorded over by a restrictive and overly protective IT department, who only updates their software and hardware every other decade. Which means the client will be looking at your work through the shit-tinted goggles of IE6.
But you’re used to that by now. You know all the dirty tricks and hacks in the book, so you make the site. You know the client won’t be able to see modern web stuff, so you deliberately stay away from them. No round corners, no fancy fonts, little or no Ajax-techniques and no obvious transparent PNGs.
That’s not to say you’re making a bad site, on the contrary. Some of the best design is done within tight constraints, and a little restraint never hurt anyone. Also, most of these clients have pretty restrictive corporate identities and styleguides anyway. So you design your site, slightly boring, but ultimately functional and usable. Something, maybe like this:
The client approves the comps, and the finalized website is online soon afterwards. The client tests the site on their internal, locked-down network and sees exactly what he was promised in the comps, being rendered in IE6. The client also notes that the site feels snappy and loads quickly, even on their outdated hardware. A direct result of the site’s design being restrained and sober.
The client then drives home, and, feeling a little bit proud of the work he’s helped to achieve, decides to whip out his personal laptop and opens up the site in a more modern browser (Google Chrome, Safari or Firefox, perchance), so he can show his wife what he’s been doing all these weeks. At first, a shock.
This site looks a lot better than it did a few hours ago in the office! What happened here? There’s subtle animations, tasteful rounded corners and the odd drop shadow here and there. The headings are rendered in a slick custom font that he never recalled installing and the entire site just oozes quality.
“Did I pay for this?”, the client wonders, “Who ordered these upgrades?”
First thing next morning he calls you, and asks where those upgrades came from, and why they’re suddenly gone again, now that he’s looking at the site back on his office machine sporting IE6.
“Well,” you start, “have you heard of ‘progressive enhancement’?”
Progressive Enhancement is a web-design methodology that aims to provide the best user experience to as many types of browsers and users as possible. It does this by building the site for the oldest browsers, making sure it works great for them, and then adding enhancements for modern browsers on top of that framework, so people get a more enhanced experience, the more modern, or progressed, their browser is.
It is closely related to another methodology called Graceful Degradation. This works the other way around, where you build a website that has all the bells and whistles you can imagine (AJAX, CSS3, etc…) and then either hacking those to work with the older browsers, or making sure that those browsers fail “gracefully”, in other words, so that the site remains usable when certain features simply don’t work.
The advantage of PE over GD is that with PE, you’re always certain that most of your users wile have a great experience, and that their experience will only improve in time as they upgrade their browsers. With GD, you only hope that people stuck with older browsers won’t be freaked out too much, and that future browsers won’t choke on your ancient hacks.
For new, let’s go back to the hypothetical client. You’ve just given him the gist of what Progressive Enhancement is all about, but as I’m sure you can imagine, several different outcomes to this conversation are possible.
Best case scenario, the client “gets” it, and is thrilled to know that you’ve covertly built him a future proof website that scales beautifully, from the ancient, turn-of-the-century browsing dinosaurs to the latest CSS3-, HTML5-sporting Web 3.0 browsers.
Worst case scenario is that the client demands those same enhancements be recreated for IE6. But now you’ve got an arsenal of valid counter-arguments, such as:
- It’ll take a lot of extra time and money to get that kind of visual fidelity in older browsers.
- Updating or upgrading the site later on will take longer and thus will be more expensive.
- The site won’t run as fast as it does now, both on IE as well as on modern browsers.
So, unless your client is Satan himself and/or completely immune to reason or logic, you’ll have saved yourself a mountain of extra work, and earned yourself a contented, loyal new customer, one with a better understanding of what designing for the web entails.
And all it took, was a little
We designers have a tendency to pull out all the stops when we’re mocking up a website. We know what’s theoretically possible in all browsers, so we don’t skimp on the frivolous details. Technically, rounded corners and drop shadows and the like are all possible on IE6. They just require a lot of hacking, extra markup, extra images… all of them slowing down the rest of the site for everyone. So, what to do?
Well, it just requires adding just one extra step to your existing process.
First you design your site like you always do, pulling out all the graphical & typographical stops as you see fit. Then, when you’re happy with it – STOP. Don’t send it to the client just yet. Instead, duplicate your file and tone it down. Take out everything you know is difficult to do in IE6. Better yet, ask the guy who’ll be writing the CSS to do that for you. After removing all the frivolous eye-candy, give the comp a final spit & polish to make sure the design still *pops* and only then send it to the client.
After the usual bout of back&forth, and you finally get client approval for the “restrained” comp, build that, re-adding some or even all of the eye-candy by way of targeted CSS3 and AJAX, so those with modern browsers get the enhanced “special edition”.
It’s a difficult balancing act, sure, and it requires an intimate working knowledge of CSS and browser capabilities, as well as a keen eye for design, but the rewards for dealing with these “conservative” clients in this way are legion, and you’ll end up with:
- Smoother & quicker development cycles, as there’s little or nothing to hack.
- A site that just works and has no IE overhead.
- A client who might feel as though they got more than they bargained for.
- Happy users, regardless of what browser they’re using.
Now wouldn’t that be nice?
The example given is a mock-site for a mock-client. It was quickly thrown together as an example of what’s possible with progressive enhancement.