One of the terms we hear a lot in web development is “progressive enhancement.” If you’re new to web development, Wikipedia defines it as follows:

Progressive enhancement uses web technologies in a layered fashion that allows everyone to access the basic content and functionality of a web page, using any browser or Internet connection, while also providing an enhanced version of the page to those with more advanced browser software or greater bandwidth.

Perhaps another way of looking at it is you introduce a basic feature such that it functions without any of the newer-ish technologies – such as Ajax – and then progressively enhancing the feature so it works a bit more smoothly (or flashier, because that’s a proper term).

Ultimately, it should improve the user experience without compromising the feature for those who don’t have access to newer technologies.

But there’s a challenge those who have been in development for a while tend to face.

Fighting Against Progressive Enhancement

For those who have been working in this industry long enough, I think we generally go through several phases as it relates to progressive enhancement and other similar techniques:

  1. We start by wanting to make everything as fancy as flashy as possible.
  2. Next, we learn we shouldn’t do that so we make everything as basic as possible and, if there’s time at the end of the project, we enhance what we can.
  3. Finally, we believe we have a level of intuition about what the user would want so we leave some things as simple as they get and we enhance other things.

Maybe it’s not like this for everyone. Maybe it’s just me.

Either way, the first step is what we definitely want to move away from, the second step is kind of the sweet spot, and third step is one from which we have to pull back from when working on client projects.

For Example

I’ve recently been working on a project in which the user needed to define ratings version certain criteria. Each of the criteria had a number of different stars such that you could rate the criteria.

Progressive Enhancement and Ratings

I built the initial version so when the user clicks on a star, it makes an Ajax request and saves the value in the back then, using some basic security, prevents the user from continuing to vote as not to skew the results.

It was fun to implement, but the problem is I ended up over anticipating how the feature should work thinking I was doing what was ultimately going to be asked.

Don’t Anticipate What The User Wants

Because of that over anticipation, I ended up needed to refactor the functionality a little bit such that it worked in a more basic fashion.

Rather than having each rating trigger an Ajax request, it’s now setup such that the user must rate each of the five criteria. Once all five are provided, a Submit option will appear and they can confirm they want to save their rating.

What’s The Point?

The point is the further we get into our careers, the more we think we think we know how something should function. Sometimes, this comes off as presumptuous – and it is – though it’s not meant to be us saying “We know what’s best.”

Instead, I think we’re taking what we’ve learned from experience and then applying it in order to go ahead and complete a feature that’s similar to one we’ve done before. The challenge, though, is no two clients are the same.

And as such, we shouldn’t presume to know exactly what they want.

Say you have two clients: Both may want a level of progressive enhancement in their application or in their site, but they may want varying degrees of it.

So it helps to clarify just how much to introduce from the outset – during requirements gathering – so as to avoid trying to anticipate a feature or a need and then having to refactor.

Sure, it’s fun to introduce that kind of stuff and it’s fun to challenge ourselves to take it as far as we possibly can, but it’s not always a great idea to do so in a client project. That’s the stuff of side projects, right?

Instead, get absolutely clear on the requirements for how something should work prior to building it. I know it sounds like common sense, but when you’ve been in the industry or long enough, you end up making assumptions that may ultimately result in more time on a feature than not had you just clarified from the outset how it should work.

An Update via Twitter

Chris Taylor was kind enough to offer some feedback on Twitter. All of the tweets are listed below in order to give complete context:

When I receive feedback like this, I’m always quick to go back and think about the way that I’ve presented my original material. Regardless of if I what I said was accurate or not, it was presented in a way that was confusing for some, so I always appreciate this kind of stuff.

With that said, I want to be clear that I’m not against progressive enhancement – obviously I’m a fan of it – but I also think that there are varying degrees of it.

For example, in the most basic case you may have a form that a user must fill out, click on submit, and then have the validation occur before saving the data. If the data is invalid, then the user will be presented with errors.

Then, on the other end of the spectrum, the user fills out all of the form elements, gets live validation feedback on it as they move from field to field, and then maybe even have the form submit once all of the inputs are valid.

But in between each of these examples, there are varying degrees of enhancement. So the point of what I was trying to make throughout the post is that progressive enhancement isn’t something that we should avoid, but we shouldn’t always go to the furtherest degree of implementation.

Sometimes, clients don’t want that. When they don’t, find that middle ground.