Firefox/Projects/Animation priorities

Summary

The purpose of this sprint is to design and develop three key areas that we feel Firefox would benefit from animation:

1. Tab tearoff
2. Text search on page
3. Movement of toolbar items within rows (UI elements, bookmarks, tabs)

Introduction

Animation in the browser is a tool, but not a goal unto itself. Wherever animation is used, it should be with a definite and purpose and benefit to the user.

Like many web technologies, animation is a useful but easily abused tool. The early web and the dawn of the .gif format saw animation heinously overused websites, with blinking, spinning, and scrolling animations thrown in because they "looked cool." As the web stopped foaming at the mouth and begin the transition to what could be done to what should be done, animation became used more successfully as a tool. Some ways in which animation can be useful include:

• Making browsing feel faster
• Adding visual affordances to makes tasks more understandable
• Making the browser and tasks more visually appealing

To bring animation to Firefox, we decided to first focus on three key areas that we felt would give users the most benefit by adding animation. Out of many possibilities, we looked for places where animation would make interactions feel faster and help users perform tasks.

Status

Phase 1 (first two weeks, ending August 15):

• Competitive analysis of animation in browsers/software
• Brainstorming areas for animation, narrowing down the possibilities down to three areas for focus
• Sketching & making mockups of the three areas of focus

Phase 2 (second two weeks, ending August 28)

• Talk to Neil Deakin and roc (who is on vacation until 8/24, and will then be in Mountain View for platform week)
• Iterating on mockups and sketches
• Getting feedback from the community (including blogging, forums)
• Planning implementation, finding developers interested
• (possibly) Creating quick iterations with interested developers

Near Term Goals

• Add tangible benefit to Firefox's user experience by exploring, developing, and implementing browser animation (starting with three)

Longer Term Goals

• Explore the overall place animation has in the browser:
  • What do different kinds of movement relate, and which should be related by Firefox?
  • How does animation change the speed and personality of a browser?
  • How can we implement animation with minimum performance costs?

Tab tearoff

Summary

Currently, tearing off tabs is functional... but that's it. There's little affordance to tell the user what is going on - if they've grabbed a tab, where it's targetted, and what will happen when they let go.

All of the browsers more or less treat tabs as real world objects. We describe them with real-world metaphors, like "dragging" and "tearing." And, we manipulate them like real-world objects we can, by rearranging and moving them. Thus, animation could help to reinforce this real-world metaphor while providing a visual affordance for how the tab is being manipulated.

Text search on page

Summary

Currently, finding text on a page in Firefox can be challenging. The text is highlighted as the user types matching input, but this slow color change can be difficult to detect - especially when the highlight is similar to the background color. A subtle animation as the user types input could direct the user's attention to the word they are trying to find.

Movement of toolbar items within rows (UI elements, bookmarks, tabs)

Summary

Currently, items in the toolbars can be added, removed, and rearranged. By giving these items some slight animation, not only may Firefox feel more lightweight and adaptable, but it will be more visually clear what the user is manipulating and how the browser will be changed by letting go. For instance, animations of tabs being arranged is essentially live preview of tab rearrangement: if a tab is slid to the right and an animation shows it doing so, releasing it only makes permanent what is being shown. This is in contrast to the current system, where a small marker shows where a tab will be dropped but not what the arrangement will look like once is in that slot. Other rows give no feedback at all: not even a bar. The customize toolbar window, for instance, does not give an indication of what will happen when a UI element is added to the toolbar.

Design

Mockups

-movement pic-