[Tarako] Creating a good loading experience for home screen app

RESOLVED FIXED

Status

defect
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: timdream, Assigned: dwi2)

Tracking

unspecified
x86
macOS

Firefox Tracking Flags

(blocking-b2g:1.3T+, b2g-v1.3T fixed)

Details

(Whiteboard: [sprd295070][partner-blocker][tarako_only])

Attachments

(4 attachments)

For low-end devices like Tarako, we will always ended up killing the home screen when the user switch to anything else. The re-launch looks very "webby" right now with visible reflow multiple times.

We want to get rid of that and make the experience great.

This doesn't necessary need to be addressed in 1.3T schedule (PM/TAM will make the call).
Flags: needinfo?(styang)
blocking-b2g: --- → 1.3T?
Hi Mike,
Can you update your thoughts here? Thanks
Flags: needinfo?(mtsai)
Let's try some approaches and test how them actually feels and compare with current situation.
After press home key: 
1.Current elements appearing sequence, but remove motion for search field, just make it appear at right  
  location, same to first row collection icons. So no more move down motion for both.
2.Show all icons first -> Show Docking and Search Field TOGETHER
  ( Same Search Field and first row collection icons motion change like 1. ) 
3.Use the application page (on the right side of e.me page) as default home page.
  Because since there is no Search Field, which means one less element to load after press home key,
  and this gives less waiting time than current one. 
  From UX's pov, the second page (on the right side if e.me page ) maybe more useful for users. 
  It's the   main gate for applications. Searching function is useful but not necessary to be 
  set to default homepage.As long as it's easy to access as secondary page should be fine. 

Tks.
Flags: needinfo?(mtsai)
George, Tzu-lin, would you mind document the finding here so that triage team can make a blocking decision?
Flags: needinfo?(tzhuang)
Flags: needinfo?(gduan)
As discussed with Peter (System FE) PM, and we made consensus that to adjust Tarako Home screen to stop at Apps screen instead of e.ME page. please proceed this changes.
Summary: Creating a good loading experience for home screen app → [Tarako] Creating a good loading experience for home screen app
Hi all,

I made of video of my WIP. This WIP does two things:
1. Preload searchbar at the time of homescreen loading
2. Make collection icons placed at right place at the first time

WIP is here https://github.com/dwi2/gaia/compare/mozilla-b2g:v1.3t...nojitter_hs_v1.3t?expand=1

I'll keep trying if I could make loading time of icon faster
Flags: needinfo?(tzhuang)
(In reply to Tzu-Lin Huang [:dwi2][:tzhuang] from comment #5)
> Created attachment 8412341 [details]
> preload_searchbar.MOV
> 
> Hi all,
> 
> I made of video of my WIP. This WIP does two things:
> 1. Preload searchbar at the time of homescreen loading
> 2. Make collection icons placed at right place at the first time
> 
> WIP is here
> https://github.com/dwi2/gaia/compare/mozilla-b2g:v1.3t...nojitter_hs_v1.
> 3t?expand=1
> 
> I'll keep trying if I could make loading time of icon faster

Hi Mike, can you check the video and comment what you think? If it's good enough, I think we can just take this approach. Thanks
Flags: needinfo?(mtsai)
(In reply to George Duan [:gduan] [:喬智] from comment #7)
> Created attachment 8412379 [details]
> VID_20140425_141147.mp4
> 
> 
> Default to app page instead of everythingme.
> https://github.com/cctuan/gaia/commit/
> bbd6fa92a8a319463b52dfa229a02d931408d4e0

Mike, please also evaluate this too.
Loop in UX homescreen team for more input. Thank you, Gordon, Maria and Peter.
Flags: needinfo?(pla)
Flags: needinfo?(msandberg)
Flags: needinfo?(gbrander)
Flags: needinfo?(mtsai)
traige: we will take either of the solution, depending on UX decision. thanks 1.3T+
blocking-b2g: 1.3T? → 1.3T+
Duplicate of this bug: 996531
Whiteboard: [sprd295070]
Temporary assign to George (I cannot assign both of them on Bugzilla at the same time).

Switched to ASSIGNED since George have worked on it.
Status: NEW → ASSIGNED
Adding Jacqueline for 2.0 home screen and because Maria has been away. Jacqueline please review and provide feedback. Thanks!
Flags: needinfo?(jsavory)
Currently, I agree that the feeling of the transition is a bit too choppy and that this bug should be 1.3T+

I think we could improve the homescreen transition for low-end devices by adding some minor animation and 
I can work with the current homescreen visual designer to create a proposal that should work for this situation.
Flags: needinfo?(jsavory)
If I understand comment 12 correctly, George is taking care of this.
Assignee: nobody → gduan
(In reply to Gregor Wagner [:gwagner] from comment #15)
> If I understand comment 12 correctly, George is taking care of this.

Yes.

(In reply to jsavory from comment #14)
> Currently, I agree that the feeling of the transition is a bit too choppy
> and that this bug should be 1.3T+
> 
> I think we could improve the homescreen transition for low-end devices by
> adding some minor animation and 
> I can work with the current homescreen visual designer to create a proposal
> that should work for this situation.

We don't need a proposal, we need a evaluation and green light on either proposal on the comments above.
Flags: needinfo?(jsavory)
Whiteboard: [sprd295070] → [sprd295070][partner-blocker]
You are amazing for including videos!

How realistic would it be to fade in the homescreen content w/ CSS? Layout would happen while `opacity: 0;`. This could make the transition feel intentional and might help lessen the feeling of jank.
Flags: needinfo?(gbrander)
George, is the above idea doable?
Flags: needinfo?(gduan)
Hi Gordon,

homescreen content? you mean all the icons including page's and dock's or only page's ? does that include search bar of eveme?
In original design, we load icons from db by below order: dock -> eveme -> apps.

So, if we want all icons fade-in together, that would be absolutely slower than before, since it would have to wait til all icons are ready.
If we want eveme or apps fade-in only, we'll still see the icons in dock bar show first, and then see other icons fade in.

Is that what you expect?
Flags: needinfo?(gduan)
Flags: needinfo?(gbrander)
Posted video IMG_1752.m4v
Pelase see attachment : IMG_1752.m4v (1.32 MB, video/x-m4v) 
We compare new implementation by Tzu-Lin and George in the same test environment. The e.me as home page (right one) one loads more smoother than the left one. Especially the step of loading the main shortcuts (shortcuts outside docking). In this case, the performance quality feeling is really about smoothness and speed users percepts. So the right one is a better solution here.
(In reply to GoodMike from comment #21)
> Pelase see attachment : IMG_1752.m4v (1.32 MB, video/x-m4v) 
> We compare new implementation by Tzu-Lin and George in the same test
> environment. The e.me as home page (right one) one loads more smoother than
> the left one. Especially the step of loading the main shortcuts (shortcuts
> outside docking). In this case, the performance quality feeling is really
> about smoothness and speed users percepts. So the right one is a better
> solution here.

Hi Tzu-lin,
would you mind to take this bug and provide a pr as comment 5?
Flags: needinfo?(tzhuang)
Duplicate of this bug: 995597
Assignee: gduan → tzhuang
Flags: needinfo?(tzhuang)
Hi Cristian,

Could you help to review the patch for v1.3t? 
I made two adjustment in Homescreen: 
1. Preload searchbar at the time of homescreen loading
2. Make collection icons placed at right place at the first time (by adding another css class .firstPage

Thanks
Attachment #8417163 - Flags: review?(crdlc)
Time log shows that HomeState.getGrid and appMgr.getAll consume too much time. The former is caused by the low performance of indexedDB, and the later is caused by complicated webapi call. 

The two functions consume nearly 2 seconds (even over 2 seconds sometimes).

We should work on this.
Comment on attachment 8417163 [details] [review]
pull request against v1.3t

Hi,

   I've just written some comments on Github about avoiding to couple ev.me and homescreen. Please request to me again for a review when those comments will be addressed. And please, ask for a review to Ran from Ev.me as well because we are touching code in both worlds.

Thanks a lot and good job mate
Attachment #8417163 - Flags: review?(crdlc)
Comment on attachment 8417163 [details] [review]
pull request against v1.3t

Hi Cristian,

Comments addressed. In order to cleanly separate Ev.me and homescreen, I move initiation of evme-activation-icon back to everything.me.js and wrap it in preInit(). Homescreen could still preload evme-activation-icon without too much coupling.

Hi Ran,
Could you kindly help to review the Ev.me part? Thanks
Attachment #8417163 - Flags: review?(ran)
Attachment #8417163 - Flags: review?(crdlc)
Comment on attachment 8417163 [details] [review]
pull request against v1.3t

It looks better, some comment more in github, ask again please, because sometimes I don't read github comments without pending reviews, thanks a lot for your great work
Attachment #8417163 - Flags: review?(crdlc)
Attachment #8417163 - Flags: review?(crdlc)
Comment on attachment 8417163 [details] [review]
pull request against v1.3t

For me is ok!, great job mate! 10x
Attachment #8417163 - Flags: review?(crdlc) → review+
Please land this patch on v1.3t before 5.10.
Ying, are you ok to land the patch? thanks.
Flags: needinfo?(styang) → needinfo?(ying.xu)
(In reply to Steven Yang [:styang] from comment #31)
> Ying, are you ok to land the patch? thanks.

I was told we are waiting for feedback from e.me.
(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from comment #33)
> (In reply to Steven Yang [:styang] from comment #31)
> > Ying, are you ok to land the patch? thanks.
> 
> I was told we are waiting for feedback from e.me.

oh, yes. sorry for that. let' keep this open till e.me confirm back.
Thank you for tarako only workaround.
Let's wait for e.me.
(In reply to James Zhang from comment #35)
> Thank you for tarako only workaround.
> Let's wait for e.me.

I don't see a backout commit. Please keep the Bugzilla status and tree status in-sync even if an operation was done by mistake.

We can backout IF e.me have problem with this, I think.
In my meeting with you guys last time, I heard there is no issue from e.me. no ?
Amir Nissim from e.me wrote a few comments on GH
Attachment #8417163 - Flags: review?(ran) → review?(amirn)
Comment on attachment 8417163 [details] [review]
pull request against v1.3t

minor comments on Github.
r+ since the patch already landed and is for 1.3t only
Attachment #8417163 - Flags: review?(amirn) → review+
this has been r+ four days ago.  what are we waiting for?
We have landed this patch, but the performance is not very well if homescreen has been killed, our target is 0.5 second.
Hi James,

I think it is quite hard for Gaia to make homescreen finish startup process in 0.5 second.
Even on hamachi (master branch), no app (except the blank 'template' app) could finish startup process in 0.5 second.
http://goo.gl/9h2uMO
(In reply to Faramarz [:faramarz] from comment #40)
> this has been r+ four days ago.  what are we waiting for?

This bug has already landed (comment 32) so there is nothing to do here unless we want to land this on master too. 

:tz, do we? If we don't need a master patch here, put [tarako_only] whitboard tag and close this bug.

(In reply to James Zhang from comment #41)
> We have landed this patch, but the performance is not very well if
> homescreen has been killed, our target is 0.5 second.

Please create another bug for that. That is unrelated to this bug.
Flags: needinfo?(tzhuang)
I don't think master need this patch, the reasons are:
1. There will be a new homescreen app in the near future.
2. Homescreen don't get killed on other devices as often as on tarako.

So I'll close the bug.
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Flags: needinfo?(tzhuang)
Resolution: --- → FIXED
Whiteboard: [sprd295070][partner-blocker] → [sprd295070][partner-blocker][tarako_only]
Triage: no need for v1.4.
Flags: needinfo?(msandberg)
Flags: needinfo?(jsavory)
Flags: needinfo?(pla)
Flags: needinfo?(gbrander)
You need to log in before you can comment on or make changes to this bug.