publications

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:

     

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:

     

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: