Design Tidbits

back Tidbits Overview

Tools for Design and Visualization


Interaction Design

Screen Design


Visual Design

Design Process

Web, Web Applications, Web Design





Selecting Objects By Attributes – Part I

By Gerd Waloszek, SAP AG, SAP User Experience – March 10, 2008

In this short series of two articles, I would like to look at a fairly common task – namely the selection of one or more objects on the basis of their attributes – and present a number of ways of performing it, ranging from a text-based, formal query statement to new visualization techniques. Once again, I will demonstrate how flexible user interface design can be and that user needs and requirements should ultimately determine which approach is chosen. My first article investigates common text-based approaches: a spreadsheet with attribute filters, a query on a flat-file database, and a Web interface for the query.

In the second article, I will discuss two visual approaches: first, the combination of starfield displays with dynamic queries as developed by Ben Shneiderman and coworkers; and second, the Attribute Explorer developed by Robert Spence and coworkers. I will conclude the second article with a "quick-and-dirty" comparison of all the approaches presented.

First off , we need a typical task with which to demonstrate the different approaches. An often-used example is that of choosing a car or a house. When choosing a car, prospective buyers will typically want to base their choice on characteristics such as price, fuel efficiency, number of seats, and so on. In this series of articles, I have elected to use sample house-related data to illustrate my points.


Starting Point: The Data

Before you can start demonstrating the task of selecting one or more objects you need to collect a list of, say between 100 and 1000+ objects, where each object is characterized by a number of qualitative or quantitative attributes. It should be noted that it can sometimes be difficult to put together such a list (see Shneiderman, 1999 for an example). Once you have the data, it can be easily arranged in a table, with one row for each object and one column for each attribute value:

# Attribute 1 Attribute 2 Attribute 3 Attribute 4 Attribute 5
yes ... ...
no ... ...
no ... ...
yes ... ...
... ...
... ... ...

Table 1: A list of objects characterized by a number of attribute values

As you can see from the schematic table, attribute values can be numbers, texts, or even Boolean values. To be more concrete, I will use the following sample house data*:

Price Garden Bedrooms Style
64815 8 1 Flat
68433 60 3 Flat
50327 86 2 Flat
75715 5 4 Terraced
63270 36 2 Flat
86213 96 4 Terraced
84175 55 5 Terraced
124312 98 1 Detached
159781 87 4 Link Detached
... ... ... ...

Table 2: Section of demo house data

*) This data originates from a demo application of the Attribute Explorer written by Andrew Smith from IBM

The users' task is to narrow down the list of acceptable houses to one or more that satisfy their requirements with respect to price, garden size, and so on.



The easiest approach to performing the selection task is to create a spreadsheet, which is more or less a table that allows some manipulation of the data it contains.

A spreadsheet of the sample data

Figure 1: A spreadsheet of the sample data

Narrowing down the number of choices is the real challenge for the user. Sorting may be the first idea that comes to mind, but it is not very useful for more if you have more than one attribute restriction. Filtering turns out to be the better approach, but not every spreadsheet application provides this capability.

Microsoft Excel, the "giant" among spreadsheet applications, offers so-called "auto filters." These come in very handy for narrowing down choices. To activate auto filters, the user selects "AutoFilter" from the menu. A dropdown list appears in the header of each attribute column, offering a number of options. By default, no attribute restriction is applied. Opening a dropdown list leads to a number of filtering options for the user. "User defined" is the best option to go for if you need both a single attribute value and a value range. Using a modal dialog, users can define restrictions for an attribute's values according to their needs:

Using an AutoFilter in Microsoft Excel

Figure 2: Using an AutoFilter in Microsoft Excel (translated from German version by the author)

Constraints can be numeric or qualitative. As soon as a filter is applied, a filtered list of all objects that satisfy the restrictions is shown instead of the complete list (see Figure 1). Of course, users can also enter restrictions for other columns as well. Restrictions for one attribute can be logically combined via "AND" or "OR." Filters for different columns are combined in an "AND" fashion, that is, all restrictions have to be met.


Flat Database

Leaving all the complexities of relational databases aside, I will confine the following discussion to a simple flat file database (which corresponds to one table in a relational database).

Command Line and Natural Language Queries

Formal query languages, such as SQL, were developed to retrieve information from databases. Instead of directly manipulating filters, attribute restrictions are formulated as a query (or SQL) statement, such as:

  • SELECT * FROM cars WHERE price < 200000 AND price > 100000

Typically, users do not directly enter such statements. Programmers code them into query applications. However, because these statements are "hard-coded," they may often be too rigid. Users would like to have more flexibility and be able to use the expressive power of a query language. Thus, some attempts were made to allow users to formulate database queries in simplified, "natural" language. A typical natural-language statement might read:

  • Find houses between 2 and 5 bedrooms and an asking price of between 100,000 and 200,000 dollars.

Natural-language query systems (NLQ systems) are, however, hampered by a number of problems, such as ambiguities, synonyms, and noise words. In addition, users have problems with formulating the query statement correctly, because the natural-language use of "and" and "or" conflicts with their logical interpretations. Q&A from Symantec was one of the more successful systems to pursue this approach back in the late 1980s, but Shneiderman & Plaisant (2004) question whether its success was in fact related to the natural-language query.

Simplified Queries

Most consumer databases allow users to create simple queries without formulating an explicit query statement – just by direct manipulation and entering some attribute values. As an example, FileMaker Bento for Mac OS X uses an approach that is similar to Excel's auto filters. However, the user interface is a little bit different: There are no modal dialog boxes for entering attribute restrictions, just dropdown lists and entry fields. The user has to go to "Advanced Find" and press the "plus" icon in order to add and define attribute restrictions. For ranges, two restrictions are necessary. Note that the logical combination (AND = All, OR=Any) has to be the same for all restrictions, which may be limiting in some cases.

Query interface in the FileMaker Bento database application

Figure 3: Query interface in the FileMaker Bento database application

As with Excel, the query result is a hit list of all the items that match the attribute restrictions. It is shown immediately after adding, deleting, or changing a restriction. All in all, the procedure is much the same as in Microsoft Excel.


Adding A Web Interface

So far, I have only dealt with numerical and textual attribute values. A useful extension would be the possibility of adding thumbnails and/or large images to the database of houses and showing them on demand – at least for the hit list. Images can be easily added to databases, but not so easily to spreadsheets (you can only add image links to cells). In the Web age, however, a typical approach would be to add a Web interface to the database or text file that contains the data. In the case of our house example, a real database would not be necessary. We could also use a text file that has been exported from a spreadsheet application. If we store the images separately, we simply need to store the links to the thumbnails and/or larger images in the spreadsheet, text file, or database.

For the query interface, an HTML page with some server-based scripting code – such as PHP or ASP – would do the job. A simple example of such a query page might look like this:

Example of an HTML query page with options for defining restrictions and hit list

Figure 4: Example of an HTML query page with options for defining restrictions and hit list

For this simple demo example, the design of the query section was inspired by Bento – but without the flexibility of adding or deleting attribute restrictions. Note that there are radio buttons allowing users to display thumbnail images of the houses (a single checkbox would also do the job). Clicking on a thumbnail might display a larger image in a separate window. You will probably have noticed that this query page resembles a catalog page in a Web shop.



In my second article, I will cover two visualization techniques: starfield displays combined with dynamic queries; and the Attribute Explorer. I will conclude the second article with a "quick-and-dirty" comparison of the approaches presented.




  • Ben Shneiderman (1999). Dynamic queries, starfield displays, and the path to Spotfire. (
  • Ben Shneiderman & Cathérine Plaisant (2004). Designing the User Interface (4th Edition). Pearson Addison-Wesley.
  • Andy Smith, Simon Moore, & Ryan Bennitt (2003): Visual Attribute Explorer. (IBM alphaWorks; provides a downloadable stand-alone Java prototype of the Attribute Explorer)


top top