A Pattern Language



Two day workshops on HCI Patterns were held as part of CHI 2003 and CHI 2004.

A One Day Workshop on Socio-Technical Pattern Languages was held as part of CSCW 2002 in New Orleans




http://www.groupware-patterns.org/cscw2002


CSCW 2002 was held in November (16-20) in New Orleans.

http://www.acm.org/cscw2002/

Pattern Languages have proven useful in Architecture and OO programming. I've been attempting to apply them to the fields of HCI and Organizational Learning. Tom Erickson and I held a workshop on the application of Pattern Language to Human Computer Interaction at CHI '97 in Atlanta. Other workshops have been held; for instance, there was a two-day workshop at INTERACT in 1999 in Edinburgh. Another workshop was held at CHI 2000 and a panel at CHI 2001. At CHI 2002, there was another workshop on HCI patterns. In May, DIAC 02 on the future of the web decided to use patterns as the form of submission.

My colleagues and I are currently developing a socio-technical pattern language. This is meant to encapsulate useful design patterns from the social sciences. Intended users include various consultants and software designers and developers. In the software development process, our hypothesis is that socio-technical patterns will be useful throughout the entire cycle. First, patterns may suggest new applications. Second, patterns should help formulate problems and guide overall design. Third, because the pattern language links inter-related problems, the pattern language should be useful for organizing complex software development efforts. Fourth, developers should be able to provide better documentation of design rationale more quickly because, rather than writing such documentation from scratch, much of it can simply refer to the relevant patterns. Fifth, again, because the structure of the pattern language is meant to reflect the strength of interactions among various linked problems, it can be useful as a guide to testing. Sixth, both because of this property of reflecting the degree of interaction and because of the enhanced documentation, software maintenance should be easier and less error prone. Seventh, since a pattern language, through several layers of abstraction, relates requirements (aspects of the problem space) to functions and eventually to specific software components, the pattern language may even prove useful in sales and marketing efforts. Eighth, and perhaps most importantly,since the pattern language is written in natural language, it is an attempt to provide a lingua franca for all stakeholders in a complex change process that includes and surrounds any software development process. It should help computer scientists, usability experts, graphic designers, marketing, and end users communicate their desires and concerns in a way that is mutually understandable.


In the near future, we plan to publish a website which will contain the beginning of a socio-technical pattern langauge. Casual users are welcome to browse through this collection and send e-mail comments. More serious users are welcome to register and participate in discussions, suggest additional patterns, and publish software components that instantiate some of the patterns. Our website will also eventually aspire to provide tools to help pattern writers create patterns. Tools will also be provided to help designers select patterns relevant to a specific problem and help organize and compose patterns.


For some examples of socio-technical patterns and accompanying ideas, visit here

Don't be surprised to find signs that say, "Under Construction" in many places however.

Comments are welcome. The samples below are more illustrative of HCI Patterns (rather than sociotechnical patterns). We hope to add more extensive Pattern Languages later such as those developed by Jennifer Tidwell, Marinj van Welie, and Lauretta Jones and colleagues.

Check out the recent EuroPloP conference too:

http://www.hillside.net/patterns/EuroPLoP/

Here is the beginnings of what a pattern might look like in Human Computer Interaction:

Home Base: People inevitably get confused in attempting to use systems. Provide a "Home Base" -- a known context to which the user can return at any time. Issue: If you don't save any state information, the user may have to redo work. If you do save state information, then is it a "home base"? Possible resolution: You could return to home base in a navigational sense only -- data entered could be saved.

For a substantial example of an HCI Pattern Language, see Jenny Tidwell's Web site, Tidwell, J. Common Ground: A Pattern Language for Human-Computer Interface Design:

http://www.mit.edu/~jtidwell/common_ground.html

Or, Martijn van Welie's at http://www.bton.ac.uk/cil/usability/patterns/

Here's an example of a what a pattern for effective organizations might look like:

Actions determined at the edges are more sensitive to local conditions than those dictated from above. Further, people taking actions at the edges will be more motivated than if the actions are dictated from above. However, a series of uncoordinated actions taken at the edges may result in an overall effect that is self-cancelling or counter-strategic. Therefore, push for decisions to made as peripherally as possible but make sure that everyone knows the overall strategy and that widespread communication is maintained throughout the organization.

Report on Pattern Language Workshop, Malmo, Sweden, June 24, 2002

Here is a link to a brief report on the pattern language work at PDC '02 in Malmo by Doug Schuler. http://www.cpsr.org/conferences/diac02/patterns/pdc2002-workshop.doc

and http://www.cpsr.org/conferences/diac02/patterns/pdc2002-paper.doc

Doug was instrumental in the DIAC02 conference in Seattle in May of 2002. The general website for that conference also shows many patterns.

http://www.cpsr.org/conferences/diac02/

Also check out the following update:

http://www.cpsr.org/program/sphere/patterns/

If you find those patterns of interest, you may want to join a related e-mail discussion group:

Pattern-language@lists.cpsr.org

mailing list!

You can subscribe or unsubscribe or change other options by going to https://ssl.cpsr.org/mailman/listinfo/pattern-language.

To post to this list, send your email to:

pattern-language@lists.cpsr.org

General information about the mailing list is at:

https://ssl.cpsr.org/mailman/listinfo/pattern-language

Design Patterns are prescriptive; that is, they try to pair named common problems with a solution as well as analysis of the problem. Activity Patterns are descriptive; that is, they attempt to capture some recurring properties of human activity without necessarily passing judgement on whether the activity pattern observed is good or bad. However, Activity Patterns can still inform design in that a designer wants to be aware of the current situation. Examples of Activity Patterns can be found at the following:

Patterns of Activity in domestic settings

http://www.mrl.nott.ac.uk/%7Eaxc/patterns_of_home_life/patterns_homepage.htm

Some potential "Activity Patterns" (to be developed further) might be:

Escalating Conflict


Conflicts, once they erupt into causing each party pain and suffering, tend to escalate. Each party "blames" the other for the conflict and justifies their own actions in terms of retribution and prevention of further injury (by reducing the resources of the other party). This happens with individuals, but tends to happen more explosively and more consistently with groups. The shared pain (and victory) of one group tends to increase bonds within the in-group and attempts to reduce guilt result in "de-humanizing" the out-group.

Personal Power Struggle Leads to Tribal Split

What begins as a personal power struggle between two potential leaders often results in a destabalization of the tribal structure that may cause the entire tribe to split. Witness the USA 2000 Presidential election or many civil wars in Africa, S. America and so on. Luckily, the USA had a highly ritualized (even if debated and flawed) system of resolving the conflict.

Initiation

Almost every tribe has initiations. These serve a dual purpose: 1) to use cognitive dissonance in order to make the group seem more attractive to the one initiated and 2) to enhance the group to trust the individual initiated (as to motivation, but often also as to competence.

Play for a Fool

A close cousin of initiation is to play a newcomer for a fool. That is, some members of the in-group give false information to the newcomer which results in the newcomer doing something foolish but generally not life-threatening. This activity makes it clear to the newcomer that they will have to rely on the special knowledge of the group while they are getting the "lay of the land." Sometimes, the Play for a Fool is actually part of an initiation and the newcomer becomes part of the group. Sometimes, however, Play for a Fool is simply meant to turn away newcomers. And, sometimes, I believe the outcome is not forseen by the group.

Twist of Class

In every stratified society, the so-called "underclass" has some interpretation of the world or some special talent or knowledge that makes them, at least in that one sense, "better" than the so-called "upper class."

Bill Joy, one of the founders of SUN Microsystems is looking to Christopher Alexander's principles to help structure the community around JINI.

Pedagogical Patterns

Check out these links from Doug Gordin http://csis.pace.edu/~bergin/#pedpat

-- from there you link to:

http://www.pedagogicalpatterns.org/ which has some specific examples.

In general,, "pedagogical patterns" is a pretty good google query. Gregory bateson-- "the pattern that connects" -- gets referenced a lot--here's a nice essay on batesonian patterns & learning:

http://jan.ucc.nau.edu/~jwb2/research/PTC/ptcpaper.html

Mining Pedagogical Patterns by Markus Voelter:. http://www.voelter.de/publications/pospapers.html

Patterns for e-business

http://www-106.ibm.com/developerworks/patterns/index.html

and...

http://www.ibm.com/framework/patterns/ ------------------------------------------------------------------- Useful references include the following:

Alexander, C. A timeless way of building. New York: Oxford, 1979.

Alexander, C. A., Ishikawa, S., Silverstein, M., Jacobson, M. Fiksdahl-King, I., and Angel, S. A Pattern Language. New York: Oxford Press, 1977.

Alexander, C. The Nature of Order. New York: Oxford Press, In Press.

Brand, S. How Buildings Learn. Coplien, J. O., and Schmidt, D. C. Pattern Languages of Program Design. Reading, MA: Addison-Weslye, 1995.

Gamma, E., Helm, R., Johnson, R., and Vlissides, J. Design Patterns: Elements of Reusable Object Oriented Software. Reading, MA: Addison-Wesley, 1995.

Here are some interesting links:

patterns for communication software

Recent conference papers from Pattern Languages of Programs

Info on our recent CHI '97 workshop

Draft of the Workshop Report

From here, you can branch to more about patterns

Some cool ideas about patterns of effective software organization.

Home


To contact the author: truthtable@aol.com

Last modified: December 13, 2004