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

List:       kde-usability
Subject:    Re: Drag and Drop Improvements (Was: Drag and Drop Up-One-Level)
From:       "Jamethiel Knorth" <jamethknorth () hotmail ! com>
Date:       2004-05-05 17:38:16
Message-ID: BAY7-F93cYXF9x0TbbB00002fe2 () hotmail ! com
[Download RAW message or body]

>From: Dan Jensen <admin@leinir.dk>
>Date: Wed, 5 May 2004 16:46:47 +0200
>
>On Wednesday 05 May 2004 12:00, Jamethiel Knorth wrote:
> >A whole lot about the dragging and dropping of files
>
>   All of what I saw there seemed very good to me, and well thought 
>through, so
>I will just add my comments in appropriate places :)

Thanks.

> >[1]: Types of available toolbar icons
>
>   Bookmark bar should simply be a target in itself (as an add bookmark
>action), imnsho... But, it should also provide feedback to the user (like 
>it
>does now, showing where the bookmark will be created)... Also, in addition 
>to
>what we have not, and in accordance with [5], it would make sense to me to
>have the bookmark folders open and let you drop into place... A bit of 
>work,
>I know, but it would be good for usability as I see it. The same goes for 
>the
>buttons (Up, Back, Forward).
>   Otherwise, it looks good :)

That is a good point. It somewhat overlaps with not having targets for 
actions, but the bookmark folder is also somewhat a target. However, I 
wonder how useful it actually is. You can't drag the site, so when would you 
actually use this? All you could do is bookmark a file, directory, or site 
that you are not currently in. Have you ever wanted to do this?

> >[3]: Drag-and-Drop Opening
>
>   It would seem you can already, at least in some cases (Kicker lets you 
>drop
>files onto the Konqueror launcher, as well as opens the quick-browsers 
>(I've
>got a home folder quick-browser button there, and (after a quick test) it
>lets me drop stuff onto anything in the pop-up menu, but doesn't open up
>sub-folders on hovering over them, which seems counter-intuitive to me)).

Well, it's good that its part-way there. It should be all the way there. I 
can drag to it or to quickbrowsers and folder links, but the Panel does need 
to allow the submoving on the quickbrowsers.

At the moment, the Panel doesn't let me browse the KMenu, and it should. 
Apparently, you already can properly drag files to .desktop files (which is 
good) and links to .desktop files (also good) so the KMenu should support 
dragging to entries in it.

> >[4]: Drop Delays
>
>   I agree that the delays would very possibly become counter-intuitive,
>because timing is not the same for everybody (in fact, very much not the
>same), and we don't need another nit-picky option for this.
>   However, it might be possible to make this the same amount of time as 
>the
>current menu opening delay.

I think this is a problem because I cannot configure those delays (as far as 
I know) and even if I could, they might be inconsistent. Also, I would 
likely want them to be different. Personally, I want the drop-delay to be 0. 
In my personal usage, I'd definitely rather have no delay. However, I want 
delays for those menus. So, I think that we do need another option. I'm 
thinking it would probably go in accessibility somewhere, in the short time 
I've been thinking about it.

> >[5]: Pop-Up Menus
>
>   I agree with you here, however on the topic of pop-up menus I would like 
>to
>make my opinion on the whole "Remove the pop-up menu on dropping files"
>discussion. In my experience, users really like this feature (because they
>don't have to worry about "Oh no, what will this thing do to my precious
>document?"). Just like that ;)

I think we need the pop-up menu until someone gets huge icons on the pointer 
in the style of OS-X, where there's a sphere in bright colors telling you if 
you are copying or moving. That was one thing that OS-X definitely did 
right.

>   The pop-up menus could be structured as shown in [6].
>
> >[6]: Hovering to navigate
>
>   The MacOS version of this that people are referring to is called Spring
>Loaded Folders and was one of the most requested features to be
>re-implemented into MacOS X when it was removed from x.0 to x.1. So yes, it
>would seem to make sense to implement this. However, in stead of popping up 
>a
>lot of Konqueror windows (even with spatial navigation (comments on [8])), 
>it
>might be possible to open up a menu containing the folders, perhaps like 
>so:
>
>Home icon (hover the same amount as the menu delay [4])
>   [Header: /home/leinir]
>   Move here
>   Copy here
>   Link here
>   -----
>   Documents >
>     Move here
>     Copy here
>     Link here
>     ------
>     Work >
>     Family >
>       Move here
>       Copy here
>       Link here
>       -----
>       (No sub-folders)
>   Downloads >
>   Music >
>   Pictures >
>   public_html >
>   -----
>   Cancel
>
>   Header is only shown on the top menu. The idea is to make absolutely 
>certain
>the users knows where it is (The link might be a symbolic link).
>   There is only reason to have one cancel (anything more would possibly
>confuse the user, and also be counter-intuitive (does it cancel that 
>submenu,
>or the entire action).

I don't think I like this idea. First, there do not need to be 
Move/Copy/Link items in every entry, those can appear after the drop (they 
do in every other instance, so it is consistent, and the diagrammed method 
will get cluttered). Second, I don't think we need a full quick-browser in 
the Home button. If people wanted a quick-browser, we could add a button 
which is that, but it isn't useful. And, the drag-and-drop should remain 
consistent with the functionality of the button. The Home button goes to 
your homedir. Dropping on the Home button moves/copies/links to your 
homedir.

Also, these menus would be weird in the other buttons. The Back button can't 
really have a tree structure, it isn't a tree-structure. The Up button is 
kinda a tree structure, but it is reversed, starting at the top, so it 
doesn't work the same.

> >[7]: Lack of Knowledge About Targets
>
>   The tooltips shown on mouse-over would need to be instantaneous, and not
>have the normal delay, to be of use together with [4], [5] and [6].

Instantaneous after the target is valid to drop to, yes. We shouldn't have 
them jump up the instant your cursor wanders by, like hordes of eager 
fanboys.

> >[9]: Related Enhancements
>
>   Using the sidebar as suggested, with the automatic folding out of
>sub-folders would be slightly inconsistent with the pop-up suggestion in 
>[6],
>however an alternative way of doing this would be popping up a window
>containing basically a sidebar tree-view of the filesystem, with the chosen
>folder as root, and then simply doing what would normally happen, giving us
>the following set of actions to do:
>
>1. Drag an item and hover over for example Home
>2. A treeview shows up, with Home as root
>3. Drop the item on a folder in the treeview, using it as you would any 
>other
>filebrowsing treeview
>4. A menu shows up asking you what you wish to do
>5. You choose the action
>6. The action begins to be performed (giving appropriate feedback)
>7. When error dialogs have been shown, or when the transfer has begun, the
>popped up tree-view is hidden again
>
>   Of course, this would give us a problem with cross-platform things that 
>the
>suggestion in [6] does not, which of course gives us the option to decide
>that the small inconsistency that is is really isn't very big.

I don't think it is a big worry. They are in one sense inconsistent: they do 
not behave the same as one another. However, they both behave the same as 
they do in regular use for that widget, so they are consistent with the more 
important case. The Back button for moving back behaves the same as for 
dragging a file to go back. The tree-view behaves the same for browsing as 
for moving. Each widget is internally consistent. This is more important 
because it allows people to know what to expect based on how something 
appears.

> >[11]: Adding to Other Applications
> >[12]: Cross-Desktop Support
>
>   These two really go together... If we wish for this to be adopted
>universally, i.e. by other applications, it is is vital that a fd.o is 
>aware
>and supportive of this.

Well, not quite the same. Even if freedesktop.org doesn't like this, it can 
be used throughout KDE. But, yes. After a little more thought, maybe we send 
it over there?

_________________________________________________________________
Stop worrying about overloading your inbox - get MSN Hotmail Extra Storage! 
http://join.msn.com/?pgmarket=en-us&page=hotmail/es2&ST=1/go/onm00200362ave/direct/01/

_______________________________________________
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]