 |
« | Week of Dec 7 | < | Individual Entries | > | Week of Dec 21 | » |  |
 |
 |
A Usable Open Source Software Community
design, society & sociology, software development, usability
December 18, 2003, 10:42 PM
I've written a lot before on the subject of bringing usability to open source software. I've been silent on the topic recently, but not idle; I've been working diligently all semester long with my friend Dana Gelman for our CSCW course on a project to design an open source community that has the tools, techniques, and participants to develop products that can effectively target end-users.
Our core recommendation is that existing open source communities that develop applications targeting end-users (for our purposes, "end-users" will be shorthand for "users that are not like the developers") should invite usability professionals and interaction designers to participate in the development efforts. This is harder than it sounds, however, since existing, developer-centric communities will have to change the way they work to make room for these new people with new skills. To begin to paint a picture of what this new, integrated community might look like, we have developed eight specific recommendations for any OSS community that targets end-users.
- Involve usables in the core development team. Our literature search has shown that most OSS projects have a small team of one or more developers that do the bulk of the work. On large projects, this team is responsible for decisions relating to the high-level architecture and organization of the code. We propose bringing interface designers into this team to take responsibility for the user experience, including defining and maintaining the core metaphors, ensuring interface consistency, and other high-level duties. These participants will also need to interact closely with the core developers to determine implementation tradeoffs, which is why they're part of the same core team.
- Incorporate personas. I've already argued extensively for this recommendation, so I won't say much more of it here, except to note that to be effective, the personas must be used and valued (in particular, they should be frequently referenced by name) in design conversations throughout the community.
- Build small, heterogeneous teams of developers and usability people. Small teams are more productive, and can focus on the details of an interface design with a minimum of overhead.
- Modify the joiner script to require newcomers to justify design decisions with the personas. Open source communities have an implicit cultural barrier to entry called the "joiner script" that sets a standard that new members must live up to in order to become contributors to the project (think of it as a very long interview process). We recommend not admitting contributors (both developers and usability people) who are unwilling to justify design changes and feature requests in terms of the personas' needs.
- Use synchronous communication (chat) for design meetings. Synchronous communication is more efficient at building shared understanding, which is essential for making effective design decisions.
- Transmit design decisions back to the public list. The previous recommendation introduces a problem, however. People who are outside the immediate circle of the design team (contributors working on other parts of the project, contributor hopefuls, users, etc) also need to be kept in the loop about the design decisions that are made and the rational for them. For this reason, someone needs to be willing to summarize the synchronous design conversation and post it to the asynchronous communication medium in use by the project (e.g., a mailing list or discussion board) so these other followers can get access to it.
- Provide a shared visual information space. We recommend using a shared, visual information space (like a shared whiteboard application) in parallel with synchronous chat for design meetings. Design is a very visual process, so having the easily accessible graphical space to work on rather than trying to describe all interface changes linguistically is necessary.
- Modify bug tracking tools to better support collecting usability issues. Bug tracking tools are often used to record change requests as well as bugs in open source projects. On large projects, however, we found that they often break down as large numbers of UI problems pile in and contributors must spend time sorting through them. We propose developing more efficient bug tracking tools that are capable of handling UI issues as well as code bugs. We have not yet defined the form such a system must take, since this is really another semester project in and of itself.
Dana and I have put together a final report that contains more comprehensive descriptions and extensive arguments for these changes, ties our assertions back to the literature, and describes an experiment we are proposing to test one aspect of our solution (how personas change the design conversation in an integrated open source and usability community). I haven't made this paper publicly available (yet) since we're hoping to publish portions of it at CHI or CSCW and I don't want to run afoul of prior publication rules. But if you're really interested, drop me an email and I might send you a copy.
Divide and Conquer
processes & methodologies, writing & communication
December 16, 2003, 04:25 PM
Now, I'm thinking about team projects and efficient ways for several people to work on the same project.
In The Mythical Man Month, Fred Brooks confronts the problem of how to effectively divide up the work of large, complex software development efforts. He concludes that the project management notion that bringing more people on to the project will linearly increase the amount of work produced is a fiction, in fact new people will actually decrease the work output temporarily as they demand the current staff's time during ramp-up. Thus, the concept of a "man-month", which assumes men and months are interchangeable, is a fiction (hence the name of the essay). Even after ramp-up, adding more people to a project exponentially increases the communication overhead, since everyone must now potentially communicate with one more person to do their job.
The key issue here is that communication cost. When working in a group, you have to consider whether its possible to split up the work in such a way that the communication costs will be low. If everyone can work in parallel without talking, then you can just divide up the work into N pieces and if it isn't going fast enough, bring in more people to make N larger. Brooks' example of a task like this is ditch digging; if your ditch deadline is bumped forward, just hire more people, give them shovels, and dig in.
Unfortunately, most kinds of thought-work, which everyone in design, usability, research, and software development tends to be engaged in, isn't very much like ditch digging in this regard. Most of our projects are communication-intensive, and can't easily be split up in such a way as to make them parallelizable. Code has to work with other code, interface designs are too holistic to develop entirely separately, research must tell a coherent story, etc. What to do?
If possible, the best answer is "do it yourself". Many novice teams make the mistake of splitting up jobs that could be done way more efficiently by any one of them alone. Don't feel like you have to give everyone an equal amount of work at the expense of making everyone work harder than they'd otherwise have to.
If the task is too big for one person to accomplish, then your best bet is radical colocation. In Agile Software Development, Alister Cockburn recommends this technique for small teams that must engage in frequent communication, and he gives an extensive argument on why even moving people down the hall from one another can drastically limit communication opportunities. This generally leads to miscommunications, which leads to buggy software, unusable interface designs, misrepresented experiment results, etc.
So in summary: if possible, don't even try to split up thought-work; have it come from one mind. If that's not feasible, try to divide it up to minimize the amount of communication the workers will have to engage in to do their jobs. If the job is such that you can't reduce this to an acceptable level (which is more often the case than not, so don't be lulled into underestimating the amount of communication necessary), then radically collocate.
The nice thing about this advice is that it applies at all levels: from units as large as corporations outsourcing large initiatives to one another and as small as two people in a small student team.
Email Rob:
On Ideas and a Community of Ideas
design, society & sociology
December 16, 2003, 10:49 AM
I've been busy with the end of the semester recently, which is why I haven't been posting much. This, of course, means I've generated a huge backlog of things to say. Now that classes are behind me, I'm going to try to get some of them out in the open, so if the next few days seem rather verbosely scattered, that's why.
Let's start relatively concrete. I was talking to Matt a few days back about ideas and the ways we come up with them, and the relative value of coming up with ideas versus putting in the time and energy to actually execute them. We agreed that most of the real work and the real value is in the execution of ideas; if one person comes up with an idea but another puts in the required work to see it brought to fruition, then the second person is the one with the stronger claim (a fact that is recognized by copyright law). But ideas are funny things; sometimes good ones will hit you out of the blue with amazing ease, but frequently if you try to sit down and deliberately come up with one it won't be there when you need it. Ideation is easy to do but really hard to focus and control, and a good idea that comes at the wrong time or in the wrong place is next to useless.
My theory on coming up with ideas is that getting the right idea is a matter of having the right kind of brain with the right kind of information in it, which enables you to make the appropriate neural connection to get the idea you want (I further believe that ideas don't come out of nowhere; they are composite thoughts that arise from mushing together apparently disconnected facts, values, and beliefs). The long and the short of this is that having the "right" idea is a matter of having the right person with the right knowledge at the right time.
We designers can up our chances of being that person through extensive domain research and brainstorming techniques, but we cannot ever step into another person's head, and sometimes that's what's needed to get at the right idea. But if we can't do it, who can?
The user community, of course. But often user ideas are never heard by designers, since there are no effective feedback channels from the end-users to those who develop their products. What we need is a forum for collecting such ideas and encouraging the best ones to rise to the surface. For this purpose, I propose an online community built to leverage this broad swath of brains who could possibly make these connections.
There are many barriers, however. How would the community designer encourage contribution of ideas? And once users are contributing, how would the community evaluate the ideas to know which are suitable for recommendation to the designers (who should, of course, exercise their own judgment in deciding how and whether to apply them)? It seems a fertile ground for exploration. The only community I know of that's attempted it was the Dilbert Lazy Inventor site (which is off the web now I think), and that struck me as more of a toy than a serious site.
Although I haven't emphasized it before, this idea strikes me as very much in line with my thoughts on increasing end-user participation in open source software development. It's nice to find those rare occasions when all your interests converge.
Email Rob:
Email Rob: