Tom Chi  

OSS S.O.S. - How HCI Killed Open Source

July 30th, 2004 by Tom Chi :: see related comic

KC has been taking care of articles for the last two weeks, but I’m back now (whilst he is on vacation) with a comic and article responding to the somewhat misguided call to arms put forward by Frans English. He has set out to improve awareness of usability issues within the OSS community with an essay entitled:
Open source usability is a technical problem we can solve on our own.

This is clearly an essay written by developers, for developers and it is rife with severe misunderstandings about the nature of both usability and design. While his goal of raising usability awareness in OSS is admirable, his message is filled with a deep distrust of established usability techniques and the professionals who practice them. Worse yet, there is an underlying tone that usability work is trivial to learn since it is less technical than code.Perhaps the most egregious example is this passage:

> All it takes is to think once about each little item like smbUmount. If the changes to this and other items that are obviously not user-friendly are made, most of our usability work will be done. We don’t need usability reports. We need each developer to devote as little as one single thought to usability.

Imagine that I were to pose the reverse statement. What if I were to say that usability specialists could do kernel development if they would only spend as little as one single thought on coding each day? Such statements are absurd and indicate a severe lack of understanding of what it takes to do usability (or kernel development) well. Perhaps some mistakenly think that usability is easy since it is easier (and speedier) to form an *opinion* about usability than it is to form an opinion about code. But when we move beyond opinions to the world of real usability engineering, one sees that it deals with as many complex variables as any other engineering discipline.

While the author does acknowledge that a deluge of usability opinions does little to help move OSS forward, his strategy to deal with this could use some help. Instead of recruiting people with usability skill and/or design skills, he would rather have the OSS community reinvent the wheel. He calls for knowledge bases constructed from HOWTOs and questions fielded via IRC channels and the like. But it takes no more than one single query (ok, actually maybe a couple queries) on Google to amass quite a bit of knowledge about usability engineering. Avoiding this body of knowledge and distrusting usability professionals sounds like classic �not invented here� syndrome to me, and points to a significant cultural hurdle that the OSS community must overcome.

Aside from such problems in the article, I feel that he has missed stating the true call to arms. It is simply that when it comes to innovation, excellent usability and design work are as important as excellent technical work. Period. If OSS is to suceed, the community needs to understand that usability is not just “another technical problem to solve”, but rather, it is an entire discipline worthy of real study.

With such a shallow bench and a fundamental misunderstanding of these disciplines, the OSS community has been forced to spend much of its time copying existing applications. In this way they take advantage of usability and design work done by others, but such a strategy necessarily trails behind the products being copied. To truly be innovative, they will need real in-house experience and experts of their own, not 1000 developers spending a single thought.

52 Responses to “OSS S.O.S. - How HCI Killed Open Source”
mindful_learner wrote:

Having speed-read the article, I find it interesting that Frans seems to focus on the obvious, visual aspects of usability (e.g. colours, labels, position of buttons). Therefore, it is not surprising that he sees this as a challenge easily overcome with a few guideliens and common sense (just tell us what colours to use, what lables are friendly, etc). Hence his rather embarrasing example of relabelling a menu item. Sadly, this is of course a complete misunderstanding of what it means to develop usable, effective and productive software applications. Perhaps this is still the last bit of marketing the usability community needs to do, that usability is not skin deep (though I think Alan Cooper has made admirable steps in this direction).

mindful

Gabe Johnson wrote:

Open source has a hard time with achieving reasonable usability, but it hasn’t been impossible. There are some projects–FireFox springs to mind–that have moved past the surface level (better labels, as per the article). The open source world is full of applications with horrible interaction, but where are all the decent ones? Does anybody have examples of open source projects that have done the HCI thing right? (Or, as close to right as what passes for usable commercial software?)

I suspect there are two main reasons why Open Source is so weak in the HCI front:

1) The decentralized free-for all that is Open Source promotes ’scratching personal itches’–if you don’t like something and have the savvy to ‘fix’ it, go right ahead. This means there is no central game plan (unless the project’s alpha-geek enforces interaction models–I am unaware of examples of this, however… any references?).

2) OSS programmers are often just hacking in their free time because their day-jobs aren’t satisfying their desire to write strong code. So for those people, they’re coding as a hobby, not as a job, which makes it difficult to impose un-fun constraints on them like listening to a non-programmer (oh the humiliation) as to why their software isn’t usable. The trick here is to find a way that good HCI can mesh with the OSS mentality and development model. Any suggestions?

Calybos wrote:

I’d say an additional factor is that they so rarely have any customers to satisfy–that is, any non-techie customers. And as we all know, coders are far more willing than humans to put up with a lousy interface for the sake of “cool functionality.”

No wonder there’s no emphasis on usability in open source: nobody sees a need for it.

Calybos wrote:

Followup… To me, the most telling part of English’s article was when he said,

“The KDE project alone has an average of 200 checkins to its code repository each day… [there aren’t enough usability specialists available to handle] this level of productivity.”

Yep. That’s what he considers “productivity.” Churning out tons of fast code with no awareness or interest in whether it’s usable or even useful.

Tom Chi wrote:

Yes, it definitely sounds like a very immature development practice if they are equating number of check-ins to productivity. Such a scenario sounds like a testing nightmare and something that would be chocked full of unfound regressions.

It’s a complete other discussion, but lack of adequate testing is another big hole in the way OSS projects work today. While they have bug reporting mechanisms, I am wary of any system where only the mainline scenarios have been exercised. Without real testers exploring the niches and trying to actively break the code I think it is just a matter of time before OSS is shown to ring hollow on its promises of improved security and privacy. Both testing and HCI fall under that umbrella of things that the “truly 1337 coders” would rather not bother with.

