(Note: the audio for this post is here.)

We had a build meeting the other day for a client’s site, and we walked through the site map to determine what content types we were going to need to pull this off.

In these cases, the first content type you inevitably define is the ubiquitous “text page.” This is a simple page. Of text. Duh.

Text pages usually consist of a title, a summary (for index pages where you’re listing a bunch of them), and a body of text. Many content management systems support this model explicitly (it’s built-in this way — think of a blogging platform), or you end up modeling your page like this if your system gives you that ability.

But how far do you…push, the text page? There are a lot of opportunities to re-use this content type. How far do you take it?

This particular client also need an “announcement.” We took a long view of it, and determined that their announcements section was really just a group of text pages, reverse-ordered by date. So, we thought, let’s just tack a “date” field on the text page model, and be done with it. If the text page is in an announcements section, we’ll order by that date. If not, we’ll ignore it.

Then, the client needed an “article” content type. Well, what is an article? It’s a text page…with a date…and an author. So, let’s just tack an “author” datatype on the “text page” model, and we’re good…right? We can use it when we need to, and ignore it when we don’t.

Later, the client needed a “newsletter” content type. Turns out, this is just a text page with a PDF file attachment. So, we tacked on a “file” datatype…

Now, in truth, this situation was hypothetical. But you see the idea at work here? How content types are really just derivative of a core content type? The fact is, an awful lot of content types can be defined as:

1. Title
2. Summary
3. Text body

Tack on these datatypes —

1. Date
2. Author
3. File attachment

— and you’ve handled four separate, logical types in our mythical client’s content model: text page, announcement, article, and newsletter.

So, the question is, did we take this too far? Or is what we have planned here an elegant solution to modeling this content?

In the end, it depends. It depends on a lot of your content management system’s functionality external to content modeling. Dividing these four logical types into multiple actual types is often valuable for more than just content modeling — many systems will drive things like templating and permissions by content type. And what happens when you need to add a property to your Announcements, but not your Articles? So having everything as some uber-text page can lead to other issues.

In the end, it comes down to repetition vs. elegance. While duplicating your core set of properties on every content type is a pain, you avoid some tricky issues. Conversely, pushing the envelope with a single content type is elegant, but you can paint yourself into a corner pretty quickly.

But, my point here is that we shouldn’t have to do this. And here’s why —

Very few content management systems are using the object-oriented concept of inheritance these days. Inheritance says that Class B is a superset of Class A — it includes all of Class A’s functionality, and then some more. So if I happen to change Class A, Class B will change too.

In this case, I would model a “Page” object with these properties:

1. Title
2. Menu Title (for implicitly menued systems)
3. Summary
4. Body
5. META keywords
6. META description

Then, would extend this base “Page” object into the “Announcement” object by adding a “date.” I would extend that into an “Article” object by adding an “author,” and into the “Newsletter” object by adding a “file.”

Then, say I want to geo-locate everything someday. I just add a “location” attribute to the base object, and everything extends from that.

Very few content management systems allow this. I’ve seen it in exactly two systems, both heavy of document management — Alfresco and Documentum. It’s elegant, it’s precise, and it’s powerful, which should be obvious since it’s been a core tenet of object-oriented programming for years.

Sadly, implementing this kind of system is complicated, and usually computationally expensive. Documentum, for example, maintained a database table for every level of inheritance, and did one-to-one joins all the way down the inheritance tree to return a big database row for an object. (But, on the other hand, this is built-in to Postgres, so WTH?)

Even if a system didn’t let you do traditional inheritance, N-levels deep, it would be handy if you had a “base object” from which you could derive your types from. Meaning, you could alter a base object to include things like the title, summary, text, etc., then each type would be adding properties to this base type. You couldn’t go more than the one level deep, but it would still solve a number of problems.

If your CMS has a strong content tree, you could fake inheritance a bit. You could create a base content type, then add subcontent to “flavor” it. Your base type would have the core properites, and you could add subcontent underneath it to hold other information specific to the pseudo-class you need that particular object to act like. This is hack-ish, but it might work well in some cases, and it fits the model of “Custom Field Sets” we discussed several years ago.

In the end, content type inheritance is the holy grail of content modeling, and you don’t see it that often, which is too bad. It would be a huge asset to any CMS that implemented it. eZ publish claims that it’s on the roadmap, but I’ve yet to see anyone put a date on it.

In this latest audio post, we re-visited the grand-daddy of content management posts on Gadgetopia: What Makes a Content Management System?

For 33 blessed minutes, I ramble on about exactly what makes your site management system turn the corner from a simple “relational database with an admin section” and turn into a bonafide “content management system.” In doing so, I present a broad overview of content management functionality.

Audio is here.

What comes out of the box with eZ Publish is just a starting point. Don’t be afraid to extend the platform, through custom classes, extensions, template operators, etc. Don’t accept a limitation. If you feel hindered in any way, ask questions, because there’s a way to do anything.

Click on the cover image to get the PDF (warning — it’s big).

In this audio post, we re-visit last year’s post on subcontent — the concept of modeling content by stacking it on top of each other. I feel just as strongly about this as the day I wrote the original post.

Audio is here.

(Note: there’s one blatant mistake in this one that I didn’t realize until I played it back. Toward the end I say “node dependent,” when I really meant “position dependent.” Not being remotely capable with audio editing, I have no idea how to fix it short of re-recording the whole thing.)

The following topic tree represents the entire USA TODAY story collection going back as far as late 2003. We’ve presented these stories within our site structure, which has up to four (4) levels in each of our seven (7) site sections.

If you’re into Information Architecture, this is an interesting case study of content classification.

(Audio is also here. Sorry about the quality — I was using a different mic this time, and the input levels were all hosed up.)

Navigation is often a pain when it comes to content management. Now, don’t confuse “navigation” with information architecture — that grand plan of what goes where in relation to what.

By “navigation,” I mean “menuing.” It’s less theory, and more practical application of how do you get a specific group of links in a specific spot on a page, and make sure the right group of links shows up with the right content?

In the broadest possible sense, there are two theories to handle menuing:

1. Implicit, meaning the menus are driven off the content structure of the site.
2. Explicit, meaning you have a specific “menu” structure, and it links to specified content in the site, regardless of where that content is.

Interestingly enough, Ektron and eZ publish — the two systems Blend works with most often — are perfect examples of the two approaches.

eZ publish is usually used as an implicit system. It has a very strong content tree, so you build your site as a series of content objects stacked on each other. Under the “home node,” you usually have a series of top-level content pages representing your top-level categories.

On the templating side, you simply spin through this list of nodes, and print out their titles and URLs as your main menu. When you get into a second-level page, you query the siblings of that page to make your secondary navigation menu.

On the one hand, this is elegant and has benefits:

1. Content automatically appears in menus. You create a new page in a section, and that section’s menus suddenly get a new link.

2. You can enforce security in navigation. To add something to Menu A, you have to have access to create content in Section A.

3. Menu information and settings is handled a lot like content. Since the menu is based on the content and therefore tightly bound to it, it gets versioned — by rolling content back, you roll the menu back too.

4. It’s easy to match menus with content. Since you don’t have an explicit “Products Menu,” you don’t have to worry about how to make sure that menu appears on all the pages in the products section. The menu is built-in to the content.

But, on the other hand, this approach can be frustrating. The first problem is that you often want the representation of content in a menu to differ, meaning it often has to have a different title. If your page is called “Selected Case Studies of our Product in Action,” you probably just want the link in the menu to say “Case Studies.”

This is usually accomplished by giving every object an attribute called “Menu Title” or something similar, which is the title used in the menu. Thus, you can give your pages a full title, and a shorter title so your menus don’t get out of control.

The second problem is that sometimes (1) the content structure, and (2) the navigation structure, of your site are just not the same thing. In these cases, you can jump through hoops trying to get your navigation to come out right.

Say you have a node which you don’t want to appear in the menu. You need to find a way to suppress it. In these cases, you often find yourself architecting your templates so that if the content object doesn’t have a menu title, it doesn’t appear in any menus.

But what do you do if you don’t want you menu to mirror the structure of the site? Well, therein lies the rub — if you’re basing your menu on content, you need to make sure you have content for every option. In eZ, you can create a class which just has a title and a reference to another object, and use that has a “dummy node,” just so a menu link shows up, but this can get out of hand awfully quick.

And what if you want to link to a URL not on your site or a URL not represented by a content-managed object? Then you have to create an “External Link” content node or something just to get that link in a menu. In this way, the line between content and navigation starts to blur, in that you have content that’s really just navigation.

