What happens on projects once the wrong path is started on is that we’re usually reluctant to turn back even if we don’t feel quite right about the direction we’re heading in. The problem gathers momentum the more time or money that has been invested into following the wrong path.
It is essential to overcome that hesitation. If a poor navigation structure is going to introduce usability issues (such as the case in the example site for this article), we need to fix that wrong structure instead of continuing to develop the site.
If we don’t, it will be more difficult to repair the damage later. When designing or redesigning navigation, we need to remember the needs of the user come first.
Complex navigation structures are rarely necessary. We just think they are when we first create them. What you need to always be doing is asking yourself if there isn’t a simpler way to achieve the same goal.
If there is a simpler way, you need to use it, because anything else, no matter how impressive it looks, will cost you more than it benefits you in the long run. In this article, we’ll use a live website example for simplifying a complex navigation structure to improve usability.
Step 1: Examine the existing design
The problem we are starting with is that the existing navigation design has excess complexity. In the case of the example site that we’re redeveloping for this project, that complexity seemed necessary, but only because a better way wasn’t immediately obvious.
First it will help to understand why the original navigation was complex in the first place. The subject site is a tutorial site, and the subject matter of the tutorials is for a rather complicated system.
Because the site uses a live emulator of the subject system for the student to learn on, it means we can’t (or shouldn’t) navigate from page to page. We need to display content by inserting it inline to avoid reloading the system constantly and having to save the system state.
Navigation links therefore don’t always redirect to physical pages, and most will redirect to virtual pages. Navigation in this case can be thought of as being divided into lessons, chapters, and topics.
The top navigation bar is already simple enough, although it could do with an updated look. When the user first arrives on the site, they will see the menu in the left column.
The user needs to choose a lesson from this menu before they will be able to see the individual lesson chapters and topics, as shown at Fig 2.
What makes this structure too complex is that there should not be a need for splitting the navigation this way (user can’t select top level navigation items without an extra navigation step), and numeric pagination is not ideal for topic selection.
It is easy, however, to understand the logic behind why the navigation was originally designed this way. The emulated device was created first and had a certain size determined by SVG code.
So the original navigation design is an attempt to save horizontal space so that both the lesson and the emulated device can fit on the screen simultaneously.
Now that we know the flaw in the existing navigation structure, it makes planning a new navigation design in the next step easier.
Step 2: Plan a new design
Because there is now more consistent (but still not excellent) support for CSS3 Zoom in the most popular desktop browsers, the emulated device can be zoomed to a smaller size without requiring massive amounts of re-coding.
If this is done properly, more space will be available on the left, allowing us to have an additional column in the middle.
The really obvious change is that the lesson body has been moved entirely away from the navigation area, which is exactly the way it should be.
This change will allow more flexibility in the navigation system, and will provide more room for the lesson body to be displayed.
Step 3: Implement the plan
Remember that each lesson can have multiple chapters and each chapter can have multiple topics. How do we deal with that? The easiest way is to make a collapsible stack of menu items. Expanding a lesson reveals its chapters, and expanding a chapter reveals its topics.
At fig 4 you can see the unexpanded list of lessons shown in the left menu.
Notice also the necessary addition of a navigation button in the lesson body. This is to remove the need for the user to always use the navigation menu to jump to the next or previous topic in the chapter.
This is what the user will see if they select a lesson from the left menu:
These somewhat cryptic looking links may not mean much to you, but for somebody training to be an aviator they are self-explanatory. Expanding the list to the third level will show the individual topic pages, as shown at fig 6.
As the list of links grows, a vertical scrollbar is added to the page. We could make the scrollbar attach to the menu itself by setting a fixed height for the menu.
External scripts, CSS frameworks, and fonts used in the above example include:
- Bootstrap v3.3.7
- Font Awesome v4.7.0
- Google Fonts: pompiere, concert one, varela round
These are by no means the only way to get something like this working, but they’ve been used in this project as a way to quickly achieve a web-safe solution without the need for too much coding or additional markup.
The constructor for the menu prototype is remarkably simple if you are using Bootstrap as your CSS framework.
At the first indent level, you create a div for the navigation area (here with the ID of “leftSide”) and a class div inside it to set up what properties the containing space should have. In this case we’re just using the standard “well” class that’s already predefined in Bootstrap (fig 7).
Inside this set, at the third indent level, we add a pair of paragraphs for hiding and displaying the menu (fig 8). The display property of each is important, as it will allow the links to work as a toggle switch.
What the hide function does is it shrinks the left column to width 40px (just enough to show the icon required for expanding it back to normal), and expands the middle column width to 50% of the viewport. Showing snaps everything back to the way it originally was.
Now we need to create a container to hold the menu items.
Then add the navigation item, in this case the “instructions” panel.
These are handled by an external script, but shown at fig 12 for the sake of completeness.
Back to the menu in our HTML file. A line break is added as a simple separator, then the remaining items will be added as a series of nested lists. The initial constructor is shown at fig 13.
From this point on, adding the remaining menu items is very simple. For the sake of brevity, only the addition of the first item set is shown, but the remaining item sets are added in exactly the same way.
All the items need to be added between the list tag pair, as shown.
The next menu item would be added by inserting a new line at line 75, and then following exactly the same procedure for item T1-L2, and so on.
Once all of the items (chapters) from T1-L1 through T1-L6 have been added, we would add a new line break, and then start a new list (as category T2), following the same procedures until the menu is completed.
The final step in our navigation menu overhaul is to add a script to make sure our menu items are initially shown unexpanded.
If your site isn’t getting the results you want, one possible reason could be that your navigation system is more complex than it should be.
Reducing menu complexity is an important step toward improving site usability. By making it easier for users to find their way around complex systems, you will be rewarded by more return visitors and possibly more referrals.