I’ve submitted this idea to the Ubuntu Community Council. (Hopefully I’ll be able to write back soon and tell you they love it, but we’ll see.)
Brief:
Mark S. wants to make Ubuntu more appealing to users. I feel Ubuntu would better achieve this by instituting a new set of Teams which would run alongside the existing group of Teams. We already have Teams whose primary focus is on implementing (in many cases, this means coding) direct changes to the system. What is missing is a set of Teams to identify and address the experiences that Ubuntu is delivering to users, purely from a user-experience perspective. We need to shift the focus away from “How we build the system” and shift it towards “What experiences are users having of the existing system, and how can we improve upon that?” It’s all about delivering experiences.
Detail:
In their landmark book, “Design Patterns”, the Gang of Four espouse the virtues of designing for the interface, not the implementation. Right now, Ubuntu is designing for the implementation, not the interface (which for our purposes, is the end-user experience.)
Ubuntu Teams are currently built around how they are implementing various parts of the system. I call these ‘coding teams’. We have coding teams for implementing the various Ubuntu derivatives like Kubuntu and Edubuntu, teams for implementing server support or laptop support, teams for implementing artwork, teams for implementing assistive technologies, teams for implementing documentation, and so forth. It’s an implementation-focused approach. It’s all about *how we build*. Now, there’s nothing wrong with being interested in how we build, and really there is nothing wrong with keeping the existing ecosystem of coding teams. I, however, feel we can do better, and should do better. I feel we need to extend our consideration beyond simply *how we build*, to encompass *how we impact the user*. We are not just delivering software, we are delivering an experience. To that point, I feel it would be good to create a parallel set of teams, whose primary goal would to a) identify and b) evaluate the experiences that Ubuntu is delivering for certain types of users. I refer to these new teams as ‘Experience Teams’.
Take for example, the first-time user. We could have a ‘Welcome Experience’ Team (WET). It could consist of people from a variety of coding teams. The WET would meet to discuss the various experiences Ubuntu delivers to its new users. They are not interested in anything but cataloging a) what new users might be interested in, and b) what impressions they might be having of how things currently are:
* how do people first learn about the existence of Ubuntu and Linux in general?
* how do first-timers go about downloading and test-driving Ubuntu?
* what are the various support, hardware and other issues that may be of concern to them when they are doing this ‘test drive’?
* what might their first-time installation issues be?
* how do new users feel about navigating and maintaining their systems, once the install is complete?
Basically, Experience Teams are trying to “look through the eyes” of an imaginary Ubuntu user who has certain limitations, interests and concerns. It doesn’t matter which coding teams the members of WET are part of (if indeed they are a part of any), only that they are good at relating to this imaginary Ubuntu user – in the case of WET, the first-time user.
Experience teams, like the WET, are not concerned with coding. They are not implementation-minded. They are, instead, interested in cataloging the a) Interests and b) Impressions that users might be having for their particular Experience Domain. For example, the WET might identify the following for first-time users:
a) Interest: I’d like to see if Ubuntu is for me, maybe take it for a ‘test drive’, but how exactly do I do that?
b) Impression: Overwhelmed and confused by the Ubuntu.com website. Not immediately knowing how to obtain that information.
The WET could deliberate if this was an issue that should be considered for implementation. (“Is it really an issue that new users might want to give Ubuntu a try, but are unsure what steps that would take, and how they would go about it?”) They could discuss the issue amongst themselves, or instead they could put it up to a vote on Brainstorm, or at the next UDS. In any case, there needs to be some way of deciding which ideas are to be ‘greenlighted’ for implementation. If an idea was greenlighted, the WET would need to discuss which coding teams need to be contacted in order to start the appropriate work order. The WET would check on the status of WET-related work orders. When work orders were completed, they would evaluate the effectiveness of implementations produced by the coding teams, to see if they succeed at satisfying the Interests and Impressions which they had previously identified.
We could have Experience Teams for various Use Cases, such as:
* a ‘New Software Experience Team’, representing users who are adding, configuring and updating software. (Who might ask, “What might a person wanting to install new software be interested in?” and “What might their current impressions be of how Ubuntu delivers on that now?”)
* a ‘New Hardware Experience Team’, representing users who are adding new hardware. (Who might ask, “What might a person wanting to install new hardware – including assessing hardware compatibility before purchasing said hardware – be interested in?” and “What might their current impressions be of how Ubuntu delivers on that now?”)
* a ‘Media Playback Experience Team’, representing users who are concerned with multimedia, pluggins and codecs. (Who might ask, “What might a person wanting to listen to music, watch videos or slideshows, view and organize photos, or play games be interested in?” and “What might their current impressions be of how Ubuntu delivers on that now?”)
* a ‘Contacts Experience Team’, representing users who are concerned with online communications such as email, Twitter, IRC, IM, etc. (Who might ask, “What might a person wanting to initiate or renew electronic correspondence be interested in?” and “What might their current impressions be of how Ubuntu delivers on that now?”)
* a ‘Community Help And Participation Experience Team’, representing users who are addressing issues, inconsistencies, bugs, reporting and community support. (Who might ask, “What might a person wanting to get help with <fill in the blank> be interested in?” and “What might their current impressions be of how Ubuntu delivers on that now?”)
* a ‘Look and Feel Experience Team’, representing users who are concerned with visual appeal, notifications, visual affects (including optional compositing), locating, creating and submitting community artwork, etc. (Who might ask, “What might a person wanting to tweak and customize their system be interested in?” and “What might their current impressions be of how Ubuntu delivers on that now?”)
* a ‘Fiasco Avoidance and Recovery Experience Team’, for identifying, avoiding and recovering from fiascos (like PulseAudio on Hardy, or Intel Video driver on Jaunty) thereby helping keep the Ubuntu-rage on the forums down to a minimum, and keep the Ubuntu name and reputation in high regard. (Who might ask, “What might a person wanting to find how other people have addressed a particular problem be interested in?” and “What might their current impressions be of how Ubuntu delivers on that now?”)
Experience Teams would frequently ask questions like:
“How did the user know where to look?”
“How did the user know what that was called?”
“How could that be made more evident, more obvious, more straightforward?”
People could rotate through Experience Teams, maybe once per development cycle. (In a year, each Team might lose and gain 2 new members who came from other Teams.) In that way, there would always be fresh perspectives, new questions, new approaches, ideas would pollinate. As well, Experience Teams could share the questions, techniques and approaches that have been effectively used by other Teams.
Perhaps there is a step between when a Team ‘greenlights’ an idea for implementation, and the delivery of the work order to the Coding Team. Perhaps the greenlighted idea first needs to be given to the Look and Feel Team, or some other Team which ensures that whatever gets implemented is done in such a way as to present a *consistent* experience to the user.
In closing, there is certainly nothing wrong with the current system of Ubuntu Development Teams. I am merely suggesting they could be made to work more effectively, and to produce a higher quality product (and end-user experience). There is nothing wrong with being concerned with implementation, but that should not come at the expense of considering what experiences are being delivered to the user population by those implementation choices.
Ubuntu WTF! 