Le 4 mars 06 à 16:53, Damien Pollet a écrit :
On 3/4/06, Nicolas Roard <[EMAIL PROTECTED]> wrote:
Yes, I think I agree. While I was curious about the introduction of
vertical separators, I think they indeed make the menu look busier.
To make a parallel with typography, that's kind like tables... many
people (maybe due to some office application with stupid defaults...)
tend to frame their tables and put lines to separate each column, each
line, etc... Often I only put one line below the column headers, and
use spacing (\quad in LaTeX) to separate columns. White space
separates better and doesn't bring noise (try applying a 10 pixel blur
to the screenshots).
For the detachable menus, I don't like that the menu title is
repeated, and takes the place of the 1st item.
Well, I don't like it either. At least the title shouldn't be visible
in the grab until the menu has been torn off.
Just writing this I got another idea... what if the mouse had a
physical button reserved for a "grab" action, rather than click =
select, double-click = activate, and so on... ?
That's pick and drop idea, it is planned to have such possibility in
Étoilé. Pick and drop is basically based on the idea of unifying copy/
paste and drap/drop.
Drag/drop vs copy/paste is a 'usability detail' , that has been sadly
reflected at implementation level ;-)
iirc copy/paste vs drag/drop inconsistency has been outlined in some
Anti-Mac writings.
Pick and drop ideas (somewhat outdated) are summarized on this page :
<http://www.dromasoftware.com/etoile/mediawiki/index.php?
title=Pick_and_drop>
Drag/drop works quite well for Window objects (unless they are
nested), but utterly fails with other UI objects. That's rooted in
two basic facts :
- UI objects visibility is window-dependent or container-dependent
(it's essential l when you consider them as drop receivers)
- you cannot manipulate two or more UI objects within a drag/drop
session
Drag/drop is an interesting UI mode because it doesn't suffer from
usual mode issues and introduces a very elegant metaphor useful for
casual users. Yet the cost of this benefit is very high : drap/drop
is always getting in your way and messing up your UI objects (windows
most of time) layout on your screen.
By getting in your way, I mean to use this paradigm you have :
- to discover whether drag/drop result is orthogonal to copy/paste
result, very often it isn't the case even on Mac OS X
- to discover whether the Desktop Environment is going to be smarter
than what you suppose, by sensing where you could drop (before you
are on the drop area) and ultimately by opening a path to the drop
area you have in mind (that involves to make fully visible the window
which encompass the drop area… Mac OS X is supporting this behavior
in a rudimentary manner only at Finder level, yet another level of
inconsistency. Though it has improved a lot today as a side-effect of
Exposé, but it's far to work flawlessly, just think to panels not
visible in Exposé mode to take an example)
- to try to reach the drop area, it fails quite often when the drop
area is partially/mostly obscured by some other UI objects (but we
are all lazy, so we give it first try…)
- to be careful before initiating a drag session, it could
potentially result in an erratic drop (or a destructive one) if you
decide to interrupt it (that's common when the drop target is not
reachable). Usually you have learnt the 'dead zone' workaround to
cancel a drag session. Or the magic key if you are a Mac OS X user,
just press 'esc' and the drag is cancelled. That's a nice trick, but
well it doesn't work in a consistent manner, it won't work if you
initiated the drag in a different application than the one currently
active. Finally Drag/drop is usually undo unaware when you are
outside of the UI object where the drag has been initiated.
Now the worst which happens in a recurrent manner (when you decide to
use drap/drop heavily)
- to layout differently your windows or UI objects on screen
(especially funny when it involves windows belonging to different
applications)
- to revert to your previous environment layout immediately or at a
later point
The very restricted mode bound to drag/drop results in various
interaction problems. To take an example…
Have you ever tried to deal with scrolling within a drag session, I
suppose so. The results are really mixed. I would outline you have no
visual clues and it is implemented in a way that totally ignores
Fitt's laws. Just test it in Mac OS X Finder icon view or list view,
it is always :
- scrolling too fast or too slow
- scrolling horizontally or vertically (when you want the reverse)
- activating another UI object (especially funny in Mac OS X Finder
with spring loaded folders mechanism… it is going to open a new
window and close the previously visible window where you wanted to
drop your stuff)
On Mac OS X, I have never been able to understand where is located
the hot point related to a scroll view (in order to scroll in the
middle of a drag session). In my experience, it worked more smoothly
on Mac OS classic, but far from perfectly.
I have described drag/drop issues with Mac OS X only, because Mac OS
is well known to be the kingdom of the drag/drop. At least, that's
what Mac users love to tell to everybody :-)
All that ranting to state that drag/drop (copy/paste too) should be
supported as casual user feature, being by its paradigm a restricted
version of a more general paradigm (let's call it Pick and drop ;-)
Cheers,
Quentin.
--
Quentin Mathé
[EMAIL PROTECTED]
_______________________________________________
Etoile-dev mailing list
[email protected]
https://mail.gna.org/listinfo/etoile-dev
