next‑generation printing dialogs /4

23 October 2007, 15:12

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

voodoo child

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

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

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

gold, silver, bronze

I also summarised the three levels of printing we support:

level one

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

level two

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

level three

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

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

just in time assembly

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

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

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

version 0.4

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

disclaimer

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

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

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

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

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

…and then we are at level three.

tags enter the matrix

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

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

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

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

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

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

more solutions

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

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

the gray zone

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

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

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

blink revisited

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

summit sumarum

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

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

Labels: design stage, openPrinting, practical

0 comments · post a comment

If you like to ask Peter one burning question and talk about it for ten minutes, then check out his available officehours.

  Peter Sikking is an experienced
interaction architect. He unabashedly puts shipping great products at the centre of his design practice. He is known for his work for Google, Nokia, the Metapolator & GIMP open source projects, and startups.

Peter teaches, mentors, lectures and publishes. He enjoys working with small teams in an international setting, but also the fact that his work can be found on half a billion mobiles and creates billion‐dollar revenues.

What is Peter up to? See his /now page.

get in touch: email · twitter · g+ · linkedin · xing

on interaction architecture

our blog

The m+mi works blog is a record of what we do and how we think. It is a resource for anyone who wants to discover more about the process and practice of interaction architecture. These are our reports from the interaction‐design frontline.

subscribe: atom or rss