An interface critique of The Gimp

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

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

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.

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

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

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

'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

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

Pattern dialog

Palette dialog

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

Layers and channels

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

The Xtns menu

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

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

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

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

Tools

Filters

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

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

AARRRGGGHH!!!!!

subtley different

AnimFrames

Guides

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

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

GTK

Multiple Windows

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

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?

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

An interface critique of The Gimp

Contents

An interface critique of The Gimp

Declaration of interests

On style

The main file menu

New file dialog

Open file dialogue

Dialogs Menu

Brush selection dialog

Pattern dialog

Palette dialog

Layers and channels

Tool options dialog

The Xtns menu

The 'big right click on the image' menu

Edit menu

Select Menu

View

Image

Layers

Tools

Filters

Script-Fu

AnimFrames

Guides

Redundancy

GTK

Multiple Windows

What do we do?