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

Some of his conclusions i do find valid such as 'red color when search not found' or '1 pixel away click is unpleasant'.

UI Design 101 : Never ever rely on color alone to convey important information to the user.

The red tint can (and does) mean "valid" rather than "wrong" in some parts of the world.

That's probably why Firefox displays a "Phrase not found" label when the searched string is not found.

When web browsing, by far the most common button anyone hits is the Back button. -- Where is it proven this is the 'most common button anyone hits'?

Jakob Nielsen, December 1996, citing "Characterizing Browsing Strategies in the World-Wide Web":

"We have known from some of the earliest studies of user navigation behavior that BACK is the second-most used navigation feature in Web browsers (after the simple "click on a link to follow it" action)."

Had he been a usability expert he would not rely on assumptions. He'd rather rely on at least statistics, but moreover rather on scientific proof.

He's implicitly referring to well-known usability studies. He didn't use footnotes, but it's "A Quick Guide", not a dissertation.

The above paper has a big table of usage frequency. You can see for yourself how many time subjects clicked "Back" (12632) compared to, say, "Reload current" (1507). Mr. Roe distilled the most useful information (back button = popular) for you to use; if he had needed to back up each sentence with a paper full of statistics, his Quick Guide would have been a thick book. Such thick books already exist, and apparently aren't getting read. His goal was to shorten and simplify things so they do get read and used.

If you want thick books full of statistics and user studies, go visit a bookstore or library. A Quick Guide is not A Thick Book.

Lighten up.

December 1996??? That's far too old to be useful anymore. For the record, i've read several more insightful texts about usability such as from Neil Stephenson.

Do you have any evidence that people have stopped clicking on the Back button? I haven't rigged a browser to collect sample data but from watching people use web browsers it certainly seems true.

If you have studies showing that the Back button isn't used very much today (for some strange reason), please cite them. I'm sure those of us who are usability professionals would appreciate reading them.

It is ugly, but antialiased.

I don't think that is his point. He wants something like

bdr@arthurdent: /home
bdr@arthurdent: /home

to become

b@a: /.../SiEd/source
b@a: /.../research/tex

Grouping in contrast is counter productive. It makes it impossible to distinguish something because windows are removed from the taskbar. It is neccessary for a large amount of windows, but not for long window titles.

does just that! (take a look on the window list menu)

when there is limited space that is where the lovely window selector applet really shines, or even when there isn't limited space, taskbars are ugly space wasting things.

Except that you are required to click on it once just to know what you can select. A taskbar indicates all the options without the user having to click on anything.

That only becomes a problem when you don't know what windows you have open. A non grouped taskbar indicates all the options, but you end up having to group items or you simply can't show all the opened windows due to lack of space, then you have to click to be able to see which windows are included in that group, you may not want to raise all of them for instance.

Had all of the points been common sense to everyone, we would not have usability problems with our applications any more. The examples used in the article clearly illustrates the problem. Although the article uses open source programs as examples, proprietary program have just as many problems (Despite having many UI experts, IE 6 is a lot more confusing interface-wise compared to firefox. ex. more than five buttons on the toolbar, location bar and toolbar on separate lines etc. IE in Longhorn improved this by enlarging the back button)

Note that the author (nor did the Gnome HIG) did not suggest that programmers should follow the suggestions word by word. These are intended to be suggestions and they should by applied only when they make sense. Certain programs might not want to follow certain points outlined by the HIG because of functional complexity/historical reasons (ex. the gimp probably will not follow the HIG due to the fact that a lot of its users are former photoshop users)

As far as the suggestions goes, they make sense for the most part (even the 1 pixel problem is a valid point and for those who never use the maximize function: does it matter if you scrollbar is 1 pixel or 0 pixel from the border of the window?) The author suggested to dump the word not found popup, however, I think the find dialogue itself is a nuisance as well and should be replaced by a find toolbar similar to the one found on firefox and similar popup and dialogue clean up should be conduct through out gnome. This would make the user's work environment more smooth and streamlined and lessens amount of interruptions.

the gimp probably will not follow the HIG due to the fact that a lot of its users are former photoshop users

Maybe its users are, but not its developers, and one doesn't necessarily drive the other. The keyboard shortcuts are all different, the placement of the tools is different (and makes much less sense to me), it's missing gobs of simple features that Photoshop has had for ages ...

I use Gimp every day, but we should be so lucky as for it to turn into a Photoshp clone. :-)

