This is an article about how we can deal with progressive enhancement when used with real-life projects, by real-life projects I mean the big projects with demanding clients that we are all familiar with. These types of clients are mainly focused on the impact of their branding experience for all the visitors of their website. To them it does not matter in what context or where the site is viewed from as long as the brand is represented. If you combine this vision with the way that visual designers work, it usually results in the fact that the website should look the same (and give the same experience) on all browsers, connections and devices.

A project like this is usually filled with red tape and politics about specs and money. Front-end developers have to negotiate these hazards and advise their clients (and team) about using proper techniques. These techniques are critical for a fast, accessible and responsive website. A site that has little need for support and rework is cheap and without countless rework issues for IE6 we have more time on our hands to develop for the future.

By now we all know that the answer to these problems is 'Progressive Enhancement'. But, lets face reality, most of the time progressive enhancement is a bit of a utopian ideal. Let's say your client has 95% IE7 users but still wants to show off with shadows, gradients and transitions. Obviously there are ways to still use our beloved techniques, but it gets a lot harder when you have to explain to the client that the project will be expensive and time consuming.

Crossroads

In these projects we often get to a crossroad where we have to make a decision. Are we going to develop for the future or are we optimizing for the fading past of 2001? Both ways are valid as long as the choice is made wisely. Most of the time this choice is not made by (or known to) the whole team. Then the trouble starts. Who is responsible for the design decisions when it is unclear who knows what techniques are used while developing? What will happen to your credibility if you present the final templates to an unhappy client that expected gradients in IE? At that moment it's probably not so cool to tell them that -ms-filters suck right?

Tickets start to appear in the issue-tracker because the client's tester (who has the visual designs as a baseline) spots loads of bugs in IE6. I could go on and on with more situations like these. I guess at one point in time we have all been in them. You are in big fat trouble if the vision on front-end development was not chosen on time. It is vital for the project that all stakeholders are involved when this vision is spread out.

I've noticed (and I've also heard this from other developers) that many visual designers have a bit of trouble with progressively enhancing their design. In their eyes it looks more like tearing down the design to make it work in less capable browsers. Their work has obviously been done with vision and according to them, it should look the same everywhere.

Lets work together

It is our responsibility as web developers to teach everybody around us about the browser differences and the solutions that progressive enhancement can offer us to make projects ready for the future.

I think we can solve some of the issues I mentioned above by working together as a tight team. Obviously the whole team needs to be committed to their jobs and it also helps if everybody in the team knows a little bit about what their teammates do. A front-end developer for example needs to know his typography, but to be able to build templates he also needs to understand the back-end technology.

The same goes for visual design. They are 'web' designers right? So, try to understand what browsers do and why some stuff is hard and most stuff is easy. Try to crawl into the mind of a developer and look at the abstract methods that are used to build a website. Use a design tool that is component based so you can generate five pages with different content blocks on the fly. In my opinion Photoshop is for pixel nerds and generates loads of overhead when prototyping.

Think more like a web developer and work together. The front-end developer could use the designed components to recreate them in the browser. To go even further, the developer could use these components as includes in his development environment. As long as you use the correct naming conventions everything is synced up nicely.

When you know a bit more about what your teammates do, it becomes a much easier to communicate. The faster the communication is, the more time you have to document and keep everybody up to date. It is vital that you create a group consciousness that you are working on a web project. On the web everything is dynamic, the web has loads of users that browse on different devices, browsers and connections.

Think in responsive design, nothing is fixed anymore. Maybe the interface that you are building appears on someones fridge door in 2014? I'm not saying that we have to 'over' design and think of every aspect possible. It's just about being agile in your thinking process.

All team members know different things. Where one is really into making fast websites, the other might be into accessibility. The best thing to do is combine these skills and get the correct group of people together before you start a project. It is also very important to incorporate your client into the project team, make sure you work with your client and not for them. This way the project becomes nice and agile and the client will understand the choices that are made in the process.

Conclusion

As I have said before, it is vital for your project to work together closely. I think the 'scrum' method suits this nicely. Knowing a bit more about your teammates and getting the client involved are also important parts.

Next to this is the vision on front-end development. As this is such an important part of the project, this vision needs to be shared with all stakeholders. The vision needs to be written down and understood by everybody and could even be part of a pitch. To write this down, you need to know a lot about what the goals of your client are. For example; What is the target audience for this project and what are the goals of these people? In what context are they looking at the site? On a mobile in the train, or on the toilet with an iPad? Maybe they check the website on the 15" CRT in the nurses station (yes, hospitals are shabby when it comes to this :-)).

This article reflects my idea on how to handle projects. Please share your opinions because this is an ever changing subject and we could all use some fresh ideas.

In my next article I am going to try to explain something about progressive enhancement and it's background. For now read the masterpiece 'Hardboiled webdesign' by Andy Clark to get more information about the general use of progressive enhancement. Andy also writes a bunch about the mindset that you need to be a hardboiled web developer and use progressive enhancement in real-life projects.