Content Blobs vs. Chunks: A Real Life Example

For someone who has to try to explain this division every day to clients who don’t understand why they “just can’t make this font different and tweak the color a little bit,” the distinction provides a lot of good, simple reasons why clients should turn over as much of the style over to the developer as possible.

Andy Welfle
Content Strategist

I’m loving this article over at A List Apart that talks about the battle for presentation control between a web designer and a web content creator. For someone (like me) who has to try to explain this division every day to clients who don’t understand why they “just can’t make this font different and tweak the color a little bit”, it gave me a lot of good, simple reasons why clients should turn over as much of the style over to the developer as possible.

This is why I am a huge advocate of Markdown. When I compose in Markdown (which I am doing right now), I am just seeing plaintext. Yet, I can add links, lists, bold text, italics, and all that HTML formatting goodness.

It’s hard to convince a client, however, that we’re taking control of the content’s presentation out of her hands for her own good. Why wouldn’t she be able to change the font size, or make it purple, or switch it to (shudder) comic sans instead of the very nice Proxima Nova-centric stylesheet we designed? After all, sometimes she has content that needs to “pop” and draw attention to itself? And ultimately, she doesn’t care about the integrity of the design and styles as much as we do.

The onus is now on us, the content strategists, designers and developers, to identify the intent behind why the clients wants to change colors and font sizes. Is it because she wants to put in subheads? Great! Let’s style some H tags. Or is it more specialized: Does she want to call out a recipe or a book title?

That’s why Karen McGrane, the ALA article’s author, advocates for “chunks, not blobs” of content. I’ve seen this before in a talk by Sara Wachter-Boettcher, my content strategy hero, in her presentation at the Responsive Web Design Summit this year.

Chunks? Blobs? What’s the difference?

A “blob” is, basically, a consumption page that’s just made up of a big ol’ WYSIWYG field blob — you can type, mess with the text, insert a photo or two, and — BOOM. Publish. That might look something like this educational resources page on Fort Wayne Airport Authority‘s site we created:

Looks nice, right? It’s a list of flight-related books, both fiction and non-fiction, categories in various grade levels.

Trouble is, it took the client forever to enter and get to look right. First, they had to:

  • Create separate listings for fiction organized by grade level, and non-fiction entered by grade level
  • Enter the Book title and author
  • Italicize the book title
  • Link the book title to the appropriate link

We quickly realized this left a lot of room for inconsistencies and error. What if the client made an ordered list instead of an unordered list? What if they spelled it “non-fiction” in one instance and “nonfiction” in another? Or what if they overlooked a title and didn’t italicize it?

(This isn’t to say we don’t trust our clients. Our contacts at FWA are some of the best clients we’ve ever worked with. But they’re busy people! They don’t have time to worry about making this page look good. That’s our job.)

We got to work. We came up with something chunkier like this:

Not only do the colors, sizes, and font choices (all controlled by a professional web designer) help guide the eye to the important parts of the list, but it also inserts it into a table, which works better for when this (responsive) site is viewed on a tablet or smartphone screen.

We built this site in ExpressionEngine, our CMS of choice. Before, when this was all a content blob, the composition screen looked like this:

After giving it special content types for each variable, and being apply to apply a consistent, controlled style to each, we used Pixel & Tonic’s Matrix plugin to enter content:

Essentially, the client is filling out a web form now. They have a field for the title, author and Amazon link, and they can rearrange those within either a fiction or non-fiction column, within a row indicating the grade level. We’re presenting it visually so they don’t ever have to fathom the styling being applied to it.

This same principle can be applied to recipes, too, or even something as general as blog posts: how about instead of a headline and body entry fields, you pull out the lead paragraph, pull quotes, sidebar fields, and more?

The chunkier you get, the more development and strategy work is front loaded onto the web developers. But ultimately, that will save the client time and tears when actually creating the content.

A word of warning

As I said above, this requires planning. And it requires skill. And, just as important, it requires trust in us, the service provider, from the client. We need to be careful how you explain it, because to a client who may not understand the goals and intentions of a highly chunky site, it looks like we’re just being a ropeholder — making them sacrificing their flexibility and creativity to exert our own control.

But of course, that’s not why you’re doing it. You’re helping the client craft their content and making it as easy as possible for them to create it.

Because, after all, that’s our goal, isn’t it?