preparing for openPrinting, 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?
- 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.
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.
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.
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.