Slashdot Mirror
Instrumented GIMP To Identify Usability Flaws
Mike writes "New users of the GIMP often become frustrated at the application's unwieldy user interface. Now Prof. Michael Terry and a group of researchers at the University of Waterloo have created ingimp, a modified version of the GIMP that collects real-time usability data in order to help the GIMP developers find and fix its usability problems. Terry recently gave a lecture about ingimp and the data it collects. During each session, ingimp records events such as document creation, window manipulation, and tool use. A log of these events is sent to the ingimp server for analysis. The project hopes to answer questions such as 'What is the typical monitor resolution of a GIMP user?' and 'Is the GIMP used primarily for photo editing or drawing?'"
I already see one potential problem with this approach, and that is that it collects usability statistics from ingimp users, not GIMP users. How would it be guaranteed that the two groups are statistically equivalent?
(No, I have not RTFA yet.)
This poses interesting questions. Those who are integrated enough to be willing to engage in the ingimp project are very likely to have differing behaviors or preferences. Additionally, one of the chief complaints people tend to have about usability is the inability to do something. By looking at the behavior of actions rather than desired actions, those actions which are easy to do in the current iteration will be seen as more desired, rather than simply more accessible. Meanwhile, those actions which are difficult to preform due to actual problems with the interface will be more likely to be overlooked.
My wife does Web design for University of Waterloo and she's always moaning about the usability of the GIMP. I too am more into design than development these days, so that makes two people who're--more or less--ideal for the task.
Not to mention we have both customised our GIMP's to look and behave more like Photoshop (the missus was fiddling with the keyboard-shortcuts for ages). It seems this data should be collected in this project, as I doubt we're the only ones who've changed everything to our tastes, the developers should finally realise what people want in an image editor.
On a related, by tangential, note: GIMP's new core (GEGL) seems to be nearing completion, with that comes all the things people have been clamouring for. Such as non-destructable layer effects, CMYK etc. If they fix the usability and shift to GEGL as the core of GIMP it might finally become the Photoshop killer we've all been waiting for! Failing that Krita is coming along very well as an image editor, it lacks a few features, but is far more usable than the GIMP.
Overall, I don't think anyone should be saying: 'year of the Linux desktop!' just yet. But this is definitely a step in the right direction. :)
I'm going to transform myself into a mighty hawk. Either that or I'll just go and work at Dixons, haven't decided yet.
Then there was the time IBM instrumented a mainframe to determine what instructions were heavily used so they could focus their optimize-the-microcode effort on them.
They found one particular instruction that accounted for some exceedingly large fraction of the execution time. So they went to work on the microcode and doubled its speed. Then they deployed the new microcode and measured the application performance, expecting to see a big improvement.
It didn't change a bit.
After a little more research they discovered they'd optimized the idle task's wait loop.
= = = =
Collecting data can be useful. But making good decisions based on it requires wisdom and insight.
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
As someone who began using GIMP before using Photoshop, I find Photoshop's interface to be awkward and GIMP's to be natural.
Given that a significant majority of people who use GIMP probably used Photoshop first, I wonder what percentage of "moaning about the usability of the GIMP" comes from simple acclimation to a different way of doing things? I'd be interested in seeing the results of introducing one group of people who haven't done any digital graphics work before to Photoshop, another group to GIMP, and seeing how long it takes them to feel comfortable and learn the ropes. Then, you'd have them switch tools and see how well they adapt.
As it stands, I think we're seeing a lot of selection bias.
South Park pokes fun at sacred cows to make a point. Family guy pokes cows to hear them moo.
Qualitative methods like the ones you suggest -- observations, interviews, ethnographic methods, contextual design -- are some of the best methods out there to uncover the data you suggest should be collected. In fact, my HCI class focuses exclusively on these methods. They're cheap, they're fast, and you got a lot of data very quickly.
ingimp doesn't intend to supplant these techniques. In fact, it would be a mistake for people to assume it could or should. And the GIMP project already has a good group of people who are using the very techniques you propose (see http://gui.gimp.org/ ).
However, GIMP is a very general purpose application and there are limited resources to improve it. How should future development efforts be prioritized? Are most users experts or novices? Do they use it to color correct images, crop and resize them, or are they doing more sophisticated things like graphic design over hours of use? What are common workflows? Are they the same workflows we assume people are doing, or are they completely counter to our expectations?
Quantifying broad usage is not something that can be done by qualitative methods alone, but it can help to focus future development efforts if you can better characterize your user base, how they're using the software, and how many people are using it in various ways. With this data, you can optimize for the minority or the majority -- at least you know who you are optimizing for.
One of the benefits of this data is that longitudinal patterns of usage can be discovered that wouldn't come out in laboratory based usability studies. For example, if a new feature is added, these stats can help you determine whether people are adopting and using the new features as expected. Longitudinal data is rare -- we're building a longitudinal data store right now unlike any other in the open source community.
One of the challenges that is glossed over is that creating a sustainable usability infrastructure is no trivial task. We're collecting data in a very unobtrusive way that requires very little effort on the part of the user, and that data has a fairly high degree of ecological validity -- people are using the software in their own environments, not in an artifical usability lab. Again, while not a replacement for qualitative methods, the data we collect do help answer other questions valuable to guiding development efforts in a resource-constrained environment. Other ideas on creating a self-sustaining usability infrastructure, which does not overly burden the developers or users, are certainly welcome.
On a final note, there are benefits to this data beyond usability itself. For example, we've found that people use the most frequently used command stats to discover features/commands/plug-ins they weren't previously familiar with, and which they find valuable. The data set is a bit richer than it at first seems.
Michael Terry
I really can't be the only one that absolutely loves GIMP's UI.. can I? Everyone that seems to have a problem with it is always saying the same thing.. "It should look like Photoshop", "It should feel like Photoshop", heck "It should be Photoshop". Personally I hate applications with one big monolithic window.. they always tend to then have encosed sub-windows that you cannot pull out of the main window, this drives me crazy when using a multi-monitor display. GIMP is a godsend for allowing me the flexibility to place all my tool dialogs on one monitor, in the locations I prefer (and it remembers them between sessions!), then have a maximized editor window on another (which saves sooo much "zoom in" "zoom out" time due to the more efficient real-estate usage).
And here we have it, folks: the key weak point of OSS. Perhaps, more accurately, the key failing point of the OSS fanboys.
EXACTLY!
Fanboys fail to understand that there is something in the world called CUSTOMERS, unable to program, unable to send patches, but with specific needs. Fanboys like software made "by programmers, for programmers". Or actually "by programmers, for themselves and screw everyone else, if you don't like MY software, fork it or fork you!".
In the link I mentioned about "a better pile of poo" we see that this kind of software, by programmers for programmers, was made in the early stages of software developers. Today, software is made by teams of developers, artists and user interface experts (aka "interaction dudes").
You know what's interesting? That fanboyism is usually greater in linux circles. Windows developers are used, accustomed to nice, friendly user interfaces - and although most of the time they make crappy software with awful programming techniques in Visual Basic, sometimes they excel and make wonderful user interfaces. (Now mix nice user interfaces with an MVC approach and woo hoo! )
I tend to think that Linux programmers are so used to hack and slash code, that they forgot what it feels like to have a nice UI, with keyboard,mouse shortcuts, context help, cut-copy-paste, etc etc. Most of the Linux open source software I've tried have a crappy interface. This is why I prefer Irfanview, Pixia and Virtualdub to the GIMP or AVIDemux respectively. By the way, I tried Jahshaka once. What an awful UI.
Update: This is just in. A friend of mine just told me: "gimp is a bunch of garbage. I downloaded it and the gui is adobe photoshop chewed up and sneezed at the monitor". Your honor, I rest my case