[Desktop_printing] Role of CUPS and error handling
ellen.reitmayr at relevantive.de
Sat Mar 25 11:55:51 PST 2006
-----BEGIN PGP SIGNED MESSAGE-----
while doing some printer installations for testing purpose I found that
me/we (the usability people) will need a lot more background information
on CUPS . The workflows in three distributions I've tested so far (SuSE,
Kubuntu, Ubuntu) confused me more than showing me the real benefits of
CUPS. I won't go into detail right now - we can do that in Atlanta - but
they were either asking for too many difficult decisions, permissions
were not set, or important options were not provided. The web interface
seemed to be more streamlined, but I've only seen it on an NX server
without a real network and printers around it.
Kurt, who gave me irc support during the different printer installations
proposed to have a personal, 1-day meeting before Atlanta to tell
exactly what the problems were, and to give further background
information on CUPS.
Thanks for your answers on that issue, they also were a lot of help!
Ellen Reitmayr wrote:
> In order to make printing usable, we need to make sure that the technic
> works. A huge amount of the current dissatisfaction with printing is not
> because of the interface, but because it something does not work (no
> auto-detection, wrong driver that produces mostly blank papers with few
> cryptic text, no 'ink/paper empty' notifications on most systems, ...).
> Surely a less complex interface with better defaults that diminishes the
> number of difficult choices a user has to decide on increase the success
> rate and therefore user satisfaction. But in order to do so we need to
> reduce the degrees of freedom.
> A crucial question is the role of CUPS in the future:
> - Can we make sure it will be the technic of choice for the major distros?
> - How does it perform in mixed environments (windows, linux, mac)?
> - CUPS itself may be very complex, for example when it comes to
> server-client relations.
> -- Can we facilitate those concepts for the user?
> -- Can we get rid of the notion 'server' and 'client', but simply
> connecting to printers that happen to be connected to a computer or
> directly to the network?
> -- Can we make sure we don't run into trouble if the same computer
> happens to be server and client (CUPS client only versus IPP Using
> Broadcast in SUSE)?
> - How much of the device recognition in the CUPS web interface can be
> made automatically? When manually setting up a printer, there are many
> choices a user has to decide on (ipp, http, socket, ....). Is something
> like 'scan network' or automatic recognition when a usb printer is
> connected something CUPS can do, or is it the OS? if it's the OS, is it
> a problem for us?
> - Assuming the above points won't cause problems, is relying purely on
> CUPS the solution to concentrate on? Or are there further reservations?
> Another aspect is error handling:
> When something goes wrong, it is crucial to provide proper error
> messages and directions how to go on. You wrote there are specifications
> for the error codes in the IPP specs and the CUPS IPP implementation
> guide. Also, you wrote that manufacturers can send their own guis for
> special error codes.
> - In the CUPS implementation guide
> (http://www.cups.org/documentation.php/spec-ipp.html), I couldn't find
> the error codes. Did I miss them, or are they stated elsewhere?
> - Are there guidelines for the manufacturers for the special error code
Desktop_printing mailing list
Desktop_printing at lists.osdl.org
Ellen Reitmayr email: reitmayr at relevantive.de
Usability Engineer mobil: +49.177.3325867
relevantive AG fon: +49.30.23455630
Saarbruecker Str. 38 fax: +49.30.23455639
10405 Berlin web: www.relevantive.de
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the Printing-summit