Jason Santa Maria - A Real Web Design Application

Prominent webdesigner Jason Santa Maria wrote an interesting article the other day about the pro’s & cons of current webdesign tools (such as Photoshop, Fireworks, etc…) and what a true webdesign application (if it were created today) would need. It’s an interesting read, so check it out at:

http://jasonsantamaria.com/articles/a-real-web-design-application/

The author raises a lot of valid points, notably the huge disconnect between designing static pixels in Photoshop & co. and the crafting of HTML markup, CSS styles and how to resolve cross-browser inconsistencies. Jeffrey Zeldman wrote a similar article a while back and makes the point that hand-coding HTML/CSS isn’t going anywhere anytime soon. I’m of a similar opinion.

In my current workflow, I use a myriad of different tools when designing for the web.

Some of my favourite webdesign tools

After wireframing I’d hop into Photoshop, design all the pages (keeping browser capabilities/limitations at the back of my mind at all times) and then use Layer Comps to review the flow of the site through all the different pages. Some web-designers have begun skipping Photoshop altogether and designing straight in the browser, but I’ve found that a hybrid solution is still the best option for getting the most out of your designs.

Once the client is satisfied with the static comps I fire up Coda, write the markup to be as efficient and semantically valid as possible. With the markup done I hop into CSS, boot up all the virtual machines and alternative browsers I’d like to support and then I’m off for several hours of writing a few lines of CSS, Cmd/Ctrl-S, and then tabbing between browsers while pressing F5 to make sure my layout works.

This is a hugely time-consuming process and is usually the cause of great frustration among beginning web-designers (or designers used to the consistency of the Flash platform) – but for all its faults, it’s still the best option. All the WYSIWYG (What You See Is What You Get) tools out there either sacrifice flexibility, browser compatibility or cleanliness of the markup. Or, in the worst case, all 3.

Writing semantic, search-able markup is one of the most difficult and multifaceted jobs out there. Most hand-coders even find this to be a difficult task, weighing the different semantic options, and choosing between either making alterations to the original design, or sacrificing markup brevity to stay true to the design’s visual complexity (i.e. adding more divs). For a machine to be able to do this, it would need not only to understand the different design elements, but the content you’re designing for as well.

If I was designing such a piece of software, I’d make it work as a block-based design tool: in the design phase, you just drag & drop all the different “boxes” onto a canvas. The design remains mostly static until you come to the export phase. Then your task would be to go through each block, assign a type to it (be it a div, section, header, footer, aside, whatever), give it an id or a class-name and then change the nesting order of the tags (within reason) while the rendering engine attempts to refactor the page’s CSS to work with the changed markup.

Of course, taking browser inconsistencies into account this becomes an almost mind-bogglingly complex task for a computer to handle. With HTML/CSS, to achieve any kind of style or effect there are as many options and techniques available as there are webdesigners and webbrowsers.

To create a simple header some would use 3 divs and an h1, where others could use just a single div, an h2 and a nested span tag. And that’s just the markup, adding the myriad of possibilities CSS offers the potential amount of ways you can go about to achieve a certain style or look become infinite. Any webdesigner worth his salt will know at least 3 or 5 different ways to accomplish something in CSS. He’ll try one way first, finds it works in most browsers except in one instance, and then tries the two other coding techniques until he finds something that yields the most predictable cross-browser results.

Because of the cascading nature of CSS, almost every single situation is unique and there is almost no way of knowing beforehand which technique will yield the best results, except maybe years and years of experience. Software could never be a full substitute for something like that.

As long as our markup is critical to our client’s business needs (S.E.O. is 80% about having good, clean markup), and web-browsers continue to display subtle (or not so subtle) differences we can never in good conscience use WYSIWIG editors. Perhaps one day, when all rendering engines adhere to the same strict webstandards (or a single engine gains such market dominance and quality that all others would strive to emulate its behaviour) such a design tool could become a reality, but until then you’re still better off learning to code by hand.

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:

A plain-jane website

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.

Wait, what's all this then?

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?

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.

Some of the techniques you might use to enhance the site.

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.
• Etc…

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

Managing expectations

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?

Addendum:
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.