unity-design team mailing list archive

[Mark Shuttleworth <mark@xxxxxxxxxx>]

This will be a controversial mail, so I'll ask in advance that we not
let it get heated.

I don't think we can succeed if we work on a list that is free for
everyone to throw their ideas onto. I'm thinking that we need to create
an invitation-only list (which is publicly archived) alongside this one.

Here's why.

I'm interested in the challenge of producing a free software desktop
that's delightful to use, and convinced that good design has to be at
the heart of that. I'm also certain that the design conversation and
collaboration has to be open - at least about the pieces which are
already in public play (in our case, for example, the Messaging
Indicator, Notifications, and the Ubuntu Netbook Remix launcher (unity).

At Canonical, we've started growing a really good team to lead this
work. There are now more than 10 folks at Canonical who's sole focus is
design, art, and user experience, across the full range of Canonical
products (web - Launchpad and Landscape, desktop - GNOME and UNR). To
match that we have a team of developers that is implementing various
bits and pieces that don't already exist, or don't already exist in the
form that they need to in order to deliver the experience we want.

So I'm putting my money where my mouth is, in other words.

Figuring out how to shape the relationship between that company team,
which works on public elements as well as things which are being
designed for netbooks that aren't yet shipping and hence which have to
be confidential, is challenging. The team is stretched, I don't think
they can participate in a large public freeform mailing list discussion
in the same leisurely way that many members of the community can do.
That will create the impression that the Canonical team doesn't care, or
isn't interested in the feedback.

The real challenge is that emails on this list can vary widely in how
"hard they are to respond to". For example, an email on a specific
design issue is easy to fit into a work day. There's a person who is
responsible for taking the final decision on that piece, and they can
participate in that thread and then communicate the decision.

Much harder is a broadbased thread like "high level goals" or "what is
beautiful". I just don't see any way to have the full time team engage
in long threads like that.

My current view is that we need a core team that meets in person fairly
regularly and has a shared set of language and tools. That team needs to
be open to participation from the community, but it also needs to have a
shared set of values, so it frankly would not be open to folks who have
a completely different vision of the future. That core team can
collaborate with the goal of producing final specifications for Ubuntu.
The team should all be at UDS, for example. It should not be a team that
fights with itself - it needs to be made up of people who trust each
other and work well together. And they should not have to defend every
single decision against a flood from folks who are not part of the team.

That means that the design process would contain explicit separation
between folks on that core team, and others who express interest in a
more casual fashion, or who have not yet bought into the core design
ideas and process of the core team.

I'm aware this proposal could result in outrage over barriers to
participation. But I think it will be more effective if we try to build
a core team that knows each other well and can establish norms and
relationships.

Besides, I don't think effective design would come from purely freeform
participation. At the moment, I have final signoff of specifications
coming from the design team into Ubuntu. In due course, that
responsibility will be assumed by someone in the Canonical design team.
There is collaboration and consensus in many elements of the work, but
to the extent that decisions are taken in that final signoff they are
final and binding. And that will remain true even when someone else
takes over from me.

Thoughts?
Mark

Attachment: signature.asc
Description: OpenPGP digital signature