notes from san francisco: pdf

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.

PDF creation is ‘printing to virtual paper.’ The whole transformation part is there, the formatting of application data for a printed medium of a certain size (A4, letter). Some printing bits are missing, like finishing (sorting of pages, stapling, et cetera), but the similarity is striking.

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.

strange relative

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 APIs, most if not all can be recycled for pdf export.

That’s it for pdf. Next up: the results of a first wave of dialog usability testing.

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