On Wed, 2004-06-16 at 11:11, Matthew Gregan wrote:
> But seriously, I think you'll find printing is spooled on any OS that
> isn't completely third world. I agree that it's often annoying and
> confusing for a user who's trying to stop a print job, especially if the
> printer has also buffered a large piece of the job.
It is also quite difficult to explain from an HCI point of view. I have
written an application that prints, and it is hard to give the user the
correct "mental model" of what is happening. For example, the user wants
to print, so a button is supplied that says "Print", all well and good.
Unfortunately, the print button does not print, it spools the job. If
you present the user with a dialog box that contains a progress bar of
the percentage of the document processed (as you should) it is tempting
to say "Printing 40%", but that would be wrong, because 40% of the job
has not been printed, 40% of the job has been sent to the spool. If you
say "Spooling 40%" the user gets confused because the button that he or
she just pressed said "Print", not "Spool", and what the hell is
spooling anyway.
What is really needed is a way for applications to talk to the printing
daemon (dÃmon?[1]) to find out the position of the job in the queue, and
the percentage of the job that has been sent to the printer. Then you
could present the user with a dialog box that contained a lists of
tasks:
* Processing document (p% done)
* Adding document to print queue (p% done)
* Waiting for other documents to print (n/m documents)
* Sending job to printer (p% done)
The system would indicate how far through each task it is, and tick of
each task once it is finished. This also would remove the need for the
user to know about the print manager, as there would be a dialog box for
every document he or she is printing, and the user would be able to
cancel the job at any stage using the dialog box associated with the
document.
[1] Sorry, UTF-8 withdrawals :)
--
Michael JasonSmith http://www.ldots.org/
