Progressive Enhancement And Standards Do Not Limit Web Design

20 min read
Design, Web Design, Process, Opinion Column, Discussions
Share on Twitter, LinkedIn

About The Author

Chris is a Developer Evangelist living in London, England, who writes about JavaScript development, accessibility, and all things open web. After several years … More about Christian ↬

Email Newsletter

Weekly tips on front-end & UX.
Trusted by 200,000+ folks.

Lately I have been getting bored and annoyed with people getting up in arms against Web standards and the ideas of progressive enhancement, claiming that they hold us back from creating a rich, beautiful Web. There are also claims that these tools limit us from pushing the boundaries of what is possible with today’s technologies. The problem with claims such as these is that they are based on a misunderstanding of standards and progressive enhancement and ― at least to me ― on arrogance and ignorance about what our job on the Web is. The Web is out there for everybody and is a product and a medium like any other. For example, I am a big film buff and love good movies. I also understand, though, that in order to fund great movies we have to make money from terrible ones that appeal to the lowest common denominator or rehash ideas that were successful in the past.

The problem with claims such as these is that they are based on a misunderstanding of standards and progressive enhancement and ― at least to me ― on arrogance and ignorance about what our job on the Web is. The Web is out there for everybody and is a product and a medium like any other.

For example, I am a big film buff and love good movies. I also understand, though, that in order to fund great movies we have to make money from terrible ones that appeal to the lowest common denominator or rehash ideas that were successful in the past.

Shiny New Technologies vs. Outdated Best Practices?

Dozens of case studies featuring CSS transformation and animation, and demos of the canvas element and HTML5 audio and video that “work only in the latest build of browser X,” give us the illusion of a Web that could be so much richer and more beautiful. They also lead to claims that we are stalling because of the grumpy old people of the Web who claim that we have to follow rules and support outdated technology. Actually, none of this is about stalling: it is about maturing as an industry and embracing the adaptive nature of the Web. If you start a design and try to make it work all by yourself, then you have not understood the Web and its collaborative nature.

The Mess That Is The Web

Good Web products are the result of successful collaboration. One-man armies with a limited view of the impact of putting something up on the Web lead to a steady stream of mediocre, unsecure, unmaintained and hard-to-upgrade Web products. This includes all of those websites that look terrible but “do the job,” the very big group of websites that are incredibly hard to use but still “communicate the brand’s message” and the few that are stunningly beautiful at first glance and boring seconds later. Finding a truly usable, accessible, beautiful, maintained (and easy-to-maintain) website out there is almost impossible.

The reason is that experts tend to advocate for their field of expertise as being the most important one, instead of partnering with other experts and making both a better offer and subsequently a better product.

Creating Celebrities And A Place We Wish We Were At

We look up to the “rock stars” of Web design, the people who “push the envelope,” rather than praise teams that did an amazing job of delivering a great Web product in an existing but deficient infrastructure. Great technology always happen in environments where the designers or developers have full control over the content and technology and free reign to build something great.

This is pure escapism, because in the real world you never get any of this, unless you build websites for yourself.

It’s frustrating, which is why instead of trying to change our work environment and make our mark as Web developers, we escape to Awesomeland, where everything is shiny and new and the client-side is really popping.

Returning from a conference at which you’ve glimpsed the future of CSS gives you the feeling of being part of something worthwhile. Less fulfilling is having to argue with your team to reserve time to write a plug-in that ensures your corporate CMS spits out clean, semantic HTML instead of a tag soup, or that at least allows you to add a class that gives you a style handle to work with. Now guess which in the long run will change the game? Probably both, but by fixing the underlying infrastructure, we enable cool new technologies to become relevant to the mass market.

We can build amazingly fast, low-riding cars that reach top speeds of 150 mph, but if the roads are full of potholes and crammed with cars, then they become little more than toys for rich people who own their own racetrack. The same applies to any design showcase in which texts are expected to be a certain length and products to be a fixed number, and where CSS knowledge is needed to make the website look right when you add a product.

This is not how people use the Web, and maintainers should not have to depend on experts to make changes to their websites. Websites change constantly; this is what makes them interesting and much more versatile than, say, print media.

Hollywood And Advertising Teach Us Nothing

A lot of showcases hail movie websites for having the most feature richness and visual beauty. Well, try to find websites for older movies and you will see that most are 404 errors or “Not available any more” (for example, try to find out what exactly is the Matrix, and you’ll be waiting a while). Is this the Web we should be putting our efforts into? Is this innovation? Or should we start to work as teams and add our unique talents to produce something better and more durable than what is merely pretty and what satisfies our own ideas of a great website? Isn’t the main premise of Web design something that is available to millions of people worldwide and available longer than data stored on a cheap CD (whose lifespan is approximately 10 years, in case you were wondering)?

The Myth Of Innovating Exclusively Through Technology

Know what? In most cases, we are not innovating: this is not the revolution; it has been done before.

During the first browser wars, we were in exactly the same boat, and people were building things that worked only in certain browsers, and they claimed this was the future. I am sure you can guess which browser was the worst offender and why we’re having a hard time getting rid of it now.

Yes, IE6. A lot of the websites in CSS3 showcases today, especially the animated ones, remind me painfully of the IE6 CSS expressions and page transition showcases of old. Did you know, for instance, that you could rotate text in IE5.5 with the matrix filter? The difference is that, back then computers were so slow that all of these effects looked bad; nowadays, on fast computers and shiny iPhones and iPads, they look much more impressive. While I am very happy that we don’t use a hybrid technology that comes with a boatload of performance issues and a syntax that must have been defined in a feverish dream, I am also not convinced that the “CSS3″ browser-forking that we do now to make websites work in this or that browser is future-proof either.

Innovation Isn’t About New Toys

We generally tend to regard the use of the newest technology as “innovation.” This is why you see old problems being solved with new technologies over and over again, even though they have already been solved. Pure-CSS menus, for example, were newer technology but were a step back in usability: you cannot delay the hiding of a menu and you cannot test if it will fit the screen before opening it.

For this, you need a technology that has two-way communication: you set something and then check that it worked. CSS does not have this checking mechanism; we are at the mercy of the browser doing it right. With JavaScript we have that option. We also have a sensible syntax in JavaScript; whereas CSS, with all of its -browser extensions, is slowly but steadily turning into a syntactic nightmare.

CSS has developed some great defensive features: for example, media queries, which allow different designs to be served to different screen sizes automatically, are wonderful. However, does CSS need all of these features, and should we have to wait for universal browser support, or would it make more sense to use JavaScript now in conjunction with CSS to achieve the same effect? A good CSS designer and someone with rudimentary knowledge of JavaScript libraries are all it takes. But oh no, why share the fame when we can do it with CSS3 alone?

Innovation is not about using the newest technology exclusively. Innovation also happens when you combine existing tools and make good use of them. Flints were great as spearheads for killing each other or skinning animals. Hitting them with another rock or against each other all of a sudden gave us fire. No one showed up with a lighter to teach people how it works. Instead, we analyzed what we had and put it to good use. And guess what? Flints don’t need fuel either.

The Corporate Spin On Innovation, And Its Consequences

The other thing we should never forget is that every time we innovate, some people will one way or another sell these ideas to corporate IT half a year later. Most of the time, the innovation is sold as part of a bigger software package: “Oh yeah, our CMS package Overpriced-And-Underspec’ed-otron now supports AJAX… in multiple colors!” Sadly, this also happens to be the only time when the innovation will have a real impact on the mass market.

If we really think that large corporations or end users care about what we do, we’re fooling ourselves. In the end, software and the Internet exist to solve the problems of people. And sadly, the people deciding on the best solutions are not us but rather those who only go for what’s cheapest and seemingly the most secure.

A large company that offers a corporation its software package at a fixed price, promising to solve all of the issues plaguing the corporation’s daily workflow and to train the people who work with the software are selling much more easily than us with our “We will help you understand the Web and make it easier for your employees to be more effective” pitch. Which sounds like more work for an already overloaded IT decision-maker?

The Stockholm Syndrome Of Bad Interfaces

This breeds a lot of ordinary interfaces on the Web that are painful to use and terrible to look at. The amazing thing, though, is that people love to use them. This is what they learned in corporate training, and these are the products supported and endorsed by the company.

Memorizing five convoluted steps and mechanically going through them every time is easier than finding the time to learn new things. There is a comfort in knowing how to get the results you are asked to get in a predicable way if you really don’t want to use something to begin with.

If you don’t want to be one of the people who builds the Web, then every change becomes an annoyance ― upgrading being one of them.

This is why we have outdated set-ups: not because of evil companies that refuse to embrace new technologies, but rather because people couldn’t be bothered to upgrade because no perceptive gain comes from it.

Instead of targeting the people who really prevent the Web from evolving and giving them something to consider as a great gain, we stay in our comfort zone, talking to each other about pushing the envelope and suffering from the wider market not caring.

Want to drive the Web forward? Find a way to disrupt the five-year upgrade cycle of corporate environments. Whenever you talk to the leading lights of Web design about this, you get an answer like, “This is a battle we can’t win.”

This Is Not About Technology Or Design

In the end, we deliver products. We are passionate about the Web, and we want to push it forward. The problem is that we stay in our comfort zone rather than expand our knowledge:

Designers want to push the envelope towards richer interaction and more beautiful designs with rich typography.
UX people want to make it darned easy for people to achieve their goals; and if a pattern works well on the desktop, it should also work well on the Web.
Engineers push for speed, with “best practices on performance” that are relevant to search result pages and Web apps like Gmail but not so much to content-heavy websites.
Other engineers want to build the most versatile and flexible platform ever so that people can use it without ever having to bother the engineers again (because they would have already moved on to solving other problems).
Mobile enthusiasts start to abandon the idea of Web technologies as the way forward because the technologies are too limited and too far removed from the capabilities of the platform.

A lot of these are mutually exclusive, and the latter is especially not true and only happens because we as Web developers forgot the nature of the Web: a technology stack that adapts to the needs of the end user ― data that has a clever morphing interface that gives each use case the interface it needs. That the Web began as a text platform and evolved into a rich media system is great; that we want to replace one with the other is just plain wrong or at least very premature.

Where Is The Beauty Of The Web?

Here is the real beauty of Web design: adaptability; interfaces that adapt to the needs of the user independent of their technology or physical ability. We forgot this for a few reasons:

We’re control freaks. We like to control what we do and are afraid of chaos and people messing with our products. Sure, we love to be disruptive and break conventions, but only when we can choose the font-face and colors.
We’re bitter. For years, we worked tirelessly to make the Web better and more beautiful, and our clients hardly ever cared. We were constantly promised to be allowed to build something amazing, and then our budgets were cut or we had to move on to the next project before adding that last little element that would have made it awesome.
Cheap thrills. It is easy to draw praise for “thinking outside the box” by telling people that progressive enhancement is dead or that IE6 should no longer be supported or that everyone you know has a 1920-pixel resolution. You get applauded, and people look up to you because this is exactly what they want to tell their boss every day. But does it help us? Or are we getting praise by escaping to our own world?
Frustration about the end product. We are hardly ever able to look at a live product and say, “This is cool and looks exactly as we planned.” Even worse, after a year of maintenance, we are lucky even to be able to recognize it as our work. Portfolios are outdated as soon as we put them up (I know because I am hiring people right now and cannot assess their quality of work that way).
Arrogance and ignorance. Our market, our HR practices and even our job boards clearly distinguish between designers and developers. Instead of challenging this and acknowledging “Web developers” who grasp both the user experience and the command line, we are content to stay in our own silos.

A developer who claims not to need design input is as useless as a designer who doesn’t care about the technical implementation of their design. We should encourage each other to build the best products through collaboration, and not regard each other as show-stoppers or whiners who always want it their way.

To Recap: Our Issues

So here are the issues you have to face as someone who wants to build great Web products:

The technology stack you’re asked to support is unknown. You can fool yourself into believing that everyone out there is as happy to upgrade and chase after the newest tech, but doing it just shows that it’s been a while since you had to deliver a real project.
Outdated technology is here to stay. People either are not allowed to upgrade or simply don’t care. When I watch TV, I don’t want to know how its internals work, and a lot of Web users think this way, too.
Your work will be butchered. The website you plan to build will be changed over the course of the project (e.g. the client runs out of money, which always happens), and what you do manage to get out will be changed over the years to something you never intended to build.
You can’t know everything. When you put a product on the Web, you need to make it do the following: work for humans, look pleasing, perform well, be secure, be extensible, have the option to be localized to different markets and languages, be easy to change and adapt and be cheap to run and migrate to another environment. If you can do all of that, please send me your CV… on second thought, don’t, because I’m sure you’ll be a poor team player.
You can’t rely on solutions standing the test of time. A lot of “great tricks” and “best practices” come with a massive price that gets paid a few months down the line. Many solutions that were once the bee’s knees are now considered bad practice (table layouts, for example, were at one time the bulletproof solution for flaky CSS layouts).

All of this points to a truth that I learned long ago: following standards and enhancing progressively means building stuff that will not come back to haunt you down the line.

Why Standards Matter, And What “Following Standards” Means

Working towards a standard means two things: making it easy for others to build on your work, and having a fixed point to start from. The thing about standards in any professional environment is that they work. They might not be the best or most elegant solution, but by sticking to them you are at least delivering a workable solution. This is why we standardized screws and print sizes and also why one can find boilerplate contracts around.

Products built somewhere else by someone unknown will still be maintainable if the developers followed a standard ― even if the product lacks documentation. I can still put my old lego cars together from the parts even though I lost the booklets. If I had sawed off parts of the legos or bent them to make them prettier, I wouldn’t be able to do that.

By following standards, you are signing an agreement with the people who take over from you, saying: no big surprises ahead ― I’m a professional.

That said, don’t look at standards as a “by any means necessary” proposition. Adding ARIA roles to your HTML right now, for example, would make the W3C validator complain, but the roles allow people to quickly navigate your document without your having to write custom keyboard navigation with “skip” links.

Progressive Enhancement Works

Progressive enhancement is not about supporting old platforms: anyone who says this totally misunderstands the concept. Progressive enhancement means one thing: delivering what can be supported to the right platform. This means the following:

Including everything that is absolutely necessary for the comprehension and functionality of the website in HTML. Not static HTML, mind you, but HTML rendered by a well-written back end that gets the data via an API.
Keeping the look and feel as much in CSS as possible. If you need a few HTML elements to achieve a certain look, that is not an issue whatsoever. This is actually why we have elements like SPAN and DIV. You will find standards zealots who frown upon every extra DIV on the page. Tell those people to chill out.
Enhancing the behavior of the product with a richer interactive layer. This could be CSS for hovers, transitions and animations, or JavaScript, or Flash, or Silverlight… heck, throw in Java applets if you want. As long as you add them only when appropriate, you’re not doing anything wrong.

A great pragmatic example of progressive enhancement in action is SWFobject and SoundManager. Instead of putting a Flash movie into the document and hoping it works, put a download link to the audio or video in the document, add a JavaScript and let the script do the rest. It checks whether Flash is supported by the browser and creates the right markup for the given browser to embed the audio or video only when it is able to be played. Everyone gets to see the movie or hear the sound, but only those browsers that can support a player will show one.

The main test of good progressive enhancement is this: are you offering functionality that you are not sure will work? If not, then congratulations: you have built a great Web product. Testing before implementation is as obvious as checking the depth of a lake before jumping in. There is no magic to it.

One big benefit of progressive enhancement that is often forgotten is that by separating the different tasks of a Web product into different technologies, you are able to segment the workflow and assign each part to a different team.

A progressively enhanced product can be built in parallel by the back-end team, the front-end developers and the UX and design team. If you start with the design and try to trace your way back, you aren’t working together but rather throwing work over a wall and probably causing existing code to be changed or even totally re-architected. To save time, enhance progressively and measure twice, cut once.

The product cycle should begin with a definition of basic functionality; once this is agreed on, all groups can work in parallel and reconvene at later stages in an iterative fashion and make the product a bit better every time. This also means that if there is an emergency and funding gets canned, you can at least deliver a working product. Agile, isn’t it?

Best Practices Come From Application And Iterative Improvement

To improve our entire market, we have to stop advertising everything we do as a “best practice.” Best practices should come from real products built by real teams for real clients, with all of the annoyances and problems they bring. Test cases that cover all “current” browsers are nice, but many more things can throw a spanner in the works when we build real products.

So, if you work at a company and managed to implement some cool new technology in an existing product or have stories to tell about how shifting to a CSS layout saved your client thousands of dollars, please write about those. We need tangible stories to tell clients, not tales of a bright future.

Furthermore, scrutinize every “best practice” you find in your own environment: does it really deliver on its promise? Does something need to be added to make it work in the “real world”? Write about these add-ons and fixes, adding them as comments to the original article.

Together We Can Do This

The last thing I want to bring up here is that I am tired of the debate about developer vs. designer vs. project manager. As listed above, real Web projects require a lot of different skill sets, and you would be hard pressed either to find someone who possesses all of them or to find the time to learn them all yourself and stay up to date.

It is all about teamwork, trust, delegation and communication. If we stay cooped up in our respective ivory towers and complain that we can’t work with the other groups, while pretending that we could do their jobs anyway if only people would upgrade their browsers, then we shouldn’t be surprised that we don’t get the time and opportunity to own and deliver a real Web product, as opposed to some piece of software with a Web interface.

(al) (vf)

Explore more on