804270 - [Gaia::Homescreen] App Opening and Closing Transition Not Implemented According to Spec

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Gaia::System, defect, P3)

Description

[Peter La]

Please refer to page 6 of the following document:
https://www.dropbox.com/s/5xbazzqs8i9vnji/Transitions_v10.pdf

Comment 1

[Peter La]

Tested on: otoro_2012-10-22_ics_us.

Comment 2

[steve]

Needs correct transition implemented. See latest transition document for correct behaviour.

https://www.dropbox.com/sh/hcpn9opc593l7tx/7zqGtV_inH

Comment 3

[Arnau March [:arnau] ( not working in Firefox OS anymore :( )]

Cristian did some test to implement this transition as specified in the pdf, but due to hardware limitations the app and icons animations did not sync. So together with Victoria we decided to remove the icons animation until phone performance allow us to create a smooth animation.
Please refer to http://buildingfirefoxos.com/transitions/opening-and-closing-apps/ to see how this transition should be.
Thanks!

Comment 4

[Cristian Rodriguez (:crdlc)]

Furthermore, the problem is more complex due to the current architecture, the homescreen doesn't know when the open-app animation is performed, then, we cannot synchronize both. I gonna implement the open-app and close-app in system but not in homescreen.

Comment 5

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

Also you need to be very careful. I don't know how the spec has been decided but not all transition can be implemented right now if you don't want to slow down application startup time. Transforming on the Scale and changing the Opacity are OK but others probably won't go into the fast path that has been implemented in the platform.

Also switching between 2 different images will throw some expensive repaints (15ms each). 

Also can you define what should be shown if the application is not ready (cold launch) since the transition on http://buildingfirefoxos.com/transitions/opening-and-closing-apps/ seems to assume that the clock app is launched?

(I would like a better transition than the current one to be implemented but we need to be careful to not regress app launch performance).

Comment 6

[Cristian Rodriguez (:crdlc)]

the path is this

diff --git a/apps/system/style/system/system.css b/apps/system/style/system/syst
index 5d12c97..52622c8 100644
--- a/apps/system/style/system/system.css
+++ b/apps/system/style/system/system.css
@@ -268,11 +268,11 @@ body {
 
 #windows > .appWindow:not(.homescreen):not(.active):not(.inlineActivity):not(.o
   opacity: 0;
-  transform: scale(0.6);
+  transform: scale(0.1);
 }
 
 #windows > .appWindow.opening {
-  transition: transform 0.25s ease, opacity 0.15s ease;
+  transition: transform 0.5s ease, opacity 0.5s ease;
 }
 
 #windows.slow-transition > .appWindow.opening {
@@ -322,7 +322,7 @@ body {
 }
 
 #windows > .appWindow.closing {
-  transition: transform 0.25s ease, opacity 0.15s ease 0.1s;
+  transition: transform 0.5s ease, opacity 0.5s ease;
 }
 
 #windows.slow-transition > .appWindow.closing {

Comment 7

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

(In reply to Cristian Rodriguez (a tope!) from comment #6)
> the path is this
> 
> diff --git a/apps/system/style/system/system.css
> b/apps/system/style/system/syst
> index 5d12c97..52622c8 100644
> --- a/apps/system/style/system/system.css
> +++ b/apps/system/style/system/system.css
> @@ -268,11 +268,11 @@ body {
>  
>  #windows >
> .appWindow:not(.homescreen):not(.active):not(.inlineActivity):not(.o
>    opacity: 0;
> -  transform: scale(0.6);
> +  transform: scale(0.1);
>  }
>  
>  #windows > .appWindow.opening {
> -  transition: transform 0.25s ease, opacity 0.15s ease;
> +  transition: transform 0.5s ease, opacity 0.5s ease;
>  }
>  
>  #windows.slow-transition > .appWindow.opening {
> @@ -322,7 +322,7 @@ body {
>  }
>  
>  #windows > .appWindow.closing {
> -  transition: transform 0.25s ease, opacity 0.15s ease 0.1s;
> +  transition: transform 0.5s ease, opacity 0.5s ease;
>  }
>  
>  #windows.slow-transition > .appWindow.closing {

The way it is implemented also fire an extra repaint when the opacity transition ends. It will be better to implement that as an animation instead of a transition so both changes will ends at the same time and won't fire an extra repaint.

Comment 8

[Cristian Rodriguez (:crdlc)]

alright

Comment 9

[Cristian Rodriguez (:crdlc)]

Attachment: Patch v1

Based on animations and following the spec

Comment 10

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

Comment on attachment 733404 [details]
Patch v1

(In reply to Cristian Rodriguez (a tope!) from comment #9)
> Created attachment 733404 [details]
> Patch v1
> 
> Based on animations and following the spec

The current patch seems to regress performance by 100ms or so. Also why can't you try to apply the growing effect on the homescreen as well? The system app can animate that too.

Comment 11

[Cristian Rodriguez (:crdlc)]

Yes it was implemented 30 minutes ago, do you want to test again? thanks Vivien

Comment 12

[Cristian Rodriguez (:crdlc)]

Please Arnau check again my last changes ;)

Comment 13

[Arnau March [:arnau] ( not working in Firefox OS anymore :( )]

Cristian,
what you have done here is freaking awesome! Thanks for trying to push the boundaries.
Vivien, please consider this patch although it could slow down apps loading time, as a UX improvement. This is the kind of small things that makes users perceive the phone as good product.

Comment 14

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

(In reply to arnau from comment #13)
> Cristian,
> what you have done here is freaking awesome! Thanks for trying to push the
> boundaries.
> Vivien, please consider this patch although it could slow down apps loading
> time, as a UX improvement. This is the kind of small things that makes users
> perceive the phone as good product.

Arnau,
I want both world. UX improvment as well as app startup time. While we're looking for a solution to this can you describe what should happens on a cold launch? Actually we are showing a screenshot of the application but I start to believe that there is no right way to take a screenshot... Does your UX will be fine with a static images taken from somewhere? (maybe the manifest)

Comment 15

[Arnau March [:arnau] ( not working in Firefox OS anymore :( )]

We all want both things ;)
I have been talking to Victoria, the visual team will need to agree on a initial generic screen, but by now it's ok if you use the dark screen with the rocket engraved.

Comment 16

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

(In reply to arnau from comment #15)
> We all want both things ;)
> I have been talking to Victoria, the visual team will need to agree on a
> initial generic screen, but by now it's ok if you use the dark screen with
> the rocket engraved.

I don't think a single generic screen if fine. I was mostly thinking about a screen per app for cold start.

Christian, it seems like the implem has a bug if you hit the home button during the app opening transition.

Comment 17

[Victoria Gerchinhoren [:vicky]]

hi Vivien et all,

The generic grey screen with the rocket seems fine to me since this animation takes place when opening from the homescreen that is already a dark screen the transition will look smooth. 

That screen should be used only the first time it opens, and after that (when it's revealed, because it's still in the task list), it will open with the last screen captured, right?

I say we go with the rocket screen for that particular case of opening for the first time, and we think better of a screen that can fit better for each app.

Thanks Cristian for doing this! Great job!

Comment 18

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

Right now the new animation slow down app start up time by ~140ms. The main parameter that seems to affects it is the duration of the opening transition: 0.5s.

Can we make it shorter and keep a good effect?

Comment 19

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

(In reply to Victoria Gerchinhoren from comment #17)
> hi Vivien et all,
> 
> The generic grey screen with the rocket seems fine to me since this
> animation takes place when opening from the homescreen that is already a
> dark screen the transition will look smooth. 
> 
> That screen should be used only the first time it opens, and after that
> (when it's revealed, because it's still in the task list), it will open with
> the last screen captured, right?
> 
> I say we go with the rocket screen for that particular case of opening for
> the first time, and we think better of a screen that can fit better for each
> app.
> 
> Thanks Cristian for doing this! Great job!

Hi Victoria,

for me there are 3 times of screenshots:
 - first time ever launch: The rocket launcher is shown.
 - cold launch. the app has been killed or closed for any reasons. Currently we are showing a screenshot that is taken right after the application has been launched - this screenshot is often wrong and if the application and sometimes contains outdated data (for sms for example). It looks really bad and that's the one i want to fix.
 - hot launch. the app is already opened and so the last screen the user was on is displayed.

Comment 20

[Cristian Rodriguez (:crdlc)]

> Christian, it seems like the implem has a bug if you hit the home button during the app opening transition.

Sure, I am going to reproduce the bug. Thanks

> Right now the new animation slow down app start up time by ~140ms. The main parameter that seems to affects it is the duration of the opening transition: 0.5s

You are right, the current animation takes .5 seconds instead of .25 seconds. I try to set other values to compare the app start up time. IMHO now the animation should go better because we are using an animation instead of a couple of transitions, isn't?

Comment 21

[Cristian Rodriguez (:crdlc)]

Thanks for spotting Vivien! I've solved the bug when clicking on home button while the animation. I've reduced the animation time from .5 to .3 seconds. Could you check the app start up time again? Thanks a lot

Comment 22

[Cristian Rodriguez (:crdlc)]

Good morning Arnau, I've changed the animation time from 0.5s to 0.3s in order to check the app time start up, ok? If Vivien says that this time is good for solving this issue, I would like you test again the implementation to know if you are comfortable with this new duration. Thanks

Comment 23

[Arnau March [:arnau] ( not working in Firefox OS anymore :( )]

Ok to change the animation to 0.3s.

Comment 24

[Victoria Gerchinhoren [:vicky]]

(In reply to Vivien Nicolas (:vingtetun) (:21) from comment #19)
> (In reply to Victoria Gerchinhoren from comment #17)
> > hi Vivien et all,
> > 
> > The generic grey screen with the rocket seems fine to me since this
> > animation takes place when opening from the homescreen that is already a
> > dark screen the transition will look smooth. 
> > 
> > That screen should be used only the first time it opens, and after that
> > (when it's revealed, because it's still in the task list), it will open with
> > the last screen captured, right?
> > 
> > I say we go with the rocket screen for that particular case of opening for
> > the first time, and we think better of a screen that can fit better for each
> > app.
> > 
> > Thanks Cristian for doing this! Great job!
> 
> Hi Victoria,
> 
> for me there are 3 times of screenshots:
>  - first time ever launch: The rocket launcher is shown.
>  - cold launch. the app has been killed or closed for any reasons. Currently
> we are showing a screenshot that is taken right after the application has
> been launched - this screenshot is often wrong and if the application and
> sometimes contains outdated data (for sms for example). It looks really bad
> and that's the one i want to fix.
>  - hot launch. the app is already opened and so the last screen the user was
> on is displayed.

Hi Vivien, thanks for the clarification here! So, how do you suggest to solve this "cold launch" situation?
Thanks!

Comment 25

[Victoria Gerchinhoren [:vicky]]

bTW the animation in .3s looks great!

Comment 26

[Cristian Rodriguez (:crdlc)]

IMHO I agree with Vivien but I guess that how to support the cold launch is out of this bug. Could be that a follow up or another different bug? We should land this one if there is not regression with the current patch in order to test the new transition on master. Please Vivien, do you see something wrong? Thanks a lot

Comment 27

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

Comment on attachment 733404 [details]
Patch v1

Without opacity and with a shorter time the performance seems acceptable. Let's see how it will looks on datazilla.

Comment 28

[Cristian Rodriguez (:crdlc)]

https://github.com/mozilla-b2g/gaia/commit/47e0639ae27fae16595d06cc6682f897fc815170

Comment 31

[jachen]

Hi Cristian-
I would like to ask you to raise the "approval?" flag and fill out the user value and risk profile. 

Then we can also raise the nomination flag to go to triage. I did email Vicki and Maria regarding this already.

Thanks!
Jaime

Comment 32

[Cristian Rodriguez (:crdlc)]

Comment on attachment 733404 [details]
Patch v1

NOTE: Please see https://wiki.mozilla.org/Release_Management/B2G_Landing to better understand the B2G approval process and landings.

[Approval Request Comment]
Bug caused by (feature/regressing bug #): 
User impact if declined: high, animations are very important to perceive a good product
Testing completed: yes
Risk to taking this patch (and alternatives if risky): low although not simple change
String or UUID changes made by this patch:

IMPORTANT: This bug 866643 should be landed at the same time when is merged

Comment 33

[Lukas Blakk [:lsblakk] use ?needinfo]

(In reply to Cristian Rodriguez de la Cruz (:crdlc) from comment #32)

> IMPORTANT: This bug 866643 should be landed at the same time when is merged

Waiting for review on that bug, holding off on approval until we know the two are on master without fallout.

Comment 34

[Chris Lord [:cwiiis]]

If the primary reason for uplifting this is user perception, I think this should also be blocked by bug 847241, which completes the experience. Otherwise, switch-to-app transitions always display the home-screen first instead of transitioning straight from the cards view.

I filed bug 868076 for this, but that could just as easily be tracked here.

Comment 35

[Alex Keybl [:akeybl]]

Comment on attachment 733404 [details]
Patch v1

Please renominate when blocking bugs are resolved.

Comment 36

[KM Lee [:rexboy] (inactivate after Sep. 22)]

This bug is required for uplifting bug 840147.
Since the blocker bug 866643 has gone, may we renominate it?

Comment 37

[Cristian Rodriguez (:crdlc)]

This bug 866643 was closed as worksforme because was fixed by bug 866174 which is not on v1-train