[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 20:50:28
Message-ID: BAY7-F49GP6YDPHdKlq000039fe () hotmail ! com
[Download RAW message or body]

>From: Dan Jensen <admin@leinir.dk>
>Date: Wed, 5 May 2004 20:19:51 +0200
>
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
> >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?
>
>   You cannot drag the actual site, but you /can/ drag the icon from the
>address bar... And yup, I've wanted to do this before :) Also, it would be
>good for consistency, if we use pop-up menus for navigating other places
>(Back, Up, Forward, Home...)

I had not realized you could drag that icon, but you are correct. However, 
this runs into one of those irritating little conflicts: It both makes sense 
to drag into the bookmarks, and it makes sense to drag into the targets of 
the bookmarks.

Now, I see many ways to deal with this:

(1) Only Allow Dragging Into the Bookmarks List
When an item is dragged into the bookmarks list, it will display a line 
where it would be inserted, and then it can be dropped into the list.

(2) Only Allow Dragging to Bookmarked Targets
When dragging into the bookmarks list, valid targets are enabled and invalid 
ones are disabled, and dropping the item on an enabled target displays the 
Move/Copy/Link option.

(3) Combine the Two
As bookmark folders are not valid targets, dropping on them would add a 
bookmark, as would dropping on an untaken portion of the bookmark bar. 
Dropping on valid targets would display the Move/Copy/Link options and be 
treated as dragging to that location. To help keep it clear what is to 
occur, the tooltip over a target to bookmark would be "Add bookmark"

(4) Further Combine the Two
As (3) but with an option added to the Move/Copy/Link menu. The menu would 
instead be Move/Copy/Link/Add Bookmark.

I do not like number one because it breaks the idea that if you drag an item 
to something representing a location, you are moving it.

I do not like number two because I think that bookmarks are mostly used for 
web-browsing, and that means you can't drag to most of them anyway.

I do not like number three because it mixes metaphors.

I prefer number four to number three because it leaves more options open, 
but I don't like it for the same reasons as number three.

So, basically, none of the choices I see are just plain good. I would love 
to have a little discussion of this. Although this is an awkward choice to 
make, it doesn't invalidate the drag-and-drop idea in toolbars, because any 
choice will be beneficial.

> >Dropping items on the KMenu
>
>   Yes, indeed this would be a great leap in usability... That, coupled 
>with an
>ability to right-click on KMenu items and pulling up details, thus editing
>the KMenu from the KMenu :) This is already possible in the Bookmarks menu,
>so why not the KMenu :)

Again, a conflict. Dragging items around in the KMenu is nice, but right now 
when you drag an item to a link to a program, that program opens the item 
(or tries to). Obviously, this interferes with being able to move items in 
the KMenu. Would there be value in having a distinction between .destkop 
files and other files? I would prefer to avoid it.

The other alternative I see is as with those above: pick one behavior, allow 
adding to menus only and allow dropping to programs to start, or add an 
option to the drop menu to allow inserting into the menu or starting.

I think that adding the menu option here completely defeats the purpose of 
dragging to programs for quick an easy opening, so I would rather avoid it.

> >Placing menu-showing delay option...
>
>   The first place I looked for this option was in the Style kcc... It 
>seemed
>the best place to configure settings for menus... Then I looked in Mouse 
>(as
>it's of course when the mouse hovers...).
>
> >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).
>
>   Well, I guess we could simply change those three into one that reads 
>"Drop
>here" or somesuch...

Why do they need options? If you release on something, you just dropped it. 
What is unclear in that?

> >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.
>
>   Yes, but this menu would only show up after hovering for that magic 
>amount
>of time that we've already discussed before ;)

But that changes the behavior of that button, which never shows a menu 
otherwise. I would rather avoid changing the behavior of widgets.

> >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.
>
>   Aah yes, I honestly forgot to write about those :) I wasn't thinking of
>having that quick-browser type menu show up there, I was more thinking of
>this:
>
>Back/Forward would have (for example)
>
>/home/user/Downloads
>/home/user/Downloads/Desktop Stuff
>/home/user/public_html/images
>/mnt/music/comedy
>/mnt/music/comedy/Eddie Izzard
>
>Up would have (for example)
>
>/home/user/Downloads/System
>/home/user/Downloads
>/home/user
>/home
>System Root
>
>   Dropping on any of those would of course pop up the dropped file actions
>menu :)

And, as that doesn't change the behavior of the button, I agree.

> >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.
>
>   This is a very good point, yes :)
>
> >Using even if fd.o don't like it
>
>   This is also a very good point ;) And yes, indeed, we should implement 
>it,
>then show it to fd.o and see if they like it enough :)

Well, we should plan it out, then show it to them for comments, then 
implement it.

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