Firefox OS, Animations & the Dark Cubic-Bezier of the Soul

I’ve been using Firefox OS daily for a couple of years now (wow, time flies!). While performance has steadily improved with efforts like Project Silk, I’ve often noticed delays in the user interface. I assumed the delays were because the hardware was well below the “flagship” hardware I’ve become accustomed to with Android and iOS devices.

Last year, I built Firefox OS for a Nexus 4 and started using that as my daily phone. Quickly I realized that even with better hardware, I sometimes had to wait on Firefox OS for basic interactions, even when the task wasn’t computationally intensive. I moved on to a Nexus 5 and then a Sony Z3 Compact, both with better specs than the Nexus 4, and experienced the same thing.

Time passed. Frustration grew. Whispers of a nameless fear…

Running the numbers

While reading Ralph Thomas’s post about creating animations based on physical models, I wondered about the implementation of animations in Firefox OS, and how that might be involved in this problem. I performed an audit of the number of instances of different animations, grouped by their duration. I removed progress indicators and things like the boot shutdown animation. Here are the animation and transition durations in Firefox OS, grouped by duration, for transitional interactions like scaling, opening, closing and sliding:

  • 0.1s: 15
  • 0.2s: 57
  • 0.3s: 79
  • 0.4s: 40
  • 0.5s: 78
  • 0.6s: 8

A couple of things stand out. First, we have a pretty wide distribution of animation durations. Second, the vast majority of the animations are more than 300ms long!

In fact, in more than 80 animations we are making the user wait more than half a second. These slow animations are dragging us down, resulting in a poorer overall experience of Firefox OS.

How did we get here?

The Firefox OS UX and interaction designers didn’t huddle in a room and design each interaction to be intentionally slow. The engineers who implemented these animations didn’t ever think to themselves “this feels really responsive… let’s make it slower!”

My theory is that interactions like these don’t feel slow while you’re designing and implementing them, because you’re working with a single interaction at a time. When designing and developing an animation, I look for fluidity of motion, the aesthetics of that single action and how the visual impact enhances the task at hand, and then I iterate on duration and effects until it feels right.

We do have guidelines for responsiveness and user-perceived performance in Firefox OS, written up by Gordon Brander, which you can see in the screenshot below. (Click the image for a larger, more readable version.) However, those guidelines don’t cover the sub-second period between the initial perception of cause and effect and the next actionable state of the user interface.

Screenshot 2015-04-18 09.38.10

Users have an entirely different experience than we do as developers and designers. Users make their way through our animations while hurriedly sending a text message, trying to capture that perfect moment on camera, entering their username and password, or arduously uploading a bunch of images one at a time. People are trying to get from point A to point B. They want to complete a task… well, actually not just one: Smartphone users are trying to complete 221 tasks every day, according to a study in the UK last October by Tecmark. All those animations add up! I assert that the aggregate of those 203 animations in Gaia that are 300ms and longer contributes to the frustrating feeling of slowness I was experiencing before digging into this.

Making it feel fast

So I tested this theory, by changing all animation durations in Gaia to 200ms, as a starting point. The result? Firefox OS feels far more responsive. Moving through tasks and navigating around the OS felt quick but not abrupt. The camera snaps to readiness. Texting feels so much more fluid and snappy. Apps pop up, instead of slowly hauling their creaky bones out of bed. The Rocketbar gets closer to living up to its name (though I still think the keyboard should animate up while the bar becomes active).

Here’s a demo of some of our animations side by side, before and after this patch:

There are a couple of things we can do about this in Gaia:

  1. I filed a bug to get this change landed in Gaia. The 200ms duration is a first stab at this until we can do further testing. Better to err on the snappy side instead of the sluggish side. We’ve got the thumbs-up from most of the 16 developers who had to review the changes, and are now working with the UX team to sign off before it can land. Kevin Grandon helped by adding a CSS variable that we can use across all of Gaia, which will make it easier to implement these types of changes OS-wide in the future as we learn more.
  2. I’m working with the Firefox OS UX team to define global and consistent best-practices for animations. These guidelines will not be correct 100% of the time, but can be a starting point when implementing new animations, ensuring that the defaults are based on research and experience.
If you are a Firefox OS user, report bugs if you experience anything that feels slow. By reporting a bug, you can make change happen and help improve the user experience for everyone on Firefox OS.

If you are a developer or designer, what are your animation best-practices? What user feedback have you received on the animations in your Web projects? Let us know in the comments below!


  1. jorrete

    Thanks for the article!

    As a Flame user, I find the UI vibrations interactions, like keyboard pushes, very long. The keon, a more modest device, feels more responsive while keyboard vibration is active, I think just because is shorter.
    The home hardware button also feels slow invoking the task manager.

    Waiting to try those changes!!!

    April 27th, 2015 at 08:00

  2. André

    Same for me on my Nexus 4. The vibration is too long after pressing a key on the keyboard. On android it “feels” much better. More than a “snap” and less like a “vibrate”.

    April 27th, 2015 at 22:22

    1. Dietrich Ayala

      Thanks André! That’s a good catch in an area I didn’t look at. Can you file a bug for that?

      April 27th, 2015 at 22:23

      1. André

        Thanks! I opened a ticket for it:

        April 29th, 2015 at 09:36


          Awesome, thanks!

          April 29th, 2015 at 11:36

  3. mac

    Well, the problem is not only with overall performance (in context of responsivness) but also with keyboard performance. I can say that the keyboard one is even bigger. There is bug about it with video link that shows difference between 2.0 and higher version of b2g. Just take a look: . Problem is also with animations during message receiving or call in progress:

    April 28th, 2015 at 00:54


      Thanks Mac! Yeah there is a lot more to do than just this patch. Hopefully this patch will make those other performance issues yet more apparent, so we can fix them sooner.

      April 28th, 2015 at 12:37

  4. alex_mayorga

    ¡Hola Dietrich!

    Where are those Nexus and Sony builds available?


    April 29th, 2015 at 06:14


      I built them myself, following the instructions on MDN:

      Unfortunately Mozilla doesn’t have the license to redistribute the binaries that are on these devices (radio libraries, etc), so cannot provide builds.

      April 29th, 2015 at 08:09

    2. André

      Firefox OS 3.0 builds for Nexus 4 are available from here:

      April 29th, 2015 at 09:25

  5. Aleksandar Blagotić

    Speaking of UX, you could add lightbox-like behaviour on post images ;)

    April 29th, 2015 at 13:53


      Good idea. We’re rebuilding the WP theme for Hacks, so I’ll put that on the list :)

      April 29th, 2015 at 13:54

Comments are closed for this article.