Pulling Back From Progressive Enhancement

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.

8 Replies to “Pulling Back From Progressive Enhancement”

  1. Hey Tom,

    Although I totally agree with your conclusion, I do think you’re discussing whether seasoned developers make too many assumptions or not.

    As I understand it, the progressive enhancement that’s lately being discussed is a more technical advancement of the mobile-first philosophy, meaning that the website should first get the critical path (the necessary basics) to the client as fast and best as possible, and only then enhance everything where it makes sense, up to the optimal version of the website. The goal of this being that a mobile user does not need to wait 10 seconds just for your cool animated logo to load before he can interact with the site.

    So, to my understanding, the title of your post let me make assumptions about the content of your post, which turned out to be false, again proving the point you’re making in your conclusion! :D

    1. Although I totally agree with your conclusion, I do think you’re discussing whether seasoned developers make too many assumptions or not.

      You’re right – that’s really the crux of the matter. The longer we’re in the industry, the more assumptions I think we tend to make on behalf of our clients.

      We think we know what they want when, really, they may very technically savvy and know where they want to draw the line with certain features.

      As I understand it, the progressive enhancement that’s lately being discussed is a more technical advancement of the mobile-first philosophy, meaning that the website should first get the critical path (the necessary basics) to the client as fast and best as possible, and only then enhance everything where it makes sense, up to the optimal version of the website.

      Agreed. I think it’s been grouped in with the mobile-first philosophy though it definitely existed long before it came along.

      As far as the enhancements are concerned, I think there are degrees of enhancements that can be made and finding that “happy place” of enhancements that satisfies the requirements and also makes our clients happy and gives the users the easiest time with a given solution is key.

      We can over engineer a solution and that’s what I want to avoid.

      So, to my understanding, the title of your post let me make assumptions about the content of your post, which turned out to be false, again proving the point you’re making in your conclusion! :D

      I’d say that it’s almost like I have some sort of strategy when, in fact, I just push keys until something happens on the computer screen that seems to look like it makes sense :).

  2. Well, I get the impression that you’re rather talking about iterative design, not progressive enhancement.

    Iterative design is when you as a developer start with something basic, get feedback, and only implement the finer details after having evaluated this feedback.

    Progressive enhancement is when you build your website so that it gets loaded in several layers, first focussing on the bare minimum that is necessary for it to be usable, and then progressively enhancing the individual elements of the site to support more modern or visually appealing aspects.

    But I might be wrong, I constantly mix and match terminologies anyway… :)

    1. Well, I get the impression that you’re rather talking about iterative design, not progressive enhancement.

      You’re not wrong — the thing is, I think we are iteratively introduce degrees of progressive enhancement :).

      I’m probably getting way too pedantic for my own good at this point.

      Progressive enhancement is when you build your website so that it gets loaded in several layers, first focussing on the bare minimum that is necessary for it to be usable, and then progressively enhancing the individual elements of the site to support more modern or visually appealing aspects.

      Right on! But how far do you go with said enhancement? That’s really all I was trying to get to – that is, I think you can enhance things too much for a client and then have to back off a little bit.

      Then again, I could be totally off base here. Maybe something has progressive enhancement or it doesn’t. I tend to think of it otherwise, but that doesn’t mean I’m right and that I need to adjust my perspective :).

  3. Hi Tom,

    I certainly believe we overdevelop now. All the frameworks and js libraries and AJAX have gone to our heads. Many of today’s websites barely load properly on quad core computers. There are up to sixty tracking and service scripts run on bog-standard consumer sites.

    Have we as developer gone stark raving bonkers?

    I guess it’s the entry of the marketing people. While I’m not fan of Google’s invasion of privacy, their insistence on a faster loading internet is almost all that stops the whole monolith of web technology from toppling over from its own weight.

    1. Hey Alec,

      I do agree that there’s a lot of over-engineering making the rounds.

      But the problems that you share as examples are rather caused by the lack of progressive enhancement.

      One of the sites I often cite as example is the one from Filament Group: https://www.filamentgroup.com/

      If you open the site in your desktop browser, you’ll notice that it is loading real fast.

      But when you now go to your smartphone and open that same website in your mobile browser, you’ll be surprised to see that it is just as fast on mobile. This is progressive enhancement done right. On the first page load, it will only load the bare minimum critical path. Everything else is loaded asynchronously after the page has displayed, and is then cached for the next page request.

      The good folks at Filament Group share all of the tools they use to achieve this astounding feat through their GitHub repos: https://github.com/filamentgroup/ .

      So, while over-engineering is certainly a problem that can slow your websites down, progressive enhancement certainly is NOT (well, provided you do it right, of course).

  4. Let me start off by saying that I believe that progressive enhancement does have it’s place. I believe in what it sets out to accomplish. But it, like frameworks, libraries, plugins, and everything else we use as developers, has a specific purposes.

    Like Alec Kinnear and Alain Schlesser get into in the comments above, it is sad that most sites don’t know how to wield the tools of their craft well. We should be vigilant in what tools we select to use and surgical in how we apply them. Progressive enhancement isn’t any different.

    For me, it all comes down to being wise enough to step back and reflect on what you’re building. It should be relatively simple to make most blogs and websites progressively enhanced. But if your building a highly interactive app / site or a single page application, from my experience, you’ll spend inordinate amounts of time trying to make it progressively enhanced when the app / site you’re building fundamentally requires JavaScript.

    A map based app is a great example. Considering that you cannot even show a map without JavaScript, is it even worth your time, and perhaps your client’s money, to make an app like that progressively enhanced if the core part of your app cannot even be rendered without JavaScript?

    1. I’d say we should aim for more simplicity, Michael. Almost anything can be rendered with straight HTML and CSS. We should use technology to enhance, rather than as an end in itself. Coding a fallback position (if you make that fallback position simple enough) shouldn’t be that big a chore. As you wrote, layered/granular progressive enhancement makes hard tasks bigger than they already are.

      Indeed always ask yourself is it possible to do what you are trying to do with a far simpler and higher performance solution (faster loading and less processor intensive), closer to the base languages of the internet (HTML and CSS).

      In an analogy of technologies, we recently watched Ben Hur (1954) and Spartacus (1960) again. We were amazed at the quality of the special effects and the CGI in that epoch of movie making. Of course the mystery was that many of the effects were done live on camera. Moreover as the actors and director were not relying on special effects, the text and acting were a factor of five better than anything modern we’ve seen. In big budget films now, CGI has gone full circle and directors are striving to shoot as much as possible on camera. CGI for CGI’s sake just diminishes the experience and give the whole film a linger fake taste.

      We should focus on the final experience and not the toys in between.

      We arrive at the same destination by different routes.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.