DCamp Eventspace : Open Source and Usability Session

Open Source and Usability -- session notes

See also Saturday session: Open Source Usability and Designing for Open Source

Facilitated by Eugene Kim (EK). Notes by Bryan Stearns and Ken Guzik (sorry if we missed or misattributed anything, or missed your name if you came in late - this a wiki, so please fix it!).

Eugene started with a round of introductions: Say who you are, whether you self-identify as a Usability Practitioner, and what you hope to get out of this...

Usability Practitioners:
Mimi Yin - Working on Chandler at OSAF
Ken Guzik - not working on open source, but interested in hearing about it
N(sorry, didn't hear your name & couldn't see your nametag clearly - you're "N_" below) - what usability designs drive social networks?
Dawn Nidy - formerly with Open Source Portfolio
Nancy Ackerman - not currently in open source, but interested
Rashmi Sinha - not open source currently
Jenny Gove - not open source now, but in the past (Netbeam)
Rick Boardman, Google - wants to find out how he & google can help;

Those who didn't so self-identify:
Bill Ward - Lots of incomplete projects :)
Debbie Willrett here to find out more about open source
Karen Schaeffer - does low-level infrastructure; "browsing here"
Sarah Allen - working on Open Laszlo; interested in how to bring in open source collaborators into a design
Adina Levin - Socialtext; wants to hear success (or scary!) stories about open source design
Bryan Stearns - developer working on Chandler at OSAF; here to hear more about design in open source
Lloyd Budd - working on Firefox and Ubuntu as a QA/community lead; it's hard to get designers & engrs to talk to each other!
Julia Budd - Teacher/silversmith; here to listen
Ted Leung - Working at OSAF on Chandler community development; interested in how to get open-source people to do non-spaghetti design
Jeffrey Harris - Chandler developer; does what Mimi says :)
Katie Parlante Chandler manager; how to have an open design process (as well as dev't)
Mike Van Riper - works with lot of open source projects; curious about design from developer perspective
Shawn Kaneko - not currently in open source, but interested;
Simon Hui - not currently in open source; works on search-engine site; here to learn
Lyssa - Socialtext; what do people (specifically end users) want or expect intuitively?
Eugene Kim - interested in collaboration on a societal scale; how to improve tools?
Tony - recently started working on Firefox; developer.

Eugene: Worked on FLOSS usability sprints ("get dev's and UPs in the same room and see what happens". What stories do people have about open-source usability? One problem: there are only a few here who self-identify as usability practitioners. First question: why aren't more usability practitioners here?

Debbie: There was a discussion earlier about customization for the particular user (for instance, the way the Amazon site changes its behavior based on your previous usage patterns); why isn't there more of this? A friend who knows Microsoft stuff says new
Word suite will have an inference engine that'll work based on usage patterns automatically.

Ted: How many people have designers working on your open source project, and how many? We (OSAF) have 2 full-time people plus folks on mailing lists; we'd like more...

Ken: Is open source usability different from non-open-source projects; is the process different?

Rashmi: Cognitively it's not different, but the process makes it different. Corporations know this, but the open source process hasn't recognized this.

Ted: Hacker lit says "software by hackers for hackers" - this isn't conducive to usability.

Karen: Most large open source projects are funded by corporations.

Mike: Changes happen because of committer interest. It's hard enough to get developers to see the problem; it's a communication issue. Open source's decentralized development process hurts this.

Adina: Well known hacker stereotypes (scratching your own itch) lead to this, but there are also a few success stories: Firefox, Gaim. How do they do it?

Lloyd: Firefox's design was basically done by two full-time people. Are there good tools for distributed design?
Adina: so it's a tools thing...

Tony: Bugzilla use by Firefox has safeguards for UI review: UI changes have to be reviewed just like code changes. Putting it in public on Bugzilla & mailing lists involves the community.

Mimi: It's a structural problem: software is modular so that different developers can work independently on different modules, but user workflows cross modules; the open-source distributed development style causes this. In a company you can solve it by fiat...

Brian: Projects with the best usability are sponsored by companies. Other small projects never seem to have good usability. Ego is a problem, too -- less so in the corporate world.

Tony: Ego can lead to forking...

Katie: It's harder if you're a lone designer. Designer needs a coder to make stuff happen.

Rashmi: Open source is fundamentally different than the corporate world where there are specified roles. Designers don't have the currency in open source projects.

Lloyd: We build on Firefox because of the consistent UI, but even within our own project, it's tough to keep designers from being scared away by developers.

N_: Many successful open source projects don't have a front-end: a command-line interface is good enough. The open source community lacks people who do design & feedback.

Adina: In a corporation, it's not about the organization, it's about customers & sales. If you're providing software to non-geeks, you have to make it good or customers won't buy it. Customers are different than me.
Karen: Successful ones do.

Sarah: Do we need a parallel structure so that designers can effectively authorize other designers to be commiters? We need to empower designers.

Ted: It's part organizational structure; we need to attract people on both sides. We need to grow a design community that the development community wants to work with, and designers who want to work in the process. We need trust between the communities.

Nancy: Developers want stuff to be used; you can sell usability in that way. There are several passive ways to promote usability: 1. have an explanation of what usability is. 2. Have peer resources available to help. 3. Make it easier to put up user-study session videos - this'll do a lot.

Mimi: At previous FLOSS sprints, we talked aobut open source projects started by designers. Analogy: you can have a pharmaceutical company driven by researchers (the company finds a way to market discovered drugs), or you can drive it by doctors finding real-world problems (the company then works to solve those problems). Here's a controversial idea: Firefox actually is not that great because the interface doesn't support what people are trying to accomplish (research for travel or work; which college should I attend, etc.); the browser doesn't solve that problem, so we cobble together tools (email, bookmark managers, etc). If designers would first identify workflows, we'd get different tools.

Ken: Design & developer leads are peers where I come from. Development leads happen, but design leads don't: how can we develop design leads?

Mike: open source projects are often started by a couple of people, who then authorize more commiters who share the development or architectural vision. We need a "seed" designer, or a designer/developer pair to start projects off with this kind of shared respect. Other projects have been successful with a single leader whose vision includes both (eg, Pagemill). Either way, someone has to enable others.

Eugene: http://openusability.org is a matchmaking service.

Karen: If the project has a good feedback loop, designers won't be ignored. Developers want people to use the products, but won't seek out designers.

Katie: Firefox is actually a counter-example: Mozilla had feedback structures, etc,, but a small team took control, pissed people off, and made decisions: two people went off and did it.

Dawn: I'm waiting for a milestone where we have a highly-usable project with a high adoption rate that solves a new problem; this hasn't happened yet. (Firefox doesn't solve a new problem - they didn't set a bar higher than "better than IE"). We need to solve different problems.

Arun: Project leads rarely understand usability. Can we extol designers' virtues? How can we be more prominent?

Ken: There's a lack of common language. We need models of good usability. User study videos are awesome, but you have to get engineers to watch them and understand what they mean.

Sarah: The culture of developers is important. At Laszlo, we never say "no" to designers. "What's the problem with this architecture that we can't solve this user problem?"

Lloyd: Engineering is measured on completeness, but we can't easily see how usability is measured. Also, the most vocal people aren't necessarily the best.

Jenny: Usability requires resources to be respected: labs, etc. Sun now has a usability lab in the Czech Republic, a collaboration with the University of the Czech Republic. How can you do that when it's not a corporation, and be respected & listened to?
Karen: If it helps, developers won't object. Developers sometimes can't facilitate usability in architecture.

Dawn: Textbook usability methods don't work; we need to be more flexible as usability practitioners and find new methods to work with open source developers... getting into projects the way they already work. Lab studies are time-consuming. Agile development conflicts with this.

Mike: I want to find projects with equal designer & developer weight.
Eugene: propose it as a session!
Mike: If you show 'em how to do it right, they will...

Adina: People vary in empathy, and may not have the ability to conceptualize something different. Seek out developers with this empathy & user understanding.

Eugene: Wrapping up: There'll be a session tomorrow on usability sprints, one potential systematic way. Also, there'll be another FLOSS sprint this summer.

Notes by kguzik

These bullet points roughly follow the transcription above, but I only recorded the salient pieces as I heard them and can't precisely attribute them to individuals. That can be an exercise for the reader :-).

How is open source usability different from classical usability:

The social aspects of introducing usability have different challenges in an open source, collaborative environment.
Developers care about usability, so the challenge is getting them to see the problem so they can embrace it.
Open source culture is like scratching and itch. “This bothers me”
Not all hackers have usability expertise so the introduction of features may happen without a usability process.
Are there good tools for distributed design? That’s a big challenge.
Firefox has two full time designers which are the primary source of new features/usability with the application.
Discussions are across forums using ASCII art, and ensuing discussion surrounding the designs. The collaborative nature adds a lot of value.
Designers need to work in a collerbative way to ensure usability. There are very few (no?) tools to do collerbative design.
Ego is a real problem, In the commercial world there are forces working to balance the egos. In the open source world it’s more difficult.
OS developers can always fork a different development branch to explore their own avenues, but this is not a free process. Others must be involved to make it happen.
The language for discussing usability issues is missing. The only language is for coding, not for UE or usability so communication is very very difficult.
Developers often scare away designers who don’t understand the language to communicate their ideas.
Customer focus has a strong influence on the process of developing software that is usable. In the OS world the real end users are not always easily seen.
Need a lead designer to guide the process just as a lead developer is needed to guide the architecture. In the commercial world these roles are well define, but not in an OS world.
Developers want their projects to be used. Usability can be sold in that way.
3 passive ways to sell usability:

Exploration of what is usability
Here are resources that can be used by engineers interested in usability.
Put up videos of user study sessions for other engineers to watch.

Open source projects can/should be started by designers.
The user requirements need to be defined fully up front, and developers are often not the best people to do this. OS projects tend to be smaller or less focused than they should be for this reason. A designer/marketing lead up front will produce a better product definition to follow.
OS projects are often started by tech leads, who maintain that position throughout the project as other people join in. If the project is also started by a design lead, then the same thing may/will develop on the design side as other people follow on.
OpenUsability.org – Matchmaking service for designers.
The turning point will come when there is a highly usable, widely adopted product with excellent usability and defines a brand new space.
Defining a common language for engineers and designers is difficult. If the engineers are presented with numerous, conflicting critiques it doesn’t help to communicate the usability issues.
At Laszlo, the watchword is “Never say no to the designers”. If you do say no, then you have to present and prove your point.
Engineering is measured by completeness, but the metrics of measuring usability are not well defined. Its hard to communicate design problems without such metrics by which to gauge success/failure.
Text book usability processes don’t work in the OS world. E.g. user studies are laborious and hard to get together in ways that are useful and economical. New methodologies are needed that will work with the structure of the OS development teams.
Need an incubator project for developing usability processes to show other OS projects how it can be done. This is currently lacking. It would be interesting to dedicate an effort to this.