Personal tools
You are here: Home 1997 Vol. 29 No. 3, July 1997 Papers A Critical Examination of Separable User Interface Management Systems: Constructs for Individualization
Document Actions

A Critical Examination of Separable User Interface Management Systems: Constructs for Individualization

Carson Reynolds

No earlier issue with same topic
Issue
Previous article
Article
SIGCHI Bulletin
Vol.29 No.3, July 1997
Next article
Article
No later issue with same topic
Issue



Abstract

The existing framework for separable user interface management systems (UIMS) currently lacks an integrated abstraction of the user and the user's preferences. Without this abstraction, separable interface theory fails to provide a theoretical framework for automatic customization of user interfaces according to the individual user's needs. The purpose of this paper is threefold: to present perceived limitations with existing UIMS models, to suggest a solution to these limitations, and finally to introduce a theoretical tool for constructing this solution.

Keywords: Separable Interface, UIMS, Intelligent Interfaces, User Modelling, Persona, Agents

Perceived Problem: Separable Interface Theory

Separable Interface Theory

In his introduction to The Separable User Interface, E.A. Edmonds discusses the evolution of techniques for "the separation of user interface issues from functional ones" (1992). Edmonds states: "Interfaces that serve as front-ends to, and integrate, existing systems and services are separable" (1992). This is the basic supposition behind separable interface theory. Put simply, separable interface theory is a theoretical framework for creating user interfaces that emphasizes the independence of the user interface from the functional aspects of the system that the interface serves. The promise of separable user interface theory is that it could one day lead to "the automatic (or semiautomatic) construction of user interfaces" (Green, 1985). Ideally, separable interfaces should encompass all "that shows through to the user" (Moran, 1980). Several models have been created in order to provide a framework for creation of separable interfaces.

Separable Interface Models

One of the most influential UIMS models is the Seeheim model (Figure 1). This model was constructed in order to show which constituent parts are required in order to generate a user interface automatically. The Seeheim model does not, however, describe "how a UIMS should be structured or implemented" (Green, 1985). The Seeheim model, while not the first UIMS model, served as the basis for many UIMS models that followed.

Figure 1: The Seeheim Model: developed in 1983 to describe substantive components of a workable user interface management system.


In 1990, Edmonds and McDaid created the knowledge based front ends (KBFE) model (Figure 2) by extending the Seeheim model. They augmented the Seeheim model with what they termed "knowledge-based modules" (Edmonds & McDaid, 1990). These knowledge-based modules distinguished the KBFE framework from previous models by enabling "the KBFE to be a cooperative system" (Edmonds & McDaid, 1990). Edmonds and McDaid commented that knowledge-based modules could be utilized to "contain information about the problem domain, the user's environment, and the characteristics of the end users themselves" (1990). The KBFE model is also notable in that it made the crucial transition from theoretical model to actual code, proving the feasibility of the model.

Figure 2: KBFE Model: developed to describe the Edmonds and McDaid architecture


Separable Interface Limitations

The Edmonds and McDaid architecture made a significant contribution to the human-computer interaction community. However, their model does not go far enough to provide for the needs of the individual user. While the KBFE model allows for the inclusion of knowledge-based modules that contain "the characteristics of the end users themselves" (Edmonds & McDaid, 1990), it does not explicitly include any construct for automatically individualizing the presentation for a specific user. The KBFE model (Figure 2) seems to include a single presentation embedded into what Edmonds and McDaid term the "harness". If the KBFE model is to be comprehensive it should model everything "that shows through to the user" (Moran, 1980). Most modern operating systems allow some level of user interface customization that shows through to the user. Consequently, if the KBFE model is to be applied to modern operating systems it needs to include an integrated abstraction of the user's customization. A specialized user model needs to be developed to better facilitate individualization.

The question "Why individualize the interface?" probably arises in the reader's mind. Conventional wisdom seems to hold that interface design decisions should be made by an expert user-interface designer. However, some studies have shown that interface designers fail to design interfaces that appeal to their intended audience. One such study -- "Cultural Diversity in User Interface Design: Are Intuitions Enough?" -- presented a variety of individuals with three interfaces (designed for specific cultural groups) and then asked which interface the individuals liked best. Overall, only 33.6% of the surveyed users preferred the interface that was specifically designed for their cultural group. The authors of the study state in the discussion of their data: "Clearly then, `professional intuition' is neither a sufficient nor reliable methodological foundation for producing an `appealing perceptual experience' in interactive computing systems" (Teasly, Leventhal, Blumenthal, Instone, Stone, 1994). If the KBFE model includes only a single presentation, then it would seem that this singular presentation could be prone to not appealing to the group for which it was designed. The logical solution to this issue is to allow users to provide feedback to an agent whose purpose is to individualize the user interface in accordance to the user's wishes and thus employ alternative interfaces.

Suggested Solution: Persona

Definition of Persona

In order to compensate for the lack of individualized presentation within the KBFE model, the author would like to propose a theoretical construct: the persona. A persona is defined as a specialized user model that serves as a repository for all of the user's preferences within a given system. Separable interface theory abstracted the interface away from the application that it served. The persona is the abstraction of the user's choices away from the interface. The persona should do the following:

  • encompass all the persistent decisions and preferences of the user
  • contain pointers to the components which the user has chosen
  • be portable.

Basis of Persona

The persona, as described within this paper, is the aggregate of several concepts concerning user modelling from eclectic fields. In the literary tradition, personas are used in order to communicate with the "mock reader" (Coney, 1978) that a writer might develop for rhetorical purposes. The user interface design community continued the tradition of the persona and mock reader relationship in a new incarnation: "the typical user". "Much of interface design is built around the premise of `the typical user' " (Becker, Nastos, Posner, Mawby, 1995). However this generalized user model proved somewhat problematic in that (according to some) -- "there is no such thing as the typical user" (Becker et. al., 1995).

More recently, a particular type of user model, the virtual individual, was created and employed "in establishing the patterns and setting the standards by which we are evaluated and with which we often must conform" (Orvec, 1996). Jo Ann Orvec (1996) -- in Virtual Individuals, Virtual Groups -- describes this specialized user model:

A virtual individual is a selection or compilation of various traces, records, imprints, photographs, profiles, and statistical information that pertain (or could reasonably be said to pertain) to an individual -- along with writing done, images produced, sounds associated with, and impressions managed by the individual.

Note that this definition not only delineates the boundaries of the user model, but also discusses potential functional aspects as well. Jon Orwant (1996) presents another functional vision of user models:

In short, the user model (and any sensor, servers, and engines maintaining it) should posses all the knowledge of a lifelong friend -- it should be able to recognize the user, know why the user did something, and guess what he or she wants to do next.

In Orwant's view of user modelling, "The more the computer knows about a user, the better it can serve that user" (1996). The persona combines many of the above theories in order to perform a specific role.

Role of Persona

The persona user model is designed to help compensate for the perceived inadequacies in the realm of personalization that the KBFE model exhibits. Functionally a persona would operate as a portable registry of all of the various options that differentiate the individual user's environment from a default environment. Essentially, the persona would perform as a "filter" between the user and the default user interface environment.

To better exemplify the role of a persona a hypothetical situation will be presented. A user of a particular operating system uses a network computer at work. The user makes a variety of changes to the operating system's appearance. These changes are stored in the user's persona. Next, suppose that the persona is transferred to a second computer at the user's place of work. This second computer's user interface now looks and performs exactly like the first. This sort of functionality would be particularly useful in a network computing environment in which no data is stored on the local computer. A user's operating environment is, then, no longer bound to a particular computer, but instead a virtual entity which can be "plugged in" to other computers.

Solution Generation: Tailored Interface

Tailoring Agent

The implementation of a persona within a UIMS system could be greatly enhanced by the addition of a "tailor". Henderson and Kyng (1995) suggest "continuing design in use" as a method for creating user interfaces which "better fit work situations". This technique could be made the responsibility of and automated by an interface agent. A "tailoring agent" would be responsible for the creation and continuous modification of the persona according to the user's needs. A tailoring agent would acquire information from the user and the user's persona and then use an expert system to determine which combination of user-interface settings would be most appropriate for the user. Before permanently altering a user's persona, the tailoring system would verify the accuracy of its choices by polling the user to see if the modified user interface is to the user's liking. Using this technique, the tailoring agent adapts the user-interface to the user instead of forcing the user to adapt to the interface.

Interface Banks

Figure 3: The Persona / Tailor Model: Tailor and Persona introduced to better facilitate individualization


The tailor requires "banks" of various user interface components. A bank is defined as a collection of similar components that all perform the same task within the user interface, but that are specifically designed to appeal to a certain type of user. Once the tailor makes a decision, it selects components from various banks and constructs an interface from these components. A dialogue bank, for example, would contain a variety of different dialogue boxes that are specifically designed for different cultural groups. A certain set of dialogues could be created for inexperienced computer users and another set of dialogues could be created for highly technical computer users, for instance.

