Wall-papered websites

In my day-job (Senior Designer at Three Sixty) part of my role often involves styling websites-in-development using CSS. Often, I don’t begin this process until all of the markup has been written and labelled (with the relevant classes/IDs) by the development team — I tend to think of waiting for this to be completed as “not wall-papering until the house is built.”

More recently, I’ve been finding that client-demands often push the boundaries that separate the stages of a website build. In short, we find ourselves receiving requests for new functionality or content additions to be made to a website mid-way through a build. Away from the obvious issues (budget/timescale interference) this can cause what I call the “wall-paper effect.”

In CSS, the idea is to cascade styling rules that correlates with your markup so that you have to do as little definition as possible. For example, if you know that all of your text is going to be red, you define that once and let it cascade down through all of your rules, as opposed to defining it on every class or ID.

This isn’t laziness, it’s efficiency which both developers and browsers alike will recognise and laud with glee. However, in order for it to work effectively, cascading styles can only really be applied if the markup is all in place.

Think of markup (HTML, PHP etc) as the bricks and mortar of a website. It’s the foundations, the walls and the layer/s of plaster too. It is the structure and the layout that holds all of the rooms of the building (website) in the right place.

The styling (CSS) is the decór; the carpets, the furniture, the fittings – and the wallpaper.

As a designer, if I know the number of rooms (layout) and what their main purposes are (content) then I can design the wallpaper (and the carpet, the fittings and all of the other details) to suit those purposes best. As a designer who appreciates web-development, I will also do this using as few CSS rules as possible.

So, when someone jumps on the project and decides there should be a new courtyard in the middle of the house and three more rooms on an additional storey accessible only via rope-ladder…well, it creates problems.

In CSS itself, the wallpaper effect manifests itself because there are now styling rules which apply to elements added after the initial build. Because they have been built beneath that layer of wallpaper, we now need to rip a section of it off and paste a new—potentially different—sheet to cover the gap. You end up with patchwork code covering awkwardly bulky markup.

Now, any developer worth their salt will tell you that cleaning up code (sometimes called refactoring) is part-and-parcel of the job. Once a project has been signed-off, developers will want to run through all of the code and ensure it’s as neat and tidy as possible. Not only does this help web-browsers and search engine indexers, it also helps any other developer who might need to delve into the work at a later date.

However, refactoring should figure as a part of the budget for a given job anyway; and will usually be a minimal fee included as part of the wider project. If your additional mid-build requests mean that refactoring takes much longer (and therefore costs more) you shouldn’t be aghast when a revised price is mentioned.

Finally, I should probably mention that the wallpaper effect applies to more than just one iteration of your website. If we continue using the building analogy, imagine this: that huge mansion, with the new courtyard you added midway through the construction, is your website displayed on a large, desktop monitor. Well the laptop-version is only a detached house, so that courtyard needs to work in that building too (it might mean making it smaller, or moving it somewhere else). Oh and don’t forget the tablet-version of your website either, that’s only a semi-detached property so your courtyard might need to disappear altogether on that one. And smartphones? Well that terraced house definitely won’t have space for the courtyard, but you might still need bits of it to move into other rooms.

The point I’m making is that modern websites are usually responsive, and the number of breakpoints in your styling will mean that any new additions you make midway through a build might need to be organised across multiple versions, most often in different ways.

So, if you want your website to be delivered on-time and within the initial budget, ensure that your designers have everything they need before they start the build. Get them to list everything they need and agree on what needs to be delivered, by yourself as much as by your designers, before a build begins.

Otherwise you’ll have no one to blame but yourself when your visitors notice the awkward annexes and patchwork wallpaper.

Show your support

Clapping shows how much you appreciated Steve Pannett’s story.