publications

GIMP’s new free‑poly tool

June 21, 2008, 13:42

Recently there was a heartwarming post on the graphics planet:

‘Another exciting thing that will be in 2.6 (and the next 2.5 release) is the hybrid polygon/free select tool! It is truly a thing of beauty…’

David Gowers, featured on meetthegimp.org

The story of how the the free‐polygon tool came about is one of developer–interaction architect cooperation.

going poly…

The initiative came from Martin Nordholts. He had built a proof‐of‐concept polygon selection tool and was asking me to write UI specification for it. First I asked my self if GIMP really needed this tool. Is it not replicating what can be done with the path tool?

After I convinced myself that it was a good idea to have a polygon select tool, I had to deal with yet‐another‐tool in the GIMP toolbox. One of my goals is to end up with less tools than now, not more.

magic combination

So following my intuition I asked Martin on the irc: ‘is there any way that this polygon tool can be integrated with the rectangle selection tool?’ Martin answered along the lines of: no, but what about the free selection tool?

Brilliant. Not only did I instantly know this was a great idea, I also instantly knew what it was going to feel like to use this tool. Martin and other developers on the irc could not imagine how free and polygon segments could be represented on screen and created by users in an elegant way. I knew within minutes how this was going to work.

small is beautiful

Fuelled by enthusiasm, I wrote the initial UI specification in an hour and a half. It was really a straightforward merge of two simple tools: like before, clicking was going to create polygon segment, dragging free segments. My trick was to place a polygon point at both ends of each free segment, enabling the connection between both types of segment.

I was determined to keep it simple. Concise, straightforward tools like this fill me with more satisfaction than more complex ones—although necessarily so—like the rectangle selection tool (13 pages of specification). In a similar fashion I am more proud of the simple but super elegant applications I have designed for Nokia, e.g. the Translator, than of the complex ones, e.g. the email client.

tit for tat

The refinement of the tool after development commenced is a further example of our cooperation. Martin contributed the 15 degree constraints (using the control key) as seen on other tools and better modification of free segments—rotate and resize—when grabbing one of their handles.

I saw that these were indeed improvements in user interaction and integrated them in the UI spec. Martin relied on me for UI solutions for corner cases he encountered.

One was the issue of whether the polygon points should be always visible—quick to grab, but high visual noise—or only on mouse‐over—clean but slower. I kept in mind the activity of tracing existing images where you want the points to be invisible to inspect if the trace is correct to the last pixel and quick to grab, to adjust a point to the last pixel. I squared that circle by making points visible when the mouse is nearby and figuring out how far away nearby is.

Another issue was that polygon points are really in the way when you want to create another one close or on top of it. This also affects continuing with a free segment exactly from where the last segment ended. My solution: the shift key suppresses existing points, clearing the way to create new segments anywhere.

With all these UI changes, I guarded the conceptual integrity and ensured that we were not introducing bloat, getting in the way of the core value of this new tool.

closing credits

What we have seen here, I see in general in the projects I do. Developers drive innovation on a technology and feature level. Interaction architects create the UI that actually works. UI that is integrated in the overall concept and that supports the activities that users undertake.

In the middle is cooperation between us, where ideas are brainstormed, solutions are cooked up. And where each side determines if this is the right way forward. Developers for the technological aspects and interaction architects for the user interaction.

test drive

Go on, try out the new free‑poly tool of GIMP 2.5. We had a ball creating it for you. You will find it under the trusty lasso icon of the old free selection tool. That is, until we tackle the update of that…

Labels: architects, GIMP, practical

—ps

2 comments, link‐ins, forward this posting:

     

GIMP redux: intro

March 12, 2008, 11:39

Lately, a couple of things have started to orbit each other:

GIMP UI analysis

This is the current phase of our redesign project. And although a consensus has formed among my team about the gist of it, not having it written down as a coherent system means that no coherent improvement can be made to the GIMP UI. Only with a finished analysis can I drive the roadmap that stops GIMP going the way of the dinosaur.

what’s up?

People have been writing me—thanks btw.—asking when they are going to see the results of the redesign project. Renovating a big application is going to take time. In the meantime, it is a good idea to show where we are going. Our project wiki is a place to see us work, but it is not a great narrative to read.

libre graphics meeting 2008

I was already asked for the topic of this year’s lecture. What could I cover that would advance the deployment of interaction architecture in ‘pro’ graphics applications? And for that matter, advance ‘pro’ graphics applications in general?

the big picture

Last and foremost, a nagging feeling that the long list of meso‐level issues in our rough outline are part of a bigger issue, which has to be addressed first. Not seeing the wood for the trees, I need to helicopter out.

bird’s eye view

So I have set myself a challenge with the title of my libre graphics lecture: ‘GIMP: a new simple interface for a complex application.’ That is the big picture. The GIMP product vision mandates it to be a deep, feature rich application that takes commitment to master.

But at the same time there is plenty of scope to radically cut down the visual noise in the interface, improve user efficiency and increase the room for creativity. Only big steps in these departments will ensure that there is a future for GIMP.

live and let…

I have got two months to prepare for lgm and I will do that right here. In a series of ‘GIMP redux’ articles I will go top‐down through the UI. These blog entries will at the same time pop up in the wiki as chapter seeds. There they will evolve, building up the analysis.

There is room for review and feedback, here in the comments, over on the developer list, or via the brainstorm. That will drive the refinement of the analysis chapters.

So there you go: the big picture of what is going to happen to the GIMP UI will be developed in the next months, in time for the lgm 08. And you will read all about it here.

Labels: GIMP, GIMP redux, practical

—ps

2 comments, link‐ins, forward this posting:

     

GIMP lecture, berlin

December 09, 2007, 14:54

This Wednesday (12‑12‑7) I will be presenting at the newthinking store in berlin. It’s berlin‐usability‐stammtisch‐Wednesday and I will do a lecture on GIMP, open source and interaction architecture.

Apart from the announced focus on the run of the GIMP redesign project thus far and our professional approach to the top‑10 most requested features, I will also elaborate on the—partially novel—methods developed during the project.

If you are in or around berlin this Wednesday, I hope to see you there. Tucholskystraße 48  10117 Berlin, it starts around 19:30.

Labels: architects, GIMP

—ps

0 comments, link‐ins, forward this posting:

     

the making of: GIMP UI brainstorm

September 22, 2007, 20:02

It all started with Esteban’s message on the GIMP developer mailing list, asking where he could ‘upload a mock‑up of UI changes.’ That destination didn’t exist, yet. In my reply, the words visual brainstorming pop up and the idea was born.

That was the eve of my summer holiday, during which I spent some time thinking about how to make this work. The more I fine‐tuned the rules for a UI brainstorm, the more I felt it would be worthwhile to roll out.

trigger happy

A UI brainstorm is a great way to let everybody, regardless their experience in the field, contribute to a interaction design project. The whole idea is that one idea intuitively triggers the next and that in the context of the brainstorm anything is possible.

No matter how boring, impossible or just plain whacky the idea, it is a valuable contribution. Either it triggers a reaction from other participants in the opposite direction, or it invites to meander for a minute along that train of thought (‘imagine there really is no menu bar…’). Both are a step in the right direction.

get off

Participating in a brainstorm is a gratifying experience because ones ideas become officially part of the project. For us who organise the brainstorm, the contributions are valuable because we again get triggered by them. The result of that goes into our design process.

happy, clappy

If there is something that destroys the creative process above, it is negative thought. Any kind of naysaying or discussion of merit of an idea destroys the atmosphere where anyone can come forward and contribute.

For this reason I said ‘no polemic, please’ from the start. No written contributions, images only. And quite topical, to ask participants to express themselves graphically.

Looking at the kind of heated comments that usually accompany a GIMP news item, I knew comments would hijack and sink a brainstorm forum in no time. So in line with the positive vibe: no comments.

tech crunch

‘It is going to take ages to build an automated forum for this’ I thought, while still on holiday. Then I realised that all it takes is a mailbox, a blog and some manual labour in between. Ready to roll, that is if the use of google services was not objectionable.

I ran the idea past Sven and although not enthusiastic about the google angle, he also saw the point of getting things running. So a couple of weeks later I put the whole thing together on a Saturday afternoon.

…two weeks later

Although only announced on the same GIMP developer mailing list, the news spread fast across the internet. Sixty thousand visits from 145 countries, 334 sites reporting on the brainstorm and sending visitors.

Seventy contributions up to now. More came in, some people thought they could game the system: send in text‐only images or plain screenshots of other applications where obviously they did not invent any pixel themselves. Those did not make it. Good thing that moderation is built into the manual publishing of the blog.

sifting through

Kamila and I went through all of the published contributions during our team meeting yesterday. We analysed the issues the contributions address and got triggered by several contributions, giving us valuable ideas that one time or another will come in handy.

I think that quite a few people are enjoying the GIMP UI brainstorm. We look forward to see it develop in the coming months.

Labels: GIMP, practical, ucd

—ps

6 comments, link‐ins, forward this posting:

     

lgm 07, top‑5 GIMP user requests

May 25, 2007, 01:55

After my project overview at the lgm conference, Kamila Giedrojć joined me on stage to present the top‑10 user requests, and our solutions models for them. Here are the remaining top‑5:

5. avoid pop‑up dialogs

for tools, file plug‑ins, et cetera

During the expert evaluation we found unnecessary dialogs, whose default settings are fine, 99% of the time. The dialog simply creates more work and breaks the flow in these cases. Our conclusion: take them out.

Other examples of unnecessary dialogs include the rotate, perspective and scaling dialogs.

no vacancies

We also observed that the inspectors—the toolbox that by default appears on the left, and the dialogs‐column with layers, etc. that appears on the right—are already pretty much filled up with essential dialogs, and with the introduction of GEGL will be even more so in the future.

This means we cannot pursue a solution where most dialogs would stop popping up in the middle of the screen, and would instead appear in an inspector.

sneak preview

We found during the expert evaluation that a majority of dialogs offer either a limited preview of the effect they would deliver or no preview at all.

Our solution is to make the whole main window the preview. It is big, but still limited in the number of pixels that actually need to be calculated. And the image has the right size and the right zoom level, because users set it that way.

Here is the current situation in GIMP, working on an image, doing a Gaussian blur:

For this moment we have actually stopped working on the image itself. The work is done within the dialog, where the preview still has to be zoomed and panned to help us.

Below is our new solutions model. The heads‑up display with full‐window preview offers a continuous workflow on the image itself.

The partial transparency of the heads‑up display creates the user experience that one can work on the whole image, although technically speaking it still obscures part of the image.

disclaimer

this is a quick‐and‐dirty lash‑up to show you what we mean; there are for sure some things missing and lots of small issues to solve; enjoy nonetheless…

4. better painting tools

We presented some of the concepts we are working on at the moment.

In the expert evaluation we found the four brush models only available for color painting. Taking image content into account, we see that these brush models can be useful for any kind of brush based tool, like dodge/burn or sharpen.

Our solution is to make the brush models part of all brush tools, taking their icons out of the toolbox and into the tool options.

warped saturation

During our expert evaluation it became clear from all interaction aspects that the iWarp plug‑in should be a brush tool. Our workplace observation showed that if GIMP would implement that, then it would be the number one tool for photographers.

We found that there is a tool to paint with brightness (dodge/burn) but not with saturation. There are whole photography art movements based on reducing saturation, commercial photography depends on turning it up. A saturation tool completes the palette of basic painting tools.

power modes

We evaluated the paint modes and appreciated how powerful they are. However, we observed that there are ‘natural’ modes (e.g. dodge, saturation)—where one can actually predict what they will do—and mathematical modes, like multiply or color erase.

Because the natural modes can be easier matched to actual artistic goals, our conclusion is that these modes should be removed, and their functionality merged into existing and new painting tools. The mathematical modes can stay where they are, being powerful, oblique and fundamental.

dipping + smearing

During our expert evaluation of ‘wild brushwork’ we noticed that there is no equivalent of physical painting: having a palette in your hand; smearing this and that color on the canvas; even mixing in other materials, like sand.

So we created a solutions model for a file palette, which sits at the edge of the image window:

Nicknamed ‘blobs of paint,’ the blobs are dragged in from color selector swatches or project palettes, or eyedropper‑ed from the image. Furthermore the treatment from any filter or plug‑in could be dragged into a blob, which would mean one could paint with noise, for instance.

Just dip your brush in a blob and smear away on the canvas. Mixing between different blobs? We are thinking about it. Finally, even more important than creating blobs is deleting them: just drag it out of the palette. This is an easy‐come easy‑go palette.

Oh, and again our disclaimer…

3. layer trees or layer groups

During the workplace observation we saw users group layers, not only reducing clutter in their layer stack, but also for logically, when bits on the layers are part of the same concept.

Surprisingly, we saw users use layer groups to maintain versions of their file, labelling a group of all layers and then duplicating it to continue working on the next steps.

groups + sets

Groups are a physical organisation of consecutive layers, primarily used to reduce clutter. Here we see four layers organised in two groups:

The logical way to display this in the layer dialog is like above: vertical, to the side of the actual layers.

Sets are a logical organisation of layers. A set ties layers together to a single concept. A layer can be part of multiple sets. We see that here:

Sets, being distinctly different than groups, can be connected to any layer. Therefore it is logical to display sets different than groups in the layer dialog, horizontal, above the layer list, as shown above.

We conclude that both layer groups and sets should be implemented in GIMP, with distinctly different UI, as outlined above.

versions + approaches

Layer groups or sets are not the most elegant solution for maintaining versions of a file. A more straightforward solution is to build simple versioning in to the file itself.

When we allow during the lifetime of a file a certain state to be labelled, and allow users to return to that state later on, then we have versioning:

The user scenarios speak of ‘compare different approaches.’ This can be different artistic approaches, or different technical approaches towards the same result.

This is elegantly supported by allowing branch versions. Different approaches can be developed and compared directly within the file:

The introduction of GEGL will make it very natural to drag and drop ‘good ideas’ from one version to another.

Our conclusion is that versioning should be supported by GIMP, but not by abusing the layer stack. The key to success is to keep the versioning system as simple as outlined above, much simpler than the source control systems that developers use every day.

