Tony Byrne asked that we research possible formats for CM Pros design
patterns. He submitted a suggestion and James Robertson sent in an
example.
There is a great deal of design pattern work in the object-oriented software field and in user interface and interaction design. Can their formats - and especially their terminology - be adapted for use in CM Pros patterns?
I looked in several print and web references on Design Patterns. They have excellent descriptions of each type of element in their pattern and numerous examples. Here I provide only the names for their pattern elements. I think we would benefit from using industry-standard terminology where it makes sense.
A Pattern Language, Christopher Alexander.
Design Patterns,
Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides (The Gang of Four).
Design Patterns Explained, Alan Shalloway and James Trott.
Reengineering Patterns, Steve Demeyer.
Common
Ground, Jenifer Tidwell.
Web Design Patterns, Martijn
Welie.
More references in the CMS Glossary
entry.
| Alexander | Gang of Four | Shalloway | Demeyer | Tidwell | Welie | Byrne | Robertson |
|---|---|---|---|---|---|---|---|
| Name of Pattern | Name of Pattern | Name of Pattern | Name (Action Phrase) | Name | Name | Title | |
| Context, Larger Patterns | Context | ||||||
| Intent | Intent | Intent | |||||
| Problem | Applicability | Problem | Problem | Problem/ Forces | Problem | Characteristics | |
| Solution | Structure | Solution | Solution | Solution | Solution | ||
| Participants/ Collaborators | Participants/ Collaborators | ||||||
| Consequences | Consequences | Trade-offs | Resulting Context | Benefits/ Drawbacks | Advantages/ Disadvantages | ||
| Known Uses | Known Uses | Known Uses | Notes | Known Uses | Published Advocates | ||
| Motivation | Rationale | Why | Suitability | ||||
| Smaller Patterns | Related Patterns | References | Related Patterns | Related Patterns |
Jane McConnell added Success Factors (requirements) and Strategic Positioning.
Thanks
Bob, that’s some great work, very succinct!
I agree
with you on the thought of using industry standard terminology, and I like some
of the industry standard terms – I particularly like the idea of stating the
problem you’re trying to solve clearly before you state the
solution.
I think
I’ve mentioned it before, but I really like this
site:
http://www.theserverside.com/patterns/index.tss?forum_id=6
It’s very
simple, just space for people to post their thoughts, and for other people to
comment on them. They don’t have any required fields as far as I can see. We
could pretty easily do a version like this, but it might be nice to force people
to enter their patterns in a fielded form. Do a bit of content modelling; eat our own dogfood and
all that ;-)
To that
end, my suggestions for fields would be:
Name of
Pattern
Context /
Strategic Positioning (not fussed about the name) – could this map back to a
stage of the “CMS Lifecycle”?
Intent
(?? sounds interesting but I’m not sure what it means
here?)
Problem –
what is it you’re trying to solve? Why is it a
problem?
Solution
-
Success
Factors / Success Criteria / something like this – ie
“how do I know when it has succeeded?”
Participants
/ Collaborators (of course this would be more useful if we had standard names
for all actors and systems in a CMS project...)
Known
Uses (maybe even “known users”? ie “Bloggs Corporation has been doing it this way for years, and
they’re very happy with it”)
Related
Patterns (within the CMPros patterns database and
external patterns)
I
definitely think we need a facility for encouraging discussion on a pattern.
There will always be dissenting views, people who want to provide real-world
examples, and suggestions for new techniques to include in a best practice
pattern. It might even be worth allowing people to comment on a particular
version of a pattern, so users can browse back through previous versions and see
the comments on those versions, which may not be relevant any more. This is a
subtle point, suggestions welcome on this one!
I’ll have
a think about this stuff and hopefully mock something up to help
out.