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:

     

notes from san francisco: testing 1‑2‑3

May 06, 2009, 06:39

This second blog posting about the openPrinting summit in San Francisco covers the usability testing of the printing dialog. First, a few words about usability testing.

I have worked with people who saw a usability test as a kind of final school exam: better send something into the test that will not rock the boat. This kind of fear surely stamps out any kind of interaction design innovation. Under those circumstances I say: why bother doing this project at all?

hard knocks

Experienced software developers appreciate working with a dedicated software test team. Yes, these testers aim to take everything apart, but the resulting software will be a lot better when it hits the streets. Similarly, I enjoy working with a usability team.

The usability test delivers hard‐hitting facts, but these flow straight into debugging and adding depth to my interaction designs. And when the test says it works, then my work is validated and that marks the end of doubt and discussion.

before the test is already a test

The usability test was performed by Jan Mühlig of relevantive, who also headed up the first involvement of openUsability with openPrinting in Atlanta, 2006. Although I took over the project at the Lexington summit in the same year, Jan has been closely involved at different phases of this project.

Straight away the preparation meeting was a hoot. For interaction architects, having a frank, uncomplicated discussion with professionals who have empathy and usability experience is both a pleasure and highly valuable. Jan’ feedback triggered a redesign that Kate, my associate at m+mi works, and I performed during our preparation of the test material.

agile like paper

The test was performed using a paper prototype. I played ‘computer’ in most of the test sessions, driving the dialog response to users’ input. Working this way allowed us to do three rounds of testing—with in between two further rounds of redesign—in exactly six days.

Being a usability researcher, Jan was not going to take for granted that any of our big, innovative concepts—no matter how sound they looked—was simply going to work. ‘Just print’; two levels of detail in the dialog; always a preview; quick presets; parameter tagging: he gave all of them a real workout during the tests. They had to prove to be a real improvement over the current state of printing dialogs.

the results are in

Walking you through the results, I will illustrate them with the latest iteration of the design, the one that went into the third test.

‘just print’

Printing still does not exist. At the start of test the participants were interviewed about what printing means to them and how they experience it. Again and again the answer is that the act of printing is not interesting, only the result counts. Here are some quotes:

‘What I think about is hard‐copies, really; a piece of paper I can look at.’

‘…but most often, I’ll just press print.’

‘I just click on print and… —[Jan:] the print appears by magic? —Yes.’

Although ‘printing does not exist’ is our number one guiding principle, it is striking to experience in the test how strong this force is. Our solution for supporting this is ‘just print,’ bypassing the print dialog altogether. Below you see the jury‐rigged file menu we used in the test:

I had put ‘Print one copy’ as a label in there for ‘Just print’ in the first test, but that did not work out. So, if you want to learn something, take some risk and use the test results. From the second test on the menu was as above. It fared better, but more testing is needed here before setting this label in stone.

preview

If ‘printing does not exist’ is a strong force, the print preview is huge. We are not talking here about participants getting along nicely with the preview and they knowing how to flip trough it. We are talking about seeing that for 100% of the participants the preview addresses a fundamental need.

Although it was my vision right from the beginning to design the print dialog around the preview, it is still amazing for me to see in the tests how deep it has an effect on users. So deep, that participants of the ‘just print’ persuasion started going through the print dialog more after seeing it—and the preview—only once. It is a huge effect to have the voodoo taken out of printing.

Now as an interaction architect I expect that long‐term—after the printing dialog has built a new level of trust in the print process through the preview and other factors—users will start taking up the offer to ‘just print’ for boring, predictable print jobs. But at any moment: if there is a hint of doubt, then the preview rules. Below we see the preview in the compact, level 2 dialog:

We added to this level the only universal printing parameter in the world: number of copies. If there is one thing we learned from this whole test cycle is that the way to the print is through the preview. The preview is the last thing to check and the Print button is logically located just below it.

tagging

Because of a lucky labelling flaw in our test set‑up, all the test participants went through the situation where the first tag they chose did not deliver the printing parameter they were looking for. After selecting a second tag they did not get the familiar situation of seeing different parameters, they got more of them (all parameters referenced by both tags). Then in 100% of the tests the conversation was the following:

Jan: Is this surprising?
Participant: Yes.
J: is it negative or positive?
P: I think it is positive, it is good that these are shown together because […].

Every participant formulated the last answer in a different way, citing a different reason why it was an improvement. But it was striking how the pattern returned in every test. Based on that Jan declared that he does not have to see dozens of tests more to know whether it works, it simply does. Below we see the full‐fledged level 3 dialog:

The whole tags + parameter section functions as an extension of the level 2 dialog. What is new is that the tags are now sectioned, along the lines of old‐fashioned functional vs. new user needs. Twelve of them in a single grid was simply too much. Next up for us is a parameters on the left vs. on the right design exercise and further work on the individual controls.

