Content Structure for Responsive Design and Beyond

Aaron Manire // January 2013

This is part two of a three part series, “Emergent Design for the Web”.

Keep it DRY

Once in a while, you may hear a software developer boast that they are lazy. They don’t like to work. Instead of laboring away on a tedious data transformation, they’ d rather write a script that accomplishes the task and can be re-used for any similar project that happens to come along. Then, presumably, they’ll lay back in a hammock, sipping a gin and tonic, while a squadron of robots attends to their household chores.

But in reality, a programmer’s work is never done. You’ll find that same self-declared slacker putting in extra hours refactoring functions and troubleshooting inscrutable bugs for the sheer satisfaction of solving a nagging problem. So, yes, programmers are not really indolent free-riders, they’re just echoing a well-established programming principle: Don’t Repeat Yourself. It’s a pithy phrase that abbreviates nice and mnemonically as “DRY”.

The problems that arise from duplication of code are numerous. The inefficiencies that come with performing the same work over and over is obvious. Less apparent, is the extra work that comes with having to maintain a system that requires editing text in multiple places for a minor addition. Worse yet, try untangling the various threads of a “legacy” system when the original designers are long gone and no one seems to know how the thing works. The DRY principle keeps things tidy and organized. You only have to change code in one place and that’s it.

Copacetic Content

So that’s a fascinating look at nerdy stuff and all, but what does it have to do with the content on my website? Well, as it happens, the content itself is a codebase. That’s right, all the chunks of words, media, email addresses and links are wrapped up in a specialized code called hypertext markup language for rapid delivery to a web browser or, perhaps, some other contraption. So, your content really is code and if it repeats itself too frequently, then it’s inefficient, hard-to-maintain code. But if your content is well-structured, it can pay dividends from one page to the next and across the Internet.

It’s no longer enough to think in terms of creating web pages. The future is already here and it’s called cross-channel publishing. Responsive design, third party display applications (like Readability or Instapaper), mobile applications, JavaScript objects, RSS readers, screen readers and even cars could potentially be used to re-render your content in unexpected ways. The goal of cross-channel publishing is exemplified by National Public Radio’s motto: Create Once, Publish Everywhere, or COPE. After struggling with weak content on the websites of hundreds of local affiliates, NPR realized that they had to adopt a new approach to publishing their news stories. The key was to create reusable chunks of content that can be shared via an application programming interface (API).

The premise of structuring content may sound a lot like database normalization. That’s because it is. Most content management systems have a database backend and, therefore, support this capability to some extent. Drupal, in particular, has been moving towards well-structured content ever since it absorbed the Content Construction Kit (CCK) module into its version 7 core release. It’s easier than ever to implement fields and structure relationships in content.

One prerequisite for structured content is the separation of presentation from content. There’s another programming principle in play here, the separation of concerns. This means keeping design-related elements (ornamental images, layout, colors, etc.) out of your content. To simplify things a bit, CSS handles the presentation layer and the content is stored in a database and rendered up into HTML for the web browser.

Content Modeling

But we’re getting ahead of ourselves. Before we dive into the database, we need to think strictly about our content and its internal and external relationships. What exactly is it that we’re talking about? This is where content modeling comes into play.

There are a variety of approaches to getting this out of our brains. One approach is to use old-fashioned paper and a locked room. Mark Boulton favors Post-It notes and Dani Nordin prefers Butcher paper. There are also a wide variety of “mind mapping” applications that can facilitate this process for individuals or groups where physical proximity is too difficult. No matter which approach works for you, the end result is the same: a rough diagram of your content structure and relationships.

It’s also possible to go too far in reducing your content to reusable chunks. Deane Barker wrote a fascinating blog piece recently on the possibility of splitting apart content down to the paragraph level. He concludes that this approach works for technical documentation but that it is too easy to disrupt the narrative flow when trying to apply this approach to other writing styles. So, let’s not underestimate the importance of striking the right balance between readability and re-use.

A rigorously structured document also opens up a different window onto the content authoring and editing process. If done well, structured content can make a content author’s life a breeze. But if done poorly, it can create a miserable authoring experience that contributors will subconsciously or deliberately resist. Unintuitive interfaces require more cognitive overhead, more expertise and more training. Staff turnover is always a major problem for organizations. So, it’s easy to underestimate the importance of taking their perspective into consideration when developing your site. A little extra effort can go a long way towards reducing inefficiencies that lead to system-wide repercussions.

Coordinate your Terminology

An essential product of the content modeling process is a shared terminology that guides your developer and designer when constructing your site. Well-crafted labels and descriptions will reinforce the goals of the site while reducing the many arbitrary decisions that it takes to implement a content structure. Content types, fields, views, blocks, taxonomies and other site elements are easier to understand, maintain and share when they have a clear name and well-documented purpose. Designers want it to look great and are rarely involved with the internal architecture of the site. Developers are focused on making sure that everything works. While there are many generic conventions for implementing a CMS, neither your developer or designer understand your content as well as you do. Your domain expertise is critical for building a long-lasting content structure.

Prepare to Maintain

But don’t expect to get everything right in an initial closed doors content modeling session. Far from it, your site will evolve over time. Prior to the launch, expect challenges to arise while implementing the content structure in development. A content migration from an earlier site or external source will probably require further modifications. After launching, you will find that your content types may need to be revised, cleaned up and re-used in places that were never considered from the outset. Revisit your content model, labels and descriptions throughout these ongoing changes and you will have a good overview of your site.

A Question of Semantics

Computers are powerful tools, but they’re still rather useless when it comes to understanding human motivations. Therefore, it’s up to us to constantly explain our intentions to them with unmistakable signposts. HTML is essentially a kind of linguistic semaphore, precisely describing what constitutes a page header and a paragraph, for example. And our ability to communicate with these machines is rapidly evolving. HTML5 includes a battery of new elements for describing the content of a page. Microformats like RDFa are another growing option. We have more options than ever for signaling the structure of content and with the rapid growth of content consumption beyond the traditional web browser environment, it’s well worth the time to plan your content structure strategically.

 

This is part two of a three part series, “Emergent Design for the Web.” In the next installment of this series, I will take a close look at implementing content structure in Drupal with an eye for usability and re-usability.

Aaron Manire

Aaron Manire

Director of Web Development

I coordinate Drupal development teams and plan technological growth, and like to get my hands dirty with code when I can. I enjoy that at Isovera I’m constantly learning new things, sharing that knowledge with others, and working with the terrific people who make our work possible.

Filed under: