Nice like Elevators with Progressive Enhancement

Elevators are nice. They get you up and down tall buildings quickly with almost no effort. They're accessible and even somewhat social. Yet stairs remain the standard method for traveling from one floor to another. Even buildings with elevators have stairs. Being nice isn't the same as being standard. And being standard is very important.

Stairs are the standard because stairs are reliable. Stairs don't stop working when the building is on fire nor when a power line goes down. And stairs are completely intuitive; you simply walk up when you want to go up; there's no pressing the wrong button.

To the stars!

Starways are even better than stairways.
Photo by Carrington Vanston

Many web technologies are nice like elevators. Most commonly, Flash and JavaScript are used to make a user experience quick and easy. But neither Flash nor JavaScript are universally supported on the web. The iPhone, for example, has a popular browser with no Flash support. And Google's search engine doesn't handle JavaScript. While these are exceptions to the norm, it would be a big mistake to ignore them.

Fortunately, HTML is reliable like stairs. And just like buildings with both stairs and elevators, we can use HTML everywhere on the web, and apply conveniences like Flash and JavaScript in addition to HTML. This strategy is known as "progressive enhancement." A term first coined 6 years ago (approximately 1800 years ago in web time), progressive enhancement is by now unremarkable for many web designers and developers.

The idea is that you put everything in HTML first (stairs), make sure that works, and then go on to make it work better with tools like JavaScript and Flash (elevators). This seems pretty obvious, and in many places it is. Drupal's JavaScript principles, for example, start with "All pages should be perfectly functional without scripts."

Yet progressive enhancement isn't yet ubiquitous. Plenty of sites are still missing stairs. Google finds millions of sites telling their visitors "flash required" or "javascript required". And these are the sites that have at least considered the possibility that Flash or JavaScript may be missing. Many more just silently fail.

Beyond practical concerns, a lack of progressive enhancement should raise a huge red flag. While the phrase was coined in 2003, "progressive enhancement" describes how the web has always worked. HTML embodies progressive enhancement; even if you don't have a browser, you can open HTML documents in any text editor and get the content out. At a lower level, the network protocols are built around the assumption that any given packet of data may not reach its destination.

A site built without progressive enhancement should raise questions about all other aspects of the site. Do security precautions on this site similarly ignore all but the most obvious scenarios? Will the site be as incompatible with future technology (e.g. HTML 5) as it is with older technology?

Elevators are nice. But if an architect designed a multi-story building with no stairs, he'd be immediately identified as unprofessional and probably fired. Even if it's an otherwise great building, you just don't leave out the stairs; that would be ridiculous. Some day the web will similarly dismiss websites without progressive enhancement. Even if it's an otherwise great site, you just don't leave basic content or navigation out of the HTML; that would be ridiculous.

2 Comments

Great analogy! I found the last paragraph quite eye-opening: "...he'd be immediately identified as unprofessional and probably fired."

With stakes that high, it's amazing how many sites don't have stairs.

For me personally, I've had a hard time with making non-JS enable users experience the site in a clean way. I can still deliver the content, but have a hard time making it pretty sometimes (especially with image sliders).

Thanks for the article.

Thanks Jim.

Yeah, without JS, you generally have to sacrifice some usability in either visuals or speed. For an image slider for example, you could either show all the images (less pretty), or pass a request parameter with next and previous image IDs, e.g. /page/?image=3 (slower). I'd maintain that the integrity of the HTML document trumps these concerns.

Add a comment

About the Author

Scott Reynen

Lead Developer

Scott has been working on the web for about 15 years, working in a variety of languages and platforms before finally settling on the LAMP stack. He is passionate about web standards, reusable code, and building community on the web. Scott deals primarily with the implementation phase of Aten's process, mostly focusing on server-side code, though he also enjoys JavaScript and is obsessed with semantic markup.

Read More Scott's Blog Posts