Channeled Interfaces: Hiding the Big Picture

A while back, we discussed content trees, which are a great way to organize content in a CMS. They provide a great view of the entire landscape of content in your system. However, not all CMS users are created equal, and some of them may not need to see “the big picture.”

You have a number of different people working with your CMS – developers, administrators, editors, and the “standard” content contributor. This last group is probably constrained by the type of content they develop.

For instance, the PR department may only be allowed to post press releases to the Web site. This being the case, do they really need to see everything? Content trees can be intimidating things, and they can lead to confusion and all sorts of questions.

Furthermore, there’s a good chance that press releases should only go in one place in the tree – the folder called “Press Releases.” In these cases, browsing the content tree is just an pointless step, since there’s only one place they can put their content anyway.

Enter “channeled interfaces,” which is a really snazzy way to refer to “wizards.” In these cases, the interface constrains the user in a “channel” bounded by what they’re allowed to do.

I’ve seen this in a couple different CMSs now. Besides the normal permissions model, there are two “levels” of users – the users that get to see the big picture, and those that don’t. Consequently, there are two interfaces.

The first thing to disappear in the channeled interface, it seems, is always the content tree itself. In both cases I’ve seen, the channeled interface was conspicuously missing the tree, the assumption being that these users can create content, but shouldn’t be allowed to organize content because that’s handled on a larger scale than they’re qualified or that they care to manage.

Channeled users generally just get a home page that says something like, “Create a New Press Release.” This takes them straight to the press release edit form where they can create one, which then gets automatically routed to the correct folder in the tree and submitted to the correct workflow.

When I was working with Documentum’s Web Publisher, I was an administrator, so I saw a big, complicated interface. I was nervous about exposing our end users to it, because it was a little overwhelming. So I was pleasantly surprised when I logged in as a simple contributor for the first time and was presented with a control panel with “Create a new __” links for everything that user was able to do. One click, and they were in an editing interface.

If your system uses a content tree, you need to place the content once it’s submitted. This is important, since it’s the one big step removed by the channeled interface. There’s a simple and complex way to do it:

1. Just tie locations to content types. Press releases go in this folder, period.

2. Allow some programming and derivation. An event model could let you capture the submission event and derive the location. For instance, an event hook could look at the current time, and then put the content in “Press Releases/2006/June”, for example.

Perhaps the location is determined by content on the object. If the user selected “Products” as a subject, then your event could examine the object and put it in “Press Releases/Products”. (Then does it keep the property, or throw it away since it’s only used for placement?)

If your CMS doesn’t support channeled interfaces, you can probably build them with an acceptable API. You can hardcode a form and create a little “mini-interface” like we discussed a few weeks ago.

However, you’re now presented with the odd circumstance of having to deny these users access to the standard admin interface. Your channeled interface isn’t going to constrain much if they can just log into the standard interface at any time. And, alas, it would take some serious forethought for a vendor to include a “Deny admin interface access” option.