on interaction architecture

working on a vision with Krita

noreply@blogger.com (peter sikking) — Fri, 05 Mar 2010 15:42:00 +0000

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.

from open source to symbian

noreply@blogger.com (peter sikking) — Tue, 03 Nov 2009 18:42:00 +0000

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.

GIMP redux, single‐window mode

noreply@blogger.com (peter sikking) — Fri, 18 Sep 2009 17:19:00 +0000

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:

too easy, too fast: the tabs got adopted from web browsers, without much thought;
it would be rather logical to use a thumbnail on the tab itself to identify the image;
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.

teaching interaction /09

noreply@blogger.com (peter sikking) — Tue, 28 Jul 2009 12:40:00 +0000

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.

GIMP redux, squaring the CMYK circle

noreply@blogger.com (peter sikking) — Fri, 19 Jun 2009 15:14:00 +0000

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.

GIMP redux, enter: the schmuck

noreply@blogger.com (peter sikking) — Wed, 20 May 2009 07:56:00 +0000

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

it needs further fine‐tuning for that press, best done in CMYK;
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.

notes from san francisco: testing 1‑2‑3

noreply@blogger.com (peter sikking) — Wed, 06 May 2009 04:39:00 +0000

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:

we were relying on the actual labelling of the quick presets to communicate what they actually were;
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;
the preview does not contain enough information to show what a quick preset completely entails;
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.

notes from san francisco: pdf

noreply@blogger.com (peter sikking) — Mon, 27 Apr 2009 21:36:00 +0000

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.

working on GIMP’s transformation tool

noreply@blogger.com (peter sikking) — Tue, 24 Mar 2009 12:17:00 +0000

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.

all zap and no design

noreply@blogger.com (peter sikking) — Wed, 29 Oct 2008 00:16:00 +0000

A week ago I was at zap your PRAM, an un‑conference ‘for people who don’t like going to conferences.’ Here are some of my favourite reports from other participants: Stephen, Deane, John and Deb.

It was a remarkable event. Instead of terrible air conditioning there was a log fire in the central hall spreading a wonderful scent through this old mansion. Instead of awfully calculated ‘networking’, it was totally natural to talk to a bunch of interesting people.

dissenting voice

Steven Garrity had invited me to participate on a panel discussing the value of design. He proposed that I show the impact of design on GIMP or openPrinting. Instead I thought I could spice things up by talking about my problems with the word design, along the lines of my recent I’m not a graphic designer post.

Steven thought that was ‘…potentially contentious, which could be fun.’ Here is the gist of my ten‐minute talk:

I am not a designer, part 2

I am simply not able to call myself an interaction designer. The interaction part is brilliant, it is all about flow, actions in time to achieve certain goals. The problem is the word design, which has been hollowed out over time.

Hollowed out…

…by consumers: aka users. They perceive and value design as the outer shell of an object, website or a piece of software: ‘making it look cool.’
…by clients: of designers: the producers of said objects, websites or software. They share the consumers’ outlook on design and are happy to superficially cater to it. Adding insult to injury, they schedule the design at the end of development processes, as a special sauce that gets poured over the actual product right before serving.
…by designers: who seem happy to participate in this game between the two groups above and deliver those outer shells, that special sauce.

meanwhile…

Designers are forgetting to solve the problem. Forgetting that when something needs to be designed, it means that it will interact with people. That this interaction with people defines what this artefact, this object; website or software, actually is. That designing means making it work, beyond a pile‑up of commodity functionality.

common theme

The difference is empathy. At zap your PRAM that turned out to be sort of the theme‐of‐the‐day. Hannah Donovan, lead designer of last.fm, had already held an excellent talk in the morning that heavily featured empathy.

To me empathy means feeling the pain of users. Yes, in your stomach. Instinctively knowing that ease of learning, ease of use or ease of remembering targets are not met. And it is keeping you awake at night. Empathy is what it takes to be a designer.

a picture is worth a…

At my talk I had to show at least one example to get the non‐designer‐geeks tuned into what I was talking about. Some well‐known website where obviously money is spent on ‘design’ but problems do not get solved. Ebay came to the rescue:

Top‐left next to the ebay logo we see me being greeted. That tells me I am signed in. See the two red buttons at the bottom of the pic? Their message (sign in or register) contradict the fact that I am signed in and destroys my confidence surrounding this concept.

Now I do not know how many designers were involved with producing the pieces with which this page is built up. But I do know that one designer with a good dose of empathy should have been in charge of making the whole signed‐in concept work.

1971

There is nothing new about this story. In 1971 Victor Papanek published a book titled: design for the real world. Focussing on product design, this book is full of intriguing ideas, concepts and challenges that are applicable to interaction design today.

One central theme of the book is that product designers are creating shiny junk that is designed to sell, but fails to work even according to basic criteria. Think of american cars at the turn of the ’70s: every year new huge impressive‐looking models, with same‐old technology under the bonnet and total disregard for road‐safety issues.

golden showers

The US design establishment was really grateful for Victor pointing out the elephant in the room and asked him to resign from his professional design organisation in the US. I should blog one day about the long‐tail impact of this book.

the big picture

I wish designers would start designing, with a healthy dose of empathy, focussing on solving the real problems. As soon as that becomes the norm, I will be happy to call myself an interaction designer.

the armpit of usability

noreply@blogger.com (peter sikking) — Sat, 20 Sep 2008 09:27:00 +0000

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.

to Istanbul via Tokyo

noreply@blogger.com (peter sikking) — Fri, 18 Jul 2008 12:09:00 +0000

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:

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?

GIMP’s new free‑poly tool

noreply@blogger.com (peter sikking) — Sat, 21 Jun 2008 11:42:00 +0000

Recently there was a heartwarming post on the graphics planet:

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

David Gowers, featured on meetthegimp.org

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

going poly…

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

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

magic combination

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

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

small is beautiful

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

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

tit for tat

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

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

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

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

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

closing credits

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

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

test drive

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

I’m not a graphic designer

noreply@blogger.com (peter sikking) — Wed, 26 Mar 2008 12:35:00 +0000

I really enjoy inspired graphic design and typography. Whether on screen or on paper, I appreciate the added value when a master of these crafts has pulled through a bold vision, down to the oh‑so‐important details.

Having a heightened perception of the two crafts, I have read about their theory and techniques during the last twenty years. And I am able to apply some of that, for instance in my presentations, which are not of the ‘force‐fit the powerpoint template’ variety.

at the interface

This perception and knowledge also enables me to work and communicate much better with graphic designers and typographers on my projects. I understand their point of view: it is not about making it look cool, it is not decoration. I talk in their terms about goals and possible solutions.

Which is important since the interaction architecture (making the ‘building’ function) sets the scope and boundaries for their design (the ‘interior,’ so to speak). Both of these have to be up to scratch and made in cooperation, or else the result will be a damp squib.

however…

But I know I am an amateur in graphic design and typography. From Latin: amator, meaning loving these crafts, I must also admit that I am no good at them. Whenever I try, I futz around, endlessly. It has all the symptoms of not being competent: not knowing where to start; no vision and steady direction; and most telling of all: not knowing when I am finished.

I am still ashamed of having made the first business card and first two websites of m+mi works in this way. And have been surprised when professionals had anything nice to say about them. What a relief, when I hired a graphic designer/typographer to work on the current website.

Yes, I still had to do all the interaction architecture work for the website (of course) and the close cooperation takes effort. But getting a typographical system, color system, page designs, logo, patterns and illustrations delivered competently was worth every penny.

In short, I’m not a graphic designer, nor a typographer.

what about you?

I meet quite a few people whose job is interaction designer, interface designer, screen designer, (G)UI designer, user experience designer, web designer, et cetera. And on those occasions there is always something in the air: that we work in the same ballpark, cover the same bases.

Sooner or later this turns out to be not exactly true, more often than not. Over the years I have developed an acid test to see where somebody stands:

‘if you feel that photoshop or GIMP is a vital tool for your design work, then you are not in interaction design, you are in graphic design’

the ps acid test

You don’t agree?

flip that

First of all if you were in user interaction then you would know it is all about structure and pixel‐based applications are simply not conductive towards radical changes of the proportions and order of an interface. It should take five minutes max to do that, not at least half an hour.

You would not dream of using photoshop or GIMP if you had to do actual interaction design with any reasonable efficiency. Makes me wonder about these job ads for the types of designers mentioned above, that not only list a full suite of usability skills, but also full proficiency with the whole CS3 suite.

Between all that usability surveying and graphic design, is there going to be any time left to get some actual interaction design work done?

party like it’s…