Tailoring Goal

The goal of the tailor is to create, from the available library of banks, a user interface that the user will find most appealing. In the case of selecting from the dialogue bank, the tailor agent would begin by asking the user's level of computing experience. The tailoring agent, using the user's answer as its input, would select the dialogue component that it believes is best suited for the user. The tailoring agent would then verify its choice by periodically polling the user to determine if the dialogue boxes are too technical or not technical enough. The tailoring agent, of course, is not limited to dialogue. Ideally, the agent would adapt any portion of the user interface for which a "bank" and expert system is provided.

Relation to Persona

A persona and tailoring agent would act in tandem to help individualize a UIMS. The persona acts as the repository for the decisions of the tailor and the user. The tailor then uses the persona, along with other available sources of information about the user, as the basis for its decisions.

Revised UIMS Framework

The framework for separable user-interface design, with the addition of a persona and a tailoring agent, has the potential to actively customize the user interface in accordance with the individual user's needs. This revised model (Figure 3) would be closer to achieving the goal of "automatic (or semiautomatic) construction of user interfaces" (Green, 1985). These two components could assume the primary responsibility for managing the user interface.

Conclusion

Perhaps, with the separation of the individual's choices away from the interface, user interface management systems could be made more flexible, and more compelling. Instead of "the automatic (or semiautomatic) construction of user interfaces" (Green, 1985) the automatic (or semiautomatic generation of individually adapted environments would be possible.

Acknowledgments

Many thanks to Mary Coney for lending a patient and receptive ear. In addition, thanks to my peer review group for the sympathetic and creative input. I also wish to thank Marshall Smith, Roger Squire, Dan Johnson, Daryl Carson, Will Robbins, Mom, and Dad for listening to my endless musings ...

About The Author

Carson Reynolds is pursuing degrees in Philosophy and Technical Communications at the University of Washington. He is independently researching methods for construction of dynamic, evolving, and adaptive interfaces based upon the principles of fuzzy logic and elements of artificial intelligence.

Author's Address

Carson Reynolds
4210 Brooklyn Ave. NE, Suite 208
Seattle, WA 98105, USA

Telephone: +1-206-654-7077
Email: creynold@acm.org
http://weber.u.washington.edu/~creynold/

References

Baecker, R.M., Grudin, J., Buxton, W.A.S., Greenberg, S. (eds.). (1995). Readings in Human-Computer Interactions: Toward the Year 2000. San Francisco: Morgan Kaufmann Publishing, Inc.

Coney, M. B. (1978). The use of the reader in technical writing. In: Journal of Technical Writing and Communication, 8, 97-106.

Edmonds, E.A. (Ed.). (1992). The Separable User Interface. San Diego, CA: Academic Press, Inc.

Edmonds, E.A. & McDaid, E. (1990). An architecture for knowledge-based front-ends. Knowledge-Based Systems, 3(4), 221-224.

Green M. (1985). Report on Dialogue Specification Tools. In: User Interface Management Systems. Pfaff, G.E. (Ed.). Berlin: Springer Verlag.

Henderson, A., Kyng, M. (1995). There's No Place Like Home: Continuing Design in Use. In: Baecker, R.M., Grudin, J., Buxton, W.A.S., Greenberg, S. (eds.). Readings in Human-Computer Interactions: Toward the Year 2000. San Francisco: Morgan Kaufmann Publishing, Inc.

Moran, T. (1980). A framework for studying human-computer interaction. In: Guedij, R.A., ten Hagen, P.J.W., Hopgood, F.R.A., Tucker, H.A., and Duce, D.A. (Eds.). Methodology of Interaction. Amsterdam: North Holland.

Orvec, J. A. (1996). Virtual individuals, virtual groups: human dimensions of groupware and computer networking. New York: Cambridge University Press.

Orwant, J. (1996). For want of a bit the user was lost: Cheap user modeling. In: IBM Systems Journal, 35(3&4), 398-416.

Teasly, B., Leventhal, L., Blumenthal, B., Instone, K., Stone, D. Cultural Diversity in User Interface Design: Are Intuitions Enough? SIGCHI Bulletin, 26(1). 36-40

No earlier issue with same topic
Issue
Previous article
Article
SIGCHI Bulletin
Vol.29 No.3, July 1997
Next article
Article
No later issue with same topic
Issue

 

Powered by Plone CMS, the Open Source Content Management System

This site conforms to the following standards: