[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Print Manager should not be moved to kcontrol "Peripherals"!
From:       Kurt Pfeifle <kpfeifle () danka ! de>
Date:       2002-01-02 22:35:21
[Download RAW message or body]

<this is a plea for kdeprint>

Hi,

I am not a developer, but doing a lot of work related to printing. Not the
private printing at home, but enterprise level printing in large print shops
or office workgroups.

I have been documenting the new KDEPrint module recently, writing the KDEPrint 
Handbook and contributing to the http://printing.kde.org/ website. 

IMHO it is a bad move for the KDEPrint related kcontrol module to be taken to
"Peripherals". (This is not only because it requires me to change things and
screenshots for the new documentation, which time could have been used to
document *new* things and fill existing gaps.)

I was just about to start with the writing the new KDEPrint-3.0 Handbook.
Unfortunately, I missed the discussion that has taken place on your list about
it (I'm not subscribed) and discovered the change only after I succeeded with the 
CVS compilation (not at all easy for me, but essential to start writing the docu).

To put the printing manager into peripherals might seem logical to someone 
who only has a printer connected via /dev/lp0 at his disposal. But printing
has a lot more than that to cover....

I have read the argument "it is more easy to find in peripherals as users 
expect it to find it there". Well I didn't look for it there until I systematically
scanned the whole visible tree. A lot of existing KDE users will suffer the same
confusion when they use KDE3 the first time. And even converts from the MS 
Windows OS will not expect print administration amongst "peripherals".
You look it up yourself, if you want to know...

When I first realized the change, I thought it to have been done in error,
or by someone who had shifted it for the pure sake of "changing". Now that I 
know, there was even a short discussion on your list, I still feel strong
about it.

I have read the argument "it is psychologically easier for users to touch it
if we don't call it a 'system' task." Well, I won't really comment a lot on this 
argument. But a user will be in trouble if she just clicks around in the printer
manager without knowing what to do, even if you put it in "peripherals". Moving
the module doesn't ease the task one iota.

Printing is not at all comparable to configuring a mouse or a keyboard (difficult
as this might be in cases). And there is a reason, why you traditionally
needed root access to configure printers and printing in Unix. There are 
statistics that point out: the effort for administrators to handle network 
printing (including Windows network printing, which is in my experience *not* 
a lot easier to administer...) in their day-to-day tasks consumes up to 66% of 
their time (the most moderate statistic I know of, speaks of 25%).

Printing and network printing is (and remains) one of the most complicated
tasks for everyone dealing with day-to-day IT business. (Lots of different
hardware, lots of different protocols, lots of printer languages, page 
description languages, implementations, conversion software, filters ...no
one single standard involved agreed ba everybody. To get a document as displayed
on screen to be read on paper involves a lot of error-prone steps and a lot
of correctly configured components, ahrdware and software.)

The work of Michael Goffioul for "making KDE/Unix ready for the desktop" is 
in my opinion still very much underestimated -- even inside the KDE core 
developer group. This is likely "the natural thing" of Open Source or Free
Software developement, because the developers do normally "scratch were they feel 
itches" -- and their printing problems (my guess) are only related to printing
on small parallel or USB attached printers. They probably can't imagine
a kcontrol module responsble for 50 or moer printers and more than 1000
users...

To me, "printing from the desktop" starts, true, at the "desktop at home"
at the private users' box, but it stretches to the enterprise desktop
(probably only running "Thin Clients") with a network of 1000s of users.

And here it is were we talk "business"!

You might not know (but I tell you now as much as I can), that there are some
big institutions out there, with a lot of financial power, who are still 
heavily using OS/2 on their desktops, running some proprietary ERP (lets call
it so, even if it is banking or insurance...;-) software. They will still 
do so for the next 12 or more months. But they have their task forces already 
investigating what would be the replacement for OS/2: believe me, Windows 2000
and Windows XP are not the only candidates. (Maybe I am not telling you
any news here, but some of you might have forgotten about it...) And I know
too: those evaluation teams are also considering KDE as a platform for their
new desktops and Qt for the porting of their programs (if they are not written 
from scratch).

For users from that corner, decent printing and related administrative tasks
is a mission critical administrator as well as day-to-day desktop user issue.
They will never compare it (for lack of alternative) to a mouse or a keyboard.
These two normally "just work" (true there are now issue with the Euro-
Character, and there is a bit of complication to get it from generating a
keycode by hitting a key to displaying a certain letter on screen -- but
do you hear as many cries for help in the newsnet about it as about 
printing?). 

They are testing CUPS right now to see if it fits their needs (they need
TLS/SSL-encryption for their printjobs crossing the inter- or intra-nets
and other features). And they were very pleased and impressed to see what
KDEPrint as a CUPS frontend is already now giving to them, when they were
lurking at the KDE booths at "Systems" in Munich and "Linux World Expo" in
Frankfurt!

KDEPrint is an essential feature for making "Linux ready for the desktop"
(and in some environments even more important than KOffice, probably). And
thanks to Michael (and his pre-decessors and supporters in the development)
it is already *ready* for the desktop, due to its nearly full-scale CUPS
support.

To move printing management from "system" to peripherals doesn't sound logical
to people from an enterprise background; it doesn't make it easier for 
the user to find it; it doesn't make it easier for a user to *use* it;
and it doesn't reflect the importance of printing for KDEs success on
the desktop.

So if there should be a move at all:  t h e  o n l y  p l a c e  o u t s i d e 
o f  t h e  " S y s t e m "  b r a n c h  i s  a t  t h e  t o p  l e v e l ! 
(Yes, I regard "Printing" to be of the same importance as "Sound" and "Power 
Control" for enterprise level desktop computing...) [Maybe the home user will 
disagree with my last sentence, and I understand that ;-)  ]

Printing at the top level of kcontrol would also make it possible to structure
the different submodules of KDEPrint more: printing manager, add-printer-wizard,
kprinter, kjobviewer etc.

To make "Printing" visible on the top level of kcontrol would reflect all the
needs that came to the fore so far: easier finding and accessing the module,
encouraging people who are horrified from touching "System" (I am not so sure
if I wouldn't prefer to keep them away from printing too ;-), reflecting
the importance of KDEPrint for the system, etc.

But don't put it at the top level without Michael Goffiouls acknowledgment
beforehand; he told me he'd need to do some code changes for this (even as he
likes the idea, this would take some time).

</plea>

Thanks for reading and considering,

Kurt
-- 
+--------------------------------------------------------------------------+
|              .--.                                  CUPS + ESP PrintPro:  |
|             |o_o |                                 ********************  |
|     ~       |:_/ |                Unix/Linux Printing made fun and easy  |
|    ° °     //   \ \               http://www.danka.de/printpro/faq.html  |
|    /V\    (|     | )  .~.         Kurt Pfeifle,  Danka Deutschland GmbH  |
|   // \\  /'\_   _/`\  /V\                Tel.:   +49-172-715.7017        |
|  /(   )\ \___)=(___ )/( )\               mailto:kpfeifle@danka.de        |
|   ^`~'^              ^^~^^                                               |
| Network Printing Services: Consulting+Training+Workshops+Troubleshooting |
+--------------------------------------------------------------------------+
[prev in list] [next in list] [prev in thread] [next in thread]