May 07, 2012

Abstract interfaces

Gimp 2.8 - an important milestone in the road to Gimp 3 - is out. But this post is not about the new single window UI, or about the fact that saving an image is easy for the first time. This post is about the path to get to version 2.8.

Gimp is powerful - not entirely Photoshop powerful - but more than sufficient to handle anything an amateur photography enthusiast might want to throw at it. But overshadowing it's power is a user interface that feels piecemeal and awkward. If I had to summarize it's problems - it would be this: the interface lacks abstraction.

When a programmer builds user interfaces, it is a bit like an engineer trying to sell a product. A programmer knows exactly how piece of functionality works - what the variables are, what the functions do. The user interface reflects that - a list of inputs for the variables, organized into groups of functions. This would be perfect, if the goal of a user was to run the various functions - but when the user comes in to perform a task, the interface begins to get in the way.

A great abstraction bridges the gap between the user task and tool functionality.

And Gimp is taking it's first steps in that direction. Starting with a brutal evaluation of the current state of the interface, the Gimp team is doing what any good built-by-consensus project would. Reach out to the community for ideas.

But there is many a step before Gimp begins to resemble a polished UI. While that in no way means copying the Photoshop interface, but it involves coming up with a way to interact with the user in such a way as to provide capability and not functions. Of taking all available ideas and distill them into a coherent experience. But again, just like consensus might not be the best way to build a program, it might not be the best way to polish an interface. Maybe it just takes singular vision.

No comments: