1141572 - Update tab tray animations to match UX mocks

Status: RESOLVED FIXED

(Firefox for iOS :: General, defect)

Description

[Aaron Train [:aaronmt]]

Attachment: screenshot.png

The animation we're using to open and close the tabs drawer are awful. After using the browser for some time over the weekend I simply can't stand the animations. 

 * It clips through the entire browser UI
 * It's disorientating and jarring
 * It's sluggish and slow (https://bugzilla.mozilla.org/show_bug.cgi?id=1135768)

Comment 1

[Nick Alexander :nalexander [he/him]]

I agree, and I would go further: the animation metaphor we use makes little sense.  If you tap the tap number, the "screen" -- including chrome UI -- collapses to a tab representation.  The title and favicon fade in, with the page blurred behind them [1].  If you then tap a *different* collapsed tab, the "screen" -- including the chrome UI, magically transported from the other location they collapsed to -- expands.  Except the chrome UI pops and jumps around.  The arrangement of surfaces doesn't make sense to me: there's only one chrome UI, it shouldn't be going to and coming in from different places.

[1] That pops like crazy for me, so I removed it when landing Bug 1135768.  I've filed Bug 1144908 to re-introduce it.

Comment 2

[Aaron Train [:aaronmt]]

Tried out a build w/1135768, yes, while the animation is better the layering and clipping problems still exist (as mentioned above).

Comment 3

[Darrin Henein [:darrin]]

I don't disagree – the currently implemented animation is far from ideal. That being said, I think there is still some work before we're close to what was spec'd out here: https://s3.amazonaws.com/f.cl.ly/items/0B3j252T1B1q0P3K3B20/tab-switch.gif

The chrome UI (url bar, etc) should remain with each tab, as if each has their own instance. You'll notice in the linked gif that the URL bar slides behind the thumbnail as well. One major difference is that in all the mockups/gifs, the background layer of the tab and tray is persistent, so the only thing animating is the tab itself.

If there are concerns with the intended animation (as in the gif), I'm happy to discuss those.

:nalexander, should we use this bug or file a new one to get the animation closer to the design?

Comment 4

[Wesley Johnston (:wesj)]

These types of inflamatory bug titles aren't really helpful.

We've talked this through quite a bit in meetings. Our current setup (a BrowserViewController controlling a TabsManager) requires that the BrowserViewController be behind the TabsManager during the transition. We use a fake screenshot of the tab to make it appear on top during the transition. We could try to fake it with the urlbar as well, but I'd rather just fix this (bug 1146423).

Comment 5

[Nick Alexander :nalexander [he/him]]

> :nalexander, should we use this bug or file a new one to get the animation
> closer to the design?

Let's use this one.

> If there are concerns with the intended animation (as in the gif), I'm happy
> to discuss those.

Concerns?  No -- but I'm confused because the ticket I landed (Bug 1135768) did not move us closer to the attached GIF.  That is, the collapsed tab representation has the title on top, etc, etc.  However, I'd very much like to see the chrome animation updated -- the tray and buttons moving out to the sides makes much more sense to me.

Comment 6

[Darrin Henein [:darrin]]

Sorry, ignore the visual design of the gif and focus solely on the animation. Bug 1146423 is probably relevant as well...

Let's get it as close to the design as possible and then we can evaluate the metaphor and visual relationships, etc.

Comment 7

[Wesley Johnston (:wesj)]

Darrin, can we close this? It seems like you've been doing other tweaks to this in follow ups?

Comment 8

[Darrin Henein [:darrin]]

Yep.