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

dead already???

[Anonymous Coward]

google's cache right here

Site seems unreachable, so....

[seanfuller]

Usable GUI Design: A Quick Guide for F/OSS Developers

Update: I have read many comments on this article and have written an FAQ responding to some of them
Introduction

The Open Source software world is full of excellent software. High-quality F/OSS software is available for virtually any task a computer user could want to do, from word-processing to web-serving. There is one small problem with much of this huge array of software: it is often far more difficult to use than it could be. Professional UI designers tell us that user interfaces should be the first thing designed when we come to develop an application, and that programmers are incapable of doing this kind of design. They say it can only be done by the professional UI experts; OSS projects don't have access to these kind of people, and therefore can never be truly usable.

This doesn't mean we should just give up on UI design. From the quality of many commercial applications' UIs, having usability experts on staff doesn't guarantee a good interface either. Effort, knowledge and thought by any developer can improve the usability of an application greatly. We may only find a local optimum rather than the global, but even that is a step in the right direction.

After years of struggling with these problems, I thought I would write down a short list of five things that we OSS developers should consider when designing our application's GUI. These are drawn from my experience in using and writing OSS software and my reading of a few very interesting books and web sites on the subject. These works are listed in the references -- they are all excellent reading for any developer interested in usability issues.

I have intentionally only mentioned points here which do not require major amounts of work to implement, and about which there is little controversy. Larger "whole-application" issues are beyond the scope of this article. None of these ideas is new or particularly complex, but their effect can be very great. I should also note here that in several of the examples I use, it is possible to fix the problem by changing the application's settings. I have decided to only consider the default settings: presumably, the defaults represent the developer's idea of the most usable design for their application.

Before I start, I should probably make one more point in order to at least mitigate the flames I will receive: although I may sound quite harsh on some applications below, this is in no way meant as anything but constructive criticism. I use most of these applications every day and they are fantastic pieces of work, the product of years of hard work by dedicated developers. I am merely making suggestions of potential improvements; no offence is intended to anybody.
The Points
0) The user is not using your application

The most basic point in all computer UI design is that the user does not want to use your application. They want to get their work done as quickly and easily as possible, and the application is simply a tool aiding that. The more you can keep your application out of the way of the user, the better. Effort spent on using your application is effort not spent on the work the user is trying to do. Two key quotes from Alan Cooper's second book, About Face 2.0, summarise this very well:

1. "Imagine users as very intelligent but very busy"
2. "No matter how cool your interface is, less of it would be better"

Points 1 to 4 in this article are really just special cases of this rule.
1) Fitt's Law

This is the most basic and well known of UI design laws. It states that the larger and nearer to the mouse pointer an on-screen object is, the easier it is to click on. That's common sense, yet it is often completely ignored in UI design.
Firefox toolbar

Figure 1: Firefox toolbar

Consider, for example, the default Firefox button bar (Figure 1). When web browsing, by far the most common button anyone hits is the Back button. The Back button should therefore

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.

Blame the egg heads

[Anonymous Coward]

"Usable GUI Design showing that good user interfaces are not beyond the means of free and open software development:"

The problem is that open source is dominated by the uber-geeks, and not enough people who specialize in user experience. So obviously, if more GUI specialists got involved in open source, the better the user experience of open source software. (Need I add a "duh" to this?)

Trival widget issues

[bburdette]

I think most of the issues the author raises are pretty minor. Saving a mouse click here or there is convenient, yes, but its trivial compared to real usability issues like how do I use this application without reading a manual? Large, well placed, and convenient buttons are useless if the user doesn't know what to do with them. Having a good help system that explains the purpose of the different elements of an app is essential. There's nothing worse that being stuck in a completely opaque application with no clue as to how to proceed, and the help system has no answers. For me this kind of program is CAD or (at first) the GIMP. For some users this opaque program is mozilla or outlook. From what I've seen these programs don't really cater to the beginning user that well, there's nothing to really explain the basics like what is email, the difference bewteen a browser and the internet, what is a scroll bar, etc.

Which brings me to the topic of widgets. Why can't you help-click on anything in your gui and have it explain itself? One obvious problem with such an elaborate help system like that is that the infrastructure for it is a lot of work to build. Why should I have to explain what a scroll bar is to some noob, I'm trying to write an email client here! That's why the widgets should have help built in to them.

The other thing is that a lot of the author's issues are with widgets, like scroll bars that don't go to the edge of the screen. Like most developers have control over that! 99% of developers will never bother to develop their own scroll bars to get that extra pixel. And if they did, every application would have different widgets, and that would suck too.

All that said, I do like the point about only showing the user what is really needed. Lately as the app I've been working on has grown, the menus and toolbars have begun to look more and more intimidating. Its much better to keep what the user can see down to a small set of frequently used items, and tuck the esoterica away. Otherwise they end up having to ask themselves whether they are supposed to know what every obscure menu item does, and its a lot of work to know what is important and what may be safely ignored. And that's what I want to minimize: the amount of knowledge the user needs to know to get the job done.

on the contrary

[scotty777]

The gas pedal is on the right, and the brake is to its immediate left.

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

Th automatic transmission gear slector must be labled as Park, Reverse, Neutral, Drive, Low ... or with the letters P, N, D, L ...

The car turns toward the right when the stearing wheel is rotated clockwise.

These standardizations are mandated by law, and have been in the USA since the 1960's. Prior to that time, shifters had various orders, and there was lots of discussion about which was best. Accidents happened when folks picked the wrong gear inadvertently. The popular public demands for safety that resulted in mandated seatbelts also resulted in automobile UI standardization of gearshifts...

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.

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:User Interface Design for Programmers

[Jameth]

Fitt's law is not the "most basic ... of UI design". Fitt's law has become unreasonably important because UI designers stopped giving users visual cues about keyboard shortcuts. Even my Dad uses the backspace key rather than the back button! Its so much easier. Mouse gestures will also dramatically change the effect of Fitt's law.

Exactly. Of course, KDE Usability had a big argument about doing exactly that so that people wouldn't have to try so hard to learn short-cut keys.

What was the proposed solution? Place Shortcuts in Tooltips.

So, when you hover over the refresh button, it doesn't say ' Refresh ' it says ' Refresh (F5) '. Imagine that.

So, if you're among the camp that feels that the fact that, over a year after the wishlist item was posted, this still is marked as 'New' and nobody has even attempted to impliment it, vote for bug 67178 and try to convince them that such a minor change could make a world of differnce for the K Desktop Environment's usability quotient.

That's http://bugs.kde.org/show_bug.cgi?id=67178 and click vote and you could help revolutionise the Linux desktop!

more reading on usability theory

[on the 8ball]

Didn't see these sources mentioned in a quick glance through. I recommend them highly as well:

Donald Norman's book The Design of Everyday Things

Jakob Nielsen's articles and newsletters on web design and usability testing:
Useit.com

Both are pretty good.