And the key word we're looking to address here should be "perceived".įrom a UI perspective, I like the toolbar showing as soon as the app is launched. I think the key thing we're trying to improve here is perceived performance. This is followed immediately by the session store restoring all previous session history entries for that tab, at the end of which we need to reload the current history entry ( ), which as a side effect momentarily resets the progress bar. When Gecko eventually starts up, it opens those tabs as well and starts loading the foreground tab. We parse the session file from Java, open the tabs in our UI and queue up corresponding messages to Gecko, display some minimal progress on the progress bar and then wait for Gecko. By coincidence your phone probably manages to start Gecko fast enough that this happens right around the time the splash screen fades out - on my phone it usually takes a second or two longer. That it resets is an artefact of how our session restoring works and happened before the splash screen changes as well. As far as I can tell, the progress indicator doesn't behave any different than before. I'm not sure this can actually blamed on the splash screen. > The progress indicator resets after the (In reply to Dietrich Ayala (:dietrich) from comment #4) While I think that bug 1378688 led to some improvement, I'm still not really convinced that this is an improvement and would agree with Richard in comment 1. I hope this illustrates the problematic nature of these changes. Firefox logo disappears, progress indicator resets to beginning, and shows the progress of the web page being loaded.Īs you can see above, both splash screen implementations add *more* stages in the user flow, and the visual design of these new stages brings attention to *Firefox* being slow, instead of letting the network or web page receive that attention. Firefox opens with app UI fully visible, with Firefox logo visible, and progress indicator showing the progress of something (unclear what. App UI becomes visible, progress indicator shows the progress of the web page being loaded.Ģ. Firefox opens with no app UI visible yet, with only Firefox logo visible.ģ. Firefox opens with app UI fully visible, and progress indicator showing the progress of the web page being loaded.įlow in splash screen, after initial landing:Ģ. Here's a breakdown of the states of experience in each implementation.Ģ. I've been using this new change since it landed, and it actually they added a new problem on top of the old: The progress indicator resets after the Firefox logo disappears. Unfortunately the change implemented in bug 1378688 didn't address the concerns I had, which is *why* I filed this new bug. (eg, show progress indicator that tells a story about slow network, slow website, etc)Īdding "regression" since this is a UX regression in the area of perceived performance. But when loading from other app, it seems like we want to do everything possible to instantly make app UI visible and push any perceived slowness away onto other potential causes. I can understand showing the Firefox logo splash on launch from homescreen. It tells a clear story about how *Firefox* is slow, instead of how the *network or website* is slow. Showing a Firefox logo, especially when loading a link from another app, does the opposite of improving perceived performance. Instead of attempting to load the web page, it appears Firefox is now struggling to just load itself. Overall, the splash screen gives the feeling of a much slower app. Notes from bug 1378688, which made the splash screen semi-transparent but the Firefox logo remains:
Now it loads the splash screen with the Firefox logo as the app icon, which I see regularly since the change landed. The app used to load the UI and then the web page, which gave the impression it was busy loading the web page.
0 kommentar(er)
