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)"

1 of 327 comments (clear)

  1. Re:No. by dasmegabyte · · Score: 5, Informative

    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.

    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 .NET, I use a lot of User Controls to create "panels" of functionality, thus preserving this principle of design while reproducing the functionality).

    --
    Hey freaks: now you're ju