When Brit CSS mega-star Andy Clarke writes more than a paragraph on a topic in a blog post, you can usually assume a firestorm is about to follow. Yesterday he reiterated two intertwined topics that he's championed in the past (building for modern browsers first, and no longer showing clients static visuals), and so far the response I've seen isn't people freaking out in disagreement, but rather freaking out because they know Andy is correct but aren't sure how to fit the process into their budget models.
Andy's post, Time to stop showing clients static design visuals presents a modest proposal.
No, I don't mean cannibalism. Although as a complete derailment of the topic, the line "Queequeg was George Washington cannibalistically developed" in Moby Dick gave me the strangest idea for a graphic novel.
Instead of human consumption, he speaks about two topics: Ending the practice of progressive enhancement, and moving from showing Clients Photoshop/Fireworks proofs and instead showing them markup/CSS proofs that behave and render like a real website will render. He speaks about the topics as if they are the same one. This is just as well, because they are.
There's a major problem with the way a good deal of companies are presenting designs to clients. With a static visual, you're showing them a proof that is more like a poster than a website. It's one size, it's non-interactive, and it presents the lie that all browsers are going to show this website the same way. The fact is that despite years of web standards activism, some 'modern' browsers (*cough* IE *cough*) are both behind in implementing CSS properties that have been in the wild for years, or in some cases, choosing to implement properties their own way, and standards be damned.
@font-face anyone?
Andy's proposed approach (and it's not a new proposal, he's been championing the idea since at least Transcending CSS) is that the common philosophy of progressive enhancement (aka make a website that looks and works well in the worst browser, then build up from there) is horribly backwards, as well as the practice of trying to get every browser, new and old, to render a website the same way. We should be building websites for modern browsers first and foremost, then ensuring that the website looks professional, but not identical, in non-compliant browsers.
Under this philosophy, Internet Explorer 7 isn't a modern browser. Let's not fool ourselves, kids. Even IE8 with all its new whistles and bells isn't adding a single piece of CSS3, concentrating instead on catching up in CSS 2.1. We should, he proposes, be targeting browsers with the most advanced, up-to-date CSS and then allowing the design to regress with less capable browsers.
I'm sure that more than a few of you are thinking I'm off my rocker. Not design for IE? It's the biggest browser out there? Am I bananas?
Maybe. But not about this. Take for a moment if you will the example that Andy gives regarding rounded corners. They're a common design element that have historically been a pain in the ass to do with CSS. Way back in Fighting the Bane of Rounded Corners (Or How To Avoid Unwanted Markup) I discuss ways to cut down on markup while preserving a rounded corner design in all browsers. In Andy's post, he goes one large step further and sets up a rounded corder design that doesn't add a single extra element for markup... and doesn't show a rounded corner on every browser. He does this using border-radius, which has browser-specific implementations so far for Safari and Firefox, but no support in other browsers.
What is a rounded corner? It's a little bit of polish, that's it. Not having it doesn't make a design any less professional, but not going into the deep end to make it appear on every browser that doesn't have border-radius support saves you a tremendous amount of time (and markup) which results in a cleaner website and saves the client money.
Andy isn't isolated in an ivory tower with this kind of idea, either. One example he gives, a little website called Twitter (you may have heard of it) has adopted this philosophy with their new redesign. Those of you who predominantly use Internet Explorer may have never noticed the difference. Their new design is clean, professional, and even pretty. However, if you were to load it up in Firefox or Safari, you might notice that many of the design's corners are rounded in those browsers. It's a nice touch, but the site doesn't lose anything in Internet Explorer for not having it. Some day (probably around Internet Explorer 10 or 11) Microsoft enthusiasts will see the rounded corners, but the site isn't any less for them not seeing them now.
Rounded corners are only one small visual element that are difficult to add to non-modern browsers, but costs the site's appearance little when those browsers fail to show them. Concentrating manpower on creating cross-browser solutions for these items, let alone for the blighted pox that is Internet Explorer 6, costs us a good deal of development time, which means it's costing the clients a good deal of money.
So let's stop thinking backwards. Let's design kick-ass sites that look amazing with modern CSS on modern browsers, and look kick-ass without the non-critical design elements in non-modern browsers.
How does this tie back into static visuals?
Let me spell it out.
On a Photoshop proof a rounded corner is a rounded corner. If you hand it to a client and say "This is your website" then they expect their website to always have those rounded corners. You've created an expectation that must be met on any quirky old browser their grandmother happens to be using on a ten-year old e-Machine. This in turns means you're spending a massive portion of your budget on small details like mimicking :last-child pseudoclasses on a dynamic list that has a unique design for the last list items (or supporting rounded corners, or whatever feature IE just can't manage to catch up with).
If instead you're presenting your client with a markup/CSS proof, they're seeing the website in the browsers they use, and can see how the site renders differently in each, as well as any additional behavior like fluid designs changing size with the window, etc. You're creating the proper expectations from the beginning that they're going to get professional results in each browser, but different results. You also get the benefit of showing them how non-static elements will behave. The product they sign off on will be much closer to the product they get.
The big problem with this according to some of the feedback I've seen Andy get, is that markup/CSS 'proofs' take more time to implement than Photoshop/Fireworks static proofs. Andy himself claims to be much more efficient time-wise at building a proof mostly in markup/CSS than in Photoshop. But even if you're not, you can absorb that extra time spent in the budget that would have been wasted on extravagant solutions generated to create identical rendering where it need not exist.
To me, the time matter is a minor one. It's more about honesty and reality. A static proof will never show a client how a website will actually look, it's merely an approximation, and one that leads to disillusionment when the site is later viewed in the dynamic, multi-browser world that web pages actually exist in. By the same token, adding tons of non-semantic markup to a page to support non-critical elements like rounded corners isn't doing the clients any favor.
I could rant forever on this topic, so I'll just keep it simple. I agree with Andy 100%. We need to abandon old processes and focus on modern web development for a modern web. We don't need to abandon old browsers in the process, but we need to create the realistic expectation for clients that they will appear differently.
And we need to accept that Internet Explorer 7 is not, and never was, a modern browser.
