The Machine Knows What You Need

Eventually the vast amount of information on the Internet will be available to users through generic browsers in mobile phones. Is there some way we can help users find information useful to them among all the hundreds of thousands of links? We have already determined that designers should not approach this problem by designing a static unbalanced hierarchical tree, as with mobile phone features, because the number and relevance of items in a search result are not known at design time. In order to minimize the interaction paths that conduct users from queries to the answers they need, the system must dynamically create an unbalanced tree as the search begins.

Presumably that can be done. Mobile phone features are prioritized on the basis of a user needs analysis. The most important and most frequently used features should be the easiest to access. With information searches, some search results are likewise more significant than others, and some search engines leverage that fact using traditional information search methods. All Webpages that contain the search string are first listed as search results. Then the pages are analyzed more closely to discover, for example, how many times the search string is mentioned in a given document. More advanced text analysis tools also understand the context in which the searched term appears in the text.

These methods are wholly dependent on the information in documents turned up by the search and the search terms provided. Because mobile phones are companions that remain with their users throughout the day, they have a much wider potential for refining search results. As users access information through their mobile phones, the phone can keep logs of the kinds of information in which the users are often interested. It can track the users’ communication patterns—the places they visit and the persons to whom they send messages. By reference to the calendar, the phone knows something about recent and future events to which the search results might be related.

Let’s play the scenario out into the future. A user’s phone activities probably have patterns dependent on the time of day. In the morning, local weather and traffic information about the user’s route to work are predictably interesting. An advanced phone could be equipped with sensors to analyze the environment and determine where the phone is. Positioning capabilities are already emerging. The desired traffic information is naturally going to change depending on whether the user is leaving home or leaving the office.

If a phone is possessed of context awareness and can adapt to user behavior, then it can use the same information to change user interface components such as the menu hierarchy. Elementary forms of such adaptation already exist. For instance, most phones have a dynamic list containing the most recently dialed numbers. This means that the system has logged user behavior and provided a way of easily repeating recent actions. Currently call lists are ordered by calling chronology only. The most recently dialed number is first on the list, the number dialed before that is second, and so on. Here, one simple way of introducing more intelligence would be to add other ways to sort the list. It might be worthwhile to rank the most frequently called numbers. As the users probably call different numbers at different times of day, the order should change itself by dynamic. During the working day, the most frequently called persons are usually colleagues and customers. On the drive home from the office, users probably call home, and in the evening they call friends and relatives. In informal studies we have found that the five most frequently called numbers weighed by the time of day constitute 75 percent of all calls.

The possibility of adaptations like the ones we’ve just imagined presents yet another design challenge—when should adaptations occur? Does the user interface adapt and change gradually, increment by increment, in an evolutionary manner that might go unnoticed by the user? Should it be more decisive, changing big time at infrequent intervals, thereby surprising the hell out of the end user for a short period of time and then becoming consistent again? Of course, both of these suggestions could be wrong—the first is just too slow for a product that may be replaced every 6 to 24 months, and the second stands a good chance of putting users off the product for life.

Discussions on adaptivity for personalization have so far focused on the positive benefits that it can bring to bear on overcoming the increased complexity of the phone and mushrooming amounts of information that it can deliver. On the other hand, not all products or even all aspects of a product need to be adaptive. Knowing the difference is key. Adaptivity must not be used to fix poor interaction design, and should not be used to bemuse. It adds value to the product when it increases the user’s odds of successfully completing a task.

Bringing information about the user and context into the design equation has risks. It requires that a device store a lot of personal information about the user—an amount way beyond the user’s comprehension. What would happen if someone else got hold of this information? What security issues need to be addressed to avoid misuse of personal information, to create trust, and to encourage the user to grasp the opportunities of adaptivity? All in all, it is agreed that user interfaces could be greatly improved by using all the information that mobile devices acquire about users and their environments. This will simply have to be done judiciously.