Stories2patterns

From stories to patterns (and back (and back again)) ‏ A pattern language network tutorial Yishay Mor, Oct. 2008

Problem: sharing design knowledge

Acceleration : the world is changing. Fast. Faster.

The design divide : access to technology is not the barrier; Access to the knowledge of how to make and use it is.

See: http://www.slideshare.net/yish/planethandheldlearning08-presentation/

The void The Prophets will tell you what should be done The Explorers will tell you what they did Current discussion of learning and technology alternates between the abstract theoretical and the anecdotal. In between there is a shortage of design-level discourse. ?

Where am I? What do I do now? You're in a hot air balloon You should find where you want to go and land there. Did I tell about the time I crossed the Himalayas in a Zeppelin?

Therefore..

Collect stories of success

Extract their essence as design patterns.

See: http://www.slideshare.net/yish/case-study-how-to-presentation How to write a case story

But ...

The long way from cases to patterns

The bull can't see his horns.

Practitioners are often too close to their story, the key element of success seems obvious to them.

“ Oh, that's common sense”

there's nothing common about common sense.

The “make something useful” pattern (aka “like, duh? ”) ‏

Avoid stating the obvious*

(yes, this is an example) ‏

Some questions to ask a case..

What are you about ? What are you an example of ?

What was successful?

What made it successful?

What in the context was necessary for it to be

successful?

When might it not work?

Do we have any other examples of this?

I see a pattern!

Name it (and rename later)‏

Write it in 30 words - NOW !

Fry it

Sing it

Draw it

C o n t e x t Problem Solution

Some questions to ask a pattern

What's your problem?

What would we do without you? (why do we need you) ‏

How are you different from X?

What are your boundaries? (when are you not relevant) ‏

Walk me through the steps

Huston. We have a problem If there isn't a problem, there's no need to design. Problems are your friends! A good problem description is half the solution. But, describing a problem is a problem Colliding forces: we want A, but need to satisfy B Elimination: Where would we be without this? Exclusion: What does this solve that a cheaper alternative couldn't C o n t e x t Problem Solution

It depends (on the ...)‏ Too broad : applicable everywhere, but hard to apply Too narrow : immediate to apply but rare application Feature deletion: Start from a story context, delete non-essential detail Boundaries: Note where this pattern doesn't apply Fusing: Find two examples, note common features C o n t e x t Problem Solution

[describe] a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice (Alexander et al., 1977)‏ C o n t e x t Problem Solution

Back to stories: rule of three (revised*)‏

Find two more examples of this pattern

Find one “near-miss”: similar story that doesn't match

Interrogate the stories, adjust the pattern.

Link

* http://c2.com/cgi/wiki?RuleOfThree

..and back to the pattern

Link to related patterns

Refine distinctions & refactor if needed

Draw clear lines between this and other patterns.

Identify part-of / instance-of relations

If needed, split into sub-patterns, add super-patterns, or merge redundant patterns.

Revisit the name & summary

Present for review

Repeat. http://xkcd.com/289/

Thank you The pattern language network project: http://patternlanguagenetworg.org Participate: http://snipurl.com/planet-workshops Yishay Mor http://www.lkl.ac.uk/people/mor.html yishaym@gmail.com This presentation http://www.slideshare.net/yish/stories2patterns-presentation