Until the OSS roster grows to include people with those other skills and the culture shifts to value their opinions (including at times valuing them over the hardcore coder), OSS will have a hard time setting the pace for anything but purely technical applications.

dave wrote:

There are so many things wrong w/ OSS and usability it feels like an insurmountable mole hill.

What’s interesting is the title of Tom’s article “… How HCI Killed Open Source.”

But then, Tom, you go on and do exactly what the author of the article you are criticizing did, which is to limit the importance of user/useage research to the GUI itself. Usability is just a piece of the missing puzzle pieces in the OSS community. Where is the rest of the UCD, too?

That said, I think what you said at the end is really the most valuable thing at all. To paraphrase … Where is the innovation? How can you innovate if the best you can do is copy from the non-OSS community?

I think there are some great examples of OSS alternatives to pay-for stuff, but these are few and far between. While FireFox is a near dream compared to IE (its chief competitor), OpenOffice is almost unusable and it has the full support of a major computer corporation.

Recently on the ixdg list and the SIGIA-L there have been discussions about UX and OSS. A lot of bickering, but in between it there were some solid thoughts.

— dave

Tom Chi wrote:

That’s a fair point. I focused on usability because I was responding using the language that the article used. But as per my previous comment there are many other things missing. Besides usability testing, there is interaction design, visual design, user research and ethnography, systematic requirements gathering, etc. And of course let’s not forget testing, internationalization, accessibility, and every other thing developers often neglect because they are not as interesting (to the devs) as the core technical problems.

Matt May wrote:

Tom, we seriously have the Vulcan Mind Meld thing going on. I blogged about this subject yesterday:

I dont know why every user interface designer in school or looking for work right now isnt working on the front end of an open-source project. There are more than enough to go around. And if Linux or any other open-source product is going to take hold of the market, theyre going to need to compete on equal footing with commercial software. That means doing things like usability testing on real, non-geeky people and solid user-centered design practices as a matter of course. Some of the stuff coming out of commercial software houses is great, but its not rocket science. It can be matched, or exceeded and it must, if Linux on the desktop is to succeed. Being free is no longer an excuse.

Dave wrote:

Matt, if you have a full-time job that is not related to OSS projects, how are you supposed to do the type of things you are suggesting? I mean its one thing to geek out and spend all night coding, but to do user testing “in your off time”? … I’m not seeing it.

I also am not sure why the “truism” around Linux must succeed is actually true. Don’t get me wrong, OSS is cool, but why must it succeed? Why Linux? Why can’t MacOS work? Why not others? My issue is around the truism part. For me, I don’t think this makes a lot of sense. To me the truism is, we can do better than what has been done to date. That can be done inside or outside of OSS, and in either case will require that UCD/UX practices are applied. Right now this is done most noteably outside of OSS and has been for some time. But since Linux has so much legacy right now, I would say, why Linux? Its like going back and saying, Beta is better than VHS … lets revive Beta by this and that change. I’m not saying that Linux is dead in the water, I’m just suggesting that a “religious crusade” for the sake of Tux is not a compelling starting point for me.

I am compelled to create great designs. But for the users, not for the software.

— dave

Reed wrote:

As a programmer who is interested in usability, I notice a definite misunderstanding going both ways here. 200 checkins a day *is* a lot of productivity– it’s coding productivity (by lots of people), and testing and QA productivity since most of those are no doubt bug fixes. But it’s not design or usability productivity of course.

The reason that usability is is ignored in open source projects is that there are no usability experts involved in most projects! Just programmers!

How to integrate that job into a typical open source projects has yet to be determined however. I think that the article’s proposal for a usability KB or “Howto” is a good one — but they have to be written by people who know usability, giving tips and understanding and ideas to programmers “in their language” to some extent (and written for software/architecture designers and managers too — these are all the same people is most open source projects) not written by some programmers guessing.

We need to start speaking each others’ languages. Usability problems can be considered bugs. If a usability person is, (after reaching consensus with other project members) able to change the GUI code to fix it, then that would be ideal (This requires GUI APIs which are themselves usable by non-experts!) On the other hand, people designing open source software need to know what the basic usability questions are, and how to communicate with the usability people during design and development processes within the project.

If you want to help projects’ usability and design, I encourage you to find a project and indicate your interest. Many project leaders love any help they can get, in any area. The only thing to be careful of is that they can also be *very* protective of their ideas and design, since these are very personal projects for them. The general culturally correct way to work your way into a project is to start by learning everything about it, then by fixing simple bugs and problems, working well within the existing design, before trying to influence the design. I don’t know how this process would work for usability design exactly. Usually the project leaders remain the #1 design authority, though they may delegate out modules to other people, including any UI module, so you can work more closely with that person. So some serous diplomacy and might be needed, or just keep looking around for a project that is willing to change their software design a bit more than others.

Jon wrote:

Reed wrote:

We need to start speaking each others’ languages. Usability problems can be considered bugs

In my experience, the problem with logging usability issues as bugs is that development continually downplays the importance of these defects, relegating them to the lowest possible value and indicating that the code can ship without addressing them. I’m sure I’m not alone in lamenting that I’m sick and tired of hearing “do you want it to work or do you want it to be usable” when debating the “value” of a usability defect. If usability errors are to be grouped with functionality errors, development needs to be begin to understand (on a cultural level) the importance of usability and understand that to the user, usability is functionality …

Julian wrote:

Reed wrote:
there are no usability experts involved in most projects!

That’s because whenever they attempt to get involved, their “opinions” are often downplayed or ignored. I’ve spent a lot of time over the past 5 years trying to push a better understanding of usability in a variety of projects, and I’ve only succeeded in educating a small handful of developers to appreciate good UI. The rest still fail to understand.

