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:

     

next‑generation printing dialogs /4

October 23, 2007, 15:12

At the end of September the openPrinting summit was held in Montreal, Canada. I presented there an overview of eleven months of work on printing dialogs. A number of the summaries I made really drove the message home, so let’s have a look at them.

voodoo child

Everybody loved the motto ‘printing does not exist.’ As we found out during early usability testing, between the moment users think they want to see it on paper and the moment it rolls out of the printer, there is just one big blank. From users’ point of view, nothing worthwhile or productive happens in between.

My favourite equivalent is streetlights: infrastructure that no one notices, until one stops working. One implication of this is that we spend the most time working on dialogs with dozens of parameters that almost nobody uses.

Another is that it is not seen as a glamourous job to work on printing, by interaction folks or developers. Practically speaking, no developer is working to improve the rather dreadful linux printing interaction at the moment. And no one is queuing up to get started.

gold, silver, bronze

I also summarised the three levels of printing we support:

level one

An awful lot of printing is done where users know from the start that the print will be OK. All those emails that get printed. The second, third or umpteenth time that office document gets printed. An estimated 80–90% of printing is like this.

level two

Users need to check that the print will be OK. Or quickly check/set which printer is used. Or that this photo should be printed either swiftly or at super quality.

level three

Fine‐tuning of individual printing parameters. We are talking here about the last 1–2% of printing…

We will support level one printing with just print: an optional bypass of the print dialog. In the file menu—right after the normal ‘Print…’ item—there will be the option to ‘Just print’ (working title): it will skip the dialog, showing subtle feedback that the print is formatting–queuing–printing.

just in time assembly

When you get to level three, what does a good printing dialog look like? As I explained in my presentation: here we see the revenge of the five million use cases. Printing is a generic infrastructure service and I can only say: it depends.

It depends on the actual goals of that user. It depends on the context of the actual application where that user prints from. It depends on the actual printer. And only at the moment where the actual user + application + printer meet, I can answer that question.

That particular moment is when the printing dialog is opened. And that is why we are enabling users to effortlessly configure the printing dialog that is just right, for their goals, that application and that printer. And we will persist this configuration for exactly that user + application + printer combination.

version 0.4

Inspired by the discussions following my presentation at the Montreal summit and knowing the nagging problems that still needed to be solved, I did another round of redesign of the printing dialog. So again first our…

disclaimer

this is a pre‐release version of the design; there are for sure some things missing and small issues to solve; enjoy nonetheless…

First of all, I optimised the default appearance of the dialog for level two printing, concentrating on printer, preset & preview:

Gone are the tags at this level. Also gone are the orientation controls, because the checking of orientation is handled via the preview. A year ago I had identified ‘number of copies’ as the only universal printing parameter that makes sense for all types of printers.

Somewhere along the line I must have confused that with must be universally available. But it is useful only in particular situations, like making handouts. So it was also removed from this level. After all that pruning, it was logical to enlarge the preview area, to harmonise the design.

Let’s open up ‘Control printing aspects’ (animated gif)…

…and then we are at level three.

tags enter the matrix

A nagging problem that was still lingering was the appearance of the tags that configure the dialog. I just knew there are current‐generation UI controls that could serve as a model for this. I  found them in Apple’s Garageband:

These have the function of checkboxes—used to build up a list of selection criteria—but are more compact and neat, with less visual noise. Taking that as a starting point, it turned out that for us something even more compact, neat, with way less visual noise was required:

Call it a configuration matrix. It can be implemented with a table widget, but forget about just taking the default table widget. An exercise in toning down is needed to ensure that it stays in the background compared to more important elements in the dialog:

Note that the columns in the matrix have a variable width to optimise the space for the tag labels. The shortest sit next to the longest inside a 200‑pixel column. The mid‑sized tags sit together in their own 200‑pixel column.

To show the configuration matrix in action, here are all the combinations of three of the tags (animated gif):

More full‐size dialogs: first, second, third, fourth, fifth, sixth, seventh, last

more solutions

Eleven of the tags in the configuration matrix are reserved to be set up by the printer. The twelfth is reserved for the application name, top‐left in the widest column. This is the place where the application integrates if it has got a few printing parameters of its own.

Remember, if there are more than just a few, then an application is better off showing the whole transformation–to–paper process in its own main window, preferably with hands‑on UI to control it.

the gray zone

In praxis, some combinations of printer settings do not mix and match, so when one is set the other one should not be available. Example: folding and hole punching is not possible. Although better interactive UI should communicate that, the best we can do in praxis is to disable hole punching when folding is on.

To not leave users completely in the dark why a certain parameter cannot be set, I introduce a subtle icon next to it:

Clicking on the icon will bring up a dialog not only explaining why the parameter is disabled, but also what to do to make it active again. Hyperlinks in that dialog could show and highlight the necessary UI for that in the dialog.

blink revisited

Speaking about highlighting, we have combined tag–parameter highlighting (when clicked) to make a connection between a tag and its associated parameters and this is what looks like in this version (animated gif):

summit sumarum

The Montreal openPrinting summit got everybody in the printing community connected again. There is a sense of urgency that this is the chance in the next five years to get printing on linux sorted out.

Folks from both gtk and KDE were there and that gave them a jolt of inspiration to get ready to work on implementing these dialogs. I look forward to working with them.

Labels: openPrinting, practical

—ps

0 comments, link‐ins, forward this posting:

     

cross‑platform is bunk

October 11, 2007, 17:49

Picture this: m+mi works opens two more offices, in addition to our Berlin ‘headquarters.’ One for functionalist architects (sense and simplicity) in Amsterdam and a cool Mediterranean design studio in Barcelona.

Our company is then operating in three countries. All have a lot of EU law in common and quite similar culture, traditions and mores. It should be relatively straightforward to come up with a common management policy and house rules for all three offices.

holiday cramp

Let’s start with holidays, when our offices are closed. For all the common Christian holidays between the three countries, there are plenty of days where only one or two countries have a day off.

Of course I do not like the overhead of implementing and documenting different holiday schedules for the three offices. And I fear that co‑workers and customers in Holland will be confused when trying to reach our Barcelona office on a Catalan holiday.

not the only fruit

So let’s look at ways to arrive at a single, consistent holiday policy for all three countries:

preferred native solution

It is my company and I am Dutch, so I tend to see the holidays in Holland as natural. So we take those: my co‑workers and customers in Germany and Spain suffer.

grand compromise

also known as roll your own, if there are holidays on the eighth, eleventh and seventeenth, then we will have one on the twelfth: mass confusion among co‑workers and customers.

lowest common denominator

Only the holidays all three countries have in common are company holidays: too sparse a set of holidays, will really upset my co‑workers everywhere.

union of all

If it is a holiday somewhere, it is a company holiday in all three countries: now we got holiday bloat, co‑workers can’t get any work done, customers think we are always chatting in the café.

The lesson from all this is that there is no other choice then to grit our teeth, comply with the law, traditions and mores in each country and focus on doing the right thing for co‑workers and customers within the context of each country.

back at the ranch…

So what has this got to do with user interaction? Well, just like m+mi works operating in three countries, a lot of applications operate in up to four ‘countries.’ They are the macintosh, windows, KDE and gnome desktop platforms.

All four have a lot of UI guidelines in common and quite similar look + feel, traditions and mores, thanks to the Xerox PARC–macintosh bloodline. It should be relatively straightforward to come up with a common UI design for all four platforms.

cross‑platform cramp

But for all the commonality between the four platforms, there are plenty of interface guidelines where one or two or all are different.

In the fourteen years that I have worked on cross‑platform projects, the engineers have never liked the overhead of implementing and documenting different UI for the different platforms. And they fear that windows users will be confused when trying to use the same application on linux.

weasel out

So they look at ways to arrive at a single, consistent UI for all desktop platforms. And so in my career I have seen all variations of the bunker‑thinking above:

• forcing the original UI design upon all platforms; especially applications that started out on windows have this tendency: preferred native solution;
• roll your own look + feel, the Java route: grand compromise;
• use only UI elements that are available on all platforms; makes it impossible to create usable UI on any of the platforms: lowest common denominator;
• making everything available on all platforms; means re‑implementing something specific for one platform on all others: union of all.

All of these are as dissatisfying, confusing, infuriating, and user productivity wasting as the m+mi works holiday solutions. It takes a lot of convincing from my side to get the engineers out of their bunker and look at the matter from the users’ point of view.

The lesson from all this is that there is no other choice then to grit your teeth, comply with the law (UI guidelines), traditions and mores of each desktop platform and focus on doing the right thing for users within the context of each platform.

Labels: fundamental, practical

—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:

     

whistling in the dark

September 19, 2007, 23:24

Recently I worked on a project about which I can tell you—typical for my industry—nothing more than that it involves a hand‐held touch screen device. Exiting stuff, no?

Anyway. More interesting was that on our multi‐disciplinary team we had a dedicated sound designer: Aaron Day from Receive‐Transmit.

vroom

First of all his scope is not just sound, but the whole user experience. That made working with Aaron one of those rare occasions where I am able to communicate at native level and work together at amazing speed.

Not having to explain all the time how user interaction actually ticks really helps. This usually only happens when working with usability folks.

bleep

Now I must admit that for the last ten years, I had always thought of sound as something that users turn off. Working with Aaron changed all that.

He promotes the concept of ‘sound that is more felt than heard.’ This involves precisely controlling the vibrator in a hand‐held device, using it like an infrasonic synthesiser.

Then combine that with a bit of audible sound on top for some sharpness. Forget about the boring buzz from your current mobile phone. Instead, think of the click you feel when pressing a key on your mobile.

click

When Aaron asked me to select from a list of ‘sound opportunities’ the ones that really mattered, I said: ‘in those places where we lost the keys.’

By returning in this way the tactile feedback back to touch screen controls, you are able then to really enjoy the benefits: complete freedom to optimise the controls and their layout for every situation.

…

Another great concept promoted by Aaron is three overall sound levels:

1. hearing and feeling sounds: say today’s key tones;
2. ‘silent’ but you can still feel it: audible sound is still played, but soft enough to be drowned out by ambient noise;
3. really turned off: and now you miss the tactile feedback from level two.

Instead of the usual « I am really funny, listen to me » approach to sound, this set‑up will ensure that sound will really be a useful part of the user experience.

Labels: practical

—ps

0 comments, link‐ins, forward this posting:

     

next‑generation printing dialogs /3

July 23, 2007, 20:05

Another round of working on the openPrinting dialog. As it turned out, it was an exercise in detailed design solving general issues.

The first issue I wanted to tackle was the (not so pretty) vacant space in the dialog when no tag has been selected. So I took the scissors to the dialog:

The idea I wanted to try out was a fluid layout for the tags and a dialog that would be sized smaller in the ‘no tag selected’ case. I cut the tags section in even smaller pieces and shuffled around until the idea worked. Here is a sketch:

rinse and repeat

Also I wanted to address the perceived complexity of the dialog, the gist of the feedback I had received. For this I had to practice what I preach:

‘the most important aspect is that you are able to throw everything out and start again from scratch’

ps, whenever prototypes or mock‑ups are discussed

You have to stay agile as long as possible in a project. Else your hand is forced by existing drawings when trying to solve interaction issues. I ditched the visio files, visio itself, and the windows template. Moved on to omnigraffle, started with a clean canvas.

beyond the frame

I dealt with another issue at this point. Up to now I had been taking the window frame of the dialog into account. On linux the window frame can be any shape, graphic design and color.

To solve that, I literally took the window frame out of the picture. I deducted 30 pixels at the top and 4 for all other sides from the 640×480 maximum size we are working with and set my canvas size accordingly.

narrow down

I started with designing the smaller dialog for when no tags are selected. Before I show how that worked out, first our:

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…

It has also been a while that I have reminded us all that the design shown here is for general inkjet only. The other printer clusters will have at least a different set of tags—mapped to a different set of printing parameters—if not more fundamental optimisations of the dialog itself. Remember that one size does not fit all.

Here are some of the solutions I have put in:

• a slightly bolder appearance for the quick presets list, as it has a higher priority than all the tag and parameter stuff;
• sized the quick presets list items like I always intended: 1½ times the height of a normal list item, for a single line of label text; multiple label lines: normal size;
• shrunk the right column in the dialog to the size of the quick presets list (minus the scrollbar);
• flowed the printer + tags section into the right column;
• toned down the tags, which turns out to be quite tricky; it is easy to make them look disabled or not clickable at all;
• the return of the dogcow, to trace back our heritage.

