Usability, a question of (open source) leadership

At today's Open Source Business Conference Jim Zemlin, president of the Linux Foundation, said something interesting (and hope-inducing) about open-source development. The session was on what the open source world can learn from Microsoft.

Surely, there are many things to not learn from Microsoft. Usability, however, is not one of them. Say what you want about Microsoft, but it has led the industry in lowering the bar to computing for average people. When I was in law school Microsoft used to give me free software so that it could come by my house to watch how I work. Microsoft spends considerable resources in the field to determine how people use, or could use, software.

I asked Jim to comment on how open source can match that, given that open-source communities (as opposed to open-source commercial projects) tend to be comprised of developers who may or may not have a feel for what non-developers want.

Jim suggested that it's a question of leadership. That is, within open-source projects that place a premium on usability, this trickles down within that project and eventually expands beyond to adjacent projects. He noted Ubuntu as a classic example of a project that is making usability a top priority, which is having an effect on other desktop and server Linux distributions.

I suppose this isn't all that different from the proprietary world. Microsoft is good at usability, but many of its proprietary peers are not. There is nothing inherent in proprietary software that is better than open source when it comes to usability. Rather, it's either a core cultural priority or it's not.

Importantly, there is something inherent in open source that can be better about usability than proprietary software: The users write the software for other users. There is no intermediary that processes product requirement documents to translate use cases to engineers. There are just engineers.

The trick for open source will be finding ways to bring non-developers into the conversation. I'm not sure how to accomplish this, despite spending five or six years thinking about it.

Your thoughts?

[kieranlal]

Drupal's managed to grow by bringing non-developers into the conversation by using GUI only development. Website building tools for form building, layout tools, and dynamic site navigation make highly motivated users able to build advanced websites. Today we are focused making great designs available to non-developers.

I was in the panel as well and I think they missed the biggest learning open source can get from proprietary software vendors. What have learned from Microsoft and Google "A computer on every desk and in every home...", "Google's mission is to organize the world's information and make it universally accessible and useful."

Proprietary software companies are much better at setting overarching missions that include a focus on their users. Open source projects bootstrap as a development models first. As they migrate to marketing models they often struggle to include a mission for their users. Ultimately the open source projects that will succeed will have a mission statement, or user experience statement, that casts the widest net for creating values for the most users.

[odubtaig]

Funnily enough, watching my dad wrestle with the idiosyncrasies of Excel and Word has taught me a great deal about how not to design an interface. Not that I'll be designing much in that way myself for a few years yet. It is, though, another reminder that one of the greatest failings of OpenOffice.org is that it had this wonderful opportunity to present an alternative to MS Office that worked in a much more usable way and instead chose to emulate it to a tee, including all the really irritating little niggly bits.

Honestly, I don't find a lot of FOSS software less user friendly, just different, and I'm possibly the world's biggest fan of Focus Stealing Prevention.

[odubtaig]

PS. seems cnet's still mangling paragraphs.



Testing if <br> does anything.

[russ danner]

For starters, we have to make a space for them (normal, non techie users) in our communities. Most of our communities have too high a technical threshold such that no normal person would ever want to participate.

I hope this blog is followed up by another blog :) The session was about what we could learn from microsoft -- I'm not sure we spent enough time really asking this question -- and it's an important question. Sam Ramji of Microsoft did a good job where the conversation found traction but this talk, very good in a lot of ways but (i thought) somewhat off topic left me wondering if open source has the stomach to really ask the question about what microsoft might actually have to offer in terms of getting it right or if open source is content to focus on what it's currently doing. Microsoft is making more money than any open source company and is operating at a scale no open source companies have yet to achieve -- there has to be something we can learn. I think we need to spend more time listening.

[PACSferret]

I think its still evolving. open Source (or perhaps more precisely, Free software) used to be at a level of "you want documentation? Read the code", but now as acceptability outside the 'hardcore' has reached a threshold (for some years, perhaps), more and more non-developers engage, from writers, testers, graphics, etc. I don't know if there are any non-commercial OSS projects who have professionals running usability labs and focus groups but there is no reason why they couldn't (although incentivising users may be an issue). I recall visiting a v.large proprietary company who had a lab with hidden video cameras to track user's eye movements. I though it was spooky at the time, but that is what is needed to really understand how software is actually being used.

Where does the infrastructure come from? Obviously for a commercially-oriented project that isn't so much of a problem but otherwise?

The first, step, though, is to recognise that a great deal of OSS does have usability problems, and that developers are almost never the right people to address those - many projects have yet to grok that.

[celestelyn]

I can't say I completely agree. If you look at the literature of the professionals actually doing open source usability, leadership is only a secondary problem (in addition to developer-designer communication and lack of professionals involved). The primary reason usability in open source fails is that there is no vision or understanding of who the product is for. This can be solved on the developer level, and even at this level can and will make an impact. Things like leadership, communication, and professional involvement support user research and acceptance of the findings on a project-level. Sure, these things are very important too, but not the root of the problem.

(I feel like I've been talking in circles about this topic for the past few weeks)

[dominic_sartorio]

Here's a product manager's "spin" on this.

Usability is a by-product of understanding your target user and the problems they are trying to solve. In the proprietary world, this often gets captured in requirements docs and product designs that get thrown over the wall to engineers who typically don't (or aren't allowed to) talk to their target users. Consequently engineers are left with this vague sense of "the user" without any clear idea of who exactly they're developing the product for, and have to trust their product managers to tell them, and the result is, frequently, hard-to-use software unless you invest heavily in usability labs and so forth. Alan Cooper wrote a great book about this problem, "The Inmates are Running the Asylum", I recommend reading it.

With open source, suddenly engineers are allowed to talk to target users. But many don't know how - they never had to before. I see this over and over again with open source projects, engineers say "great, we don't need product mgmt to tell me what to build anymore" but still have vague and incomplete understanding of "the user". And I'll say c'mon guys, get out of the office, meet a living breathing end user of your product!

The role of PM is still needed but does change in open source. You're no longer dictating via requirements docs what to build. It becomes more facilitative ... brokering peer to peer relationships with the user community. What I do is (1) always invite engineers to my meetings and calls with customers and partners and (2) use collaborative tools where engineers and users can directly interact. I then back off and manage the process, as opposed to managing individual requirements. So, still a useful role for PM to ensure usable products, but the role is different.

Disclosure: I run product management for my company. :-)