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.
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.
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.
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.
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.
2 comments (post a comment):
- at 19 October, 2006 00:00, Harry commented
- Peter, I like your thoughts on painless printer management (I'd prefer to call it painless installation… management implies ongoing monitoring), vendor supplied defaults (maybe even some standardization in this area.. like a device can always be expected to print draft or high-quality out of the box), simplification of exposed options and facilitating workflow patterns. The enterprise will require more of the underlying platform, however, in that it needs a surefire way to gather accounting information tied to end-user behavior. I gather you are focusing on UI so this may not be your concern. Some enterprise output management guru’s have suggested a UI component where behavior may be prompted (…” are you sure you want to print 13 copies in color using simplex”…). I find this a repulsive thought (I wouldn’t have requested it if I didn’t think I needed it) but (well done) accommodations of this type in the standard print framework may help strengthen Linux posture in the enterprise.
- at 26 October, 2006 16:55, commented
- While you're on the subject of printing, I can't help but share this cracking video http://www.zshare.net/video/otpuska-wmv.html
That guy really rethinks the use case, ehh? :D