Like most web developers who publish articles, I always preach about standards and best practices (which, incidentally, makes me wonder why we don’t see more loud-mouthed naysayers who try to get recognition by writing about how all that is a big joke.) This article will be no different, except this time no one can argue about whether it makes a real difference. Today, I will be talking about progressive enhancement.
What is progressive enhancement? More importantly, why should you care? Wikipedia can define terms way better than I can, but it’s exactly what it sounds like. It’s about progressively enhancing your website where those enhancements are available, which usually refers to JavaScript.
Why Should You Care?
This whole concept came about because of the technique of “graceful degradation,” a technique to make web pages break less instead of work better. Both techniques are answers to developers cutting corners and not building things the right way from the ground up. Progressive enhancement is about doing it the right way.
I can’t say I blame anyone for it or even that I am not guilty of it. After all, you can get a site or project 90% of the way there for 50% of the time and effort. That last 10% is a high cost, low reward situation that is always the first thing to go when deadlines loom or clients make demands. Nevertheless, you can still ruin your pages for various groups of people.
While progressive enhancement technically includes cascading style sheets (CSS), I am not here to make the argument that you should write your pages as semantic HTML without a style sheet at first. It is still a good idea, though, and occasionally looking at your pages without CSS during development can show you any glaring issues with your document structure.
Adobe Flash is now more of a consideration than ever in this era of iPhone dominance. I can’t count how many sites I have not been able to view a page on my phone because it “requires” Adobe Flash. Progressive enhancement would mean that content is made available without Flash, then later “enhanced” with Flash on devices and browsers that display it.
The top offender is how developers and designers treat JavaScript. As a developer, you cannot take for granted whether or not visitors have JavaScript enabled or speculate on what their reasons are regarding it.
The problems caused by cutting corners with JS are all over, from missing content blocks (failed AJAX calls for example) to forms that cannot be submitted.
Solid Tip: Take advantage of the noscript tag. It will make your life easier and your pages more accessible.
How About Some Example?
I have been developing a nice new complete application UI from scratch.
There have been multiple instances from the very beginning that have been obvious forks in the road where it would be very easy to take the easy way out and skip “progressive enhancement,” such as with sorting and paginating table results or showing modal box pop-ups for tidbits of information.
Take my nifty pagination bar below. It encompasses the all the functionality a user could want in navigating results, and it does so without any JavaScript. That doesn’t mean I shouldn’t take advantage of JS. You should always make things as easy for users as possible.
In this case, I use the <noscript> tag that holds a Submit button. This allows the viewer to use the page select drop down without JavaScript. For everyone else who has scripting enabled, the page form will automatically submit on change.
Over the last 6-7 years, JavaScript frameworks have become popular, making it dangerously easy for people to abuse JavaScript with nifty effects and widgets that fail hard without JS, such as flyout navigation menus and accordion boxes.
A lack of proper learning is to blame. Most novice designers simply copy the tutorial for existing pieces and change just enough to get it working on their own page. If another method of navigation is provided, users can be cut off from sections of your site. This is another situation where the noscript tag would be helpful. Non-JS links could be placed inside to accommodate users.
A good menu, however, will be built as plain HTML first, and then progressively enhanced to make the user experience better. Take the Newegg.com navigation menu, for example.
Build First, Then Enhance
While we could put on some smoking jackets and have some in-depth poetic discussions around all that “progressive enhancement” means, the above situations are a simple problem. Some people will read about the topics and continue to take the quick and easy route, never spending the extra time to build up the basics and follow up later with enhancement. Usability and accessibility should come first.
As with anything in life- if it’s worth doing, it’s worth doing right.
