Rethinking Website Navigation Structure in Higher Ed
Did you know that the first HTML website ever posted on the internet is still out there? It’s a good thing to take a look at now and then. It’s nice to read the text – the language that they used and the optimism with which it was used will take you back in time. It’s also helpful to understand just what HTML was designed to be and what it wasn’t.
The first website describes the web as a vast network of documents, each one able to reference any other one. Picture that in your head for a second. Did you imagine a full and complete document with occasional references to other things?
The reality of the first website, though, is a crude and poorly planned content hierarchy born out of the necessity to deliver content in small chunks to text-mode browsers.
Today, content hierarchies basically rule the roost of Higher Education websites. There are some immediate and obvious benefits:
- Simple menu construction
Menus can be constructed out of basic UL and LI tags to almost any depth or length.
- Complexity reduction
Being able to break the website into progressively smaller “chunks” allows developers and content editors to focus as much or as little of the website as they need to at any given time.
- Permission delegation
It’s relatively straightforward in a content hierarchy to assign a user to “this page and everything below it.”
For years this was also the path of least resistance. When we dealt with files directly using Dreamweaver or GoLive the site mirrored the structure of the file system on which we built it.
At work we use a Content Management System called TERMINALFOUR that organizes its content on the back-end into a strict hierarchy. Each page has the potential to be a “parent” to several “child” pages.
WordPress doesn’t organize its content this way, but it does force you to build menus as a structured hierarchy. It’s not the only way to go but it’s definitely still the path of least resistance.
In addition to the pros, there are some cons.
- Placeholder nodes
Every once in a while you’ll come across some pieces of content that can be grouped, but have no content for a page that collects them. You’re then left with the difficult choice of having inconsistent menu behavior, or creating a stub page that exists solely to contain other pages.
- Org-chart sites
Because we rely on the hierarchy when assigning permissions for editors, we often get locked into creating a site that mirrors the org-chart for the University. While this is easy for us to handle when managing the site, it doesn’t necessarily foster the best user experience.
- Ownership squabbles
Because the content of one sub-site is contained under some other sub-site, there will be unavoidable conflicts over who owns what and to what extent.
Temporal content is any content that is anchored to a specific point in time. There are a handful of ways in which you can present this content.
- Chronological order
Good for showing some sort of content where the latest piece builds on the previous (i.e. a conversation), or when showing content related to future dates.
- Reverse chronological order
This is best for showing news or blog posts with the most recent first.
This is our best random access memory analogue. If the user knows the date for which they want content, they can easily pull content from that date.
One interesting case study is the Twitter timeline. Content is presented in reverse chronological order except for conversations, which are presented in chronological order.
A taxonomy is any method by which you can associate a piece of content with a word or phrase and then use the word or phrase to find it later. WordPress by default allows for two types of taxonomy: Category and Keyword.
WordPress categories can be hierarchical, making them ideal for creating multiple buckets into which you can place items. Keywords are flat – they are meant to be assigned independently to articles.
The downside to a taxonomy is that it only gives you methods for filing content – once you pull a list of all the content that matches the terms you searched you still have to find some way to present that content. Because of that, taxonomies are often linked tightly with temporal content.
A wiki navigation structure places every page at the root level of the site. Site editors are not required to know how to find pages – they merely reference them by name and then the site software uses a process called disambiguation whenever there are multiple matches.
Wikis excel when it comes to creating an encyclopedia because that’s one type of application where each piece of content is an atom – a thing that is definable and understandable.
Rings had a bit of a hey-day in the 90s when everybody wanted to get into some sort of web ring. Each member of the ring would link to the previous and next member of the ring and in a way you’d form some sort of community. This was a big thing when search engines were bad and nobody could afford to pay for hosting just to list a bunch of friends’ sites.
Recently, sites like TVTropes and Wikipedia have revived rings as a sort of secondary navigation at the bottom of the page. The content you’re reading may be organized into a handful of categories which you can then explore by moving to the next page in that category’s ring.
On the technical side, this is just a re-hash of a taxonomy, but it can be a way to encourage idle browsing. Where ever you have a content carousel on your site, that’s a place where you could employ a ring tied to a taxonomy instead of maintaining that content manually. You’ll have to decide if the automation saves more work than setting it up.
A multi-site scheme for content organization is one where the main website is broken down into several smaller sites explicitly – not implicitly through a hierarchy. The most obvious example of this scheme is the WordPress multi-site network configuration which allows each site to have its own content, templates, and settings.
You can use this scheme in pretty much any CMS but a lot of it hinges on how automatic your CMS will make the process. You may end up having to enforce this scheme through a lot of manual intervention and setting up rules for your editors to follow.
Now we blur the line from content organization to pure menu display. A megamenu is a menu system that’s come up in recent years where each part of the main menu contains HTML content maintained manually. This allows you to blend the benefits of a hierarchy with a taxonomy and even present legitimate content within the menu.
The big huge downside to this, of course, is that it’s mostly manual. With a little work you can put dynamic elements within the menu structure, but you will still need some way to manually define what goes where in the menu.
I’m torn on this one, to be honest. My University’s users have varying degrees of comfort with HTML – most of the least-active users are HTML illiterate. I know that they would love to see a megamenu blazoned across the top of the screen, but wouldn’t know how to maintain it. The question is, then, whether they would see this as a roadblock to editing or as a challenge to broaden their knowledge.
Universities often rely on quicklinks as a way to provide commonly used tools to repeat visitors. Benefits include eliminating the noise for repeat visitors and speeding up their navigation times. The downsides: the complexity of having multiple menus on the page in a responsive (mobile) design and the political jockeying that comes with a site-wide list of 20 or so “most important” things.
I wouldn’t have titled this article the way I did unless I was actually trying to rethink my own University’s relationship with its content. We currently employ a hierarchical site structure (which informs our main navigation) as well as a meta-navigation bar (the “toolbar”) with quicklinks and live search.
The prospect of cramming all that into the header of a mobile website keeps me up at night, literally.
It’s a difficult nut to crack and finding some better way than “hamburger everything!” to present our navigation has kept me up with a notepad and Netflix into the early morning.
Our dirty secret is that even though TERMINALFOUR requires a strict hierarchy (every page must have a parent page) we often use Link Sections to insert links in our menus that redirect elsewhere in our hierarchy. When we choose, we can make an exception and place some sub-site at the root level of our website (or at the root level of one of our colleges’ sites) to simplify its own internal navigation.
Looking at our sitemap, however, we employ this exception a lot.
When the exception is more common than the rule, we need to change the rule.
What I’d Like To Make
Now, I’m not the webmaster here – I can’t just fiat lux these changes – but here are some ideas I’ll be proposing:
- Eliminate the toolbar and quicklinks, keep the live search.
The live search is fast and easy to use, and can get users who know what they want exactly what they want without us having to worry about departments jockeying for position or about wasted screen real-estate.
- Adopt a Multi-site and Megamenu site navigation scheme.
Divide the site into a collection of sub-sites with their own megamenus. It may be more work for us in the short term, and we’ll be asking more of our users, but it’s important to note that our needs when it comes to organizing content don’t always match with the needs of our visitors when navigating the site. Using megamenus to sever content organization and presentation can give us the flexibility we need to meet our visitors’ needs.
- Develop a system for noting affiliation.
The colleges, schools, and divisions rely on the hierarchy to show which departments, centers, and institutes are a part of them. Instead, we should allow for each one of those entities to exist as an atom at the root level and develop some alternative method for noting affiliation. I call this out specifically because our current site templates didn’t have this as a requirement and as a result we have some areas (e.g. an academic department within a college) where the site identification is unclear and sometimes even the subject of debate.
- Abandon the ownership lexicon.
This is probably too sky-high of a dream, but I would like to see us abandon our ownership lexicon when we move away from a content hierarchy for organization. It’s no longer helping to say “this is my site” or “this is their site.” The reality is this: every inch of the University’s website is the University’s – we are all just stewards. I maintain the University’s site about University Communications. The University Communications site does not belong to me.
It’s still early in the project and I don’t know if I’ll be able to convince others to join in on these ideas. I have a sneaking suspicion that some of these things have already been decided by people of higher rank and I just haven’t gotten the word yet.
At any rate, fingers crossed.