[back]

Gimp GUI Stuff

I felt I wanted to give in my thoughts on this critique, and what would be a better way than quoting right in-place. Now this is not an intention of violating Jon's copyright for this document. I have kept the original document intact, just added my comments with RED in between the original chapters. So all black text and all the images are verbatim from Jon's original document. All this is done in a good will and the purpose of this modification was to put my thoughts right after the relevant part of this critique - to make reading easier.

Now, although I probably disagree on certain points here, keep in mind the following things:

I am a long-time gimp user. I learned the GUI. It is in my spine. I love the Gimp. So expect my subjective views and wear appropriate filter goggles.
I think this document is useful and good thing. Thanks Jon for taking the time to write up the stuff. It's very good to have something concrete than just random "it sucks" -quotes.
If you are using Lynx or some other text-based browser or some ancient graphical beast, you may have difficulties in seeing the red color. For that reason I am also using <BLOCKQUOTE> from now on to separate my additions. So all red should also be indented.
I dont have answers to all this. I have ideas for some points. I am also pointing out some of the reasons why things are as they are, which doesnt make them any better but should give some idea why gimp is like it is..
By "we" I refer to myself and a bunch of people in the Gimp Development irc channel. "We" does not mean "The Official Gimp Development Team" but rather a bunch of random people who happened to be in the channel at the time of the discussion. Some of the developers may disagree with me, and I may be unaware of things. So this is just "as is" stuff.. Nevertheless I hope it is useful.

The original document is located at http://www.snowdrift.org/computers/gimp-crit.html.

An interface critique of The Gimp

So, this is a comment :)

Declaration of interests

Brush selection dialog

The 'big right click on the image' menu

An interface critique of The Gimp

Declaration of interests

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

This is good. I will also comment on only the facts I feel like adding to. Or on facts upon which I disagree with you. Neither is this commentary a comprehensive thing or a personal flame or anything like that.

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.

This seems to be a feature of Gtk - the black 'hilight' is the active widget indicator.

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.

Doesnt Photoshop also have the mini-pullouts? We had discussion on this feature, and if I remember correctly we agreed this would be useful. It boils down to the fact that someone needs to implement them. That would allow grouping of tools of similar nature in a single button. However this is not so straightforward, since different users have different needs, and someone might like to have Ellipse selection and Rectangular selection on different buttons. Switching a pullout all the time is annoying, though the ctrl-thing might work better if the button has only 2 or 3 tools embedded.

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.

Yes. Perhaps we could rename it to "Gimp" since it is more a "Gimp" menu than anything else. File-menu has to do with file options and those are related to images. What do others think about this? I can update this part once someone comes up with a better idea. (on irc for example, irc.gimp.org:6667 - #gimp).

Most apps have a "File" -menu, it might be the reason also Gimp has it.. Most apps have a File New too.

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.

This is because certain parts of Gtk toolkit looks are modelled after the Motif toolkit (Netscape is using it, for reference) - and motif drop down lists have that kind of square. Certain Gtk themes get over this and you can have an arrow too if you prefer so.
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.

This sounds like a good idea.

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

However, note that pressing Ctrl-P (default key for Palette window) also raises the dialog window which is very handy when working with large images. All dialogs raise when the corresponding hotkey is pressed.

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.

In X we cant assume that the windowmanager actually does have this functionality. Twm does not have a 'close window' -button in the titlebar for example. And there are reasons for running twm - for example in low-end machines or over a sluggy network link.

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.
We need a "Delete brush" button since it is possible to generate and save brushes run-time. Also, now that we have image hoses and pixmap (color) brushes, we could use a notebook approach on the brushes dialog..:

You can see in the middle of the dialog the current situation we want to avoid. We have:
- grayscale brushes, used by the normal painting tools
- pixmap brushes, like above but contain colors. Also used by the paint tools, but then the color comes from the pixmap brush used. Much like a colored rubber stamp.
- image hoses. These are animated pixmap brushes that spit out random images when you draw. Nice when doing stuff like autumn leaves on the ground or something..
Using a notebook will organize this nicely.

We could even possibly stick the Patterns into this, since those are also pretty related stuff.. You paint with patterns using the clone tool or you use bucket fill to fill selections with them. The Ideal Situation would ofcourse be the ability to drag the tabbed panels around and group them in any way one likes. But this is in the "Someone needs to go and implement that" -category. Feel free to add that if you can code and you have too much time :)
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.
This is correct. Good points. Also, the dialog is pretty much broken at the moment. Ideally it should stretch to the size given. But there are two ways of doing it:
- the way you mentioned - simply stretching the palette display
- or a way of adjusting the number of columns and rows according to the dialog shape - that way you can also change the shape of the dialog. I would like to have a palette shaped like the toolbox (tall and thin) so it would fit on the left edge of the screen and thus would need very little screen space from the middle where my image windows are. In that case the zoom buttons could be useful to set the initial cell size. Scrollbars should only be used on demand like they are now.
However the text field for color name is important since palettes like the Web palette have the hex values in the color name. It is very handy to look them up straight in the palette. No need to fire up the color picker tool for that.
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.
  
  This is a historical thing. As you may know, in X11 there is no "active image" in the same sense as in Windows (the one last clicked on) - many people use MouseFocus where you will lose the focus when hovering over another window.
  
  Recent Gimp has a concept of Active Image by marking the last image manipulated the 'active' one. This allows Layers dialog to update when you work on another image. But this is pretty new stuff and I guess we just didnt feel like dropping the selector. Besides, sometimes you want to dig up an another image - maybe one that is iconified - and drag the layers from it to another image (yes, dragging layers around and into other images works now..) So dropping the selector would be a bad thing in my opinion.
- 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.
  
  I consider the preview a good thing in finding the right image among the twenty other images open at the same time.
- 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.
  
  This works now. The whole DND stuff is very new in gimp and you can expect it to change and mature at a fast rate.
- get rid of the up and down ordering arrows, they take up space and users can use DnD for ordering.
  Try dragging a layer on a stack with 40+ layers. Will get evil. Sometimes it is nice to do it with the buttons. Also dragging with a drawing tablet pen is not so easy - at least I tend to drop the dragged thing sometimes. I rather use the buttons or the new PageUp-PageDown key shortcuts (see the stack menu for the keybindings and never touch the stack menu again :) That is the reason the stack stuff is in the submenu btw, to make the menu less tall. Since you really will use the shortcuts anyway.
  - PageUp-PageDn - Select next / previous layer in the stack
  - Shift PageUp-PageDn - Move selected layer up / down in the stack
  - Control PageUp-PageDn - Move selected layer to top / bottom of the layer stack
- 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.
  
  Although I think the ones in your mockup are too small. It's hard to see the previews.
- 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 guess the whole purpose of this menu is to allow the keybindings for layer movement. Unlike in Photoshop, where everything is hidden from the user until you buy the Photoshop Bible and find them out.. The menu serves also as a label and reminder. Not perhaps the most elegant, but you can avoid opening the submenu :)
  - 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.

Yeah, the Xtns -menu is the Dumpster of Gimp. Everything that doesnt fit anywhere else, goes here :)

I believe most of this mess is temporary since we need to re-organize the menus before the 1.2 release anyway. And like you point out below, the hiding of Script-Fu and such is a good thing and it has been discussed even before. Things should be organized by context and function. Not technology like you point out.
- 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.
Good decision! I guess we should have a Xtns haxX0r -submenu for all this 'stuff' :)

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?

What if you dont have a side-table? Not everyone has a 1600x1200 resolution, and even that is too small when editing print-sized images. This is not a big deal in my opinion, since you never paint at the same time when you dive into the menus selecting for a function.

