The GNU Image Manipulation Program
has long been dogged by
criticisms of its user interface. Among the complaints are the program's
heavy reliance on popup menus and the behavior of its multiple windows.
To be fair, a bitmap image editor is probably by nature very hard to
design well: witness Adobe Photoshop (to which the GIMP is often
unfavorably compared) and the training-and-documentation industry that
has grown up around its complexity.
And the GIMP, whatever its shortcomings, has a large and dedicated user
base. So the development team could be forgiven, perhaps, for simply
giving up on usability. But just the opposite is happening. The latest
development release incorporates a number of enhancements aimed at
improving usability. These changes alone will probably do little to
attract new users or discourage existing ones. But beyond the
incremental improvements, the GIMP project seems committed to finding a
better design process.
I will have more to say about process issues shortly. But first, let's
examine some of the user interface improvements in GIMP 2.3.4. This
release is a preview of GIMP 2.4.
There have been several changes for better compliance with the
GNOME Human Interface Guidelines.
These are mostly minor alterations like
changes in capitalization of menu items and the labeling of buttons with
appropriate action verbs instead of "OK." Menus have been reorganized;
particularly noteworthy is that the Script-Fu menu has been merged into
the Filters menu, eliminating a long-standing source of confusion.
There is also a new rectangle selection tool which, rather like the
current crop tool, uses a two step process where the user creates a
"proposed selection" that can be resized either with the mouse or by
entering numerical parameters before finalizing the selection. Also like
the crop tool, the unselected area is dimmed for improved visual
Drag and drop capability has also been enhanced, both internally and
between the GIMP and other applications. It is now possible, for
example, to select a brush, pattern, or gradient by dragging it from its
palette to a Script-Fu dialog. With the addition of
(Direct Save Protocol) support, you can save images by dragging
them to any file manager that supports XDS, as shown in
Finally, developers are addressing one of the most common interface
gripes: the multitude of separate top-level windows. It is now possible
to set "helper" windows--palettes and dialogs--to be transient to the
image window. This means that if you minimize an image window, all the
helper windows, and the main toolbox, are minimized with it. This
behavior becomes problematic when there are multiple images open, but
given that users have widely varying expectations for window behavior,
there is probably no perfect solution to this problem.
But what does this all mean for the user experience as a whole? Not
much. The changes are in my opinion, mostly useful. Yet the new
usability fixes do not represent a unified vision of the GIMP experience
(before anyone starts writing nastygrams, let me point out that I don't
consider the GIMP team particularly at fault here--but more on that in a
I believe that there are two larger issues that need to be resolved. One of
these is inconsistent UI behavior. Take drag and drop, for example.
Suppose you have discovered that you can save an image by dragging its
thumbnail from the GIMP Image dialog to a ROX-filer. Knowing this, you
might expect to be able to open an image by dragging it from ROX to the
Images dialog, but ... no such luck. It turns out you *can* open an
image with drag and drop, but you have to drag it to the main toolbox.
There are other issues with drag and drop, not necessarily the fault of
the GIMP, but nonetheless problematic for GIMP users. For example, you
can open an image in the GIMP by dragging it from Firefox or
Epiphany, but not other way around. XDS support is nice, but there are
few file managers that support it.
Another sore point is the tradeoff between functionality and simplicity,
and there appears to be no consistent approach here. Some of the changes
in the new GIMP tend towards simplicity, such as combining the Script-Fu
and Filters Menus, while others introduce complexity, such as the new
rectangle selection tool.
What underlies both of these issues, I suspect, is that up to now there
has been no real vision of who the users are and what they need.
OpenUsability is a Web-based project portal
that "... brings Open Source Developers and Usability Experts together."
The site provides a structure and tools for gathering usability data and
discussing design issues; a growing number of projects are
participating, some of the more prominent ones being Wikipedia,
WordPress, Anjuta DevStudio, and a number of KDE projects.
Simply registering your project at a portal guarantees nothing, of
course, but the GIMP team appears committed to really using the process.
Among the forty-plus registered participants for GIMP-OpenUsability are
lead developer Sven Neumann and at least 6 other active GIMP developers.
Moreover, in less than two months the GIMP forums have racked up about
350 posts; based on a quick non-scientific survey of the projects at the
site, these numbers make the GIMP by far the most active project at
OpenUsability.org. Looking at the content of the discussions, we find a
bit of the perennial "Why can't GIMP be more like Photoshop?" complaining,
but also a good deal of thoughtful consideration of what a more usable
GIMP would look like, and how to improve the design process.
Those who are hoping for revolutionary changes in GIMP will have to wait
a bit longer. Based on the current release, GIMP 2.4 will offer some
significant improvements, but the overall experience will be more or
less unchanged. For the long term, who knows? OpenUsability is an
experiment, and there is no proven model for integrating user-centered
design into an open source development process. Nonetheless, it is
encouraging to see the GIMP team take this initiative. If the effort
succeeds, we may have a new model for open source development.
to post comments)