Interaction Design Patterns - Theorie · Folie 4 Design Patterns originate from architecture People...

Interaction Design Patterns

Software Ergonomics Event, February 26, 2009

Stefan Pauwels, Uni Basel / ZKB

Christian Hübscher, ZKB / Uni Basel

Pattern Event Software Ergonomics · 26.02.2009 · © Stefan Pauwels & Christian Hübscher

Folie 2

Content

  Introduction

  What are Interaction Design Patterns?

  Ways to implement a Pattern Language

  Why Patterns?

  Casestudy ZKBconnect

  Discussion


Folie 3

Content

  Introduction



  Why Patterns?


  Discussion


Folie 4

Design Patterns originate from architecture

  People can shape buildings for themselves, and have done it for centuries.

  Christopher Alexander, an architect, released „The timeless way of building“ 1979, in which he wondered:

„[...] if there was a code, like the genetic code, for human acts of building?“

Image: http://flickr.com/photos/johnmueller


Folie 5

The structure of Alexander‘s patterns

  Alexander defines a pattern as a three-part rule of:

  Context

  Problem

  Solution

  „The pattern is, in short, at the same time a thing, which happens in the world, and the rule which tells us how to create that thing, and when we must create it.“


Folie 6

Alexander‘s Patterns of varying problem scale

  Magic of the City

  Promenade

  Shopping Street

  Market of Many Shops

  Individually Owned Shops

  Building Complex

  Long Thin House

  Common Areas at the Heart

  Short Passages

  Light on two sides of every Room

  Filtered Light

  Climbing Plants


Folie 7

Light on two sides of every room

„When they have a choice, people will always gravitate to those rooms which have light on two sides, and leave the rooms which are lit only from one side unused and empty.

Therefore:

Locate each room so that it has outdoor space outside it on at least two sides, and then place windows in these outdoor walls so that natural light falls into every room from more than one direction.“

Excerpt from Christopher Alexander‘s pattern „Light on two sides of every room“.

Sourc

e: A

lexa

nder

, Is

hik

awa,

Silv

erst

ein,

Jaco

bso

n,

Fiks

dah

l-Kin

g,

Angel

(1977)


Folie 8

Software engineering adopted design patterns

  Proven solutions to software development problems appear to fit well in a design pattern form.

  A well-known collection of software design patterns was published by Gamma, Helm, Johnson and Vlissides (1995): „Design patterns: elements of reusable object-oriented software“.

Image: http://www.owlnet.rice.edu/~comp212/00-fall/handouts/week04/designPatterns.htm

In HCI, we have interaction design patterns

A definition:

An interaction design pattern is a structured description of a proven solution to a recurring interface design problem in a specific context.


Folie 10

„Auto complete“ from IBM‘s design patterns

Source: https://www.ibm.com/software/ucd/designpatterns.html


Folie 11

„Tag cloud“ from Van Welie‘s pattern library

Source: http://www.welie.com/patterns/


Folie 12

Today we have lots of HCI patterns and pattern collections

http://developer.yahoo.com/ypatterns/

http://www.welie.com


Folie 13

Content

  Introduction



  Why Patterns?


  Discussion


Folie 14

What can a pattern language do for you?

  Capture design knowledge

  Share ideas with others

  Platform for discussion and development of solutions

  Prescriptive rules / guide

  Prototyping / design tool


Folie 15

Ways to publish a pattern language

  A pattern language for anyone: Publishing your library

  As a book

  As an online collection

  You share your patterns with everyone.

  Does that mean the language has to be universally applicable?

  Or are languages always domain specific?

  Web design

  Desktop applications   Mobile devices

  ...


Folie 16

Open, community-driven pattern languages

  Many online pattern languages are community-driven

  Different people with different backgrounds can share design knowledge

  Tends to result in very broad and sparse collections

  Problems, forces and solutions have to be generalizable

http://patterns.holehan.org/


Folie 17

Building a pattern language for a specific design team

  You can build and use a pattern language for the development of in-house applications

  Such a language could be used by your company‘s

  Application users (in participatory design)

  HCI Professional

  Business Analysts

  Developers

  By staying inside a single application domain, an in-house pattern language can be better connected to (or contain) your components


Folie 18

A complete pattern language?

  If you want to use a pattern language to enable non-HCI people designing usable and consistent interfaces, the language should be sufficiently complete.

  Welie (2003): A pattern language is complete when every good design can be described using the patterns.

  Alexander (1979):

  A pattern language is morphologically complete, when the patterns form a structure with no gaps.

  A pattern language is functionally complete, when it is self-consistent and doesn‘t create forces it can‘t resolve

  Complete pattern languages seem to be rare, however Borchers (2001) reports having built and successfully reused one specific for interactive music exhibits.


Folie 19

What about Components?

They are similar to patterns:

  can be described with same attributes (when, why, …)

  are managed in a library

They are different to patterns:

  they describe always a chunk of page or screen design

  they can only be specific to one design system

  they contain code fragments

… but components and patterns can be combined.

htt

p:/

/ww

w.u

ie.c

om

/art

icle

s/co

mponen

ts_vs

_pat

tern

s


Folie 20

Sun Webdesign Component Examples

Sourc

e: h

ttp:/

/ww

w.s

un.c

om

/web

des

ign/


Folie 21

Design patterns can be categorized according to more than one dimension

  Scale of the solution   Business task cases

  Task flows

  Sreen layouts

  Basic interactions   Interface Elements

  Levels of abstraction can be bridged

  Multi Selection -> Checkbox, Selection Box

  Down to specific components

  Grouping patterns by context

  Organize patterns alongside a design process

Source: van Duyne et al. (2007)


Folie 22

Different levels of design patterns

Sourc

e: W

elie

& V

an d

er V

eer

(2003)


Folie 23

Patterns not only need structure but connections, too

  Pattern Aggregation („has-a“): A pattern is part of another pattern. This enables connections of multiple problem scales.

  Pattern Derivation („is-a“): A pattern is a specialized form of another pattern. This enables abstract patterns.

Sourc

e: K

. M

ulle

t, 2

002


Folie 24

Content

  Introduction



  Why Patterns?


  Discussion

Why Patterns?


Folie 26

Why Patterns?

Often seen in user interfaces (UI):

  bad UI architecture

  suboptimal interactions

  many inconsistencies

… we need ways to capture good UI design solutions to make them available to all people designing user interfaces …


Folie 27

Why Patterns? – Communication

In IT projects misunderstandings are very common:

Let‘s use an X to solve this...


Folie 28

Why Patterns? – Communication

Patterns provide a common language for everyone involved:

Let‘s use pattern X to solve this...


Folie 29

Ways to capture Design Knowledge

Other ways to capture «design knowledge»:

  Style guides – for platform, company, etc.

  General guidelines – applicable for different systems

  Standards (e.g. ISO)

  Claims (Sutcliffe & Caroll, 1999)

  Heuristics (e.g. Nielsen, 1994)

Sourc

e: D

eard

en a

nd F

inla

y (2

006)


Folie 30

Why Patterns?

Major contrast to other kinds of «design knowledge»:

  Level of abstraction of guidance

  Grounding in existing examples

  Statement of the problem adressed by a pattern

  Discussion of the context of application

  Provision of a supporting rationale for the pattern

  Organisation of patterns into pattern languages

  Embedding of ethics or values in selection/organisation Sourc

e: D

eard

en a

nd F

inla

y (2

006)


Folie 31

Why Patterns? – Design Principles

Dialogue principles (ISO 9241-110):

  suitability for the task

  self-descriptiveness

  conformity with user expectations

  suitability for learning

  controllability

  error tolerance

  suitability for individualization Sourc

e: I

SO

9241-1

10,

2006


Folie 32


Eight golden rules of interface design

  Strive for consistency

  Cater to universal usability

  Offer informative feedback

  Design dialogues to yield closure

  Prevent errors

  Permit easy reversal of actions

  Support internal locus of control

  Reduce short-term memory load

Sourc

e: B

. Shnei

der

man

& C

. Pl

aisa

nt,

2005


Folie 33


What are the problems with design principles:

  Sometimes they are not self descriptice – themselves

  Often they show the end – not the means

  They are only very general and high level

… but design principles can also be included into pattern languages.


Folie 34

Why Patterns? – Style guides

Sun – Java Look and Feel

Source: http://java.sun.com/products/jlf/


Folie 35


Microsoft – Windows Vista UX Guidelines

Source: http://msdn.microsoft.com/en-us/library/cc872782.aspx


Folie 36


What are the problems with style guides:

  sometimes they only focus on the look (layout etc.)

  often they only describe solutions, not when to use them

  they seldom provide a rationale

  they are not very structured i.e. not very accessible

… as general guidelines they can contain all the information that patterns consist of, but the information is often hard to find.


Folie 37

Why Patterns?

Patterns can be organized on different levels of abstraction:

On what level is my problem?


Folie 38

Why Patterns?

Patterns are easy to compare:

What xxxxxx

Use when xxxx

What xxxxxx

Use when xxxx

What xxxxxx

Use when xxxx

Which one is for me now?


Folie 39

Why Patterns?

Patterns can lead you through design:

… if the language is structured properly.


Folie 40

Why Patterns?

Patterns can lead through the levels of a user interface:

Surface

Skeleton

Structure 1 2 3 4

Source: Jesse James Garrett, The Elements of User Experience, 2002


Folie 41

Why Patterns?

Main advantages as we see it:

  Abstraction (where needed)

  Cover all levels of design in a coherent system

  Stable internal structure of individual patterns

  Organization in a language

… structuring of the knowledge as a main advantage.

Promise of patterns: they can lead through a design.


Folie 42

Content

  Introduction



  Why Patterns?


  Discussion


Folie 43

ZKB Case Study

Interaction Design Patterns

for ZKBconnect,

an advisor-workbench application


Folie 44

Discussion

Any questions?

Topics for discussion?

Next event…


Folie 45

Contact

If you have any questions or comments, please contact us:

  Stefan Pauwels Uni Basel / ZKB [email protected]

  Christian Hübscher ZKB / Uni Basel www.chuebscher.ch [email protected] [email protected]


Folie 46

Main References

Alexander, C. (1979) The timeless way of building. Oxford University Press, New York.

Alexander, C., Ishikawa, S., Silverstein, M., Jacobson, M., Fiksdahl-King, I., and Angel, S. (1977). A pattern language: towns, buildings, construction. Oxford University Press, New York.

Borchers, J. (2001). A pattern approach to interaction design. AI & Society, 15, 359-376.

Curtis, N. (2009). Components Versus Patterns. URL: http://www.uie.com/articles/components_vs_patterns/

Dearden, A. and Finlay, J. (2006). Pattern languages in HCI: A critical review. Human-Computer Interaction, 21(1):49–102

Mullet, K. (2002). Prescriptive design patterns: proactive guidance for real-world systems. Presentation held at IBM CASCON Workshop, Oct. 1, 2002

Tidwell, J. (2005). Designing interfaces: Patterns for effective interaction design. O‘Reilly.

Van Duyne, K. D., Landay, J., & Hong, J. (2007). The Design of Sites (2nd Ed.). Englewood Cliffs: Prentice Hall.

Van Welie, M. and van der Veer, G. (2003). Pattern Languages in Interaction Design: Structure and Organization. In Proceedings of Interact, volume 3, pages 1–5.

Date post:	14-Jul-2020
Category:	Documents
Upload:	others
View:	3 times
Download:	0 times

Interaction Design Patterns - Theorie · Folie 4 Design Patterns originate from architecture People...

Documents