This is the part that is correct: they can also be *very* protective of their ideas and design, since these are very personal projects for them

Usability people can probably only get respect in an Open Source project by “taking over” large portions of it based upon code contributions. That’s just the way Open Source projects tend to be run. Most usability people just can’t or don’t want to do that much code.

Marius van Dam wrote:

“Usability people can probably only get respect in an Open Source project by “taking over” large portions of it based upon code contributions. That’s just the way Open Source projects tend to be run. Most usability people just can’t or don’t want to do that much code.”

Right on spot!
In one of the comments under the discussed article someone suggested that they should create a site where they can brainstorm on the basis of design sketches.
Although it’s not a bad idea; it’s certainly better then the current situation where there is only brainstorming and no sketching of alternative interfaces; in the end I only way something can be achieved is by doing. At least, that’s the opinion of the techie guy in my company, who is very aware of usability issues. (good for me!)
People from the user experience community that want better open source software could partner with usability-aware developers to create sub-projects focused on usability and overall experience, based on the existing code. If those projects are successful eventually it’s work may be reintegrated into the main code.

marius wrote:

BTW: ‘Frans English’ (author of the discussed article) has a beautiful name!

In dutch ‘Frans’ means ‘French’.

Wibble wrote:

Open Source Usability

Article at Newsforge by Frans English has generated some buzz, including this very nice rebuttal at ok-cancel. both are worth reading, in the given order if possible. Frankly, one of the problems of ‘usability’ in open source is, as stated…

Simon Edwards wrote:

Reed wrote:
there are no usability experts involved in most projects!

Julian wrote: That’s because whenever they attempt to get involved, their “opinions” are often downplayed or ignored.

That’s because from the developer’s point of view there is no difference between a usability expert and just some guy who walked in off the street and has an opinion on everything…

What this all comes down to is trust and reputation. The usability community needs to do a much better job of ’selling’ usability and not just sounding like a bunch of smug know-it-alls who like to complain how bad OSS usability is but don’t actually do anything to help out.

One way to help establish some trust and give developers some insight into what it is that usability people actually do, would be to create a full detailed design for a program(s). From start to finish, every detail. Put in the hard work. Choose something not too big, little a backup utility for example, and design and document the whole thing and how it should work. Work out what the use-cases are likely to be. Explain why things should be done a certain way and explain why the alternatives were not chosen. Explain which usability principles are being used. Test the paper prototypes on real people and incorporate the results into the design and the design document.
Most of all, help demonstate that the usability people are here for the long haul and are willing to do the hard work.


Simon

Julian wrote:

Simon wrote:
Most of all, help demonstate that the usability people are here for the long haul and are willing to do the hard work.

Sure, so why don’t you go ahead and do that? :) I’d rather be able to just contribute to open source projects every now and then with advice on how to fix certain aspects rather than spend all that time documenting and creating just a single project. Nonetheless, it is a good idea.

Aaron J. Seigo wrote:

usability is very much under-represented within open source development. however, it’s not for the reasons that are often given by those peering in from the outside.

consider: if we didn’t have any developers who knew anything about compilers, would we have any good open source compilers? probably not.

open source development is an exact reflection of the efforts that go into it. for example, internationalization and localization is a strong point of many Open Source projects because there is an international audience who got down to the business of translating and localizing. technical prowess is a strong point of many Open Source projects because there is a large group of technical programmers working on those projects.

so where are the usability people doing the same thing for usability? by and large, the answer is: absent.

some say that there is no interest in usability among open source projects; fallacy! more accurate is that there is a dearth of expert-level usability efforts relative to the amount of other aspects of development (art, i18n, coding, packaging, etc).

some say it’s because open source developers don’t understand usability. well, duh! how many developers of closed source software (which most open source developers also do) “understand usability”? if the answer was “lots”, there wouldn’t be a usability industry, would there? so again: where are the usability people?

some say open source requires usability people to write code. based on my personal experience, this is not true. what’s lacking are definitive, accurate and useful (to developers) sustained sources of usability input with a direct focus on specific Open Source applications.

if we want Open Source to be “more usable” then people with knowledge and skill in usability issues need to step up.

btw, several of us looking to help grow this process will be at the KDE annual conference in Stuttgart in the second half of August. if you, as a usability professional, are interested in seeing what may be possible, please consider attending. http://conference2004.kde.org

Julian wrote:

Aaron: I’d hardly consider myself an “outsider” to the open source community. Read some of the other comments here. These are not all comments from “outsiders”. Usability people have made attempts at getting involved, but for the most part their attempts at contributing are rejected.

Open Source people have no good way to judge whether someone is actually knowledgeable about usability, and therefore it seems to be something that is just opinion. So.. it’s very easy to dismiss attempts to contribute, and generally that’s what happens.

The problem here is how to get open source developers to actually respect/listen to usability people… the right usability people.

Marius wrote:

I guess suggestions aren’t enough then? Maybe it would work if some formal usability testing was done, and the results, including video compilations of serious errors (could call them ‘bloopers’?) were put online for everybody to see.

I especially see long montages of lots of people making the same mistake over and over again. :-)

Aaron J. Seigo wrote:

@Julian: of course not all people who talk about Open Source usability are outsiders. many, however, are. and some who are usability professionals and hang around open source projects simply do not grok how to interact with said projects, which leads to a feeling of ineffectiveness. and of course not all projects are the same. some projects ARE not open to usability (even if that’s unintended), and that sucks.

in KDE, for a long time it was simply usability agnostic. by which i mean the developers were neither really FOR nor AGAINST usability. there just wasn’t much in regards to usability addressed, period.

over the last while, however, usability has been introduced more actively as a concept to the developers and there is both interest and efforts being put in. it isn’t perfect (yet) but we moving towards better processes.

