|Reducing the user interface|
This paper discusses ways that you, the developer, can reduce the user interface to better manage the explosion of data and product functions. A variety of techniques are discussed, and these recommendations should not only make your UIs easier to use, but should allow your users to be more productive.
User interfaces are constantly getting larger and more functional. There's probably a simple exponential growth function similar to Moore's Law that could describe it, but whatever it is, the key is that UIs keep expanding. Many applications have far more data and functions than a single user would ever want or be able to use. This paper focuses on, among other things, ways to enable users to quickly filter down large data sets and to limit functions based on their job roles.
The growth of UIs is evidenced by the huge growth of stored data. For the first time it's been predicted that more money will be spent on storage this year than on servers. We're a data-rich society. To deal with this exploding trend in data growth, UI developers have taken greater care lately in formatting the data in efficient presentations such as tables, trees, and charts. To keep up with the trends, table controls are continually being enhanced, most commonly with capabilities such as sorting and column reordering. Tree-based controls, such as cascading menus and navigation trees, are also becoming more common. And macro combination tree-table controls, such as Windows Explorer, are showing up everywhere.
From the functional perspective, UIs are also growing. Tool bars are filling up with more icons, necessitating more tool bars to hold all the buttons. Menu pull-downs are getting so long they need to wrap to additional columns. And because one user needs a certain function, all the other users typically get the same function whether they want it or not. So, users end up having to sift through lots of choices to find the relevant ones. It's enough to break the spirit of a novice user.
With all this data and all these functions, we need to consider ways to reduce the user interface, through such mechanisms as automation or user controls. Although some solutions discussed might seem like extra work, there are many simple enhancements that will also improve usability. Almost all UIs can benefit from good reduction techniques. It's typically good for UI designs to present their data in a comprehensive, high-level summary overview. Then, with tightly coupled and fairly seamless filtering mechanisms, you can give users the controls they need to quickly scope the UI to only the relevant data. This paper also discusses some basic filtering concepts and how to apply them to your solutions.
Part 1 - Reducing UI data
The top of the table is where you typically add column headers that title each column. This is also where you can fairly seamlessly add sorting and filtering controls to give users a tight-coupling of the user action (for example, a sort or a filter operation) and the resulting data presentation. Providing sorting using the column headers is becoming commonplace; perhaps more interesting and powerful is providing users with the capability to do inline filtering on table columns.
Figures 1 and 2 below show how such filtering capability can be used to powerfully and progressively filter out the non-desired rows of data items. In Figure 1 the "Group Name" column has already been filtered to include only those names with a "t."
Figure 2 continues the same example, showing the table filtered again after the user has typed another letter, making the text string "ti," which has greatly reduced the table's contents down to one data item. With such inline column filtering, tables that have thousands of rows can be quickly filtered to just a few desired rows in a few seconds. It's a fast way to sift out a large amount of data and help streamline the user's task.
Figure 3 is a dynamic example (animated .gif) of the power of table filtering. It shows a slightly more complicated table with an intermediary dialog for the user to define and enable the filter. This is useful when there are multiple (potentially infinite) filter settings for a column. Users can also set a filter (not shown) with a selection from a drop-down list of choices, which can be useful when there is a well-known set of possible filter settings, but not so many as to be unwieldy.
You can extend column filtering to specialized tables. The following is an example of applying filtering to a selection table, which is a table primarily used for quickly selecting and unselecting rows. Mail programs often use these (for example, Notes), as do newsgroup readers and the Tivoli Console. The examples in Figures 4 and 5 use Tivoli's SF (sortable/filterable) Selection table to show how you can let a user quickly select a subset of possible choices after applying the filtering criteria. In Figure 4 the user is presented with a large list of people to select from. However, in this example, the user doesn't care about anyone who is not from the city of Apex, and would like to quickly filter out the irrelevant table entries.
To select everyone who lives in Apex, users would first filter on the "City" column to only include people from Apex. Then, they could easily swipe select all the remaining entries with the left-side selection column, or by a "select all" function from a context menu or shortcut keys. The resulting filtered and selected table is shown in Figure 5.
To help the user sift down to a workable set of desired data elements you can use multiple filterable tables per panel. This could be useful in a Find type of dialog, with perhaps one table to filter the data set before showing the results to the user, and another to present and accommodate the user in further filtering the data displayed as Results. Figure 6 shows an example of this, with the Find criteria in the upper half of the panel, which includes a filterable selection table (that is, "Resource Type"), as well as other filter fields to the left of it. It also allows the user to further filter down to the desired data set with a filterable table in the Results section. However, because the user's initial query was fairly successful in this example (that is, the data set was reduced to a very manageable five items in the initial Find query), further filtering will probably be unnecessary in the Results table, at least in this instance.
One major limitation with trees today is they don't work so well with large data sets that cause a deep (many levels) and/or broad (many peer nodes per level) tree structure. This can require lots of scrolling (and risk of getting lost) in the levels of a branch, so it is usually recommended that peer nodes be kept to a few dozen or less, and that non-container leaf nodes not be displayed in a tree. These restrictions are meant to keep trees small enough to be usable, but introduce other complexities such as additional navigation controls elsewhere to compensate (drop-down menus to seed a tree, a secondary tree to the right of a primary tree, etc.).
Another problem with most trees today is that their container nodes typically only filter on an all-or-nothing basis ("expanded" or "collapsed"). This makes it hard to find things in a large tree because irrelevant branches and nodes can get in the way. However, node filtering capabilities can be provided between the two extremes, while simultaneously putting the filter control inline as an integrated part of the tree control as shown below in Figures 7 and 8.
Figure 7 shows a fairly standard tree. Two of the container nodes are expanded (no filtering: "TME System" and "Gateway Raleigh") and one completely filtered, or collapsed ("Gateway Austin"). However, if the tree could be more meaningfully filtered so as not to show irrelevant nodes -- perhaps by a context menu setting or a simple filter dialog -- then it might look like the reduced one shown in Figure 8.
Note that the tree has been "pruned" by its user to show only errors, which are shown with red underlines beneath each node icon. The "twisties" are also analogously twisted half way between fully opened and fully closed to help indicate the partial filtering. In Figure 7, the container node "Gateway Austin" is filtered out of view because it contains no error states. This example shows how many irrelevant nodes in the user's environment can be quickly filtered down to only the ones of user interest.
A range selector is a commonly-used control that lets users quickly filter chart data. The one in Figure 9 shows a range that is currently selected to be between 35 and 55. Users can quickly adjust either end point of the range, or slide the entire shaft of the range selector to move both ends simultaneously, to get to the desired range of values.
Figure 10 shows an example of multiple range selectors and drop-down lists as filters tightly coupled with a chart UI. In this parallel coordinate charting example, as a user changes the "Free Drive Space" to limit it to a range between 5 and 30MB, the chart quickly is reduced to a small subset of the entire set of possible links, allowing the user to quickly diagnose a problem source. Users are given the power to quickly bring elements into and out of the display, which allows them to quickly weed out irrelevant data in their quest to find the essence of a complex problem.
You can also enable similar chart reduction techniques for other types of graphs, such as line graphs and bar charts. If a chart is unwieldy or complex, or if you need to present loads of data, consider adding filtering capability. It's a powerful way to let users take control and reduce the less relevant information.
Part 2 - Reducing UI functions and tasks
In the portfolios in the examples above, some of the potential tasks are different for each user type (technicians can "Work with Events" while their supervisors can only "View Events"), and some tasks are possible for both user types ("View Problems"). Overall, the huge array of possible functions that might be available in an application is automatically and appropriately filtered for the different user types.
For example, technicians need to close out problems as they complete them, whereas supervisors might never do this, so they shouldn't be burdened with the choice. And if a user never needs to do something, his or her UI will be simplified if it's never shown. Chances for errors are also reduced. As you implement a role-based filter, be careful not to disable (gray out) user-inappropriate tasks if they are never possible, because this would only clutter the UI and also be misleading, as it might prompt users to think they could tweak some settings to enable the never-needed functions.
Now let's look at the banner area at the top of Figures 11 and 12 (wedged between the title and menu bars). Along with key summary statistics that a specific user type might need -- such as problem description, problems open, etc. -- key functions could also be presented here. In this example these are provided by pushbuttons ("Done..." and "Summary"). There are many other ways that role- and task-specific functions can be made available, such as by menu choices, tool bar buttons, panel pushbuttons, or status bar indicators. The key is to really know your user types and to understand the tasks they do, which can be accomplished with a user and task analysis.
Importance-based filtering: One way to use prioritized filtering is to vary the level at which a choice is presented. For instance, if you use Windows Explorer every day you might want to put it in the top level of the Start Menu, or on the desktop for even higher access; the higher its level in the UI, the easier it is to access and use.
An example that shows the commonly-faced trade-offs between presenting a choice at two different levels is shown in Figures 13 and 14 below. Figure 13 elevates the "Close" action to a highly accessible level for each open view in a console. Figure 14 shows another version of a view area in which the "Close" action has been filtered out of the top level UI, but is accessible by surfacing a menu upon "right clicking" an item in the view list. If an action or setting is rarely ever done by most users, you would help them by filtering it out of the top UI levels -- "burying" it in an "Advanced..." dialog. And perhaps the greatest demotion you could make for a functional setting would be to relegate access to just a flat configuration file.
So, where should the "Close" function be put? For everyday design dilemmas like this, it's often not so simple to ascertain. Usability testing can often settle such issues, but it's also good to think through the possible pros and cons even if you are fortunate enough to afford to do usage-based evaluations. Some of the tricky trade-off decisions you might balance as a UI developer are shown in Table 1 below.
Table 1 - Design trade-off matrix
Frequency-based filtering: Another way to prioritize actions is to manipulate their visual prominence based on usage history, which reflects the frequency of use. Microsoft has done a lot of this type of dynamic and automated filtering; one example, shown below in Figures 15 and 16, is historically-prioritized "Personalized Menus." The user initially sees just the filtered menu (Figure 15) unless a time delay is reached or the double-down chevrons are clicked, in which case the user sees the full unreduced menu as shown in Figure 16.
In Figure 16 below, the user sees all the possible peer choices in the drop-down menu; however, there is still some level of filtering at work. The more recently accessed choices are made more prominent by a darker gray background color, which could potentially provide a heuristic to users to help guide selection.
Be extra careful when using methods like this, especially if you are totally changing the way a system currently works. Use a conservative default, which in the above example would be for users to see all choices unless they choose to filter any out. Defaults should typically be aimed at non-expert users, for they might not be able to easily turn off a potentially annoying setting.
There are many ways to vary the visual prominence of choices in order to affect filtering for the user. Presenting a history list of the last 10 or so files worked on with an application is another good example of bubbling up the most likely choices. In general, the less prominence a choice is given, and the lower the level a choice is presented, the more it effectively becomes filtered out. A choice might not be completely reduced from possibility, but it can get diminished to a lesser and more appropriate access point. Users are also able to use this type of frequency-based filtering as a heuristic to help guide them. If they are seeking a primary function, they aren't going to look for it at the lowest levels of the system.
The red box in Figure 17 represents a "trip zone," where mouse movement is monitored for an interface object within it, which in this example is the portfolio tab. The portfolio tab needs to be either "moused-over" or clicked to open the portfolio, which contains the menu of possible tasks for a user, so the tab is a very important UI element.
During early usability testing of the Tivoli Console, we discovered that users had difficulty opening the portfolio with a mouse-over. We used the standard mouse-over delay of 600 milliseconds, which meant users had to put the mouse pointer over the portfolio's tab for six-tenths of a second before the portfolio would automatically open. This probably doesn't sound like a long time, but it was enough to disrupt the user's task flow and also cause frustration. It was also long enough that people didn't realize it could open on mouse-over. So, we then decided to see if we could assess the user's intent and then reduce the latency period when their intent was to open the portfolio; if a mouse pointer is moving toward the portfolio tab, if it is slowing down, and if it is moving slowly near the tab, then the chances are likely the user is trying to select it.
In Figure 17, the upper mouse-pointer track (in green) shows the pointer slowing down and heading toward the tab. Chances are the user is intending to select it, so in this case the mouse-over delay could be reduced to approximately 200 milliseconds. By not decreasing the delay to 0 milliseconds, or even automatically opening the portfolio before the user reached the tab, we are not being too potentially annoying for the cases where we incorrectly assess the user's intent.
It's also worth filtering out the very slight movements of the mouse during this delay period, which could cause the delay period to restart, further exacerbating user annoyance. The problem with not having a delay is that UI elements could spring up and be distracting if they are activated for unintended targets, especially as the pointer is quickly moved across a number of these targets. But if the user were on the lower mouse-pointer track in Figure 17, which shows the pointer not slowing down and not heading toward the center of the tab, chances are likely that the user is trying to access an object other than the portfolio tab.
Shaving off much of the delay period based on anticipating user intent could be beneficial for users in completing their tasks. It also could provide the benefit of decreasing the width and size of target areas to compensate for the advantages gained by this design's tracking and accommodation of user intent. You can add intent-based filtering to many interface elements such as tool tips for things like tool bar icons, menu pull-downs, zoom buttons, and so on.
There are many other types of information reduction and organizing techniques that could also be helpful. Searches, sorting, and queries are some related topics that might be relevant. In addition, there are useful ways to save filters and make them customizable. There are many related areas that are well researched, as well as ones that are ripe for more study. But any way you look at it, tremendous gains stand to be made through effectively applying information reduction techniques to the UI.