Second, if you were in my ballpark, you would know that next‐generation user interaction can be fully created and painstakingly specified using the technology that architects used in 1908. Paper, pencil, a typewriter and gaslight is all it takes. No electricity required.

This is because the most important work of interaction architects is done with our eyes closed—or in my case, staring into infinity.

Realising the product vision with a bold interaction vision; seeing how everything is connected; moulding the flow of a series of activities; taking the point of view of a million users; reducing complexity; reducing clutter: none of that is done in front of a computer screen.

once removed

Not a line I draw ends up on an end‑user screen. Not a word I write is compiled into code. Not a sentence I say instructs users. I draw, write and talk to enable the specialists I work with to excel at what they do and realise inspiring software for my clients.

I’m not a graphic designer, I am an interaction architect.

GIMP redux: intro

noreply@blogger.com (peter sikking) — Wed, 12 Mar 2008 10:39:00 +0000

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.

radio interview + openPrinting

noreply@blogger.com (peter sikking) — Fri, 18 Jan 2008 10:06:00 +0000

Last Saturday I was at the comfortable—but no less professional—podcasting studio of Chaosradio (host Tim Pritlove’s home). The discussion was easy‐flowing and the result was a podcast of almost two hours (in German) about usability and interaction design.

It was great to do the podcast together with usability consultant Ellen Reitmayr. Not only have Ellen and I been working together for years, on projects like GIMP, openPrinting and openusability, and had a complete story to tell about that. Also we have been discussing and exploring for years the central theme of the podcast: the way usability and interaction architecture integrate and complement each other.

In a similar way Ellen and I were able to integrate and complement our stories from our own profession’s point of view during the podcast. The fact that we have contrasting opinions and diagnoses of mainstream topics like ‘how good is the UI of windows/office/mac OS‐X?’ spiced up the conversation.

last chance saloon

As mentioned at the end of the podcast: the application period of the season of usability openPrinting associate interaction architect opening lapsed on January 10th. But I am giving it a couple more days, so if you are a finishing student/starting professional and want to work with me on a cool, challenging and high profile interaction design project: apply this weekend…

GIMP lecture, berlin

noreply@blogger.com (peter sikking) — Sun, 09 Dec 2007 13:54:00 +0000

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

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

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

10 reasons why you can’t morph a mobile into an iPhone

noreply@blogger.com (peter sikking) — Wed, 14 Nov 2007 17:29:00 +0000

Last thursday was world usability day. The local event was a big hit, the auditorium was packed. At some point, there was standing room available only . Apart from helping with the organisation and presenting the morning session, I also lectured in the afternoon:

why one cannot morph a mobile into an iPhone (also not with usability)

ps’s lecture at the berliner wud 07

Along with two spicy controversies in the title, I had chosen this topic to be able to share my analysis and hands‑on experience in this market segment. It was pure coincidence (I swear) that the following day the iPhone was launched in Germany…

You can have a look at the slides (pdf, 3.3 MB). But they contain big pictures, a couple of big words and no narative—like a good presentation should. So read on if you want to get the story…

161.000.000

That was last wednesday’s number of results for the word ‘iPhone’ in google. Today it is millions more. And that for something that was unknown on the first of January, 2007. How can it be that everybody writes and talks about the iPhone, even queues around the block for ‘a mobile’?

I will show now ten reasons why you can’t morph a mobile into an iPhone:

10. hardware

The most important piece of hardware of the iPhone is Steve Jobs. I am not trying to polish his already shiny ego. Instead, I am talking about his instinctive understanding that once a piece of software leaves the engineering department, user experience is everything.

To be able to produce inspired software, the top boss has to believe in great user experience and kick everybody’s ass to get it done. In huge companies a VP will do, but management below that level will be sidelined when trying to implement proper interaction architecture and usability processes.

leadership or bust

The upshot for interaction and usability specialist is that if you notice that your top boss is not actively supporting you, you might as well quit. Your work will be destined for somebody’s desk drawer for ever. Managers who totally believe in great user experience: you will have to rise to the top before you will get your way.

As for the top bosses: no general usability guidelines or usability testing of your current software will produce any greatness. If you do not feel how bad things are right now and are not prepared to kick ass, then forget about producing something as inspired as the iPhone.

9. product vision

When analysing an iPhone you will notice the conscience decision not to compete with blackberry & co. It is part of a clear product vision and this enabled Apple to take with confidence the decision to ditch the keyboard and go for touch screen. We will see that this was rewarded with plenty of room for joy in the UI.

Choosing what your software is not is one of the most difficult things for a development team to do. Avoiding tough decisions, ‘does everything, for everyone, with universal value’ is the usual outcome.

no vision, no product

I do not work on projects where the key people are not able to formulate a vision, with my help, within the first two days. There is then simply no basis for great interaction design. Without a vision, usability testing will yield trivial incremental improvement, nothing inspired.

8. (really) hardware

On the iPhone, the single hardware button that takes you to the home screen and the seventeen software icons on that screen that take you into applets, are an integrated system. That may sound normal, but too many times I have been asked to create new interaction architectures for hardware platforms that were already a fait accompli.

It is difficult to tailor UI for hardware that has a one button too many, or is missing one. If the hardware and software concept is not developed in tandem, the result will be and feel patchy.

software + hardware = one

From experience I can tell you that the hardware proximity sensor and accelerometer of the iPhone are simply vital for creating great software interaction with such a big touch screen. The iPhone is different from mobiles in that hardware and software form one single concept.

7. features

The iPhone has one third the number of features of a normal high‐end mobile phone. And that is not because they did not have the time at Apple to include the other ²⁄₃. Instead, they made the necessary choices.

When I started working in the mobile phone industry, my colleagues told me that because of the immature market, competitiveness simply meant more features. Ten years later and the industry still has not grown up.

mature on features

This circle of dependancy is diabolic. Users and features are like children and candy. They never say no, even if stomach pains will surely follow. For developers, it is the easiest thing hand out. New features are a commodity. If you have no clue how to improve your software, you can always add new features.

One cannot achieve iPhone greatness if one is not prepared to make tough choices on which features really matter. This counts for any kind of software.

6. joy of use

I am not talking about gimmicks here, although the iPhone has a couple of them, like the big shutter when you take a photo. I am talking about traits of the UI that in two years time will still put a smile on your face. One of these is the screen–to–screen navigation, which fluently slides the new screen in and the old one out in one movement.

Not only does this improve usability by creating a connection between the two screens and using the directions to code forward, back, up/down a level type of navigation. It is also fast enough and has such elegant movement curves that it creates the experience of handling a smooth little machine, with great fit and finish. It has the quality of handling a Leica camera.

functionalism is not enough

Like traditional architecture, interaction architecture has gone through its functional phase where productivity was everything. And there is nothing wrong with bulldozing the time wasting interaction of big, ugly software that tends to be used in offices.

In this post‐modernist world, joy of use counts. Forgoing gimmicks and getting it right lends a quality feel to a software product.

5. display

Comparing the size of an iPhone screen to that of the original macintosh, we see that it is not that much smaller, 480×320 versus 512×384:

The original mac is where the desktop publishing revolution took place, people made posters and newspapers on those screens.

ambiguous device

A suspicion rises: is this a tablet computer or a mobile? The iPhone covers the middle ground in this regard. We will see the consequences.

4. paradigm shift

When designing applications for the iPhone you could try the mobile phone approach with grids, lists and all the actions in option menus. However, from experience I can tell you that is a dead end. The applications on the iPhone break away from the mobile paradigm.

A case in point is the web browser, where they ignored the mobile WAP browser and used the big screen to put a normal web browser, using the random access touch input for zooming and panning. A great experience, instead of a damp squib.

full use of full‑screen

‘Avoid mobile look + feel like the plague and use the whole screen’ is what I can recommend anyone developing for the iPhone. Only in that way one can achieve the required inspired interaction.

3. telephone?

Phone is one of seventeen icons on the home screen of the iPhone. It shares the ‘top shelf’ with iPod, email and web browsing. This illustrates that making call does not have absolute first priority.

We could go further and ask ourselves why is it called an iPhone? iWhatchamacallit would be more appropriate.

don’t call it a…

The iPhone is a Trojan horse. At Apple they sidestepped the question of creating a better mobile by creating a modern communication device that happens to make calls and send SMS’s, then stuck the phone label on it to get it adopted.

2. holistic

Although it is a fuzzy, vague term, holistic does apply to the iPhone. In the eight preceding points, we have seen how everything fits together. Sure, dozens of persons worked on the iPhone, but the result feels as though it was created by a single hand.

simply holistic

This holistic user experience is the key to simplicity. ‘Don’t make me think’ is achieved via seamless continuity starting with leadership, product vision, via hardware, ¹⁄₃ of features, ending in paradigm shift and joy of use.

1. jump factor

Below we see every mobile ever made cluster together on the left and the iPhone as a lonely star on the right:

Incrementally improving a mobile so that it leaves the cluster and approaches the iPhone is impossible. It is actually easier to join the iPhone’s position from above, below or the right. The only way to get there, is to jump.

conceptual innovation

The jump factor needed is innovation, which is by nature a conceptual undertaking. Given the right leadership, product vision and ¹⁄₃ of features, interaction architects are able to make that jump and deliver a great user experience.

Usability is by nature empirical. This works great to obtain the input that interaction architects need: facts on the table, I always say. Also user testing is useful to validate interaction concepts. Interaction architecture and usability are two complementary disciplines that can deliver the validated innovation needed for iPhone greatness, under the right circumstances.

next‑generation printing dialogs /4

noreply@blogger.com (peter sikking) — Tue, 23 Oct 2007 13:12:00 +0000

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

voodoo child

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

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

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

gold, silver, bronze

I also summarised the three levels of printing we support:

level one: An awful lot of printing is done where users know from the start that the print will be OK. All those emails that get printed. The second, third or umpteenth time that office document gets printed. An estimated 80–90% of printing is like this.
level two: Users need to check that the print will be OK. Or quickly check/set which printer is used. Or that this photo should be printed either swiftly or at super quality.
level three: Fine‐tuning of individual printing parameters. We are talking here about the last 1–2% of printing…

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

just in time assembly

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

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

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

version 0.4

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

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

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

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

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

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

…and then we are at level three.

tags enter the matrix

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

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

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

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

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

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

summit sumarum

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

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

cross‑platform is bunk

noreply@blogger.com (peter sikking) — Thu, 11 Oct 2007 15:49:00 +0000

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

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

holiday cramp

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

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

not the only fruit

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

preferred native solution: It is my company and I am Dutch, so I tend to see the holidays in Holland as natural. So we take those: my co‑workers and customers in Germany and Spain suffer.
grand compromise: also known as roll your own, if there are holidays on the eighth, eleventh and seventeenth, then we will have one on the twelfth: mass confusion among co‑workers and customers.
lowest common denominator: Only the holidays all three countries have in common are company holidays: too sparse a set of holidays, will really upset my co‑workers everywhere.
union of all: If it is a holiday somewhere, it is a company holiday in all three countries: now we got holiday bloat, co‑workers can’t get any work done, customers think we are always chatting in the café.

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

back at the ranch…

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

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

cross‑platform cramp

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

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

weasel out

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

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

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

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

the making of: GIMP UI brainstorm

noreply@blogger.com (peter sikking) — Sat, 22 Sep 2007 18:02:00 +0000

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

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

trigger happy

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

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

get off

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

happy, clappy

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

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

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

tech crunch

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

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

…two weeks later

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

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

sifting through

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

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

whistling in the dark

noreply@blogger.com (peter sikking) — Wed, 19 Sep 2007 21:24:00 +0000

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

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

vroom

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

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

bleep

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

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

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

click

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

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

…

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

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

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

next‑generation printing dialogs /3

noreply@blogger.com (peter sikking) — Mon, 23 Jul 2007 18:05:00 +0000

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

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

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

rinse and repeat

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

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

ps, whenever prototypes or mock‑ups are discussed

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

beyond the frame

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

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

narrow down

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

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

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

Here are some of the solutions I have put in:

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

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

building up

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

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

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

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

design on a toilet roll

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

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

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

max headroom

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

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

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

gluing it all together

The following aspects make the steps above work:

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

the parameter section is build up as follows:

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

wrapping up

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

next‑generation printing dialogs /2

noreply@blogger.com (peter sikking) — Sun, 08 Jul 2007 19:35:00 +0000

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

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

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

starting at the top

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

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

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

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

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

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

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

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

pretty vacant

Here are some tags in action:

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

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

blink

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

coming up

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

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

economic outlook

noreply@blogger.com (peter sikking) — Fri, 15 Jun 2007 23:02:00 +0000

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

Some of my favourite snippets:

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

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

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

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

economic brain scan

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

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

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

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

business 101

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

‘by engineers for engineers’

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

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

‘an end in itself’

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

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

‘ignore what the market says’

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

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

‘concentrate on ease‐of‐use’

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

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

‘an order of magnitude more work’

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

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