it must be kept in mind, though, that just as the processes for writing code are similar yet different in Open Source projects compared to closed source projects, so must usability process be similar yet different when compared with traditional closed source usability efforts. this is NEW ground, and one i hope more people involved in usability will find enticing because it is new ground. it means challenging our own ideas as well as introducing new ideas to others. what could be more interesting? =)

but to accomplish this we REALLY need usability experts who are both engaged by the idea of usability in Open Source and are willing to discover ways to marry usability effectively with Open Source development. it can be done, of that much i am sure.

the KDE developers are generally ready for and open to such efforts and therefore is a good candidate to start with. as evidence of that, _real_ usability studies and input by usability experts that have been done with regard to KDE in the past have resulted in positive changes in response. there is still yet much to do.

Graham Storrs wrote:

Actually, in most circumstances in which usability experts could contribute to an open source project - and in most circumstances in which they do contribute to closed source projects - they might as well be “just some guy who walked in off the street”. I speak as someone who has been designing UIs for over 20 years. What the UI designer really contributes to a project is the method by which users and their task requirements are understood and modelled in such a way as to inform design models so that system functions and information resources can be orchestrated to support user activity as it unfolds through time. If all we are used for is screen design or usability testing without all that requirements analysis and modelling work, then, frankly, most people armed with a set of guidelines and a drawing package could do a similar job. Given that we rarely get the chance to ‘do it properly’, it is little wonder that most people on a project tend to have a low opinion of our expertise - they barely see us using any of it and they can see that the added value of our role is actually quite small in most cases.

Simon Edwards wrote:

Just to continue on a bit with what Aaron was saying. OSS projects are craving good usability expertise. I think the reaction to the two studies/tests that Relevantive did (www.relevantive.de) about KDE show that developers _do_ listen and _do_ want help. Many KDE developers have read those studies and addressed the problems raised. This also helps show the amount of effort required on the part of usability experts to make a definite and useful contribution (and not just ‘opinion’).

Graham Storrs wrote: If all we are used for is screen design or usability testing without all that requirements analysis and modelling work, then, frankly, most people armed with a set of guidelines and a drawing package could do a similar job.

True, the so-called “spray on usability”. :) Seriously, I doubt usability experts will “get the chance to ‘do it properly’”. It’s that trust and reputation issue again. You are going to have a hard time finding developers that will follow your design from day 0. Which is why I suggested making and documenting complete software designs. You will have more luck finding someone willing to implement a usable design once they have seen the _full_ design and rationale, than trying to hookup with a developer first and then working out a design. You need the design document as bait. ;-) You need to take the initiative first.

(If any usability people here want to try designing something from scratch, but don’t know what kind of program to design or problem to solve then email me.:-) Personally I would like a fast and easy CD based backup program for people who hate making backups. Take the pain out of that chore please!)


Simon

BlndCat wrote:

I’m torn between the two sides here. I’m from a technical background but my main work is with usability (of web sites).

I think Graham has a very valid point, and it is something that occurs in web design not just in OSS. In many cases it is hard to cultivate the appreciation of the work put into UI, IA, usuability and the results from this work in a company never mind in a OSS project.

Julian: your posts on the 1st and 2nd seem to be contradictory in tone. On the 2nd you wrote:
>The problem here is how to get open source developers to actually respect/listen to usability people

Yet in reply to a fairly sensible (but hard) suggestion by Simon you wrote:
>Sure, so why don’t you go ahead and do that? :) I’d rather be able to just contribute to open source projects every now and then…

The problem with contributing “every now and then” is that you have no real depth of knowledge on the project. And worse you will sound like a person looking over the solitaire player going “oh oh over there over there, the red 5 and and…” which is hardly a way to get developers to listen.

My suggestion would be trying to pitch towards companies like Sun, IBM, Red Hat and Novell where we are more likely to have an understanding and maybe slightly appreciative audience.

Bob Salmon wrote:

Disclaimer: I’m a ex-closed-source programmer, who’s only contribution to OSS is to fix one bug in Emacs. I’m not a usability expert either. Lack of knowledge doesn’t stop me having an opinion! (That must make me a manager ;-)

It’s a stereotype that programmers are thing-oriented rather than people-oriented, and it’s my suspicion that with OSS programming this tendency is even more pronounced. Also, in distributed [OSS] projects, people’s interaction is usually limited to email and check-ins.

So, a usability expert expressing views that seem vague and people-related rather than say “algorithm A is O(n.log(n)) but algorithm B is O(n^2)” is an impedence mismatch. You can judge a programmer by her code (which is open for all to see), and so trust and respect can be developed.

Given that this is the normal form of communication and interaction in OSS, how do usability gurus fit in? I don’t think it’s practicable to expect the community to change, so usability types will have to learn how to speak OSS-developer. Quantitative rather than qualitative data from relevant case studies would help - particular comparisons with M$ products!

Also, could usability gurus use the existing trust networks? Could Linus / Alan Cox / et al ‘get usability’ just like Bill Gates ‘got the internet’? Should we be lobbying them to champion the cause, which would then be better received by the OSS developer masses?

Andrei Sedelnikov wrote:

Everyone working in the field of usability was “selling” it to his team and his company all these years. He has objectives to do it: getting better product, more respect in the company, more salary.

Why he is now supposed “to sell usability” to OpenSource, or may be even to start coding by himself? What does he get from it? Better product? - he cannot be sure if his work will really have effect on product. More respect? - Hardly. More Salary? - definitely not.

I can imagine a successfull OSS + Usability collaboration only in the reversed way: when some OpenSorce Team gets real understanding that they desperately need usability in their project. Then an usability expert can come to OSS at least because he will not have “to fight” for usability.

Julian wrote:

BlndCat, what I mean by “every now and then” is that I’d rather not have to be a primary developer of a project to investigate and contribute to some aspects of the UI. But yeah, I understand what you’re saying about looking like an over-the-shoulder solitaire player. The thing is, with the UI of most open source projects out there, I still tend to think even an over-the-should-solitaire-playing usability engineer would be better not ignored. True, it’s nowhere near as useful as actually being involved in the project from the beginning… and I do understand how that harms the image of usability folk in general.

I guess my point is that I’m not even entirely sure how usability folk should be involved with Open Source. Most Open Source programmers can be “over-the-shoulder-solitaire players” when it comes to code–and that’s generally where a lot of the strength of Open Source comes from–”many eyes” and all that. I don’t know if that can be decently applied to usability as well, if at all.

david clarke wrote:

As an ex. software grunt and team lead I can tell you that most programmers are not anti usability any more than usability people are anti programmers.

OSS is a tough community filled with programmers who love what they do, it does not accept most *programmers* let alone anybody else. OSS is a labour of love for those involved.

Credentials have to be proven in the OSS community. Those that prove they are useful to OSS are the ones who are accepted. And those people will necessarily have to have the same passion for OSS as the current contributers to OSS.

It is not for everyone, but I believe contributing could be personally very rewarding for those who help to create the next generation of open source software.

Torsten Rahn wrote:

I’d like to invite all people interested in usability for OSS projects to join our KDE usability mailing list:

http://www.kde.org/mailinglists/

and to visit our KDE conference “aKademy”

http://conference2004.kde.org/

where you will be able to talk to OSS developers as well as usability experts.

About the article above: Of course the article of Frans English is targeted mostly at code developers. The people who visit newsforge will most likely be code developers. As there are lots of things that *can* be fixed by code developers if they only spent just one additional second it makes sense to point it out (like Frans did). Doing that in a diplomatic way and giving them self esteem (”You don’t need experts to fix tiny issues doesn’t need a usability expert to fix it”) is essential when you work for OSS. Of course there are enough more interesting and less tedious issues left for usability experts if only the code developers thought an additional second more.
Hopefully as a result of this article code developers will think a lot more about usability issues so that the usability experts in our team will be able to focus a bit more on the more difficult things to fix instead of myriads of tedious “smbUnmount”-fixes.

The most important points when participating with OSS is diplomacy as well as attitude: You have got to figure out how to
** place your “advice” so that it gets *visible* (a good place is either the mentioned mailing list — more effective might be writing an article or a report like relevantive did)
** try to communicate your suggestions in a way that doesn’t sound insulting as well as dismissive. While Frans’ article certainly might have sounded dismissive in respect to usability experts, Tom’s article is dismissive in certain respects as well.
** make points why it is vitally important to fix this stuff as soon as possible. And why it should be fixed today instead of later (after implementation of feature D or E)
** try to find out who might be the ideal person who might fix the issue you found
** earn your respect by fixing tiny stuff as far as possible yourself

I have been coordinating the KDE artwork group for years and I also worked a little bit in regards to usability in the KDE project since 1999. The problems why it isn’t easy to contribute to OSS projects in terms of artwork and usability are fairly comparable in certain respects. All kinds of developers have a lot of suggestions on their TODO list. So just making suggestions for further items doesn’t cut it (in fact its rather annoying). You have to illustrate why it is important that those issues get fixed and ideally you give them as much (short!) advice for implementation as possible so that it doesn’t require much thoughts left for the developer.

Greetings,
Torsten Rahn

Jay Zipursky wrote:

David wrote:

Credentials have to be proven in the OSS community. Those that prove they are useful to OSS are the ones who are accepted. And those people will necessarily have to have the same passion for OSS as the current contributers to OSS.
I spend enough time proving myself and usability in general at my full-time job. Why would I want to do this for an OSS project?

OK, OK, I have no passion for OSS. I admit it.

As someone else mentioned above, I don’t think you’ll get hard core usability work done on an OSS project unless you find an out-of-work usability professional or a company willing to donate time. Just conducting a usability test with 5 participants is a relatively huge undertaking. (Let alone getting the developers to agree on just what usability goals are important to test for…)

BlndCat wrote:

Jay Zipursky wrote:

I spend enough time proving myself and usability in general at my full-time job. Why would I want to do this for an OSS project?

but that is no different to programmers/developers themselves. Most of them get paid fairly well at work, but they still have to earn respect and trust outside of work and in OSS projects.

If you came across a project that you thought, “wow good idea, good code, solves a problem for me and others like me, but hell the usuability is so poor” then maybe you would find the extra motivation to prove yourself.

And if you need another answer to your why question. It should be noted that the amount of respect and recognision you get from doing OSS projects can be a lot higher, and have a bigger scope than at your company. I can name the main developers of Samba, but without researching I couldn’t tell you who worked on NFS. (sorry showing my tech roots)

but yes I agree with you that any usuability work is a lot of work.

Jay Zipursky wrote:

but that is no different to programmers/developers themselves. Most of them get paid fairly well at work, but they still have to earn respect and trust outside of work and in OSS projects.

Yes, but they don’t have to prove the value of programming, they just have to prove their own skill.

s.p.i.d.e.r wrote:

It seems to be an inherent part of the human psyche to divide up and fight between the groups - we are all part of the same big puzzle and all of the elements are just as important.

Usamajility practitioners have adopted the current attitude because they were forced to prove the validity of there work - as with any new discipline. It is now time to let the water pass under the bridge and just get on with it - as per the majority of the comments.

Just to steer the discussion away from the age-old epic battle of the two factions and take another look at the article…the comment below

“Usability discussions will no longer be long anecdotes and personal opinions, but will become problem-oriented, and will be discussed in terms of right and wrong.”

