GatherContent is becoming Content Workflow by Bynder. Read More

From blobs to chunks: A real life example of how to structure content

From blobs to chunks: A real life example of how to structure content

4 minute read

From blobs to chunks: A real life example of how to structure content

4 minute read

From blobs to chunks: A real life example of how to structure content

Andy Welfle

Content Strategist, Reusser Design

Table of contents

1.
2.
3.
4.
5.
6.
7.
8.

I've spent a large percentage of this week obsessing over Karen McGrane’s column on A List Apart. In the article she talks about the conflict between content creators and web designers, and the contrasting understandings they have of the formatting and presentation of content.

This tension can be similarly placed in between the author and the developer — it’s about a divide in the production and the delivery of content.

As someone who attempts 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"; this really resonated with me.

This is also why I am a huge advocate of Markdown. When I compose in Markdown (which I am doing right now), I am just seeing plain text. Yet, I can still add functional attributes: I can embed links, create lists, I can make the text bold or italics, and perform all the HTML formatting that I need.

The Client, though

It's hard to convince my client, however, that us taking control over the content's presentation (and out of her hands) is for her own good.

Why shouldn'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 stylesheet we designed? After all, sometimes she does have content that needs to "pop" and draw attention to itself. And ultimately, she doesn't think about the integrity of the design and styles as much as we do. After all, that’s not her job. (Spoiler: It’s ours.)

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 forward-thinking web developers will advocate the use of custom “chunks” of content, not “blobs”, like you might find with a WYSIWYG editor responsible for the main content of a site page. Sara Wachter-Boettcher also highlighted the benefits of a similar approach in her presentation at the Responsive Web Design Summit this year.

A real life example

A "blob" is, basically, a consumption page that's just made up of a big ol' WYSIWYG field — you can type, mess with the text, insert a photo or two, and — BOOM. Publish. The output might look something like this (an educational resources page on an airport's site we created):

Books titles, authors and links entered in a WYSIWYG field.

It looks pretty nice, right? It's a list of flight-related books, both fiction and non-fiction, categories with various grade levels for each.

The trouble is, it took the client forever to enter the content and get it 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 Amazon.com 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 imply that our clients are idiots — in fact, this client is one of the brightest we’ve had. It’s just that they shouldn’t need to worry about this, they’re busy people.)

So we got to work on the blob – along with our developer, I (the content strategist) began to break the beast down, to chunk it:

Separate content chucks for each variable in this list.

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 our new approach, when this page was one big content blob, the ExpressionEngine composition screen looked like this:

The content window had completely free-form, WYSIWYG content. Highly formatting something like this takes forever and lends itself to inconsistencies.

After defining 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:

Matrix allows the designers to control the formatting, while allowing clients to concentrate on the content.

The result is that the client is now filling out a web form. They have a field for the title, author and Amazon link, and they can rearrange those fields within either a fiction or non-fiction column, and 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.

And what’s happening as a result? ... the client is now starting to see the connection between function, structure and presentation.

This same principle can be applied across a spectrum of content types: Recipes, employee profiles, product pages, or even something as general as blog posts: how about instead of headline and body entry fields, you pull out the lead paragraph, pull quotes, sidebar fields, and more?

The more you break it down, 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.The basis is that, the more you break it down into functional chunks, the more you can interrogate the function of each of these chunks when you are creating them. That is a good thing for everyone.

A word of warning

As I said above, this requires planning. It takes a lot of consideration. And, just as importantly, it requires a trusting relationship with your client. You need to be careful how you explain these concepts, because to a client who may not understand the goals and intentions of a highly broken down site, it looks like you're a rope-holder — making them sacrifice their flexibility and creativity to exert your own control and efficiency.

But of course, that's not why you're doing it, are you? 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 your goal, isn't it?

I've spent a large percentage of this week obsessing over Karen McGrane’s column on A List Apart. In the article she talks about the conflict between content creators and web designers, and the contrasting understandings they have of the formatting and presentation of content.

This tension can be similarly placed in between the author and the developer — it’s about a divide in the production and the delivery of content.

As someone who attempts 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"; this really resonated with me.

This is also why I am a huge advocate of Markdown. When I compose in Markdown (which I am doing right now), I am just seeing plain text. Yet, I can still add functional attributes: I can embed links, create lists, I can make the text bold or italics, and perform all the HTML formatting that I need.

The Client, though

It's hard to convince my client, however, that us taking control over the content's presentation (and out of her hands) is for her own good.

Why shouldn'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 stylesheet we designed? After all, sometimes she does have content that needs to "pop" and draw attention to itself. And ultimately, she doesn't think about the integrity of the design and styles as much as we do. After all, that’s not her job. (Spoiler: It’s ours.)

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 forward-thinking web developers will advocate the use of custom “chunks” of content, not “blobs”, like you might find with a WYSIWYG editor responsible for the main content of a site page. Sara Wachter-Boettcher also highlighted the benefits of a similar approach in her presentation at the Responsive Web Design Summit this year.

A real life example

A "blob" is, basically, a consumption page that's just made up of a big ol' WYSIWYG field — you can type, mess with the text, insert a photo or two, and — BOOM. Publish. The output might look something like this (an educational resources page on an airport's site we created):

Books titles, authors and links entered in a WYSIWYG field.

It looks pretty nice, right? It's a list of flight-related books, both fiction and non-fiction, categories with various grade levels for each.

The trouble is, it took the client forever to enter the content and get it 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 Amazon.com 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 imply that our clients are idiots — in fact, this client is one of the brightest we’ve had. It’s just that they shouldn’t need to worry about this, they’re busy people.)

So we got to work on the blob – along with our developer, I (the content strategist) began to break the beast down, to chunk it:

Separate content chucks for each variable in this list.

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 our new approach, when this page was one big content blob, the ExpressionEngine composition screen looked like this:

The content window had completely free-form, WYSIWYG content. Highly formatting something like this takes forever and lends itself to inconsistencies.

After defining 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:

Matrix allows the designers to control the formatting, while allowing clients to concentrate on the content.

The result is that the client is now filling out a web form. They have a field for the title, author and Amazon link, and they can rearrange those fields within either a fiction or non-fiction column, and 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.

And what’s happening as a result? ... the client is now starting to see the connection between function, structure and presentation.

This same principle can be applied across a spectrum of content types: Recipes, employee profiles, product pages, or even something as general as blog posts: how about instead of headline and body entry fields, you pull out the lead paragraph, pull quotes, sidebar fields, and more?

The more you break it down, 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.The basis is that, the more you break it down into functional chunks, the more you can interrogate the function of each of these chunks when you are creating them. That is a good thing for everyone.

A word of warning

As I said above, this requires planning. It takes a lot of consideration. And, just as importantly, it requires a trusting relationship with your client. You need to be careful how you explain these concepts, because to a client who may not understand the goals and intentions of a highly broken down site, it looks like you're a rope-holder — making them sacrifice their flexibility and creativity to exert your own control and efficiency.

But of course, that's not why you're doing it, are you? 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 your goal, isn't it?


Ready to get started?
Start your free trial now
Start free trialBook a demo
No items found.
andy welfle

About the author

Andy Welfle

Andy is a content strategist at Reusser Design, a small but innovative web development company in Indiana, USA. He's endlessly fascinated by online writing platforms and his life goal is to teach the world Markdown. His obsession with the mechanics of writing goes further than that, though — you can read his blog about wooden pencils (the original word processors!) and you can also connect with him on Twitter.

Related posts you might like