trouble

Not everything went that smooth from the beginning. I will illustrate that with this level 2 dialog that went into the first test (thus, now an obsolete design):

The test showed the following problems:

• participants had trouble identifying what the quick presets (on the left in the dialog) really were: a preset controlling all parameters or a single parameter settings?
• participants had trouble getting to level 3 in the dialog (via the More control button);
• participants were looking to ‘open up’ a quick preset to show what the actual implications (parameter settings) of it were;
• participants were looking to ‘open up’ a quick preset to show the printing parameters.

To find out what was going on we did a full‐risk redesign for the second test. That fared even worse. But now we knew what was going on:

1. we were relying on the actual labelling of the quick presets to communicate what they actually were;
2. our labelling was not good enough and since in production the real labels will be supplied by the printer manufacturer, they will never be perfect;
3. the preview does not contain enough information to show what a quick preset completely entails;
4. the information structure in the dialog was not clear: we were not showing that a quick preset encapsulates a full set of parameter values and thus the whole print.

into the light

To see how we solved this puzzle, let’s have a look again at the level 2 dialog that went into the third test:

The quick preset—now called ‘Current setting’ for users—now serves as a banner for everything but the printer. Under it, what is an essential print setting and not ascertainable from the preview is listed in short‐hand for a more complete overview what a quick preset will accomplish.

Furthermore, a change that meant the end of a principle that I had long cherished for the dialog: visibility and 1‑click selection of quick presets. With the limited reliability of quick preset labelling, the visible listing of them has limited value. Making the choice of quick preset a pop‑up enables to run it as a banner, closing the circle.

This design tested well in the third test. This means the big concept bugs have been debugged and fixed. For the actual quick preset pop‑up I have some innovative ideas in mind that I want to see explored. If they ever make it into the design, they sure will need usability testing, of course.

encore: labelling insights

While preparing for the first test, we spend some time straightening out the tagging used in the dialog. There we discovered some subtle factors in the labelling. Some of the tags had labels that looked like an end‑goal (‘fit to paper’), instead of a range where users can find their own optimum (‘paper fit’). The former gives the impression of a quick preset and is thus incorrect.

Similarly we have seen that quick presets can give the impression to be a single parameter setting. Although users have every right to store such ‘single issue’ presets, factory‐shipped presets should target broader goals and be labelled as such. ‘duplex: on’ is a very bad preset label, ‘good enough for jazz’ is a good label.

That’s it for dialog usability testing. Next up: the trouble with infrastructure.

Labels: fundamental, openPrinting, practical

—ps

1 comments, link‐ins, forward this posting:

     

notes from san francisco: pdf

April 27, 2009, 23:36

Two weeks ago, I presented about the ongoing work on the printing dialog at the openPrinting summit in San Francisco. Some of that was an overview of what had happened since Montreal, that you could already read about here.

Three distinct topics formed the new and notable in my talk, I will present them here in three separate blog entries. First up, a topic long overdue.

what about pdf?

As part of the second season of usability project for openPrinting we had a closer look at generic pdf creation, because it is handled via the printing dialog on all main desktop platforms. First, we found out why engineers were tempted to implement it in that way.

PDF creation is ‘printing to virtual paper.’ The whole transformation part is there, the formatting of application data for a printed medium of a certain size (A4, letter). Some printing bits are missing, like finishing (sorting of pages, stapling, et cetera), but the similarity is striking.

Another factor became clear when we looked at under what circumstances does it make sense to create a pdf from an application. Answer: if it is worth printing, it is worth making a pdf of. So if it walks like a print job and quacks like a print job, why not represent it like a print job?

a spanner in the works

There is one slight problem: users won’t have it. No matter how long it has been the norm to create a pdf via the print dialog, they have no idea why it is ‘hidden’ there. To them it feels as printing via the ‘save a file’ dialog would be: very strange.

Users see pdf creation as document creation. A document that is highly predictable in how it displays on another computer. And that they feel is relatively immutable. This showed us why users create pdfs and by tuning in to that we found the correct way to represent it.

back to reality

Connecting all the dots we see that pdf creation is actually a file export, and that is what our solution model is based upon. In the simple case that will mean a ‘Export to pdf…’ in the file menu; for applications with existing export functionality, it can integrate there.

Ironically, although pdf creation has been banned from the print dialog by this move, it is still up to the printing framework to provide it. It is a nice example of how the user‐world and engineering‐world can be at odds with each other. And of how it is up to interaction architecture to reconcile these two worlds.

strange relative

The dialog for pdf export won’t be a twin brother of the print dialog. That follows as a matter of fact from the tasks of printing and pdf export being different, with a different meaning to users.

For instance, to fit the task, the pdf dialog will have a much larger size than the 640×480 limit I set for the printing dialog. Being sized more like a main application window, this extra space will be used for a much larger preview area, which is called for in document creation.

The dialog for pdf export will be a cousin of the print dialog. That follows from the identical transformation for printing and pdf export. Interaction design innovation, code and application APIs, most if not all can be recycled for pdf export.

That’s it for pdf. Next up: the results of a first wave of dialog usability testing.

Labels: openPrinting, practical

—ps

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

     

the armpit of usability

September 20, 2008, 11:27

I remember it clearly, it was during the first world usability day in Berlin, during a lecture by Jochen Prümper on productivity and SAP. He was talking about the relationship between verticality and usability. Suddenly, years of project experience and analysing software products gelled.

down the ramp

The graph below shows how the average level of usability ramps down to zero, depending on how vertical the market of a certain type of software is:

Software gets more specialised as we move from left to right:

general

intended to be used by everybody. e.g. desktop environments; web browsers; email, chat and call software. Office applications live on the border with the specialised category, with inherently lower usability.

specialised

not general‐purpose but still used by many in many different situations. e.g. graphics, drawing, charting, outlining, presentation and project management software.

vertical

focussed on supporting one profession or hobby only. e.g. CAD, accounting, simulation, audio/video production, genealogy software.

bespoke

made‐to‐order software: projects instead of products. Includes custom implementations of software products (SAP et al). Both the number of users and developers can range from singles to thousands.

‘I am doing just fine…’

What is remarkable is that this usability ramp is matched by an identical average willingness to work with interaction design and usability professionals:

cause and effect

I am convinced that the primary driver of the usability ramp is contact between users and developers: the more vertical the software, the more direct the contact between them.

There may still be a layer of (project/product) managers or functional analysts between these two groups. But the more vertical the software, the more tempting it is for these folks to wash their hands of user requests and pass them on directly to developers. The customer asks—and pays—for it, no?

mind the void

Because users are living inside the software they use, for them innovation seems to consists of yesterday’s software—like it has always been—with some new features added. A lack of real innovation combined with feature‐bloat equals destroying the little usability that was there to begin with.

So the more vertical the software, the more its development is driven by reacting to what users ask for (features!) and fear of changing ‘like it has always been’ through innovation. And that ramps usability to zero.

splendid isolation

At the general end of the ramp the relative isolation of the developers forces that they have to think more systematically about their UI, which is beneficial to usability. Still these developers make all the classical mistakes—like imagining themselves to be typical users—which limits severely the maximum of usability that can be reached.

Everywhere along the ramp the exceptional occurrence of good usability raise the average. These exceptional specimens have ignored what users asked for and instead given them what they really needed. They have innovated their UI beyond ‘like it has always been’ and not fallen into the ‘people are used to outlook’ trap.

The quickest and cheapest way to get there is to integrate interaction and usability professionals in your development processes. But…

‘I said: I am doing just fine, really…’

…then there is the work‐with‐pros ramp, which I have used since its invention to quickly estimate if a company will really go ahead to improve their usability, or are just talking the talk. It holds up pretty well up to now.

At vertical‐software companies, the domain knowledge they took the years to gather about their niche markets is considered a barrier to entrance to interaction and usability professionals: how on earth could we help them? I have given up on trying to explain that we are highly experienced in getting tuned in in a matter of days into the activity of their customers, in dimensions these companies did not know existed.

penny‑wise

When it comes to bespoke software, it is very simple: unless the customer insists on interaction/usability pros on the project and is prepared to pay in full for them (including a nice mark‑up for the software company), it is not going to happen. Any other interaction/usability set‑up is a direct threat to the bottom‐line of software companies and their room to fudge/negotiate a project into a ‘finished’ state.

Looking at both ramps—seeing rotten usability and slim chances of that changing at the sharp end of the wedge—I have dubbed vertical‐market and bespoke software to be the armpit of usability:

the implications for open source

Open source software has a reputation for especially bad usability. I say: it is not that much worse. From my lofty position there is not that much difference between awful (commercial) and goddamn awful (open source) usability. Both decimate our productivity and daily joy‑of‑use.

I see open source tracking the usability ramp of commercial software, starting off lower at the general end. By the time commercial software slides into bespoke territory, open source does not fare worse:

The difference is that because of the community character of open source, developers are more in direct contact with users than their equivalent commercial developers. This makes open source developers work more ‘vertically’ than they have to, at the cost of usability.

a win‐win situation

In the future usability ramp and work‐with‐pros ramp will multiply to cause a quadratic effect for the former: at the general end, interaction and usability professionals will steadily improve average usability, while the armpit of usability will be as miserable a place as it is today.

Labels: fundamental, practical

—ps

2 comments, link‐ins, forward this posting:

     

to Istanbul via Tokyo

July 18, 2008, 14:09

Last week I was on the road for openPrinting. First a couple of days in Tokyo to discuss with the Japanese printer manufacturers my printing dialog design. There was appreciation and encouragement, but the best news last week was that the printing dialog is scheduled to go in all major linux distributions next spring.

With that under my belt, I spent a couple of days in Istanbul for guadec, the GNOME developer conference. I did a presentation to raise awareness among developers for openPrinting.

the 8 rules of printing interaction

For my presentation I condensed the challenges, findings and solutions of printing interaction into eight rules:

1st rule of printing: printing does not exist

m+mi works’ partner company, relevantive, performed user research at the beginning of this project. It showed that for users there is no worthwhile, productive activity between the moment they want to see something printed and the moment it comes out of the printer.

Printing, like streetlights, is infrastructure and it just has to work. This has important implications as we will see.

2nd rule of printing: printing does not exist

When I got started on this project in October 2006, I evaluated all printing dialogs for GNOME, KDE, windows and OS‑X. The overall impression was one of stagnation, a time warp back to the mid‑nineties. Only OS‑X is inching forward, getting ahead of the others.

Since then I have learned where the stagnation comes from: no one can be bothered to do the development work. This ‘can’t touch this’ approach was again palpable at guadec. Delivering an innovative interaction concept has broken this negative spiral. Alex Wauck is developing my new dialog design, for GNOME and KDE at the moment.

3 levels of printing

Taking the paradox of the first rule to its logical extreme, we introduced three levels of printing.

level 1

Printing that just works. Users know for 90% of the printing they do that ‘it will be OK’ when done like last time. As the first—and probably most important—innovation in this project, we complement today’s Print… command with ‘Just Print’, which shows no dialog and prints using defaults and last used settings.

level 2

A basics level of involvement: what printer; maybe set a quick preset; check the preview; done:

level 3

Detailed. Parameter. Tweaking. It is ironic that within the openPrinting project we will spend most of our time, discussions and effort on covering this single last percent of usage.

4th. wysiwyg is overrated

There is no better way to derail a discussion about printing than by using the example of printing a word/openOffice writer file. These applications are one of the few out of tens of thousands where the data is already paper‐formatted on the screen. That takes our mind off an important part of the process.

Spreadsheets; web browsers; email; MP3 collections (iTunes); anything based on a database: all these applications will have to put their data through a transformation to get it on paper, when they print. This is exactly the point where application and printing infrastructure have to cooperate most.

5 million use cases

Being a generic piece of infrastructure, printing turns out to have as many use cases as there are users. Try to take the encyclopaedic route and map these out: you will go mad with an exponentially ballooning amount of variants.

Life is easier being a printer. Each model is made in relative limited numbers for a specific market. This focus is useful for the printing dialog design. But I can not run a design project saying ‘gee, everything depends on the printer model.’ So early 2007 we surveyed the printer market and formed the following printer clusters:

• personal laser
• workgroup laser
• high volume printers
• general inkjet
• photo printers
• wide format
• impact printers

This covers more than 95% of the market. I am in the process of designing a printing dialog for each cluster. Printer manufacturers can customise these best‐practice examples for their models.

6th. unknown: good printing dialog

What is the ideal layout for a printing dialog? I can tell you that only when I know the specific user’s goal (one of those five million), in the context of the application that is used and the printer that is targeted. Of all of us, only that specific user is present when these three meet.

The solution is user‐configured printing dialogs. Users shape the dialog so that they can achieve their goal for that print. The dialog configuration will be persisted as it was left, for the particular user + application + printer combination. It will be ‘just right’ next time that user prints from that application to that printer.

7th. tabs considered harmful

I am talking about the tabs, at the top of the dialog below, that segment the printing parameters into technical categories. Apart from the danger of separating parameters that were related or putting one in the wrong category—both from a particular user’ point of view—there is a more fundamental problem.

Assume six tabs as shown here. And the better‐than‐real‐life situation that all printing parameters are evenly distributed over the tabs and that users actually know where to find each parameter.

• is it not a pity to have to change tab once to set one parameter? there is a 83% that this occurs;
• is it not annoying to have to change tab twice to set two parameters? 75% chance;
• set three parameters, what is the worst that could happen? to have to change tab three times: still a 50% chance.

That is an untenable situation. Tabs work great in some situations—e.g. tabbed browsing, preferences dialogs—but not in a printing dialog.

8th. tags not tabs

The solution is to associate multiple printing aspects with each parameter instead of just one category. Tags instead of tabs:

As a result from rule five, this mapping will come from the printer (PPD). Implementing rule six, users will configure their dialog by selecting the aspects (tags) that interest them, seeing as a result all parameters they need in the dialog (animated gif):

printing rules, OK?

Those are the 8 rules of printing interaction. Stay tuned for a small encore, the guadec special: what about pdf?

Labels: fundamental, openPrinting, practical

—ps

1 comments, link‐ins, forward this posting: