App Launch Screens, an Android taboo

App Launch Screens, an Android taboo

It’s no secret that Google have been focusing their efforts on user experience on mobile for some time now. Mobile search optimisation, penalties for sites not optimised for mobile, and a topic we covered recently on app interstitials are just a few examples. Recently, Google have been tackling the issue of splash screens.

For a long time now, the general opinion on the use of “splash screens” on Android has been overwhelmingly negative; so when a recent update to Google’s “Material” design guidelines seemed to advocate for the use of what they call “launch screens”, this faced some backlash from the Android community. We believe this backlash is somewhat misguided, and along with a helpful post from the Android Developers Google+ account, aim to show you the advantages that these screens can provide, and how they can be implemented without detriment to the user experience.

The Launch / Splash confusion

Splash screens are bad. Splash screens exist only to promote an app’s “brand”, and do so at a detriment to the user, often slowing down entry into the app and causing frustration.

In the past, splash screens would often come with a minimum delay, ensuring that the user views a company logo or other branding material every single time they open the app. Splash screens have also been used as a waiting screen with a progress indicator, while content is being downloaded in the background. Both of these approaches are generally deemed bad practice, and are certainly not what we want to vouch for in this post.

But wait, didn’t you say the backlash was misguided?

Indeed I did! That’s because this backlash is directed at splash screens, and their is an understandable confusion as to what the difference is between this and the recommended launch screen.

The Material design guidelines recommend one of two approaches to launch screens:

  • Placeholder UI – this is a simple “approximation” of the actual UI a user will see when the app loads, without the usual content filled in. This is a good approach to use if your app has an extremely quick launch, as transitioning from the placeholder UI to the actual content will be near seamless.

  • Branded launch screen – this an opportunity to show your app’s branding while the system does the necessary work to load your app, usually a simple app logo on a single colour background.

That second option sounds an awful lot like a splash screen…

It sounds exactly like a splash screen, and for the most part the concept is the same. However, another section of the guidelines has some more clarification on branded launch screens:

 “Launch screens should be used for initial, cold launch from the home screen, and should not displayed if the application is running, or if the launch comes from another application.“

This is the key difference that makes a launch screen palpable. Instead of hindering the user experience, if implemented correctly, a launch screen simply takes advantage of an already existing delay when opening the app. The term “cold launch” means that the app is not currently in the devices memory, and will take longer to load, especially on older devices.

How it’s done

In order to ensure that we are only taking advantage of existing delays (which hopefully should be minimal), and not introducing delays of our own, the previously linked Google+ post specifies how Google themselves are implementing branded launch screens in their apps. This implementation takes advantage of Android’s built in theming system.

An app usually defines one or more “themes” in an XML file, with things like background and toolbar colours, text styles and more. Through this system, we can define a specific, “launch” theme. Instead of using just a solid colour for its background, this theme uses a more complex XML file, which defines a background colour and one or more images. In Google’s apps, this consists of a plain white background, a large version of the app’s icon, and a Google logo at the bottom.

Above is an example of what the user sees with and without a launch screen. The left shows the Google Keep app, which does not use a launch screen of any kind, just displaying a blank canvas with the app’s default background colour. On the right we see the Google+ app’s altogether more appealing launch. Once the app is launched, the first view will override the launch theme and transition to the desired content, all without introducing any unwanted delays.

Speed is still key

At this point, you may be thinking “great, now it doesn’t matter if my app takes an extra second or two to launch!”. Well, that’s just lazy. Launch screens should never be used in order to try to cover up other wrongdoings within your application. If done correctly, a launch screen can make your app perceptively faster to launch, but if users are constantly staring at your brand logo, waiting for something to happen, don’t be surprised if an angry mob of Android die-hards come knocking at your door.

If you found this post useful, or have any further questions, please leave a comment!

Looking to develop an app with The Distance? Call Tom or email us