Progressive enhancement is a logical principle. At least, for the people who understand it. It is a pretty complex and confusing principle for those who’ve never heard of it, like clients, sales people, designers, but also rusty software developers and front-end developers. When you work on bigger projects, with many stakeholders and many specialists in a team, it can be very hard to convince your colleagues about the need of a good architecture based on progressive enhancement. So more often than not, progressive enhancement is the sole responsibility of the front-end developer who gets it. This is a shame. The end result can be so much better if everybody involved truly understands the different technical and visual layers that make a website, not just the nerds.
Finding the right arguments
There are many excellent articles about progressive enhancement. Unfortunately the majority of those articles are published in the rather obscure scene of web developers. These articles definitely helped me in understanding and using the principles, but unfortunately, too often, I was the only one in my team who reads and understands them. This often means that I create a website based on progressive enhancement principles as well as I can. But the work I do is also based on static designs and old-fashioned ideas about the web. What a waste.
For every stage of a project I want good arguments. Arguments to convince the client that it’s a good thing that websites look and behave differently on different browsers. I want to be able to show the visual designer that thinking about the structure of a page will improve the end result. I need to be able to show the interaction designer that interactions can be layered. I have to be able to convince the software architect that the CMS has to be output agnostic and well structured.
And I want to get these arguments out there. First of all I want to help people like me with finding the right arguments on the right moment for the right people. When discussing graded browser support we need convincing arguments for the client, not some vague ideologies. And secondly, I think we should get these ideas and arguments out there. Progressive enhancement is not the sole responsibility of the front-end developer, it’s part of the whole project. Or like the incredible Sunpig once wrote:
Like agile, progressive enhancement is a principle, not a technique.
The coming months I will be actively thinking about these arguments. If you have any ideas or good resources, let me know.