This all sits inside the actual window frame. Before someone trips over the shadow: that is just a bit of ‘special sauce,’ to make it all come alive:

building up

Next, what happens when a tag is selected? The dialog grows so that the right column gets the same width as the middle one. The tags move up—elegantly—to make room for parameters. The gradient under the tags is not decoration: it forms the connection between the tags and the parameter area:

When more tags are selected, the dialog will need to grow vertically at some point to accommodate them. Before that happens, the tags can still move up a bit to make some more room:

Here are all the combinations of three of the tags, in all‑jerky, all‑dithered animated gif glory:

More full‐size dialogs: first, second, third, fourth, fifth

design on a toilet roll

If most users select up to three tags per application and with eleven tags as shown here, how many configurations are possible? Answer: two hundred and twenty.

How does the interaction architect that designs the dialog for a certain printer model stay in control of good UI, without being at the mercy of an algorithm or of the developer? Here is how it works:

1. take the complete list of printing parameters, say for general inkjet;
2. segment the parameters into logical sections, that make sense to users, as opposed to those that make sense to printer manufacturers;
3. design the UI for each section, on a canvas with the width of the right column in the dialog;
4. sequence the sections in a logical order, again a decision on a user interaction level; now you have designed a long column of printing UI;
5. decide on the tags using usability research and map them to all the printing parameters;
6. finished.

max headroom

Reviewing the list above I notice how similar the first four steps are to designing a contemporary printing dialog with tabs. I also notice an additional problem with tabs: you have to make a variable number of controls fit in an area of fixed width and height.

The problem is not having to fit a lot into a fixed area, you can always split it in two. The problem is having to fill out a fixed area with almost nothing. I can distinctly remember evaluating dialogs where desperate measures have been taken to make one or two checkboxes ‘fill’ a tab.

Our sections do not have this problem: at least their height adopts to any number of controls. A section with a single checkbox is perfectly OK.

gluing it all together

The following aspects make the steps above work:

• the interaction architect has absolute control over the contents: what is displayed and in what order; this includes the type of UI control: if a pop‑up list is the best solution, then a pop‑up list will be displayed; this situation is quite similar to content with HTML mark‑up;
• the dialog has absolute control over the presentation, it implements the UI style (KDE, gnome) and the UI theme; this includes all the margins between the items within a section and between sections; this situation is quite similar to a CSS style‐sheet determining the look of a website;
• when in the sequencing two sections need to be adjacent, this does not necessarily mean one above the other; they can also be placed side by side in two columns;
• not everything will fit the width of the right column, for instance when we get to work on the high volume printers, the booklet making section is going to be ‘interesting’ to design; the left column in the dialogs shown here is 128 pixels wide, the other two 200, so widths of 328, 400 and 528 are also available for exceptional interaction.

the parameter section is build up as follows:

1. the user‐selected tags determine the parameters that shall be displayed;
2. these parameters determine the sections that shall be displayed;
3. within these sections only the parameters that shall be displayed are laid out in specified order;
4. the sections are distributed—serpentine style—in specified order over the column(s) of the dialog:

wrapping up

‘It was an exercise in detailed design solving general issues,’ as I reported before. My intuition tells me that we can go one step further with simplifying the ‘no tag selected’ dialog, but that will have to wait for printing dialogs, round four.

Labels: openPrinting, practical

—ps

6 comments, link‐ins, forward this posting:

     

next‑generation printing dialogs /2

July 08, 2007, 21:35

For the openPrinting Meeting on the linux foundation summit in Mountain View, I prepared a presentation. I updated our mock‑ups of the printing dialog for the occasion.

As discussed last time, the usability team had some constructive critique for the first mock‑ups:

• printer selection pop‑up at the bottom? from looking at the task logic it needs to be at the top of the dialog;
• there can be confusion over what a quick preset does (change the printer settings, not any dialog parameter display) and what a tag does (change the parameter display in the dialog, not any printer settings); the dialog could do more to avoid this confusion;
• there needs to be a stronger relationship between the tags and the the parameters shown; a stronger showing of cause and effect.

starting at the top

I started with the first point, printer selection to the top. I noticed that choosing a printer configures the actual dialog: which quick presets are available, and which tags. Also, the tags purely configure the dialog itself.

Combining this led me to take printer selection and tags out of the content of the dialog and make them part of the frame of the dialog. This addresses in part the second point of critique.

Before I show how that works out in practice, first our:

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…

Keeping that in mind, here is the dialog in default appearance: no tag selected:

Note that I lightened up the quick presets list on the left, but the items are still nice and big for quick access. Also I wanted the tags to form a cloud with a loose structure. This whole top printer + tags section has much more a ‘written sentences’ feel than ‘controls on a grid.’

I have used color and position here to make the top section part of the dialog frame, to show the principle. However, on linux the dialog frame is set by the window manager, which can give it any shape and color. So later a different solution will be needed for KDE or GNOME and I will work with the developers of the Qt and gtk toolkits on this.

Also there is the ‘written sentences’ aspect, which becomes interesting with internationalisation for right‐to‐left languages. But nothing that can’t be solved.

pretty vacant

Here are some tags in action:

More full‐size dialogs: first, second, third, fourth

The big wide open space at the right of the dialog—when zero or one tag are selected—is not very satisfying. The dialog can be more compact in that case. However, keeping the quick preset list nice and big, and the overall dialog make‑up relatively stable, will require some fluidity in the printer + tags section. To be continued…

blink

To address the third point of critique I introduced animation when a tag is switched on or off, to show the connection between parameters and tags. I could have gone for the matching parameter widgets to fly in and out of the tag. Instead, I settled for a color highlight of the labels of said parameters:

coming up

Jan mühlig of Relevantive talked to me about a couple of quick rounds of usability testing. With both of us analysing the test results together and me refining the dialog concept in between every round, that makes a nearly ideal design set‑up.

I am looking forward to that and to report about it in printing dialogs, round three.

Labels: openPrinting, practical

—ps

2 comments, link‐ins, forward this posting:

     

economic outlook

June 16, 2007, 01:02

two interesting articles in this week’s The Economist. First one is the leader article that accompanies the cover:

Some of my favourite snippets:

‘…Apple illustrates the importance of designing new products around the needs of the user, not the demands of the technology. Too many technology firms think that clever innards are enough to sell their products, resulting in gizmos designed by engineers for engineers.’

‘But too few technology firms see “ease of use” as an end in itself.’

‘Listening to customers is generally a good idea, but it is not the whole story. For all the talk of “user‐centric innovation” and allowing feedback from customers to dictate new product designs, a third lesson from Apple is that smart companies should sometimes ignore what the market says it wants today.’

The Economist, Lessons from Apple, June 7th, 2007

economic brain scan

Second, there is the portrait of Mark Shuttleworth of ubuntu. More snippets:

‘A successful South African entrepreneur during the dotcom era, he wants open‐source zealots to lose their religion and concentrate on ease‐of‐use instead.’

‘…open‐source software lags behind in many areas too, Mr Shuttleworth admits. “The community tends to build for functionality, not for comfort,” he complains. “We have to inspire the free‐software world to make the user environment attractive. This takes an order of magnitude more work.”’

The Economist, Bringing free software down to earth, June 7th, 2007

business 101

The Economist sets the agenda for business leaders and other decision makers. The more remarkable then that innovation in user experience is in effect their front‐page story. The snippets above resonate with my everyday business.

‘by engineers for engineers’

This is the norm in software today. Remarkable are the few—and I mean just a few—pieces of software in the world that actually have a functioning user interface. I say it is remarkable that the world puts up with this situation.

One of the things I have to accomplish in each of my projects is to get accepted that UI decisions can no longer be based on the technical structure of the code, nor on the personal user preferences of the developers. They can only be based on solid interaction architecture.

‘an end in itself’

A decent UI is seen as a ‘nice enhancement,’ something we can work on ‘after we have shipped this important version.’ Somehow unusable, off‑putting or productivity‐wasting interfaces are not a serious bug.

The companies I work with are the ones who have realised that in any piece of software that has a UI, the value is created by users, and user interaction can make or break this.

‘ignore what the market says’

