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

List:       kde-usability
Subject:    Re: KDE improvement suggestions
From:       Esben Mose Hansen <kde () mosehansen ! dk>
Date:       2005-02-25 23:04:45
Message-ID: 200502260003.55656.kde () mosehansen ! dk
[Download RAW message or body]

On Friday 2005-02-25 20:18, Uno Engborg wrote:
> Esben Mose Hansen wrote:
> >On Friday 2005-02-25 14:50, Uno Engborg wrote:

> >>
> >>Actually, the current state fails the discoverability test as well, you
> >>can't find "link here" anywhere.
> >
> >That sentence doesn't make sense. It is as discoverable as it going to get
> >with the current drag&drop mechanism. It is just as discoverable as copy,
> >move, ie, when you drop a file, it will be in the menu.
>
> No, you can perform the move and copy operations from the edit menu by
> doing cut and
> paste. There is no similar way to do a link.

I doubt many users correlate the Edit menu and drag&drop, and if they did, 
they would get burned often. E.g, many programs use Edit->preferences, which 
makes no sense drag&drop wise. If that is what you meant. Could you please 
elaborate the more difficult arguments a bit? I can't always follow you.

>
> >>I would like the menu to go away altogether, and drag should just do the
> >>most frequent operation, i.e. move.The other operations should be
> >>possible from edit menu, and perhaps the standard file rmb context menu.
> >
> >Is move the most frequent operation? It depends on what you are doing, of
> >course. If you are dragging files to a removable harddisk/usb key, then
> > copy would be the norm (I guess).
> >
> >For this reason alone, your proposal is flawed.
>
> Moving files between different physical media is a totally different issue.

But different medias (and networked drives, pseudo file systems like 
"printers" and so forth) are something Konqueror have to encompass as well, 
with the same UI --- that's what transparency is all about. So are you 
suggesting making drag&drop useless for these (major!) cases, or something 
else?

>
> Even if my statistics for move being the most frequent selection would
> be wrong, wich I very much doubt,
> since I feel that KDE works much better since the order of the drag&drop
> menu changed a while ago.
> it is the only choise that makes sense if you see it from a desktop
> methaphor point of view.

Neither of us are native speakers, I think, but I also think you have the word 
"since" wrong. Are you saying that KDE drag&drop got better due to a change 
in the drag&drop menu? What change is that? Sorry if I'm being dense. 

I never understood the desktop metaphor. My real desktop is a mess, and have 
always been so. My computer desktop is quite orderly, provided I can have 
multiple desktops. A wild guess: You are saying move is the most common 
operation in KDE because copying real world desktop objects are uncommon? 
Again, please elaborate you argumentation a bit, it's too sketchy for me to 
follow.

>
> >>The idea get the rmb context menu on mouse up instead of mouse down was
> >>to make it  possible
> >>for old KDE users to at least be able to have a similar behavior as they
> >>have today, even if admittedly
> >>at a somewhat less discoverable position.
> >
> >I still think this is an bad idea. I see no gain, and a lot of
> > inconsistencies stemming from the right button drag.
>
> As far as I'm concerned, I don't need the drag&drop menu on any mouse
> button.

I use it... but then I seldom drag & drop more than a few files. For many 
files, I prefer the command line interface (I've been using computers since 
the Intel 8086 days, so I can be a bit old fashioned). I like the menu 
because I often copy, but once in a while want to move.

> But if we should have it, it is probably a better idea to have it on the
> right button than the
> left. Then at least all the users comming to KDE from that other DE that
> 90% of all people
> tend to use would feel at home.  I don't hear many people complaining
> that it creates
> inconsistencies in MS-windows,  could you elaborate on what  problems would
> happen in KDE?

This has been chewed to death on this mailing list before. Please just search 
for it. But in short: Try it. Every popup menu in KDE works like that. The 
reason has something to do with all these usability laws; you would have to 
ask somebody else for the details.

>
> >I just tried it. It was as simple as could be hoped for
> >
> >1. shift click first item
> >2. shift click  last item
> >2. shift click (if you want) and drag.
> >3. before drop, pressed the shift key (or ctrl key to copy)
> >4. drop
> >
> >Can't be much simpler, can it?
>
> Congratulations you have the life ahead of you :-)

How simple can it be? Let's see. What pieces of information do you provide? A 
range of source items (2 pieces of info, begin and end), a destination (1 
piece of info) and an operation (1 piece of info). Above, providing these 4 
pieces of information took 5 operations. So in theory, we could do away with 
one. Which one? Well, the drop doesn't provide any extra information after 
the drag. But I sure like to not have to drop end as soon as I stop moving 
the mouse, and I don't think I am alone here.

>
> >>What I meant when I said that newbies have more problems with the
> >>current state than
> >>experienced users is that they don't know how to use modifier keys to
> >>expand selections.
> >
> >Which is silly, because newbies usually don't use drag&drop at all. It
> > just isn't discoverable, and I can't see any way to make it so.
>
> It depends. If you never have seen the desktop methaphor in action that
> is probably true.

So you are saying that the users may use the drag&drop if shown by some 
presenter? If think you are right there. But if that was the case, they could 
(later) ask this presenter on how to avoid the menu, who could write a piece 
paper: Hold shift for move, ctrl for copy. Or whatever. Or they could guess 
from the menu. Or read it in a nice, friendly passive popup, the manual or 
something.

> However if they haven't, we don't give them enough help to get them
> started at all.  To help this
> group of users you need some kind of first time user introduction that
> learns them to handle
> the mouse and such. The first Macs came with such tutorials.

The difficult part about tutorials is getting people to read them, and 
remember what they read.

>
> Users that have seen some desktop DE or only use it occationally will
> know how to drag and drop.
> Various modifier keys are much harder to remember though.

Remembering where drag&drop is possible is the hard part, in my humble 
opinion. *I* often can't remember this. The other part is just watching the 
cursor while pressing some of the shift-ctrl-alt keys.

Actually, I find the use of the shift key for range selection common in the 
non-power users, funnily enough. But that may just be statistical noise.

[...]

> Now he runs Gnome. So I guess he is silly;-)

Yes, I would say that installing a completely different desktop just to avoid 
holding shift down while dragging is silly. No offense. But if he likes Gnome 
better, great! Nothing wrong with that.

>
> >I think the next step forward would be friendly, passive popups that tells
> > the user about neat & new tricks.
>
> Perhaps we should ask the artists for a nicely designed paperclip
> graphics to go with it;-)
> Seriously, that is a good idea as long as you can turn it off.

Even the infamous paper clip could be turned off, or so I understand. But the 
popups should probably have a checkbox labeled "Never show these popup again 
[ ]", like the current "don't show this dialog again [ ]". 


-- 
regards. Esben
_______________________________________________
kde-usability mailing list
kde-usability@kde.org
https://mail.kde.org/mailman/listinfo/kde-usability
[prev in list] [next in list] [prev in thread] [next in thread]