Left Navigation Ideas

Most of this page is a previous version of the parent page.

Description

The left navigator or tree is used today as a way to explore the contents and attributes of a platform. While this gives the user a way to access tons of information, the current organization of the tree has some unexpected behaviors and creates tedious navigation in some cases, obscuring the most important or frequently accessed information. A new design is proposed to increase the usability of this feature.

Some of the suggestions here are based on a previous UX analysis of the tree with alternative design ideas.

Platform-centric navigator

Currently, when a user navigates into the RHQ UI, the tree is platform-centric or infrastructure oriented, showing a given platform system as the root, and below this are nodes for application servers as well as physical system resources like CPUs, network interfaces, file system. Currently these are mixed in alphabetic order and the hierarchy becomes very deep in some cases.

An example of the platform-centric view today illustrates the concerns mentioned above

Platform-centric cleanup

The behavior of the tree should match user expectations based on the tree in Windows Explorer, which is probably the most common tree widget in the world. In particular, these best practices should be followed:

• All nodes in the tree are navigable - can be clicked at any time and show some kind of information on the right
• Tree nodes can be opened and closed by the user at any time without restriction
  • nodes do not collapse automatically - user can open as may nodes as they like anywhere in the tree.
  • opening and closing nodes is independent of navigation except when a child is in focus.
  • when closing a parent of a child that contains your current focus, move focus up to the parent
• Essentially, follow completely the interaction behvior of Windows Explorer

Specific change recommendations, generally in order of urgency:

• Remove redundant naming on the nodes, simplify all labels as much as possible. Specifically doing this here in the tree should not mean removing that context elsewhere where it might be helpful.
• Elevate servers to the top of the platform tree. Each server folder contains folders of apps by type, if necessary.
• Group all physical resources under a folder called "System Resources."
• For the sake of consistency, use folders to contain even if there is only only child. In other words, if there is only one of something, we still "autogroup" for consistency
• Use common visuals for objects as much as possible
  • Use a folder icon for containers in most cases
  • Reduce number and variety of icons to create more legible tree
  • Keep badges where they are absolutely useful
• Remove child count numbers in parentheses
• Consider removing color coding on labels - users should be able to troubleshoot via other parts of the UI, without relying on the tree as the source of alert information.
• Improve the expand/collapse arrows so they are more legible and easier to click.
• Remove tree 'connectors' imagery

Things to consider adding to the tree

• extension point to add and remove individual nodes
• extension point to provide custom navigation - for example, a mode switcher for the tree. Note - this isn't too different than the mockups, except it adds an explicit switch to the left panel.
  • why not have dropdown or tabs that let you re-root or get a less verbose view of the platform
  • filter out all the extra stuff - so instead of seeing all, just show me a specific jboss app server.

Mockups

Application-centric navigation

This design does not address the need for users to have an application-centric view, where the application is the most important object, and the physical hardware supporting it are treated more like supporting context. This type of view might be the primary entry point for many users, and should be addressed elsewhere in the application.

Moving forward we need to promote a more application-centric model because we believe this is how many users think and want to operate. In this view, individual platforms are not the root of the tree or the primary means of navigation. Instead, users orient first by application (type?), and then may explore specific platforms in the case that they do care about something happening on a specific piece of hardware. We would of course allow then to pivot on that hardware in order to drill down to specific details and troubleshoot, for instance.