Author: Jozsef Mak
Visitors to the Ubuntu Art Talk forum recently have been discussing the pros and cons of using the GIMP versus Pixel, a lightweight application with an interface that emulates Adobe Photoshop. Pixel is fast, friendly, and more feature-complete than the GIMP — but it’s not open source. It’s shareware and available for all major platforms.
Interestingly, the bulk of discussions have focused on the GIMP’s GUI. The interface seems to irritate users more than the software’s missing features.
In the past, developers have attempted to improve the GIMP’s look and feel. One of the efforts was the Gimpshop initiative, which changed only the GIMP’s menu layout but left the rest of the interface intact. Another more interesting undertaking was an interface redesign project on the OpenUsability Web site. The idea was to invite input from the community that could be used in the GIMP’s upcoming releases.
The OpenUsability initiative had a promising start. Designers from all over the world injected a great deal of input into the discussions. Unfortunately, this collaborative effort ended because designers and developers couldn’t agree on the basics. Designers wanted a radical overhaul of the GIMP, but developers were interested only in minor interface changes. As a result, the most creative proposals were dismissed without serious consideration. These unbridgeable differences killed off the project, and the design community abandoned it. The forum is still up, but it has generated hardly any meaningful activity for many months.
The disappointing end of the GIMP redesign initiative confirmed that the GIMP project is cruising along on its own closed trajectory, hardly touched by users’ needs.
The open source community needs separate programs targeting Web development and desktop publishing. Since each field demands different tools and functionalities, the programs should support these standards to the full.
Adobe, several years ago, created ImageReady for Web designers and Photoshop for desktop publishers. One way to revitalize the GIMP would be to fork the project along these lines. In other words, the program should be split into two parts, one supporting Web development and the other offset printing.
The Web-oriented editor should support Web-based file formats only and should be able to create rollover effects, menus, animated buttons, and photo album, and support batch processing. Its development could be coordinated with Nvu, so that the code it generates is supported by the Web editor. Ideally, these applications should work closely together like Fireworks and Dreamweaver.
The second program should be optimized for complex image editing supporting CMYK, LAB, and Duotone color modes. Incorporating these features would allow the developers to integrate the program with Scribus, an open source page layout and desktop publishing program, which has been crying out for a bitmap editor.
The conditions are right for an undertaking like this; first, because startups such as Pixel are targeting the Linux platform, and second, because designers need a user-friendly open source image editor.
In its current state the GIMP is the victim of a design philosophy that doesn’t meet user expectations. If its developers can’t resolve this situation, the software will be marginalized by startups such as Pixel.