publications

working on a vision with Krita

March 05, 2010, 16:42

Last weekend I was at the Krita sprint, to work with them on defining their product vision. And hey, while I was there anyway, I could also help them with some UI first aid. Krita could simply not continue without having a vision. Without a clear definition of what they are trying to achieve, the project was threatening to go nowhere, at an ever-slower pace.

british invasion

Now, I would hate to see that happen. Similar to the Beatles and the Stones, the animosity between free/libre graphics projects is blown out of proportion by the fans. The Jagger, Richards, Lennon and McCartneys of GIMP and Krita get along just fine.

GIMP definitely does not try to be the graphics application for everyone. So there is plenty of room for other applications to address user needs that GIMP does not want to cover. And although GIMP, Krita and other apps may have quite a bit overlapping functionality, their product visions may be different enough to prevent them from being direct competitors.

Even then, I would not have been upset if a large overlap with GIMP had been the result of Krita’s vision. I was simply curious to find out what it was. So I offered my services and got to play Mr. Wolf for a weekend.

life is a beach

These days I have have some criteria for doing pro bono jobs like this. Is it going to be fun? Is my work going to be appreciated? Am I going to work with some great people? Do I look forward to the travel and the location? It better be good. The Krita sprint ticked all the boxes.

Hospitality was great and the location could not be farther opposite to ‘air conditioned conference room at the airport hotel.’ Working in the living room of an old house in the middle of the historical town centre is a treat. I had never been in Deventer, but it turned out to be almost an open‑air museum of a cute, old Dutch town.

hashing it out

Our vision session was on Saturday morning and it felt very much like when I started working with GIMP: OK, it’s a graphics application but what are they trying to achieve? The impact of this was demonstrated the night before, when the Krita team was discussing some of their UI problems and I realised that without a product vision I simply was not able to help them in a meaningful way.

So on that morning we sat down and I explained to them that I was there as the interaction consultant and not as the‐man‐from‐GIMP; that I always do this method at the beginning of all my projects, starting as a complete outsider; that it is their vision, because Krita is their life; but also that their vision has to be formulated through the eyes of users (they don’t care that Krita is written in C++, for instance).

the knockout

Then I set them off with the three magic questions—what is it, who is it for and where is the value?—and moderated the session from there on. I made sure that we got definite answers on all the questions, even when having to make a choice was no fun. I also made them realise how much hard work there was involved with stating to support certain user needs.

Before I travelled to Deventer I was both anxious and curious about the Krita–KOffice situation: a paint app with natural brushes as part off an office suite? The discussion of this took its time, stretching our session beyond lunch.

Essentially, all I had to do was show them that there were only two options (make sense of Krita being part of KOffice, or leave) and insist that they did not dodge the question. It turned out that Krita was already on a path of severing ties with KOffice and we reflected that in the vision by not mentioning the latter at all.

putting it all together

After the session I wrote up the vision, short and sharp, I like it that way, so it can be used as a tool in the project. After useful feedback by the Krita team and a final adjustment, it was ready for prime time:

‘Krita is a KDE program for sketching and painting, offering an end–to–end solution for creating digital painting files from scratch by masters.

Fields of painting that Krita explicitly supports are concept art, creation of comics and textures for rendering.

Modelled on existing real‐world painting materials and workflows, Krita supports creative working by getting out of the way and with snappy response.’

the Krita product vision, as written by ps

I am really happy how coherent their vision turned out to be. Funny enough, there is about zero overlap with the product vision of GIMP.

Krita’s maintainer, Boudewijn Rempt, did an excellent write‑up of the far reaching implications of this compact vision. After he published it, he remarked that he could feel how carefully the words had been chosen and placed by me. Yes: nothing is a coincidence in there, it all fits together like an intricate puzzle.

instant karma

The product vision was immediately placed on the Krita website, signalling what was already going on at the sprint: thinking, designing and working in a new, clear context.

Suddenly there was a clear basis for deciding which plugins should be removed from the standard distribution and moved to a online repository of user‐installed options. The vector tools are receiving a hard look at the moment, now that the focus is so solidly on painting from scratch.

the Bonnie situation

With a product vision, I was able to help them with many a UI topic. We worked on the pop‑up palette; brush engine parameter input; the overall activity of setting up a brush, just right; brush presets, managing and using them; a strategy for dockers and dialogs on screens small and large.

