|
|
|
| Print version | |
Related Links |
|
| Don't Let Your Interface Lie | |
Background Links |
|
| Amazon Website | |
| Microsoft Developer Network (MSDN) | |
By Gerd Waloszek, SAP AG, Product Design Center – 03/10/2004
Have you ever wondered how Amazon can know so well about your interests or how Microsoft Office applications adapt menu items to the user's behavior? Is it magic that does these tricks or is it something trivial? In this article, I will offer answers to these questions and show that magic is not needed. I will present examples of "non-intelligent" mechanisms, such as feature matching, counting, and ranking and will demonstrate how these techniques can add value to a user interface – be it for operating systems, applications, or on the Web. In my conclusion at the end of the article, I will reveal the origin of my own interest in such techniques. But first let's take a closer look at these – actually not so – "magic" tricks and see what they can achieve.
The book recommendations found on the Amazon Website are probably one of the best known applications of statistics on Websites. They go like this: "Customers who bought this book also bought: ..." And then a short list of recommended books follows (see figure 1 for recommendations for prospective customers of Ben Shneiderman's book Leonardo's Laptop).
![]() |
Figure 1: Recommendations for customers of Ben Shneiderman's book Leonardo's Laptop (from Amazon Website)
People may wonder how these miraculous recommendations come into being. My hypothesis is: The mechanism behind recommendations is not a miracle, it's based on correlation, or – in simpler words – coincidence. Simply note which books a customer bought, then pick the current book, and check which other books the customer also bought. Add a simple ranking mechanism, set a threshold of five items, and there you have it. I assume, however, that Amazon's recommendations are based on a more sophisticated mechanism. For example, it would make sense to filter the book titles by topic or domain in order to avoid recommendations that are out of context.
Amazon does not stop there. Below the book recommendations shown in figure 1 you find further recommendations and links that are based on similarity:
![]() |
Figure 2: Further recommendations for customers of Ben Shneiderman's book Leonardo's Laptop (from Amazon Website)
While it is hard to speculate about what kind of similarity the "Explore Similar Items" link is based on, the second recommendation seems to be based on superficial word equality. And it's a sponsored link, too. Nevertheless, this link involves at least some finesse: Amazon detected that I approached their site from Germany, so they offer a link to a German price comparison site. I leave it as an exercise to the reader to muse about the usefulness of such a link. I wanted to buy a book, not a laptop...
The related and background links found on many Websites, such as Microsoft's Developer Network (MSDN), and recently even the SAP Design Guild (just take a look at the page border to the right), are another approach to exploiting similarity. Here, the similarity of topics is used as the basis for recommending further articles.
![]() |
Figure 3: Related links on the MSDN Website ... (from MSDN Website)
![]() |
Figure 4: ... and their counterpart on the SAP Design Guild
In general, determining similarity can be a difficult matter. Which criteria should the similarity be based on, and how can you measure it? Often however, this task is simplified and broken down to counting the number of corresponding features: The more features two objects have in common, the more similar they are. For a more realistic metric, you might want to add weights to the features. Features can be extracted automatically or defined manually. Think, for example, of a text document: Its features or attributes can be keywords that the author determined beforehand – these are the "meta data" for the document. Automatic mechanisms, on the other hand, might scan the document, extract (predefined) keywords, and count their frequency.
![]() |
![]() |
|
![]() |
![]() |
Figure 5: Determining similarity can be a complex affair: To which animal is Gati the cat most similar – a cow, a sheep, or a horse? (cat photo by Thomas Mattern, all others by Gerd Waloszek)
In short, you can base links to related information on automatic mechanisms or you can handcraft the links, as we do for the SAP Design Guild. Which of these mechanisms will eventually lead to more useful links may be an open question. It should, however, be evident that handcrafted links can only be supplied for small to medium-sized Websites.
Beginning with Windows ME, Microsoft developed the notion of "Activity Centers." These simple applications reside in a window of their own and are designed to support well-defined, often guided, tasks, such as cropping or resizing an image. Activity Centers have an interesting feature that I want to draw your attention to: They offer links to tasks that are related to the current task and might be an option for proceeding in the current context.

Figure 6: The Windows Photo Center preview is an example of an Activity Center – related tasks are listed under "You can also:"
For Activity Centers, related tasks are probably assigned by hand. For large software systems, such as SAP's ERP applications, it is, however, conceivable that these links are created automatically. The necessary meta data could be supplied by the respective applications.
"Matching" is the general term for finding items that bear some sort of equivalence. Equivalence can be based on "similarity," expressed, for example, as the amount of overlapping features. It can also mean some superficial equality, such as equal names, descriptions, and types. As matching is a huge topic in itself, I want to constrain the discussion to examples in which the system in essence looks for equal strings.
Microsoft Excel offers a feature called AutoFilter. It allows users to filter the columns of an Excel spreadsheet according to a wide range of criteria. In the simplest case, these are the names or text strings in the cells. The custom AutoFilter (see figure 7) allows for more complex filtering criteria, including the combination of two patterns (I would have liked the option of a third pattern, though). As filters of different columns can be combined, the filtering options are nearly limitless.

Figure 7: The custom filter in action. I found the "contains" option most useful; regrettably, it appears near to the end of the dropdown list box, and I have to scroll to find it
I appreciated the usefulness of AutoFilters when I worked on a project, in which I had to maintain the interface documentation for a control library. I had to keep track of thousands of entries and assure their consistency (see figure 8). Using the filter options, I could easily detect inconsistencies within the documentation as well as within the parameters themselves.

Figure 8: The custom filter in figure ... applied to the Excel spreadsheet containing the documentation for a control library interface
All in all, employing and combining simple matching capabilities can result in an extremely useful tool.
The shuffler, as promoted by Alan Cooper, is a filter mechanism similar to the AutoFilter. Using the AutoFilter efficiently may require some expertise. The idea behind the shuffler, in contrast, is to simplify the filtering task and design it in a way that everyone can perform it: Users create queries by selecting attribute values, thus forming natural language-like statements that everyone easily understands.

Figure 9: The shuffler allows you to filter large data sets with natural language-like query statements
Selection elements, such as radio buttons and dropdown list boxes, offer only predefined attribute values. It is conceivable to use input fields and combo boxes in the shuffler so that users can supply their own values. But this extension of the shuffler would also weaken the basic idea behind it and make the formulation of filter queries (and the matching process behind it) more complex.
Many Websites offer voting options that allow users to rank the usefulness or quality of articles. I found an elaborate example of this feature on Microsoft's MSDN Website:

Figure 10: Readers can rate an article on the MSDN site for quality (from MSDN Website)
The rating options are placed below the article, based on the hopefully correct assumption that people read an article before they rate it. At the top of the article, readers find its current rating:

Figure 11: Readers find the rating for an article on the MSDN site at the beginning (from MSDN Website)
Actually, I am not sure how I would react if an article had a poor rating (and no reference to the number of people who rated it; this information is given only at the bottom of the page). Voting can be based on a number of criteria, such as relevance, usefulness, and arousal of interest – quality is just one option. With the increase in Open Source content management systems (CMS), discussion boards, and Web log systems, features like voting have found widespread use on the Web.
The number of page requests can be regarded as an "implicit" voting measure. This metric has to be used with caution though, since it includes an unknown number of visitors who enter a Website by mistake. On an intranet, this problem may be less severe. Nevertheless, this feature has useful applications. For example, assembling an FAQ or finding the basic information pieces that beginners should read can be based on frequency metrics. But beware – popularity can also be a danger. Think of the radio stations that play the best hits of the 1950s, 1960s, or 1970s. After a while, you will hear the same songs over and over and get bored. Popularity metrics can lead to an impoverishment of the offerings, leaving only those documents (or songs) that everybody likes – resulting in a truly"average taste"...
From time to time, experts suggest filtering and sorting menu items or options according to frequency of use. This feature is meant to help beginners and casual users. However, it clashes with the demand for consistency because menu items may change their locations repeatedly. And it's probably right in about 50% of the cases, which results in a net gain of zero...
The technique of sorting items according to frequency of use leads us directly to the most simple math operations, namely ranking and sorting.
Ranking items means ordering (or sorting) them and then limiting the number of offers according to a predetermined threshold (top 10, top N, ....). The specific ordering can be based on diverse criteria, such as frequency (the ubiquitous counting), ratings (such as preferences), or time (typically the most recent items come first). With "ranking," I refer to context-specific characteristics of objects, such as frequency of use, user preferences, and time of (last) usage.
With the term "sorting," I refer to the ordering of objects according to the characteristics of the items themselves, such as the alphabetical order of their names or descriptions. Sorting is often performed on results of a search (hit list) or on actual data. Thus, in the context of this article, it is of lesser interest. Nevertheless, the example from MSDN below (see figure 12) shows once again the usefulness of simple ordering by time:
![]() |
Figure 12: List of most recent articles on the MSDN site (from MSDN Website)
Microsoft introduced a feature in its Office suite and other applications that is a variant of the above-mentioned frequency-of-use heuristic: When a menu opens, only the most recently used menu items are displayed. After a delay, the menu expands, and users can select from the whole set of menu options. Some people take this feature for a blessing (Microsoft, for example) because it limits the number of choices to the – as Microsoft thinks – most probable ones. Others are driven crazy by it (like me) because the function they currently need is initially not listed, and they have to wait for the menu to expand. This feature, which fortunately can be turned off, also clashes with the demand for consistency because menus change their look over and over according to the usage of items.

