The last few months have been an exciting time for open source usability. Here is a first hand story of what has been happening, some photographs and reflections.
This article is divided into three parts.
Part 1: Some recent developments
Part 2: The issues around open source usability
Part 3: Why you should care, and how to get involved
PART 1: SOME RECENT DEVELOPMENTS
I first became interested in the usability of open source software (or the lack of it) while still at UC Berkeley around 2000. I did some work (actually my students did the work!). In the process, I also, met others interested in the topic such as Nancy Frishberg. But I was soon convinced that it was a wasted effort – open source developers did not really understand what usability had to offer, and it was difficult for a UX (User Experience) professional to have much impact.
Eugene at BayCHIForward to November 2004. Eugene Eric Kim of Blue Oxen, a company (named in honor of Doug Engelbart) got in touch with me about a “Floss usability sprint” he was organizing. No, not Floss as what dentists nag you about, but Floss as in Free, Open Source, Libre software. I was skeptical, but interested.
Eugene sees the problem of open source usability as a problem of collaboration. The open source and usability communities have a lot to offer each other, but don’t know how to work together. Did I tell you that Eugene’s company specializes in promoting collaboration? Personally, I think that its not just a problem of collaboration, there are some structural reasons why open source and usability don’t go together. But collaboration is definitely the beginning to a solution.
The sprint happened in February 2005. There is a wiki where you can learn more. Or see some of the pictures. But most of all there is a community - an assortment of people interested in the topic. Some are from open source projects, some are usability practitioners, some just care about the issue.
Doug Engelbart with Peter Trudell at BayCHI
It was a short but intense period of time. Everyone who was there learnt a lot. I had some of my hypothesis about open source usability confirmed, others turned out to be completely inaccurate.
Post-sprint, Eugene gave a talk about the sprint, followed by a panel with some of the sprint participants at BayCHI.
PART 2: ISSUES AROUND OPEN SOURCE USABILITY
These are the nascent days for open source usability and it is worth reflecting on what the problem is, why open source software is so hard to use, why designers and usability practitioners don’t work on such projects and how all this can change. Here are some of my own thoughts (based on discussions at the sprint and FlossUsability mailing list).
Katie & Rashmi on the BayCHI panel
a) The problem of currency: In any system people exchange goods and services using some type of currency. The currency could be any arbitrary thing – it could be fish, cows, or massages. In the open source world, it happens to be code. The problem is that usability professionals generally do not write code.
I know several UX professionals who volunteered for open source projects. They had great suggestions, but unless they found someone who could code them up, their suggestions had little or no value.
Usability testing for Chandlerb) Which leads to the second problem, that I have termed the obstacles to simplification. While this problem is not unique to open source software, it is exacerbated for such projects. Open source software projects are often feature driven. People join a project, they want to contribute. How can they contribute – by adding a feature. The user experience becomes more and more complex over time, as more and more features get added. With corporate projects, it has often been noted how the structure of the website, or system might reflect the internal structuring of the company. Given the distributed, autonomous nature of open source projects, this structuring is much more complex and not at all user-centric. It becomes even more difficult to rein in the complexity.
Identity Commons team hard at workc) The heady success of firefox: Many years ago, open source developers mostly used to build tools for other developers. That is not the case now. And with the success of Firefox, the open source movement has tasted blood. They know the impact good design and some grassroots marketing can have. Many of them see a huge opportunity for growth if they can figure this “user” and “usability” stuff out. I sensed this again and again in my conversation with open source developers. They see the importance of usability in a way they did not four years ago when I first became interested in this.
d) Thirst for methods and resentment towards drive-by usability: The other observation was that everyone from open source projects really wanted to learn how to do this themselves. Also some of them felt that they did not know where to go looking for usability methods information. This surprised me – my own perception is that UX community is actually pretty open about sharing methods etc. b)
A number of projects did card-sorts
Also, I noticed some resentment towards what was termed “drive by usability” – an expert who does not understand their project or goals and gives them a bunch of usability suggestions after a quick review.
e) Need for remote, distributed methods: This is extremely important. By its very nature, open source development is distributed. Lots of people working in various locales connected by various technologies – IM, email and IRC. (Post sprint, I have become hooked to IRC myself!) Conventional usability often works in a very hands-on manner. In person interviews, or usability sessions. Remote methods have only recently started to gain traction. While design still might need one or two people in charge, user research/usability feedback for open source projects will have to be remote and distributed. Jakob Nielsen’s guidelines for 5 users, which really translates to a biased sample of five from Silicon Valley or wherever the company is headquartered, is not going to work in open source. User input has to be broader and less localized, otherwise it will not gain community acceptance. While there is place for hands-on methods during sprints, or conferences, the majority of user understanding will be acquired remotely. I suspect that “Usability by IRC” is what they really want :-)
Mary Hoder, Victory Grey & Nancy Frishberg
f) Many open source projects need information architecture help: This was a major realization during the sprint. A number of projects were struggling with how to organize information on their project website, or for the software itself. Navigation and menu organization were problem areas that needed immediate addressing. At least three of the projects OpenACS, CivicSpace and Chandler chose to do card-sorting exercises to understand how users thought of the information space. It was also interesting how several developers who had never heard of card-sorting before immediately warmed to it.
There are many more observations and reflections. But these are some of the ones that have stayed with me.
PART 3: WHY YOU SHOULD CARE, AND HOW TO GET INVOLVED:
One reason why you – a User Experience professional – should care is because there is a real chance to have impact. Recently (post-sprint) Civic Space Labs (one of the sprint project participants) redesigned their website. This is what the redesigned website looks like. Contrast this to the websites for other open source projects.
Now that does not look like an open source project site, does it?This is what Kieran Lal from CivicSpace said about the redesign on the FlossUsability mailing list:
“We need to make sure our site is task and benefit oriented, not feature oriented. We have attempted to customize our menu’s and blocks so they are context sensitive through the top levels of navigation of our site. Previously we offered 8 horizontal navigation options and up to 37 vertical navigation options including sub-menus on every page… Now we offer 3 main options on every page, and customize the top level pages to be context sensitive.”
And this is what Chris Messina, also from CivicSpace, had to say:
“…we took Drupal, on which CivicSpace is built, and got rid of everything. Truly for three days last week I became a minimalist interface “painter”. Basically anything that I couldn’t justify or didn’t add value to the immediate workflow at hand got trashed, which, when starting out, was everything.
Slowly and not even terribly methodically I went over each link, block and chunk of content to determine whether it deserved to be added to my *pristine* design. What survived basically comprises the current beta of civicspacelabs.org.
Our content still needs to be overhauled, but I think our site is infinitely more browsable, usable and _enjoyable_ because there’s less of it to be overwhelmed by.”
Both Chris and Kieran already care a great deal about the user experience. And like any other open Source project, this redesign probably had the input of many people. But I like to think that the sprint did influence that redesign to some degree.
Chris Messina, Kieran Lal & Steve Williams at BayCHI
Recently, I was at the Information Architecture Summit in Montreal. I asked around and was lucky enough to find two Information Architects who are now volunteering for CivicSpace. So, keep an eye out on CivicSpace. They have the passion, the dedication, now they now have some UX volunteers!
CivicSpace is not the only project that is trying to reach out to UX people. Even more interesting is an effort by OpenACS to launch an “OpenWebGUI” effort. Essentially the realization is that a number of open source projects have some common functionality, such as an administrative interface or login mechanisms. There is an opportunity to develop some common designs or interaction patterns that can be used across projects. Joel Aufrecht from OpenACS is leading this effort. Go to
to learn more. This project needs volunteers! If you are interested, then email me or contact Joel directly.
Other reasons why you should care. Have you ever encountered some open source system that seemed great, but you could not even install it? Have you ever wandered to one of multitude of Open Source CMS’s and wished they knew how to get the menu labels right? Or wanted to change the hideous visual design? I know of several UX practitioners who did volunteer. Many of them that they were not able have impact. Now we have several projects that are ready and waiting for design and usability feedback.
All the sprint participants
Other advantages in working with open source projects. Projects like the OpenACS webgui effort have the potential to have a broad impact, to define standards across projects. Secondly, open-source projects would make great case studies in your portfolio – there are no NDA’s you will be signing – this will be work you can put on your portfolio, and talk about as much as you want to. This might be especially useful for people looking to build their portfolios.
This openness might also be a good way to understand the ROI of usability. If a redesign leads to increased downloads, or usage of a system, that information can be freely shared. Companies have typically not been willing to share this information freely, making it difficult to link project success with design and usability.
Below are some of the open source projects that participated in the sprint, and are (to the best of my knowledge) looking for usability input. You can find their contact information on the Flosswiki.
I am sure there are many other open source projects looking for usability/design help. I will update the list as I learn of more. If you are interested in joining the discussion, then also consider subscribing to the FlossUsability mailing list.
Thanks to all the sprint participants for some great discussions during the sprint, and on the mailing list.