1087845 - [Settings] The timing of dispatching visually complete event is not realistic

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Gaia::Settings, defect)

Description

[Arthur Chen [:arthurcc][inactive after 6/30]]

We dispatched the event right after settings innerHTML but it is not the timing of what users are perceived. We should dispatch the event after the inserted DOM is localized.

Comment 1

[Arthur Chen [:arthurcc][inactive after 6/30]]

Attachment: Link to https://github.com/mozilla-b2g/gaia/pull/25425

EJ, would you mind review the simple patch? Thanks.

Comment 2

[EJ Chen [:eragonj][:小龍哥][Contributor mode on](inactive)]

Comment on attachment 8510026 [details]
Link to https://github.com/mozilla-b2g/gaia/pull/25425

Let's see whether this fixed the profiling tools or not, r+.

== Reference ==

https://datazilla.mozilla.org/b2g/?branch=master&device=flame-319MB&range=7&test=startup_%3E_moz-app-visually-complete&app_list=music,settings&app=settings&gaia_rev=e09e1734ad523cf6&gecko_rev=e8610076a5ff&plot=median

Comment 3

[Arthur Chen [:arthurcc][inactive after 6/30]]

Thanks, EJ.

master: 739c80eba6e2ce9c3cda9661f882c445fa7f0cc4

Comment 4

[Geo Mealer [:geo] -- This account is inactive after 2015-07-07]

I suspect this is the right thing to do, but has anyone from product been able to comment on this? It's not quite a requirements change, but it's an understanding-of-requirements change.

Comment 5

[Geo Mealer [:geo] -- This account is inactive after 2015-07-07]

Should have flagged NI in comment 4

Comment 6

[Arthur Chen [:arthurcc][inactive after 6/30]]

The new timing for visually complete in settings app is the menu items of the initial panel is displayed and localized. Hardware related information may not be ready at that time as it requires time consuming operations. I'm not sure where the original requirement from so flagging Bruce for details.

Comment 7

[Zibi Braniecki [:zbraniecki][:gandalf]]

I'm not sure if this is the right thing to do. App Visually Complete is an event to be fired when the screen stops being updated. That's the time when the timer in users head that is measuring "how long does the app takes to load" stops.

If we fire it before the screen is stable, we kind of cheat on this test in order to get good grades.

I see two solutions to that:

1) We alter the performance criteria for selected apps to use a different timestamp. For Settings, maybe we can use 'moz-chrome-interactive' instead - that's exactly when the UI is ready and usable, but some of the content that will be on the screen is still loading (SIM card status, Wifi etc.) - same problem was reported by Camera app folks.

2) We modify our UX to mitigate the feeling that Settings app is not ready to use until this additional data is loaded. Currently, if you launch Settings you can't use it until wifi/antenna is loaded - you can't enter any panel, click on any toggle etc. That means that the app is not usable until it happens. If we can modify the UX to make the app fully usable except of the items related to the hardware components that are loading, then we could get closer to being able to claim that 'app-visually-complete' happens before the hardware states are being ready.

I would personally recommending going for 1 and 2 together. Eli, what do you think?

Comment 8

[Zibi Braniecki [:zbraniecki][:gandalf]]

oh, and we offer navigator.mozL10n.once() wrapper which is a bit better than using raw 'localized' event listener :)

Comment 9

[:Eli Perelman]

The original requirement is well-documented in bug 996038:

> 'moz-app-visually-complete': Emitted when the application designates that it
> is visually loaded, e.g. the "above-the-fold" content exists in the DOM and
> has been marked as ready for display: e.g. not `display: none`.

So this event is the marker to determine when the app appears ready to use. Before the implementation of the moz-* events, the legacy performance marker was located pretty close to where 'moz-app-visually-complete' is located now (I remember, because I did the original implementation of the Settings app :) ).

I partially agree with Gandalf here. I don't think solution 1 is proper. I think the problems that solution 1 try to solve are already addresses in other events. Solution 2 is spot on and is what I recommend. I propose that you re-evaluate the Settings app from a UX perspective, and consider UI changes and async UI [1] paradigms to improve the experience. Couple that with moving the event to the location where the app REALLY appears to be visually ready and work on your baseline from there.

[1] https://developer.mozilla.org/en-US/Apps/Build/Performance/UI_Synchronicity

Comment 10

[:Eli Perelman]

(In reply to :Eli Perelman from comment #9)
> Before the implementation of the moz-* events, the legacy performance marker
> was located pretty close to where 'moz-app-visually-complete' is located now

By this I mean it was located pretty close to where it was before this bug's change moved it.

Comment 11

[Arthur Chen [:arthurcc][inactive after 6/30]]

The reason I moved the place of emitting moz-app-visually-complete is because after bug 1007600 landed we dynamically insert DOMs of the initial panel when launching. I misunderstood the meaning of the event that it should only be emitted when everything stops updating.

I would incline not include the availability of the information from the hardware in the major performance indicator as it does not (and should not) block users from configuring settings. Settings app now feels like "blocked" by the hardware is because both timing of information becoming available and items becoming interactable are pretty close. I think we should try to enable the menu items faster. When the menu items are enabled, we fire moz-content-interactive (there is no functional chrome in settings app).

We should answer the following questions (specific to settings app) with the UX input before moving forward:
- What can be considered as visually completed?
- Which event can be used a the major performance indicator?

What do you think?

Comment 12

[Arthur Chen [:arthurcc][inactive after 6/30]]

(In reply to Zibi Braniecki [:gandalf] from comment #8)
> oh, and we offer navigator.mozL10n.once() wrapper which is a bit better than
> using raw 'localized' event listener :)

If I insert a new DOM element after navigator.mozL10n.once(), does it call to navigator.mozL10n.once() again after the newly added element gets localized?

Comment 13

[Zibi Braniecki [:zbraniecki][:gandalf]]

(In reply to Arthur Chen [:arthurcc] from comment #11)
> Would answer the following questions (specific to settings app) with the
> UX input before moving forward:
> - What can be considered as visually completed?

When the screen stops updating.

> - Which event can be used a the major performance indicator?

I think that for Settings it should be moz-content-interactive. We still want to keep moz-app-visually-complete because it impacts the user perception and we want to track hardware/driver updates here.

I believe that getting menu items usable earlier, caching menu options availability (so that they are not popping out after firstPaint) and visually deemphasizing hardware indicators so that once they are added it doesn't feel like a major UI update, are three things major wins we can have here.