> even the 1 pixel problem is a valid point and for those who never use
> the maximize function: does it matter if you scrollbar is 1 pixel or 0
> pixel from the border of the window?

Yes, it does. The edge of the window is a handle for resizing. With a zero-width area, you can't resize anymore. And even with a one-pixel edge it is difficult (especially with a trackpad) to hit it exactly and grab it for resizing. Ideally, the border should be at least two pixels wide on a lower resolution screen, and upwards of five or six on a high-res one.

Its about the one pixel border between the scrollbar and the windowborder, the latter always being as large as the windowmanager wants and used for resizing. But when you maximise the window, the windowborder is 0 pixels wide, and just the unneccesars one pixel border between scrollbar and windowborder prevents the user from scrolling when the cursor is at the edge of the screen.

Fortunately sawfish allows to resize a maximized window and I use this a lot. I would certainly miss this feature.

You can always alt-right click to resize a window in most window managers (Metacity excluded). In the same way that alt-left click moves the window.

You can resize windows in Metacity with Alt+Middle mouse button.

the gimp probably will not follow the HIG due to the fact that a lot of its users are former photoshop users

GIMP 2.2, which is about to be released any day now, is following a lot of the HIG suggestions. Why should former Photoshop users not be interested in a well-designed user interface?

Wow, yes a good question... a former boss once said to me that photoshop had "the best user interface ever" in fact was so insistant that he crowbarred it into a conversation the day after a conversation about the gimp. The worrying thing about ex-photoshop (and current) users is they all think photoshop is easy to use... which it is (if you already know how to use it.) I find photoshop not really intuitive at all, whereas I find the gimp much easier, I get the feeling it's more intuitive, but then maybe thats just because I've used it more?
The thing is, most photoshop users are never going to be happy with the gimp until it turns into a photoshop clone, they see the similarities and wish it could be the same...

There is one big difference, which is part of the OPENSTEP behaviour: When Photoshop is inactive, all the tool windows in Photoshop disappear from view. It helps greatly to reduce clutter on the screen when switching away from Photoshop. The cool part is that when Photoshop is inactive (at least on MacOSX), you only see its icon in the dock, no where else. You can drop images on it, and they'll load. Right click on it to quit Photoshop. Make it active and all the tool windows pop up. Make it inactive and the tool windows disappear.

It's wonderful and elegant.

You can see this behaviour in many OPENSTEP compliant programs, if you try GNUStep.

Windows don't normally do this with apps, which is why Photoshop for Windows uses an MDI interface. That's the "Windows way" of handling multiple windows. It's less elegant, because I can't directly access the desktop to grab images and throw them into Photoshop, but it sure is much less annoying than the Gimp way.

Gimp just sits there in the background when inactive and adds a ton of clutter to the display, because none of the tool windows interact with eachother. There's no consistency in how the windows relate to eachother, so if a tool window is active, some hotkeys aren't working, I can't drop images on it, I can't automatically see the main window. It gets confusing as to what really is the "entry point" of Gimp. Where do I drop images to load them? I need to mess around and dig to find the main window. It's highly annoying.

The fact that you can put tool windows in tabs is not a sufficient solution, because you need to put an effort into arranging Gimp windows by dragging them to the tabs. You never need to do that in Photoshop or in OPENSTEP like programs.

I really wish better multi window handling is added to Gnome (or metacity?) at some point for those apps which have more than one window to make them behave more like OPENSTEP apps.

>The cool part is that when Photoshop is inactive (at least on MacOSX),
>you only see its icon in the dock, no where else. You can drop
>images on it, and they'll load.

Imagine you want to drap and drop an image as a new layer inside an existing image, and not open it as a new image. How can you do that ?

Imagine you want to drap and drop an image as a new layer inside an existing image, and not open it as a new image. How can you do that ?

It seems this isn't possible, and you're right, this is one of the areas where Gimp is ahead of Photoshop. Pretty funny, considering how useful that is and how complete drag'n'drop is in OSX. :-)

Also I think I left out a detail in my previous post. When Photoshop is inactive, images are still visible, it's just the toolbars that go away. It's only invisible when no images are open.

When you click an image, Photoshop goes active and toolbars pop up again.

You can minimize each image to the dock, but that doesn't help.

But, if the action you suggest did work, here's how I imagine it would work:

1. Click the Photoshop icon to activate Photoshop.
2. Press the hotkey to clear the desktop temporarily (default F11)
3. Grab the image you want and hold the left mouse key
4. If you have a lot of images open, press F10 to activate Exposé within an application. This way you can see all open images.
5. Move the mouse over the image you want, let it be highlighted. Press space or wait for the blink which deactivated Exposé. The image window goes active and comes to front.
6. Drop the image.
7. New layer created.

In steps 6 and 7, Photoshop would interact with the OS. The rest is mostly handled by OSX itself. The really nice part is that I can drag something and still use the keyboard to manage window placement to find the window I want to drop it in. That's really nice. As far as I can tell here, the keyboard is locked to detect only modifier keys while dragging something in Gnome. I tried grabbing a desktop icon and clearing the desktop of windows. Didn't work. :-(

Playing around with Gnome a bit, it's probably Metacity or X which should have an extra layer of window control. I don't know if such child windows are possible with Metacity, but they would allow such control and they shouldn't appear in the taskbar.
I think it would really add great amounts of window control and reduce clutter in the taskbar for applications in general.

Observing multiple windows open in Photoshop, it seems that you can have multiple main windows without specific children or more accurately a shared set of children. To do that in Gimp, we'd need all tool windows to be of a "child" type and all images to be of a "main" type. I'd imagine that changing this would be trivial in Gimp, if Metacity/X supported it.

One more difference is that Gimp relies on a main window where Photoshop doesn't. It relies on the menu bar at the top of the screen, and the dock icon in the bottom. These points are entry points to use Photoshop.

It makes using Photoshop easier to use, because there is only one set of menus, where Gimp uses one set for its main window and another in an image window.

It's a terrible kludge but you should one day try pressing Tab with the focus in the GIMP image window. It hides all GIMP windows except the active image and the toolbar. The next time you press Tab, the toolbox goes away as well. Pressing Tab again brings all the GIMP windows back on screen. IIRC, this has been around since GIMP 1.2 and it is mentioned in the startup tips. It has some annoying focus issues though and could probably be done better.

You hit the nail my friend, congratulations. I was just going to type the words you typed. In short, Gimp needs to have only one window in taskbar, never loose focus out of image window, remove menu from toolbox, organize tools in toolbox into different categories ("click and hold to select others" type of). Oh wait, has I just explained the look and feel of Photoshop on windows?

I really wish gimp guys best of luck, they have lots of work to do.

All hotkeys work in dialogs in Gimp 2.2

All hotkeys work in dialogs in Gimp 2.2

Playing with it now, and it's a definite improvement over 2.0. :-)

There is still the issue of having to dig through to the main window to access Gimps main preferences, extensions and things like that.

Another issue, is that the main window is resizable. This is a bit unfortunate since the tool icons get rearranged automatically in different setups. This makes it difficult to find an icon where I mostly rely on it's position rather than its appearance.

This is a pretty basic GUI law that is broken here: Never Move Tool Icons Around Without The User's Consent.

This doesn't happen in Photoshop and never in OSX.

"Another issue, is that the main window is resizable. This is a bit unfortunate since the tool icons get rearranged automatically in different setups. This makes it difficult to find an icon where I mostly rely on it's position rather than its appearance.

This is a pretty basic GUI law that is broken here: Never Move Tool Icons Around Without The User's Consent.

This doesn't happen in Photoshop and never in OSX."

Is this a kind of joke?!!?

Please consider that you are never forced to resize the toolbox window. So do not resize it... and the tool icons will never move. The resizing is a way to control the interface. It is indeed a feature that is in Gimp and that Photoshop or OS X do not have. A feature!

Please consider that you are never forced to resize the toolbox window. So do not resize it... and the tool icons will never move. The resizing is a way to control the interface. It is indeed a feature that is in Gimp and that Photoshop or OS X do not have. A feature!

I find myself often resizing the main window because the tool box below the color choosers never fit in the window width-wise. That's ok, but the annoying part is that the icons in that same window move around.

Of course it's nice to be able to resize a toolbox to your needs, but Gimp is one of the very few drawing programs I've tried where you can do this trick and have the icons move around like that.

The following drawing programs do not allow this:

Photoshop (MacOSX, Windows)
Deluxe Paint (Amiga, Windows)
Personal Paint (Amiga)
Brilliance (Amiga)
Inkscape
Adobe Illustrator (MacOSX, Windows)
Artgem (Windows)
MS Paint, yes, that one too (Windows)
XFig
Sodipodi
Art Effect (Amiga)
TV Paint (Amiga, Video Toaster)

I would like to investigate this with Paint Shop Pro (Windows), and I can't remember if it allows this.

In my opinion, you shouldn't be allowed to do this, because you are now relying on the appearance of the icons rather than their position, by the simple operation of a window resize. This resize may occur due to changing font settings on your system, or icon sizes in the toolbox.

You shouldn't be allowed to rearrange the keys on your cellphone either. It's a stupid analogy in the physical vs. GUI sense, I know, but imagine the difficulties you'd have in operating your cellphone if the number of rows and columns changed once in a while and your keys got rearranged. The only fixed key would be the one in the upper left corner. Using remotes, cellphones and many other handheld devices with more than 4 buttons depend on key positions more than key appearance. Same thing with an icon panel in a GUI.

Again, I'm playing around with Gimp, and I found a solution: Don't use the toolbox attachment bar at the bottom of the main window. Have that in a separate window.

I think certain features of Gimp are working against each other, and there is basically too much window handling necessary to make it work properly. The fancy tabs system wouldn't have been necessary in the first place, had there been proper tool window handling. (This is of course not necessarily Gimps fault!)

A solution would be to have the icons in a separate, unresizable window, but it adds to the already big mess that Gimp makes through the lack of proper tool window handling.

There's a lot of work to do. Basically a total revamp of the interface would be nice to see for Gimp 3. :-)

Things I'd like to see:

- A single menu instead of two
- Resizable previews, so I can get bigger than stamp sized previews like in Gimp 2.2.
- Paint brush tool box window where you don't have to create new brushes using another complex tool box window to have one bigger than 19x19 pixels (why can't I edit existing brushes?)
- Get rid of layer boundaries, or make them a secondary feature. They create only additional work in the hassle of resizing them. Are there any practical uses for these?
- Some dialogs are oddly blocking the rest of the program. If I want to change the color properties of the image, I have to first select the Hue/Lightness/Saturation and then click an image, before the dialog appears. Very confusing. Also I can't draw or select anything at the same time. I have to select the draw function, draw, then select a color property dialog, adjust, go back to draw function where the color property dialog now disappears. That's plain stupid. :-)

Oh, well. This post is getting long. :-)
-

Some dialogs are oddly blocking the rest of the program. If I want to change the color properties of the image, I have to first select the Hue/Lightness/Saturation and then click an image, before the dialog appears. Very confusing. Also I can't draw or select anything at the same time. I have to select the draw function, draw, then select a color property dialog, adjust, go back to draw function where the color property dialog now disappears. That's plain stupid. :-)

Yes, it is confusing that Color corrections are implemented as tools (and of course there's always only one tool active). But then it's exactly like this in Photoshop as well so there is probably a good reason for it. I suggest you not put these tools into the toolbox but call them from the Layer->Colors menu. The dialog does directly popup then. That's the default behaviour, your toolbox setup is somewhat broken and you should only change such things if you know what you are doing.

Yes, it is confusing that Color corrections are implemented as tools (and of course there's always only one tool active). But then it's exactly like this in Photoshop as well so there is probably a good reason for it.

The difference is that in Photoshop, it's not a tool that you use on the image, but it's more an "accessory function". That means the tool you are using, stays. If your tool is the eraser, it stays that way when you close the color adjustment window. I think that's more the issue.

I suggest you not put these tools into the toolbox but call them from the Layer->Colors menu. The dialog does directly popup then. That's the default behaviour, your toolbox setup is somewhat broken and you should only change such things if you know what you are doing.

I am using a completely default setup on the second preview of Gimp 2.2. I'll have to test this more when I get home, but why are color adjustment tools available in two different ways like that?

But having the color adjustment tools (or any other such tool) open all the time would be nice, as I can lasso select, adjust, lasso select, adjust, lasso select, adjust much faster and easier. This would be even better than what Photoshop does. :-)

That's also one of the niceties of OPENSTEP programs. If I use a text editor and want to change fonts in several places in the document, I can have an advanced free floating font palette available with nice big font previews, select text, select a font, select text, select a font, etc. without opening and closing dialogs or having to select from a tiny, crummy toolbar with font names above the document.
It's also non-blocking, so I can have a color palette open next to the font palette and use them freely.

When I make the program inactive, the font dialog disappears from view. So nice. :-)

I don't know what you are doing wrong then. If you select the Color adjustment tools from the menu, the tool dialog immidiately appears. Why would you have to click into the image window first?

