Refining Data Tables
Published: August 28, 2006
Many articles have been written on what is probably the single most ubiquitous interface element within Web applications today: the form. Forms justifiably get a lot of attention because their design is critical to successfully gathering input from users. Registration forms are the gatekeepers to community membership. Checkout forms are how eCommerce vendors close deals. But what goes in must eventually come out, and the information users provide to Web applications often makes its way back to users in the form of tabular data.
After forms, data tables are likely the next most ubiquitous interface element designers create when constructing Web applications. Users often need to add, edit, delete, search for, and browse through lists of people, places, or things within Web applications. As a result, the design of tables plays a crucial role in such an application’s overall usefulness and usability. But just like the design of forms, there’s more than one way to design tabular data.
In a previous Communication Design column, “So the Necessary May Speak,” I discussed how to reduce the number of both visual design and content elements within a table to the absolute minimum necessary for effective communication. So, I won’t repeat myself here. Instead, I’ll focus on interface design solutions that enable users to find their way through large data sets.
When tables are chock full of information, it’s quite likely that people will need to filter out information that isn’t relevant to their queries. In such cases, exposing a complete list of data filters is an effective way of quickly communicating what refinement options are available.
Figure 1 shows data filters in use on Shopping.com. In this example, a complete list of available filters is always present above each set of product search results. Filter categories group the filters—for example, price, brand, size, category, etcetera—and help users get an immediate sense of how much data will be left after refining the search results by a specific attribute. With an above-the-grid design, vertical space is at a premium, because you don’t want to obscure the actual data in the table. As a result, the display of filters in each category is often truncated after a predetermined number of items, with a link to see the remaining options.
Figure 1—Data filters above a table
Alternatively, you can place a complete list of data filters to the right or left of tabular data, as shown in Figure 2. Though this design provides more vertical screen real estate for each category of filters, some filters may be less visible, because they appear further down the page.
Figure 2—Data filters to the left of tabular data
In cases where a limited number of filters is available or frequently used, presenting just a few filters might do the trick. As shown in Figure 3, a simple set of tabs, links, or drop-down menus can provide a few high-priority ways of quickly slicing through a large set of data.
Figure 3—Selecting options to refine tabular data
When there are too many possible filters to expose them all at once or refining a data set is a secondary use case—for example, the purpose of a tabular grid may be to get an overview of all the data rather than find a specific value or set of values—keeping data filtering options accessible, but not constantly visible may be a better solution.
For example, a user might expand a collapsed group of filters by clicking a link labeled something like Search Options, thereby displaying the filters only when the user needs them to refine the search results. In the example shown in Figure 4, a set of filters dynamically appears overlaying the top of a table when a user clicks Search Options. By default, the three most popular queries determined the first three filtering options that appeared. However, users had the option of choosing a different set of filters or adding more filters before executing a search.
Figure 4—Filters that require a user action to become available
Occasionally, the best way to find what you’re looking for in a table is to search for a specific attribute value. In such a case, you can provide a means of specifying a query for each attribute by adding input controls to every column in the data grid, as shown in Figure 5. Of course, this design presents problems when column labels and values consist of small amounts of text or numbers, because the addition of input fields can dramatically increase the overall width of a table.
Figure 5—Refining a search on individual attributes
When an explicit relationship exists between the filtering options in a set, it may be preferable to expose that relationship within the filtering controls. In Figure 6, the data has a strong hierarchical relationship that the user interface expresses and enforces.
Figure 6—Representing a hierarchical relationship between filters
The examples in Figures 4–6 highlight the use of expandable groups of options for filtering the data in a table, as follows:
- adding filters to and removing them from a list, as in Figure 4
- providing input fields for each attribute column to let users search each column of a table, as in Figure 5
- using a hierarchical filtering control whose content changes, depending on a user’s selections, as in Figure 6
Certainly, there’s no reason these solutions couldn’t always be present on a screen like the options we looked at earlier—and vice versa.
Sorting It Out
In each of the options I’ve discussed, the ability to sort a table remains a useful way of drilling down to specific content. Sorting, of course, can occur either when a user clicks a table header to sort a specific column, which corresponds to a specific data attribute, or uses a dedicated sorting control, as shown in Figure 7.
Figure 7—Two common ways of sorting a table of data
While we’ve looked at a number of design solutions for filtering large sets of tabular data, this isn’t an exhaustive list. So, if you’ve encountered other ways of getting through a large set of tabular data, I’d love to hear about them from you.