Finally, there’s something that may seem to be a minor point, but it’s really not: for implicit menuing to work, your content management system has to allow for arbitrary ordering of content. Menus are order-sensitive — the order of menu options is almost always important and can rarely be derived. If your menus are simple iterations of content, then you need to make sure that content can be ordered in some arbitrary way.

Ektron is the exact opposite to the eZ publish scenario — it’s an explicitly-menued system where there’s a separate menuing system, so menus are a completely separate conceptual idea from content.

To create a menu in Ektron, there a special interface for it. You can create a menu, and put menu options into it, from which you can pick content from anywhere on the site.

There are several benefits here:

1. It’s simple. While developers tend to enjoy elegance and purity of content, users often just want a link in their admin interface that says “Menus” and just want to know how to get Link A to appear in Menu B without any concern of the relative conceptual merit of it all.

2. The navigation structure of your site can be completely separate from the content structure, which is handier than you might think. Any menu can be comprised of links to completely random content from around the site.

3. The menu subsystem can handle very menu-specific functionality. For instance, it can a little checkbox where you pick how you want the hyperlink to be handled — should it pop in the same window or a new window? This is a very specific menu-type construct, and an explicit system makes it pretty simple.

However, there are some downsides —

While explicit menus are simple, they’re more de-coupled from the content, so you can do some odd things with them. Someone might be able to add some random content to the products menu, which you don’t want, or delete the menu entirely. The menu just becomes something else you have to manage.

What’s worse is that very rarely are explicit menus subjected to the same controls as content. They’re not versioned, very rarely can they go though workflow, and some systems don’t even put individual permissions on them — if you can “Manage Menus,” you can manage all the menus. In this sense, they become second class citizens. They can’t be managed as tightly as content, yet they’re just as important to the functioning of your site.

Finally, you’re often trapped by the menu system’s functionality, since they’re probably not extensible. For instance, if you have to have scope notes with your menu links — little one sentence explanations of what’s behind the links — you may be out of luck. Menus aren’t content, so they’re not as definable or extensible as content, which means you’re often stuck with what your system has, and nothing more.

So, which is better? I’m going to take the absolute middle ground here and say that they both have their merits, and the best content management systems can handle both of them.

As I said, eZ publish is normally an implicitly menued system, but it can handle other methods as well. There’s a “Toolbars” subsystem that can be used for simple explicit menus. Additionally, you could build a menuing system out of content objects fairly easily. eZ publish has such great content modeling tools that it wouldn’t be hard to model a “Menu” and “Menu Option” class and effectively roll your own menuing system.

Ektron, on the other hand, has great explicit menuing tools, but does not do implicit menuing easily, primarily because of the lack of arbitrary ordering. You can iterate nodes in Ektron, but you’re very limited on how they can be ordered. Ektron stores content as XML, so you can’t even order them easily by some interior “sequence” property.

The bottom line is that you need both options. Different scenarios can call for different things, and in working with the two methods I’ve described here, there is always at least one time in every project where I yearn for the option I don’t have.

Here’s a fact: intranets don’t have to be crazy-complicated. Intranets are fundamentally about sharing simple information, which is not as hard as some people make it out to be. As simple as this is, most organizations either have no intranet, or a smattering of HTML pages someone threw together with Front Page that no one looks at.

In working with companies on their intranets, I’m confronted by the fact that there are fundamentally two types (genres?) of information:

Permanent and temporal.

Reference and announcement.

Eternal and time-sensitive.

Groomed and discarded.

Wiki-ish and blog-ish.

Pages and posts.

Pages and posts — that brings us back to a couple of posts about the concepts of posts vs. pages:

• Thoughts on Posts and Articles
• Ruminations on Posts vs. Pages
• More Great Wikipedia Coverage

I’m not going to re-hash those arguments here, but I recommend you go read them, as they really touch on an important point: some pages on an intranet are eternal, and some are temporal.

• An announcement of an upcoming potluck — temporal
• The mission statement — eternal
• Information about a news article involving the company — temporal
• A procedure explaining how to apply for a new ID card — eternal

Now, this is a bold statement, but think that 95% of information on an intranet would fit into these two groups. Something is either an announcement, or it’s a reference page of some kind. Sure, there are other types — a discussion space type, for instance — but a lot of companies could fit almost everything into these two groups.

The most common phrase I hear about companies and their intranets is: “Our intranet is a mess.” The next most common phrase: “We just need a list of announcements somewhere…” So, they need a blog, essentially. And, invariably, they need a smattering of static pages as well.

Going back to that post mentioned above about the Wikipedia coverage of Hurricane Ivan:

With Wikipedia, you’re not seeing a series of posted items. You’re seeing a single body of information, continually updated and groomed. Thus, the basic information stays right where it’s easy to see. Wikis are more “speak to me like I know nothing” information, rather than “tell me the very latest nuance” information.

The ideal is really a combination of both — keep the basic (wiki-ish) information right there, and have a sidebar of the latest (blog-ish) information as it comes in.

So, we need a platform that allows groups to have blog-ish stuff, and wiki-ish stuff. What fits? Three platforms jump to mind:

• Wordpress
• Google Sites
• Movable Type

Yes, I know there are many more, but these are at the lowest end of the scale in terms of complexity and the highest end of the scale in terms of applicability — remember, we’re trying to be simple here.

Wordpress is great, and crazy hackable, but it suffers from what I’ve always considered a huge limitation: lack of the ability to have more than one blog. This is something that Movable Type has done from the start, and I’ve always taken it for granted.

One of the most common requirements for a company intranet is that different organizational units have their own “spaces.” Every department needs a sub-site all their own. It strikes me that this would be hard with Wordpress, although with all the custom plugins and development, perhaps there’s something I’m missing.

Another problem with Wordpress is that it’s bound to PHP. More on this below.

Google Sites is really fantastic. Blend uses Google Apps for Domains, and so we get Google Sites with it. I tried it out and was somewhat blown away by what appears to be an arrow shot directly at Sharepoint. Additionally, it’s built with the concept of multiple sub-sites in mind — they even provide tagging tools to organize sites. Your company could have hundreds and hundreds of Google Sites, and you could search for any sites tagged with “Human Resources,” for instance.

But, we all know Google Sites has perhaps a fatal flaw: you don’t own it. Your stuff is housed on Google’s servers, and this is just out of the question for a lot of companies.

Which brings us to Movable Type, which I think is the real winner here. First, it handles the posts/pages thing well, you can set up multiple blogs and allow individual permissions to each, and then there’s the biggest benefit of all: MT is a data push system — basically a big code generator. It’s written in Perl, but will effectively publish to anything.

A lot of companies are bound to .Net. It’s not their fault, but they’re Windows shops and all their stuff is in .Net. It’s in this environment where I think Movable Type would really shine because it can generate ASP.Net Web forms.

Gadgetopia uses MT to generate PHP files — why couldn’t it generate Web forms? Remember that it would just need to generate the Web form — all of the pages it generated could extend from the same code-behind.

This way, everyone consuming your intranet stays solidly in the world of .Net. All your hard-fought Windows user controls could still be in the pages (using Builderoo or some other tools, you could even get user controls embedded in posts), and you could use all of the other .Net integration goodness that the rest of your company runs on.

And this brings me back to my original point: there is a huge number of organizations out there for which a copy of Movable Type and a well-designed template would be an utterly massive improvement on their ability to share information.

I have built two intranets now using a mid-range CMS — it cost both companies about $40,000 in software alone. Looking back, I’m struck that they’re not doing much more or less than they could do with a copy of Movable Type.

This may sound simplistic, but take your organization and a single installation of Movable Type. Give every department their own blog, in which they can manage posts, pages, and media files (have you seen MT 4 yet? It does supporting files quite well).

Suddenly, every department has a simple announcement list (with RSS, even), and the ability to create whatever reference pages they need. This would solve a huge number of issues for the majority of companies struggling with their intranets.

Sure, there are higher-level functions that MT wouldn’t do well — things like a company directory, or a repository of policies and procedures. But in my experience, this stuff is often done in the main CMS anyway. The company directory is probably better served out of Active Directory, and policies and procedures are becoming more specialized with DITA and Docbook and other methodologies.

And of course, we could sit here all day and make up scenarios that would embarrass our humble little blogging platform, but that still doesn’t help the organization I consulted with two weeks ago. Even after multiple tries, their intranet is such a mess that they’ve given up and just they now post announcements to the bulletin board in the hallway and hope people see them.

Movable Type certainly wouldn’t solve all their problems, but it would solve most of them, and involve less pushpins.

