Just following the recent World Usability Day and a few months past the third birthday of OpenUsability I took some time to talk to Jan Mühlig, one of the OpenUsability founders and to get an inside look at some of the history of the project, how it works from the inside and some of the current direction.
Relevantive KDE / Linux usability study published
OpenUsability founders at KDE World Conference
OpenUsability project started
Slashdot and similar news sites first pick up on OpenUsability
First OpenUsability booth at LinuxTag, visit by German Minister of Justice Brigitte Zypries
OpenUsability e.V. founded
OpenUsability begins cooperation with the Open Society Institute to sponsor and mentor student usability projects
Hi Jan — first I'd like to get a little background — could you tell us where you're from, who you work for, where you live?
I'm Jan Mühlig. I was born 1971 in Reutlingen, in southern Germany. I studied sociology, ethnology and philosophy in Regensburg (Germany), Mainz (Germany), Chicago (US) and Lausanne (Switzerland). I've been living in Berlin since 2000 and am currently the CEO of the usability consulting firm relevantive, which I founded.
How did you get into usability — was that something that came while you were studying?
Not really. I did user research during my studies (media sociology), mostly dealing with TV and I did ethnology, which has a lot to do with understanding others' behavior. After my degree (MA) I started working in an advertising agency where I projected TV audiences for commercials. Then, in 1999, I took a position as a marketing manager at a big multimedia agency. The problem there was that we made a lot of interactive things, but many of them were crap because we never took the users' perspective but just assumed that we knew what was best. A year later, after I quit that position (in the summer of 2000), I decided to do exactly what was missing in my previous work.
With the background I had from my studies it was not very difficult. I met a school friend who worked as an IT consultant and we decided to found the company. We still had a lot to learn. In the end, most of my usability knowledge I got from books and practical experience.
Open Source Meets Usability
So, that's the beginning of Relevantive. How did you move from there to getting into the Open Source world?
I played around a little with Mandrake around 2001, but I had no special interest in OSS. Then, in 2003, I had some arguments with Jutta Horstmann, who claimed that Windows is not more usable than Linux. In order to settle that, we started a large usability study during which we — especially Jutta — got in contact with Eva Brucherseifer who helped us to set up the testing machines with Linux / KDE. We published the study under a free license and when we presented first results at LinuxTag in 2003 we got a lot of different responses. On the one hand we said Linux on the desktop can be as usable as Windows, but you very much have to configure it and we mentioned a lot of weaknesses. We were invited to present our study at the KDE world summit in Nove Hrady.
The reaction there and the interest in usability was very mixed. Some, like Daniel Molkentin, Cornelius Schumacher, Eva Brucherseifer and a few others were very interested and wanted to know how to improve usability in KDE. At that time I understood very little about how thinks were done in Open Source, and I saw that the infrastructure OSS projects worked with weren't very suitable to usability work (mailing lists, bug tracking, CVS).
I also had the impression that it would be very difficult to get usability folks to join OSS projects. That's why we said we needed a platform that actually interfaces usability and OSS development. So jutta started to set up GForge. I knew from reading usability mailing lists (KDE) and from experiences during Akademy that it didn't make sense to approach a developers and “convince” them of the benefits of usability; I came to the conclusion that usability can only work if the developers are ready to go for it, which is incidentally the same in the commercial world.
So we had three challenges:
- Get developers interested in usability
- Get usability people inside the projects
- Get workflows, interfaces and resources between the two groups
The interesting thing is that OSS developers identify much more with the software they write, so many actually have a strong interest in their software being usable because they like happy users. But I don't actually believe that a majority of developers can become really usability savvy — it takes time to learn it and actually you need some distance.
A Project is Born
So now we've got some of the background — the platform, the motivation, some of the process — how and when did that all come together to form OpenUsability?
After Nove Hrady (Akademy 2003), the platform we developed was financed by Relevantive and all efforts came from there. But we didn't want people asking, “What is the real reason they're doing this?” We wanted something with more credibility. So even though the OpenUsability project existed, we thought we'd be more successful by formally being separate from Relevantive and on November 3 of last year, we founded OpenUsability e.V. Since it was not just a project, but a real organization we had more options — the ability to take donations, add new members, etc.
Who's a part of OpenUsability — both in the early days as a project, the founding, now?
Jutta and I were the first, then when Ellen joined Relevantive, she did a lot both in her worktime as well as in her free time. I organized a periodic usability round table in Berlin and through that I had the chance to convince more usability specialists to do things for OSS like Björn Balazs, or Peter Sikking. Ellen had contacts to the CCC people, like Sven Neumann, for instance. Since they were interested in Open Source, Tina Trillitzsch and Florian Gräsle also did some work for Relevantive.
So are all of those guys from usability backgrounds?
Except for Sven, the GIMP maintainer, all of the others had some kind of professional or academic usability background.
Working with OSS Projects
What are some of the other projects you have worked with at OpenUsability?
KDE PIM, though they're short on developers now. Björn and Florian worked on Kuroo, the Gentoo package manager. Björn also worked with TV-Browser; Ellen worked with Guidance (Kubuntu). Celeste and Ellen are very much involved with KDE Human Interface Guidelines. Katrin is helping out with Gallery, a web image gallery presenter.
How did those projects get in contact with OpenUsability? Did the developers approach OpenUsability?
Yes, that's one of the main principles of OpenUsability: that developers approach OpenUsability, mainly by registering their project on openusability.org. We also meet a lot of people at conferences and try to get folks that are interested in usability to sign up too. That's what recently happened after a EuroOSCON presentation with a radio server project Campware.org.
What is also important is that we prefer a “small” or “local” approach; usability does not come necessarily from top down, but through developers or projects working directly with usability specialists. That's why a project like OpenOffice somehow don't fit our approach as most decisions there are done top-down.
And what are the first steps?
Ideally we'd start with a thorough analysis of the goals and try to work out the best solution, but in practice, many developers come with a question and a certain feeling that things could be made better. Unfortunately, a lot of this is in the form of “What's the right way to do...” and on deeper inspection it points to a deeper problem rather than a quick fix.
In other cases, developers take themselves as the primary (or ideal) user. If the usability specialist from OpenUsability sees this and has no hard-data to base a recommendation on, a usability test (i.e. confronting “real” users with the piece of software in a structured manner) often helps, especially if no one has figured out what the user actually needs, or how they use the program.
Unfortunately usability tests are rather expensive; you need to find people, usually pay them for coming, analyse the results, and so on.
So, that usually doesn't happen for OSS projects? Or only in special cases?
Just like Open Source developers, our usability specialists also contribute in their spare time or “for fun”, so we try to maximize their efficiency. Analytical methods often make more sense and in many cases they're a prerequisite to doing tests anyway. A lot of real user testing would ideally be covered by universities, for instance as student projects, since they often have resources for such.
What other challenges do you tend to hit along the way?
In the case of GIMP, for instance, one main challenge was to identify what GIMP wants to be for the user, that is: what is the vision behind the software? That's difficult in OSS because a lot of software was started because of a developer “scratching an itch”. Evolution of OSS projects mostly works through additions (of features, etc.), but rarely are projects changed at the core after it's reached a certain size or level of recognition.
So, roughly speaking — how does that compare with non-community projects that you've seen. Is “open” usability a totally different world or just a set of variations on the usual theme?
It's a completely different world. In most commercial projects you're there (as the usability specialist) because marketing or product management wants you there. Commercial developers often hate you because they think you make trouble and slow things down. Also, in commercial projects (like, let's say a corporate intranet), there are a lot of politics, and usability only can change 5%. In Open Source, you are working directly with the developer and he is the one who decides. There is no management above, at least not in the community projects.
So, if as a usability specialist you are trusted by the developer you might have a big influence on the outcome — which is something extremely gratifying but also a lot of responsibility.
Also, in OSS you can see the effects almost immediately because of the short release cycles, whereas in commercial projects the feedback loop is very long. This is pretty close to an ideal usability engineering process where you have lots of feedback loops between software and user and thus iteratively get better in small steps. That's just wishful thinking in commercial software development.
What about the methods?
The methods do not differ very much, but the communication channels do because you rarely work locally together but rather instead communicate by electronic means — IRC, mailing lists (usually poorly), wikis and other collaboration platforms. However, if you happen to sit together with the developers you're working with you may be able to do a lot work in short amount of time, like at Akademy, LinuxTag or similar events.
Trust also has a lot to do with it. Usability input is not comparable to code. It is not as much objectively reproducible or verifiable. A project maintainer can't evaluate usability input in the same way as he can evaluate code. Instead, to some extend they must trust the competency of the usability specialist. There, meeting each other face-to-face and really talking can change a lot.
I think that's true in a lot of OSS. It's easier to work with people with faces.
That's why I would love to see more usability specialists present — let's say at Akademy. You often have to meet the people before you are not ignored in mailing lists anymore.
Any other big things on the horizon?
The Season of Usability, which Ellen initiated, which thusfar has been very successful is a clear sign that we are on the right track. The other important thing coming up will be to launching the new OpenUsability platform which should very much ease collaboration. From there we want to spread the word worldwide and get usability people in every country to support Open Source projects. We also want to get universities to support Open Source projects in an educational setting and on the other side to get companies to share their usability knowledge and to open up the process — to make usability open.