Mattias et al,
I'm a big fan of patterns, so I'm going to stop grading exams to comment. :-)
It would be nice if there were "infrastructure" to validate patterns - I'm
thinking here in terms of the infrastructure (and its costs) to validate
anything else. I don't think it will happen any time soon. It would have to
be a large undertaking - after all, what good is a pattern language with only
a very few validated patterns?
And might we succumb to a variation of 'analysis paralysis' - not wanting to
use a pattern till it's been validated up the yin-yang and back.
On the other hand, even as they now stand, I think patterns fill an important
niche area. They give us something we can use /now/, in the absence of truly
validated methods/techniques/whatever.
Perhaps there's an intermediate step. Imagine a system that tracks which
pattens users are accessing, and some very simple buttons on each pattern that
say something like "Was this pattern useful?" and let users indicate coarsely
their answer. One might then mine that survey information and follow up with
specific users, asking them to explain briefly how the pattern was useful.
The resulting data could start the ball rolling in terms of looking for trends
etc in how patterns are (successfully or otherwise) used.
...just a thought.
Cheers.
Fil
Mattias Arvola wrote:
> Terry, Chuck and all,
>
> Comment on validation of design patterns.
>
> I agree that it is a problem to validate patterns. Most pattern collections (usually more
> collections than languages) tend to be based on rather sloppy research. They are usually
> just documentation of what usually works in different situations. Alexander's patterns (in
> A Pattern Language) often lack a firm grounding in evidence.
>
> To validate a pattern I would start by establishing that the field of forces the pattern
> describes actually exists in the situation it portrays. Triangulation of methods is probably
> useful here. Then I would try to verify that the problem is real: that forces in the pattern
> actually are in conflict if the solution feature isn't present. Finally we come to the tricky
> part: Validating the solution feature of the pattern. We could probably conduct (field)
> experiments to see if it solves the conflicting forces or if (as Alexander would put it) they
> spill over to surrounding patterns, but we seldom do. If we did, it would merit the pattern
> two asterisks in Alexander's format. Instead, i think it is common to base it on
> observations that inductively support the solution (this would merit it one asterisk). Here
> we must remember that a pattern is nothing more than a clearly stated and debatable
> working hypothesis of what we currently know to be the best arrangement for solving to
> a recurring problem.
>
> Given that a pattern is a working hypothesis it probably should be tested as one
> (experimentally). Building well-founded and evidence-based patterns is like building
> theory: a constant flux between inductive and deductive research.
>
> However, we may wish to do inspirational patterns. Not meant to be based on evidence
> of what works, but instead inspire people to find new solutions. Such patterns are not
> evidence based, and talking about validation of them is probably not the right word. Jonas
> L�wgren has written a paper on such inspirational patterns:
>
> L�wgren, J. (2007). Inspirational patterns for embodied interaction. Journal of Knowledge,
> Technology & Policy 20(3):165�177.
>
> Cheers,
> // Mattias
> --
> MATTIAS ARVOLA, Ph.D.
> Sr. lecturer in Interaction Design.
> Link�ping University and S�dert�rn University.
> www.arvola.se
--
Prof. Filippo A. Salustri, Ph.D., P.Eng.
Department of Mechanical and Industrial Engineering
Ryerson University Tel: 416/979-5000 x7749
350 Victoria St. Fax: 416/979-5265
Toronto, ON email: [log in to unmask]
M5B 2K3 Canada http://deseng.ryerson.ca/~fil/
|