2. adjustment layers

This feature is perceived as powerful and we appreciate the immense value of being able to change your mind and readjust a graphics operation throughout the lifetime of the file.

The introduction of GEGL allows readjustment in a very natural way. Let’s say that we have applied levels–curves–noise–blur to a layer:

GIMP will show the performed operations in a list, similar to •1 above. When the image at this point is not punchy enough, there is nothing more natural than to select the curves operation again like in •2, and to readjust to taste.

Experimenting with the order of operations is as simple as dragging blur above the noise item in the list, as shown in •3.

as easy as 1‑2‑3

Architecturally speaking, the beauty of the layer system in GIMP is that the whole concept can be explained in a single sentence: ‘Layers are transparent foils with graphics, their stack forming the image.’

Introducing adjustment layers blows up this sentence into a full tutorial chapter. Architecturally speaking adjustment layers are a 90s highjack of an unrelated concept to achieve a certain goal: readjust operations later on.

Our conclusion is that adjustment layers are actually less powerful than taking full advantage of what GEGL can offer. We rather spend our effort on creating powerful control of graphic operations based on GEGL, than to introduce adjustment layers.

1. single window interface

During our expert evaluation we found that the inspectors have the status of real windows, which means they show up in the task bar. And they occupy 440 pixels of screen width, as demonstrated here on a 1024 screen:

Cramped is the word. At this year’s lgm the GIMP team decided that a 1280 wide screen is the minimum supported. 34% of that screen width is lost to the inspectors. Even a whopping 30 inch, 2560 pixel wide screen loses 17%.

Then there is the very disturbing situation of two menu bars. We first have to solve these issues:

Oh, better throw in our disclaimer…

Removed the extra menu bar, the inspectors have been made real floating windows. This means that the items in the task bar now match the goals of users: images. A crude scaling represents our goal to slim down the inspectors. They shall be lean and mean.

Finally, the semitransparent inspectors make that in user experience terms, we can claim those 440 pixels back to work on images. A majority of tasks can be performed under the inspectors. Yes, selected parts of the inspectors, like the color selector, will become opaque when users focus on it.

#1 trend

Only when having solved these issues, are we in a state to discuss a single window interface.

Interaction architecture—like traditional architecture—undergoes changing solution trends. And there is no denying that the latest big photo applications, apple aperture + adobe lightroom, come with single window interfaces.

And there is no denying that single window interface is by far…

So it is disclaimer time again. Starting from the improved situation above, the view can be switched with a menu item to this:

The inspectors have been docked to the side of the window, not overlapping the image, they are opaque again. Multiple open images appear in tabs. Inspectors can be torn off to become floating, and additional inspectors can be docked in columns for people with seriously big screens.

drawbacks

As shown, there is no overlapping of the inspectors and the image pane, and we are working under cramped circum­stances again. And having two different UI modes means double the documentation and double the support effort.

We have not reached a conclusion yet on the introduction of a single window interface. We are positive that the current situation needs to be improved.

wrapping up

And that concluded our presentation. I want to thank Kamila for working so hard on the project, and for presenting with me at the lgm.

Labels: GIMP, practical

—ps

14 comments, link‐ins, forward this posting:

     

lgm 07, top‑10 GIMP user requests

May 22, 2007, 01:12

After my project overview at the lgm conference, Kamila Giedrojć entered the stage to present with me the top‑10 user requests, and our solutions models for them.

Now let me say first here, that a solutions model shows the way forward, based on analysis of the user interaction aspects. It is not a finished solution. It takes quite a bit of work to solve and design all the details, and we are not in that phase yet.

It is both the direction of the solutions models and ensuring that the details do not undermine the concept behind a solution, that are the greatest contributions of an interaction architect to a project. Now without further ado:

10. better printing support

Starting with the product vision we see that it mentions high-end photo + original art. It is a matter of course that part of this work will end up on paper, for sale or exhibition.

It is important to realise that printing is fully part of the workflow, not an afterthought. Placing the image on the page is a creative step towards the final result.

Compare bog standard printing…

…to creative placement:

Our conclusion is that printing should be integral to GIMP, not an extra plug‑in. Furthermore we conclude that the place­ment of an image on paper is a creative, hands‑on affair.

This is done best by preparing the print in the main window, placing the image there on a virtual piece of paper with a tool similar to the new selection/crop tools. This should be supported by a handful of interrelated number fields for margins, image size and printing resolution.

9. painting with ‘natural brushes’

Returning to the discussion of the product vision, we see that GIMP is an application for working with existing images, not for painting from scratch.

Furthermore, nowhere during the whole expert evaluation did painting with ‘natural brushes’ rise as a secondary requirement for performing an essential task.

