preparing for lexington /2

18 October 2006, 22:09

After the first installment was published, Jan Mühlig and I worked some more on the openPrinting project.

ceci n’est pas une pipe

I was curious to find out what users expectations are—apart from ‘get it on paper’—when they print. So Jan did some user testing.

And guess what: there is no such thing as printing.

It does not exist as a task, as a meaningful activity. One moment you decide to see it on paper, the next it rolls out of the printer. Only invoking the print command has a place in between that.

print professionals

I can see how this holds true in general, even for people whose job focusses on the printed page as the final result, like print designers. Apart from going through a calibration process, their own printing of proofs has to ‘just work.’

Only people whose job it is to operate (big) printing machines do care about the process and its parameters. The operator and the specialised software to run those machines means they are exactly not within the scope of this project.

implications

All this validates our approach to work with defaults for different printer settings for different tasks. The printer vendors need to supply these, backed up and refined by the community.

The individual user needs to be able to refine and customise the defaults for their own workflow. And selection of a default must be really direct, selecting from a pop‐up menu is not going to be good enough here. It would defeat the purpose of the whole concept.

lead by example

We saw last time that life gets a whole lot simpler if you design the printing dialog for a specific printing model, working from its product vision, which includes market segment and the printing solutions offered.

But we cannot answer the question ‘what does a good printing dialog look like’ with ‘depends on the printer.’ That would leave all printer vendors and desktop projects completely in the dark.

generic medicine

So after some discussion Jan and I came up with the idea of designing a printing dialog for several generic printers, each representing an important market segment, examples of which are:

  • a personal laser printer;
  • a personal photo printer;
  • a workgroup color laser printer;
  • a department A0 plotter.

The resulting printing dialog would be generic in the sense that it is based on a generic product vision, offering a generic printing solution. But it would allow us to set the standard any printer‐specific printing dialog will be measured against.

more specific…

Vendors and software projects can then use these generic printing dialogs as a starting point for their own specific dialog. Not by dumping any printing parameter that is printer‐specific on a tab or dialog called ‘Special options’, but by integrating these with the generic parameters into something well‐organised that makes sense to the user.

Labels: ,

PS logo

2 comments · post a comment

preparing for open­Printing, lexington

11 October 2006, 01:06

In less than two weeks there is the openPrinting Summit in Lexington (US). Jan Mühlig of Relevantive and I have been invited to attend and to work on the user interaction and usability aspects of printing, as implemented on all linux platforms.

…where to start?

Apart from starting to discuss with Jan, who has been involved with this project for a while, I also had a hand‐over session with Ellen Reitmayr while enjoying some Sudanese food. Ellen worked with Jan on the project, but has decided to concentrate on KDE.

The project scope is vast: all current and recent production printers available, software at operating system level. Usage is very diverse:

from personal to enterprise printing
very much an experience question: is the printer directly connected to my computer, or am I sharing one of a hundred printers in the building with tens of others?
function
what is the print for: to read; to proof; to share; to impress; to exhibit.
printing virtual paper
is what is printed a virtual paper document (A4 or US‑letter formatted) that just needs to be realised on paper, or is printing a transformation of information. The latter is a different experience, with its own anxieties. Examples are printing web pages, photos or database records.
new patterns in working
one day working at the office, the next tele‐commuting at home: the default printer for each situation needs to ‘just work.’ More extreme: companies where nobody has a fixed desk, or even a fixed city where they work. It should just take one click every day to confirm the ‘right’ printer.

strategies

Each printer model is targeted at a relatively small market segment. The printer model aims to deliver a printing solution to this segment through its technology. If you combine these two, market segment + solution, then the unwieldy world of printing, as sketched above, becomes quite compact.

So below you will see a couple of times repeated that primarily the information that configures the solution for a UI design problem has to come from the printer vendor. Through their product definition and development process they are in the best position to provide it.

enter the community

To back up and refine the efforts of the vendors, the user community can play an important role.

  • back up, because vendors can get a bit sloppy sometimes when it comes to updating and customising printer drivers;
  • refine, because unforeseen usage patterns can develop for a printer, and also the ultimate printing parameters for hi‐spec photo papers on a specific printer can be provided by the paper manufacturer and then refined again by printing gurus.

So linuxprinting.org can play an important role in sharing drivers, best driver choices and defaults. In order for this to work, the giving part of the sharing, the entering of information, data or software to this website needs to be painless, meaning seamless integration into the printing UI.

Now let’s discuss areas that are in need of UI solutions.

problem zones

painless printer management

To start using a printer should be as difficult as ‘plugging it in.’ The plugging gets a bit more complicated in networked corporate situations, but I hear that help in the form of geographical display of working and printer positions is on its way.

This is also the place for solutions for new patterns in working. Sets of printers based on a location concept, and a way to make the printer‐of‐the‐day expire are minimum requirements here.

The rest should be ‘automatic.’ The best driver choice and the driver itself can be fetched from the internet. Yep, the printer vendors need to supply these, backed up and refined by the community.

too many options

People just want to print, not tweak a couple of dozen of printer parameters. So what we need is a small set of default settings, derived from market segment + purpose of the printer. Yep, the printer vendors need to supply these. Users can tweak their own defaults, and share these with the world, via the community.

The UI design of the printing dialog, with dozens of printing parameters, which in part are fully depending on the printer in question, need a general solution flexible enough to customise the dialog for the printer. The grouping of parameters and the actual controls used for these need (again) to be provided by the vendors, backed up and refined by the community.

It should be clear that whoever customises a printing dialog for a printer, needs the help of usability folks, to break away from the technical and to focus on user value.

broken printer?

I am told that at the moment printers under linux are technically not able to report back to the user why they refuse to print. This is an untenable situation.

The amount of anger these situations generate are contributing to global warming. Reporting in non‑technical language about the state of a printer is mandatory.

saving some trees

Oh yeah, I would like to save some trees while I am at it, simply by making duplex (where available) and two‐on‐a‐page printing options easier to use. People benefit too. It is much easier to ram a staple through 15 sheets of office paper, than through 60 of them.

Labels: ,

PS logo

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.

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