27 April 2009, 23:36
Two weeks ago, I presented about the ongoing work on the printing dialog at the openPrinting summit in San Francisco. Some of that was an overview of what had happened since Montreal, that you could already read about here.
Three distinct topics formed the new and notable in my talk, I will present them here in three separate blog entries. First up, a topic long overdue.
what about pdf?
As part of the second season of usability project for openPrinting we had a closer look at generic pdf creation, because it is handled via the printing dialog on all main desktop platforms. First, we found out why engineers were tempted to implement it in that way.
Another factor became clear when we looked at under what circumstances does it make sense to create a pdf from an application. Answer: if it is worth printing, it is worth making a pdf of. So if it walks like a print job and quacks like a print job, why not represent it like a print job?
a spanner in the works
There is one slight problem: users won’t have it. No matter how long it has been the norm to create a pdf via the print dialog, they have no idea why it is ‘hidden’ there. To them it feels as printing via the ‘save a file’ dialog would be: very strange.
Users see pdf creation as document creation. A document that is highly predictable in how it displays on another computer. And that they feel is relatively immutable. This showed us why users create pdfs and by tuning in to that we found the correct way to represent it.
back to reality
Connecting all the dots we see that pdf creation is actually a file export, and that is what our solution model is based upon. In the simple case that will mean a ‘Export to pdf…’ in the file menu; for applications with existing export functionality, it can integrate there.
Ironically, although pdf creation has been banned from the print dialog by this move, it is still up to the printing framework to provide it. It is a nice example of how the user‐world and engineering‐world can be at odds with each other. And of how it is up to interaction architecture to reconcile these two worlds.
The dialog for pdf export won’t be a twin brother of the print dialog. That follows as a matter of fact from the tasks of printing and pdf export being different, with a different meaning to users.
For instance, to fit the task, the pdf dialog will have a much larger size than the 640×480 limit I set for the printing dialog. Being sized more like a main application window, this extra space will be used for a much larger preview area, which is called for in document creation.
The dialog for pdf export will be a cousin of the print dialog. That follows
from the identical transformation for printing and pdf export. Interaction design innovation,
code and application
That’s it for pdf. Next up: the results of a first wave of dialog usability testing.
If you like to ask Peter one burning question and talk about it for ten minutes, then check out his available officehours.
What is Peter up to? See his /now page.