Our conclusion is that natural brushes should not be part of core GIMP, nor of the standard distribution. The beauty of the plug‑in system is that when somebody out there still feels the need for painting with ‘natural brushes’ they can write and distribute the plug‑in themselves.

8. improve the text tool

typography, along paths, geometric distortion

During the expert evaluation we observed:

• text being used in both original art + web graphics, both creatively and functional;
• no requirements for page layout functionality;
• at some point users have to make a choice: is this text pixel or vector based;
• requirements for text styling + typographical control, e.g. kerning and baseline shift, to be able to produce the professional results mandated by the product vision;
• the current ‘one text per layer’ doctrine is not practical. Producing ten buttons on a single canvas for a website, ten layers are needed to label them.

Our solution is to allow multiple text blocks within one text layer. Because they can overlap, they will have their own stacking order.

With the introduction of GEGL, users need no longer be concerned with the ‘pixel or vector’ question. And that can only be a good thing. Text will be editable until the end of time. It will be very natural to apply geometric distortion or pixel effects to texts.

7. save for web

Production of web graphics is part of the product vision. The user scenarios reflect this and the scenario for web images speaks of ‘export parts in optimised web format.’

kilobytes

It is important that web images are as small as possible. The ‘customer’ who commissioned the graphics is also picking up the bill for the network traffic they generate.

Combine all of the above with the fact that there are only a handful of web formats compared to more than a hundred in general. We conclude that save for web is a separate workflow where one compares the few web formats to solve the size versus quality question.

before + after

Does the quality of a jpeg compressed image needs to be compared side by side with the original? On the final website there is only the jpeg, and it either looks ‘professional’ or not. It is up to the GIMP user’s internal value system to judge what is good enough in each case.

Our solution is to reuse the main window for the save for web workflow, plenty of room to inspect the image quality. Standard zoom tools can be used to work at a level of detail where one is comfortable. GIMP can help with checking feasibility (gif) and doing the size calculations to recommend the optimal file format and ‘best’ default settings.

6. organise brushes, palettes, gradients in categories

Resources accumulate, and users ask for categories to break down their collections. The problem is that a resource (here a palette) can only be associated with one category:

This means that there is only a single way to find back the palette: via this one category. This is similar to files and folders: there are a lot of unfindable files hiding on your hard disk.

Tagging allows to attach multiple concepts to a resource:

For instance customer name; project name; that it is a warm palette; a retro palette. This means that the palette can be found back via any of these concepts.

For this to be successful, we need to create UI that makes it incredibly easy to tag resources with existing and new tags, whenever users feel like it, in an incremental fashion.

next…

That was to bottom‑5 of the top‑10. Read all about the top‑5 next time…

Labels: GIMP, practical, product vision

—ps

3 comments, link‐ins, forward this posting:

     

lgm 07, GIMP project overview

May 16, 2007, 19:53

A week or so ago, I delivered a presentation at the lgm conference together with Kamila Giedrojć, my associate on the GIMP redesign project. Instead of dumping the keynote slides in a pdf and making you guess what we said, I will recount the presentation here in three episodes.

I started the presentation with a project overview:

in the beginning…

It all started at the lgm 06. Or actually, two weeks before it. We were discussing at the openUsability meeting, when I asked GIMP maintainer Sven Neumann: ‘so, what is GIMP actually?’ Sven replied: ‘good question.’

Sven invited me on the spot to the lgm 06 and to work with the GIMP team to develop a product vision. That took two hours, the first hour consisting of me explaining the team why we actually needed one. During the second hour we created the product vision.

Here is what it looks like on paper:

Nice and short, it contains only the essential. And by being so concise, we are able to use it as a tool.

definitely not

At the same time we also discussed what GIMP is not:

not photoshop

this means that there is no obligation for GIMP to do things the photoshop way; there is not point to work on a project just to provide a free and open version of some commercial software;

also not painter

the focus for GIMP is to work with ‘found’ images;

not the only linux‐pixel‐oriented‐application on earth

in the old days, GIMP had to save the day for everyone who wanted to change some pixels on linux; today, GIMP has been released of that obligation, and its team can focus on high‑end use.

not a web page mock‑up application

I brought up web mock‑ups, but we realised that seriously supporting this would mean introducing a ton of functionality; it is better done in a specialised application.

real‑life balance

For interaction architects there is no such thing as intuitive interaction. However, we can talk about the 3E’s:

The triangle shows the relationship between them; the dot represents the real‐life situation that you cannot have it all. The trade‐off for GIMP is shown here: user efficiency (ease of use) is everything, with a nod towards ease of learning.

This can be derived directly from the product vision, which speaks about high‐end use and production of graphics.

This explains for GIMP users why it took considerable effort to learn to use the software. We cannot increase ease of learning, or we would lose out on ease of use. All we can do is make it a more gradual, incremental learning experience.

out of tune or auto‑tune

