MICHAEL HERMAN
Home | Business Agility | Publications | WorkSpace | About | Contact

FifteenPropertiesHCI

WorkSpace | RecentChanges | Preferences | Random | Index | Search

PatternLanguage | FifteenProperties


the following is from John C. Thomas, http://www.truthtable.com


Fifteen Properties Applied to HCI Design

A short note on the interpretation of Christopher Alexander's fifteen fundamental properties as applied to HCI design.

1. Levels of scale. This seems fairly straightforward. HCI design, in principle, spans levels of scale from aiding in the design of social structures and large-scale architectural designs that are technologically instrumented and enabled, through the design of applications and task support, down to the level of making sure that fonts are visible and trackpoints have the proper damping functions. (See, "The Million-Person Interface).

2. Strong centers. This is probably one of the most overlooked principles of design in HCI. Often, what exists for the user is a "sprawl" of functions, tool bars, and icons with no overall or subsidiary organization. A better design would allow the user to quickly find a "home base" from which, it would be obvious where other subsidiary home bases would be. There is some sense in which hyperbolic trees, fisheye lenses, and home pages begin to address this.

It should be possible for users to "know where the action is" in entering an application or a web page.

In another interpretation, this refers more to underlying architecture and points to the need for a core of functionality that transcends a specific release or even a specific application. A good underlying architecture will communicate this essential center (related to central purpose or style) to the user.

3. Boundaries. Often it is not clear in existing designs what is possible and what is not possible. There are no strong boundaries on function or on data. What words are "in" the dictionary of a word processor spell-checker, e.g.? There is no intuitive way to know; only on a case by case basis can the user explore this. Similarly, it is not typically obvious how large a file can be handled by a typical application program. The only boundaries that are fairly clear are at the very base hardware level; e.g., how much memory the total machine has, how big the screen is.

A related concept is that of "scope." What is the "scope" of action of an invoked command? It should be clear to the user before taking an action over which actions the object should apply. Recently, I meant to apply an action to a single item and my finger slipped (or the cursor drifted) to the next menu item which applied the action to all (over 1000) such items but there was no preview of this action!

4. Alternating repetition. I interpret this in the context of HCI to be nearly identical to its meaning in the context of organizational design; that is, to refer to activity patterns.

Input, process, output. Pick up the phone, answer a person's question, put down the phone. Contact a client, discover their needs, make the sale. Research, develop, deploy. Set the nail, tap, pound, pound, pound. There are many patterns and if one were to see these patterns laid out a symptom of a well-working organization would be that these activity patterns had a rough periodicity to them. If they show so much variability that no pattern can be perceived, the organization is too disorganized.

By the same token, HCI designers must understand the flow and rhythm of activity at a variety of levels and support this. At the intermediate application level, for instance, we can imagine that there is a cycle to creating a document by inputting words into a document and then editing it; then, repeating the cycle. At a higher level, these documents may be part of a larger cycle of activity in which input for a "fall plan" is solicited by numerous people in the organization and then consolidated. Perhaps, another round of input and consolidation is included in the process. At a lower level, the user probably goes through a process of planning a paragraph and then typing it. At a still lower level, there is an alternating repetition of keystrokes.

In the physical world, animals use widespread "rebound" effects to lessen work. For instance, the achilles tendon and the arch in humans store energy when we run that is released in the next step. Most of our input devices do not currently support this kind of rhythmic action.

5. Positive space. I interpret this to mean two things. First, it is better to have functionality over determined than underdetermined. That is, it is better to have several "alternative" ways of accomplishing the same task than to leave "holes" of functionality that cannot be accomplished in any way. Secondly, at a higher level, the overall design of a system should "push" at the edges; allow for users and teams of users to extend functionality into new areas.

6. Good shape. At the more micro levels, this applies making shapes, sounds, textures, etc. that are aesthetically pleasing and clear. Equally, we can apply the idea of "good shape" to input devices. There are gestures of movement that are more natural and complete and those that are less natural and less complete. At a "higher" and more abstract level, this principle can be applied to overall screen design, tool design, and perhaps even to the design of applications. "Good shape" applied at the application level would mean that the parts of the application tools help pull together to define an overall application shape. This overall "shape" helps a user understand "where" particular functionalities would be found and how the various functions fit together. Typically, "editing" a document, "filing it" and "creating" it are all portrayed as single menu items in some fairly arbitrary menu hierarchy. But, how does this contribute to an overall "shape" of the application? It doesn't. We could imagine instead that if there were one or more models of the overall document creation process, that the various functions could fit within and help define this overall model in some abstract, and quite possibly, in some concrete way.

7. Local symmetries. Generally, if there is a method to move "up" there should be a symmetrical method to move "down." If there is a method to paint the foreground, there should be a method to paint the background. If there is a way to make an object larger, there should be a symmetrical way to make it smaller. As I interpret it, the HCI design principle should be applied both to functionality (symmetry of function) and to implementation (the *way* in which the functions are invoked should be symmetrical).

8. Deep interlock and ambiguity. Ambiguity? Surely, this is something that HCI design should avoid. But is it? At the highest level, if tools are well-designed, the user should not be sure (or even consciously thinking about) whether they are using a tool or interacting directly with the medium. Is a sculptor creating a vision out of the rock, or is the rock revealing to her or him the vision that hides within it? Is the writer creating a fictional world or revealing a deeper truth? Is the writer indeed, writing words or creating images and events? Is the musician playing notes that have been laid down or by the composer or co-creating with the composer by discovering what is there? Is the scientist finding out about nature as it is or building mental constructs that portray a world as built?

The way I interpret "Deep Interlock and Ambiguity" as applied to HCI design is not that (at least typically) it should be unclear what a command does, (although there may be an occasional place for this) but that really good HCI design should support the kinds of ambiguities and interlocks that are characteristic of "creative flow."

9. Contrast. At a fairly micro level, this can refer to such mundane but essential elements as ensuring sufficient contrast between characters to be read on a screen and the background. In general, any two importantly different events from the user's perspective should be sufficiently contrastive to ensure that the user can perceive the difference. This would seem like a fairly obvious principle of user interface design, yet there are many cases where, e.g., it is not clear to the user whether a "message" from the system is a message that essentially means, "Everything is fine and we're just letting you know that" from a message that essentially means, "You are in deep trouble and you'd better do something soon." !! In terms of pragmatic contrast, the words form categories of similarity and difference that are appropriately contrastive for the system designer, but not at all for the end user.

10. Gradients. I see at least two good applications of this principle. First, in terms of finding things and organizing things, it is typically better to have things organized and searchable by gradient than by category. For example, being able to list files alphabetically, by recency, by size, by importance are four ways of graded category and search. This is more amenable to the way human memory and the application of decision criteria typically work than by forcing exact queries. "Give me all the files that were created after April 1, 1999 and have 'Alexander' in the title" may miss exactly the file I'm looking for that was actually created March 31, 1999 and was titled, 'fifteen properties.' The creation of semantic gradients would greatly help in the search and organization of vast quantities of information. In (my personalized) semantic gradient, 'fifteen properties' would be very close to 'Alexander,' whereas in the rather arbitrary alphabetic gradient, they are very far apart.

Again, we can interpret some pieces of the current generations of HCI designs to incorporate some aspects of this in such innovations as fisheye views and hyperbolic trees or dynamic queries.

Secondly, the actions that users take should form natural gradients. When we walk through the physical world, we move continuously through space (except when we fall off a cliff or trip over a branch -- situations we like to avoid in the natural world, though the computer world seems full of them!). As we swing a club harder, the club moves faster, at least up to a point. As we put more effort into throwing a rock, the faster and farther it goes (and the more likely to kill a prey or drive off a predator).

There are aspects of this in current interface design; e.g., the longer we move a cursor, the further it goes; the more times we hit the "bigger" function, the bigger something gets. But there are many areas of action where this breaks down at every level of design.

At the micro-level, most input devices are oblivious to the dynamics of motion. Hitting the "T" key harder doesn't produce a darker "T" on the screen, e.g. Shouting at a speech recognition device simply makes it less likely that our words will be correctly transcribed. At the outset, most input devices immediately translate our inherently and naturally (not to mention sophisticated and sensitive !) analog motions immediately into digital form (presumably because that is what is easier for the computer to deal with).

11. Roughness. Austin Henderson and Jed Harris (CHI 99) argued eloquently that systems should be designed with this quality (though they did not label it as such). An example they gave was of a paper invoice system a company used. In order to "increase efficiency" the paper invoice system was computerized. What really happened was that the people now have to use both systems. They are required by the company to use the new, expensive, computerized system, but in order to actually get work done, they still have to use the paper system.

Both systems use forms and ask for specific information types to be put into those forms. But in the paper version, people may use "roughness"; e.g., in one situation, where the "address to be delivered" was to be input, the user wrote a notation that before delivery, the dispatcher should call a specific telephone number to determine where the delivery was to be made (because it was a ship visiting different ports). But, in the "intelligent" computerized version, such a notation was impossible because "Call 914-784-7561 and speak with Mr. Thomas to determine the current whereabouts of this ship" is clearly not an address; in fact, it doesn't even fit in the allocated space.

Roughness is an especially good property when one considers architectures that are to support cross-cultural adaptations. To take just one obvious example, the number of "bits" required to specify an English character set is not appropriate for most Asian languages.

12. Echoes. This property offers an excellent potential method for teaching a complex system. If there are echoes of complex advanced function or overall design within the setting of a small, confined first application or small function set, the transition of the user from novice to expert can be facilitated. For instance, if a small introductory word processor includes functions for making characters larger or smaller, might it work for this to foreshadow that graphics functions and more abstract functionalities also allow changes in scale, similarly evoked?

13. The Void. Christopher Alexander writes (The Nature of Order, Part I, p. 80) "In the most profound centers which have perfect wholeness there is at the heart a void, which is like water, in infinite depth -- surrounded by, and contrasted with the clutter of the stuff and fabric all around it....Is there a way that the presence of the void arises mathematically, as part of a stable unified structure, or is it merely a psychological requirement? It is the latter. A living structure can't be all detail. The buzz finally diffuses itself, and destroys its own structure. The calm is needed to alleviate the buzz."

One obvious interpretation of how this might apply to HCI design is to point to the danger of over-optimizing and re-engineering. This is another way to conceptualize the point that Harris and Henderson made.

Another interpretation is that there should be a place for the individual team, the individual user, and the individual role of the user to "fill in" with specific function. A fairly trivial example of this is simply that most "spell-check" dictionaries and Automatic Speech Recognition facilities allow the user to add their own vocabulary elements. Many systems also allow the user to store their own objects, functions, macros, etc.

14. Simplicity and Inner Calm. Christopher Alexander (Ibid., p. 85) writes "Everything essential has been left; nothing extraneous is left. But the result is simple in a profound sense, but not in the superficial geometric sense. So it is not true that outward simplicity creates inner calm; it is only inner simplicity, true simplicity of heart, which creates it."

Amen. This seems to be crying out against "feature-creep" --- the adding of the union of whatever features any competitor actually has or has pre-announced and whatever features any programmer on the team has time to program regardless of whether such features add to the actual utility of a system, application, or widget. The lack of simplicity and inner calm is even more apparent when needed aspects of a system are not allowed for in the basic architecture and must be "hacked in" later. So, it would seem that the architecting for breadth and then being austere in implementation might be one heuristic for achieving this.

15. Not-separateness. In HCI design, this seems to reflect the following interconnected set of notions.

Users do not come alive at the instant they begin using your system and die when they exit. They come with preconceptions and the system affects their lives outside and after interacting with your system. This is most dramatic, perhaps, in the case of Repetitive Stress Injury, but applies more subtly in various other cognitive and perceptual domains as well. What is the impact of continually placing the sensitive analog body movement capabilities against the crude, digital, discrete world?

Information, artifacts, and results do not live only in the space of the computer system we are designing. I visited a lab with Lewis Branscomb (former Chief Scientist of IBM) once where we were being shown a new printer. The printer was cheap and produced a curly, silver piece of paper about 5 inches by 4 inches. Lew asked the inventor, "what will the person do with this piece of paper after he gets it off the printer?" It was clear that the inventor had never considered this question. There was no existing infrastructure (folders, binders, etc.) to support the collection and use of curly, silvery, 5" by 4" pieces of paper.

Further examples of considering the "ecological validity" of design can be found in Thomas and Kellogg.

I think that the fifteen properties may serve as guiding principles to be used in conjunction with the development of a more specific "Pattern Language" for HCI. The current draft is merely a first attempt and could benefit greatly from Dialogue and critique.


WorkSpace | RecentChanges | Preferences | Random | Index | Search
This page is read-only | View other revisions
Last edited June 27, 2003 8:15 pm CentralTimeUSA by MichaelHerman
Search:
© 1998-2017 Michael Herman and www.michaelherman.com, unless signed by another author or organization. Please do not reprint or distribute for commercial purposes without permission and full attribution, including web address and this copyright notice. Permission has always been granted gladly to those who contact me and say something about themselves, their work, and their use of these materials. Thank you and good luck! - Michael