I brainstormed UI ideas; rejected many bad UI solutions from a passel of other paint and pixel apps; made concrete solutions; outlined direction for big issues; connected the dots between related UI issues; concentrated on what it should feel like to work with Krita; I showed how even within the compact scope of the vision, plenty of diverse use has to be supported.

One thing I emphasised was to move away from ‘how would I like it’/input of a few users/looking at other apps for UI solutions. That is not the way to create UI, I’m afraid. Instead, the Krita guys should build up an understanding of the activity of many users that fit their vision and always make solutions for a hundred thousand of them.

different strokes

It was interesting to see for me that solutions that I am working at for GIMP would not be fitting for Krita. This is not only a matter of having different visions—although it suffices. I noticed that also the different as‑is situation creates different context and leads to different UI solutions.

Wrapping up, I want to thank the Krita team for the great cooperation during the sprint weekend. At times it was quite intense, but always in a positive atmosphere. It is very gratifying for me to see in Boudewijn’s and Cyrille’s blog how they are charging ahead with their new‐found élan.

Labels: GIMP, practical, product vision

—ps

3 comments, link‐ins, forward this posting:

     

from open source to symbian

November 03, 2009, 19:42

Last week I was in London, at the symbian foundation and SEE2009. The reason for that is that I am a complete schizo. Well OK, not really. Let me explain: there are these two major—but completely separate—themes in my career as an interaction architect.

First one is mobile. For more than twelve years I have been working on fundamental and application interaction design for mobiles. There are more than half a billion mobiles around with software that I designed.

These days at m+mi works, I am fortunate to be lead interaction architect on some of the more interesting mobile projects, solving their fundamental challenges; I enjoy mentoring a next generation of mobile interaction designers for our clients; and I provide deep analysis of mobile usability test results, showing cause and solutions.

the other peter…

The second theme is open source. Since 2005 I am involved in the open‐usability scene in Berlin. You can read all about my involvement with openPrinting and GIMP on this blog. However, there is no mobile in my open source work and no open source in my mobile work. That’s the schizo split. It was because of GIMP that I ended up in London.

When Scott Weiss, UI technology manager at the symbian foundation, adopted our UI brainstorm to start the symbian UI brainstorm, I got in touch with him. A good talk resulted in an invitation to do a presentation during a symbian foundation UI workshop and to take part in a panel at SEE2009. Both with the aim of sharing my experience in working with open source projects with key players in the mobile industry.

fast forward

The condensed version is that commercial and open source work are 90% the same. Which means that everything learned in commercial projects can be used in open source. And vice versa, new methods I developed for open source projects get used in my commercial work.

The 10% difference is openness —surprise!

This openness creates an interesting dynamic where users are literally using today what was programmed yesterday. And that for serious work. This allows for experimental modes of interaction design and creates unique opportunities for usability testing.

However, as I have explained before: without usability or interaction design experts on the project, the very direct contact and feedback between users and developers in open source only leads to awful usability.

seriously

Working on open source is not just a hobby of mine. It is a strategic activity for m+mi works. By working openly and publishing about it in this blog, we have a fighting chance of making understandable what interaction architecture is. And making clear that it is missing in most development processes today.

You will notice that this blog does not talk about all that mobile work that we do. All of it is under NDA. Which is logical—in a closed source way—because yes: interaction architecture is highly strategic. It fully determines what a product or piece of software is, for its users.

feels like yesterday

As part of my presentation, I recounted how my involvement with GIMP started; talked about methods like the scenario weekend; gave examples of ideal cooperation based on infectious enthusiasm; and of course told the story of the making of the brainstorm.

At the SEE2009 panel, form, audience and the venue were different, but above condensed version was woven into the narrative of the panel. Both the workshop and SEE2009 turned out to be good opportunities to meet interesting people. I thank Scott for inviting me to be part of it.

More related musings in a couple of days.

Labels: fundamental, GIMP, practical

—ps

0 comments, link‐ins, forward this posting:

     

GIMP redux, single‐window mode

September 18, 2009, 19:19

This blog entry covers the final part of my talk at the libre graphics meeting this year, after dealing with the schmuck and squaring a circle. It will also be pure falsification of history, Soviet‐style: I used my talk to kick off a discussion and to start the design process. Most of the interesting things I am showing you today were not even conceived when I delivered my lecture.

real history

Here is what was presented at LGM: First, I set the mood by showing a selection of single‐window contributions from the UI brainstorm:

The high number of contributions in the single‐window category confirms that this is a major issue where action needs to be taken. The many forms the contributions take shows us that a measure of flexibility and configurability is needed.

Next, I reminded everyone that it is a fifty–fifty world: about 50% of GIMP users love the multi‐window interface of today and do not want to lose it, about 50% of GIMP users would love to move to a single‐window interface.

one switch

With the world fifty–fifty split, we will serve them with one switch in the Windows menu, switching between multi‐and single‐window mode. I used the mock‑up with the beautiful orange sports car from the brainstorm to demonstrate the basic idea (no real UI design implied here).

When set to single‐window mode, each document will appear in a tab:

the toolbox and inspectors can be ‘torn off’:

here the toolbox is side‐docked back and it is shown how the inspector floats:

and last, inspectors can be made multi‐column. Here, another column has been created to allow more dockables to be organised:

The eagle‐eyed will see that there is quite a bit of fudging in those images, so don’t sweat the details.

three problems

I closed off the talk with three things that were bugging me at the time:

no tab tear‐off

tearing off a tab and making that into a separate window—as seen on web browsers—would make our single‐window interface into a multi‐window interface. How annoyingly inconsistent.

no side‐docking, to multi‐windows

both toolbox and inspectors are unique for the application and by nature there are multiple window instances. That means it is unnatural to dock the toolbox and inspectors to windows. It is however possible to introduce multi‐column inspectors for multi‐window mode.

no image comparison

With tabs, only one image is visible at the time. Thinking about clever plans to see two images side‐by‐side in split panes, one sees immediately the confusion rising: which is the image that the menus perform operations on. Which one is shown in the layers dialog?

tomorrow starts now

So far, so predictable. Here is where the interesting stuff starts. After my talk I had a good round of brainstorming with Martin Nordholts on the tear‐off and comparison problems. The result of that is what I call the polaroid.

To demonstrate it, let’s say one is still working on that lovely orange sports car and in a second tab we have loaded this image of a cool Ferrari Berlina:

Now we want to compare our orange creation to the Ferrari. All we have to do is to tear off the Ferrari tab and presto: a polaroid of it appears:

This is not a GIMP image window. It is not even a window, the window manager will know nothing about it. We avoid making it look like a window, down to ignoring the theme colors and executing the control strip at the bottom in paper white. You can move and resize the polaroid to your heart’s content, as long as it fits inside the GIMP window. You can zoom, pan and look at it, and that’s all.

voluntary confinement

That last point will be very hard to do, because everybody will be thinking of one little feature they would like to add, for themselves. But we have to be strict here to avoid mass confusion: every toolbox tool, every menu item, every dialog (in an inspector) only operates on the front tab—the orange car in this case— and never on a polaroid.

For example, when I discussed these plans with GIMP‐usability contributor Ellen Reitmayr, she asked: ‘so can you then select and copy a bit of image from these [polaroids]?’ Good question. After realising that this would mean interacting with the layer stack and selection tools, the answer has to be no.

It is however possible to open multiple polaroids of the same image. And also of the image in the front tab, where one is working on:

As you can see they can overlap and they will have to have their own stacking order. Just click on a polaroid to raise it to the top. The final thing you can do with a polaroid, is to close it…

the decline and fall of tabs

This is how things were more or less when I returned home from LGM. At that point there were still three things that were bugging me about using tabs in single‐window mode:

1. too easy, too fast: the tabs got adopted from web browsers, without much thought;
2. it would be rather logical to use a thumbnail on the tab itself to identify the image;
3. sign of the times: the web browser folks themselves are looking at solutions beyond tabbed browsing.

And pretty soon I was looking at the image parade you see these days in many a photo app and viewer, mainly triggered by a visual association with a row of tabs with thumbnails on them:

There are some really interesting possibilities, when we replace tabs with that. Let’s try it out:

We see three open images and like you would expect, clicking on an image makes it the active image (the ‘front tab’) and dragging any of them up or down enough ‘tears’ it off to become a polaroid. A mouse‐over tooltip will display more info for each thumbnail, for starters: the filename.

history repeating

Now let us go a step further and not only show open images in the parade but also recent files that have been opened or worked on, the history:

Everything is in strict chronological order: open a file and it moves to the front of the parade. What I find very intriguing is that the notion of which file is open starts to blur. Having a file being loaded from disk becomes a side effect of clicking it to make it the current file. Similarly GIMP can decide to start closing files with no unsaved changes when there are too many of them open and memory gets tight.

My current thinking is that it is not necessary to mark files in the parade as being open. The concept quasi disappears for users. The white stars indicate unsaved changes.

One or more graphics files that are dropped on the parade get added—cued up if you want—right after the open files. Just as useful will be that a folder dropped on the parade cues up all the graphics files in it. Current work + history + cued up work + polaroids has a lot of potential, I think.

the Midas touch

I realised that it would be an eyesore and an absolute waste of space to introduce a scrollbar for the image parade. Still, it is going to scroll. It happens to be that in the last couple of years I have been working for two large companies on the interaction fundamental’s of iPhone competitors.

So how about using touch UI? A flick or a drag along the parade scrolls it; a push slows down, then stops the scrolling; a tap on a thumbnail makes it the current file; a flick or a drag of a thumbnail perpendicular to the parade creates a polaroid: it is perfectly doable, using mouse, trackpad or tablet.

non‐preferential customisation

All we need now, is some more flexibility. First, I think everybody will have their own idea what the right size for the image parade is. From pretty small:

to pretty big:

I think any size in between those has its purpose and why could that not depend on what one is doing next? Simply grab the dividing line between parade and canvas and adjust to fit your mood. Next, does it has to be at the top of our window? Left, right and bottom should also work:

I foresee every GIMP user having their own sweet spots, when it comes to combinations of size and orientation of the image parade for the type of projects they do.

raising the dead

It will not be necessary to introduce new items in the preferences dialog for anything I have shown you here. In that light I called during my LGM talk preferences ‘the graveyard of many a good idea.’

For configuring the image parade I have already built in a settings pop‑up in all the screens you see above. The top/left/right/bottom setting will be in there, as will be one for controlling the amount of history. Something along the lines of: 48 hours; a week; a month. And for those who never look back: a setting for no history at all.

red hot anticipation

To wrap up, for about 50% of GIMP users the good news is that single‐window mode is coming, complete with tear‑off toolbox and inspectors; multi‐column inspectors; polaroids; image parade with history and cued up work; touch UI and quick and easy customisation.

And it is coming faster than you’d think. Martin is ready to develop it for version 2.8 and this blog post was hotly anticipated to outline my complete plan.

For a different 50% of GIMP users the good news is that multi‐window mode is here to stay. It will benefit from multi‐column inspectors being introduced. But I actually expect that once single‐window mode is out there, there will be pressure from the community to have a look if multi‐window mode cannot be done a bit more, well, modern.

Labels: GIMP, GIMP redux, practical

—ps

71 comments, link‐ins, forward this posting:

     

teaching interaction /09

July 28, 2009, 14:40

At the end of May it was again my pleasure to teach interaction design at the FH Vorarlberg, Austria. I will discuss what was new and notable compared to last time, show which new GIMP functionality we worked on and then present the results.

full intent

Kicking off with ‘what’s different?’, I had fine‐tuned the goals of my course:

structure, structure, structure

If there is one thing I want my students to take away from this course it is a project structure that enables them to tackle any (interaction) design project. I took the structure and methods used in my daily practice and condensed them to a project survival guide. In a fine example of ‘the medium is the message,’ these structure and methods also form the programme of the course.

true interaction

Furthermore I want to introduce the students to what pure interaction design is and what it takes to do it professionally. I chose our design project such that no one could simply fudge their way through using visual design or information architecture skills. How the interaction flows in time is our focus.

The title, interaction design for the real world, reflected that once again the course was all about working on a real design project on real software. New this year was the increased ‘real world’ focus, where for many aspects I related to the students how these are ‘business as usual’ for interaction architects: to deal with certainty with the uncertainties of any given project.

time + space

The time set‑up was different this year, with three full days of working together at the FH and the students sending me their final work two weeks after that. Also different this year was that my course was fully booked, with sixteen students participating.

I divided the students into four design teams and used our three days together for intense and full‑time design work (hey, just like the real world…), using the structure: day 1: from 0–to–100 on the project, ending in an expert evaluation; day 2: brainstorming to create as many solution options as possible; day 3: narrow down to a single design concept.

Each team had to then deliver a design concept document two weeks later. Looking at what could be achieved in three days, I set the scope of this document to be a project‐internal briefing, for the principal interaction architect.

GIMP + vector

On to our design project. I want that the work produced during this course ends up contributing to the real word. So I chose GIMP as our ‘client’ to design for, because I can ensure there that interaction design is advanced towards implementation.

During LGM the GIMP team discussed readying last year’s SoC vector layers code for inclusion in GIMP v2.8. That was exactly the type and size of interaction design project I was looking for. I will now introduce the material my students started out with.

The proof‐of‐concept code allowed to take a path:

and convert it to a vector layer, receiving an outline stroke and/or a fill:

the shape of the vector can be changed for ever like any path, and when not edited display like this:

the fill and stroke parameters could be found and changed in one dialog:

and that was it.

spoiled for choice

The exact set of functionality (aka features) has a major impact on the interaction design and interaction architects have to rightsize this set before even starting to think about interaction. Usually this means fighting too many features, since anybody—developers; users; marketing folks; managers—can come up with more features.

In our design project, there was plainly not enough functionality to be useful/usable. So before the interaction designing started, each team sat down to brainstorm and then decide on their essential set of functionality. What struck me at the start of this phase was to hear talk of ‘window’, ‘click’, ‘button’, ‘slider’, et cetera.

That had to stop immediately. It took a couple of rounds of explanation—‘it is just a boring list of what functions it has’—to get the cold, analytical side out of my students. But then they were on top of the functionality, as it should be. As we will see next, functionality like vector layer management, managing and combining shapes and working with simple shapes (rectangle, ellipse, etc.) was integrated.

four team results

Now the grand finale, the results of the four teams. First let me make clear that the work of all four teams is available under GNU Free Documentation License 1.2. I present them in team order.

team one

• members: Andrea Chavez, Christoph Bischof, Julian Tomaselli + Tamara Christina Blumer
• design concept document (pdf, 2.7 MB, limited pdf viewer compatibility)

Team one was the one with the hottest debates. That may sound a bit inharmonious, but it was good to see the whole team so worked up about making good interaction.

The main theme every team fundamentally had to deal with was the integration of the new vector functionality with the existing interaction, like that for paths and geometry transformation. This team solved it by introducing a shape tool in the toolbox and using the path tool for advanced vector manipulation.

Team one was the fist of several teams to arrive at the solution to use a library dialog for selection and management of a large set of user‐defined vector shapes. This works analogue to how brushes are selected and managed.

Apart from a doing a good job overall of keeping all the aspects of the interaction together, I especially liked their use of the modern GIMP sizing handles for the simple shapes.

team two

• members: Sara Geller, Laura Ramirez, Jakob Tripolt + Florian Wenger
• design concept document (pdf, 9 MB)

Team two shows us that all it takes to deliver a detailed design concept is pencil and paper. Funny enough this team, that did the most note‐taking, also resisted for the longest time to use the pinboards that I strongly recommended for gathering the results of the brainstorm phase. At the end, they did.

Team two integrated shapes and vectors into the path tool, giving the path tool different modes.

Overall they went deepest into a lot of interaction issues and solutions. I really liked their serious workflow analysis.

team three

• members: Mona Seiffert, Giselle Anahi Salinas, Markus Angerlehner + Anna Weiss
• design concept document (pdf, 732 KB)

Team three shows that it does not take a long document to get the core concept across. To my surprise this team dived into making pixel‐perfect mock‑ups of their ideas quite early in our design process. That was another thing that had to stop immediately.

In our high‐pressure environment where the teams had just enough time to arrive to a solid concept, the focus has to be on staying agile and creative. While all the time the scope of the design gets wider and the big picture becomes clearer, any part‐solution needs to be hot‐swappable for a better one until the very end. You can do that when solutions are pencil sketched, not so easy when they are visually designed with considerable effort.

‘Keep it brief’ is what I asked for the design concept document. But vector layers turned out to be a design project that was more multifaceted than the humble introduction would let one believe. So apart from the core concept, a lot of peripheral interaction issues needed addressing, as the other teams did.

team four

• members: Daniel Corn, Katherina Donner, Marko Heijnen + Lena Seeberger
• design concept document (pdf, 528 KB)

Team four introduced not one, but two new tools in their design concept. And for good reasons, like addressing smooth workflow, or an appreciation of the elegance of the free‑poly selection tool. So they introduced a freehand tool besides a shape tool, the former converts freely drawn shapes to stroked/filled vector shapes.

Also this team did a a good job overall of keeping all the aspects of the interaction together and I am quite taken in by their clean and effective little storyboards.

after the project is before the project

From the moment I selected vector layers as our design project down to the moment I am writing this, I have kept out of actively designing this feature, by simply not starting to. This in order to stay as objective as possible, while working with the students; while grading their work; even while describing it here.

But now it is time for me to get started. I will take the concepts of all four teams as the starting point for my interaction design of vector layers for GIMP. I’ll keep you up to date on that here.

Finally, I would like to thank the students for their hard work during the three intense days that we spent together. It was great to feel the vibe and I had a great time.

Labels: architects, fundamental, GIMP, practical

—ps

3 comments, link‐ins, forward this posting:

     

GIMP redux, squaring the CMYK circle

June 19, 2009, 17:14

Before we return to the schmuck, there is going to be a small intermezzo.

indexed

In the future GIMP will lose its indexed mode. As I wrote last time: creative work is RGB work. Ages ago I made a solutions model how GIMP could still support producing indexed images. This means doing the creative work in RGB, here shown at 200%:

When it is time to prepare an indexed version, a projection screen can be pulled over the image window that shows how the user‐controlled indexed set‑up works out, in this case a modest 16 colors:

The core of the solution model is that this projection is again a surface, that can be worked on, to make the corrections that are specific to this indexed set‑up. The non‑destructive nature of GEGL makes it possible to reapply these corrections after more creative development, or to adjust them at a later stage.

It is from the projection that an export to indexed file formats is performed.

a coin drops

Cut to the chase: it was while reading the GIMP review on ars technica by Dave Girard, where he used ‘vinyl’ and ‘audio masters’ to describe CMYK and RGB. Suddenly I could see the parallels with the indexed situation.

going to press

Here is my solutions model for preparing artwork for the printing press in GIMP.

By now it should come as no surprise that all creative work is going to be in RGB. This has also the benefit that at all times all GIMP plugins work, without a chance of color shifting conversions. Here is a schematic representation of creative work on a jazz poster, built out of four layers:

jazz posters, found at: polish jazz art in nyc

At any stage during the project, when there is a need to work towards the printing presses, a press projection can be pulled over the image window that shows how the user‐controlled plate set‑up works out, in this case a five‐plate job:

The layer stack—used in the creative development—is not used in this view. Instead what matters is the user’s plate set‑up, which is displayed and controlled as a similar stack. Each plate is fully editable: painting, curves, gradients, (lots of) plugins, anything goes. This gives us the required full control over the plates.

Note also that the colors in the press projection are already slightly different than that of the normal view, because the color profile of the printing press is taken into account.

it’s all a set‑up

Everything hinges on the particular set‑up of the press projection. This is where users freely set—as required—the number of plates and what ink/paint/lacquer is used for each plate. Any color will be possible and we can support metallic paints and matt/glossy transparent varnishes, using a bit of animation on the projection.

The set‑up is also the place where the more tricky stuff is supported: overprint and trapping, rich blacks, combined ink limits: it is probably only the beginning of how advanced this has to get. I had not forgotten about this.

CMYK + spot

In general the plate separation is calculated from the composite image that feeds into the press projection. However there will be full flexibility to map the content of any layer directly to any plate. For instance that light blue text in our example: it can be directly mapped from its text layer to the light blue plate, bypassing the composite.

Here is also the one and only time that CMYK will play a role in GIMP: as a small configuration file that is a default (OK, the default) for the projection set‑up. Nothing more, nothing less.

agile development

Since the press projection can be freely pulled over the image window and then flipped up again, GIMP will be able to fully support the required creative workflow. The mosaic below shows GIMP tracking in 16 steps real‐life work on either the creative concept or on the printing plates:

The non‑destructive nature of GEGL makes that whenever the press projection is pulled down, the updated artwork is re‑separated and all previously made plate optimisations are re‑applied on top. When the underlying artwork changes significantly, then every existing plate optimisation step can be validated by users and where needed adjusted.

The result is maximum creative flexibility and minimal rework of the plates over the life‐cycle of the file. Ah yeah, of course the whole press projection will be saved in the GIMP file. At the end, it is from the press projection that an export is performed to the file formats appropriate for shipping to the printers’.

what about CMYK files?

When a received CMYK file is to be used in new creative work, we already saw that ‘it needs to be imported and converted to RGB.’

When further fine‐tuning for the printing press is the goal, then the solution is to shove the CMYK file straight into a press projection, as a static, pre-defined separation. Each plate is then still fully editable as outlined before.

the non‑issue

