Sunday, September 04, 2005
A Pattern Approach to Interaction Design
Find it at http://media.informatik.rwth-aachen.de/materials/publications/borchers2000a.pdf
I think this part would be the most relevant...
Each pattern of a language captures a recurring design problem, and suggests a proven solution to it. The language consists of a set of such patterns for a specific design
domain, such as urban architecture.
Each pattern has a context represented by edges pointing to it from higher-level patterns. They sketch the design situations in which it can be used.
Similarly, its references show what lower-level patterns can be applied after it has been used. This relationship creates a hierarchy within the pattern language. It leads the designer from patterns addressing large-scale design issues, to patterns about small design details, and helps him locate related patterns quickly.
The name of a pattern helps to refer to its central idea quickly, and build a vocabulary for communication within a team or design community.
The ranking shows how universally valid the pattern author believes this pattern is. It
helps readers to distinuish early pattern ideas from truly timeless patterns that have been confirmed on countless occasions.
The opening illustration gives readers a quick idea of a typical example situation for the pattern, even if they are not professionals. Media choice depends on the domain of the language: Architecture can be represented by photos of buildings and locations; HCI may prefer screen shots, video sequences of an interaction, audio recordings for a voicecontrolled menu, etc.
The problem states what the major issue is that the pattern addresses.
The forces further elaborate the problem statement. They are aspects of the design that need to be optimised. They usually come in pairs contradicting each
other.
The examples section is the largest of each pattern. It shows existing situations in which the problem at hand can be (or has been) encountered, and how it has been solved in those situations.
The solution generalizes from the examples a proven way to balance the forces at hand optimally for the given design context. It is not simply prescriptive, but generic so that
it can generate a solution when it is applied to concrete problem situations of the form specified by the context.
The diagram supports the solution by summarizing its main idea in a graphical way, omitting any unnecessary details. For experts, the diagram is quicker to grasp than the
opening illustration. Media choice again depends on the domain: a graphical sketch for architecture, pseudo-code or UML diagram for software engineering, a storyboard sketch for HCI, a score fragment for music, etc.
The rest are how to use the patterns etc... then its mostly for music (Worldbeat). Some of its references look interesting though. This article mostly provides a framework to build on.
I think this part would be the most relevant...
Each pattern of a language captures a recurring design problem, and suggests a proven solution to it. The language consists of a set of such patterns for a specific design
domain, such as urban architecture.
Each pattern has a context represented by edges pointing to it from higher-level patterns. They sketch the design situations in which it can be used.
Similarly, its references show what lower-level patterns can be applied after it has been used. This relationship creates a hierarchy within the pattern language. It leads the designer from patterns addressing large-scale design issues, to patterns about small design details, and helps him locate related patterns quickly.
The name of a pattern helps to refer to its central idea quickly, and build a vocabulary for communication within a team or design community.
The ranking shows how universally valid the pattern author believes this pattern is. It
helps readers to distinuish early pattern ideas from truly timeless patterns that have been confirmed on countless occasions.
The opening illustration gives readers a quick idea of a typical example situation for the pattern, even if they are not professionals. Media choice depends on the domain of the language: Architecture can be represented by photos of buildings and locations; HCI may prefer screen shots, video sequences of an interaction, audio recordings for a voicecontrolled menu, etc.
The problem states what the major issue is that the pattern addresses.
The forces further elaborate the problem statement. They are aspects of the design that need to be optimised. They usually come in pairs contradicting each
other.
The examples section is the largest of each pattern. It shows existing situations in which the problem at hand can be (or has been) encountered, and how it has been solved in those situations.
The solution generalizes from the examples a proven way to balance the forces at hand optimally for the given design context. It is not simply prescriptive, but generic so that
it can generate a solution when it is applied to concrete problem situations of the form specified by the context.
The diagram supports the solution by summarizing its main idea in a graphical way, omitting any unnecessary details. For experts, the diagram is quicker to grasp than the
opening illustration. Media choice again depends on the domain: a graphical sketch for architecture, pseudo-code or UML diagram for software engineering, a storyboard sketch for HCI, a score fragment for music, etc.
The rest are how to use the patterns etc... then its mostly for music (Worldbeat). Some of its references look interesting though. This article mostly provides a framework to build on.
# posted by ~Z~ @ 3:45 PM 
