Tatjana, Thanks for your inputs here :)
Tatjana S Heuser wrote: > > On CUPS, I'll just give a pointer to: > http://www.catb.org/~esr/writings/cups-horror.html yeah, I read that a couple years ago just after I packaged gnome-cups-manager for JDS on Linux. Didn't quite like what he said, but he got a lots of good points, not just for CUPS, but for engineer designed GUI ;) > > It's not easy to come up with a user interface (be it GUI, curses or > commandline based) where a user (who knows what he wants to achieve, > but is not familiar with the implementation) can "just do" what he > intents to. It's even more difficult to design this interface in a way > that it reinforces correct thought models of the process and discreetly > corrects those that lead to erroneous assumptions. > > As far as printing is concerned, it may be an interesting experiment to > take a look at the MacOS X GUI to CUPS, which is doing a few things > differently (while still modifying the same configuration files). Yeah, we will certainly take a look at that. We may have done so already in the past, someone in the communities definately have. > >>From a user point of view, I'd want a UI (User Interface, graphic or > not) to: > - show the status of a job I have submitted, if possible: > - where is it? (in queue, submitted to printer (to what > extent/page), printing (page count), in output tray x, stopped > (where in the process, and why? Is my job preventing others > from being printed, or is it just waiting indefinitely? What > is holding my job (Quota? too large for spool filesystem? Too > large for printer memory?) How long has it been waiting? Is > there an estimate how long it will have to wait in that print > queue?) My experience of this on L/Unix is not great, often once the job is submitted to the spooler. one just can't see its status. If it is still showed up in the queue, it is often because either a job has stuck there or printer on pause or wrong paper tray, something unnormal. I don't know of any open standard way of doing this as much, I see there are some works being done by the Free Standard Printing group to specify protocol to this level. Let me know if there are works being done in in area, I guess Norm is the man who is expert here :). > - which printing options have been set/are necessary for the > job? (paper size/specific paper slot, duplex, finisher > options...) > Not all printers may be able to give such a detailled feedback, but I'm > just summing up what I'd like to see at a glance, if possible. Also: > > - other print queues available, and their processing status > (busy/unavailable/idle since ... hh::mm, number of jobs, > estimated time until printout if a new job gets added, > estimated time until completion (speed of printer, and page > count of job are known, so giving an estimate isn't exactly > rocket science), capabilities of these print queues > (duplexer, finisher,location, paper options,...) > - with a gui: drop-and-drag movement of a job from one queue to > another as long as it hasn't started printing yet. Nice idea. Definetely cutting edge. > > As user, I'd like to select from already defined queues, be they local > or on the network, as well as add acces to those I may know that are > there (even if not explicitely preconfigured by administration as long > as they aren't blocked for me intentionally). It's difficult to > explain to a user why he might be able to use cat and ftp to print to > local or networked printers, but not the UI without prior "system > administrator magic". So I think there should be a way for a user to > define his own printer queues/spooling directories. If the UI gives the > status of a job as clearly as described above, (and is able to show on > which filesystem at which location a job in spool is lingering) I don't > hava a problem with personal configurations. We really ought to define the set of tasks that users should be allowed (to the limit that it doesn't interfere with other users) to do and make it really intuitive for them. > Some of those ideas require communication with the printer, but a > surprising number of them can be achieved by just keeping a "better" > track of jobs as they are submitted. This would also reduce the number > of dormant jobs in the filesystem which never got printed due to > errors. These are not just a minor hassle, but can turn out to be a > major security problem. At a site that shall be unnamed, there had > been the desktop computer from legal sent to maintenance. Once > connected there, it happily started printing an impressive stack of > (highly) sensitive stuff that had erronously been sent to an > unavailable printer (and, lacking better feedback from the spooling > system, just been resent when it never turned up). When the spooling > system noticed a printer with the desired capabilities, it just started > to spew out what had been hogging its spool. Nice story. Could be a good selling point :) > Therefore - better printer management (and usability in general) can be > considered a security feature. It's never wrong when a user knows where > his stuff went and what's happening with it. > Thanks again for the ideas! BTW, are you a usability guy? -Ghee
