Splash Screens — useful or not needed? — Part 2

Current Uses & Problems

When it comes to Splash screens, the crossfire is real. Do we uphold the proper guidelines or give in to the marketing temptation? Are users going to “walk out the door” when you decide to show a splash screen and artificially delay their experience? Or is the brand exposure appreciated by users making them come back for more? The following is a list of problems we can identify for splash screen usage on mobile applications, sorted by technical, usability and marketing issues.

Technical driven issues

As any other mobile application feature, the splash screen presents technical challenges and needs to be planned carefully by the development team. From a purely technical perspective, there are a few problems with the traditional approach to splash screens.

Nowadays, mobile phones are powerful enough to rival some desktop machines and like the former, they can operate under a multi process and multitask context. This means that the resource loading stage can and should be highly optimized by splitting work between several tasks in parallel. Furthermore, once the resources are loaded they remain in memory for some time, meaning the loading process itself (and the splash screen being shown) is only done one time, rendering the splash screen (more accurately, the UI Placeholders or the Launch Images) useless.

Following this train of thought, splash screens are not necessary for most applications. Let’s review: a splash screen is a placeholder for loading heavy resources before the application starts and this process can be time consuming when older hardware is used. In fact, most apps (especially utility applications) do not even require an Internet connection at startup much less loading heavy resources. Aside from specific cases such as games or map applications, the previous statement holds valid. Additionally, we can be sure that both the Google and Apple engineers make sure that both operating systems can load applications as fast as possible and splash screens remove this ability from its applications. How? It is a matter of perspective. Say an Android application is started, displays its splash screen and then reveals its first screen. Technically, what happens is that the splash screen, which is most likely an instance of an Activity, loads very fast (approximately 400 milliseconds), taking advantage of the OS level optimizations for fast loading of applications. For the Android OS, the application loaded very fast, but for the user the application is loaded only after the splash screen is removed, which is the equivalent of the splash screen load time + the splash screen presentation time + the first screen’s (which is also most likely an instance of Activity) loading time by the OS. The splash screen presentation time (usually required artificial delay) that is implemented to ensure the branding gets noticed, gets worse as devices become more powerful, because the artificial delay will have to become longer as the apps will naturally load faster!

Keeping up on the Android framework example, splash screens falsely create the notion that an Android app has a single point of entry. Android apps can have several entry points via the use of the proper Intent-Filter actions in it’s manifest file (while for iOS apps it is mandatory to have a single entry point), but the use of splash screens creates the illusion that the application can only enter from that specific context. This, in turn, provides a favorable condition for displaying branding on a splash screen.

A minor but still very relevant problem pertains the increase in the application’s apk or ipa files with splash screen once viewed resources. Previously, we reached the conclusion that splash screens should be only viewed once given most device capabilities, performance wise. Whether the splash screen is an Image / Logo type or a Video type, developers will need to add resources (such as bitmaps, layouts, etc.) to create the splash screen. Now factor in the array of devices that the application will run on. Each framework supports a different (and sometimes very large) set of possible device screen sizes, resolution and densities. In order to make the splash screen look good on all of them (since it is usually branding, it needs to look really good), several different variations of the same resource might be need! Thus, splash screens, which are only displayed once, can dramatically increase the size of the resulting application build executable!

Usability driven issues

User Experience (UX) is an essential part of any application design as it severely increases the success rate of an application. At its core, mobile applications are meant to let users achieve a purpose quickly. Splash screens (especially artificial ones) prevent it, by blocking user interaction typically in favor of brand expose or some equivalent purpose.

Top quality applications are perceived to be fast and easy to use, which is a clear message to all developers and designers. Developers should make their code as optimized as possible and able to execute as swiftly as possible (especially taking advantage of the work done by Android and iOS engineers that work hard to make the systems as fast as possible), taking especial care about UI rendering, context transitions and battery efficiency. Designers should create beautiful designs but also be especially thoughtful and mindful of ease of use (a simple exercise is counting the number of “steps” or interactions that a user needs to take to achieve some purpose).

This brings us back to the original purpose of the Splash Screen, which was to serve as a placeholder for the application while it loads. This still holds true and stands valid from a usability point of view: if an application can’t load quickly or needs to load some heavy resources at startup then a Splash Screen provides the cues needed to inform the user that the app is working properly, that it is loading and of what status / progress the task is at.

Marketing driven issues

The dreaded marketing devil that is insistent in showing users branding information! Branding is welcome and should be encouraged when creating mobile applications, as it is the trigger for creating visually unique applications. However, there should be proper timings and contexts for showing this information.

Usually, users arrive at an application from one of the following sources:

• Email newsletter or direct link from a website
• In this case, users will know exactly what application they are downloading and why they want to use it. If the source is an email newsletter, then it means a user is already a loyal customer from that specific brand.
• Search on the App Stores for a brand name
• In this case, users already know the brand and know exactly what they are searching for. They will be able to recognize the brand’s logo.
• Search for a keyword and app icon recognition
• In this case, users know what they are looking for and will most likely “pick up” the application whose logo they recognize, thus they are also aware of the brand’s logo.

These sources provide assurance that users do recognize the company’s / brand logo and also indicate that the best approach to invest in branding is on the application’s icon! It is the first image that a user will see on the app stores and it will sit on their device’s menu once the application is installed. This should render the branding information displayed on the splash screen useless, since it is already present on the app’s icon (why sacrifice the user’s time by delaying the application startup when the user already sees the branded application icon?). Furthermore, in-app branding appears to be a better option to ensure users truly recognize the brand when using the application(for example customizing actionbar widgets or adding an “About” screen with such information), as it will be visible across all of the application’s screens.

Simple and Clean Approach

We are now aware of the splash screen’s origin, types and usages. We know all points of view from the different actors that revolve around splash screens. Thus, we are capable of proposing an approach to Splash Screen development (within the mobile context), aiming to create clean and simple splash screens for our applications.

The first rule of thumb forcefully deals with the primary and original purpose of a splash screen. If the application has heavy resources that need to be loaded, then we have to show a splash screen. For the sake of good UX design, all splash screen instances should inform the user of the tasks being executedin the background and their progress. Furthermore, when possible, the user should be informed of the estimated time remaining for the task(s) to finishand for the loading process to be complete (the user needsto know why he/she is waiting and how long it is estimated until the process is finished).

Next, we should try to reach a compromise in order to accommodate both the marketing goals and the technical and UX guidelines. To achieve this, the design guidelines for Splash Screens must be followedand in order to support branding, we should make the splash screen part of the applications’ onboarding strategy(we will dedicate a post to Onboarding in the future). This strategy loosely translates into the following: On “special cases” (i.e. on the applications’ first run and updates), trigger the onboarding sequence, or in other words, a “long” version of a onboarding integrated splash screen (for example, a simple image effect welcoming the user to start the sequence). On every other startup instance of the application, make sure to follow the platforms’ guidelines, using UI Placeholders and / or Launch Images to make the splash screen instantaneous, allowing users to accomplish their tasks as quickly as possible.

Following up on the marketing goals accommodation, consider heavily investing on your application’s icon, as it is the first image that a user will see on the app stores and it will sit on their device’s menu once the application is installed. This is the best approach to invest in branding on mobile applications!

User’s tolerance is usually low (especially in a mobile context) and most of time mobile application’s only have one chance to prove their worth before being deemed unneeded, faulty or useless… So our apps need to dress to impress. Make sure to include a ‘skip’ call to action (if possible) so that users can skip the onboarding sequence and the integrated splash screen.

As a finishing touch, ponder on the option to include a setting that enables users to disable any form of splash screen (or the onboarding sequence altogether) making the instantaneous version the only possibility that can be used.

Conclusion shortlist:

• Rule 1 — If there are resource heavy resources to be loaded, show a traditional splash screen.
• Rule 1.1 — All splash screens instances should inform the user of progress and if possible of the actions being done in the background (the user needs to know why he/she is waiting and how long it is estimated until the process is finished).
• Rule 2 — In order to support branding, make the splash screen part of the onboarding strategy:
• Rule 2.1 — First run and application updates can trigger the “long” version of a onboarding integrated Splash screen.
• Rule 2.2 — All other application starts should follow the platforms guidelines: use UI Placeholders / Launch Images and make the splash screen instantaneous so that the user can accomplish his/her task as quickly as possible.
• Rule 3 — Consider investing on the application’s icon for branding purposes.
• Rule 4 — Make sure to add a ‘skip’ call to action so that the user can skip the onboarding sequence and the integrated splash screen.
• Rule 5 — Make sure to add a setting so that users can disable any form of splash screen (or the onboarding altogether) making the instantaneous version the only possibility that can be shown.