Posted by & filed under Navigation.


P>You should use a vertical navigation pattern when your application requires global navigation (i.e. navigation that persists throughout the application) that will be displayed in a vertical format anchored to the left-hand edge of the viewport.  While vertical navigation menus generally consume more pixels (i.e. more total area) than their horizontal counterparts, they have become more popular as desktop monitors move to wide-screen formats.  Vertical navigation has several advantages:

  • They are more extensible than their horizontal counterparts as the number of menu items in not constrained by the viewport width.
  • Vertical menus more readily adapt for small screen sizes.  While horizontal menus can also be made responsive, they usually require that they be transformed from horizontal to vertical below a certain screen resolution.  Since vertical menus are already in this format, the transition from desktop to mobile is less disorienting.
  • Finally, vertical navigation supports common left to right flow where navigation categories are easily differentiated from other information that may exist in the header area of the application.

Despite these advantages, it has been shown through research that the left-hand edge of the screen is the most prominent visually (along with the top header).  Using a large amount of this area for persistent area may steal pixels away from more important tasks, and therefore, strategies for hiding or collapsing vertical menus are an important consideration.

The Proposal

The basic format for a PatternFly page using vertical navigation is shown below.  This page requires only a single level of navigation as Dashboard requires no local or sub-categories.

Dashboard-select storage Figure 1: Primary categories fully exposed.

Notice that the selected state and hover states in the menu receive unique visual treatments.  This will help ensure that the user always knows where they are and has sufficient visual affordance to call out active elements.  Icons are included with the text labels to speed recognition. The visual design of these elements is still a work in progress.

When a page needs to expose a secondary level of options, an additional persistent column is opened to the right as shown below.

Storage -Volumes Figure 2: Secondary categories exposed in an additional vertical menu pane.

Here, a secondary set of categories is exposed in the subordinate menu.  Selected and hover states are also important here to make behavior visible.  The example shown here includes an additional hierarchical grouping of secondary menu items and added indicators to reflect the number and status of items in the exposed categories.  These elements are entirely optional and may be used to reflect specific requirements driven by your information architecture and user cases.  When including these added elements, one must always take care to consider the benefits of providing users with this feedback against the potential visual clutter it may create.  In all cases of navigation design, providing users with a clear map of where they currently are and where they can move to should take precedence over other considerations.

Another design goal was to be sensitive to the user’s need to get navigation out of the way and focus on content.  The current proposal provides for that is two ways.  By clicking the menu icon in the upper left corner of the page header, it will be possible to toggle the state of the primary navigation by collapsing it into a thin strip of icons that cling to the left-hand edge of the viewport as shown below.

Figure 3: Vertical navigation with primary navigation in collapsed or minimized state.

If one only wishes to collapse the secondary menu, they may do so by clicking the collapse button on the secondary menu pane as illustrated in the second wireframe below.

Admin-Full Width Figure 4: The secondary navigation menu can be hidden by toggling it closed.

What’s Next?

We will continue to elaborate on this design and evolve a full visual treatment of the concepts presented above.  Some of the questions left to be considered include:

  • How to include badges and indicators on menu items without introducing undue clutter.
  • When icons are useful and when they should be applied.
  • The integration of breadcrumbs and drill-down patterns for browsing hierarchical data sets.
  • How to handle secondary navigation when persistence is neither necessary or desirable.

Your input and feedback on any and all of these topics is much welcome!

3 Responses to “Vertical Navigation: Finding your Way”

  1. Matt, this is a great way to utilize the available space on a wide monitor. OpenShift has a small secondary navigation menu that does not need to be persistent. We’ve adapted this concept to to a flyout menu for secondary nav that sit over the main content area and will collapse once a selection is made or by manually collapsing the menu.

    • Yes, I agree that there are places where it does not make sense to persist the secondary navigation. Do you have a working example of this that you can point me to?


Leave a Reply

(will not be published)