Software innovation is not born by listening to markets, and UI improvement does not result from listening to users. Both follow from a keen understanding of what markets or users need.

It is exactly this keen understanding of what users need that companies seek when they approach m+mi works. It is the essence of what we deliver.

‘concentrate on ease‐of‐use’

Usability of open‐source software is generally bad, but that of commercial software is only a fraction better. I see the factors of literally being made ‘by engineers for engineers’ and too much development at the whim of users contributing to the worse position of open‐source software.

The methods that I introduce in the projects that I work on have the same effect in the commercial and the open‐source world: a new awareness that we are not making the software for us, and that value and innovation is created within the project team, if we underpin the UI with a solid concept.

‘an order of magnitude more work’

Yes, it takes work to replace the unusable user interfaces of today with something that actually functions. We are not talking a slight tweak here. But that does not mean doubling the number of GUI developers, and therewith quadrupling the amount of discussion in the project team.

The companies I work with get the specialist in, to do the heavy UI concept work. This stops the discussions in the project team, and lets the developers concentrate on what they do best: engineering of user interfaces.

Labels: fundamental, practical

—ps

0 comments, link‐ins, forward this posting:

     

linuxTag, printingTag

June 10, 2007, 19:32

Last week the linuxTag expo and conference was held here in berlin. It was also the site for the openPrinting in‑between UI summit. I had set for this occasion the goals of showing mock‑ups of what we thus far had only been talking about and to start getting the linux UI platforms (KDE, gnome) involved.

from thoughts to paper

To prepare, I spent a day sketching the printing dialog, together with Andrea Alessandrini—my associate on this project. We had set ourselves the target of ‘fits on a 640×480 screen.’ Dialogs need a modest size, and this way it can still be used on mini‐sub‑notebooks.

In this dialog we have to show the sections that form the core of our solution:

quick presets

aka printing defaults; with one click, the printer is set up for what one wants to do: print a high‐quality photo, a document, some internet images; these presets ship with the printer for instant success, and users can make their own; quick presets need to be directly clickable, not in a pop‑up menu, else they are not ‘quick’ enough.

preview

a square area (shows portrait + landscape) where one can preview if the print is correctly transformed to paper; shows also staples, punched holes, duplex, watermark; includes controls for flipping through the pages; the preview needs to be big enough to be reliable, but no need to be able to read text on the page either.

tags

these stand for the aspects of printing that can interest users; by selecting one or more tags users configure their own dialog; using the tags should be effortless, users should not even notice that they are configuring their dialog.

printing parameters

these really control the printing in detail; the number of parameters that need to be displayed varies and depends on the tags selected.

Most of the day saw us probing where to put the tags, and how to cope with this seriously varying number of printing parameters:

from paper to screen

The weekend before the linuxTag was spent making mock‑ups of the dialog for general inkjet printers. Yes, they are in windows look + feel, but that happens to be a neutral position in the great KDE vs. gnome stand‑off. Andrea used visio, which comes with a windows l+f template, so we did not need to reinvent the wheel. But first:

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…

Keeping that in mind, here is the dialog in default appearance: no tag selected:

The quick presets are in the left column, with two buttons to add and delete presets. Tags are shown in the centre column, with the preview below them. The preview has a semi‐transparent heads‑up display for page navigation. In the right column are the printing parameters, showing here only the absolutely essential.

many–to–many

The tags shown are just examples to demonstrate that they do not only cover technical aspects of printing, but also user experience aspects. Here is the relationship between three of the tags (left) and their seven parameters:

Note how each tag is connected to a low number of parameters. And how two of the parameters (N‑up, Print quality) each belong to two tags. The parameter section builds up according to the tags selected:

Full size dialogs: 1 tag, 2 tags, 3 tags. Which tags were selected will be persisted on a user + printer + application basis. This means that users optimise the dialog for each application they print from.

When even more tags are selected, The dialog will grow vertically to accommodate the extra printing parameters. The centre and right column have the same width, so parameters can be placed in both.

design decisions

The actual tags, parameters and their mapping come straight ‘from the printer,’ e.g. the driver or the PPD. It is ultimately the interaction designer that works for the printer manufacturer who decides what makes sense for a particular printer model.

