A bit more about Content Modeling and Design Patterns

Content first! Design system first! Mobile first! Everything first! With all these competing agendas in the web design world, it’s hard to know where to start. The intersection of content and design on The Toast started with the content.

Content modeling

Every web design project should begin with some understanding of the content model: the types of content and how those content types are structured. Content modeling means defining all the little bits of content that will appear on the site separate from which pages they will appear on.

Every website should work this way, but it’s more challenging when you have a complex enterprise site with a handful—or dozens—of distinct content types. Blog sites are literally the easiest possible site to redesign (or to make responsive) because there is only a single content type to worry about: The Post.

Blogs are straightforward because it’s self-evident that nearly every page is made up up of “parts of posts.” Sure, each post has a page unto itself. Beyond that—the homepage, section pages, tag pages, search results—all of them are assembled from little chunks of posts. Even for smaller components like sidebar modules for most popular or most recent—it’s posts all the way down.

Model T

For The Toast, we defined a content model with three separate and equally important groups:

Post Attributes: Attributes define the structure of the post itself. We included fields like the title, long teaser, featured image, and body, as well as metadata like the author and illustrator, publish date, and a flag for whether or not the post is sponsored.

Post Embeds: Attributes define the post itself, while embeds are the pieces that sit inside a post. We audited The Toast to look for places where editors were applying manual formatting or might benefit from pre-defined styles. We identified a variety of embeddable widgety things, like pullquotes, editor’s notes, and footnotes, as well as media embeds for photos, Twitter, and YouTube. (This is in addition to all the structures we take for granted in HTML: headings, bulleted lists, blockquotes, etc.)

Taxonomy: The taxonomy is the “connective tissue” that defines the relationships within this network of content objects. We took a big list of tags and sorted them into several different facets. (We love taxonomy SO MUCH we wrote a whole other post about it, so if taxonomy is your bag head over there.)

Design patterns

When web designers talk about design patterns and style guides, they usually mean a modular and consistent system of styles and functional elements. Having a repeatable library of patterns and styles is a fantastic thing. But too often, designers advocate for creating these modular design components without first defining how they will interact with structured content in a CMS. (A hand-wavy “And there’s a spreadsheet somewhere!” just doesn’t cut it with me.) These design patterns are treated as something that content—unknown, undefined, unstructured content—will somehow magically just fit right into.

Teams tried that for the last decade or so with templates and pages, and it just didn’t work. And yet, the web industry is still repeating the same mistakes. (It’d be cute to say at least we’re making them on a smaller scale, but alas, it’s not true. A design system, built in the absence of a content model, can be even more problematic because it’s more wide-reaching throughout the site.)

For The Toast we defined the content model first, and used that to inform the design system. Those decisions meant that the modular design wasn’t simply something painted on the front end—it informs the way the author experience and CMS architecture is built too.

Headers and Teasers and Images, oh my

When you’re dealing with a content model that’s as simple as a blog post, it’s easy to fall into the trap of thinking that the content model and the design system are the same thing. Many of the attributes and objects we defined for The Toast might seem like styles—titles, teasers, and pullquotes are just as much design styles as they are content structures. But the content came first.

Knowing the sizes, relationships, and expected uses for content structures first makes the design process easier. Expecting content to fit into pre-defined styles and containers makes the editorial and content management process harder.

The pattern library we developed includes styles for all the repeatable patterns that are used around the site, with expected sizes and character counts for each object.

Conditional loading

In the recirc modules and in the main feed, the headline is the essential content—it’s all readers need to decide if they want to read the story. The image and teaser might be thought of as enhancements to the headline. If this sounds a bit like progressive enhancement to you, you’re right!

At smaller breakpoints, some recircs display only the titles—users get what they need but we save some vertical space by not displaying images and teasers. At larger breakpoints, the recircs show thumbnails and teasers for four entries.

We accomplish this by conditionally loading teasers and breakpoints only when we know that the screen size is wide enough to require them. Ha, we wish. No, we accomplish this using our old friend, display:none. While hiding content on smaller screen sizes is a genuinely flawed way to think about both content strategy and performance, Wordpress doesn’t make it possible to conditionally load content at the level of an individual field, like a teaser. (For more about how the backend works, Eaton has you covered.)

In an ideal world, the content model and the design system would both be implemented in the CMS in a modular structure. We pushed this project as far as we could, within the limits of WordPress and with the help of Timber. In the future, if we want truly modular, reusable systems, we can’t treat design patterns as if they’re the end goal—they’re just the start. The real benefit for maintainable, flexible, testable sites comes from implementing this modularity in the content and the CMS.