Re: [Usability] Auto-raise windows while drag-drop engaged?

[Máirín Duffy <mairin gmail com>]

On Mon, 11 Oct 2004 20:13:17 +0300, Kalle Vahlman
<kalle vahlman gmail com> wrote:
> Consider a smaller window on top (and fully inside the frame) of a
> larger window. You drag from a third window or even from the bigger
> window, if the only criteria is the position of the mouse.  Now what
> happens is that the small window is fully visible at the moment you
> start the drag, but there's no way you are going to get a chance to
> drop to that small window if the big one always pops over it. A
> waiting time of x milliseconds is not going to erase that problem,
> although it probably would lower the change of that happening. But it
> can still happen, and at least personally I would shoot the programmer
> after just one incident if I got the chance ;)

This reminds me of an interaction from a drawing/graphic editing
program, Macromedia Fireworks. Let me make an analogy - let's say the
windows are rectangles on the canvas in Fireworks. There is a tool in
Fireworks called the "Select Behind Tool," and it allows you to focus
objects that are on the canvas but are hidden/partially hidden behind
other objects.

The way the tool works in the scenario that you described is that when
the mouse is over the smaller rectangle that is enveloped by the
bigger rectangle, the smaller rectangle will always get focus (even if
it is hidden behind the larger rectangle.) You can select the bigger
rectangle by mousing over the parts of its area that the smaller
rectangle does not overlap.

However, I think it would be annoying to have full windows popping out
in front of each other - I think this would confuse users who would
conclude that the windows are physically moving out of the order they
left them in and potentially be upset / thrown off. It's a bad idea to
move things from where users left them or even give off the appearance
of doing so because they feel a loss of control and may panic. I think
it would be better to show the outline/frame of each window as it's
being "focused" (the same way that window outlines/frames are shown in
Gnome as you alt-tab between windows.)

It *is* important that people know more information about the window
they are dragging into than just the approximate area and position of
the window on the screen. Solutions to this could be a little tooltip
thing that reads off the titlebar of the window, or maybe a little
picture-in-picture-like preview window in one set place on the screen
that shows a screenshot of the window (the PiP would probably have to
be either really tiny or perhaps transparent so it wouldnt block the
things under it.)

Would all of this be worth the effort? I'm not quite sure; if the
drag-to-the-taskbar behavior is implemented, then I'm not sure
something like this would have a place, although it has two things
going for it: (1) As far as I know, no other desktop implements such a
feature, so it's kind of a flashy sort of a
hey-look-at-this-Gnome-rocks sort of thing; (2) it's more visual than
dragging things to a taskbar - it seem to fit the desktop metaphor
better than dragging things to the taskbar, because in reality the
papers on your desk are not anchored to anything.

If this doesn't make much sense and you're curious I could make a
mockup of what I mean; just email me.

Raising the window under the mouse pointer on the click of the second
mouse button or any other button is also a good solution, I think, but
less easily discoverable.

~Máirín