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

List:       sylpheed
Subject:    [sylpheed:22423] Re: Questions from a Sylpheed newbie
From:       Julian Opificius <julianop () barnlea ! com>
Date:       2004-02-29 19:14:48
Message-ID: 20040229131448.770bd329.julianop () barnlea ! com
[Download RAW message or body]

John Coppens, thanks for your supportive appraisal of my comment.

Alfons, it's much too late to be sceptical about the real world metaphor used in
GUIs. The whole desktop GUI metaphor has been around for over twenty years. But
I do empathize with your skepticism, though: I've worked on UIs for over a
decade, and I've seen some shabby work in that time!

What I'm proposing here is that we be more consistent in our application of it.
Had we collectively as UI designers (or programmers pretending to be such) been
consistent over the years, perhaps there would have been less cause for your
scepticism today :-)

The reason to use of a metaphor in the first place is that it gives intuitive
clues about how a user interface will respond to you, based on the rules learned
from your previous real-world experience. For the programmer to second-guess the
operator's possible predominant use of a particular operation with a view to
reducing the use of modifiers (like alt or ctrl) is to "out-think" the operator.
It breaks away from the metaphor, and squanders its value. Conforming
consistently to a metaphor, IMO, is more important than saving the operator from
hitting a ctrl key. In the case of color blindness, we still don't need to
abandon a metaphor: we could just augment it by employing other supporting
graphical indicators like shape change, or international ISO symbols, all of
which are easy in a GUI world.

And to extend Charles Crayne said in his first response to your post, to even
think of writing a move algorithm that does not verify the copy before the
delete is absolutely unthinkable.

I don't object to leaving the existing default copy/move behavior as it is, but
it would be very helpful if it were a configurable option.

Interesting discussion, guys :-)

julian.
==========================

On Sat, 28 Feb 2004 20:05:04 +0100
Alfons Hoogervorst <alfons@proteus.demon.nl> wrote:

> Lo John,
> 
> On 28-02-04 (Sat) 15:47 -0300 John Coppens wrote: 
> 
>  > <Opinion>
> | > If I grab something with my hands and move my hands, I move whatever
> | > I'm holding on to, I don't replicate it. That is a fundamental rule
> | > of the physical world into which we're born screaming. I see no
> | > reason to do it any differently in a desktop manager, which is, by
> | > definition,  a metaphor for the physical world. A copy function
> | > could be supported by something additional and optional, like an
> | > alt-click-drag, that is clearly available only in the computer
> | > world, and therefore can have special meaning.
> | > <...>
> | 
> | This is one of the clearest arguments I've seen for the copy/move
> | discussion, and I wholeheartedly agree. I was thinking about
> | reorganizing part of my mailboxes to IMAP, but this inter-boxtype
> | behaviour promises to be a major headache.
> 
> I, for one, have been trained to be skeptical about these easy going
> `real world` metaphors. There was a nice discussion lately in the claws
> devel list about a proposal to use the color green and red to show that
> some action was succesful. However, the real world also has color blind
> computer users.
> 
> | Computers being what the are, would it be very difficult to make the
> | copy/move decision configurable? I like the drag=move/alt-drag=copy
> | proposal.
> 
> As I said before, I wouldn't care less. But you could also argue for
> `safety`: now a move does not delete the original folder. Imagine that
> something went wrong during the transfer.
> 
> Bye.
> 
> -- 
> Ecuación algebraico sin solución posible,
> a menos de poseer profundos conocimientos
> en matemática - Revueltas (Ocho Por Radio)
> 


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