Is one that pushed a few buttons with me - usability has struggled to quantify what is largely qualitative data since its inspection and explaining the distinction and usefulness of both to technical ‘problem solvers’ as they like to be called (?) is difficult - there is no real right and wrong - ones persons rubbish is anothers gold - usability is the practice of finding the line of best fit for a set of steak holdershow to guides are out there in the form of degrees and masters qualifications its not a subject that you can easily convey in a few pages of do this and do that comments as these will only ever be opinions!

Simon Edwards wrote:

Jay Zipursky wrote:
[programmers]
Yes, but they don’t have to prove the value of programming, they just have to prove their own skill.

More and more OSS projects appreciate the value usability. The tough problem is as a developer how can I know and trust that you as a self proclaimed usability expert, actually have the skills and good judgement that you say you do?

Same problem as with the programmers.


Simon

Jay Zipursky wrote:

Simon says:

The tough problem is as a developer how can I know and trust that you as a self proclaimed usability expert, actually have the skills and good judgement that you say you do?
Part of the problem with that statement (and part of what my original point) is that usability seems to be boiled down to expert reviews in an OSS context. Doing anything else is too effort intensive. An expert review is just an opinion when you boil it down, and anyone in that position will have an uphill battle.

On the other hand, if an OSS usability team member had the time and resources to do contextual analysis, usability tests, etc the “opinion factor” is diminished. Team members can look at video tape or observation notes and see that recommendations are based on real data. This is the method I’ve used to prove myself at work and seems to be the standard with other usability professtionals I’ve talked to.

Maybe usability professionals interested in helping out OSS projects need to band together and tackle projects as a group to distribute the load. For example, 5 usability people each testing one participant (periodically) or visiting one user is a more realistic scenario. Also, OSS teams would be more likely to trust a group than an individual.

Now I really have to get back to work. :)

Adam Barker wrote:

I’ve seen a few comments that touch on process in a light way, but I think that it’s one of the more important missing components in OSS. User centered design, interaction design, usability– these things have a tendency to be misunderstood by people who don’t live them on a daily basis. They are all an important aspect of the process behind any well-run project, just as a solid development and QA process is instrumental for ensuring quality code and on-time delivery.

OSS doesn’t run this way. As we’ve pointed out, much of OSS development is carried out by people who don’t feel fulfilled by their day jobs. Someone made the insightful comment above that adding any sort of “un-fun” element to this development process scares away your work base. Unfortunately, formal methods and repeatable practices are quite often perceived as tedious and unnecessary. Many of the larger OSS projects have adopted stringent development practices (KDE has something, I’m sure), but these practices represent only a small piece of the puzzle.

I believe this also relates to design and trust issues between the OSS and HCI communities. If you ever get to the point where developers perceive HCI decisions as more than just an opinion, you still have to overcome resistance to adopting additional process and formal methodology for a project. “Requirements gathering? Why should we do that! I already know what I want to build!”

From this standpoint, there are barriers to entry from both directions. HCI participants don’t necessarily want to project-manage, and OSS developers don’t necessarily want to be project-managed. Unfortunately, without a lot of coordination and effort, it’s hard to move past the point where a project effort is more than a bunch of cowboys checking in code that they find interesting.

There is also a huge problem to be solved regarding the shoe-horning of HCI into a large, existing project. In many cases, I believe it’s substantially harder to redesign an existing product than it would be to start from scratch. Once you have momentum (200 checkins a day), it can be extremely difficult to make fundamental changes to interaction. Unfortunately, many OSS projects are built on flawed models, necessitating very deep changes to make significant impact on user experience. The comments about smb-umount illustrate this quite nicely– “change the text,” says a developer. “what the hell is a network drive share, and why would I want to turn it off?” says the user.

Obviously, there’s no magic bullet for retrofitting existing projects. It takes an enormous amount of patience and persistence to develop and follow a plan that will change the course of such a project over a long time frame. When you don’t have political clout, it’s very hard to get into a position of power that will allow such major changes of steerage, so your suggestions, however valid they might be, are relegated to the status of outside opinion.

Honestly, though, I think that the problems facing HCI practitioners in OSS are just amplified version of those that we face in commercial development. As a community, we need to work toward a major shift in the attitude and education of the software community. It’s always tempting to do the easy thing rather than the right thing, and the vast majority of software practitioners has trouble even telling the difference between the two.

- Adam

Darren Delaye wrote:

I really doubt that I could use two builds of KDE that were 5,000 checkins apart and notice any difference at all. As Reed mentioned, it’s lots of bug fixes and small changes, and they probably don’t affect my ability to use software. It’s not so much the small changes as the big choices that get made early on.

I don’t think it’s going to be easy to get usability involved earlier in projects, even though more and more planning goes into new projects. Designing user interfaces and information flows takes time that developers aren’t going to spend on iteration. It’s their project, and it’s fulfilling some need that they have.

Maybe a better question to ask is how far can we go with checklists and tips for developers to use before they start turning their unit tests into applications.

The first thing I think of doing comes out as an attempt to turn developers into their own users. Pretend I didn’t write the software. Can I find the action I’m looking for (even though I don’t know what it’s called)? Are the important features visible or simple to get to? Do I understand the things I’m looking at? What are the first 3 things I see when I look at this (because users might not get passed the first 2)? I have no idea how to do something. Where do my eyes look for help? Hell, give ‘em the Mom test. Would my mom know what this does? Could she figure it out? Literally show it to your mom and find out. The barrier is convincing developers who think they don’t write software their moms would ever use that people who need to use all different kinds of software have all different backgrounds, and wide adoption means that yes, your mom needs to run Java Servlets from her bedroom, so what’s the first thing she tries to do?