Our team will set the standard here by designing tags and mappings for the seven printer clusters that we are working on. Usability surveys and test will be used to funda­mentally answer the question ‘what aspects of printing do actually interest users?’

think different

For manufacturers, the tags are an excellent way of differentiating themselves. Not by introducing a tag ‘manufacturer xyz’ and associating some proprietary parameters with it. Instead, by representing unique benefits with a tag:

Say a manufacturer has a line of office printers of which the unique selling point is that these make your meetings 33% shorter (cool). Then introducing the tag ‘Shorter meetings’ and associating the parameters that enable that is the way to go.

expert evaluation

At the linuxTag, the openPrinting interaction architecture and usability team met, together with project organiser Till Kamppeter. The usability and interaction experts present (Celeste Lyn Paul, Jan Mühlig and me) discussed the dialog mock‑ups.

We found the concept in general really promising. It can be a definite improvement over the current printing dialogs of any desktop platform. But:

• printer selection pop‑up at the bottom? from looking at the task logic it needs to be at the top of the dialog;
• there can be confusion over what a quick preset does (change the printer settings, not any dialog parameter display) and what a tag does (change the parameter display in the dialog, not any printer settings); the dialog could do more to avoid this confusion;
• there needs to be a stronger relationship between the tags and the the parameters shown; a stronger showing of cause and effect.

These combined would probably cause this dialog to fail a usability test. The good news is that for us it is straight­forward to sit down and solve these points. We are working on it.

automatic for the people

I was anxious to hear what Josef Spillner, our resident guru on auto‐configuring dialogs, had to say about the feasibility of our concept. The fact that parameters can belong to multiple tags makes for tricky grouping of parameters. This is not your fathers’ dialog with tabs:

Full size dialogs: first, second, third

Josef thinks that he and his team can crack this puzzle. We discussed the additional challenges of keeping parameters grouped in a logical way and giving the interaction designer that works for the printer manufacturer the means to override the auto‐configuration in exceptional cases.

all aboard

The first contact with folks from KDE and gnome and their respective UI toolkits, Qt and gtk, was very encouraging. My demo with the mock‑ups created a lot of enthusiasm, and the tag system was perceived uniformly as ‘very cool.’

LinuxTag was the first step on the road to cooperation. In the next weeks more steps will be taken, together with both the gtk community and Trolltech.

Labels: openPrinting, practical

—ps

3 comments, link‐ins, forward this posting:

     

teaching interaction

June 06, 2007, 00:43

Mid‐May I was for a week at the FH Vorarlberg, Austria, to teach interaction design. I had arranged for the students to work in project teams: to create a concept for real‐world software, under real time pressure, with a real presentation at the end of the week.

I had asked the students to prepare by reading specific articles about activity based design and my own methods. However, they not know what software they would be designing for. Let’s jump in like they did.

monday morning, 9:00

After getting acquainted, I introduced the software we would be working for: ksysguard, performance monitoring for KDE. Showing processor; memory; network or disk usage, et cetera.

design brief

When I first put my eyes on ksysguard, I thought ‘this application needs an overview,’ a summary that shows the essential. So I set the goal to design a cool object for the desktop, that at a glance informs about the performance and stability of the local or a remote machine.

Oh, and anything that looked like the same old graphs that have been around for twenty years was forbidden.

first things first

While preparing for the course, I had interviewed our customer, the developer of ksysguard, for several hours via irc. It was a typical interview to find out the product vision of the software: what it is; who should be using it and what value does it deliver.

I went with the students through the complete interview, then we discussed and wrote down a product vision:

ksysguard allows to monitor different soft‐ and hardware parameters that influence the performance and stability of a local or remote computer system.

It allows tech‐knowledgeable users, or admins of a few computers, to detect and go to the bottom of (rising) problems, and do something about them.

product vision of ksysguard

The product vision was then approved by the developer.

User scenarios could be skipped for this project. I realised that there is not a wide variety of use that needs to be reduced to the essential. We spent the rest of the day sorting out the functionality that should go into our desktop overview, according to the product vision.

tuesday…

…concept day. I divided the students into two teams and sent them on their explorations. They had to solve the problem of mapping these machine parameters (processor, memory, et cetera) to different display dimensions.

The display dimensions include space, 2‑D or 3‑D; color; transparency; time; texture and animation.

vision driven

Being the part‐time team leader of both teams, I maintained the overview for both teams and ensured that they were solving the right problems. I encouraged the good concepts they came up with, and steered them towards alternatives for the not‐so‑good.

Time and time again, I made a team check the product vision, to focus on the ultimate goal. Aspects like ‘monitor’; ‘performance’; ‘stability’; ‘detect and go to the bottom’ had to be realised by us.

wednesday

The concepts where gelling, we moved from pencil + paper to mouse + screen to prepare for the presentation. An A0 poster and a short animation film had to be produced.

I focussed both teams on producing the minimum of concept visualisation that would have a maximum of impact. One should not have too much blood, sweat and tears invested in a concept, to be able to ditch it when a better solution crystallises.

The teams moved out of our classroom. Christian and Andrea (team 2) worked in parallel at the mac‑pool…

…while in their atelier, Katharina and Verena (team 1) worked on opposite ends of the project:

thursday

Crunch time. In the morning I had both teams sketch out a quick script/storyboard for their film. This way they could keep track of what they really needed to produce and I knew they would not lose the plot.

I showed the teams how to structure their poster. Instead of just showing all the cool stuff, it is better to show first that it was not divine intervention that produced the design, but methodical work.

friday

Usability day at the FH Vorarlberg. Theme: ‘inform with computer animation.’ It was no coincidence that my course was tacked before the uDay, it gave us a real deadline and a real venue for presentation.

I had selected ksysguard from the list of projects at openusability.org because of the animation angle. Animation comes natural when handling real‐time data.

showtime

Bleary‐eyed from finishing the film and poster the night before, we exhibited throughout the uDay to usability and animation professionals:

I made that into a crash course in engaging people at exhibitions or trade fairs. And an introduction to the number of interesting conversations one can expect during such a day.

Visible in the photo above are the posters:

Watch out, those pdfs (1, 2) are 3.3 MB large. Now, let’s have a look at the individual concepts.

team 1

Disco mirror ball; Saturn ring; lava lamp; the meatball in the pea soup. It was fun discussing concepts with Verena and Katharina. But as usual, these far‑out discussions delivered results.

See the film on youTube.

I am impressed with how they use two dimensions of the ring to display on. On the side of the ring is the instan­taneous value of load and cpu usage, and on the top of the ring is the five‐minute history of both:

They did have to take the hard choice to not go into multi‐processor details here, but that choice paid off handily.

I also like a lot how they used animation to display a parameter. When a disk partition starts running out of space, the green fluid starts bubbling, lava lamp style:

The more critical the free space situation gets, the more hectic the animation becomes: cool metaphor.

For more details, check out the poster.

  The work of team 1 is licensed under a Creative Commons Attribution‐Share Alike 3.0 License. The authors are: Verena Mayer, Katharina Seidowski and peter sikking.

team 2

‘Circles must be in fashion this year’ I thought when I saw the lyrical sketches from Andrea and Christian. On that Tuesday team 1 was also ‘going in circles,’ and I feared we were going to end up with very similar concepts.

See the film on youTube.

I am impressed with how they worked hard to keep the ‘nothing to worry about,’ everyday look of the desktop object very clean by employing several strategies:

First, they introduced a level of drill‐down in the desktop object, displaying details in ‘pods’ around the central ring. This way details for up to 16 processors cores; disk partitions or memory hogging applications can be shown:

I like how this enables users to monitor details of one parameter for a while.

Second, when an certain parameter needs user attention, then the ring that represents it not only gets an opaque centre, it also grows in size:

This is a clever use of screen space. Whenever users’ attention is needed or users focus on details, most of the overall circle is used for that.

For more details, check out the poster.

  The work of team 2 is licensed under a Creative Commons Attribution‐Share Alike 3.0 License. The authors are: Andrea Thum, Christian Haudum and peter sikking.

looking back…

I had a great time teaching at the FH. I would like to thank Philipp von Hellberg for cooking this up with me, and the FH staff for making everything run smoothly.

And thanks to Katharina, Christian, Verena and Andrea for working so hard with me on this project.

Labels: fundamental, practical, product vision

—ps

0 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 preparin