Rethinking the User Interface for Printing21 Jul 2008
The user interface for printing documents and other content follows the same pattern in most current graphical user interfaces: users preview and print documents by invoking application commands. However, to monitor the status of documents in the printer queue, users must leave the application and use a separate print-queue user interface provided by the operating system. This split in what should be a unified task—printing documents and monitoring their progress—mirrors the split in the underlying implementation: applications are responsible for previewing printed documents and for sending documents to the printer; the operating system is responsible for monitoring the status of the print queue. Whenever software reflects implementation details in its user interface, usability suffers.
Apart from splitting up the user interface, dividing responsibility for printing between applications and the operating system is inflexible and inefficient. Flexible designs accommodate changes their designers did not foresee. For example, although the assumption that an A4/letter printer is available is currently reasonable because most printers use A4/letter paper, this is likely to change in the future. It is not hard to imagine a wide range of printing devices, not just for paper sizes larger than A4/letter, but devices that output content onto completely different materials, such as T-Shirt printers and fabric looms. The print preview user interface for these materials will likely be different from the print preview user interface for paper. However, an image-editing application, for example, shouldn’t make a distinction between printing an image on paper and printing an image on a T-Shirt: accommodating different printing devices in each application’s print preview code is inefficient. Fortunately, by rethinking the way applications preview their printed output, accommodating different printing devices in each application’s print preview code is unnecessary.
Since developers have no way of knowing on what devices their applications will output content, a more flexible and efficient approach makes the print preview code for a printing device the responsibility of the printing device’s manufacturer. Print preview code would then be packaged as a module that applications would call upon to provide print preview when users select the device for output. The print preview code module for a printing device would be installed with the driver software for that device.
Moving the responsibility for print preview from application developers to printing device manufacturers is a good first step, but we should go further. If we take the responsibility for print preview away from applications altogether and assign it to the operating system, we can unify the user interface for printing with a simpler conceptual model: users send documents to a printing service. The printing service is responsible for providing the user interface for previewing printed output and for monitoring the progress of jobs on the print queue.
The printing service user interface should provide the following modeless feedback:
- the progress of the current job; and
- the number of jobs in the queue.
The printing service should also provide modeless feedback when the following situations occur:
- the number of sheets in the paper tray drops to a pre-set threshold;
- the paper tray hold too little paper to complete the next job in the queue; or
- the amount of toner is low enough to affect print quality.
The print-queue user interface should present the following information for each job:
- the title of the document that the pages are from;
- the name of the file that the document is stored in;
- the number of pages printed so far;
- the number of pages remaining to print;
- the page numbers of the pages to print;
- the number of sheets of paper required (composing two A4 pages side by side requires one sheet of A3 for every two pages in an A4 document); and
- a thumbnail of the first page to print.
Additionally, the following information should be displayed for the current print job:
- the time required to print the current page (pages with graphics take longer to process that pages of text);
- the time required to print the remainder of the job; and
- the progress of the job in terms of the number of pages that remain to be printed.
The print-queue user interface should also enable users to perform the following operations:
- remove a job from the queue—including the job that is currently printing—by selecting one or more jobs and tapping delete;
- change the order of the jobs on the queue by selecting one or more jobs and dragging them to a different position in the queue (subject to the permissions necessary for shared printers, which should be indicated with modeless feedback);
- pause and resume the queue;
- change the printer settings—such as print quality (draft/final)—for any job in the queue, including the currently printing job (changes to the currently printing job take effect on the next page); and
- change the printing device.
To enable the printing service to provide its modeless feedback and print-queue information, printing devices must supply the following information to the operating system in real time when polled:
- the amount of toner remaining in terms of the number of pages the device can print without affecting print quality;
- ideally the exact number of pages left in the paper tray, but at the very least the number of pages as a percentage of the capacity of the tray;
- the time the current page will take to print; and
- the time required to print the remainder of the job.
These user interface requirements are geared towards laser printers. Some requirements, such as time-to-complete estimates, are common to all devices; others, such as consumables, are device-specific (laser printers consume toner and paper; fabric looms consume yarn). These differences highlight the flexibility of a modular approach to print preview code.
Taking the responsibility for printing away from applications not only makes application code smaller and the printing user interface more consistent, it also takes us a step closer to breaking free of applications altogether by providing a system-wide set of printing commands. For background reading on the benefits of system-wide commands see the sections Commands (page 109) and Commands and Transformers (page 143) of The Humane Interface; for working examples see Humanized’s Enso Launcher and Enso Words.