How to get progressive enhancement right

It comes up on almost every project, usually later than it should. The short answer to progressive enhancement is that it is mostly a sequence of small decisions, not one big one.

Most development decisions are really maintenance decisions wearing a different hat. The version that survives contact with a real deadline is the simple one.

Why it matters

Start with markup that works, then layer behaviour on top. The teams that handle this well are rarely the ones with the biggest budgets. It rarely shows up as a line item, which is exactly why it slips.

The steps

1. Establish what you have today before changing anything
2. Scripts fail more often than people expect
3. A page that degrades gracefully never fully breaks
4. Write down the decision so the next person does not re-litigate it

A page that degrades gracefully never fully breaks. The teams that handle this well are rarely the ones with the biggest budgets. Budget a little time for it every quarter and it never becomes a project of its own.

Turning this into a decision

How to tell if yours is fine

Code gets read far more often than it gets written, and usually by someone with less context than the author had. Three things worth confirming about progressive enhancement before you move on:

• Someone can say what the current setup is without going to look
• A page that degrades gracefully never fully breaks — and you know whether that is true here
• There is a way to tell whether the last change to this helped

The point is not perfection, it is knowing which of these you have consciously chosen to skip.