|Fighting (with) Hierarchies – Part II: Presentation|
|Fighting (with) Hierarchies Presentation - Techniques I|
|Fighting (with) Hierarchies – Presentation Techniques II|
|Hierarchies – Categories vs. Vectors or: Solving the Problem by Dissolving the Cause|
|Simplifying for Usability|
By Gerd Waloszek, SAP AG, SAP User Experience –March 9, 2001
This article begins a short series on hierarchies. Hierarchies are a way to structure complex systems, such as organizations, technical devices, or software. In the software world, hierarchies come in many guises and are present nearly everywhere: you find them in applications, hypertexts, Websites, portals, operating systems, or data collections. For example, files on a hard disk, documents in a Website, functions and options in an application, as well as a computerized part list can be organized as a hierarchy. Despite this ubiquity, many users are not as experienced with hierarchies as some developers might believe; in general people have problems understanding and using hierarchies, which are essentially an abstract notion and not a "real life" object. In this series, I want to shed some light on the problems users have with hierarchies and also discuss their various uses and presentations in the software world.
This article covers some basics of hierarchies; a follow-up article will discuss the presentation of hierarchies.
Software systems are complex. They are among the most complex systems people have to deal with. Most mechanical systems, such as machines, cars, even airplanes, have fewer parts or parameters than some software systems. This complexity has to be cast into a structure so that people can understand and handle it. Hierarchies are often the first choice for a structure because the formal methods for them are well established. On the other hand, software programs are not only complex in themselves, but often deal with complex concepts and structures, such as large organizations (e.g. companies, institutions, administrations) or information (e.g. libraries, online help systems) , and provide users with mechanisms for displaying and manipulating them. Again, hierarchies are often the best solution for mapping larger systems or data collections onto an abstract structure. Essentially, a software hierarchy must handle and present two types of information:
Both cases can be mapped to hierarchies and presented as such. But is this an ideal solution? There are at least two problems with hierarchies:
I would like to point out that in my articles I refer to hierarchies as they are presented on the user interface; the internal data or application structure is of no concern here. The distinction between an underlying internal structure and the external structure, which is visible to the users, is an indication of an inherent problem in software design: developers often present the inner workings of software to the users because
Users, however, "think differently" and need a visual presentation which takes human abilities and limitations into account. I will return to this issue below.
Many sets or systems can be mapped to a hierarchy, often simply called a "tree" (although this term is not quite correct, I will use both terms interchangeably, as is done in most publications). A tree consists of two types of elements, nodes and leaves. Nodes represent hierarchical levels and may contain other elements, such as lower-level nodes and leaves. Leaves do not contain other elements and are the "items" of a set. For example, in a hierarchical file system, the folders or directories are the nodes, while the files are the leaves, that is, the actual "content" of a storage device. Nodes (levels) can be named: folders can be given folder names, categories can be labeled, etc.
Figure 1: Tree presentation of a hierarchy
|Classification, Taxonomy||Categories, Classes||Items, Elements||belongs-to, is-member-of|
|Organization||Organizational units||Persons, Employees||is-employee-of, belongs-to|
|Hierarchical File System||Folders||Files||is-in-folder|
|Outliner ("Idea Processor")||Headlines, Topics||Text Sections||belongs-to|
Table 1: Examples for hierarchies in the real world and in the computer world
Links between elements in a hierarchy can also be named. An item set might also have different types of links at the same time, which stand for different relationships between the elements of the set. For example, in a future file system users might want to have different indexing systems for accessing files.
Simple hierarchies are only a few levels deep. Therefore, they need not be presented as a tree, but can be presented as a nested (indented) list. A book index is an example for a simple hierarchy.
|1.2||Interpreting Sensory Message|
|1.3||Data-Driven and Conceptually Driven Processing|
|1.4||Some Perceptual Phenomena|
|1.4.1||Organizing Degraded Images|
|22.214.171.124||Organizing Auditory Perceptions|
|1.4.3||Organization without Meaning|
|1.4.4||Making the Data Fit the Conceptualization|
|1.5||The Importance of Rules|
|2.||The Visual System|
Figure 2: A book index (section)
A list is an ordered set of elements residing on the same level. The ordering may be alphabetical, by date, by size or by any other relevant criterion. A simple list might be, for example a shopping list. You can translate a list into a tree by using the list heading as the root node, while the list items are the leaves below it. This "trick" is popular among developers, but not good for the users because it makes the interface more complex.
Figure 3: Examples of simple lists
While in a hierarchy there are only strictly hierarchical connections between elements (i.e. there are no connections on the same level), a network may have arbitrary connections between its elements. The extreme case would be a network, where each element is connected to each other. Imagine, for example, a Website where you can navigate from each page to every other page.
Networks are often difficult to visualize, especially if they are large. If there are only a few "irregular" connections, a tree visualization can be used; sometimes "redundant" subsections are introduced to indicate "nonhierarchical" connections. In networks "loops" can appear; these present a problem for algorithms as well as for people who navigate within a net.
Figure 4: Small Website structure as an example of a network which is basically a hierarchy with some additional nonhierarchical connections.
First of all, a hierarchy is a static structure that expresses stable relationships between its elements. Classifications, taxonomies, or part lists are examples of static structures. In an organization or a Website, dynamic aspects are also involved:
Returning to the computer world, we find that static aspects correspond to the structure of software systems or data, while dynamic aspects correspond to movements within systems or data:
Obviously, the worst thing that could happen to a user is a system that changes its structure, while he or she is moving through it.
Formally, all hierarchies are the same; they are "generic." This makes hierarchies attractive to developers. Once they have successfully mapped a problem to a hierarchy, they know how to handle and display it – the methods for hierarchies are well established. Especially, they need not care about the size of the hierarchy, that is, its number of items, its depth, and its presentation details – a tree control will solve all problems. In practice, however, all hierarchies are not the same. The problem is not with the hierarchies themselves, the "problem" is with the users. People have difficulties in understanding and handling hierarchies; we discuss this problem in more detail below. Consider, for example, Websites to see that size matters much. There is a huge difference between designing a small Website and a large-scale site or portal with hundreds or even thousands of pages. In the first case, you may end up with of couple of fully interconnected pages showing all navigation options. In the second case, there may be many structural levels, which users have to traverse in order to find what they want.
The same applies to typical GUI applications, especially if you consider the choice of controls, or the way the functionality is being offered. For example, a simple application may do without any menus (see SAP's IACs); it may even happily reside inside a dialog window. Complex applications, on the other hand, need huge menu trees and many screens or pages. Small data sets or option sets can often be manipulated using simple controls such as radiobuttons, checkboxes, or dropdown lists. Huge amounts of data, on the other hand, may require extensive trees and suitable filtering methods.
User interface designers and developers need to know the problems people have with hierarchies; otherwise, they are unable to design easy-to-use applications and Websites. People are used to hierarchies in "natural settings," for example in organizations such as the military, the government, or a large company; they also easily understand the table of contents in a book. But note that these hierarchies are concrete, mostly static, and often only a few levels deep. Dynamic aspects such as movements are also of minor concern. Structural changes such as changes within an organization often get much attention and are a matter of hot debate. People seldom get disoriented in these natural and well-known structures.
On the other hand, people have problems with abstract hierarchies. They cannot create a suitable mental model for them because the system seems artificial, and often they do not understand what the categories mean. Deeply nested hierarchies cause even more problems because people get disorientated. People already get confused in mazes, where they only have to remember a larger number of binary left or right decisions. It is even easier to get lost in complex application structures, hypertexts, Websites, or the Web as a whole, if there are no "anchor points" where they can regain their orientation. People need to know where they are, why they are there, where they came from, and where they can go. Many, if not most, software systems neglect these elementary human needs.
Break down hierarchies for the presentation of data sets by transforming them into "flat" lists (linearization) or index-like structures only a few levels deep. Use relevant ordering criteria, such as alphabetical order to allow users to scan the list fast and easily. Flattening lists works better, the smaller the data set is. Be careful not to present small data sets as hierarchies even if the internal structure is hierarchical. The hierarchical structure may increase the set because it introduces additional categories, probably on several levels, which have to be processed and understood by the users. A simple ordered list is much more appropriate in this scenario.
Imagine you need to find a file on your hard disk – organized by a nice hierarchical file system – in order to finish a letter, but you forgot where you stored it and under what name. Then you may have a problem. Do you want to scan all the folders for it? This may take quite a bit of time. You can only remember that you worked on the file yesterday. So, wouldn't it be nice if you could search your hard disk using the date attribute and sort the results by recency? Luckily, most operating systems offer such a feature. A similar approach is used by Cooper's Shuffler, which is intended to reduce the need to browse large data sets and to display huge amounts of data. Attribute-based filters, often completely neglecting the "internal" data structure, are a useful tool for overcoming human limitations. But though they can make life much easier for users, they are still too rarely used.
Category names are more important than many developers believe. From a user's point of view, however, well-chosen category names are essential for them when searching items in a data set. Names or labels may be responsible for a user's success or failure at finding an item. Much time can be wasted if users randomly browse data sets without any sense of orientation. Even more time is wasted if they fail altogether to find what they are looking for.
Can you tell the difference between the old SAPNet high-level categories Communication, Information, and Service? The problem of meaningless or overlapping category names can be mitigated, if each label is accompanied by a few items or lower-level category names. Thanks to those examples, users easily grasp what a category stands for, and the category name itself becomes less important.
Application structures typically depend on the functionality contained in an application; they can, for example, be derived from a user environment design (UED). Websites that primarily present information derive their structure from the content to be presented. The process of defining the structure of a Website is an important initial design activity. A good strategy is not to start on the basis of a handful of high-level concepts, but with a set of 20 to 50 intermediate concepts. Invite users to cluster these concepts into arbitrary groups to which they themselves give names. After a while, the clusters will stabilize; now you can use them as predefined concepts for further clustering sessions (of course, the test persons can still propose new clusters or cluster names).
I mentioned the problems that mazes pose to people. People generally have problems remembering the path through a hierarchy (the sequence of decisions in a maze, the categories in a hierarchy, ...). So, if you want to impose a structure on a data set of, for example 500 or 50000 items, how should you design the structure so that people easily find the items they are looking for? Should you present a few or many items at a time? This is a classical dilemma when designing menu structures. The simple answer is that people prefer "shallow" structures. They want to see many items at a time and thus only click through a minimum of levels.
The classic solution is Miller's famous "7 plus/minus 2" formula, which states that people can only keep a small number of things in their short-term memory. Many people derived from this statement that menus should have no more than seven items per level. This idea was transferred to full-screen menus typical for character-based screens first, but was later extended to pull-down and other menus as well. You can still find statements that eight items per level and three to four levels are optimal (Landauer et al. 1985). But are they right today? Obviously not – Ben Shneiderman has long been a proponent of "broad" menus, as exemplified in the Yahoo! Website style; there are also many imitators of this style. Why are they right? Let's first have a look at the numbers: I ask how many levels are needed for 15000 to 30000 items if I display between two and 30 items per level:
You can clearly see that if a large number of items are presented at the same time, there is a dramatic reduction in levels. In the Web, levels are clicks. If we follow the common Web lore that no information should be more than three clicks away (a statement, which is debatable as well, but it's a good rule of thumb), it is evident that there is no alternative to breadth.
Why is breadth harmless and why are the people who cite Miller wrong? Because the user doesn't have to memorize the menu – that is to say, the link list. It's on the screen and available to the user. The memory problem is posed by the levels or steps to be remembered; that is why a route in a maze is so hard to remember.
Of course, the many links shown on a menu page need some structure. It is not sufficient for 80 links to be presented like an old list unordered or ordered. The items have to be grouped into categories, preferably one or two levels deep and suitably designed so that users can easily scan them and make their choices. Be careful, however, not to generalize these results to broadly. There is a difference between a link list and a pull-down menu, especially if there are cascading menus. Here, the menus should contain fewer items because they are arranged vertically and without internal structure, are only temporarily visible and – in the case of cascading menus – require some advanced mouse skills from the users, which distract their attention. Our lesson learnt is that generally broad menus are better than shallow ones, but also that the usage context and presentation style determines how broad a menu can be.
We stated already that the sequence of decisions, levels, or pages is what presents a problem to users because it overloads their short-term memory. You can support users if you offer them some sort of "Ariadne's thread" to help them out of the maze. There are two versions of this kind of support: