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

List:       kde-look
Subject:    Re: Fwd: Re: kde-look & -usability
From:       Dave Leigh <dave.leigh () cratchit ! org>
Date:       2001-08-29 1:19:24
[Download RAW message or body]

I'd like to begin just by stating that I really like Michael's idea (more
schmoozing at the bottom of message).  I just feel it can be better.

Michael's comments effectively explain why he designed it the way he did.  I'd
like to explain why I suggested the changes (they're not arbitrary).

--- "Aaron J. Seigo" <aseigo@mountlinux.com> wrote: 
> Hi.. 
>  
> in response to feedback Michael received on this 
> list re:KPrintAction, he put  
> together this email which i am forwarding on... 
>  
> that said, do people on this list think it is 
> productive to have this kind of  
> interchange between yourselves and the developers? 
 
Absolutely!  This is definitely a KDE look topic. 
 
> ----------  Forwarded Message  ---------- 
>  
> 1) you have to make a distinction between the action 
> of "saving" and 
>  "printing". In the first case, you're taking the 
> object with its internal 
>  structure and create a file that contains this 
> internal structure. 
>  "Printing" (in large sense) is something 
> conceptually different: from the 
>  object, you create an image of it in the form of PS 
> data, and that image 
>  doesn't contain the object structure anymore. You 
> have to understand 
>  "printing" as "create a PS image from my object, 
> and then do something with 
>  it (save it, convert to PDF, fax it, ...)". From 
> this point of view, it 
>  makes sense to group all those actions that are 
> performed on the image of my 
>  object, whatever the word you use (Export, Send, 
> ...). IMO, I find it more 
>  accurate to say "Print to PS/PDF" than "Save as 
> PS/PDF". 
 
From a UI perspective it doesn't matter which is more technically accurate. A
user has very simple criteria for making the distinction:   
"Print" ends up on paper,  
"Save" ends up on the users' disk,  
"Send" ends up somewhere else.   
 
These criteria do not require any understanding of the implementation
details.  Since the user knows none of these details anyway, the UI can't be
based on them and still make sense to the user. It makes no difference to
him how his file winds up at its destination, nor should it.    

Although the typical user doesn't care about internal structure, he as a
vague idea that when you "Save As" and choose a format you are taking one
internal structure and saving it on disk as a different one, which accurately
reflects what the user wants to happen when saving as PDF (which isn't an
image, BTW). In a technical sense this is even true of native file formats. 
Whenever you save you are taking the representation in memory and saving it
to a different representation on disk.  Otherwise we'd dispense with formats
entirely and perform memory dumps.   

> 2) From the developer point of view, "saving" and 
> "printing" are also 
>  completely different, they are handled differently 
> and corresponds to 
>  different code. It would be quite difficult (even 
> impossible) to mix both 
>  without messing everything, and loosing a large 
> part in flexibility. 
 
Again, implementation is not something the users are concerned with. I should
probably point out that my previous response results in a more flexible system,
not a less flexible one. Whereas the example would allow you to send a PDF by
mail, the more flexible alternative would allow sending the current file as a
mail attachment in any format already supported by the application.
The implementation is more challenging, true.   

> 3) KDEPrint deals with KDE. If people wants to have 
> a PDF printer accessible 
>    to any application, this is not a KDEPrint issue. 
> This is like wanting to 
>    have KDE LookNFeel within GTK application. If you 
> want a generic PDF 
>  printer, just use CUPS with a PDF backend (you can 
> find one here 
>    http://users.swing.be/kdeprint/pdf). 
 
Point taken. I built my own.  
 
> 4) Sending to FTP site is already possible, from the 
> file saving dialog. You 
>    are not restricted to local file, and you can 
> enter FTP locations. Network 
>    transparency is one of the great feature of KDE. 
 
Yes, I had to think a bit before suggesting FTP.  The reason I did is because
even though FTP is possible in the file dialog, it's not obvious how.  And, as
I stated before, the intuitive definition of "Send" is that it winds up
"somewhere else."  So I'd suggest that this is one of those situations where
it's a good thing to provide more than one way of doing something... allow them
to do it from the file menu (for those that think of it as a file operation)
and also provide an option under Send (for those that think of FTP as a
communications protocol). Mandrake, for example, has put FTP clients under with
their networking tools, so I'd suspect a large number of people think the
second way. 
 
But primarily I was trying to illustrate a reason to make the transport
mechanisms pluggable. It might have made more sense if I'd suggested something
like, "Send to PDA," which might be a Palm, or an Agenda, and might be
connected by serial port or USB or "Something Else." In any case, this part of
the response wasn't a suggestion to implement something new, it was a
suggestion to keep the design open. 
 
> 5) KPrintAction is IMO a well suited name when you 
> know what it's all about. 
>    KPrintAction is a class that implement an action 
> connected the the 
>  KDEPrint library. It allows a quick access to a 
> kind of printers: specials, 
>  regulars or both (depending on the application 
> developer). In that context, 
>  KPrintAction seems to be OK. The screenshot only 
> shows one possibility: 
>  special printers. But you could also have only 
> regular printers. BTW, the 
>  fact that you have all "Mail", "Fax", "PS/PDF" 
> entries grouped is because 
>  they correspond to special printers: in that 
> example, I used the 
>  KPrintAction to provide an easy access to all 
> special printers. 
 
Normally I (personally) would base the name of a class with its function, not
its implementation. Even though you're using the print library to get things
done, the intent isn't to get anything on paper... it's to send or save. But
this is a matter of personal style and convention. So I really have no problem
with the name, in that it's not something the users would see in any event, so
it's not a KDE Look issue. 

> 6) I don't think that it is sooooo bad to have 
> together: 
> 	Export/Send 
> 	  to Mail 
> 	  to PS 
> 	  to PDF 
> 	  to Fax 
>    Is it really completely senseless? 
 
It's definitely not senseless. However, it only makes sense to those people
with some level of understanding of the internals of KDE. The ironic part is
that the reason for the existence of KDE is so that people don't have to be
aware of those internals. To those without that understanding, it appears a bit
arbitrary and confusing. Part of the reason for KDE Look's existence is to
provide developers with feedback when they might be too close to the code to
see when they're confusing the poor feebs that use this stuff :).     

Quite frankly, I was quick to respond because I've wanted something like this
(especially Send to Mail) for quite some time now.  You're fulfilling one of my
personal "wanna haves," and I give you a standing ovation for the attempt.
Please take my comments in the spirit of constructive criticism.   

-- Dave 
 
 

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