On Progressive Enhancement

When you can break free of that notion, it frees you up to explore unique interaction models and design concepts. Progressive enhancement resets the discussion around capabilities and accessibility to all. It’s a shame that it’s taken the rise of the mobile web to put this in stark relief, when the concept of PE has been around for almost 8 years.

PE is agnostic about pushing for new features or pushing features forward. If the capability exists in browser, then it’s an option. However, if it’s not, it doesn’t care. There are several things in standards that have never been implemented by browsers. Likewise, there are dozens of things implemented in browser that are not official standards (most of CSS3 and HTML5).

That said, in HTML5 we’re seeing a new situation in browser development. No longer are browsers responding to finished specs. Now, specs are responding to what has been implemented in browser. It’s not the old way of competition between Netscape and Microsoft to add new features to win on markup features. They all recognize that standards are a foundational element to their browser. Without them, you’ll fail. They instead compete on other facets of browsing: user features, speed, JavaScript engines, offline storage. The competition is still with an eye to becoming a defacto standard, but not to supplant existing standards. Even Microsoft is finally getting on board with IE8 and even more so with IE9.

In code, you write only HTML and make sure it works, makes sense from a source order perspective and could stand on its own as HTML. Only then do you start adding enhancements. This again gets back to the content and the interaction have to be completed further upstream than we currently do here.

All that said, PE fails if it’s only a front-end/backend developer endeavor. It has to incorporate IA, design, interaction and development for it to work. There is a real deficit in knowledge of how to do things better and I feel it contributes to us not really moving forward. We get caught up in things like pixel perfection and template counts and steps 1 to 4 without having a flexible way to adjust based on client/project situations.

It really doesn’t take more time to implement PE than it does graceful degradation. In fact, I think it’s faster. UX and design need to get more fully on board with the method and I’m guessing there were quite a few people who heard of PE for the very first time today. Some of the headway I made came from asking the question in the design reviews or stopping by a designer’s desk and asking “what should this do when there’s no JavaScript?”. Another approach would be “what does this do if there’s only 1 item”. You can then extrapolate that to other cases.

The big sell for different visual experiences is with the client because they expect it to look the same everywhere. The web industry has done a shit job at setting expectations with clients that pixel perfection is a valid and achievable goal. We end up wasting tons of money and time getting everything looking exact and that requires tech to put the reigns on what design comes up with or what UX proposes because IE6 can’t support it or it’ll take 10 more hours to implement it.

We had some success with it at LinkedIn with rounded corners on our container modules. In IE, they are squared off; everything else uses CSS to round them. It takes some education with the designers to help them understand the style differences, and the power and pitfalls. Group that with convincing the client; it’s a big task, but one that isn’t impossible.

As you point out, much more discussion needs to happen between UX, design, tech, and client services to help set expectations properly and to push the boundaries where we can. If only one of those groups understands the discussion, we won’t get very far.

The differentiator is where you start. Graceful degradation starts at the most advanced and strips away functionality. Progressive enhancement starts with the key functionality and enhances it based on what an agent can handle. This could be an entirely Ajax interface or multiple pages combined into one because you can use JavaScript to handle the conditional steps of a flow. In general, there is a move to use JavaScript to check these functions, using object detection. This approach does assert that JavaScript is required for an advanced experience. My mind isn’t made up on that one but it is compelling.

Another key difference is the importance of content. To do progressive enhancement correctly, you need to have content first and use that as part of the foundational experience. If you don’t know your content ahead of time, you can’t accurately determine the flow and steps to an interaction. This makes it difficult to separate out the different pieces that you’ll need as you enhance the experience.

Most importantly is that progressive enhancement is a holistic approach that includes all parts of user experience (content, IA, visual design, front-end, backend). Without all parts working together, you don’t have true progressive enhancement.

I’m sure it’s a tongue-in-cheek comment, but progressive enhancement is not just ‘arting-up’ designs. It is a holistic design and development approach to interaction design that doesn’t penalize users because of their user agent. It allows for entirely different interfaces, functionality, and flows depending on a user agent’s capabilities. Further, it’s importance is hardly limited to the mobile space; it’s just more acutely apparent in that space.