Effects and animations

Visual effects including animations, and subtle sound effects, can improve the Gnome experience in two ways. First, they help explain where objects have come from and where they have gone to -- windows, icons, list items, menus and so on. This helps non-technical users understand the behavior of those objects. Second, effects make the interface as a whole look more detailed and deliberately designed, increasing everyone's trust in the system.

Qualities of effects

For both visual and sound effects, there are three main qualities to consider.

Length: Long enough to be noticable, but short enough that people don't feel they are waiting for it. (Most of the effects discussed here would be in the range of 0.25~0.5 seconds.)

Prominence: Prominent enough to be noticable, but subtle enough that it doesn't look or sound clumsy.

Realism: Looking and sounding like physical objects, without having their annoying physical limitations. For example, sound effects need to include slight variations, otherwise repeated actions will soon sound unrealistic and grating.


  • Toolbars could slide in and out from the nearest edge of the window.
  • When an item is added to a list, the following items could slide down to make room.
  • When a group of things is being rearranged manually -- for example, a TreeView list, bookmarks or buttons in a toolbar, or tabs in a tabbed window -- items could slide out of the way to make room for the one(s) you're dragging.

  • For dragging and dropping in general, the item being dragged could:
    • be translucent and shrunk if necessary, so as not to obscure the drag target
    • rotate based on the drag speed and direction, to show its inertia as it is dragged by the pointer
    • have a small shadow, so as to appear above everything else during dragging, and so as to visibly fall when dropped
    • make a small gripping noise when picked up
    • make a small thud noise when dropped.
  • The checkmark in a checkbox could visibly be drawn when checked, and erased when unchecked.
  • The dot in a selected radio button could visibly fly from the previously-selected one to the newly-selected one.
  • When a progress bar jumps from one value to another, GTK could smooth out the transition over the course of about half a second.


  • Sidebars could slide in and out from the edge of the window. sidebar.swf

  • Applications that switch between overviews and detailed views of objects could zoom between them. For example in F-Spot, the photo roll should zoom in to the individual photo you want to view or edit. And in Evolution's calendar, days in the month view should zoom to the same days in the week or day view.
  • Similarly, in different views of the same collection of objects, the objects could animate between their respective positions. For example in Nautilus, when switching from icon view to list view, the icons and filenames could fly from their icon-view positions to their list-view positions, as the rest of the list-view information fades in.

Window manager

  • The window manager could, and does, use animation to show what happens when a window is minimized or maximized.
  • An animated graphical window switcher (such as the zooming window switcher) can help reduce complexity by showing the one-to-one relationship between normal-sized windows and windows in the switcher.

  • With application support, the window manager can show the origin of each window, by zooming it out from that point when it is opened and back into that point when it is closed. For example, a folder window can zoom out from (and back into) its parent folder (or the nearest ancestor folder that is visible). Similarly, a dialog could zoom out from (and back into) the menu from which it was invoked.
  • A window could temporarily fade out if you hold down the mouse button on its title bar, so that you can quickly refer to information underneath it.
  • A workspace switcher should animate the movement from one workspace to another, to explain why the current set of windows has disappeared (and possibly been replaced by a new set).


  • The panel could, and does, use animation for feedback when an application is launching.
  • A slow application's first window could unroll as the application launches (perhaps with the title bar replacing the splash screen).

Sound effects in general

Sound effects could have spatial realism, louder from the left speaker for something happening at the left side of the screen. They should also perhaps be themeable.

There are positive sounds, which happen when something succeeds. Examples in hardware include the clicking noises that are engineered into keyboards, mice, and touchpads. Examples in software include the sound made when a CD has finished burning.

There are negative sounds, which happen when something fails. The archetypical example is the beep or ding when an alert appears. This association is probably why many people are uncomfortable with software-based sound effects in general.


  • Fading in or out should be the last resort if there is no more realistic visual transition, in the same way as beeping should be the last resort if there is no more realistic sound effect.

Yet to be categorized...

  • Urgency bit / Notification
    • Levels of urgency
  • Draggable / Expandable scrollbars
  • Model after physical interaction




Events/Summit/2008/GUIHackfest/EffectsAndAnimations (last edited 2013-11-25 17:49:13 by WilliamJonMcCann)