Dave wrote:

This isn’t about people … This is about process…

Someone said it really well up there by saying programmers don’t disrespect Usability folks (BTW, can we move beyond usability to “Experience” … I mean are we just worried about task success rates, or are we interested in making good sound products that meet the needs and engage users?)

The overall process of OSS is the issue, and as I said before, unless you are willing to change this issue, there will not be significant advances in innovation, design quality, and usability within the OSS community.

But hey, OSS is a big success so why should anyone want to change it? Well … “free” only lets you compete so much. — dave

Oluseyi wrote:

I read this article, though “Absolutely! This needs to be heard!” and rushed off to popularize it with a set of Unix geeks I am familiar with. The response was quite illuminating.

Based on the arguments and discussions in that thread, I have conducted more research and recently discovered the Eric Raymond essay The Luxury of Ignorance and its follow-up. I don’t think there is any further excuse of any OSS/programmer “elitist”: ESR has the experience and credibility that many of you aspire to, and the reactions he receives from readers in the follow up indicates that WE (the usability-deprived) are RIGHT and you (the if-you-can’t-figure-it-out-then-you’re-an-idiot-or-it’s-not-for-you crowd) are WRONG.

Seriously, read the articles. I hope the increasing attention on this issue is a signifier of an impending sea change.

Nice work, Tom and Kevin, and thanks for keeping me thinking. I was this close to thoughtlessly creating another unusable interface for an in-house tool at work in favor of expediency. Back to the drawing board!

Oluseyi wrote:

Oh, yeah, one last thing: OpenUsability. Quoth I:

“OpenUsability.org is a project that brings open source developers and usability experts together.

The idea behind is simple: There are many Usability Experts who want to contribute to software projects. And there are many developers who want to make their software more usable, and - as a consequence - more successful.”

Get involved!

Ron Zeno wrote:

There are so many issues here that I’m just going to identify a few without discussion:

I share the perspective of most people who have worked on such projects: I have serious doubts about the abilities of hci/usability/ia/ux/ucd/etc practitioners/methods/organizations.

Open souce projects (and many projects for that matter) are “unrestrained” (for lack of a better term that has positive connotations). This makes it extremely difficult for any widespread design changes of any kind to be made, except very early on in development. This applies to all aspects of design: hci related (visual, interaction, etc), coding related(classes, objects, methods, etc), etc.

Unrestrained projects put the burden of all aspects of quality on the individual teammembers (or teams). It’s sheer fantasy to hope that these individuals can be successful in building a highly usable product without understanding usability (or any other aspect of quality that’s required for the project).

BlndCat wrote:

Oluseyi wrote (05 Aug 04) :

ESR has the experience and credibility that many of you aspire to

This isn’t a personal attack on ESR but depending on who you ask his level of credibility is between zero and as high as you suggest. His essays have been hit and miss. Personally he reminds me of Jakob Nielsen in that way, some good advice but not all he says is on the money. If you doubt me, I can provide examples but as I said this isn’t meant as a personal attack.

But I full-heartedly agree with you on the incorrectness of some programmer’s attitudes about if you can’t figure it out, it isn’t for you being a major hinderance to success of OSS. (I hope I’m not putting words into your mouth)

Nancy Frishberg wrote:

Catching up on my OKC reading, let me make readers aware of at least 2 other recent presentations that complement the discussion.

In April (at CHI2004), Matthias Müller-Prove, Jiri Mzourek, and Calum Benson (all of Sun Microsystems) spoke about efforts to improve usability of products from 3 specific Open Source software projects. Their presentation is archived at the ACM’s Digital Library (which may require ACM membership for full access), and also at Matthias’ personal site.

Borrowing heavily from their presentation, I added my own slant as the Usability speaker on the Technical panel at the
KMDI Open Source Conference
in Toronto, May 2004. The question posed to me (and to you as a party interested in usability) provokes us with a negative presupposition. Is usability really the major weakness of Open Source software? Promoting a broad definition of usability, I made the claim that whatever lacks in open source software usability one might find can also be pinned on proprietary software, and probably for similar causes. Among the intriguing controversies which became clear in the discussion portion of this panel were:

  • is there “something different” that happens when the user of open source software is also a developer of open source software? Are the examples of Linux, Apache and perhaps a few other projects different from those projects aimed at a non-programmer user? (resonant of the HCI mantra We are not our users, eh?)
  • Are Open Source projects examples of a new development model (Herbsleb’s claim), new business model (my contention, so far), or something else (or nothing new)?

All the presentations from the KMDI conference are available as streaming webcasts in several formats at
http://epresence.tv/website_archived.aspx?dir=May~9-11,~2004:~Open~Source~and~Free~Software:~Concepts,~Controversies~and~Solutions.

Other presentations mentioned the role of specific users in the feedback to Open Source software projects and the business models in rolling the projects out, notably Rishab Ghosh (one of the owners and editors of First Monday); and contributions from other technical professionals such as visual designers, documentation writers, especially David Ascher (of Python fame, currently at Active State). You may find the debate among the legal scholars entertaining, and other presentations informative.

[Yes, I know there is at least one error of fact in my slides, but I don’t think it harms the overall thrust of the discussion.]

phil jones wrote:

I actually think Tom is wrong with this claim :

“Imagine that I were to pose the reverse statement. What if I were to say that usability specialists could do kernel development if they would only spend as little as one single thought on coding each day? Such statements are absurd and indicate a severe lack of understanding of what it takes to do usability (or kernel development) well.”

The fundamental insight of open-source development (and maybe eXtreme / agile methods too) is that you can sometimes trade-off smart, up-front, design for a larger amount of dumber testing. That’s how OSS manages to accrete contributions from a lot of users / testers / fixers. Possibly many kernel developers contribute less than a single “thought” per day. It’s what sets the bazaar apart from the cathedral.

Now the way to improve open-source software UI is not to try to force UI *process*, as developed in companies, onto free-software communities. It won’t work. For social and political reasons.

No, the way to improve free-software UI is to work out how to make the trade-off : from smart UI design to dumber UI testing. And then *distribute* it. I’d say we don’t know how to do it yet. But I don’t think it’s impossible in principle. We might take hope from things like Jakob Nielsen’s point that you only need to test with a few users. Testing can be done in small-doses and still make a difference.

So although “one thought per day” may not be quite right, “one test with a friend or colleague per contributor, per week” might be getting there.

SourceForge has the tools to aggregate the work from distributed coders : it has bug-trackers and CVS repositories. What we need are similar tools to aggregate the war-stories of user-interface problems. A place to post “I showed it to Uncle Bob and he thought that the foo option was going to …” And also for volunteers to post video evidence, or story-boards of new suggestions. If this parallelization can be cracked, then OSS has a fighting chance.

Tom Chi wrote:

That’s a very interesting perspective on it. I think that there are usability issues that can be caught with many small “dumb” tests, but I also think that there design issues that will be very difficult to catch. To draw an analogy to programming, many small tests might catch a bunch of bugs, but even a flood of small bug fixes will not correct a fundamentally flawed architecture.

Similarly, it is possible to have fundamentally flawed architectures in UI design. These might be flawed information architectures and flawed global interaction metaphors, and these things might be hard to catch or correct. Usability specialists are trained to get past the small surface issues (”I don’t like the color blue…” “put that on the left”), and effectively test some of the architecture problems. Interaction designers would then take that data and reformulate.

If you take these two out of the equation, I guess it might still be possible to operate, but the biggest issues might ironically be the hardest to catch and fix.

TuringTest wrote:

One way to help establish some trust and give developers some insight into what it is that usability people actually do, would be to create a full detailed design for a program(s). From start to finish, every detail. Put in the hard work. Choose something not too big, little a backup utility for example, and design and document the whole thing and how it should work. Work out what the use-cases are likely to be. Explain why things should be done a certain way and explain why the alternatives were not chosen. Explain which usability principles are being used.

Jef Raskin did precisely that with The Humane Environment. He is developing a prototipe, also. This book should be publicished to OSS developers.

TuringTest wrote:

One way to help establish some trust and give developers some insight into what it is that usability people actually do, would be to create a full detailed design for a program(s). From start to finish, every detail. Put in the hard work. Choose something not too big, little a backup utility for example, and design and document the whole thing and how it should work. Work out what the use-cases are likely to be. Explain why things should be done a certain way and explain why the alternatives were not chosen. Explain which usability principles are being used.

Jef Raskin did precisely that with The Humane Environment. He is developing a prototipe, also. This book should be publicished to OSS developers, because it promotes a complete system, not just some stand-alone usability rules of thumb.

That’s a very interesting perspective on it. I think that there are usability issues that can be caught with many small “dumb” tests, but I also think that there design issues that will be very difficult to catch. To draw an analogy to programming, many small tests might catch a bunch of bugs, but even a flood of small bug fixes will not correct a fundamentally flawed architecture.

But there’s where another property of open source comes to help: survival of the fittest. Although a flawed design can’t be incrementally solved, the knowledge produced by a bad design can be ported to newly designed programs, to avoid making the same errors; and the best available solutions can be merged into one project (since there is no private property of any given solution). This allows for a fast evolution.

Anonymous wrote:

I would like to suggest something just a little different. Imagine a component included with (not in) OSS projects. The purpose of this applet is to log interaction problems. This gets the ball rolling by identifying a problem users can point to, vote on, even rank.

Is this a great solution? No. Are existing solutions (for onsite recording of users going through a task list in a lab) adequate for remote use? NO. Some important changes will have to be made. However, I believe some kind of data collection on this level to be vital for changing the terms of the argument as made so far.

Tomer Chachamu wrote:

Well, who here has looked through Gnome’s HIG? In my opinion (and I’m a bit of a newbie to usability) it’s a great way to get a consistent look-and-feel with sane labels, a reasonable amount of options, and some plain bright ideas. For example, this is from the text editor upon attempting to close the window, although not verbatim:

Would you like to save your document?

If you press Discard, you will lose about 7 minutes of your changes.

[Discard] [Cancel] [Save]”

…Although it was better worded.

Why is the preview showing up centered? I can’t see how it will look!

Wibble wrote:

Open Source Usability

Article at Newsforge by Frans English has generated some buzz, including this very nice rebuttal at ok-cancel. both are worth reading, in the given order if possible. Frankly, one of the problems of ‘usability’ in open source is, as stated…

WMBT wrote:

A point I would like to make is that if you have a consern with this you can do something about it. Go find a project in need of help and help out. Nothing is stopping you.
Unlike closed source products from Microsoft, Apple and many other players, you can actually enact a change that will matter instead of just ranting about it.
Instead of ranting about someone’s article because you know so much better I’d suggest that you lend a hand.
As for the “usability testing” that takes place real-time with real users every day. And those users are not just “technical” anymore.

This is a matter of “put up or shut up.” Either help the cause or go on your merry way. Nobody is stopping you from doing something about it first hand.

bncuzyruzuzo wrote:

titxoxocasinu

exkoneritewe


Leave a Reply


OK/Cancel is a comic strip collaboration co-written and co-illustrated by Kevin Cheng and Tom Chi. Our subject matter focuses on interfaces, good and bad and the people behind the industry of building interfaces - usability specialists, interaction designers, human-computer interaction (HCI) experts, industrial designers, etc. (Who Links Here) ?