Closed Bug 1380698 Opened 7 years ago Closed 7 years ago

the splash screen with Firefox logo makes the app feel slow

Categories

(Firefox for Android Graveyard :: Theme and Visual Design, defect)

defect
Not set
normal

Tracking

(firefox54 unaffected, firefox55 unaffected, firefox56 fixed)

RESOLVED FIXED
Firefox 56
Tracking Status
firefox54 --- unaffected
firefox55 --- unaffected
firefox56 --- fixed

People

(Reporter: dietrich, Assigned: cnevinchen)

Details

(Keywords: regression)

Attachments

(1 file)

The app used to load the UI and then the web page, which gave the impression it was busy loading the web page.

Now it loads the splash screen with the Firefox logo as the app icon, which I see regularly since the change landed.

Notes from bug 1378688, which made the splash screen semi-transparent but the Firefox logo remains:

Overall, the splash screen gives the feeling of a much slower app. Instead of attempting to load the web page, it appears Firefox is now struggling to just load itself.

showing a Firefox logo, especially when loading a link from another app, does the opposite of improving perceived performance. It tells a clear story about how *Firefox* is slow, instead of how the *network or website* is slow.

I can understand showing the Firefox logo splash on launch from homescreen. 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. (eg, show progress indicator that tells a story about slow network, slow website, etc)

Adding "regression" since this is a UX regression in the area of perceived performance.
Flags: needinfo?(gpetrie)
Flags: needinfo?(alam)
It's worth observing that the main point of the native Fennec rewrite, phrased in very simple terms, was to avoid showing a splash screen while we wait for Gecko to load.

To flip this around: we can improve perceived startup time, save 8MB of RAM on launch, and save 150+KB in the APK by simply deleting this feature. Awesome! :D
While we haven't conducted research on this particular issue, we have been exploring the perceived performance space on desktop. I agree with Dietrich that the intercalary splash screen would likely result in slower perceived performance.
Flags: needinfo?(gpetrie)
Hi guys, before we came to a conclusion that adding a splash screen feels slower than before, could everyone try out the latest "Nightly"? Basically, the changes are URL bar and progress indicator is added back. If everyone still feels that it makes Firefox feel slow on start, we are happy to remove the splash screen. As adding the splash screen was previously intended to make users feel faster.
Flags: needinfo?(alam)
Thanks Harly. Unfortunately the change implemented in bug 1378688 didn't address the concerns I had, which is *why* I filed this new bug. This bug is *about* those changes.

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.

Here's a breakdown of the states of experience in each implementation...

Flow prior to splash screen:

1. Click on URL in some app

2. Firefox opens with app UI fully visible, and progress indicator showing the progress of the web page being loaded.


Flow in splash screen, after initial landing:

1. Click on URL in some app

2. Firefox opens with no app UI visible yet, with only Firefox logo visible.

3. App UI becomes visible, progress indicator shows the progress of the web page being loaded.


Flow in Nightly today:

1. Click on URL in some app

2. Firefox opens with app UI fully visible, with Firefox logo visible, and progress indicator showing the progress of something (unclear what... the loading of the logo?).

3. Firefox logo disappears, progress indicator resets to beginning, and shows the progress of the web page being loaded.


As 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.

I hope this illustrates the problematic nature of these changes.
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.

That aside,
(In reply to Dietrich Ayala (:dietrich) from comment #4)
> The progress indicator resets after the
> Firefox logo disappears.

... I'm not sure this can actually blamed on the splash screen. As far as I can tell, the progress indicator doesn't behave any different than before. That it resets is an artefact of how our session restoring works [1] and happened before the splash screen changes as well. 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.

[1] 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. When Gecko eventually starts up, it opens those tabs as well and starts loading the foreground tab. 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 (https://dxr.mozilla.org/mozilla-central/rev/e0b0865639cebc1b5afa0268a4b073fcdde0e69c/mobile/android/components/SessionStore.js#1343), which as a side effect momentarily resets the progress bar.
(In reply to Jan Henning [:JanH] from comment #5)
> I'm still not really convinced that this is an improvement

"this" referring to the splash screen as a whole in this instance.
I think the key thing we're trying to improve here is perceived performance. And the key word we're looking to address here should be "perceived". 

From a UI perspective, I like the toolbar showing as soon as the app is launched. That's definitely an improvement compared to the previous 'full-screen' splash screen. The splash screen also serves the function of hiding UI that's not quite ready yet and then easing the user into it rather than having it all crash in. 

(side note: Skeleton UI is something that has also been widely adopted in many other applications to address the same "crashing in" issue, we had a bug for that somewhere before)

---

But perhaps now is a good time to compare what we have here, to our existing in-product UX? Is it actually faster? and does it feel faster? 

Ultimately, I think if it's not _obviously_ faster to most of us then perhaps this solution isn't really addressing the issues of "perceived" performance we set out to address.

I know we must consider the timing of this too. But it's a tricky thing that we should try to get right. Thoughts Harly?
Flags: needinfo?(hhsu)
Comment on attachment 8888191 [details]
Bug 1380698 - Use SVG for splash screen logo for all channels.

This patch use SVG instead of PNG.
The size is 3KB, and with no noticeable memory foot print nor CPU usage. (tested on Nexus 5 Android 5.1.1 and 6.0.1)
Should be a better solution.
Carol will upload a video to compare with no splash screen version later.
Hi guys!
Here's the video: https://drive.google.com/open?id=0B-9PIePlQZRlNmR5Z0J5aW42bkU
We put the current and the new design together for comparison.

I want to echo back to what Anthony said, we want to improve our "perceived performance". Adding the splash screen(an icon) is to gives user "Feedback" more quickly instead of letting the user staring at a white empty screen. 
Please take a look at the video and let us know if you have any further thoughts.
Flags: needinfo?(hhsu)
Comment on attachment 8888191 [details]
Bug 1380698 - Use SVG for splash screen logo for all channels.

https://reviewboard.mozilla.org/r/159122/#review165160
Attachment #8888191 - Flags: review?(max) → review+
Assignee: nobody → cnevinchen
Pushed by nechen@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/b1f588a6e1fa
Use SVG for splash screen logo for all channels. r=maliu
We are just changing some images to smaller size. And also there's no comments after Comment 10, it is safe to land this even now is code freezed period.
The patch in this bug and in bug 1378688 both make changes that don't address my concerns about using the logo as an indicator. And yes, I understand completely what perceived performance means.

The video in comment #10 is very clear - the one page *actually* loads much faster than the other - doesn't have anything to do with perceived performance. If adding the logo makes pages *actually* load faster instead of just perception, then we should always show the logo for all pages ;)

We have a performance indicator designed specifically to address the cognitive impatience - it's the progress indicator. If it's not doing its job, then we should fix *that* instead of also adding our logo there as a "we're slow!" banner.

But I have said my thoughts in comment #0 and further down as well, so will stop repeating them. Thanks for hearing me out :)
https://hg.mozilla.org/mozilla-central/rev/b1f588a6e1fa
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 56
I think Dietrich does bring up some good points here. It seems to me that there's an issue that we've yet to address with this patch, which is this notion of "blame". I can see how getting an icon in front of users in this moment could potentially become annoying (esp since all they want to do is load the page). Since this is something that happens often with a browser app, users just want to get to their web content, they might view an icon as something that's just getting in the way.

Like on the Desktop side, I think we should figure out ways to test and measure this before shipping it to a wider audience. Harly and the team are away on field work this week, I think they're wrapping up soon though so I'll bring this up with him.

Maybe a solution here could be to differentiate between a cold-start (where it might make more sense to load a splash screen) and "switching back to" an already open instance of Firefox? The latter being most suited to a "quickly show me the status on this page load I asked for" type of UI.
To add to my point ^ I will say that Apple has an interesting take on this that might be worth learning from [1]. The "Launch Screen" in iOS is something they make all Apps provide. The goal is to have a screen that appears instantly. But to also have that quickly replaced with the first screen of the app. All in the name of speed and responsiveness too.

The guiding principles there (that we can decide for ourselves if we should follow closely or not) are as follows:

- Design a launch screen that’s nearly identical to the first screen of your app. 

- Avoid including text on your launch screen. 

- Downplay launch.

- Don’t advertise.

[1] https://developer.apple.com/ios/human-interface-guidelines/graphics/launch-screen/
(In reply to Anthony Lam (:antlam) from comment #16) 
> Maybe a solution here could be to differentiate between a cold-start (where
> it might make more sense to load a splash screen) and "switching back to" an
> already open instance of Firefox? The latter being most suited to a "quickly
> show me the status on this page load I asked for" type of UI.

The logic here is 
1. If the app started before , don't show splash screen (cause Gecko is ready, web page loading is faster)
2. If the app had never starts before, and the last tab is Java UI, we don't show the splash screen (Top Site now, activity Stream later. The Java is fast enough)
3. If the app had never starts before, and the last tab is a web page, we show the splash screen
4. If splash screen appears, and the user touch the url bar, we hide the splash screen and show Java UI 
5. If Gecko is ready and the web pages receive the first LOCATION_CHANGE gecko event, we hide the splash screen.

I think Chrome also follows HIG. Our previous design also follows HIG. But I think it also changes time after time :)

btw, the two builds on each devices in the video are the same. 
I just remove 
http://searchfox.org/mozilla-central/source/mobile/android/base/java/org/mozilla/gecko/BrowserApp.java#2754
to 
http://searchfox.org/mozilla-central/source/mobile/android/base/java/org/mozilla/gecko/BrowserApp.java#2756
for the non-splash screen version.
sorry. I reseted the status flag in comment 17
Sorry for the late reply, since I just got back from the field research. Just want to clarify, the only difference about the 2 is with or without the splash screen and we did our best to trigger them both at the same time. The focus of the video is not about which one completely loads the page faster (since device and connection status will impact it), but about comparing the experience of providing a blank page or a logo feedback to the user when the app "cold start", in which often times takes a while especially on a low-end device. Also, users will only see the splash screen when it cold start and will not show when switching back from an already opened instance of Firefox. (Nevin has described the logic of it in comment 18.)

We believe by providing a subtle logo feedback, user's attention will not be on the loading of the progress bar which gives users the feeling of not being responsive. After discussing with the team, we have decided to go ahead and push this to Beta and get feedbacks from a broader audience and will conduct A/B testing or user research if needed. Thank you all for providing the comments.
The svg logo improves apk size a bit relative to whatever was used before:

== Change summary for alert #8407 (as of July 28 2017 13:56 UTC) ==

Improvements:

  0%  installer size summary android-4-0-armv7-api15 opt      36,519,468.50 -> 36,390,275.42

For up to date results, see: https://treeherder.mozilla.org/perf.html#/alerts?id=8407
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.