printing in siena

10 April 2007, 13:18

last week, part of the openPrinting interaction architecture and usability team met in Siena, Italy. I am leading that effort and had arranged this two‐day meeting for reviewing the work done up to now, and to brainstorm solutions for the design phase, in an inspiring atmosphere.

realising the vision

Right on the first morning, I led the discussion into the direction of ‘what if we do not need a print dialog at all?’ And from there we actually arrived at the concept of ‘just print’, which implements the openPrinting project vision:

‘…how to make printing with free software easier and better, so that it “just works”.’
Till Kamppeter, openPrinting organiser

Remember that printing does not exist as a task for users? ‘Just print’ will get the job done for them. Choose this new command from the File menu (it needs a better title) and the application and printing system will handle the rest. No dialogs are shown.

get fresh

To enable this, applications and the printing system need to clean up their act:

  • the application needs to use its full domain knowledge to get the transformation right: the act of getting the data formatted for paper media. This goes beyond just using the defaults, it means analysing the data and taking some smart choices, taking previous user choices into account. This includes selecting the right available printer and the right paper.
  • both need to put some effort into the handover: the act where the application hands the formatted pages to the printing system and both negotiate the application’s wishes. We want to see the both of them working together, instead of autistically against each other, as they currently do.
  • apart from listening to the application, the printing system can also have a good look at the actual print data from the application. Number of pages; aspect ratio; bitmapped, screened, line art, or text data; color or black & white? Make some smart choices based on it, again beyond the defaults and based on past user choices. This also safeguards against old skool apps that do not implement the first two points.

This all may look terribly complicated, but forty lines of code per application and printer driver can make a world of difference here. All this smartening up is also a precondition for the advanced dialog stuff as discussed below.

parallel port

From my point of view we have now circumvented the paradox of providing ‘one‐click’ operation and making 40–80 printing parameters available through the same UI. We have simply built ourselves an optimised UI in parallel for 95% of users, 95% of the time: ‘just print.’

dealing with 5,000,000 use‐cases

So after feeling very smug about eliminating the print dialog, we spent the rest of our two days redefining it, for that sliver of users—or occasions—where it is called for. It will be still available via the normal Print… menu item.

Again I led the discussion into the direction of ‘can we get rid of the print dialog as we know it?’ Somehow we tripped over hyperbolic browsing. Although it offered no solution, the graphs used to illustrate this principle did give me the following idea:

What if we let users put together their own personal print dialog?

an uncategorisable mess

The problem with print dialogs today is that 40–80 printing parameters are categorised into six or more ‘tabs’, to cut down the shear mass of them for presentation. Putting them all on one panel would be a horrible mess.

This has a couple of side effects, which were bothering me on an architectural level:

lost overview
one has to traverse the tabs to piece together the big picture;
broken relationships
printing parameters that are very much related in the mind of the user for a particular print, end up on different tabs, because the categorisation is general, thus rational;
misplaced children
just like with files and folders, a printing parameter can only be assigned to one category (tab); I was already dreading an undecided outcome of card sorting tests, telling us that 50% of the users will never easily find a parameter, regardless of on which tab we placed it;
wasted time
no matter how brilliantly one categorises the parameters, with six tabs there is a 83% chance that one has to change tab to adjust only one parameter, 56% for changing tabs twice for changing only two parameters and 28% for 3 parameters over 3 tabs. Because all these tab changes are context switches, they are much more costly in time for users than a single click.

So let’s give users a more fine‐grained control over which parameters they can see together in one dialog. For instance by providing twelve instead of six categories, which users switch on or off to build their own dialog. And the printing system remembers these configurations for each application–printer pair.

  • no, this will not lead to monster print dialogs with every parameter visible; I am confident that apart from the always‐visible trivial parameters, only one or two extra categories will be made visible for a particular application; it is just that for every user in the world these will be a different combination;
  • no, this will not lead to a monster database with thousands of application–printer configurations on the user’s hard disk; I am confident that each user has use for a dozen applications to print on maybe half a dozen printers; it is just that for every user in the world these will be different;
  • no, this will not lead to linux geeks being able to put together their own Frankenstein dialog by hacking an xml file; still a lot of interaction architecture is involved with enabling all the combinations to make sense when combined, and that is not going to be left to innocent bystanders.

So I was quite pleased that with this concept we have solved almost all of the problems of tabbed print dialogs. We have given the print dialog the ability to morph to the needs of individual users and thus, be able to handle the five million use‐cases that plague the printing design challenge. But on leaving Siena, I also knew that misplaced children could still occur.

tags, not tabs

The day after returning from Siena, I was at the innovationsforum interaktionsdesign. Bernard Kerr (del.icio.us) was presenting some past work on tag orbitals, when it hit me:

Instead of sorting printing parameters into categories, we could apply tags to each parameter and have users select some tags to build their own dialog.

feeling fuzzy?

Contrary to the rigid nature of belonging that comes with the one–to–many (folder and files, category and printing parameters) relationship, that of the many–to–many (tags and printing parameters) relationship is a bit fuzzy. And that is a good thing, here.

Tags circumvent the misplaced children conundrum. It is very similar to why hierarchical content organisation is going out of fashion on websites, as will folders on hard disks. And beyond that, they literally open up new dimensions for talking about printing parameters. Here are some tags off the top of my head:

  • need speed?
  • paper saving
  • security
  • precision
  • paper orientation
  • hand‐out
  • impress yourself

The sky is the limit. We are exploring the possibilities as I write this.

Labels: , , , ,

PS logo

1 comments · post a comment

at 10 April, 2007 17:02,Anonymous Anonymous commented
From the application side, the only "domain knowledge" that can be mapped directly using the currently available printer drivers (and there are thousands of them, many of which will never be updated for any newer "standard" you come up with) is page size, color usage, and duplexing mode. We can do a lot with that information, however auto-selection based on that information will not address common use cases such as photo printing (which media type?) and letter/envelope printing (which input slot?) Expanding our support of IPP job template attributes in CUPS and CUPS drivers may provide some future improvements to this, e.g. media=na-number-10-envelope might select both a page size and input slot appropriate for that driver/printer, based on attributes (hints) in the PPD file specific to that driver/printer.

On the driver side, many drivers already do defaulting based upon the options that are passed in. The kind of defaulting they do is generally very printer- or vendor- specific and not something that lends itself to standardization, so while an app/user may be able to take advantage of this defaulting, you have no way to define what that defaulting will be in the general case.

In short, we can improve the no/simple print dialog case by better using the information we already have (without "forty lines of code per application and printer driver"), but need to recognize the limits of that information.

______________________________

As for the user-customizable print dialog, I've pushed for this for several years now, and even did a short (crude) demo which is available on my home page:

http://www.easysw.com/~mike/uiexperiments.html

Apple has also experimented with the "no print dialog" approach, and if you sign up as a developer I believe you can get access to last year's WWDC presentation on the subject.

I think the key is to provide a user interface that can be customized, per application/printer, to show the options the user is interested in for that application/printer, with the default dialog providing a list of printers and a "print" button. 

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

portrait of Peter  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