Now I am out the other side of a university website redesign I have time to return to an article I read while in the midst of it: Menuing in Content Management: Implicit v Explicit

I found this article at a time when the project I was working on was experiencing menuing difficulties. Specifically, how to get the CMS to produce the menu system the design called for. The IA of the site had been designed with a relatively shallow menu system as an antidote to the previously very deep menu system that had grown somewhat organically over time. Once the site was put into the CMS we noticed the menu system was not that which was originally designed. Sure, all the content was there in the same structure dictated by the IA. The paths to that structure however were horribly deep.

The CMS was set to dynamically build the menus according to where the content sat in the backend. So every time a page was created a new menu item was created and placed according to where the page sat in the directory structure. Ugh. I could see how the menus on the previous site had become so out of control. In an attempt to make website maintenance easy by creating menu items for you, the CMS was becoming somewhat inflexible. (As a Mac person I see this as similar to a Windows problem: the system tries too hard to make things too easy, in the process basic tasks become convoluted and the system itself becomes inflexible and annoying. For example, who finds Clippy the paperclip ‘helpful’?)

To get around the problem we had to create a set of ‘minisites’ that forced the system to create menus as they were supposed to work. The backend organisation then became rather wider and less deep than the original setup. Several people expressed concern that the backend was becoming messy but others (including myself) expressed concern that the dynamic menu facility and the desire for a tidy backend could not dictate navigation paths on the site.

You can see our dilemma. As an IA I would fight tooth and nail to make the CMS deliver the structure and navigation paths called for in the design. People more focussed on the CMS itself would fight for a clean and tidy directory system. What was difficult was trying to get the concept of navigation as opposed to structure understood. The problem was not that the relationships between the information in the IA was not working, it was that the menus as represented on the page were not creating the correct paths that would make the information accessible. Also, the idea that sometimes the way the information is arranged does not always reflect the navigation was a curly one for some. Sometimes the navigation is different in order to accommodate users needs, expectations and web conventions. The trick is getting the navigation to give the user a mental picture of the site that is backed up by logical organisation of information. It’s a very fine line between the two and sometimes getting the balance right is difficult.

Another difficulty comes about due to the fact that IA work for university ‘corporate’ websites is not always straightforward. Due to the fractured nature of the organisation where every department/school/faculty has its own identity and the wide range of potential audiences for the site, it is almost impossible to design a ’single’ university website using one approach. Rather, a university web presence needs to be approached as a set of individual sites attracting different audiences, with varying needs and expectations. The reality is though that single audience members need to traverse a number of these sites in any one visit so paths to information are critical. These bridges between sites can make or break a successful and seamless visit.

Such a situation does not lend itself to the tree-like approach to navigation that is required for a dynamic menu creation situation as described above. There will always be some tweaking and hacking, for lack of a better term.

The post from Gadgetopia then gave me some respite in that it reminded me that this problem was not uncommon and that there was no real answer in terms of which is better: “explicit menuing” (which requires more maintainence and provides more control) or “implicit menuing” (which require less maintenance but give less control).

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.

What we were creating was somewhere in between where the structure of the site does reflect the menuing but not as implicitly as the CMS wanted to have it. Considering this, I will be interested to see how the site copes with growth in a devolved authorship environment. Control of structure is important in this case and in such an environment it can prove difficult, but discussion of THAT little problem is for another post.