That concludes my current take on ‘not quite the CMYK’ issue: bringing artwork to printing presses. Actually at LGM it turned out to be a hot topic in quite a few talks held by several projects. My contribution of squaring this circle fell neatly into place there.

Stay tuned for the last part of my LGM talk: a single‐window interface for GIMP.

Labels: GIMP, GIMP redux, practical

—ps

5 comments, link‐ins, forward this posting:

     

GIMP redux, enter: the schmuck

May 20, 2009, 09:56

‘What about schmuck?’ Katrin Alt said, when I explained to her about my work on GIMP. —Excuse me? ‘You know, what about CMYK.’ —Ah, that is a long story.

So started my talk at the libre graphics meeting this year. I will cover it in three separate blog entries, the first one being about schmuck.

hot debate

GIMP’s lack of CMYK mode is one of the hottest topics in the comments sections out there. Also fiery is the resistance by GIMP’s maintainers to introduce such a mode. In March the CMYK issue returned during a long thread on the GIMP developer mailing list. Quite a few users who seriously use and need color separations chipped in. It gave me a chance to understand the activity, both from a technological and users’ side.

The first thing to understand about the CMYK issue is that it is not about CMYK. The issue is bringing artwork to printing presses. And I mean serious printing presses, with operators, print runs and hydraulic parts. Not that very expensive, high‑spec printer that sits in the corner of the designer’s office, that one is still covered by openPrinting.

flex plate

Unlike for the printers that you and I use, with printing presses the plates that do the printing are freely configurable. Any number of plates can be used with literally any kind of ink/paint/lacquer, for cost or quality reasons. That there is a world beyond CMYK is something that Øyvind Kolås has been pressing on me, for instance, during a discussion last year at guadec.

During the mailing list discussion mentioned above, Louis Desjardins wrote to have a look at packaging for examples of how complex the plate set‑up can get. So I did, the next time I made a coffee. Turning over the milk carton, I found the marks for a seven‐plate print job, none of which was cyan, magenta, yellow or black.

mind the gap

Now, I am not saying that GIMP is the application for designing milk cartons, but the complexity of printing such a cheap commodity really shows that hardwiring a CMYK mode into GIMP would be a serious case of under‑design. Why go through all the trouble of introducing that when it cannot deal with a simple poster, printed in black + orange, or the milk carton?

2. control

The second most important thing to understand is that preparing artwork for the printing press means needing total control over the plates. This not only means a flexible plate set‑up as outlined above. It also requires that every bit of experience that a user has with the particular printing press can be used to fine‐tune each plate. I am not underestimating what this is going to take: basically the full GIMP functionality, including any plugin.

3. creative work

The third thing to understand is that creative work is on‑screen work. We must focus on the loop that exists between users, the tools they use and the image that appears as a result, again inspiring the next step of users. If I may be so bold: during creative work the image does not exist on disk, or in RAM, it only exists on the screen.

The natural medium of the screen is RGB pixels. That is why I say: creative work is RGB work.

4. what about CMYK files?

If one receives a file in CMYK format, we know by now that it was destined for the printing press—actually, one particular printing press that is is supposed to be fine‐tuned for. With that knowledge there can be two reasons we are touching it at all:

1. it needs further fine‐tuning for that press, best done in CMYK;
2. it is a found‐image that goes into a new creative work, for that it needs to be imported and converted to RGB.

5. workflow

The last thing that we have to understand about the activity is how eclectic real‐life workflow is. In theory it is simple: one creates artwork, separates it for the plates, then prints it on the press. That is also the clean model when it comes to color models.

Creative users live a bit more iterative: start creating; set up the separation to see what is possible in the end; fine‐tune that; create some more; fine‐tune some more; get feedback and adapt the creative work with that; get a print proof and do a wholesale overhaul of the separation and fine‐tuning; some last‐minute creation; print it on the press.

It is easy to see that the rigid theoretical workflow does not support creative real‐life. The rigid workflow is the the norm in software today and it inhibits creative users to work as freely as they can imagine.

form‑fit

Now that we fully understand the activity, we can work on squaring the circle. Read all about it next time.

Labels: GIMP, GIMP redux, practical

—ps

4 comments, link‐ins, forward this posting:

     

working on GIMP’s transformation tool

March 24, 2009, 13:17

Last week Wednesday there was the local Berliner usability meeting (‘stammtisch’). Desdemona Strauß thought it would be cool to try out an idea from IxDA Vienna: ‘bring two slides about what’s on your mind concerning usability or interaction design.’

So I did. I talked about what I am cooking up for GIMP: a unified transformation tool. I spoke quite a bit about the nuts and bolts of how it is going to work, but you can read about that in the spec. Instead let me recount here some of the behind the scenes topics I talked about.

pre‐historical

This tool has been a long time in the making. I remember during my early GIMP work with Kamila Giedrojć the form follows function handles were created: a parallelogram for shearing and a circle for rotation. During one or two LGMs I have spoken about the need to bring the number of tools in the toolbox down and to integrate them.

Last October saw a GIMP UI team meeting here in Berlin. Thomas Viehweger, Kamila and I worked on the transformation tool, among other things. This is where the sharing of the corners between the scale handle and the perspective handle was born.

slow going

During that meeting we also had a look at the free transform tool of the latest photoshop, mainly because one GIMP developer labelled it ‘ideal.’ Finicky, cryptic—and ultimately—slow is the interaction we saw. We already knew we could do better.

can you feel it?

So here we go. The overriding benchmark for me here is ‘does this tool support creativity; does it allow users to stop thinking about the tool?’ Before creating, reviewing and refining interaction, I concentrate on the vibe of shaping image material freely, on a positive feedback loop for users between their intermediate result and their next step taken.

And I am not kidding about the ‘pace of around two actions per second.’ I have observed that kind of working as fast as ones imagination and here is where ‘freely’ and ‘stop thinking’ are required.

By concentrating on the vibe, I am able to take the hundreds of decisions required, without falling for the lure of particular use cases or petty rules of thumb. For instance, it settled the argument whether to introduce modes for scale, rotation, shearing et cetera or to have separate handles for all these actions. By thinking about forming clay (made of pixels), touch–push–release, I was able to feel that the handles variant is more direct and hence superior.

mathematically

All those warm, fuzzy feelings got combined with systematic rigour. Although the other people involved would hate to admit it, it is the interaction architect job to completely shape how a piece of software works on the outside. And therefore interaction architect must completely know how that same piece of software works on the inside, although not down to a code level.

That meant finding out all the functionality of the current geometry tools, including asking the developers to check the code for any hidden tricks. Next was describing this functionality universally in terms of modifying corners, sides or angles under a series of constraints and symmetries. I then found a few holes in the system—for instance, more forms of shearing and perspective transformation—which I took into consideration.

Also, I went through the whole UI brainstorm to find everything related to transformation. I am happy to report that these contributions triggered ideas that are part of the mix in the final design.

start making sense

So now we have the existing pile‑up of GIMP functionality, with on top another pile of potential functionality. How to organise that into something elegant? Well, by not trying to do everything plus more. Aiming for compact yet comprehensive functionality. Realising that it is the UI that has to be conductive to the vibe. And that the selection of functionality is subordinate to this.

It has always been my intention that this tool would not do it all. It covers the spontaneous side of geometry transformation, complementary tools and menu commands cover the planned, deliberate side. It is with a clear conscience that I ban the dialog boxes and numeric input of the current geometry tools because they go against the vibe: that can be done elsewhere in GIMP.

q + a

During the stammtisch there were some interesting questions:

‘Can’t you use gestures to determine what transformation to use?’ Wow, that one rattled me for a moment. But I also felt immediately that gestures could not be it. I thought of forming clay (made of pixels) again and that one needs to get hands‑on to do that. Waving one’s hands in the air to magically form it would be too fluffy a method.

‘Can one hide the frame with the handles to have a good look at what one is doing?’ Good idea. I can see how it can help to temporarily have a clear view. I will add a way to do that.

‘You talk not designing this tool for yourself; banning your own experiences, how do you do this?’ That is a tough question. And only as I write this do I have the complete answer: I have to filter and interpret my own experiences exactly as the feedback of any other user. This usually ends with my own experience not mattering at all, or being a minor data point on an immense continuous scale.

That allows me to look at user interaction in an architectural way. Looking how one set of interaction is going to do justice to the distribution of requirements of a million users.

trivia

Just as I was explaining during my talk that all handles shown on‐canvas have to be drawn in transparent black or white and not in grey, I realised that they could be done in grey and still be visible under all circumstances. So now some are. You can actually click your way trough the different iterations of the transformation frame design.

The complete for specification the transformation tool is not finished yet. You can follow my progress in the next few weeks by checking out the wiki.

Labels: GIMP, practical

—ps

2 comments, link‐ins, forward this posting:

     

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

3 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

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