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!

Posted by & filed under Communication.

Previously, we blogged about the new generation of inline notification, which will be used in context. However, in reality there are cases that users should be notified when they are out of context. For example, when a large file is uploaded to the system successfully, the user should be notified wherever he/she is in the system. In those cases, pop-over notifications  (toasters) should be used. Please check out the conceptual design below and help us refine the design.



Pop-over notifications or toasters are fly in or bubble message which pop onto the screen to notify the user of a system occurrence. The notification should be located at the top-right of the screen and there should be a message list that allows the user to view messages later. The notifications should have a consistent location in each application.


Pop-over notifications should always be transient and they should stay on the screen for at least 8 seconds, so that they won’t block the information behind it for too long and users will still have enough time to read the messages in the notifications. Ideally, the user can configure the notifications and decide what they want to see and how long they want them to stay. In addition, pop-over notifications should remain on the screen when the user is hovering on them.


Generally, there shouldn’t be more than one pop-over notification shown at the same time. If two notifications are triggered at the same time, they should be shown one by one, and each of them should stay on the screen long enough for the user to read.


Conceptual design


  • Icon: Indicate the type of the notification. There are four types of available notifications: info, success, warning and error.
  • Message: Show a short message within the notification and make it clear what just happened or what the user needs to perform next. Do not include any unnecessary text because the user might not have the time to read it. Ideally, the message is no longer than one line.
    • Bold the important information, e.g. name of the object
    • Use the regular font weight for the rest of the message
  • Action (optional): Show the action on the right to allow the user to take an immediate action without having to navigate to a different page. Clicking on the action button should either help the user achieve the goal automatically or open up a modal window on the top of the current page. After the user clicks on the action, the notification will be dismissed right away. Directing the user to a different page is not recommended. Do not include more than one action. Do not use the label Cancel, Dismiss, or Close, use icon instead.
  • Close (optional): Allow the user to dismiss the pop-over notification by clicking on the Close icon. Do not show Close icon and action in the same notification.


What’s not covered in the current design:

  1. A notification with multiple actions.
  2. A notification that has title and details.
  3. An expandable/collapsible mechanism that allow the user to get a little bit more details while looking at the notification.

Please let us know if any of these is needed in the application you are working on and if there is anything else we are missing in this pattern.


Next steps

  1. The visual design will be created and examples in context will be provided.
  2. Animation will be designed and demonstrated.


Feel free tell us what you like and what you think is improvable. Any feedback will be very helpful for us to refine the design in the next iteration. Thank you in advance!