- Declaration of interests
- On style
- The main tool bar
- The main file menu
- Brush selection dialog
- Pattern dialog
- Palette dialog
- dialog
- Layers and channels
- dialog
- The Xtns menu
- The 'big right click on the image' menu
- Lessons Learned
- What we do?
- The End
An interface critique of The Gimp
Declaration of interests
These are some things to bear in mind when reading this:
- This is a critique. It aims to criticise. There are many things The Gimp does very
well, that are not addressed here, because I am looking for faults. In the section at
the end I come up with some ideas for general improvements. I am willing to come up with many more, but that is another stage of the UI design process.
- This is not comprehensive. Some things I look at in detail, others at a conceptual
level, and in neither case do I cover all aspects of The Gimp.
- Because of the scope of this work, I haven't gone into much discussion as to why I think
something should be a particular way. I will try to do this either as an addendum to this
document, or else in another medium such as a mailing list.
- In keeping with the point above, I make no hesitation to copy ideas from other
programs, in particular Photoshop, which I used daily for a long time.
- I have no qualification to write this, other than that I care enough to have written
it. I spent at least a year in a graphic design company doing donkey work - taking
templates and screens created by graphic designers and replicating the look and feel for
various different formats. It was dull, and not very creative, but it taught be alot
about the difference between a good and bad interface.
- Many of the points I raise are criticisms of GTK, or possibly even X itself.
- I don't expect anyone to fix any of these. This is a critque not a bug report
or a wish list.
- This was done with:
- Gimp compiled from whatever was in CVS on 14th August 1999
- Likewise for GTK, glib etc.
- Suse Linux 6.1 running the Afterstep window manager.
- 15" Sony Trinitron monitor running at 1024x768x24bit with a Matrox Millenium card
On style
Generally speaking, I only criticise something once, the first time I come across it. For instance,
I think the widget for drop down menus is flawed, but I don't repeat that for every dialog that
has a drop down menu!
I start with a critique of the main dialogues and menus. After that I highlight some of
the recurring themes. After that I talk about some conceptual flaws. Finally I make
some suggestions.
By menu subsection I refer to a part of a menu separated by a horizontal rule on the menu.
By submenu I refer to a menu that pulls out from another menu, usually indicated with a right-arrow on the parent menu.
The main tool bar
So far so good, but some things to think about:
- No tool tips to explain what the pattern an brush selector are.
- Right clicking on a tool icon gives it a dark highlight, but doesn't seem to do
anything. Confusing.
Although I don't think it is necessary yet, bear in mind the photoshop ctrl-click
technique of stacking tools. By ctrl-clicking on the select tool, you would rotate
through rectangular select, ellipitical select, lasso select. This lets you group
tools in related stacks, and cuts down on screen space needed. An alternative to the
rotation is a mini pullout menu for each tool button, but that may be hard to implement.
The main file menu
There are two file menus in Gimp, with differing contents. This is very bad.
- This is an important menu. 'About...' and 'Tip of the day' are not important items.
Both of these should go at the bottom of the Xtns menu.
- There is neither a save nor a save as option in the file menu. This is very bad.
One expects to be able to save files. Perhaps this menu would be better renamed to
Something like 'main' or even 'gimp', if it is intended to simply be a list of commands
that people are likely to use near the beginning of their session.
New file dialog
The information displayed here is fine and well layed out, but there are widget cockups...
- At first appearance, the dialog seems to have the cancel button highlighted as the
default action. This is wrong for a start, because OK should be the default option. It's broken
a second time though, because hitting return doesn't perform the highlighted option.
Since people can set defaults for this dialogue in preferences, it makes sense to have a
quick way of creating a new image, by simply doing 'ctrl+N' (bring up the dialog) followed by 'Enter'
(accept it all).
- I've never understood why dropdowns (in this case for the units) have large rectangles as handles.
They should have downward arrows, and smaller ones at that.
- When you drop down to the 'More...' option on one of these you are presented with
a menu box.
- Close is the default. It shouldn't be, 'Select' should be the default.
- double clicking an item should select that item and close the menu
- 'Select' should be labelled 'OK'. It's obvious what's going on here. It should
be the default.
Open file dialogue
This dialogue is over large, I think, and small graphical icons should replace the 'create dir'
'delete file' 'rename file' buttons. These icons should have tooltips that give the full text.
The directory drop down should be left aligned, so it is over the directory window. Very
rarely should anything in a dialog box be centre aligned.
Preferences
First of all, a global preferences is a fundamentally good idea. I think there are
severla items that should be in here rather than in other dialogues. I will mention
them as I come across them.
- 'Cancel' as default makes much more sense here, because people are likely to be
browsing this in a 'read only' mode, where changes they make could be accidental.
- Having 'OK' and 'save' is very confusing. There should only be 'OK' and it should save preferences.
Failing that, have a 'save' and 'save as defaults'.
Dialogs Menu
Contents and ordering of this menu are fine. However, this whole menu is in the wrong place, it should not be available here, only from the place where the other (similar) dialogs menu is. Hmm.
- The best widget for this is the one where there are
checkboxes next to each menu item. Selecting the menu lets you see what is on and off. Selecting
and item toggles it either on or off. This should be a tear off menu.
- The current approach makes it hard to turn on several dialogues at once. This is
worked around by assigning hotkeys, but that is a complete waste of hotkeys. It is silly
to assign a hotkey to a submenu (which is conceptually what a dialog is).
- The tool options dialog should be toggled by double clicking on a tool icon in the main toolbar.
- None of the dialogues should have the 'close reset' buttons, since they take up far
too much space. The dialogues are separate windows, so they can be closed with the window managers
own widgets at the top. The dialogs are not complex enough to merit a 'reset' button.
Brush selection dialog
Fine. Remove close button (see last point above). If refresh is really needed put it on
the same line as 'edit brush' and 'new brush' to save vertical space.
Pattern dialog
Fine.
Palette dialog
Yuck :-)
This is a key part of the UI. Once a project is underway, it's palette is the main
colour selection tool (rather than the universal colour selector). It needs to be onscreen
and visinle 100% of the time. This means it needs to be MUCH smaller. Ideally the window
managers widgets would be removed and replaced by something smaller:

