unity-design team mailing list archive

[David Prieto <frandavid100@xxxxxxxxx>]

Christian, thanks for your reply:

Hi David, can you state a precise use case when this would be useful?
>

   - For minimizing a window from the launcher. Right now you can restore
   them but not minimize them, so the process lacks symmetry. Of course you can
   minimize it from the titlebar buttons, but users are used to being able to
   minimize windows from the task list so that's a choice you're taking from
   them.
   - For going straight from an app to a specific window from another app,
   without having to (first) go through that app's most recent window, (second)
   open expose and (third) choosing the desired window. Currently the result is
   the same (you get to the window you wanted) but it forces you through more
   steps and, visually, can get more tiresome (windows zooming in and out every
   time you want to reach one of them).
   - For keeping track of an app's open windows while you're working on
   another, without having to lose focus. Also for minimizing / closing an
   inactive app without having to focus it (e.g. if you want it to remain
   hidden because the boss is coming).
   - For opening a new window straight from the launcher. You can do it with
   the first window, so why not with a second one?
   - For dragging contents from a window to another. For example, you want
   to drag a file from Nautilus window A to Nautilus window B, but B is hidden
   behind other windows. You would be able to drag the file to the Nautilus
   launcher icon, then to window B (which would be brought to the front) and
   then drop the file. The task list has this functionality, so that's yet
   another thing that Unity is taking from the user.

All in all, it's a handier way to keep a track of windows, switch windows
and perform operations on windows. The user can do all those things now, one
way or the other (even the one about opening an additional window, because
it can be done from the window's file menu, and the drag-and-drop because
you can bring the window to the front in advance); but the process is always
longer and more confusing that it would if my proposal were implemented.

Personally I think that showing the windows on mouse over is a bit heavy (on
> your mock-up the application name is also missing). Being based on over
> makes it not much touch friendly as well. I wonder if this problem can be
> sorted differently.


The same problem exists with the current implementation, because how do you
check the name for a launcher icon on touch screens? But it could be easily
solved by implementing a second way to launching it: by keeping the launcher
icon pressed for a moment, without dragging it in any direction.

   - If you hover the mouse over the launcher, the window spread appears but
   if you move the mouse away it disappears.
   - If you press the launcher for a while it also appears, but doesn't
   disappear until you click somewhere else out of the spread.

Consider that a user without a touch screen wouldn't even notice that the
second method exists, since the spread would be there as soon as he hovered
his cursor over the icon, without having to keep it pressed.


> For instance, as it is today, you can easily get to windows expose clicking
> on the focused application. Why do you think this wouldn't be enough?
>

Not really, for the reasons above.