(January 3, 2002 Draft)
John C. Thomas IBM Research - Hawthorne PO Box 704 Yorktown Heights, NY 10598
1. Executive Summary
In this paper, we argue for a new approach to the problem of ensuring that application systems are developed were are truly conceived, designed, built, delivered, and serviced in a way that enhances the productivity, effectiveness and efficiency of individuals, teams, organizations, and inter-organizational cooperative bodies. This approach is essentially to identify common functionality that is often useful but seldom implemented in specific application programs and instead instatiate this functionality into Middleware. Providing functionality that is useful to application programmers, in and of itself does not guarantee that such functionality will be used appropriately, or indeed, used at all. Therefore, in addition to providing raw functionality, we also propose to provide guidance in how to use such functionality. An initial approach to such guidance is to provide a Pattern Language for Application Developers. This Pattern Language is a lattice of inter-related Patterns, each of which helps identify, formulate, and solve recurring problems. Initially, we will focus our efforts on socially relevant software functionality. This should be distinguished from "social applications." Social applications are those whose primary purpose is social. What we will argue is that the vast majority of applications, even if their primary purpose is not social, can partake of social functionality in order to improve effectiveness and efficiency. Further, in its broadest sense, HCI-friendly Middleware could include functionality at a variety of "levels" from functions that are based on knowledge about the psychomotor and sensory capabilities of people (e.g., compensatory tracking mechanisms, color equivalency mappings among devices) to what has historically been the focus of much HCI (instrumental interactions such as menu selection mechanisms) through our initial focus of socially relevant functionality to functionality supporting still higher level business functionalities.
2. Introduction: Background and Motivation. 2.1. What is the field of HCI? Human - Computer Interaction (HCI) is an interdisciplinary field whose aim is to ensure that systems that have both computer and human components are designed to be effective and efficient and to be good for the people who use them. People in the field of HCI typically have backgrounds in computer science, engineering, psychology, education, documentation, or design. In order to design and build such systems, it is necessary to bring to bear and understanding of how people perceive, learn, think, and behave as well as how computing technology operates. In most cases, it is also necessary to bring to bear knowledge about how groups and organizations function as well.
2.2. What is the value of HCI when properly applied? The value of HCI has been established in many separate studies. Perhaps the most extensive single source is a book authored by Tom Landauer, The Trouble with Computers. The trouble, of course, is not with computers per se, but with trying to design and build systems while only paying attention to the operational properties of half the components. Few would be foolish enough to design a human-computer system without any detailed understanding of the computer technology, relying instead on an implicit mental model of computers. Unfortunately, all too often people have designed human-computer systems without any detailed understanding of how people work, relying instead on an implicit mental model of how people operate.
This is to some extent an understandable error. After all, as people, we do interact with other people all the time and it seems like common sense that we would learn how they operate. Unfortunatley, this is not true. Recall that people interacted with and had to survive in the physical world for many millenia but until a systematic approach to understanding the physical world was undertaken, people had many fundamental misconceptions. Even today, people who grow up in our culture without formal training in physics and astronomy have extraordinarily inaccurate intuitive models even of some of the most basic properties of the world around them. Many people believe, e.g., that it is warmer in summer because the earth is closer to the sun; that if the earth stopped spinning on its axis, we would fall off because there would be no more gravity; that if you whirl a stone in a sling around your head in a circular path and then release it, it will tend to bend in its path in the same direction you were spinning it; that the heavier something is the faster it will fall and so on.
Similarly, people's intuitive models of human behavior are similarly flawed. A case in point is the "fundamental attribution error." Basically, both laboratory and field studies show that behavior is primarily determined by circumstances but people believe that their behavior is primarily determined by their internal decision making. Another common adage is that "you can't teach an old dog new tricks." People believe that older people have great trouble learning new things. In reality, in healthy aging, age effects over the range from 20 to 70 years are small (age-related change is about 1/4 the variance due to individual differences within an age group of "normal" healthy people) compared with individual differences. Furthermore, the impact of aging on learning depends to a great extent on the circumstances under which learning takes place and on the nature of the learning task. In some cases, older individuals can use knowledge they have gained about learning how to learn in order to learn faster than young people; in other cases, previous knowledge can make learning new knowledge harder.
These are just two examples, and many more could be added, but the main point is that merely "experiencing" the world does not lead to correct models of physics or psychology. What Landauer documents is that spending money on new Information Technology systems that allowed processes to be completely automated led to significant productivity enhancements. However, when systems require human-computer interaction, new Information Technology systems typically only result in about a 1%/annum productivity increase. In a score of cases, however, new systems were designed by taking into account what is known about how people operate and prototypes were tested and revised before final design. In these cases, the average productivity gain was 33%/annum.
2.3. What are the HCI methodologies?
A number of different methodologies have been developed for designing and building good human computer interaction systems. Initial designs can be constructed with a scientific understanding of how people operate (from the social sciences) in mind. This knowledge exists in varying degrees of specifity. In some cases, there are specific facts that are known and fairly general. For example, we know how large typefonts have to be at certain distances to be read by certain percentages of the population. We know that keyboards that give auditory and tactile feedback lead to fewer errors and faster typing. We know that people can generally recognize faster than they can generate. We know that, on the whole, performance increases with practice according to a fairly predictable power law. This means that if we observe the improvement in performance over a short period of time, we can be fairly accurate in predicting asymptotic performance. In a few cases, with very well learned routine behaviors such as typing, reading, and talking, we can make fairly detailed mathematical models that can be used to "test" out proposed systems.
Despite a large body of knowledge however, it is generally the case that new systems with any degree of complexity exhibit emergent properties. To build good systems, it is generally necessary to do some prototyping and get feedback by watching users attempting to use the prototype doing real tasks in a situation that mirrors as closely as possible the real context. Thomas and Kellogg (XXXX) document some of the difficulties in extrapolating from laboratory studies of behavior to the field.
Although empirical studies have been shown to have a high Return On Investment (ROI) relative to most of the other expenditures in development projects, it often turns out to be the case that people are reluctant to build and adequately test prototypes. A number of "faster" methodologies can help. For example, mindless inconsistency in interface conventions among various modules can be minimized by having all developers adhere to a "style guide" that specifies how certain functions will "look and feel." Intelligent architectural design can be employed to make modifications easier; e.g., putting error messages in a table and making sure that every separate error source leads to a separate error message, at least initially. A prototype or even a design can be evaluated by a "heuristic evaluation." In this process, a small set (5-10) of HCI experts independently looks over the design or prototpye and, based on experience and principles, points out potential difficulties. This typically results in finding about 50 to 85% of the problems (with 5 evaluators) up to 65 to 85% (with 10 evaluators) (Nielsen and Landauer, 1993). There is some evidence that these numbers might be improved by encouraging evaluators to sequentially take different viewpoints (Desurvire and Thomas, XXXX).
Despite the fact that a number of effective HCI methods have been developed, it is still the case that numerous applications that people spend enormous amounts of time with have not used these methods and have severe problems in terms of their effectiveness and efficiency. These problems have continued to plague new hardware and software products for the entire history of the IT industry. A recent laptop, for instance, very nicely designed in many respects has the property that if one simply moves the laptop in the most natural way from desk to lap, the hard drive door flies open and the machine must be rebooted. A recently developed system for ordering equipment asks the user to go through ten modules just to learn to use the system! Since this is a system that the vast majority of users will only use a few times a year, anything that requires that much learning will probably require substantial relearning each time the system is used. By way of contrast, most users, without training, are successful at ordering books from Amazon.com the very first time.
The lost productivity from ineffective or inefficient systems is typically not measured. The users are simply supposed to read manuals, ask each other, use help systems and call support until the problem is solved which eventually it is. The lost productivity to companies is enormous. The process to be followed to minimize the problem is known. The effectiveness has been demonstrated. Yet, the process is often not followed. This situation is not unique, however, to Human-Computer Interaction. Fred Brooks demonstrated (and common sense would verify) that the two most common management responses to a slipped software schedule; viz., adding more people and requiring more frequent progress reports are both counterproductive. Yet, these practices also continue (Brooks, 1975).
The HCI methods can also be misapplied. While testing can reveal problems, it does not often specify solutions. The design space of possible interfaces is obviously enormous. Misapplied, one can imagine a kind of thrashing going on looking for a "perfect" interface and never converging on any one design. Apparently, a real case of this may have occured in the Advanced Automation System (Britcher, 1999).
2.4. How broadly effective is the current HCI methodology?
When applied, the current HCI paradigm seems to work fairly well in individual applications. For example, in one series of studies done on a new telephone service, six iterations were done in five weeks and in the last iteration, users were making 1/3 the errors and were finishing tasks in 1/3 the time compared with the first iteration.
However, what is not clear is how often this (or any other appropriate) methodology is applied. An examination of the web makes it clear that there are many sites that are confusing to navigate and where it is hard to find things. Moreover, it is even more clear that while individual application programs may or may not have good HCI, it is rare that an overall integrated system has good HCI.
3. An Alternative Proposal: HCI-Friendly Middleware
3.1. What are the factors of good HCI?
A system with "good" Human-Computer Interaction is designed, built, implemented, delivered and supported in such a way that it is based both on a solid understanding of computer science (understanding what computer technologies can do and how best to accomplish those aims) and social science (understanding how people operate individually and in various kinds of groups). In order to reach this goal, the system designer should ideally understand the particularities of the computer system that they are building upon. In the early days of computing, it was extremely important for systems analysts and programmers to understand the specifics of the hardware for which they were programming (how many cycles does it take to do a Shift versus an Add?). Later, this became less important, but programming still needed to focus on the specific operating system that they were using. Now, the focus has shifted to building platform independent functionality; e.g., in Web Services.
Just as the hardware of a PDP-8 and an IBM 360 (although both based on a Von Neumann architecture) were quite different, so too, in order to build a system that is optimal for people, we need to understand who the people who will use the system are. People may vary in their physical capabilities, their educational backgrounds, their native and secondary languages, their motivations, their social context, their environmental context, their ability to learn and use arbitrary mappings, their spatial abilities, their visual discriminations and so on. If cost were no object, every system would be optimized both for the machinery and operating systems that were involved and for the specific human beings that were to use the system. However, cost does matter. As a practical matter, it is necessary to generalize (hopefully intelligently) in the human dimension no less than in the computer science dimension to provide functionality that is widely useful under common sets of circumstances.
3.2. What functionality and data should be included in Middleware?
The complete system of functionalities and data that could be included in middleware will evolve over time. However, the following constitute a substantial initial list. Each item in the list will be expanded upon.
* Social Network Analysis
* Formal Organization
* Multidimensional Fuzzy Search
* Handling of Interacting Goal Structures
* Conversational Agents
* Embedded Style Guides for Perception, Motor Control, Cognition
* Creativity Tools
* Monitoring and Feedback Functions
* Business Process Pattern Language
* HCI Pattern Language
* Accessability and Transcoding Functions
* State Tables for Interaction Description
* Hierachical Help Function
* Post-It Notes for Processes
* Physical Proximity Processing
* Historical Functionality
3.2.1. Social Network Analysis
A social network analysis is basically a way of describing who communicates with whom and who has influence over whom. There are a variety of techniques for conducting a social network analysis; essentially, it is done through clustering techniques. There are also a wide variety of methods for displaying social networks visually. In the case of HCI Supportive Middleware, evidence for social networks need not be gathered via survey (as is often the case) but can be inferred from the behavior of the users of a system. Various kinds of evidence could include e-mail distribution lists, e-mail patterns, overlap in websites visited, and a statistical treatment of documents produced by various individuals. Social networks change over time, of course, but they tend to change over the course of weeks, not seconds. Updates to the social network analysis would be done periodically. Once such an analysis has been done, its current state can be used in a variety of other applications. For example, the social network analysis (SNA) could be used by an agent to help build e-mail distribution lists. The SNA could be used for collaborative filtering of web searches, to suggest newsgroups, and for helping project planning.
3.2.2. Formal Organization. Middleware that includes a representation for the formal organization can provide more intelligent functionality. For example, the formal organization can be used to help form e-mail distribution lists, prioritize e-mail, allow for delegation and for authority control on signoffs.
3.2.3. Multidimensional Fuzzy Search. It is often the case that people know something on each of many dimensions about a file, document, program, person, or website that they want to find but they may not recall any specific piece of information exactly. In trying to fill a staffing vacancy, for instance, I may specify that I want someone with 10 years programming experience and 2 years JAVA experience. The best match, however, might be someone with 15 years programming experience and 1 year, 11 months JAVA experience. Or, I may be trying to recall a document I authored about 2 years ago that was about 20 pages long and related to improving creativity. The actual item desired may be a document that I authored 1 year and 10 months ago, be 28 pages long, and use the term "innovation" rather than "creativity." In the service of many specific functions within a host of applications, it would be useful for the program to be able to find near matches on several dimensions simultaneously. To provide such functionality efficiently and separately in each application however would be too expensive, both in terms of programming and in terms of runtime efficiency.
3.2.4. Handling Interacting Goal Structures. One of the challenges of large scale organizations is to ensure that people in various departments are not working at cross-purposes. In a particular hierarchical organization for example, the customer service representatives who gave out calling card numbers to new business accounts had to get these numbers by calling the accounting department. But customer service reps were only allowed to make outgoing calls from noon to 1 pm --- exactly the time the accounting department went to lunch. This meant that new business accounts often had to wait many days after trying to open an account before they could actually begin having their employees use the calling cards. In the same company, it was clear that three separate organizations had been responsible for developing Examples of this type could be multiplied. In order to avoid having a single software project that is of unmanageable complexity and enormous expense, it often happens that systems are developed piecemeal.
3.2.5. Conversational Agents. A natural way for people to interact is via conversation. There is now some evidence that web sites with conversational agents result in people spending more time there than similar sites without conversational agents. Yet, building conversational agents is not simple. Rather than having each application develop its own conversational agents from scratch, it makes much more sense, both from an economies of scale perspective, and from the perspective of giving users a consistent experience to have this basic functionality provided in the middleware layer. Clearly, some material of an application specific nature will still have to be generated because the conversational agent will need to have knowledge of content. But parsing user sentences, dictionary look-ups, and conversational modeling including the handling and repair of misunderstandings as well as the general treatment of conversational "meta-language" (e.g., "I'm confused." "Can you go over that again?" "Can we go back to the previous topic?") can best be accomplished at a Middleware layer.
3.2.6. Embedded Style Guides. Style guides increase the efficiency of the application development process by limiting the number of decisions application programmers must make about user interface issues. The style guides can incorporate answers that are known to work. In addition, style guides help provide a consistent look and feel for users making cross-application learning easier. Style guides may exist in the form of off-line written documentation, but given current hardware costs, there is no reason not to have style guides actually embedded in the Middleware layer as hyperdocuments. In addition, by having the style guides embedded, links may be programmed to code examples. A further advantage of embedding style guides in the Middleware layer is that updates due to new technologies or new findings can be disseminated in a controlled fashion. A final advantage of actually having the style guides embedded in the Middleware is that users themselves may be given access to read the style guide in order to understand the fine points of conventions. In effect, the style guide can serve as an extended help facility.
Style guides may be organized in a variety of ways. No one of these ways is best for all purposes; hence, the advantage of making it an on-line hyperdocument. Style guides can include guidelines about various means of providing input to the computer, various means of providing output, and style guides more closely related to cognitive tasks.
3.2.7. Creativity Tools. In a world changing at an ever increasing pace, reliance on old solutions will not be sufficient, either for organizations or for individuals. Online creativity tools can be useful to people working in a wide variety of occupations in a wide variety of industries. Examples of creativity tools include mind map tools, brainstorming tools, tools to help keep track of semi-structured conversations, and composition tools. Example tools can be viewed at www.research.ibm.com/knowsoc/ under "Prototypes."
An advantage of having such tools in a Middleware layer is that some tools; e.g., tools that rearrange words to stimulate thinking can draw on the vocabulary and visual elements of specific documents or application programs.
3.2.8. Monitoring and Feedback Functions. No matter how well-designed an application is, there will be some occassions when it is confusing, unusable, or has hard bugs. In such cases, users typically call up help desks, ask colleagues, or search help or documentation to try to understand and overcome the problem. Seldom do any of these avenues result in enlightenment on the part of the system builders however. Monitoring and feedback funtionality built into the middleware layer can provide application programmers with feedback about how often their program is used and by what kind of users, which functionalities are actually used for how long and in what order, what types of information is passed back and forth among applications and modules within applications and so on. Of course, each application programmer could theoretically build such monitoring functionality into their software but they seldom do and since the functionality is overwhelmingly common, it makes more sense to embed such functionality into the Middleware layer.
3.2.9. Business Process Pattern Language. A Pattern is an outline of a common interacting set of problems and the associated solution. A Pattern Language is a lattice of Patterns. A Business Process Pattern Language would describe common issues in business and suggest ways of dealing with those issues.
The idea of having a Business Process Pattern Language embedded in the Middleware layer is to provide some common semantics and pragmatics for application software to reference. In this way, documentation for each application program can be simplified, especially with regard to issues such as the purpose and context of the various functions in a program. More importantly, pressure toward a common vocabulary and coherent ways of framing problems and solutions will be brought to bear. Relationships among programs can be made more obvious as can gaps of functionality left by the conglomeration of programs.
The Business Process Pattern Language can ultimately be tied to Object Oriented Code Patterns as well. In the meantime, the Business Process Pattern Language itself can also serve as a kind of meaning and coherence binding for users. Each user can "see" how the functions they perform in their own job interact with, support, and are supported by related business processes. Quite apart from any software, this can provide an invaluable service both in terms of motivating people and in terms of limiting suboptimizing behavior within an organization.
A Business Process Pattern Language can also help identify potential opportunties for IBM consultants and sales. The generic language gives a context and intermediate representation between business issues and challenges on the one hand and potential functionalities on the other.
3.2.10. HCI Pattern Language. A Pattern Language can also be developed around Human Computer Interaction. Indeed, many patterns in such a language have already been proposed. It is feasible to put a pattern language in a book. This is what Christopher Alexander did for architecture and the "Gang of Four" did for Object-Oriented Programming Patterns. Again, however, actually embedding the Pattern Language as a hyperdocument in the Middleware offers advantages.
3.2.11. Accessability and Transcoding Functions. Information should be presentable to people on a variety of devices, and in a variety of ways even on a single device because of variations in environmental context, task, and user abilities and/or preferences. For instance, some users may be blind and web sites should allow for textual decriptions that can be rendered by a speech synthesizer. As another common example, pages suitable for large screens may need to be summarized and otherwise massaged for reading on a Palm Pilot. Conceivably, each application could deal with these numerous contingencies and combinations, it makes much more sense to provide a generic solution.
3.2.12. State Tables for Interaction Description. An architectural ploy that allows for a clear understanding of interface issues, easy documentation, and easy modification is to have the user interface be implemented as a state transition table. On-line help and on-line as well as printable documentation can be driven off this same table forestalling the possibility for actual behavior to be at odds with documentation. By having all the interface "code" be in one format and one place, it is much easier for an application developer to ensure consistency at any one point in time as well as making modification and testing easier. Of course, each application development team could independently decide to use state transition tables in this way, but providing an easy way to implement them via Middleware functionality could greatly increase the chances of this happening.
3.2.13. Hierarchical Help Function. On-line help should theoretically allow a significant advance over printed documentation. In practice, on-line help is often not very helpful. There are several paradoxes that must be dealt with. The first paradox might be refered to as the "pig in the clouds" phenomenon. In puzzle books, complex pictures such as clouds might hide another complex picture such as a pig. It can take quite awhile to "find" the hidden figure. But once you "see" the hidden figure, such as a pig, it is nearly impossible "not" to see it from then on. Software developers, in the course of designing and building a product are forced to face and solve a large number of challenging puzzles. Once these puzzles are solved, however, the design begins to make a kind of "Gestalt" or good form for them. It is exactly some of the most fundamental and basic aspects of an application program that end up being both confusing for end-users and not documented in the help system because they are so "obvious" and fundamental to the entire mindset of those that developed the product.
A second paradox has been named, "the paradox of the active user" and refers to the fact that people are almost always trying to use a product to get real work done and typically only explore various functionalities deeply enough to get something accomplished. Unfortunately, this often means that they discover a method of using the application to get something done but hit on a very inefficient method. They do not ask for help about how to do the job more efficiently because they do not even realize that there is a problem. 3.2.14 Historical Functionality. Historical functionality, in a rudimentary form, does exist on many systems today. Many applications; e.g., WordPro, Word, Netscape allow one to choose from a short list documents or websites based on recency. However, this function, while very useful, barely begins to scratch the surface. One of the chief limitations of human memory, particularly in social circumstances is its fallibility. (Humans are subject to a wide variety of distortions of historical reality including recency, primacy, the "halo effect", the fundamental attribution fallacy, and so on.) The computer, on the other hand, has accurate and extensive recall. This affords the possibility that individuals, teams, organizations, and inter-organizational coalitions may be able to record, store, retrieve, and process information about their own behavior with unprecedented accuracy. This is not necessarily an unmixed blessing. It is possible that the "distortions" that human memory typically evidences has some benefits that we are unaware of. Under the assumption that knowledge is better than ignorance, however, we assume that providing accurate historical information and calculations on social interactions will ultimately provide value.
3.3. Knowledge in HCI can be cumulated in Pattern Languages.
3.4. How can Pattern Languages be related to Middleware?
4.0. What is the process for developing HCI-friendly Middleware?
4.1. How can Pattern Languages be developed?
4.2. What are the various levels of Pattern Languages?
4.3. Some example socio-technical patterns.
4.4. Supporting Flow and Breakdown with Different Views of Knowledge
Forces:
Users are often trying to achieve a specific goal and often learn non-optimal methods and are too busy to change (referred to as the "paradox of the active user."). Users who are trying to achieve a goal want quick, relevant information; this led to "minimalist design." (Originated with John Carroll's work at IBM). More recent work by Bonnie John on architects' (inefficient) use of drawing tools shows that long-term interaction with systems does not automatically lead to optimal tool use.
Learning to use new tools and technologies sometimes requires more extensive time commitments in order to see patterns of use; in order to understand when and how tools should be combined.
Solution: Provide (at least) two different views of relevant tools, techniques and methods; one for use when a user is beginning a project, is stuck or between goals, has an idle moment; one for use when the user is actively engaged in a goal-directed activity. The former can be more conceptual, include stories and catalogues. The latter should be more in the style of Minimalism.
Removing Organizational "Scar Tissue" with Bohm Dialogue
Forces:
Organizations need to learn from their mistakes. When a problem occurs, a process or procedure can be put in place to prevent this from happening again.
Processes and procedures multiply endlessly and eventually the organization grinds to a halt. The "cure" of adding another process can be worse than the disease.
Solution: There needs to be a process for discovering, reevaluating, and discarding processes that are contradictory, no longer needed, or not worth the work. Bohm Dialogue, being a process that builds larger organizational perspectives can allow the organization to discover process and procedure that is no longer needed. Since getting groups together in one place at one time is onerous, technology can support distributed asynchronous Dialogue.
Using Scripts and Stories to Gather Information Less Onerously
Forces:
The organization needs to learn from its experiences. Novices need to gain from the experience of experts.
Experts are busy. They are often not motivated to fill out long, complex forms that ask for "obvious" and "redundant" information.
Solution: Stories are a natural way for experts to share their experiences. Gathering stories allows for efficient information collection since stories are about script failures; that is, failures of expectation. The expert does not need to describe the script, only the exception. Scripts however, are needed to help the novice put individual stories into a broader perspective and can also be used as an effective browsing space.
Using Anonymized Stories for Organizational Learning from Mistakes
Forces:
The organization needs to learn globally from the experience of those who made mistakes so that the same mistakes do not get repeated.
Individuals who frankly describe and broadcast mistakes they have made will be "blamed" for the mistakes and, in some cultural contexts, lose face, opportunity, and money.
Solution: Provide a tool to "anonymize" stories so that the organization can learn but the individual is protected.
"Who Speaks for Wolf" -- Automated Stakeholder Remindings
Forces:
Gaps in requirements are most cheaply repaired early in development; it is important for this and for reasons of acceptance (as well as ethics!) by all parties that all stakeholders have a say throughout any development or change process.
Logistical difficulties make the representation of all stakeholder groups at every meeting difficult.
Solution: Provide automated remindings of stakeholders who are not present. These could be procedural (certain Native Americans always ask, "Who Speaks for Wolf" to remind them) or visual or auditory with technological support.
Actively Reminding Participants about Shared Context and Goals
Forces:
People focus on problems at hand. This is good because the complete intellectual capability can be brought to bear on a small (but critical path) subproblem.
This focusing capacity has its downside however. People who share common higher level goals can forget them in the heat of arguing about lower level details.
Solution: Actively remind people via display (visual, aural, tactile) of their shared context and higher level goals.
Example: Married couple decides to hold hands whenever they have a disagreement to discuss.
Using Stories to Describe When and Why
Forces:
People are often pressed for time and want only the information necessary for them to reach a goal. Computer FAQs, help systems, Guided exploration cards, etc. are good for finding specific answers about how to invoke a specific functionality.
People may not realize a particular functionality even exists; hence, do not know to ask about it. People may not realize how to integrate a technological functionality with social factors. For instance, a person may know how to invoke e-mail but have no feel for which situations call for e-mail, which are better done face to face.
Solution: Use stories of use that integrate the technological with the non-technological; that show the appropriate to-be-modeled social behavior with respect to technology. Use stories to explain when and why to use systems, not just how.
Registered Anonymity to Balance Responsibility and Honesty
Forces:
Information that is anonymous may be irresponsible because there is no accountability.
Information that is associated publicly with a person will tend to force people to put themselves in a good light, making learning from mistakes difficult.
Solution: Register actual identity with a trusted authority (to ensure responsibility) and associate the actual identity with a virtual identity that is not shared in the community of learning.
Example: Amy Bruckman's handling of Moose Crossing, a virtual community for latchkey children to teach each other object-oriented programming via the web.
Answer Garden to Balance Needs of Experts and Need for Expert Knowledge
Forces:
Experts tend to be very busy and do not want to answer the same questions over and over. FAQ's help but do not deal with novel and unanticipated questions. Any given expert may have some periods in which they are happy to answer novel questions, but these may not coincide with the novice's need for information.
Novices need to learn from experts in order to become more expert themselves. Sometimes, a few minutes of an expert's time may save many hours of needless work on the part of a novice.
Solution: Provide an "answer garden" (Mark Ackerman) in which a pool of experts agrees to answer questions asynchronously put by less expert people. The question trees "grow" incrementally and provide a knowledge repository.
Mullah Rabin Stories for Organizational Learning
Forces:
Organizations need to learn from experiences. In many cases, learning comes form various types of mistakes.
Individuals do not want to be associated with failure.
Solution: Stories are created and disseminated which capture an incident, event, or error. But these stories are projected onto a well-known fictitious cast of characters.
Example: The British Navy had a method of collecting "errors" and publishing them in a comic strip in which it was a particular fictional error-prone Admiral who was always portrayed as making these errors. The real perpetrator's identity was not disseminated, but all the people could see the value of avoiding this mistake.
Using Virus Covered Context Stories to Change from Negative Stories to Positive Stories
Forces:
Stories naturally occur in a social (and therefore an organizational context) that reflect some of the worries and cynicism in a group. It is unnatural and impossible to prevent people from retelling such stories.
Negative stories are disruptive to morale and can prevent needed change.
Solution: In some cases, it is possible to add an outer layer of context to a natural story which changes the meaning from negative to positive.
Example: An organization wants to promote more innovation. However, negative stories are circulated to the effect that anyone who tries to innovate gets shot down. E.g., "John Jones tried a new idea, and his manager Steve Stevenson reamed him out in front of everybody." Here, additional context might be, "Yes, but when the VP found out about that, he transferred Stevenson out of R&D into accounting where such strict rule-following is to be rewarded and then promoted Jones." Needless to say, management actions have to be consistent with the story.
Moving Conflict Internally to Enhance Story Credibility
Forces:
A good success story about a product, method, or service helps other potential customers, users, etc. see the relevance and become motivated to attain similar success.
Stories that have no conflict are boring. Stories which feature one-dimensional characters are boring unless the external conflict deals with value changes beyond those that most products and services and methods actually impact (e.g., life vs. death). Stories which are touted by authority tend to lack credibility whether the source is a company trying to sell its wares externally or an organization trying to exhort its people internally.
Solution: Build intra-psychic conflict into the protagonist such that he or she examines the pros and cons of the situation and then decides to take the action. Build interpersonal conflict into the drama such that the protagonist has to win over initially resistant users.
Ratchet Incremental Social Gains with Infrastructure
Forces.
Change often happens through informal social interchange; new and better ways of doing things arise.
Positive changes that occur within a group of people may be lost when that particular group of people disappears through attrition, transfer, death, etc.
Solution: Provide institutional and technical infrastructure that reinforces "good solution" so that new people will perpetuate the solutions. Examples of how such learnings could become part of infrastructure include computer application programs, procedures, songs, and architecture.
Building Stories with Common Values to Bridge Communities
Forces:
Each community naturally creates their own stories which help build social capital within the group.
Different communities have different stories and this helps divide communities who must cooperate.
Solution: Create stories that stress the commonalities between communities that must cooperate such as warring tribes, merging companies, departments that must work together.
Supporting Social Change via a Community of Communities
Forces:
Large scale social change requires the activity and commitment of many people.
Smaller communities have more credibility and knowledge of what works for their own community.
Solution: Develop a ring of rings. People who are leaders in their individual communities also get together to form a larger community. The larger community of leaders agrees on basic principles and goals. The individual communities determine how to implement and actuate within their own community.
Example: Karl-Herik Robert began the "Natural Step" program in Sweden and grew it in this manner. (This is a program to lead Sweden to a sustainable economy).
Help Desk Supports Design
Forces:
Help desk personnel are under pressure to act quickly and efficiently to solve the problem at hand.
Help desk personnel gain information about the customer problems over time.
Information about the problems that customers have is potentially valuable for future products and services.
Help desk personnel have high turnover rate and their knowledge is lost.
Solution: Use technology and/or specialized personnel to capture and organize the knowledge gained by armies of help desk personnel and then make sure this is fed forward in a timely manner to the development team for subsequent related services and products. Not only should this help produce better products and services; it may also help the Help Desk personnel feel that they are contributing to longer term goals (not just fire-fighting) and thereby reduce turnover.
A Suggested Socio-Technical Interaction Pattern.
Support Social Translucence in Virtual Communities.
In daily life, we often use social cues to help guide our behavior. If we hear a commotion in the hall, we may poke our head out to see whether there is an emergency, some fun to join in, or merely an irrelevant distraction. In a moment, we can gather from the people that are there, and the way they look and interact, which of these three possible reactions is appropriate. People are spending less and less time in face to face social interactions. Many organizational interactions are now via e-mail, data bases, or newsgroups. Yet, typically, these virtual methods give little in the way of social clues. If we visit a webpage, e.g., we have no idea how many other people are there, who they are, their level of interest, or their attitude toward the material.
Support virtual communities by providing social clues about who is there and what they are doing.
There are a variety of methods being experimented with to provide such cues including the use of video, the use of avatars with controllable "faces" put into a common space, and more minimalist approaches such as "Babble" which uses a social proxy to give information graphically about who is in the conversational space, how long they have been there, what their activity pattern has been (Erickson, et als, 1999).
Forces:
People can behave more intelligently and productively as a group if they are aware of what other group members are doing.
Having a common space helps build social capital.
People need to feel part of a group.
People need to have a sense of privacy.
Social interruptions can detract from concentrated mental work.
A webcam in constant use helps people be aware of remote collaborators but is felt to be too intrusive by most people. It is too transparent. E-mail and the web allow remote collaboration but provide no social cues. It is opaque. The use of socially translucent systems allows a reasonable compromise between the need for group awareness and the need for privacy and being able to focus on your own work.
Related Patterns:
Support Conversation.
(Conversation is a first class part of work and should be supported technologically).
Incremental Value Groupware.
Groupware systems that require full participation by everyone before anyone gains value are inherently unstable. A system that provides incremental value --- so that every additional person who joins adds value to all will be much easier to adopt.
Actively Reminding Participants about Shared Context and Goals. Gradient of Synchronous and Asynchronous Communication.
(In real life, our memory slowly fades. Sometimes, memorable events are captured in stories which are retold. Some stories seem so important that we write them down. In the electronic world, we typically have completely different media for chat, for e-mail, and for archival knowledge --- e.g., team rooms. When something moves from one system to another, extra work is required. Provide a blended synchronous, asychronous evironment instead).
Expressive Communication Builds Mutual Trust.
Only actions that are voluntary build mutual trust. In an organization, if someone engages only in "instrumental" communication; that is, communication that is required for work to get done, nothing of the character of the person communicating is revealed. By contrast, conversation, stories, and other expressive means of communication reveal something of the underlying character of the communicator. In this way, a more extensive mental model of the communicator can be built; mutual trust can result.
4.4. Some example business process patterns.
5.0. References.
Brooks, F. P. Jr. The mythical man-month: essays on software engineering. Reading, Mass.: Addison-Wesley, 1975.
Britcher, R. N. The limits of software: people, projects and perspectives. Reading, Mass.: Addison-Wesley, 1999.
Gould, J. How to design usable systems. In Helander, M. (Ed.), Handbook of Human-Computer Interaction. North-Holland: Elsevier, 1988, 757-789.
Lewis, C. & Rieman, J. Getting to know users and their tasks.