I dont know.. I like the right mousebutton big menu. It is just where your hand is when you are drawing. No need to climb to the top of the screen.. It doesnt really fit anywhere else. It also has pretty much stuff and thus it needs to have quite a lot of submenus. They annoy you sometimes, but where else can you stuff all the plugins really? If you tear it off and put it to the side, all the submenus will pop up over each other when the edge of the screen is too close (unless you put it on the left side.. but changes are that place is full too :)

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?

I dont recall that the menu ever left a stains in my pure, eerie artwork :) It would make sense to have stuff around the image once we get 120" monitors..

But then, if you are to paint a wallpaper to that desktop, it's still the same problem :) The screen is never too big, and the space is too crowded all the time no matter where you place the dialogs... :P

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.

If you figure it out, tell us too :) This is one of the main reasons why Gimp is like Gimp is and why it is not like Photoshop is on certain areas. Some things just dont plain work in X11. Well, you can set your windowmanager to ClickToFocus, but forcing that is not the right way. All in all I think the current lump of hacks, patches, bugs, inconsistencies, ugly code, some cool code, weird behaviour and an easter egg is pretty impressive. It could be improved, but like you said, I dont know any better way to handle the 200 plugins and dialogs with one mouse, keyboard, a pen and one screen. And I need to place the canvas somewhere too :)

Ok, this went a bit to the far side, but I guess you understand what I mean :)

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.
  
  I see it as a way of saving a file. Windows has the Send to -> [File | mail | floppy ] -thing, I dont know if that is good or bad. But I relate the mail plugin as one of the ways to store the image. (Believe or not, I need to mail a lot of images at my work, and nothing is easier and faster than the mail plugin!)
- 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.
  
  Perhaps they should only be in the toolbox menu? They are not used so frequently.
  
  Note. I wont be getting onto the rest of the menus thing since I dont have time for that now, and we will probably be re-organizing those. I'll read your ideas in time and take clues. Thanks for digging these so throughly. It will be useful information.
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'.

I think the GAP plugins could have their own "Animation Control Console".. what do you think? The animation features really justify a separate toolbar with something like VCR buttons.

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!
You can reduce the size of the widgets quite a bit by changing a smaller font in your ~/.gimp-1.1/gtkrc:
```
style "default"
{
  font = "-*-lucida-medium-r-normal-*-10-*-*-*-*-*-*-*"
}
widget_class "*" style "default"

		
```
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.

*cough* SGI comes to mind :)

I strongly think this is what the concept of virtual desktops is for. Just run gimp in a separate virtual desktop and the other apps on their own. I organize my programs evenly on separate desktops so it doesnt get too crowded. Works great. This is of course an issue for those who never got used to it, but they will learn. I did. :) And I loved the virtual screens right away.

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@snowdrift.org
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 :-)

Thanks also for reading the red print :) I really wish this will give some good ideas to improve Gimp. And, Jon, though I sometimes used pretty straight language, dont be offended, it was not meant as a personal thing, just to point out things :)

Tigert

Warning: mysql_fetch_array(): supplied argument is not a valid MySQL result resource in /home/tigert/sites/tigert.com/include/TIG_counter.inc on line 8
quick brown foxes jumped over the lazy dog..

Gimp GUI Stuff

An interface critique of The Gimp

Contents

An interface critique of The Gimp

Declaration of interests

On style

The main tool bar

The main file menu

New file dialog

Open file dialogue

Preferences

Dialogs Menu

Brush selection dialog

Pattern dialog

Palette dialog

Gradients dialog

Layers and channels

Tool options dialog

The Xtns menu

The 'big right click on the image' menu

File menu

Edit menu

Select Menu

View

Image

Layers

Tools

Filters

Script-Fu

Dialogs

AnimFrames

Guides

Lessons Learned

Redundancy

Screen Estate

GTK

Multiple Windows

Plugin Technology

What do we do?

The End