Martin Colebourne

Many aspects of user interfaces can be thought of as hierarchies, some explicit and others implicit.

• Website menu structures are a form of explicit hierarchy: they seek to give navigational access to a set of pages.
• Application menu structures are also explicit hierarchies. Except that they contain functions rather than navigation.

However, thinking more laterally, the structure of an Application, or a whole Operating system can be seen as an implicit hierarchy. This post explains how a UI can be viewed as a hierarchy and explores those hierarchies to identify a number of properties that the designer can keep in mind when creating and analysing software.

USER INTERFACE AS HIERARCHY

Imagine opening an application to its default starting state – let’s take a word-processing program as an example – it opens with a new blank document. The first level of the hierarchy is made up of all of the possible actions that you can take from that point:

• Type into the document itself.
• Access a menu or use a control on the toolbar / ribbon / inspector.
• Access the right-click menu, bering in mind that there may be multiple contexts that can be clicked on.
• Utilise a keyboard shortcut of some kind, e.g. Ctrl+V to Paste.
• Click on the window controls to minimise, maximise or close the application.
• Grab the titlebar to move the window.
• Use drag and drop to pull content into the document from elsewhere.

The same kind of thought process can be applied to the Operating system itself. Examples of first level items include (using OSX as an example):

• Clicking on an application in the dock.
• Clicking on the Apple menu.
• Clicking on a menu for the current application (likely Finder on startup).
• Clicking on one of the service icons at the top right.
• Using a keyboard shortcut, e.g. CMD+Space to access spotlight.
• Using a function key, e.g. F4 to view Launchpad.

As you can see, in some cases, these initial paths continue into recognisable hierarchies (tree structures), whilst others are stubs – with no children, or only a small flat list.

In some cases, e.g. a toolbar, there are a significant number of items at the first level of the hierarchy. It is also notable that some items are more prominent than others – they are bigger, more colourful, or more centrally placed, whilst others are smaller, less colourful and placed peripherally. Some are even ‘invisible’ – they have no visible ‘handle’ on the screen, meaning that the user has to know how to access them. The range of prominence is a ‘hierarchy’ of its own.

Hierarchies are a fact of life, rather than a design choice. In the vast majority of cases in software there are a significant number of possible actions or destinations, showing them all with equal weight would probably be impossible and certainly undesirable. Using a hierarchy allows for a large number of options to be ‘folded up’ into a set of tree structures, reducing the number of choices at each level and grouping like elements to aid discovery.

IDEAL STRUCTURE

At first glance it might seem that the ideal structure to aim for would be a perfect pyramidal tree, with an even distribution of options into a branching hierarchy with an equal number of choices in each level.

Supposing that we had 1000 items to choose from, a regular structure like this could reduce the task to a choice between 10 items, repeated 3 times; meaning that the user would only need to interact with 30 labels instead of 1000 – an exposure of just 3%.

However, it should be clear to anyone with design experience that this is not realistic, because it forces the user to navigate three levels for every option, reducing efficiency. In any real situation, all options are not equal – some are important, others less so; some need to be accessed quickly or frequently, others only occasionally. Some options could be very useful to an experienced user, but are unlikely to be used by a beginner; or they will be frequently used by one type of user and not at all by others.

These inequalities mean that the best answer is actually some form of skewed tree – often highly skewed. Frequently-used actions can be made easily accessible by placing them at the ‘root’ of the hierarchy, i.e. displaying them directly in the UI. Doing so also makes them easier for beginners to find and makes their use more efficient by reducing the number of clicks needed to activate them.

Less frequently-used options can be sequestered away in the lower levels of a tree structure that extends from an entry at the first level. This approach reduces the ‘root complexity’ of the overall structure by reducing the number of items at the first level, without hiding all options deep in a tree. The tree structure can group related functions together, aiding discoverability; and can be designed to aid scanability, easing the user in finding the option they need on the rare occasions that they need it.

Actions which would be frequently used by experts, or by a subset of users can be made easily accessible either by allowing the user to customise the tree – choosing to display those actions directly in the UI (e.g. by customising a toolbar); or using ‘invisible’ access methods like keyboard shortcuts and right-clicks. These methods require learning and internalisation, but the payoff for those users is sufficient to justify the investment.

BLACK HOLES

One danger implicit in the creation of a skewed hierarchy is the creation of ‘black holes’. Fundamental to the concept of a hierarchy is that the user is exposed to only one level at a time. This creates the benefits of the hierarchy, but also creates the challenge that it may not be clear that some options in a level have no children, whilst others conceal deep trees of additional options.

A ‘black hole’ occurs where one branch of a hierarchy is dramatically and unexpectedly large, concealing vastly more capability that a user could guess at from its initial representation. To understand this, let us consider one example: the Browser. Consider that you are a naive user, coming to computers for the first time. Amongst the options presented to you at the root level of the operating system are various application icons. Many of these lead to significantly complex programs – even a basic word-processing application has hundreds of functions. However, one of the icons leads to a web browser and this in turn leads to the billions of pages and web apps of the Internet. A universe of possibility is concealed beneath that one icon – vastly more than any other application. This is a ‘black hole’.

It is my assumption that designers should avoid creating black holes, but this requires further analysis. It may be that they can be reasonably justified under the right conditions on the basis of the principle of one-off-cost.

ROOT COMPLEXITY

Another interesting consideration in the analysis of UI as hierarchy is the concept of ‘root complexity’. This refers to the visible complexity of the first level of the hierarchy – its ‘root’ level.

Imagine an application that has 15 menus, 50 toolbar icons and a sidebar with another 45 options in it. This application is high in root complexity – there are 110 things for the user to click on directly. All 110 can in theory be accessed quickly and efficiently, but in practice, the sheer number of choices and clutter of the UI mean that it is too complex and the user is likely to suffer as a result, unless they are prepared to invest significantly in learning the interface. Reducing root complexity is therefore likely to be a good strategy for improving usability for average users.

However, when combined with user customisation, high levels of root complexity can be seen as a good strategy. Think of the notion of Apps and an App Store, as popularised by Apple with iOS. The huge list of Apps that are available via the App store can be seen as a form of extreme root complexity. Admittedly various methods are employed to mitigate this, e.g. Recommendations, Trending, Categories and Search. However, the point here is that there is no attempt to place Apps into a tree. At one level, this is certainly overwhelming. However, the trick is that the user chooses from this complexity only those Apps that they find useful. These are captured in the user’s start screen, leaving the user with a relatively low level of root complexity to deal with day to day. The principle of one-off-cost, along with the ability for users to choose completely different sets of Apps justifies the approach.