Re: Design in the open

[Federico Mena Quintero <federico gnome org>]

On Wed, 2012-04-25 at 14:27 +0100, Allan Day wrote:

> But there are challenges and things we can do better. Among those
> obstacles, I see:
> 
> * lack of design resources - we are always trailing behind where we
> want to be, and there are important tasks which we are unable to
> complete (a new HIG springs to mind)
> * improving the quality of design - we can always do better
> * getting the project behind a common vision - we sometimes lack focus
> * giving people a stake in the project - the danger of design-led
> development is that people feel that the project is no longer theirs.
> They want to feel they can have an impact and that they can express
> themselves through their activities in the community.
> * design disagreements can sour relationships and lead to discord
> * letting people stay in touch with and understand design activities,
> and therefore the activities of the project as a whole
> * helping community members to participate in design activities

Fully agreed on all counts.

As a way to solve these issues, I'd like to follow up on an idea which I
sketched during last year's Desktop Summit - namely, about constructing
a pattern language for Gnome's design based on the good things that what
we have and what other systems have done well.

If you have an hour or two, I heartily recommend that you read this
paper:

http://www.visi.com/~snowfall/LinguaFranca_DIS2000.html

It's by Thomas Erickson, "Lingua Francas for Design:
Sacred Places and Pattern Languages".  The tl;dr version (even shorter
than the abstract) is this:

* He gives an example of how people managed to construct a common
vocabulary of the things that work well in their town (even with people
not being fully aware of them), and use that knowledge to know *what* to
replace and what to leave as-is.  Then, he exposes Pattern Languages in
general, as a form of vocabulary to embody knowledge gained through
experience.  Then he explores a possible pattern language for (social)
interaction design.  In particular, in section 5.2.2 he summarizes a
pattern language for a design consultancy - something from which I think
we could borrow ideas.

His point is that having a pattern language gives you a way to
communicate between people of different backgrounds and interests:
designers, developers, users.  They can all take part in the design and
construction of their (software) environment, all in their best
capacity, and be assured that the result will be good, usable, and that
it will be able to evolve well as needs change.

As for how Gnome's pattern language would help with the issues you
mentioned:

* Lack of design resources.  Learning any kind of design is a big
effort.  By starting with a common vocabulary, which embodies a lot of
concrete experience from past designs, we can get people up to speed.  A
pattern language takes the mystery out of design and lets you talk in
concrete terms.  It *will* take time for a newcomer to learn all the
intricacies of the design, but at least he has a guide and a method of
reasoning about it.

* Improving the quality of the design.  A pattern language gives you a
way to measure things, at least on a qualitative basis.  For example,
"This proposal for workspace thumbnails does well on the EASE OF
NAVIGATION and EXPLORABLE INTERFACE patterns, but it is lacking in the
PRINCIPLE OF LEAST SURPRISE one because..."

* Getting the project behind a common vision.  As Erickson mentions in
his paper, a pattern language often has a definite set of values put in
it.  Gnome strives for certain values - software freedom, ease of use,
functionality, accessibility.  Our patterns can embody these values and
let us evaluate things more clearly rather than only through abstract
wishes.

* Giving people a stake in the project.  Patterns are defined
recursively; a pattern language has rather a fractal structure with big
patterns composed of smaller patterns.  The EXPLORABLE INTERFACE could
embody patterns like UNDO/REDO, INSTANT FEEDBACK, etc.  In turn, those
smaller patterns can be implemented in a number of ways, aided by even
smaller patterns.  If you set the big picture, people can implement the
sub-parts to their liking, but always based on the desired patterns.
This gives them a stake in the project - they can agree on *what* is
needed to make a good design, even if they don't know exactly what the
final parts will look like, and they can own the implementation of their
own little parts.

* Resolving disagreements.  This is about ensuring that one design can
be compared against another one and be evaluated with respect to
desirable patterns.  Or it can be about disassembling both competing
designs into their smaller patterns, and seeing if a combination of them
would be even better.

* Letting people understand design activities.  With a pattern language,
new designs become easy to explain.  "We moved notifications to the
corner because we want the PERIPHERAL AWARENESS pattern in concord with
the FOCUSED WORK pattern".

* Helping community members participate in the design - as described
above in my summary of Erickson's paper.

I daresay that this pattern language would be a great start for a new
HIG.

Finally, a way to evaluate half-implemented designs requires us to be
able to test code easily.  Colin's OSTree sounds like the perfect way to
do this.

Hope this is useful,

  Federico