[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Ayatana] Collaborative design dilemma




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