In my previous entry on progressive enhancement, I illustrated the basic approach to coding design details the progressive enhancement way. In this article though, I barely scratched the surface in what I consider a fundamental aspect of the approach: working from the inside out. Now’s time to dive underwater.

The website ecosystem

Traditional web design leads you to create HTML templates that look exactly the same across some browsers, most of the time we’re talking about the usual suspects—IE6, IE7, Firefox, Opera and Safari—, sometimes this list is moderated against the statistics of the website showing which user agents are used by visitors. This approach is flawed from the very beginning, for it concentrates only on how a template looks and behaves in a specific range of visual browsers, but fails to consider a whole world of contexts in which the website will be used—to be honest, some like search engines, may be taken into account, but only as afterthoughts. The result is a website stuck in time and space that leads to increased costs and missed opportunities:

• templates created that way are too tied to the design, resulting in the need to rebuild most, if not everything, once the design changes. I’m all into realigning, but nowadays it’s still more an exception than a rule;
• browsers evolve at a very fast pace, how they behave today may not reflect how they will in the future, especially as standards support is increasing. Some choices—*kof*hacks*kof*—one made for the sake of visual consistency may become useless or, worst, completely break the website in these new versions (that’s actually what happened when IE7 was released and the reason behind all the IE8 debate );
• despite all the efforts put in trying to control the appearance in a user’s browser, there are far too many factors that come into play—some of which will never be in a designer’s hands—so that it’s impossible to predict the exact behaviour of a design once launched on the web;
• one may be striving to use semantic markup anyway, that does not help it from being transformed, reordered, glittered with ornaments that hamper accessibility and usability. Truth be told, experience proves that can have a dramatic effect on business objectives and return on investment;
• while the promises of the Semantic Web are far from being achieved, a visual approach fails to see the forest for the trees. The Web as a whole cannot be improved if each and every website uses its own set of coding practices, on the contrary sharing and working on a common set of techniques—e.g. microformats—helps move the Web forward, give birth to useful tools for aggregating–understanding–interacting with information and make each website benefit from the collective knowledge.

Don’t get me wrong, the current state of web standards does not solve all the problems mentioned above, and from time to time every designer is forced to accept some trade-offs for the sake of pragmatism. Most of the times though, better websites can be created if the approach to coding designs shifts from the purely visual–interactive level to the semantic one. Sticking to web standards and providing the best experience to each user depending on her user agent’s support of them proves to be a much better approach. That’s what progressive enhancement is all about.

Progressive revolution

A B&W canvas

The approach advocated in this series tackles the problem at its root: instead of judging a design on how it looks, let’s first understand what it means. The fundamental difference is that meaning is universal, whether you’re looking at it through your desktop browser, reading it printed on a page, listening at it through an aural browser, etc. Universality means virtually no barrier to understanding content through whatever tool is used to process it, therefore accommodating all audiences, even those that were not put on the table first.

On the Web, meaning is conveyed using the HTML language. Most elements and attributes defined in the language are used to describe the meaning of information, not its look and feel. Therefore, the first building block of progressive enhancement is getting the HTML right; by that I mean knowing when to use which element/attribute and how to combine them effectively.

Bring colors

Let’s face it, meaning is a humble endeavour, but it does not a successful business make. Good design does; colours, shapes, lines, spaces, textures and values are the elements that help a website (and the brand behind it) stand out of the crowd. Not surprisingly, in most web projects, visual design is all the rage and plays a major role throughout project completion.

Commonly called the presentation layer, the second building block of progressive enhancement is where things start to get complicated. That’s here one achieves the visual look of a web page using a set of cascading stylesheets (CSS). The language itself is easy to understand for anyone who’s familiar with layout and typographic terms and allows one to control just about every aspect of the page. So why does it get complicated? First, because browsers, due to major differences in how they are implemented, have all varying support of the CSS specifications: from full support to no support at all, even supported features may vary from one browser to another. Second, because the CSS specification moves at such a glacial pace, designers eager to create complex designs are starving for advanced layout properties to be implemented in those browsers. In order to create these complex designs, one is faced with having to sacrifice meaning by introducing HTML elements and attributes for the sole purpose of look and feel.

Progressive enhancement is all about letting go of one designer’s creative thinking, getting rid of constraints and starting to espouse the web for what it is: a medium in which one can’t control the exact appearance of web pages, where experience primes over anything else. The beauty of it is that it’s achieved without sacrificing meaning, using as much standard CSS to control page layout as necessary. Yes, that means not everybody will see the same thing: some browsers don’t support alpha transparency, others won’t render rounded corners, multi-column text is still restricted to Gecko–Webkit rendering engines, only Opera rocks when it comes to styling paged media; these are not reasons not to use them, is it?

That is generally here that one has to fight some rebuttal against progressive enhancement. However, if the experience on a website is well thought-out—pages load fast, text is readable, navigation is clear, ... in short the designs stands out of the way—there’s no reason whatsoever a visitor will complain of missing visual ornaments, actually it would be surprising she even knows there are missing ornaments. And if she knows, it’s actually because she experienced the website through different browsers, in which case her responsibility is to choose whichever browser seems best for her needs.

Make it pop

The third building block, aka the interaction layer, constitutes everything that revolves around behaviour and is generally implemented with a combination of styles and scripts. Behaviour goes from the simple mouse hovering effect to the drag-and-drop used to add products in your basket. When it comes to interaction, most of the times it becomes an accessibility/usability issue. Why your popup menu just does not pop when users rely on their keyboard to navigate page? How does a low-vision person drag a product into her basket if she’s unable to precisely coordinate visual and motor nerves? Though cross-browser compatibility is not always easily maintained, it is much less an issue compared to these challenges.

An acceptable solution of sorts has been used for quite some time now, in the form of providing a back-end alternative to each complex client-side behaviour, make every action accessible both through keyboard and pointing devices, or hide complex interactions altogether. As a matter of fact, the amount of work to achieve all this may double the time a non-interactive equivalent would’ve taken; and even if disabled users gain full access to your website’s content, they fall back to a simple request-response paradigm, as if there was no interaction layer at all for them.

This issue is far from being solved yet, but there are encouraging signs that it will change in the near future. The actual problem lies in the first building block: HTML falls short of semantic equivalents when one needs to design interactive widgets, such as trees, toolbars, date pickers, modal boxes, tabbed interfaces, and so on. How can a user agent process such widget if it’s unable to understand its nature? HTML5, the upcoming standard for semantic markup has addressed this issue but has already shown its limits. A promising solution comes in the name an upcoming W3C Recommendation, WAI-ARIA, which has just been advanced to the Last Call Working Draft level—that announcement was immediately followed by the release of Safari 4 which fully supports ARIA right out-of-the-box, as is the case for IE8, Opera and Firefox.

An egg that’s going to hatch

It is hard to write on such topic without producing examples, as it is my intention to write subsequent articles on concrete usages of progressive enhancements and their benefits. On my way to build more advanced examples, designer Andy Clarke, along with developer Brian Suda, launched TweetCC. Besides being a really interesting web application, TweetCC is also a proof-of-concept on progressive enhancement, or progressive enrichments as Andy’s used to call it. Read on the full details over at his blog.

The next post on this series will focus on bringing the interactive layer back to disabled users.