This is my submission for this month's topic in #startYourShift, a monthly writing project on topics relevant to the Web industry. The topic for this month is Progressive Enhancement.
It's hard to talk about Progressive Enhancement without also mentioning its cousin: graceful degradation. They are similar but the subtle differences are important to your approach as you code.
So let's define them. Graceful degradation is essentially building the base product to a certain standard but then providing an alternative version or alerting the user that they may experience problems.
So what's progressive enhancement? It's the same concept, but in reverse. You set the same baseline expectation for most users, but then if you’re one of those cool people who run Google Chrome’s dev channel, you might get a little extra while we wait for the rest of the internet to catch up.
This is a dated example, but should be easy to understand. 7–10 years ago, you couldn't just put border-radius on a div and expect it to work on a good chunk of the internet. A lot of people were still using IE6 or IE7. If I really wanted to put a 5px border-radius on a div, I'd need to nest 4 divs with a transparent gif or create a background image with the rounded corners. (My hands are getting clammy just thinking about that past.)
Progressive enhancement would be looking at that div, realizing that while X amount of users may not see those fancy rounded corners, the product still works otherwise. If you're using a newer browser, you'll get to see the enhanced version. But the site works for all users.
Understanding the subtle differences between the two is important as a front end developer. Creative isn’t going to think through decisions like these when they are wireframing or designing and neither is the client.
Something I've come to appreciate as I've become more experienced over the years is that random things like this are the responsibility of your front end developer(s). We need to be asking these questions and raising these issues in wireframe meetings or design reviews. I could build Duke Medicine's site exactly to spec, but if I find out later that we needed a fallback for users without Angular, I failed.
It's not enough just to come up with a list of browsers that our site needs to support. That's obviously a good start but if you’re having to support IE8 or IE9, you're looking at a wildly different set of support compared to the current release of Chrome. When you're reviewing a comp, ask yourself if this feature needs to degrade or enhance. Then ask your design team. Then ask the client. Only then should you start coding it out.