Patterns as Mechanism in HCI Austin Henderson Rivendel Consulting & Design, Inc. PO Box 334 La Honda, CA 94020, USA +1 650 747 9201 henderson@rivcons.com ABSTRACT The growing role of patterns a basis for capturing computational regularities in HCI is being offered as a means for describing interfaces, their components and their behaviors. The description has effect through the elaboration of design and the implementation of coding. This paper suggests that with appropriate framing, patterns can become the mechanism for realizing interfaces. Further, by making patterns accessible to users, design of interaction to meet local needs and tastes can be put back into the hands of users. Keywords Patterns, interaction implementation this work, other people interact with them to get help. A BIG GOAL: PLIANT COMPUTING Computer applications are ontologically disengaged. The ontology of an application is fixed: it is crisp, unmoving and single-minded. The implementation of applications embodies this fixed ontology; but because it will never change, it need not be made explicit, and need not be expressed in the code. The ontology is compiled into the code; the code is unaware of it. Therefore applications are neither able to present their ontologies to the user (help systems can, but those descriptions are inherently disconnected from the application) nor able to interact with users to change them. In contrast, people's use of computer applications is ontologically engaged. Usage is dynamic: the world changes, the needs change, the meanings of things change, the use to which applications is put changes. The world is multi-perspective: collaborating users with different views must bring those views together. Living in the world requires ontological engagement: what things mean is at the center of existence. This mismatch between computation and the use of computation over the engagement with ontology puts heavy burdens on users. Since computers are not engaged with their own ontologies, and users must be, all the ontological work of dealing with a dynamic and multi-perspective world must be done by the users, without computational help. We have suggested ( and 1999) that there is no need for this to be the case. We have argued that this choice can be made differently and that computation could be re-invented to be ontologically engaged. We have offered patterns as a possible basis for this new computation. Therefore, my deepest interest is in how the intuitions arising from Pattern Languages for describing HCI can be used as a basis for making the applications created with them ontologically engaged. That is, if patterns are used to describe, and ultimately create aspects of applications (e.g., the UI, the user's conceptual model, even the structure of its intended use), then possibly those patterns can be made accessible to the user in support of use. And if the coupling between description and implementation can be made causal, so that changing the patterns can change the implementation on the spot, then possibly the user can be given the power to modify the application to suit their needs. FROM PATTERNS TO IMPLEMENTATIONS Patterns as partial descriptions The idea of patterns is that they are partial. The intuitions are that: they apply to some domain (e.g., a house, an interactive computer application); each captures a regularity of some sort about the domain; the regularities can be at many different sizes, about many different aspects of the domain; they combine to describe things in the domain; the way they combine is by situations left unspecified in one being matched and specified by others. When patterns are used for describing an existing situation, the description of composed patterns is inevitably incomplete; there is more detail present in a domain situation than is specified in the patterns. Patterns are importantly partial. Pattern enactment frameworks When patterns are used for creation, all the detail not supplied by the patterns must be supplied by the creation process. This, to date, is the job of the designers who are using patterns. What we must do is find the computational framework that will supply this information, or permit users, in the midst of their situations, to supply it. Much too hard for now However, for this workshop, I think this is much too large a goal to tackle. We need a much more modest place to start. has happened from the context, or must the number pad itself show this? Is the right idea to use a single "undo" button, that takes back the last action, whatever it is? What about undo of undo? For "pre-defined" jobs, the number of copies may be different from 1. Therefore, the context may require the idea of "starting" the number pad at a number different from 1. Is it in reset mode (so pushing 3) means 3, or in entering mode, so 3 and delete work on the last digit only? A SMALLER START: UI TOOLKITS I have experience in creating open-ended architectures for human-computer interaction (HCI) and in creating toolkits for designing and building user interfaces based on those architectures (1986). My intuition is that the regularities expressed in HCI architecture and captured in the interface toolkits are the stuff of interaction patterns. I would like to see if this is so. I have no experience in creating such patterns. I would like to use this workshop as a chance to explore the relation between the regularities built into toolkits and those expressible as patterns. NUMBER PAD construction of a number from digits presentation of numbers in place-value notation correction of error, or supporting change of mind, by In the work on Trillium, I was amazed at the complexity of something as seeming simple as the number pad that appears on a photocopier. Issues There are a number of things going on here, even in this relatively simple interactional element. Simple story There are 11 buttons and a display. 10 buttons are the digits, and one ("C" for clear) is used to reset the number pad. The activity is: pushing a digit button causes the corresponding digit to be slid in from the right and the number moved over. Computationally, the number in the display is multiplied by ten and then the corresponding digit added. starting over backing up one digit backing up one button push default values timeouts pushing the clear button resets the number pad to 1. Complexities How do we convey all this to the user? as a design issue, we must decide at what point is it not worth the effort? After all, resetting, and entering the number again in its entirety is not very much work. However, the complexity now begins to rise: The behavior we see in the resulting design is responsive to all of these influences. Patterns following a reset, pushing the 3 button does not slide in a 3 from the right to give 13. It replaces the 1 left by the reset with the 3. The argument is that the reset should be to 1 because that is the default value. If the user walks up, and ignores the number pad, they will get one copy. However, if they explicitly ask for 3, they should get 3. It seems there could be a number of different ways to approach this with patterns: a single pattern for entering a number and supporting resets, defaults, and changes. The number pad would be an answer, and all the internal details left unspecified. The pattern would be of value in capturing the regularities around the notion of entering a number. what happens if the first digit hit is 0? Should the number be set to 0, or left at 1? some number pads have a 12th button ("D" for delete) which is used for correcting mistakes. That is, after hitting 2,4,7 and seeing 247 in the display, if the user hits delete, they are back to 24; and then, to 2; and then to what: 0? or 1? And if 1, should the pad be regarded as reset, so that the first digit subsequently entered replaces the 1? a single pattern giving all the details of the number pad. This feels too specific and narrow. a pattern for each of the issues listed above. These would each address a much broader point, and could use the number pad as an example. As there are two different behaviors when 1 is showing (when reset, and when 1 has been hit), how does the user know which they are about to get? Should an additional indicator of some sort be given showing that this is the default or this was explicitly entered? The last of these is most attractive from an architectural point of view. However it raises the issue of how patterns are combined very strongly. The context may also force a reset: most copiers time out, and all the values are reset. Can the user tell that this CONCLUSION I would like to understand how the patterns for individual dimensions can capture the regularities of interfaces of which the number pad is an example. I would like to understand how these patterns are combined to produce the number pad in all its complexity as a special case. And long-run, I would like to understand how we can build computational mechanisms that would support designers, ultimately including users, in creating number pads and all sorts of variants on them. REFERENCES Henderson, A. (1986). Trillium: A Knowledge-based Design Environment for Control/Display Interfaces. CHI'86, Human Factors in Computing Systems, Boston, MA. Harris, J. and Henderson, A. (1999). A Better Mythology for System Design. CHI 99: Human Factors in Computing Systems, Pittsburgh, PA, ACM.