Content is the guideline

Responsive web design has shaken the web service industry up, designers are throwing out pixel-grids like they’re going out of fashion and clients are busting-out super-hero stylised HTML5 logos in every meeting. Probably.

In the short history of commercial web development the design and build process hadn’t changed much but in recent years our mobile phones got smarter, Ethan Marcotte showed us the power of the media query and flexible design advocates started yelling “I told you so!”. Keeping up with the RWD tips and techniques train has become a lifestyle choice with an ever-growing reading list.

Responsive web design is not all new territory though, as John Allsopp said in the Dao of web design, “It is the nature of the web to be flexible, and it should be our role as designers and developers to embrace this flexibility”. The issue was that most of us were viewing our creations through a fixed frame and we didn’t always possess a range of Internet-enabled devices, so designing a site header, footer and home page on a fixed canvas produced predictable results. It’s always been our responsibility as good web citizens not to hand over a skeleton site with the keys to a CMS, it was just easier to do so.

The design process on our projects we start now should have little resemblance to those of a few years ago. I think most of us are used to creating mock-ups without possessing content but we shouldn’t deliver PSD promises or work to a theoretical sitemap, we’re problem solvers and making assumptions is anti-responsive design; there will be plenty of times when things just don’t work.

Content is more important than the design and code but without rules for what content goes where and when the design and development craft will start to come apart, causing frustration for both parties as the client hits boundaries. Gathering and forcing content into strict moulds combined with the rush to fill an agreed quota will only aggravate relationships between the two sides and introduce sloppy bodges to plaster over increasingly large cracks.

The industry shift to responsive web design is forcing us to try out new project strategies to find something better than the ‘template-n-fill’ approach of old. Although there is no authoritative answer on the best process one thing has become very clear; we can only design interfaces, user journeys and solve problems based on good content structure.

You can create good experiences without knowing the content. What you can’t do is create good experiences without knowing your content structure. What is your content made from, not what your content is.

There are few projects where content is provided up-front but I think that most pages can be divided into one of three fundamental building blocks: presentational, content listing or single content piece. Using a tool such as Gather Content it is easy to define the types of content that make these blocks which in turn should help define the organisation of the sitemap. Following this it’s useful to delegate responsibilities for managing each content section and calculate the pre-requisites they’ll need, printing out a binder of required content will literally add weight to the importance of content strategy and make everybody’s work less assumptive. Setting the client’s expectations early-on for how much work they’ll need to do will enable both parties to set priorities and reduce friction as the project progresses. Win, win and win.

Constructing hierarchical, well-structured documents that can be re-flowed to suit a number of contexts is new and it is hard. We don’t have the experience or tried-and-tested tools to categorically state what will work, we can only decide in-browser and not in Photoshop. We know a lot of our tools are inappropriate–we can’t visually re-order a page as we’d like quite yet–and we shouldn’t theorise about the capabilities of devices we’ll see in the near-future. Content is the only constant and it is not appropriate nor future-proof to think about anything else first.

comments powered by Disqus

A photo of Matt Hinchliffe

About Me

I'm a 29 year old web developer building new stuff at the Financial Times based in London. I specialise in crafting scalable, performance-driven code, tackle accessibility issues and keep an opinionated interest in the latest hotness. I like my tea robustly brewed, white and with no sugar, thanks!