LGM: Usability and AdaptableGIMP

University of Waterloo Human-Computer Interaction (HCI) researcher Michael Terry always has intriguing work on display when he comes to the Libre Graphics Meeting. Two years ago, it was ingimp, a GIMP derivative that collects real-time usability data, and Textured Agreements, a study that showed how semantic markup and illustration dramatically increase the percentage of users that read and understand end-user license agreements and other click-through "legalese."

2011 was no different. Terry and his students presented two talks that could change the way open source developers work. The first was an analysis of real-world frequently-asked-questions mined through the Google Suggest search auto-completion feature. The second was another version of GIMP that — drawing on ingimp results and the Google Suggest analysis — presents a task-oriented interface, where users choose a task set to work on, and the tool palette morphs to fit the job at hand. The result is less confusing for new users, and because the set of supported tasks is customizable, it can grow through community contributions and individual personalization.

How do I ...

The first talk, entitled Quick and Dirty Usability: Leveraging Google Suggest to Instantly Know Your Users, detailed an analysis project led by PhD candidate Adam Fourney. Fourney and his collaborators started with what many Google users already know: by typing in a partial search query to Google Suggest, one can see the most popular complete search queries entered in by Google users at large. Although this is often done for comedic purposes, they instead scripted the process and automated search query prospecting runs for Firefox, GIMP, Inkscape, and small set of other open source applications, using an assortment of "how to" phrases and re-wording tricks to grab the broadest set of results.

After collecting data for three months, the team analyzed and classified the results. Additional Google tools such as Google Insights and AdWords helped to turn the raw query results into a usable data set. The queries break down into six basic phrase categories (e.g., imperatives like "gimp rotate text" versus questions like "how to draw a line in gimp"), six "intents" (e.g., troubleshooting problems versus seeking instructions), and in many cases related words allow certain queries to be correlated (e.g., "bring the window back" and "lost my window").

Analyzing the data may make for fascinating reading, but the researchers jumped straight to the potential practical applications for open source software projects. Among the findings that a Google Suggest query-study can uncover for a project are where the users' terminology and the project's diverge, functionality desired by the user base that might not be on the project's radar, and usability problems.

In the first category, the researchers observed that GIMP users frequently search for help making a picture "black-and-white." In reality, of course, the users are most likely not interested in a binary, two-color result: they want a grayscale image. Thus the project can help lead the user in the right direction by including "black-and-white" in the relevant tutorials and built-in help. The second and third categories are probably more self-explanatory: if users are consistently looking for help with a specific topic or error dialog message, it is simple to move from that knowledge to a feature request or bug.

Harvesting Google search results itself is not a new idea, but the talk (and the paper from which it originates) do an excellent job of explaining how to take a simple query and systematically glean useful data from it. An audience member asked Fourney if he planned to release his query-harvesting code; he declined on the grounds that Google's terms-of-use do not explicitly address using Google Suggest for this type of data mining, and he fears that publishing the code could lead to an obfuscation campaign from the search engine. Nevertheless, he said, the actual code was simple, and anyone with scripting experience could duplicate it in short order. The real genius, of course, comes in correctly interpreting the results in order to improve one's application.

Adaptation

A prime example of how developers could use search query analysis was on display in the second talk, Introducing AdaptableGIMP. AdaptableGIMP is built on top of GIMP 2.6 (the current stable release), and seeks to add a flexible, new-user-friendly interface to the image editor. Binary packages are available from the project for Windows and 32-bit Linux systems. The Linux builds are provided as Debian packages: one for AdaptableGIMP itself, and replacements for the standard gimp-data and libgimp2.0. Source tarballs and a Github repository are also provided for those who would prefer to install from source.

AdaptableGIMP does not remove any functionality from upstream GIMP. Rather, it replaces the standard toolbox palette, and links in to a web-based archive of "task sets," each of which loads a customized tool palette of its own. When you are not working with one of the loadable task sets, however, you can switch back to the default toolbox with its grid of tools. The custom palettes presented by each task set give you an ordered list of buttons to click that steps you through the process of performing the task at hand. It's a bit like having a built-in tutorial; no more getting lost or searching through the menus and tool-tips one by one.

At launch time, AdaptableGIMP asks you to log in with an AdaptableGIMP "user account." This is optional, and is designed to tie in to the project's wiki service (as well as to allow multiple users on a shared system to maintain distinct identities, a feature that is probably more useful to Windows households). At the top of AdaptableGIMP's toolbox is a search box, into which you can type the name of a particular task or keywords. As you type, an overlay presents live search results retrieved from the AdaptableGIMP task set wiki. Each has a title and a short description; if the pop-up results are not helping, you can also launch a search dialog window that offers more information, including a preview of the steps involved in the task and the associated wiki page.

