User-centric GUI Design Explained to All

TuringTest writes "The webzine User Instinct carries an article on Usable GUI Design showing that good user interfaces are not beyond the means of free and open software development: 'This article presents five key points of user interface design [...] that any software developer should be able to use.' In related news, The Economist writes against software complexity in an interview to MIT's John Maeda, PhD in interface design. See also OpenUsability, a project for testing user interfaces in a bazaar-like model. The specifics of UI design in Open Source projects has been previously debated on Slashdot."

Comments

Damn you all!

[BenjyD]

Hi, I'm the guy who wrote the article.

Yes, it's hosted on my 256k upstream ADSL line, which is why I said "Use the Coral cache" in all the story postings!

Slashdot would also choose the day when I switch to my back up server (K6-2 233), in order to fix my main server, to post this on the front page. I was wondering why it was making that funny noise when I loaded the Slashdot front page...

Please use the Coral Cache!

Mirrors

[Card]

The Mirrordot version and Google cache are also available.

This is what I do

[localroger]

My job is to write software for industrial controllers. Most of the people who do what I do are not "programmers." We started out as technicians or engineers, and cracked the manual the day a "programmable" device arrived on our bench.

Poor user interface design is the second biggest failure of this kind of software. (The first is failure to plan for failure, but that's a different problem.) The problem isn't that guys like me don't understand how to design a user interface; it's that we don't even think about it because we tend to be thinking in terms of the process or machine rather than the human user.

There are no universal guidelines for how to lay out a user interface. The only sure method is to code it, then try using it and see if it feels natural. Often an interface that "follows the rules" will feel clunky in use, and when that happens you should rewrite it and try again until it is intuitive. When you've gotten it to feel right yourself, you should put it in front of the people who will use it all day long and see how they like it. And you should be willing to rearrange it until they find it natural and intuitive.

One reason those field-programmable controllers have become so popular is that people like me, working in the field, can do this. If a manufacturer builds, say, a batch process controller, it must implement every possible function that any process might ever need. This usually results in a bewildering user interface since most actual processes will only use a fraction of the controller's functions. By writing a custom controller in a programmable device, I can give the user just the controls he needs to do his job.

It used to be a once a month occurrence for us to get a service call along the lines of "our scale is only weighing about half what we put on it," because a user accidentally switched from pounds to kilograms. Newer devices let us turn off modes the end user will never use, and the result is less friction all around.

It goes without saying of course that you put the most-used controls where they are easiest to find and most obvious, you only put controls that are used constantly where they are always visible. You always provide keyboard shortcuts for EVERYTHING. Especially in the workplace, day-in day-out users will learn all those shortcuts, but the temp timer needs the GUI. Both are absolutely necessary. Not putting in keyboard shortcuts is the single biggest screw-up in industrial GUI's I have used.

The art comes in determining what controls are really used most often, and when things like confirmation dialogs shift from being a useful safeguard to an annoyance. I can't begin to count the times when I've installed a relatively simple system only to find that some control I'd buried in a deep menu is used much more often than I'd realized. Usage patterns are often radically different in simulation than they are with a real machine connected to real processes. The job isn't done when you close the build file and put field installation on your calendar; you will almost always have to refactor at least once based on end user feedback. If you don't plan for this and budget for it, it's a big, big mistake.

Re:on the contrary

[chrisbtoo]

The automatic transmission shifter sequence is Park, Reverse, Neutral, Drive, Low, [Lower, [Lowest]]

But the parent was talking about a manual gearbox. Maybe the positioning of those is mandated by US law too, but I've certainly driven manual cars where the reverse gear has been in the top-left (left of 1st) and the bottom-right (below 5th, right of 4th) and, I think, bottom-left (left of 2nd). Additionally, sometimes you have to pull/raise some sort of flangey thing and others you push the entire stick downwards in order to change to reverse.

Plus, there's always the differences between indicators and wipers (sometimes they're switched).

Without doubt, though, the biggest problem that comes through lack of standardisation is the position of the damned fuel tank filler. If I had a dollar for every time I'd had to get out of a rental car to figure out where the hell it is, I'd have... like... $10.