When the word modular comes up in a conversation about web design, it’s usually in regards to the code. Object oriented programming on the backend, separating structure, presentation, and behavior on the front end, or perhaps the reuse of certain visual patterns like buttons across the site.
However, if we’re going to spend some time talking about modularity in web design our first stop, like everything else web design, should be the content.
Some time last year I caught a video of a presentation by Karen McGrane on adaptive content. I’ve since caught other videos of the presentation and read her book Content Strategy for Mobile. I highly recommend both video and book.
They address how the way we create content needs to change so it can better adapt to different devices and conditions. Much as we’re learning to be more modular in our design and development. we need to do the same with the content our sites are built around.
Why Modular Content?
For the same reasons we want other aspects of our design to be modular. It will allow for more flexible content that can be arranged in a variety of ways to best suit the given conditions. Modular content will scale better and be more maintainable and reusable.
An important consideration in this discussion is the understanding that we don’t need to present the exact same content in the exact same way everywhere. We don’t want to remove information on smaller screens, but we don’t have to present it the same way.
We can hide details until requested as long as we include those details. We can present information in a different order or different combination. All the information should be present on all devices, but it can be arranged and combined in different ways.
How we do this is what the details of adaptive content are all about.
Once again let me recommend the videos of Karen’s presentation and her book. The videos will only cost you some time and the ebook will set you back $9. Most of what follows comes directly from the book.
The key to helping our content better adapt is to give it more structure. The ultimate solution is to break our content into ever smaller chunks and then use meta data to structure it for greater flexibility and reuse.
It’s similar to how we might create more classes in our css that we could add and combine for different results on our html elements.
Karen offers 5 elements of adaptive content
- Reusable content — multiple versions of the same content for different contexts
- Structured content — more and smaller chunks of content
- Presentation-independent content — raw content without formatting
- Meaningful metadata — that describes the content for easy querying
- Usable CMS interfaces — a system that allows us to do all of the above
Let’s walk through each of the above in more detail.
Content written for one context doesn’t always work well in other contexts. For example an image that communicates something through details easily seen when viewed in a widescreen browser loses it’s ability to communicate those details when those details are squished on a small screen.
In this case it’s not the specific image that’s important, but what we’re trying to communicate with it. If the image can’t convey its message when small, perhaps a different image or a line of text could do the job.
It’s ok to use alternate content. It’s the experience and the communication that needs to be equal. If a table doesn’t fit on a small screen, maybe a chart or graph could present the same information.
The words we use may also require change. The page titles/headlines we write often serve multiple duties. They’re the main headline of the page and they usually serve as the anchor text in links pointing to the page. A title that can be easily displayed on a widescreen browser can easily get cut off on a small screen.
When it comes to text we can also create variations. Instead of a single product description on a category page we might create 3 versions, small, medium, and long and choose which is best given the context. We can do the same for page headings and titles and various other chunks of content.
More structure leads to more flexibility. It’s the foundation of adaptive content. Instead of one all encompassing blob of content we should lean toward several meaningful chunks. More and smaller chunks of content provide a means to better combine our content in different ways.
There’s no single structure that will work for all content. The structure will be dependent on the specific content, site, and audience and will require better content modeling.
Content modeling is about defining different content types and how to chunk the content that belongs on these content types. The goal is to create discreet content objects that are broken out from the whole to be stored separately.
Content modeling should offer:
- Content types — Is the content an article? An image gallery? A video?
- Attributes — What content objects are needed? Heading? Text? Attached media?
- Data limits — what limits are set on each attribute? Is a specific format needed?
- Relationships — how are different content types connected? Can attributes be shared across types?
The primary content type leads the design. Instead of thinking in terms of pages, content modeling suggests we think in terms of content packages. It has a flexible base and a variety of structured objects that can be combined in different ways for different uses and contexts.
You know to separate structure from presentation and behavior. We also want to keep the raw content separate from all of these. As soon as we start adding markup to content in the database we make the content less flexible. It forces a certain presentational structure. Does something always have to be bold or italicized? Will it forever be a red or blue?
The meaning of content shouldn’t be described based on how it looks. To create more modular content we need to separate the content from it’s form and that means no more rich text formatting and no more WYSIWYGs, which is probably music to the ears of every designer. WYSIWYG editors encourage formatting to be embedded with content.
Defining structure and priority through visual formatting is fine when designing for a single platform, but it doesn’t work well when designing for multiple platforms where we may want and need different visual formatting. This isn’t to say we shouldn’t show priority visually. We should. It’s that we shouldn’t define a single visual style for the priority of content.
Better is to define structure and priority through meaningful metadata and then style it later, after it it’s retrieved from the database. The content is stored in its raw form and the meta data describes it.
We can later query the database for specific meta information in order to present the content how we want. Different platforms can be developed to present a content package based on different combinations of metadata.
Meaningful metadata helps use separate content and presentation.
I hope much of the above has been preaching to the choir. You may not have thought about content in this way before, but I would think you buy into the ideas of modularity and can see the possibilities for combining and reusing content this way.
To make this happen we need a CMS that enables us to chunk content and structure it for reuse. We need a system that makes all of the above easy not only for us, but for clients as well. We need an interface that not only provides an easy workflow, but one that encourages everyone to spend the time and effort to chunk and structure and describe content.
Today’s content management systems aren’t so great at doing this. In fairness, they would have a hard time predicting our exact content types and needs.
The CMS we want is one that provides easy customization of its interface and provides independent systems for:
- Creating and editing content
- Storing content in a defined data model
- Displaying content in the presentation layer
- Publishing and delivering the content to the user
Providing independent systems for the above decouples raw content from its presentation and pushes decisions about how to present the content to later in the process. It doesn’t couple content and presentation in the database.
For the moment it’s probably on us to either create a custom CMS for a given site or customize one of the existing CMSs we would ordinarily use. I’m most familiar with WordPress and much of what we need can be done with some customization.
WordPress lets you to set up post types with whatever fields you like. It allows for additional custom fields and also provides some predefined post formats. Many plugins take advantage of these capabilities to create unique content packages. Think about image galleries or event calendars.
Karen points to Tumblr which predefines a variety of content types such as images, quotes, chat transcripts, audio, video, and links, in addition to the standard blob of text. Supporters of Drupal always point to it’s modularity as a reason for using it and I would think other systems have similar capabilities.
Perhaps we’re not that far off from the CMS we need or at least the ability to bend the current crop of CMSs to our needs.
What I mostly hope you take away from this post is the general idea that our content needs to be modular just like our code and the visual patterns we use across a site. To make our content more modular comes down to storing it in smaller chunks and structuring it through meaningful metadata.
This additional structure will allow us to combine content packages in a variety of ways. It’ll allow us to choose the most appropriate content objects and present them in the best possible way for a given device and context.
At the moment our current crop of content management systems aren’t set up to help us create adaptive content by default. Many can come close to what we need if we’re willing to put in some time customizing them. Hopefully in the future the systems themselves will be built so anyone can customize the interface to suit his or her needs.