Responsive web design has shaken the web service industry up, designers are throwing out pixel-grids and clients are revealing super-hero stylised HTML5 logos in every meeting.
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, from the year 2000:
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 good enough 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, we’re problem solvers and making assumptions is anti-responsive design; there will be plenty of times when things just don’t work.
Gathering and forcing content into strict moulds, or causing a rush to fill an agreed sitemap will only aggravate relationships between designers, developers and clients and introduce sloppy bodges to plaster over increasingly large cracks.
The industry shift towards responsive web design is forcing us to try out new project strategies to find something better than the “template-and-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 categories: 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 different screen sizes 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, with users and not in Photoshop. We know a lot of our tools are not powerful enough–we can’t visually re-order a page as we’d like quite yet–and we shouldn’t theorise about the capabilities of browsers 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.