[Usability]Persistence and continuity animations

[Gregory Merchan <merchan phys lsu edu>]

In order to provide the illusion of persistence and a sense of continuity
there should be an animation when a window is presented or hidden.

Everyone should be familiar with minimise/restore animations, so I'll skip
those.

When opening a file from a folder, the animation should run from the file
icon to the window to view the file. When the window is closed, there should
be an animation from the window back to the file icon. If an icon is not
visible, then the icon of its parent folder is used.

Example:
The Home icon sits on the desktop. When it is opened the animation connects
the icon to the folder window which opens. Suppose that there is a folder
called Mail in the Home folder. Again, when that is opened the animation
connects the icon to the folder window. Now the user closes the Home folder.
The animation connects the Home folder window to its icon. Lastly the user
closes the Mail folder. Because its icon is no longer visible, the animation
connects the Mail folder window to the next visible icon in the folder
hierarchy, the Home icon.


When opening a window from a menu - e.g., an app from a global app menu or
a dialog from File->Save As... - the opening animation runs from the
menu item to the window. If the menu item is no longer visible, the
animation runs from the parent menu item and so forth. When the window is
closed, the animation runs back to the menu item if it is visible (unlikely),
or to its parent menu item.

Global app menu example:
The user opens the Applications menu and selects the Web Browser. Because
the web browser takes some time to open, the Applications menu has already
closed. When the window is finally presented, the animation runs from
the Applications menubar item to the window. When the Web Browser is closed,
the animation runs back to the Applications menubar item.

Save As... dialog example:
The user opens the File menu and selects Save As.... This window appears
speedily, so the File menu will not have closed. The animation runs from
the Save As... menu item to the dialog window. Because when the Save As...
dialog is closed the File menu is also closed, the closing animation runs
from the dialog window to the File menu bar item.


In the event that the animation destination is a minimized window, the
task bar representation will become the destination.


Here are some options for the appearance of the animation:
 Windows style - a moving resizing title bar.
 Metacity style - a moving resizing black square.
 XOR square - like metacity style, but the color is "opposite" the
              underlying color.
 XOR lines - Lines connect the corners of one representation to the
             corresponding corners of the other.

There are surely others, like Apple's "genie" effect. But the four I've
listed seem speediest and least obtrusive.

How to make it work? The window manager knows and determines where windows
will appear, so it's the best candidate for doing the animation. Except
for minimize/restore there is no specification for animations sources
and destinations. The end-points may move from one app to another.
The time for an app to show a window may also be long; if the window manager
could know where the window should open, it could run the open animation 
immediately and leave a window frame with a message like "Loading Foo..."
until Foo actually maps the window to be framed.


That's a basic description of the interface. There are interface and
implementation details which remain.

If you disvalue animations more than you value persistence and continuity,
then you do not want this. Please just ask that there be a way to turn
animations off rather than interfering with those who may try to make this
work. Understand also that some aspects of developing this may benefit you
in some other way, even if there are no animations.


Cheers,
Greg Merchan