Contents: Part 1 - Reducing UI data Part 2 - Reducing UI functions and tasks Conclusion Resources About the author Rate this article Subscriptions: dW newsletters dW Subscription (CDs and downloads)

Mark Molander (moland@us.ibm.com)
Human Factors Engineer, IBM
01 Jun 2001

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 amount of UI users have to deal with can be reduced, or filtered, for various high-density presentation formats such as tables, trees, and charts. Filtering options for these three popular formats are described below.

Table-based filtering
Perhaps the most popular data presentation format is a table. Many UIs have at least some table structures, such as user lists, resource lists, logs, mail, and so on, and many UIs can be thought of as primarily tabular. Table interfaces are ideal for many data-rich situations because they can present a lot of data in a tight space while being very structured and functional. Tables are two-dimensional, so they can efficiently fill a two-dimensional container -- be it a Web page, a frame, or a window. They can also accommodate controls within the cells such as entry fields and drop-down lists.

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 1 - Table filtered by one letter ("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 2 - Table filtered by two-letter text string ("ti")

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.

Figure 3 - Filterable table dynamic example

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.

Figure 4 - Selection table example: Before filtering and selection

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.

Figure 5 - Selection table example: After filtering and selection

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.

Figure 6 - Filtering in a Find dialog

Tree-based filtering
In addition to tables, trees can also be used for presenting data. Trees are perfectly suited for showing hierarchical arrangements of information that would be difficult to show in a more tabular format. They are also more one-dimensional than tables, which gives them a narrower bar-like presence that takes up less screen space and fits in more places, such as adjacent to a table. Trees contain nodes and links. The nodes can represent objects, such as containers of resources, and the links can represent the relationship between different nodes, such as "contains," "peer," or "is contained by." Spatial layout between nodes also connotes relationship information -- similar to using indents. Frequently, a tree will appear on the left side of a window to control navigation, with the contents of a selected tree node tightly-coupled and appearing to the right of the tree, often in a table. Windows Explorer and Lotus Notes, for example, use this basic tree-table layout.

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.

Figure 7 - Tree control before filtering

Figure 8 - Tree control after filtering

Chart-based filtering
Charting is one more data format for which you can powerfully apply filtering techniques to enable information reduction. Although charts and graphs are usually presented to users in a display-only state, with no post-display user controls such as filtering, filters can be tightly coupled with charting to give users control to quickly manipulate, tailor, and reduce large amounts of data. This lets users drive such things as data mining, or finding the desired nuggets of data by enabling them to quickly manipulate the parameters that feed the chart.

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 9 - Range selector

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.

Figure 10 - Tightly coupling filters with charting

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
Objects and data are not the only UI components that can benefit from filtering. There is also an ever-increasing number of functions being added to UIs. Functions tend to get added to a product over time because different users want different things. Rarely do all customers and all their users want to use all available functions, so they are bombarded with too may options. There are a couple ways to filter the number of functions users have to face: one is to limit the number of actions users can do based on their roles, responsibilities, and authorization; another is to filter down (but not out) the lower priority user functions from the highest levels of the UI.

Role-based filtering
Below is an example of how user tasks can be filtered for different user types. Figure 11 shows the possible actions for a technician and Figure 12 for his supervisor. This is evident in two places in these UIs: in the menu of tasks the user can launch and do, which is on the left-side of the console in what is referred to as a "portfolio," and in the banner area at the top of the console.

Figure 11 - Filtered actions for a technician

Figure 12 - Filtered actions for a supervisor

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.

Prioritized filtering
Another way to reduce user choices and actions is to give a precedence to some actions over others, which essentially filters down the more peripheral actions from the highest-level and most visible and accessible UIs. This also makes more room for the important choices at the higher-level access points. This should be done based on criteria such as importance, frequency of use, and user intent. However, you must also be careful not to go too far in breaking apart different tasks that are highly related. So, you might need to balance the placement of the actions with the logical structure of the choices. But in the absence of such considerations that may cloud things up, it's important to carefully craft the UI elements to be at the most appropriate priority and access point for users.

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.

Figure 13 - High access to "Close" function

Figure 14 - Lower-level access to "Close" function

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

	Highest-level access for "Close", as in Figure 13	Lower-level "Close" access by pop-up menu, as in Figure 14
Pros	Very visible, easy for user to know you can do it Very easy to quickly clear out undesired open views	Easy to add another menu choice to an existing menu Looks cleaner, takes up less space
Cons	User could accidentally close an open view, which could be an issue if view takes a long time to load, although a safety mechanism (warning) could be given. High visibility adds visual clutter and takes up space	2 clicks to access instead of 1 Less convenient

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.

Figure 15 - Filtered partial menu

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.

Figure 16 - Full menu

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.

Intent-based filtering
Filtering concepts can be applied to many other areas of the user experience. Ideally you can make the system smart enough to understand what the user is really trying to do, and then filter out the other possibilities. If you know the user's intent, you can filter the options that are not intended. For example, if the user is moving the mouse pointer toward an object on the UI and is slowing it down, we can assume that the user is likely targeting that object. By assuming the user's intentions are to target a specific object, you can filter other options. Figure 17 below shows how an intent-based filter can work.

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.

Figure 17 - Detecting mouse movement intent

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.

Conclusion
Filtering is a key concept that can greatly increase the usability of a UI. It is often not adequately addressed, and is something you can implement to help distinguish your product in the marketplace, not to mention help users to be more productive.

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.

Resources

• Take a guided tour of the Tivoli Console, a role-based UI that presents only those tasks that are assigned to specific user roles.
  
  
• There's plenty of UI research going on at the University of Maryland HCI Lab -- give it a look.
  
  
• Spotfire, Inc. offers analytical tools that can help make your enterprise more flexible.
  
  
• You'll find more on User-Centered Design at the IBM Ease of Use site.
  
  
• Task Analysis can be an effective way of identifying which objects users find important in accomplishing specific tasks.
  

Rate this article This content was helpful to me: Strongly disagree (1) Disagree (2) Neutral (3) Agree (4) Strongly agree (5) Comments?

developerWorks > Web architecture >