"Designer-ese" - should we change the way we speak on a Design Pattern?

[Jonathan Hung]

During yesterday's OSDPL meeting a good discussion occurred around the
naming of sections in the OSDPL design pattern - Namely there may be some
confusion over the nomenclature used in the design patterns.

The following examples are hypothetical, but it isn't a stretch to see the
confusion (because it happened to me!).



Example 1: The section "Problem Summary"

Non-designer expectation of a problem summary - This is the description of
the problem. What exactly is the problem we're trying to solve? Why is it so
bad to let the problem persist?

Designer expectation of a problem summary - the description of the *design*
problem. What is the design task?



Example 2: The section "How"

Non-designer expectation of "how" - How do you implement this design
pattern? Examples of CSS, code snippets, HTML fragments that can be copied
and pasted into my work.

Designer expectation of "how" - How should the interaction be structured
from start to finish?


Questions:
1. The OSDPL is different, so how much can / should we deviate from the
accepted design pattern pattern by changing our wording?
2. Is there room for both interpretations in an OSDPL design pattern?
3. How can OSDPL design patterns better accomodate non-designers who is
unfamiliar with the terminology?


- Jonathan.

---
Jonathan Hung / jonathan.hung at utoronto.ca
University of Toronto - ATRC
Tel: (416) 946-3002
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://fluidproject.org/pipermail/fluid-talk/attachments/20080710/a8271130/attachment.html>