To Structure or Not to Structure

By Deane Barker • Posted on December 07, 2007

I’ve talked a lot over the years about content modeling. Open and Closed Content Management is probably the most self-referenced post on this site. Recently I called content modeling one of the Four Disciplines of Content Management.

But, lingering behind all the questions about how to model something is a bigger question: do you model it at all? When is it obvious to structure some content, and when do you just throw it into the “WYSIWYG pile”?

We were meeting with a client the other day about applying some content management to their Web site. We came upon a page of “business partners.” It had a repeated HTML structure consisting of a logo for the partner, their name, their URL, and a few paragraphs about them. There were maybe a dozen or so partners listed.

It looked like this:

From a content modeling perspective, you have three ways to handle content like this:

  1. No structure: This is a perfectly viable option – provided you didn’t mind a TABLE, the HTML represented here is nothing any decent WYSIWYG editor couldn’t handle.

  2. Structured as a single content object: For most systems, this means an XML document, with a repeating “partner” element, and sub-elements therein for “logo,” “name,” “url,” and “description.”

  3. Structured as multiple content objects: You could create a “partner” content type, with fields for “logo,” “name,” “url,” and “description.” This page would be a rendering of multiple partner content objects, sequentially down the page.

Not surprisingly, there are advantages and disadvantages for each, and we threw them around with this client.

Contents

No Structure

Advantages

Disadvantages

Structured as a Single Content Oobject

Advantages

Disadvantages

Structured as Multiple Content Objects

Advantages

Disadvantages

So, there’s a run-down of the advantages and the disadvantages of the major approaches. But which one to choose?

As you’d imagine, there’s no clear-cut answer. Here are some of the factors to consider:

In writing this post, I tossed it over the pond to Josh Clark for his input. In his response, he captured one of the more succinct differences between how we (developers) look at content, and how the end users do. This too, needs to play a role in your decision (emphasis mine):

The big advantage to structuring content, of course, is that it lets you repackage it and present it in different forms and contexts. The downside is that it forces editors to approach their content like machines, thinking in terms of abstract fields that might be mixed and matched down the road. The benefits often outweigh this usability cost if you’re going to present the content elements in multiple contexts and/or offer various sorting options with a large number of elements. If not, then I typically go with unstructured.

That’s brilliant, and it’s so true. Understand that structuring content can suck the soul out of the authoring process for a lot of people. Like Josh said, often the advantages are clear enough to justify some soul-sucking, but always approach this with care.

I remember a client for whom we were building a “case studies” section of their Web site. I kept trying to get them to structure the case studies. I would say things like:

If you kept your case studies in an Excel spreadsheet, and each row was a case study, what would the column headings be?

Now, this is a good question and one that’s worked well for me in the past, but this client was just not getting it. Finally, Joe said, “Dude, I think they just want a page...” And he was right. The client wasn’t thinking in terms of structure – they were thinking in terms of a page with stuff on it. The figured they could just WYSIWYG it up, and in the end, they did it this way and they were fine.

Postscript: So, what are we going to do with our original example? At this point, I can’t say, but I’m leaning away from pure WYSIWYG because of the image processing. If we get this client on eZ publish, I imagine we’ll do it in separate records because eZ can’t repeat sub-elements within the same record. If we were to go with a CMS that allowed that, then my inclination would be to do as a structured single record.

This is item #192 in a sequence of 356 items.

You can use your left/right arrow keys or swipe left/right to navigate