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 _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list