Slashdot Mirror
Jakob Nielsen Talks About Usability in FOSS
dokey writes "In an interview with Builder AU, usability expert Jakob Nielsen gives his opinion of usability in Free and open source software. The article echoed what Jon "Maddog" Hall said earlier this year in a keynote at Linux.conf.au -- "Programmers Are From Mars, Users/Managers/Companies are from Venus". Is it time to pay more attention to end-users?(who aren't geeks)"
Was a great speaker (and signed a friends Tshirt), had the view of someone between a total geek and Bdale, with enough business experience not to make a fool out of himself, but still enough of a hacker to not be out of place.
Any aussie's who havent been to an LCA before I highly recomend it, the next one is on in April 2005 in Canberra.
/* FUCK - The F-word is here so that you can grep for it */
I don't think you understood what the original poster said.
He didn't say, "Usability is for losers. People should learn overly complex interfaces." What he said is that you should separate 'what it does' from 'how it looks.'
Take k3b, for example. People usually say it's the best burner for Linux. I just click on a button to open a project, and then drag the files I want to burn onto a window. Or I can drag songs directly out of my media player, juk. Then I click a burn button and it makes the cd.
But, does k3b implement its own cd burning functionality? No, it uses cdrecord and cdrdao and whatever other command line utilities are out there. People who know what they're doing write the cdr writing stuff, and then the k3b people use those to make a nice interface for it.
Take gift as another example. It runs a file sharing client as a daemon, and then you use various gui programs to interact with the daemon. Don't like KDE? Use the Gnome interface. Or vice versa. Don't like any of the interfaces? Make up some totally new filesharing user interface. But underneath it all is the same piece of code providing the actual functionality, written by people who know how to implement it well.
When functionality and interface are separate, you can choose your interface. People can develop new, better interfaces while preserving the existing functionality, and without having to rewrite it, and you don't force people who aren't good at interface design to make all of the decisions for it.
That's what the original poster was saying. Not "usability doesn't matter."
I've come for the woman, and your head.
I have a plaque on my desk with a series of 9 principles of Object Oriented design that I stole from Bruce Eckel's outstanding Thinking in Patterns with Java. I made the plaque not because I'm a huge fan of OO (which I am), but because many of them are equally useful when designing human interfaces.
.NET, I use a lot of User Controls to create "panels" of functionality, thus preserving this principle of design while reproducing the functionality).
Don't be astonishing. In other words, don't do something in a completely new way and don't spring new concepts onto users without educating them first. I've used many designs that were fantastic after a bit of training (Blender comes to mind) but WITHOUT that training you can't do a damned thing. That's astonishing. That's bad design. That's the reason why Apple mice have only one button and the HI guidelines BEG you not to require contextual menus. And for god's sake, don't use a menu called "Script-Fu" and expect people to know what the fuck it does!
Make common things easy, and rare things possible. In other words, allow people to do what they have to do most often in a clear cut way with minimal interaction. If you have additional options, hide them. They don't have to go far away, but don't sour your main interface for an option 99% of users will never need.
Consistancy The A1 most important thing. If you perform actions with the control key on one screen, and with the alt key on another, you've got a crappy interface. If your program uses drop downs for some things and autofill text boxes for others, you've got a crappy interface. Choose one method for managing each type of relationship, one hotkey for each type of function, lay things out in similar fashions, etc. Using visual inheritance helps.
Law of Demeter (don't talk to strangers) A window should only have power over the information inside it, information passed to it and information it sends back. A Tools window that has a save button is useless.
Subtraction A design is only finished when you can't take anything else away and have it be useful. Get rid of all those bullshit options and useless features, they're just making the app bloated and confusing.
Simplicity before Generality A general purpose app that is not simple is not worth using. I point and laugh when I see interfaces like Novell's terrible management utility. Drilling through a tree where every node does something different with no explanation of what they something does is only good if you charge several grand for certifications on that interface. For everybody else, it sucks.
Reflexivity Don't change more than one variable per control, and don't use more than one control per variable. If you've got a drop down that says "Change Name to Rob and Street to Youngstown," you need two controls.
Independence / orthogonality "Express independent ideas independently," something we can argue about as it sort of breaks the simplicity/generality idea. But the concept is this: if you're editing user information on a screen/tab/etc, there shouldn't be anything about filenames on it. If you do have independent ideas that have to share space (say, addresses with names), separate them with different colours, spaceing, group boxes, whatever, so that users know they are different ideas grouped together.
Once and Only Once I could argue this too...the idea that there should only be a single way of entering or editing data is a sound one, but there are many times where it is more convenient for duplicating data or editing multiple records to use two different interfaces. But the basic idea is sound...and if you do allow more than one entry point, it should only be to make things simpler for users -- and maybe the two interfaces should share code (in
Hey freaks: now you're ju