I suggest you start using the Colors dockable. You are obviously still struggling with that color selection dialog for no good reason. I also cannot reproduce your problems with the color adjustments. You select them from the menu, the dialog pops up. Why would you have to click into the image window?

You can configure preview sizes. I am not really sure what previews you are talking about but they are all configurable.

Example is the IWarp plugin. I have a very small window to work with, which can't be moved or zoomed and is dependent on what is selected in the image. When I resize the IWarp window, I get a lot of useless space. It would be nice to see it adapt the preview to the size of the window.

Looking at it closely, previews are actually working OK in 2.2 in most other plugins. I'll withdraw this criticism. :-)

It would be nice to zoom the preview and allow the preview to take up the entire tool window. It's square now, but it'd be nice to fill out the window when you resize it up.

Once again one of these "know-it-all-with-big-monitor-types" who always ignore the actual law and say "I never maximize windows so corners are stupid".

As the article states, the law is that the bigger and closer it is, the easier target it is to hit. The corner thing is just the optimal case, and a good way to get people to think "gee, I think that is correct!".

And for the common sense comment, a huge amount of software developers seem to have none, if what you say is true.
(I would say "just look at KDE" here, but that would be mean)

--
Kalle Vahlman, zuh@iki.fi

The corner is by definition the point that is the most far away from your mouse. Probably not a good location for a frequently used button then.

The corner may be "far away" but it is infinitely big.

Move your mouse up and to the right three inches. It'll probably be in the upper right corner. Now recenter the pointer and move your mouse up and to the right six inches. Where is it? The upper right corner. Recenter and move your mouse up and to the right thirteen feet. Upper right corner! Forty yards? Upper right corner. Ten miles? Upper right corner. When n > 3", l = upper right corner.

The corners (and the edges, too) are infinitely large. And an infinitely large target will always be easier to hit than a finite one.

"The rest of the article is really just common sense, nothing more. Certainly nothing new to any application developer out there."

Which explains why applications with modal dialogs are so rare, right? And God knows nobody ever makes poor color choices in their user interface, or produces a UI where seldom-used buttons are given the same size and importance as the important ones users click on hundreds of times a day.

Certainly, since this is all common sense and nothing new to any developer, an application as extensively peer-reviewed as Mozilla Firefox wouldn't be released with the Back and Forward buttons being exactly the same size. The modal dialog in gedit might survive all the way to GNOME 1.2 (I mean, it's a big environment and most people don't use the built-in text editor) but there's no way it'd still be acting like that once we got to version 2.8 or thereabouts. That'd be lunacy!

No, the reason this article is so annoying is that the best evidence on hand -- the actual software that's being produced -- proves none of these things are common sense. This isn't preaching to the choir. To do that, you have to have people actually inside the church.

If Firefox would actually have a Back button that looked as silly as the one in the example given in this article, it certainly wouldn't be a threat to IE.

Come one, have a look at it. Almost everyone can hit a button the size of Firefox's Back button w/o risking to hit the button next to it. There is no point in making it twice as large as it is. All that would do is disturbing the visual appearance of the toolbar. The buttons should be on a fixed grid and all icons should be of the same size. That gives a nice and pleasant look and feel. Scaling the buttons by probably of them being hit would look silly, it would make it difficult to understand the toolbar metapher and it would make it hard to hit the seldomly used buttons.

>The buttons should be on a fixed grid and all icons should be of the same size.

Have a look at the bookmarks in the bookmarks toolbar in Firefox... because they have labels of very different size, they must be of different size!

I can give you another example of why you certainly DO NOT want buttons in a toolbar to have same size if they contain text, especially localised. Screem, the HTML editor is a wonderful example for this. I have a 19 inch monitor with some quite big resolution (1280x1024). Because screem imposes that all buttons are of the same size in its toolbar and I am using a localisation where one of the labels is long, Screem toolbar only can display five icons these 1280 pixels! So I use Bluefish.

I said "almost" because I know that not everyone is that versatile with the mouse. But if you can't safely hit the Back button, you will also have problems hitting the other buttons. Making the Back button larger would solve it only for one of the buttons. Fortunately though Firefox is themable and people suffering from such accessibility problems can install a theme with large buttons. AFAIK even the default themes come with two button sizes.

Actually, I don't use the Back button at all. There's a right-click menu that can be reached w/o moving the mouse at all. It comes up with the Back button right next to the mouse pointer. Now that's what I call good UI design. And of course there's Alt-Left and Alt-Right which is even better for navigating back and forth. Firefox is best used with the keyboard anyway.