Whenever you select a task, it loads a custom list of commands into the toolbox. This is a bit like loading a recorded macro, except that the steps are not executed automatically; you perform each one in sequence. An "information" button next to the task title opens up a pop-up window explaining it in more detail. For example, the "Convert a Picture to a Sketch" task set involves four steps: converting the image to grayscale, adjusting the contrast in the the Levels dialog, applying the Sobel filter, and inverting the result.

Each step is represented by a button on the task set toolbox, as you click through them they change shape to the "pressed" look. It helps to have the Undo History palette open, because clicking the buttons again does not undo the completed step. In any event, clicking the buttons opens up the correct tool, filter, or adjustment window, pre-loaded with the correct settings (if applicable), but clicking does not automatically execute every task, because some require input — selecting the right portion of the image, for example.

Looking beyond the individual task sets, AdaptableGIMP allows the user to personalize their experience by downloading local copies of frequently used task sets. The interface shows the last-update-date of each task set, which allows the user to compare it to the public version and retrieve updates. The task sets are stored on the project's wiki in XML. You can create your own task set on the wiki by using the built-in editor, but you can also create it or edit an existing task set within AdaptableGIMP, simply by clicking on the "Edit commands" button.

On the down side, the AdaptableGIMP team admits it is not experienced at building .debs — and even appeals for help with the packaging. Currently the Debian packages weigh in at 16.7MB and installing them is less than trivial. The AdaptableGIMP package conflicts with standard GIMP 2.6 and will not install until GIMP is removed, while the gimp-data and libgimp2.0 packages do install, they just break GIMP 2.6 as a result. Fortunately, all are easily removed and replaced with standard GIMP once testing is complete. Hopefully someone more experienced with packaging will offer to lend a hand, because AdaptableGIMP is an interesting package that distributions may actually want to consider offering.

AdaptableGIMP's launch-time selection of public task sets came from the results of the Google search query study discussed above, plus the ongoing data collection provided by ingimp. The wiki is open to all, however, and the concept of AdaptableGIMP "user accounts" is advertised as enabling good task set authors to develop a positive reputation with the user community by sharing their work.

All together now!

At the moment, AdaptableGIMP is tied to the wiki for retrieving remote task sets, but Terry pointed out that this is not set in stone, and that in the future it should be possible to add in other remote "task repositories." The researchers have not been able to do this yet solely for lack of time, which is also why the adaptable interface and task-set framework have not yet been modularized so that they could be re-used in other applications.

Inkscape and Blender team members in the audience asked follow-up questions about that point, including how to stay in contact with the research group as development continued. Like GIMP, both applications support a vast array of unrelated use cases, to the point where casual users sometimes do not know where to get started. From the GIMP camp itself, Øyvind "pippin" Kolås was highly complimentary of the work, saying "we think you're on crack — but it's good crack." He went on to say that the GIMP UI team found a lot of the ideas interesting and useful, although AdaptableGIMP probably could not be directly incorporated into the upstream GIMP.

Terry agreed with the latter point after the talk was over, explaining that the AdaptableGIMP interface is not meant to replace the traditional GIMP interface. Also, in the present code base, the process of changing the GIMP toolbox was not straightforward enough to make AdaptableGIMP distributable as a GIMP plug-in because it removes and replaces parts of the UI, which are activities not covered by the plug-in API.

As for distant versions of GIMP, Inkscape, or Blender, who knows? Terry and his research students intend to keep developing the AdaptableGIMP software — including the communal, public task set architecture, which (more than the interface changes) makes up the backbone of the system. As the team stated at the beginning of the talk, years of ingimp research show that most users make use of only six GIMP tools on average — but everyone's six is different. That is why GIMP and the other creative applications are so complex: everyone uses a different subset of their functionality. By separating "the tasks" from "the toolbox," AdaptableGIMP shows that it is possible to carve a usable path through even the most complex set of features, provided that you make getting something done the goal, instead of showing off everything you can do.

Graphics tools are certainly not the only subset of open source applications that could learn from this approach. Just about any full-featured program offers more functionality than a single task requires of it. The other important lesson from AdaptableGIMP is that presenting a streamlined interface does not necessitate removing functionality or even hiding it — only offering a human- and task-centric view on the same underlying features.