Content modeling & the trouble with too many parts

Content modeling is a pretty interesting emerging topic these days. Karen McGrane (@karenmcgrane) and Jeff Eaton (@eaton) had a great conversation about this recently on Lullabot's 'Insert Content Here' podcast that really got me thinking. Spending time to more fully understand the underlying structure of the content for the site we are working on yields real benefits in semantics and fundability. By adding fields to that type of content where it makes sense will result in easier authoring, searching and displaying of that content. (For example: adding date and byline fields to a press release or price and weight to a product.) 

But we have to be careful: in pursuit of logical perfection there lies the danger of overshooting the best solution for both content creator and consumer. This results in a less-than-satisfactory experience for all. To borrow a term from the database world, we run the risk of over-normalizing our content into 'chunks' that are harder to make, manage and consume. To quote Karen, 'Goldilocks FTW': we need that in-between solution that's just right.

Rather than model beyond the basic structural elements, I'd like to suggest we leverage existing HTML tags to provide the more atomic (and enumerable via nth-child selectors) divisions within the piece of content. This will help keep the authoring and editing experience less fractured, and allow us as designers to focus on presenting that content appropriately for whatever screen size and pixel density that may  come along.

This is where I think the intersection of design, authorship and site building becomes inextricably tied.

It's been said that the 'right way' to design for the web is to design from the content out. So how do we decide at what scale we begin? How small an element of content is too small? The 'content chunkers' among us might suggest taking it to the paragraph level or even smaller in an effort to ultimately define the structure of the content. 

I disagree. 

A sentence is an idea, a paragraph a thought - but the whole piece is the unit of content. That's where meaning and substance emerge from a jumble of words. So lets stop there. The content is the story. We want to design around that. That doesn't mean there aren't other ways into that content: through a teaser, a summary or a title, for example. But the content is the whole. 

To be clear, I'm not suggesting that this kind of content atomization is what people like Jeff or Karen are suggesting, but it's come up a few times now in conversation and posts that I think it's a very real intent on some folks' part. [Karen pointed me to this post by Deane Barker on Gadgetopia - which both highlights the danger and discusses its origin in the world of technical documentation.]

But what about the structure of that content?

A story or simple page may just be a title and body copy. An H1 tag and a bunch of P tags. (Which by the way are all the structure we need to identify a point in the story or take a chunk and separate it.) But what about a press release or news story? That has a date field and possibly a byline. More structure. Or a product page? Price, weight, data sheets. Structure. In each case those elements have meaning and importance in the context of the whole. The title is more important than the byline, which may have more or less significance than weight. Semantically speaking, that is. There is quite a lot we can do simply with existing HTML structures of headings, paragraphs, figures, blockquotes and asides. We should leverage those first so we maintain the integrity of the whole piece of content. Content modeling  makes sense, so long as it doesn't go too far or become too fine-grained.

Our job as designers is to understand that hierarchy and structure, and make it visually apparent, aesthetically pleasing and intuitively easy to grasp. That's quite a task. That means we need to read the content, understand it in the context of our clients business and industry, and channel that understanding into every choice we make about proportion, typography, color and layout. 

But what happens tomorrow when the client logs in and updates the copy?

If we have structured that content properly and designed around the semantic significance of the elements of that content, then perhaps nothing more has changed than having new words appear on the screen. That's because as designers our job is to create systems of relationships, not single ones. 

But what about when the user picks up a different screen?

This is where responsive design and typography become important: scale changes perception of meaning by altering how much can be seen. Relative proportion impacts how quickly the user can understand that meaning when confronted with more or less  content in view at any given time. When our window on this content shrinks or grows the relative proportion of one element of that content to another must change. What shouldn't change though is the content itself. 

This is where I have the biggest reservations about what I've heard suggested: the notion that this structural modeling of content can make possible decisions about what to display on various devices. That's crossing the line between making programmatic decisions and editorial ones. Deciding that simply because the screen is small that the reader would only be interested in the intro paragraph is simply disastrous. 

It was said originally by someone smarter than me: there are no mobile users, only mobile devices. We can't make assumptions about level of engagement with our content based on device capabilities. Given the greater and greater level of access with alternate devices in circumstances ranging from actually moving to completely sedentary, from occasional browsing to deep concentration - we have to admit that if the content is important enough to present in the first place, we must present it equally well wherever it may be found. 

Admins & Editors are people too, you know

With the preceding  paragraph in mind, there is less impetus behind over-modeling our content. When we consider the process of creating and managing that content we find more examples where some modeling is useful but can quickly become a burden on those tasked with its care. An edit form for a story with input fields for titl and body makes sense. As do fields for price, byline, date and subtitle. But forcing the editor to attach every paragraph individually would make the authoring process needlessly complex. I know, as a certain XML editing application I've been asked to use does just that. 

Our job as technologists should be to find the analogs in existing content management workflows that give us the right combination of results yielding the structure we want without adding burden to the author. Hitting 'return' while typing in a text area can easily resulting in a <p> tag spanning a paragraph. Use the 'Nth child' selector and we can quickly identify a specific paragraph within a block of copy. Or drop in a tag representing a media enclosure the when wrapped with a FIGURE tag can be enumerated just as easily. The result is a perfectly sound way of identifying (and designing) elements of content without introducing barriers to content creation. 

Structured data and content is good. But only if we have people who are willing to work with our systems to create the content in the first place. Model as much as makes sense, keep the author in mind, and leverage existing structures to make the best design systems to preserve hierarchy of meaning and convey information. We can all have our cake and eat it, so long as we keep it all in proportion.

Many thanks to Jeff and Karen for their inspiration, and especially for the feedback on this article while in progress.

Originally published on the h+w design blog