(Note: this post exists in both written and audio form. They’re more or less the same thing, so take your pick. I elaborate a bit more in the audio, since I have a tendency to ramble, but I used the written post as an outline for the audio post, so the general gist is the same. If you want the MP3, it’s here)

In Web content management, you can identify two types of pages fairly easily:

1. Free-form.
   A title and a big WYSIWYG area.
2. Structured.
   More database-like — data is structured into components and assembled into a page.

(We discussed the difference in detail in a post called “To Structure or Not to Structure.”)

However, I’ve often found that there’s something in the middle. You need a big WYSIWYG area, but you need structured areas within it. This can get tricky.

This is easily explained with an example, which will probably ring true for a lot of content management developers —

For your company intranet, you have a “Page” template. All is good.

But then your users suddenly want to embed calendars from the Exchange server into their pages. Okay, you say, and you build a “Calendar Page” data type and template. The data type includes a new “Calendar URL” field, and the template includes the code to render the calendar.

You now have two templates.

Later, the users come back, and they want a photo gallery. So, you create a “Photo Gallery” datatype and template, which allows them to upload photos, and the template renders the gallery.

You now have three templates.

Later still, the users come back and say, “This is great, but we want this page to have a calendar AND a photo gallery in it. So, we want a bunch of text, then a calendar, then a bunch more text, then a photo gallery. And maybe another calendar after that…”

What now, Einstein?

This is where you start seeing some really bizarre things done to try and jump through these hoops, and jump through the next one, and the next one, etc. Before long, everything becomes totally unmanageable. The users are irritated because they think the system is inflexible, and the developer is irritated because he thinks the user are being unreasonable, etc.

However, all is not lost. Over the years, I’ve seen and implemented two good ways to handle situations like this.

1. Composite Pages

A composite page is a single page, made out of pieces. Your users can add a “Page” to the system, then add “Sections” to the page. They can pick from different types of sections, like “text with header,” “text with image,” “centered image,” etc.

The idea is that you stack these sections on top of each other, order them, and when the page is rendered, its sections are rendered in sequence from top to bottom.

The benefit here is that the page is broken down into sub-objects, and each of these can contain their own data structures and functionality. You could have page sections for “Calendar” and “Photo Gallery.” Intersperse those with a couple “Generic Text” blocks, and you have a much more flexible page structure.

There are a few disadvantages to this model —

First and foremost, editing can be a pain. Often users just want to edit their pages without having to juggle more than one content object. Additionally, the addition of even one structure element into the center of the text breaks the page up into at least three elements.

Consider the example of a single-section page of text, into which a user wants to inject a calendar. How do they do this?

Users will have to create the calendar section, then create another text section to go under it. Then they have to transfer some text from the top section into the bottom section, so the calendar appears to be in the middle of of an otherwise unbroken flow of text. To move the calendar “up” in the page means transferring text from the bottom text section to the top text section.

So, the editing model can be complicated. I’ll admit that I haven’t seen a composite page interface that has leveraged all the Ajax-y goodness available these days. Joe and I have often theorized that it could be done much today than in years past, which could probably mitigate the editing pain that I’ve experienced.

Second, breaking what was a single object into multiple objects presents some other issues. What do you do about some of the higher level functions: versioning, workflow, and permissions? When you save a composite page, are you versioning the sections independently or as a group (if as a group, do you save new versions of sections that haven’t changed)? Can you send individual sections through workflow? Can you set specific permissions on sections? Etc.

Finally, the composite page model is optimized for pages that have “horizontal bands” of content. What happens when people start to float images to the right and left, and elements start to “hang over” other elements, either inadvertently, or on purpose? The formatting issues can get complicated here, and you might end up with users irritated that they can’t do something which seems simple, but ends up being complicated or impossible.

(I’ve seen this done once where the composition model was extended to columns as well, so a “content row” could be split into multiple “content columns” which each contained different objects. However, this gets even more complex since, on the Web, horizontal space is usually much more rigid than vertical space. So what happens if someone divides a row into 20 slivers and then tries to cram a photo gallery into one of them? The result is that all the possible objects would have to be designed as width-neutral, which is far easier said than done.)

I haven’t seen a commercial system that uses a composite page model. I’ve seen it done several times in one-off systems built by others, and I tried it once years ago. I’d love to see a a really high-end implementation of it.

2. Embedded Content

This model is more flexible than a composite page model. It considers each page as a big WYSIWYG area, into which you can insert and format text. However, in addition, you can position references (“markers”) to more complicated content, which is then “expanded” and inserted into its parent content when the page is rendered.

So, to continue our embedded calendar example from above, your users would have a big field of text, and somewhere in it would be a marker of some kind. When rendered on the public side of the site, this marker would be “caught” and expanded into a full-blown calendar.

What is the marker? It needs to be a text string that (1) allows the passing of variables, and (2) is easily parsed during rendering.

Systems using a good XML editor could allow users to put a custom XML tag. This is handy because you can validate it, and it’s quite easy to pass variables in with it, XML being a data serialization engine and all. So, your calendar marker could look like this:

<Calendar Url="http://somewhere"/>

Templating engines like PHP’s Smarty do this well too. In Smarty:

{Calendar Url="http://somehwere"}

There are a number of benefits to the embedded content model:

First, the user model is solid, because users can manipulate the page as a single block of content, which usually makes more sense to them than stacking independent objects on top of each other.

Second, the position the calendar in the page is simply a matter of where the marker is. Move it up or down within the same block of text.

Finally, the position of the embedded content can be affected by what’s around it. If users want to align the calendar to the left, simply enclose the marker in a floated DIV (provided there are no width issues).

And, there are drawbacks, which are subtle, but can be significant:

First, there are challenges to insert source code-ish markers in WYSIWYG environments. If you use XML, will it show in WYSIWYG mode? Will editors remember where it is? How will the editor handle and display it? Some editors handle this better than others. For example, if you drop a custom XML tag in the source, eWebEditPro from Ektron can replace the custom tag with an icon in WYSIWYG mode.

Second, users have to know the structure of the markers and how to embed them. Do you trust them to form an XML tag? In a perfect world, you can pop a separate window with a form that creates the tag and embeds it, then replaces it with an icon. Sadly, not all editors are going to support this.

Third, what happens when data required by the embedded content becomes invalid? What happens when the calendar in the Exchange server is deleted? Do you somehow identify content that embeds the calendar and…do what? Alert someone? Remove the marker? Do nothing and just throw an error on rendering?

In general, embedded content suffers from being less identifiable to your system. With a composite page model, each page section is likely stored as separate database record. But embedded content is nothing but a small text fragment inside another record, which is not easy to query (unless you’re using XML and your database supports XML indexing, then you’re in great shape).

You’ll quickly get to a point where you need to identify and index all the embedded content when you save a record. Keep an index in a separate database table which records what embedded content with what variables is contained inside what content. This makes it easy to find all the content that references Calendar X.

Fourth, what about permissions? How do you ensure users are only embedding content that they’re allowed to embed? It’s unlikely you can catch this real-time in the editor, so you’d have to try and catch it on save, which is less-than-ideal from a usability perspective.

Finally, you’re giving a lot of power to the users here. If they load their page up with 159 calendars, what happens to server when it renders? You’re essentially allowing the users to force your server to execute extra code based on what they put in their content. Whether or not this is a problem is up to you.

I’ve seen this model in a lot of systems:

1. eZ publish has an embeddable content model, which is built-in and fairly sophisticated.
2. I’ve built this with Ektron since eWebEditPro will let users embed custom tags and has fairly good support for editing them. When rendering, my system parses the XML for tag patterns, then replaces them with the output of corresponding .Net user controls.
3. Years ago, we wrote about a plugin for Movable Type called Builderoo which enable the definition of macros to be inserted in posts.
4. A little-known open-source system called Etomite (which I really enjoyed playing with) allows you to define “snippets” which map to executable PHP code.
5. I haven’t looked at this in ages, but Joomla used to have things called “mambots” (a carryover from when it was named “Mambo Server”) which allow you to embed functionality in pages.

In the end, the embedded content model is tougher to implement, but, done correctly, is considerably more flexible and powerful.

However, this is sometimes (often, actually) hard to explain to potential customers. It’s commercial…but it’s open-source…huh?

To try and solve this, we wrote a document to definitively explain how this works:

eZ publish: Support and Licensing Explained (90KB PDF)

Some of you out there in the content management world will find this interesting, as it provides a good example of the “supported open-source” model that some companies are operating under these days. This document is a little Blend-specific (we toss in consulting hours with an eZ support agreement purchase), but is otherwise generic to the eZ Publish Premium support plan sold by eZ Systems.

This post is about three questions you have to answer before you can even go looking for a CMS. The answers to these questions will drastically narrow the pool of systems you can select from.

(On an editorial note, my level of comfort with these audio posts is decreasing. I suspect that I sound like one of two things:

1. A bonafide expert
2. A complete jackass

Please let it be the former…)

As always, if you’re looking at this in RSS, you can (1) visit the post itself to use the little Windows Mobile widget, (2) get the raw MP3 here, or (3) if Feedburner does what it claims, there should be an MP3 enclosure on this post in your RSS reader.

Today’s post is about load-bearing walls in content management — those things that require a content editor to call a developer to change them. Where do you draw the boundaries? How much is too much?

Like yesterday, if you’re looking at this in RSS, you can (1) visit the post itself to use the little Windows Mobile widget, (2) get the raw MP3 here, or (3) if Feedburner does what it claims, there should be an MP3 enclosure on this post in your RSS reader.

This audio post revisits The Four Disciplines of Content Management from last November. I add quite a bit, and elaborate on a lot of the points, and babble on and on about content management. Whether or not that’s a good thing is all a matter of perspective.

(There’s about a half-dozen words in this post I wish I could excise entirely, because they don’t make any sense at all. I’ll let you figure out which words they are.)

If you’re looking at this in RSS, you can (1) visit the post itself to use the little Windows Mobile widget, (2) get the raw MP3 here, or (3) if Feedburner does what it claims, there should be an MP3 enclosure on this post in your RSS reader.

For the record, I only watched a couple of screencasts and browsed through some of the code. I don’t know if it would call it a CMS based on the definition we offered a few months ago, since there’s no higher CMS functionality: versioning, workflow, check-in/out, granular user management, etc. (PureEdit is, actually, every bit the “RDBWAAS” mentioned in the afore-linked article.)

What PureEdit is, however, is a nicely slick way of managing some database tables. Call it a very polished version of phpMyAdmin. It lets you, the developer, create a very usable interface to let non-developers manage database records of a database you created.

This is handy in a lot of ways, because there’s no over-arching data storage architecture to worry about (it’s your database, after all), and there isn’t any publishing architecture either — no templating or other stuff to worry about. You can just pull content from the database on the front end as you see fit, just like you’ve known how to do for years.

This is a nicely way to solve the problem we discussed a couple of years back: The Quandary of the Single Table Web Site.

What do you do with sites that need a single table of data updated? These are sites which are totally static, except for this one thing…

[…] This happens a lot — the sites are all static except for one element, be it a list of locations, events, the ubiquitous “Latest News,” etc.

What I like about PureEdit is that its datatype handling is pluggable, so you can think up a way that a user needs to manage a field, and the edit interface will present them with a customized widget for that datatype. (Example: you could plug in a Google Maps interface, have the user select a location from it, and then store the lat/lon information. This is something we’ve done for eZ publish, but it’s order of magnitude more complex in that environment.)

I also like that there’s no publishing mechanism. In my experience with content management, I’ve always felt this was the most wasted area of effort. Content publishing is vastly more simple than content management or editing (see The Value-Add Side of Content Management, CMS’s Should Manage Content, Not Display It and CMS Administration vs. Presentation Languages).

So, consider PureEdit a cross between phpMyAdmin and a full-blown CMS. It’s a nice, handy way to let non-developers manage tables of data.

It’s at version 1.1, and I’m excited to see where it goes. Add versioning, check in/out (or just simple record locking), and some more finely-grained user management (this user can edit records in Table A, but not Table B), and you’d really have a heck of a piece of work.

I subscribe to his blog, and I kept seeing release notifications going up and I was wondering what he was doing, but it turns out that Josh wants to deliver something odd in the world of commercial software: a quality product.

I know, I know — it’s rare that you hear of these types of products, but they do exist. Big Medium 2.0 took over 60 released builds and a full year of active beta testing, which is more impressive when you consider that Josh is a one-man shop.

Follow the link above to view the feature list and some screencaps. I really like that Josh has addressed my frustration with image and file handling, and has implemented image vs. file abstractions. Oh, and I got him to include versioning as well. I rule.

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.

No Structure

