In Web content management, you can identify two types of pages fairly easily:
Free-form: A title and a big WYSIWYG area.
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.