250 bytes, text/html
STR: 0. (It's best if you haven't configured cost control yet) 1. Launch Cost Control. Watch your screen. ACTUAL RESULTS: A sequence of ~4 different screens appears, each of which has buttons that look like I should interact with. Finally it stops changing when it reaches the last screen. Screencast: EXPECTED RESULTS: App launches with much fewer screen changes. I'd expect either it to be mostly-blank until it's ready, or to show the first screen immediately but have its controls disabled until the app is ready. (And load whatever else needs to load in _non-user-visible_ area.) There might be one "intermediate" screen that's unavoidable -- it seems that B2G often shows a rasterized "last snapshot of this app" at app-launch-time -- so that one is fine. The other ones, though, should be hidden / cleaned up so that they don't rapid-fire at the user on app-launch.
Screencast of Cost Control First Launch (w/ all these screens popping up): https://www.youtube.com/watch?v=_BNQymz27Zw Canceling blocking request (sorry, that was added by my file-new-b2g-bug bookmark), because I think this sucks a bit but it shouldn't block. This also is related to meta bug 817099.
blocking-basecamp: ? → ---
It annoyed me too.
tracking-b2g18: --- → ?
Summary: [Cost Control] Until I've set up cost control, opening it will flash a sequence of different screens at you, before you can actually use the app → [Cost Control] Cost control flashes on screen change
OS: Linux → Gonk (Firefox OS)
Hardware: x86_64 → All
Tracking since it's included in work around improving cost control performance (hopefully in v1).
status-b2g18: --- → affected
tracking-b2g18: ? → +
The performance reduce the effect but I think we can try harder here.
Assignee: nobody → salva
Created attachment 720764 [details] Avoiding flashing by introducing a loading cover until UI is ready
CC to José Manuel. Cancelling PR in order to try to avoid even the loading screen.
There are two problems: In steady state the FTE of the app flashes and annoys the user. Another issue is that if you don't have a Vivo SIM card, the balance tab appears and suddenly disappears. My proposal for fixing this is: We need a visual design that will allow to show a neutral screen that will fade out once we know what we have to show to the user (the FTE, the regular UI (with or without the balance tab). Adding Sergi to this bug. I totally agree this affects the perceived quality of the app and IMHO this bug should be leo+.
Not a regression from v1.0.1, so not a blocker for v1.1 unless it's specifically coordinated as a blocker with the product team.
blocking-b2g: leo? → -
As far as i can see we have two options here: 1- We're already using a neutral screen every time we launch an application (the one with the rocket launcher, depending on the branding you are using). We may keep that screen until the app is loaded, and then show the app content. The whole idea behind this neutral screen is to be used for these cases. 2- Another option is to use a BB loading component until everything is loaded properly, and then show the appropriate cost control screen. We're already using a screen like this in the FTU when the system starts looking for the available WiFi networks. You can find some samples for this component in the wiki, under "Progress and Activity Indicators" (https://wiki.mozilla.org/Gaia/Design/BuildingBlocks#Progress_.26_Activity_Indicators). I recommend to use the modal one with the spinner. The recommended solution is number 1. I think the 2nd solution will not solve the problem completely because when the user launches the app he will see the start screen, a blink, and then loading screen. As far as it's possible i recommend to use the 1st solution. As far as there's enough possible solutions, i do not recommend to create new visuals for a neutral screen. Let me know your thoughts.
Hello guys! I finish this patch, wait for the PR soon! (In reply to Daniel Holbert [:dholbert] from comment #0) > STR: > 0. (It's best if you haven't configured cost control yet) We stiil have a "flash" here but not related with this bug. I we want to solve it, let's open another one. > 1. Launch Cost Control. Watch your screen. > > ACTUAL RESULTS: > A sequence of ~4 different screens appears, each of which has buttons that > look like I should interact with. Finally it stops changing when it reaches > the last screen. Screencast: > > EXPECTED RESULTS: > App launches with much fewer screen changes. I'd expect either it to be > mostly-blank until it's ready, or to show the first screen immediately but > have its controls disabled until the app is ready. (And load whatever else > needs to load in _non-user-visible_ area.) This is what we get now. ;) > > There might be one "intermediate" screen that's unavoidable -- it seems that > B2G often shows a rasterized "last snapshot of this app" at app-launch-time > -- so that one is fine. The other ones, though, should be hidden / cleaned > up so that they don't rapid-fire at the user on app-launch. You are right but I hack this as well.
Created attachment 738943 [details] Avoid flashing by delaying showing the tabs until we know what to show exactly
Comment on attachment 738943 [details] Avoid flashing by delaying showing the tabs until we know what to show exactly Finally, this patch improves a lot the UX and it's a quick win! Thanks Salva, great job!
Attachment #738943 - Flags: review?(francisco.jordano) → review+
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Duplicate of this bug: 853332
Comment on attachment 738943 [details] Avoid flashing by delaying showing the tabs until we know what to show exactly 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 #): bug 836027 and others User impact if declined: moderate (perceived performance is notably improved) Testing completed: yes Risk to taking this patch (and alternatives if risky): low String or UUID changes made by this patch: none
Attachment #738943 - Flags: approval-gaia-v1?
Attachment #738943 - Flags: approval-gaia-v1? → approval-gaia-v1+
I was not able to uplift this bug to v1-train. If this bug has dependencies which are not marked in this bug, please comment on this bug. If this bug depends on patches that aren't approved for v1-train, we need to re-evaluate the approval. Otherwise, if this is just a merge conflict, you might be able to resolve it with: git checkout v1-train git cherry-pick -x -m1 34d0040465d4f01cdd575c3071af185db66bbca2 <RESOLVE MERGE CONFLICTS> git commit
This bug is affected by the Cost Control PR in bug 830644. I'm going to nominate that PR for approval.
As the PR has not been approved for v1.1, I'm going to merge the changes without the dependency. I'm gonna evaluate the risk of merging or make another PR for v1-train only. We'll see.
status-b2g18: affected → fixed
You need to log in before you can comment on or make changes to this bug.