I like to compare this to learning to play the violin. For quite a while the results will be not pretty. But if you put in enough hours, the results can be beautiful, for both amateurs and professionals.

For developers this shows that hard choices have to be made in the UI design, in order to nail the right balance for the 3E’s.

getting involved

I would not have gotten more involved with GIMP if the team would not have managed to agree on a product vision. Without it any interaction architecture or usability effort is doomed.

Also the commitment of Sven to really change things for the better in the UI and the planned introduction of GEGL convinced me to get on board. We started with some ad hoc work on the selection/crop tools that will come out in version 2.4.

blastoff

Fast forward to August last year. In berlin openUsabilty, GIMP and m+mi works bundle forces to create the ‘season of usability’ pilot project. The news spread like wildfire around the world, and I selected Kamila to work with me on the GIMP project.

With Kamila working 20+ hours, and us having two–five meetings a week for the project, we really picked up some speed. To start with, my team needed an overview of all GIMP functionality. We need to know what we are talking about and I had set the target that it was going to fit on twelve pages.

Again I aimed to be as brief as possible, in order to create a tool instead of sprawling documentation. Two and a half months later we had it on eleven pages. And we knew GIMP.

plotting success

Meanwhile we held our scenario weekend, on which I reported here in detail. The result looks like this on paper:

Again, concise and essential enough to be used as a tool.

this year

At the start of 2007, we commenced with the expert evaluation. Taking the user scenarios as the guide to essential use, we took an architectural look at the current interaction of GIMP.

By the end of February we were through…

Notice the contrast between the user scenarios—short and essential—and the expert evaluation: deep, structural and architectural.

the road ahead

At the moment of writing we are working on the analysis. And with all the work done up to now the solutions models are coming easy. These show us the way forward for GIMP UI.

next…

At this point in the presentation Kamila entered the stage to present with me the top‑10 user requests that are UI‑related, and our solution models for those. Read all about it next time…

Labels: GIMP, practical, product vision

—ps

5 comments, link‐ins, forward this posting:

     

more printing in siena

May 01, 2007, 12:35

After the printing in siena blog entry, a healthy amount of discussion ensued in the printing community. Here are a couple of concerns that I need to address.

‘are you sure this is going to work?’

We are going to user‐test these three new solutions to validate them. If they do not work, we will improve them. If any of them still doesn’t work, we will trash them and go for plan B. This is usability at its best, validating before committing to write code. It is called verified innovation.

‘“just print” without a dialog? cannot work…’

An awful lot of printing today looks like this:

• user invokes Print…;
• dialog is shown;
• user presses Print button straightaway.

My analysis is that the printing dialog in these cases is actually obstructing getting the print done, because the user ‘knew’ that the print was going to be fine anyway, before invoking Print…

We have corroborated this already with user testing. ‘Just print’ has been conceived exactly for this ‘awful lot of’ printing. Nobody is forcing users to forgo the printing dialog, they can and will use Print… in case of doubt about the happy outcome of a print job.

‘but things can go really wrong without a dialog’

This is the reality of today’s printing dialogs: people who just want to print, don’t read them. In these situations they simply do not function as the point of final check and confirmation. You could write in the dialog ‘These print settings will get you fired…’ and without a hitch, the Print button will get pushed.

Thus showing a dialog with printer settings does not prevent in any way ink, paper and energy being wasted on a doomed print. So my priority is to offer those 95% of users 95% of the time the option they need: forget about the dialog.

‘is this like that print toolbar icon in word?’

The developer at microsoft did the following: He took the icon that for years and in thousands of applications has the meaning of Print… (show the dialog) and attached a different function to it (default print without a dialog).

Brilliant.

Attach a different meaning to a ubiquitous symbol. No interaction professional would do that. No wonder users are confused. We will do two things differently:

• two, clearly labelled, different UI paths for the old Print… and the new ‘just print’; two menu items, two key shortcuts, and if you must have toolbar icons, two clearly different ones;
• a smarter behaviour for ‘just print’ than the print‐with‐defaults that word offers today.

‘too smart by half’

I should have put in a couple of examples of the applications smartening up about the transformation. In siena we discussed spreadsheets avoiding to put the last column on a separate piece of paper; web browsers that instead of formatting for 2.03 pages, subtly get it on exactly two.

Or a photo application not printing on the laser printer but on the color inkjet. This all is applying domain knowledge within the application to get it done. And involves no heavy‐handed meddling in the printing parameters.

‘machines take control over humans’

We want the applications and printer drivers to learn from user’s preferences. I want the printing driver to figure out that I tend to print multiple pages 2‑up, and duplex where available.

siena leftovers

no clue

We discussed the error‐case when either the application or the printer driver really cannot figure out how to ‘just print.’ For instance, this can happen when an application is asked to print for the first time, or when a file is printed for the first time.

If this is the case the print dialog will be shown anyway. And from thereon the precedent is set for this situation.

subtle clues

Part of the ‘just print’ solution is that we subtly communicate that the print is preparing–queuing–printing–ready. So that when users want to, they can get confirmation about the status of the job.

For instance by putting an icon in the taskbar that reflects what is going on. When clicked it could show more details, but else it stays outside of the users’ workflow.

application integration

We also agreed that we prefer that applications integrate their UI for the transformation into the print dialog. This ties the transformation parameters to the preview in the dialog.

We realise however that there are applications where the transformation is a big deal, or a complicated job. An example of the former is GIMP where placing the image on paper is part of the artistic workflow, of the latter is placing a spreadsheet over multiple pages.

Then the UI for this has to be displayed before the print dialog. I think Apple is right‑on in this regard with their drive to get this to take place inside the application main window. And to supply users with hands‑on UI to take control of this transformation.

Finally, it would really not hurt if in this ‘on virtual paper’ view, a ‘just print’ button was offered to bypass the print dialog.

the future is bright

As I am writing this, we are sketching print dialogs. We are discussing usability surveys to get the most out of the tags concept. Stay tuned for more news on that.

Labels: GIMP, openPrinting, practical

—ps

0 comments, link‐ins, forward this posting:

     

creating user scenarios with the GIMP team

November 12, 2006, 04:09

I spend last weekend in the linux hotel in Essen, Germany, together with six members of the GIMP project team, Kamila Giedrojć and Ellen Reitmayr.

The goal was to create a set of user scenarios, a most vital tool in the further expert evaluation and upcoming redesign of GIMP. In a nutshell, user scenarios describe the essential usage of a piece of software. These are expressed in user goals, avoiding descriptions in terms of functionality or current UI behaviour.

preparation through observation

In the five days before this weekend, Ellen and Kamila had been gathering vital raw material by performing workplace observation. Half a dozen professionals in the field of photography and graphic design were interviewed and observed on the job. These participants had been selected based on the GIMP product vision.

The three of us analysed the results of the workplace observation together. This is an important aspect of a usability–interaction architecture co‐operation: streamlined discussions, and the ability to analyse interaction and usability together.

weekend kick‐off

Saturday morning, Ellen and Kamila kicked off the meeting with their report from the workplace observation. This already contained some eye‐openers for the GIMP team. I encouraged further discussion based on the findings and this lasted to well after lunch.

product vision driven

To develop the user scenarios I started with the product vision, to identify the scenario categories we should cover:

• high‐end photography;
• creating original art, from ‘found images;’
• icon editing;
• create web graphics;
• automate repetitive tasks.

For each category, we then filled in an essential scenario with the results from the workplace observation and the ensuing discussion. We then probed if further essential scenarios could be found for the category. That turned out to be either one or none.

So I was very pleased that by Sunday afternoon, we had eight user scenarios that capture the essential use of GIMP, in a powerful way.

direct results

Along the way some hard choices had to be made by the team about what workflow to support, and what to leave to other applications. Moreover, essential functionality has been identified during the weekend and implementation of some of it started right there and then.

Soon Kamila and I will release the GIMP functionality catalogue, and the user scenarios document. We will then move on to an expert evaluation of the current GIMP, and of GEGL, that is so much a part of the future of GIMP.

…on rails

On the train back to Berlin, Ellen and Kamila were dozing off after all the hard work during the weekend. Sven Neumann and I spent the time implementing my concept for rectangle + oval selections, in extreme programming style.

While Sven was writing and refactoring code, I worked on drawings and algorithms for the next step. I went through three algorithms for the corner handle size in as many hours: the concept was clear, but the algorithm needed refinement, until I nailed it.

This all in the shortest concept–implementation loop possible. As Ellen said: extreme usability.

Labels: GIMP, practical, product vision

—ps

1 comments, link‐ins, forward this posting:

     

selecting an associate for the GIMP

September 22, 2006, 12:26

I have just finished the selection procedure for the openUsability sponsored student project: GIMP. This is a project where I work with an associate interaction architect on revamping the GIMP. This project is also the pilot for the season of usability initiative.

From the jump in the server statistics for mmiworks.net I can see that the news of the student project spread around the net infectiously on August 11th. This caused a first wavelet of applications. We closed the application period a month later, the announcement of which triggered a second wavelet.

• fourteen people applied for the position;
• quite an international showing, with applications coming from Europe, USA, Russia and India;
• a significantly high number of applicants (5) were born in the countries formerly of the Warsaw pact, although only one was still living and studying in that part of the world;
• I selected three applicants for phone interviews, and all turned out to be from the Warsaw pact faction, maybe it is just something in the water…

criteria

So how does one identify an up‐and‐coming interaction architect? In the requirements section of the advertisement you can already see what I was looking for, but I will elaborate on those words here.

‘Interaction architects need to see from the user point of view, know what makes user interfaces tick, have a mathematical eye for the beauty of the simplest solution, a sense for clean layouts and know what can be developed in practice’

ps, in the original advertisement

multi‐disciplined

There are five disciplines in the quote above and I was really looking for evidence of all of them in the CVs I reviewed. And I was looking for balance. A straightforward university education in usability, graphic/product/interaction design, software engineering, mathematics or psychology can give you a background in at most 1½ of these disciplines.

This skews a CV and needs compensation by evidence that the applicant went out before or in parallel to the current studies to obtain a background in the other disciplines. No need for a handful of university diplomas, just any kind of experience that can give me a vibe of the particular discipline will do.

determination

Another vibe I look for in a CV is an absolute determination to make it in interaction architecture. This is still absolutely necessary in the software and web industry of today.

When graduates do not stick to their guns, the industry they enter will fob them off on jobs like UI or web developer, web graphic designer, functional analyst, requirements specifier, product marketing person or the token usability tester. All of these jobs leave zero opportunity to take charge and introduce solid concepts for interaction.

So absolute determination is needed for aspiring interaction architects in order break the vicious circle of no awareness in the industry of how strategic interaction is to their bottom line, and few jobs for interaction architects.

to be, or not to be…

A final point I want to touch upon here is the topic of owning ‘it.’ I reviewed several CVs of applicants who are totally fascinated by interaction, and are really determined to make it their profession. But they are still looking at it from the outside, looking forward to enter the field.

To get the job of associate interaction architect one’s to be one, no matter how little experience one’s got. It is a state of mind.

the result

After the phone interviews it was clear to me that Kamila Giedrojć is the applicant who meets the requirements above most successfully. I look forward to kicking off the project with her.

Labels: architects, fundamental, GIMP

—ps

0 comments, link‐ins, forward this posting:

     

working on the GIMP

July 06, 2006, 20:33

After a tentative start, I am getting seriously involved with the GIMP project. Long term, this is a very hot project for an interaction architect to work on. But for now Sven asked me to do some solutions consulting for the upcoming 2.4 release. So we met up on a warm summer’s evening, Mitch also joined. He has been working for a long time on solutions for the issue‐at‐hand.

shortcut shortage

The topic was building up a selection mask in the GIMP from simple shapes (rectangle, ellipse), combining them with not‐so‐simple shapes. There are a couple of categories of control over this process:

drawing constraints

constrain the bounding box of the simple shape to a square; draw from centre.

addition mode

operarator used to add a fresh selection part to the existing selection mask: replace / add / remove / ‘logical and.’

minute adjustment

move or resize the fresh selection part before commiting the result.

The questions from the GIMP team were:

• how to control all of these option categories from the keyboard, when the only two available keys seem to be shift and control;
• also the interaction of the third category (minute adjustment) was only part‐done, they were looking for ways to integrate it into the overall workflow.

deal with a problem: ignore it

The first thing I did was looking for ways to avoid conflict, to stop the three categories competing for the same keyboard keys. I lifted the third category (minute adjustment) out of the whole conflict, using interaction ingredients already present in the GIMP:

• eight resize handles, instead of four on the corner;
• I made the handles double the size (quadruples the area), and solid (instead of a one‐pixel outline) to speed up the interaction;
• a move handle in the centre of the shape.

With these simple rules, the resulting interaction is visible, direct, and on‐the‐spot. No keyboard required. I like that.

Further attempts to separate the other two categories (drawing constraints, addition mode) failed, so it was time for some hard choices.

fundamentals

Luckily, I had worked with the GIMP team before on defining a product vision, so we had a foundation to base decisions on. It all came together:

‘you know, these professionals spend most of their days building up complex selections’

Mitch, GIMP developer

That was what I needed. Because the GIMP product vision is to be a high‐end tool, the observation above puts the priority on controlling the addition mode. So I assigned the combinations of shift and control to that. I also discussed with Sven and Mitch how visual feedback could—and should—still be given, to indicate the current addition mode.

So what about the remaining category, the drawing constraints? Well, we noticed that the current addition mode is only significant up to the moment the mouse button goes down for drawing a fresh selection. From then on it is fixed until the resulting selection has been commited.

So I said: ‘can we detect whether the shift and/or control key go down after the mouse‐down, to apply the drawing constraints?’ Yes, we could. Problem solved, then.

in short…

A fundamental issue that has been a skeleton in the closet for years. To the developers it looks like an unwieldy mess that cannot be solved elegantly.

Two hours of working with an interaction architect, and with some easy to implement measures, the problem has disappeared. Afterwards, everybody looked relieved and bemused: ‘was that all there was to it?’

Labels: GIMP, practical, product vision

—ps

0 comments, link‐ins, forward this posting: