 |
« | Week of Jun 8 | < | Individual Entries | > | Week of Jun 22 | » |  |
 |
 |
Case Studies in Open Source Usability: KDE and GNOME
processes & methodologies, usability
June 20, 2003, 10:16 PM
I joined the GNOME Usability and KDE Usability mailing lists this week, mostly to lurk and watch the discussion unfold to hopefully gain some insight into what the state of the practice in open source usability is like. Here's my (very) preliminary thoughts. Don't take these comments the wrong way; on the whole I think both projects seem to have an impressive emphasis on usability and are doing great work.
The Good
- There do appear to be people conducting actual user tests on the desktop environments for both projects, and these people are posting their findings to the list. Moreover, the developers appear to listen to them and follow up on their questions and recommendations.
- Both projects have a list of guidelines (GNOME calls them the "HIG", which I assume stands for "Human Interface Guidelines"), and these guidelines actually get mentioned in discussions. There's a discussion going on right now on the GNOME mailing list where the HIG was brought up to reason about why a suggested design decision may not be the best choice (a decision about using Alt keys in a keyboard shortcut, to be specific).
The Not-So-Good
- There seem to be a lot of "let's do it this way because I like it better" type of discussions, where list members are just arguing over personal preferences. So far there haven't been any serious flamefests, but there hasn't been a call for "let's resolve this by collecting some user test data" yet either.
- The people who are doing the user tests come to the list with problems and occasionally suggested solutions, but so far no one has come back with a story like "I user tested this part of KDE, and I found these problems. So I prototyped these suggested fixes and ran my tests again, and the problems disappeared. So I suggest we implement my fixes." HCI practitioners have found that software developers don't want laundry lists of problems, they want to know what exactly they need to implement to make their system more usable. So the HCI person needs to come back not just with problems and a few half-baked ideas, but with solid, tested solutions for the developers to pick up and run with.
- Neither project seems to have a consistent picture of who they are designing for (user profiles) and what these people want to do with their software (task lists). So far, its unclear to me how the user testing people decide what tasks to have their test users perform.
Watching these projects discuss their usability issues is a great experience, and I'd recommend signing up for these lists if you're interested in open source usability. I'll post again after I get a bit more insight from reading the list to see if any of these thoughts change.
Email Rob:
Bipolar Debate Teams
writing & communication
June 19, 2003, 08:08 PM
Dave Thomas, of Pragmatic Programmer fame, has a great idea for a debate format on his weblog. I've always believed it's very important to respect and seriously consider the opinions of people you disagree with, and this format strikes me as a particularly good way to force you to consider all sides of the argument. The constant switching of positions could keep the discussion lighthearted while still forcing you to think about the side of the argument you don't agree with. When your turn comes to hold the opposing position, you have the arguments made by your predecessor to build on, which could make for an interesting discussion.
Some time I should convince a few of my friends to try this out with me.
Email Rob:
Newsable, the Usable News Aggregator
announcements, software development
June 18, 2003, 10:41 PM
At the risk of promoting vaporware, I've opened up the website for Newsable, the open source news aggregator I'm working on, to the public. Right now the only section that has real content is the About section, which describes the goals of the Newsable project and its aspirations towards providing techniques for developing usable open source software.
I've tossed this up so quickly (maybe too quickly; it isn't really ready for prime time yet) because Tristan Louis has started a Yahoo Group on Usability and Open Source called "UsabilityBazaar" and I wanted the project to have something visible to show for itself. The group's formation was picked up by Slashdot and MetaFilter (although I discovered it via Andy), so I'm hoping this early publicity will help turn the group into an interesting place to share ideas.
Email Rob:
Designing Against Frivolity
design, society & sociology
June 17, 2003, 07:51 PM
I happened to hop over to Slashdot today and found a nice polemic over on the Guardian about how frivolous technologies are dominating the market nowdays. The article is full of derisive, quasi-luddite quotes, like The Innovations catalogue exists as proof that there are people with less perception than a wrapped loaf who are inventing things; and more, even dimmer, who are prepared to buy them
and So the fatuous becomes the essential, and we become more decadent, more hungry for diversion and suckered into buying things that will improve our lives negligibly, if at all
, but it raises what I think are some real issues. Most consumer technology nowadays are fairly frivolous, which isn't to say some people aren't working on important scientific and technological advances, it's just that the market is dominated by video phones and other gadgets that are cool for a little while, but ultimately serve no meaningful purpose. But the reason these things keep getting produced is people eat it up.
Personally, I avoid spending money on impulse purchases. I find gadgets like the ones on ThinkGeek as cool as the next nerd, but every time my Id screams "I've got to have this!!" my Superego replies "Yeah, for maybe five minutes. After the novelty of owning a portable lie detector wears off, it will just lie around your apartment and take up space". When I do purchase gadgets, it tends to be in response to some need I've been experiencing for awhile. I didn't purchase my current computer until it was clear my last one wasn't hacking it performance-wise (Netscape took around a minute and a half to get going). I've never owned a cell phone or a PDA even though they've been available for years, but for the past several months I've been having problems remembering meetings, birthdays, etc., and I've been in several situations where I needed to reach or be reached by someone while I was out and about. So I've finally been thinking of getting a phone/pda combo like the Sidekick.
Unfortunately, many people don't seem to be very good at assessing their real needs and distinguishing these from mere passing fancies. Thus, the market is bloated with products that seem glamorous but improve people's lives only marginally if at all. The solution, of course, is to help educate people in how to assess these needs and work to change society to favor long-term improvements in quality of life to short term instant gratification. This isn't to say I don't believe in the importance of designing pleasurable products, I do. But I think there's a difference between products that truly make your life more pleasurable to live and those that serve as temporary curiosities, then just get in the way.
Perhaps, in the short term, designers can help by working for those companies that are producing products that genuinely improve people's quality of life, such as the wind-up radio mentioned in the Guardian article, even if this means working for less pay. In my view, the pay cut would be worth it to know I'm really contributing to the betterment of humanity, and not just pumping out the next fad.
Email Rob:
Natural Programming and Expanding Open Source
design, software development, usability
June 15, 2003, 11:48 AM
Sometimes when I come across something I want to write a weblog entry about but I don't have time to put together the full writeup (these things can take over an hour) I instead jot down a quasi-outline of the post so I can come back to it later. I have a couple of these kicking around right now and I wanted to get them off the table. This one comes from the same discussion with Jim about open source and usability that the efficient interfaces post originated from.
Jim brought up "natural programming" (programming environments designed to be so easy to use that ordinary users can program, if only in a limited domain) as a holy grail of open source usability. If everyday users can program, the reasoning goes, then users can design their own interfaces and feed those designs back into the development base, just as open-source developers do now. This comes from Eric von Hippel’s argument in "The Sources of Innovation" that most innovations come from end-users, not manufacturers. I balked at this, however. In HCI, its commonly accepted that its unwise for an interface designer to take all user suggestions at face value. Users are not designers; they are good at finding problems with the interface, but they tend to come up with point solutions and workarounds that fix these problems in the small but which, overall, contribute to a bloated, unusable, inefficient interface. This is why providing highly customizable interfaces doesn’t solve the usability problem. In "Usability Engineering", Nielsen quotes a study that compared user performance with two interfaces: one was designed by an experienced interface designer, the second the user was allowed to customize in any way he wanted. The study found that users were much more efficient at their tasks with the interface designed by the expert than the one they customized.
On the other hand, as I discussed in my efficient interfaces post, when you have a situation like in open source where the users (the programmers) really are the designers, sometimes superior designs do come out of users’ heads, at least with respect to certain usability goals like expert efficiency. This is certainly in line with the "eat your own dog food" maxim of software development. On the other other hand, many complaints about open source software center around the observation that most of the popular open source interfaces are copied and altered versions of existing commercial tools, rather than truly innovative designs (KDE and Gnome look a lot like Windows, Gaim is pretty similar to AIM, Linux is basically a reimplementation of AT&T’s Unix). Right now, open source interfaces are good at copying commercial interfaces, making them free, and streamlining them (to a certain extent), but not much else as far as usability is concerned.
So would natural programming help to bring users into open source and produce better interfaces, or do expert designers have to participate more to bring their unique knowledge and experience to the table? For my open source and usability project, I’m moving more towards the expert designer route, although I’m still very interested in investigating what the best way to bring average users into the community is. After all, it’s worth remembering that the study Nielsen refers to only measured how productive users were with the interfaces they designed. Historically, usability has been applied to the design of productivity applications almost exclusively. But not all software is for productivity, many software products aim to provide the user with an enjoyable or desirable experience, as Don Norman discussed at CHI. Perhaps interfaces of this variety would benefit from natural programming and high user customizability. After all, if users alter the interface to their tastes, perhaps we can assume they like it better that way. Hopefully the emotion and design people will do some studies looking for correlations between the amount of control a user can exercise over the interface design and the interface's desirability for the user.
In the short term, however, I'm not certain that natural programming is the way to go to solve the open source and usability problem. More on the approach I do plan to take should be coming soon.
Email Rob:
Posted by Rob on June 21, 2003 at 11:51 AM
Correction: KDE does not appear to have a HIG, although they claim to comply with GNOME's HIG in most respects. They haven't written down a formal list of guidelines themselves, however, which could be a problem.
http://dot.kde.org/1055539007/1055544932/1055545303/1055546879/1055593780/1055609915/1055637869/
Posted by Dan on June 26, 2003 at 12:11 AM
I agree that what developers (and business folks) want are answers, but sometimes there isn't time or money or incentive to give them "solid, tested solutions." Sometimes you have to go with your gut, with what you think makes sense for the user. Parts 4 and 6 of Jesse James Garrett's article on information architecture/user experience expresses this better than I can do in a mere comment:
http://www.jjg.net/ia/recon/
Since so much of HCI/interaction design depends on context, not everything (indeed, barely anything) is going to have an off-the-shelf, pretested solution to the problem. As he says in the article, we need "tools for thinking, not secret formulas. Skills, not rules."
Which is also why, as you point out, mailing lists like these (and the infamous SIGIA-L) are difficult as sources of information.
Dan
Posted by Rob on June 26, 2003 at 05:08 PM
It's certainly true that time is often a scarce resource in a business environment. This is _somewhat_ less of a problem in an open source environment, where there aren't really "deadlines" per se and, since there are no bosses and people are working for free, they tend to get around to things when they feel like it. But even with open source there is some time pressure; you have to compete with other open source projects for users as well as commercial products and this often means getting improvements released quickly.
That said, I don't think it's worth abandoning testing unless you have no other choice. Now, by "testing" I don't mean a rigorous, statistically valid academic study, I apologise if that wasn't clear. Running a few informal think-alouds (Nielsen, of course, claims doing five should be enough; Microsoft's RITE method claims even doing one can often be sufficient) will frequently, in my experience, prove invaluable in highlighting the areas that your assumptions about the user were less than accurate.
Even if testing only validates your designs, this is an invaluable tool in resolving the "personal preference" arguments I mentioned in my post. It's hard to argue with data, so having the results of a few think-alouds to back up your design decisions helps sell them to the other team members. And who knows? Maybe testing will turn up issues we didn't take into consideration with our gut reactions.
I agree with you 100% about the "skills, not rules" approach, however. This is why I'm advocating sound _techniques_ and _processes_ for interface design in open source, not a laundry list of follow-me-and-your-interface-will-be-usable rules for the developers. Excellent, usable interface designs, in my view, are created by experienced, talented teams of designers applying sound best-practices based on observations of real-world data. Which is not so different from excellent software implementations, really.