Menuing in Content Management: Implicit vs. Explicit

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.