Here, The magnify buttons are not needed, because the palette square will auto-magnify to
fill the window size available. The window does not have scroll bars on because they
are a waste of space. I have never seen anyone work with a palette larger than 255 colours,
and that's just the netscape palette, usually a palette will be just a dozen or so
colours.
|  What it currently looks like :( |
Probably, the two tabs at the top should be replaced with a small button for 'select' that
brings up a seperate pop up selection window.
More importantly, double clicking should bring up the edit function automatically
Even better, shift or ctrl clicking should select that colour as the background colour,
which is what Pshop does.
Gradients dialog
Double clicking a gradient should have the same effect as selecting it and pressing 'edit'
Layers and channels
This is a biggie! It's the most important dialog, IMHO.
- This dialogue is FAR too big. It must be smaller.
- The image selector should be removed, as should the auto button. This dialogue should
obviously have the 'auto' behaviour and no other. Having the image selector here is as silly as having
a drop down on the 'tool options' dialog with all the tools on it. It is obvious that
these dialogs are context sensitive.
- Failing that, remove the preview from the image dropdown, as it is a waste of space,
and remove the 'auto button' and put that into global preferences.
- Get rid of the close button at the bottom - user can use their window manager tools
for this.
- Drag and drop layer ordering is good, but if it is here it needs to be extended to the
buttons below the layer list. The trash can should be a DnD receiver, not a button. Delete
layers by dragging them onto the trash can.
- get rid of the up and down ordering arrows, they take up space and users can use
DnD for ordering.
- make all the buttons on the bottom far smaller. Add color to make them distinctive
in their new smaller size.
- reduce the size of the eye and cross icons next to each layer, this will alloy each
layer entry to take up less space.
- Get rid of the horizontal scrollbar. If people have layers with long names and they want to read them, they can resize the whole dialog to something wider.
- On the right click menu for each layer, the items are in the wrong order...
- First of all, since this is a right click menu it should be context sensitive only, and it has global
options in like 'merge visible'. This is OK I guess since it saves space, but..
- options specific to that layer should come first, global options lower on the menu after a line rule
- get rid of the stack submenu its over complicated. It CERTAINLY should not have pride of place on the menu.
- I would suggest something like:
New layer
Raise layer
Lower layer
layer to top
layer to bottom
---------
duplicate
delete
merge down
flatten image
---------
Add layer mask
(rest of this menu...)

Here's what it should look like :)
|

Here's what it currently looks like :(
|
Tool options dialog
No complaints here, although remove the close and reset buttons as said before.
The Xtns menu
The biggest problem here is that this menu really contains a motley collection of
bits and pieces, but it is placed to as to be the second most important menu in
the application. Most of this menu should be in submenus somewhere else.
- First off, technology is no way to categorise at such a high level, so things
like 'perl' and 'script-fu' really shouldn't be seen.
- In the script-fu submenu, the console, server, and refresh options aren't the most
important ones, and should not be at the top.
- Really, this is a leftover soup menu, so I don't want to spend too much time on it.
The 'big right click on the image' menu
Hmmm. Well the title to this section may be a good place to start. This is, apparently
the key menu for the application, yet it has no name, is bound to the lesser mouse
button, and is context sensitive. It's so full of contradictions.
It's method of invocation is unexcusable. The canvas is what the user is working on, it is
their primary concern. Nothing, with the exception of the pointer and some tool graphics (ants, crop handles etc)
should ever obscure it. To have this blasted great menu appear right across the middle of my work
all the time is a liability.
Imagine an artist in front of their canvas. Imagine you are painting. Now, you have some tools, like a jar of turps,
a palette, some brushes and knives in a pot, a sponge, and so on. Think where the best place for these tools would be:
On a table placed inbetween the easel and you.?
On a wooden shelf at eye height that you had to pull across between the easel and you
when you wanted to get something?
Attached to a sort of rollerblind that comes down from the top of the easel?
Hmmm. How about on a table to one side of you, so that to get a new brush you had to
turn your head and body to one side?
Do you see why I think this menu is placed sinfully? OK, we can bring sanity to the
world by tearing the menu off, whereupon we discover it DOES have a name after all ;-)
But think of all the better things rick click could be doing than bringing this thing
up right where you don't want it, across your artwork?
This raises an issue though - if you have several images open, it's very hard to tell which one
is active. This stems from the fact that Gimp is multi-window, unlike Pshop which is single window (and then
has its own mini-window manager to handle all the things like dialog boxes, multiple images etc.
Something needs to be done about this, all though I'm not sure what.
File menu
- As mentioned at the beginning having two file menus with different contents is a crime.
This is the better designed of the two, so I'd keep this one.
- Mail image doesn't belong here. It should go in some misc. section, it is hardly
a core file operation - seems like a feature someone stuck in when they were bored.
- The Pshop 'save a copy' option is useful, it saves the image under a new name, but
lets you carry on working under the old name, so subsequent 'save' operations DONT affect
the file that was generated by 'save a copy'. This is like a sort of backup or hard undo point,
and it is very reassuring to do this every so often.
- Preferences... should probably be in the subsection lower down with print, or else
in its own subsection before close and quit. Better not to pollute the file manipulation
options with the preferences... choice.
Edit menu
- First subsection is fine
- Clear is broken, because it clears the whole image even when nothing is selected.
- Fill should not be here. The fill tool does that. The menus are quite crowded enough
with stuff that has to be there, without adding shortcuts to tools just becuase it kind of
fits in. Filling the current selection requires one key press to select fill followed by one click.
What is the point in having this in a menu that requires right click, move down, move right, left click?
- Stroke doesn't belong in here, it belongs in the select menu, where Pshop has it. Stroke operates on 'the selection boundary' rather than 'the selected area' so it makes more sense in there.
Select Menu
- The functions don't grey out when there is no selection. They should.
- The 'by colour' options should be a tool. Oh look it is. So get rid of it in the
menu :) The extra panel that opens up allowing you to set fuzzines and mode and to show
you what is currently selected is great, but this should be the tool dialogue for the select by colour (aka magic wand) tool.
- Select triangle will do for now, but it should be incorporated as a tool, where it can
live under the regular square selection tool (see top of document for explanation on how to stack tools ala Pshop)
- Assuming that sharpen is the opposite of feather, call it un-feather. Sharpen is too strongly associated with the 'unsharp mask' type of filter.
- Add stroke to this menu, underneath border. Stroke should launch a dialog asking for how many pixels, and weather to stroke on the inside, outside or centre of the marquee.
View
This is a mess....
- Zoom in and Zoom out are tool replication, and should be omitted
- Zoom -> to a particular ratio is a genuine use, so it is OK.
- I have no idea what dot for dot does, although turning it off sure screwed things up. Ummm...
- The Window Info and Window Nav panes are a very different kind of 'view' function than the zoom, and should be in a separate subsection of the menu.
- I couldn't work out what Window Nav did, but hey...
- The toggle stuff is great, but it's annoying that each time you toggle one, the whole menu collapses back down. I guess this is a GTK thing, but when you have checkbox items like this, the menu shouldn't collapse after selecting.
- Toggle selection should be in the select menu, not here. Also, it MUST have a hotkey that can be done with only the left hand, which it barely does. It needs this, because it is used so often while positioning with the mouse with the other hand.
- New view is very confusing. At first it seems like a clone window where changes to one are mirrored on the other. But after a few 'save' and 'save as' operations, you
can get a situation where edits to one window do not affect the other, yet both windows write to the same file when a 'save' operation is performed. Ick!
- I can't work out what shrink wrap does, but I guess that could easily be my fault :)
- 3D surface may be fun, but it sure doesn't belong in here. Somewhere in some plugin menu...
Image
OK, well, first let me take this opportunity to point out that IF, IF, _IF_ it made any sense to
have a menu that is bound to a right click on the image, this submenu is the only one that would make sense. But we've already
discovered such a binding is all wrong with a capital WR, so that's OK.
- The 'RGB' 'greyscale' 'indexed' submenu is confusing. The option that corresponds to what
the image currently is, is greyed out. This makes it look as though the image for some reason
cannot be converted to that type, which is exactly the opposite of the truth. This would make
sense for, say, a layered image and the 'indexed' option, where the greyed out 'indexed' entry
shows that a layered image can't be converted to indexed colour map. (Of course in fact it _shouldn't_ be
greyed out but should instead prompt for a 'flatten image first?' modal dialogue, but I'm just
using it as a demonstration).
I seem to remember that Pshop actually has a submenu Image->convert-> with these three options, plus 'flatten image' and some others that I forget. That certainly might be an option.
- Resize and scale are most confusing. I'd go with Pshop's 'resize canvas' which is much more descriptive than 'scale'. Conversly, I think Pshop's distinction between 'resample' and 'resize' is confusing, so I think you should stick with resize doing just what it does now.
- Golden rule: a submenu should never have the same name as any of its parent menus. This fails in the 'Transforms' menu (which I think should be called 'Transform' in any case). The submenu contains an 'image' submenu which silly, we already know we are talking about the image.
Likewise having a layer submenu in transforms is also silly - SURELY this should be in the 'layers' menu!
Layers
The horror, the horror. Another case of two menus with the same name and different contents, but this time different in myriad confusing ways. One of two things should be done:
1: Scrap this menu item, stick with the layers menu obtained from the layers & channels dialog.
2: Make this menu identical to the layers menu obtained from the layers & channels dialog.
This menu appears to be an arbitrary subset of the the other layers menu, but then with some random extras such as the stack->re-order layers item. This is bad.
Tools
This menu is redundant. It serves only as a way of looking up the hotkeys to the tools. The hotkeys should be
show in the tooltips for each tool button, so even this is unnecessary. I suggest removing this menu item entirely.
Filters
I don't envy you the task of organising this menu, but here are some points:
- This menu is misnamed. It is actually a plug in menu, not a filter menu. Not all plug-ins are
filters and vice versa. The fact that some core features of Gimp are implemented via the plugin API (no bad thing in itself) confuses the issue further.
I suggest that the filters menu be just that - filters. Things that do pixel arithmetic, like blur, despeckle, crackle, etc.
Other things can go in a plugins menu.
- Alphabetical order for the categories is indeed the way to go here. As for the definition of the categories themselves, well, you could spend forever shooting the breeze over that, so I will leave that issue alone.
- The plugin-as-function vs the plugin-as-technology problem rears its head in the 're-show last' and 'repeat last' options. They show the last plugin used - not the last thing selected from this menu. So if you last used a bit of core functionality that was actually a plugin, you might well be caught out by this. I was.
- Gratz on the easter egg :-)
Script-Fu
Eeek. Don't name menu items after technology!
Everything here is either a plugin, a filter, or else something so high level and indirectly image related that it should go in 'extras' (aka Xtns :-))
Dialogs
Redundant, we have this menu elsewhere, but AARRRGGGHH!!!!! Once again this menu has similar, but subtley different items from the dialogs menu found in the File menu. Err, that is to say the first of the two file menus.
Get the point on these repeated menus yet? :-)
This menu should be the one and only dialogs menu, get rid of the other one, merge items into this one.
AnimFrames
I'm not at all sure that there should be even this much animation functionality in The Gimp, but if there should be,
then certainly not at this level. I would suggest that all of this goes into some branch of the (currently vestigial) 'animation' menu within 'Xtns'.
Guides
I think this should be a subsection of the View menu, although I'm not _sure_ about that!
Well, that was a quick tour of the menus and main dialogues. A close look at the actual UI aspects of the tools themselves is
a task that deserves about two more weekends I don't have anytime soon, and another document.
Instead, let's have a review of some of this stuff, and what we may have learned (what I would like you to have learned, in other words ;-))
Lessons Learned
Redundancy
A big theme is the problem of menus that appear in two places, menu items that appear in two places, and menu items that perform
a subset, a superset, or a close relative of something done elsewhere in a tool or another menu.
I really think this is actually one of the easier problems to tackle, since it really just involves re-organising menus. I also think it
would bring great benefits.
It is however, a prime way of annoying users who have got used to where things are. This is something that needs to be looked at hard, as soon as possible, then done once and done right the first time.
Don't be afraid of annoying users. They will thank you for it in the end. Menu structure is rather like the API of the human computer interface. It's a bugger when it changes, but it's hell when it gets more and more wrong.
You wouldn't like to see an API where poor functions are simply left floating around for backwards compatibility, while new functions appear that do the same thing, but are part of different libraries, because that's where they belong. Let's get it right first time!
Screen Estate
Well, there are some things that are just tooooo big. Layers dialog and palettes are certainly the big offenders, but it's somethign to bear in mind
all the way through. Maybe folks in the US all have 17" monitors running at 1280x1600 or something, but for me screen space is a real problem.
It's not helped by the fact that each item on screen is a separate window controled by the window manager. Most window managers have too much estate given over to scrollbars, re-size handles, and titlebars. It's worth making an effort to
get rid of such stuff, which is the approach Pshop took with its built in window manager for all its little subwindows and dialogs. Hard work, I'm sure, but worth it I think.
GTK
Well, don't get me wrong, GTK is cool, but reducing the widget sizes in a couple of places would help, and see my points about the checkbox menu items, which are very useful and ought NOT to collapse the menu once toggled!
Multiple Windows
This is a big deal I think, although it's not at all obvious what way to go. Running The Gimp, one easily ends up with five or six windows open, all of them with close functional dependancies.
Window managers are simply not set up for this scenario. They expect windows to contain discrete applications with no strong functional links. That simply isn't the case here. The different windows have functional
relationshops with each other, and need to know more about each other. There are tools provided in places such as KDE and GNOME to deal with this, but they are neither mature in themselves, or ubiquitous (or compatible, I might add :().
As I've said, Pshop's decision to simply give up on the Windows and Mac window managers and create its own, certainly got them results. I guess this rather contrary to the IUnix way, but then I never gave a damn about that anyway. Hell, decent image manipulation is pretty contrary to the Unix way.
This is a big issue, and also deserves a rather more thorough analysis, which I'd like to provide when I can.
Plugin Technology
This is not a problem, but is turning into one. It's vital that implementation mechanism is secondary to
functional mechanism. Categorise something by the way it affects the image, not the way it is written.
- Loth as I am to prevent more Perl advocacy (it is my trade and only language), Sticking the Gimp Perl logo on
things confuses the user. At the very least, plugin developers who want to develop core functionality (i.e. anything that appears outside a 'plugin' or 'extras' menu)
should leave the labelling off.
- The whole script-fu thing should be put aside. They are simply high level plugins. Call them whatever you want (Script-Fu always seemed gratuitously obscure to me, but hey), but put them in
functional categories.
- I've not called for more standardisation in plugin's own UIs, because I know its hard to get plugin developers to do what you say. However, there does need to be
some strictness about where plugins go, and developers should be aware of which menu their plugin will end up in. It's rather like Perl modules on CPAN. No strict rules about how to write Perl (plenty of hints, but no rules), but they
DO make you choose a name that is officially sanctioned. This way the name space stays organised and people can find what they are looking for. The same needs to be
done for modules.
What do we do?
Hell, you tell me, you're the ones writing it, I'm just complaining.
Joke.
Well, the first thing to do is to talk it over. But with stuff like this especially, you can talk for a long time and never agree, much less take action.
To help avoid that, I'm going to suggest some actions.
- Draw up a complete new menu tree.
- Draw up a complete plugin categorisation, and a 'rules for plugin makers'. I'm sure such a rules document exists already, and I would like to read it, but we should
ensure that it properly addresses UI issues as much as API and technical issues.
- Make graphical mock-ups of the key dialogboxes and tool mechanisms a part of the development cycle. Again, it may be already, I'm not a developer.
The End
If you've read the whole thing, thanks. I you've just read the bits that concern you because you are writing those bits, that's cool too.
If you have anything constructive to say, please say it to a public forum where others can join in. If you have something private to say, please email jon@extrasnowdrift.org (remove the extra)
No flames please. I realise that I have criticised, sometimes pretty bluntly, what many people have spent hundreds or thousands of hours creating. But I still reckon it was worth doing :-)