• Advantages
  • The simplest, fastest, and cheapest thing to do.
  • It’s flexible. To structure content, it needs to be rigid and consistent. However, the client will invariably have an exception to this rule, and a WYSIWYG editor will let them do whatever they want.
  • It’s likely more usable for the end-user. They have content in their WYSIWYG editor that looks like it does on the page, and it’s tough to make more sense than that.

• Disadvantages
  • You’re trusting the user to not screw up the formatting. That can be a huge leap of faith.
  • You can’t isolate the individual partner records. If they suddenly decided they wanted to feature a random partner on the home page, you can’t easily go pick one out of the list.
  • The images can be a problem if they have to be resized, given the generally poor handling of file-based content by WCMSs these days.
  • WYSIWYG editors don’t do CSS layouts well, so you may have to settle for some horked up HTML. The above layout, for instance, would be hard for the average content editor to do in anything but a big TABLE tag.

Structured as a single content object

• Advantages
  • You can control the formatting at the template level, which means it’s much harder for the user to screw it up. You’ve taken the formatting out of the user’s hands and they’re now working with pure content.
  • You can programmatically resize and otherwise process the images.
  • The page remains a single content object, which is simpler for the end user (opposed to multiple content objects, in the next scenario).
  • There’s now enough structure to get at the individual records if you need to.

• Disadvantages
  • With structure comes rigidity. If the client wants an exception to the format for Partner X, it can become a complicated exception process, or it can be nigh impossible.
  • Changes to the format now become a developer concern, rather than an editor concern. If they suddenly decide they want to include a line for “location,” they can’t do that themselves without dual-purposing another field, which kind of defeats the purpose.
  • To effect this solution, you need to have a CMS that can handle repeating form elements in a content type. This usually means XML, and an editor that allows repeating XML elements.
  • While arbitrary ordering of records is simple (most XML editors will let you move child elements around within the parent), sorting based on a property can be problematic. Support for sorting in XSL is simplistic, and to sort otherwise would require you to parse the XML into some other, sortable data structure, sort it, then publish it from there, or put it back into XML to be transformed.

Structured as multiple content objects

• Advantages
  • As before, you can control the formatting at the template level.
  • You can manage each partner record individually. For each one, this means you can permission them, version them, subject them to workflow, etc. You could even give each partner a login and let them manage their own record.
  • Getting at each of the records individually is as simple as possible.
  • Most all CMSs can handle this type of structure (as opposed to the need for repeating elements in the prior scenario).

• Disadvantages
  • As before, with structure comes rigidity.
  • Can be more complex for the end user. They have more than one object floating around. Some users might find this just as simple, some may find it complicated.
  • Depending on the CMS, ordering the records on the page can be a problem. You might want to arbitrarily order these records (rather than sorting on a property), and some CMSs do that better than others.

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:

• To what extent do you need to sub-divide the content? In the above example, will you ever need to isolate a single partner?
• If your answer to the above is “no,” how sure are you of that? How well does the end-user understand the risk they’re taking by not making the content sub-dividable? Will they accept extra expense if it has to be structured later?
• How many sub-dividable units are there? The stakes are much lower with a dozen than with 15,000. Additionally, as the number of units goes up, so does the administrative overhead of managing them all as a group (finding the one that changed out of a dozen is easier than out of 15,000, no matter how good your diffing tool).
• What is the technical sophistication of the end-user? How well do they understand content management? Can they grasp the concept of compositing a page out of sub-elements, or are they going to be confused if what’s in the editor doesn’t look like what’s on the page?
• How often is the content going to change? When it does change, how often will it be a single element? Will changes to single units overlap, so if one is in the middle of a workflow, would it help to be able to send another one through workflow as a separate unit?
• How intricate is the formatting?
• How do they want to order the individual records?
• Is there any processing you need to do on sub-elements of a record? In the example, the image needs to be resized consistently every time. In other cases, you may need to do consistent calculations of user-supplied values that are best run through a stable algorithm.
• Are permissions different on individual units? In the example, if partners can manage their own record, then they have to be permissioned separately.

• How sophisticated is your CMS editing tool? Can it even do repeating elements at all? If you choose the second option, and structure within a single content object, how closely can the editing form look like what’s on the page? (Put another way, how easily can you “trick” the end-user into structuring content by making it look like WYSIWYG?)

  (Incidentally, Ektron does a good job of this. You can make input forms with repeating elements that come very close what what the end result will be. Joseph Scott’s Edit in Place would do well here too.)

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.