Figure 13: Initially, the pulldown menu in Microsoft Word shows the recently used functions only (in darker gray). After a delay, the menu expands and displays the whole set of options
For input fields, an application – for example, the browser or a business application – can remember data that the user previously entered and offer a selection of choices. This feature is called "input help." Input help is based on simple matching: The letters already entered by the user are dynamically matched to past inputs, and a list of choices is offered that start with the letters already provided. Input help bears some similarity to the most-used functions/options mechanism. Even though I do not know how the set of input alternatives is created, there must be a mechanism that limits their number. Probably, recent and perhaps frequent use comes into play. The mechanism may also vary from system to system. Again, this "help" is a mixed blessing because users are often forced to delete unwanted characters that the system automatically completed.
In a similar vein, automatic spell checkers correct words during writing. They do so for the whole document – not just in input fields. While they perform their tacit corrections after a short delay, there are cases in which the delay may be too short and users get unwanted corrections. There are also cases where the correction of certain words is always unwanted (yes, you can switch the correction mode off but this requires an extra, disturbing step). Like input help, this is an example of "dynamic matching." For spell checking, however, the matching process is far more sophisticated than for input help.
I first encountered automatic correction in the guise of the "DWIM" (do what I mean) mechanism on the XEROX 1108 Lisp machine: Whenever I introduced a Lisp variable named, for example, "hand" and wanted to introduce another one named "hund," the system insisted on changing it to "hand." I had to use dirty tricks to convince the system that the new variable should be called "hund."
Automatic translators push this concept even further. Witchpen, a dynamic translator developed in the 1980s by the Swiss mathematician Hannes Keller, provided "on the fly" text translation. Of course, Witchpen's translations had to be polished afterwards because it did not apply any grammatical rules. For translation, the matching process pulls its "corrections" – which are in fact translations – from a reference table that contains access keys and their translations.
Automatic handwriting recognition can also be regarded as a kind of "translation." Let me tell you just one anecdote about this topic: People were often impressed with how well Apple's Newton recognized long and complex words. On the other hand, they were puzzled that it had severe problems with short and common words. There is, however, a simple and disillusioning explanation for this phenomenon: Long words are typically unique, but there are many alternatives to short words – that's the simple reason for the successes and failures of Newton's handwriting recognition.
When I dug into books on artificial intelligence (AI) and machine learning in the 1980s, I soon realized that most of AI's "magic tricks" revealed themselves as some sort of matching and counting enhanced by math or statistics, such as ranking and correlation. At that time, I was deeply disappointed and disillusioned about AI. Today, AI is less popular than it was 10 or 20 years ago. But as the examples above show, its basic techniques of matching and counting items have found widespread use in the pursuit of enhancing user interfaces.
Some of the presented mechanisms can be mimicked or augmented by hand-coding, some cannot. For example, manually supplied references can be much more valuable than automatically created choices that make no sense or are even annoying. On the other hand, handcrafting such mechanisms can be arduous and error-prone. In the long run, we will have to refine these mechanisms so that they can be applied automatically to a wide range of applications. But still, we will be far from "intelligent" user interfaces or even artificial intelligence.