Splash Screens – useful or not needed? – Part 1
What is a Splash Screen?
Splash screens are a very controversial topic and have been so for a very long time. Developers, designers, marketers and even clients have been “at war” when it comes to this topic. But what is a splash screen? The usual definition would classify a splash screen as an image that takes up the entirety of the mobile device’s screen and is shown briefly. The more technical definition would be something like the following: a splash screen is a placeholder for an app while it loads.
The technical definition is not wrong. The primary purpose of a splash screen is to give users immediate feedback that the app has started… and that is loading. This effectively enhances the user experience (UX), providing an important degree of responsiveness for the very initial state of an application (if an app takes some time to load, showing a black / blank screen will probably confuse users, who will mistakenly think the app is hanged, blocked or not working). This is the focal intent of all splash screen instances. However, as all intents and purposes go, there were those that looked at splash screens as an opportunity, something more that its original purpose meant to be. Thus, a new controversial purpose was accredited to splash screens: displaying branding information. And so… they became “evil”!
Splash Screen History – The Desktop Era
Splash screens made their first appearance when Flash websites reached their peak. Back then, the average Internet connections were slow (56kb dial-up connections) and those Flash applications / websites needed to load data before being ready for use. As expected, this set up time was considerable and splash screens became a way to show some kind of animation to users while the application / website was loading. Just as nowadays, marketeers reached the conclusion that these splash screens presented an opportunity to display branding information and this practice was adopted by the majority of splash screens available at the time.
At first, splash screens took the shape of a relatively small (for desktop applications) or full screen (for smaller screens, such as the ones used by phones) image. Later, their design evolved and splash screens started to show more information about what was being done in the background, either by showing a progress bar (effectively giving users important visual cues about how long the setup process would take) or by showing which files / actions were being executed.
However, splash screen design was not the only thing to evolve. Broadband connections started to become the norm, faster and more reliable than their predecessors, effectively improving Internet connections in general. The Flash platform also developed and browsers would gain the ability to handle the technology further. All these improvements resulted in smaller set up time for applications / websites and … the beginning of the end for splash screens.
The fall of splash screens began with the introduction of ‘Skip Intro’ buttons. Content was loading faster and loading intro sequences started to be “manufactured” (splash screens were wired with a set delay) in order to continue to display the branding information to the users. This was not well received by users who did not like to be delayed by marketing techniques and so “Skip Intro” buttons presented themselves as the temporary solution for that problem. Why temporary? Because even with “Skip Intro” buttons, users were still delayed to enter the application / website , even if they now had a choice in watching the intro sequence or not. The general consensus was simple and clear: if a “Skip Intro” button is needed then the splash screen was useless and it should be removed.
Splash Screen History – The Mobile Era
History repeats itself. This millennia old saying fits perfectly when describing splash screen history. Just as in the previous era of desktops, mobile applications started using splash screens when they needed time to load (either because of slow Internet connections or less powerful mobile devices) and were used to display branding information. Their evolution was also consistent with how they evolved on desktops as well: from single images, to displaying progress bars / executed actions in the background, to allowing users to skip it (splash screens with a fixed time delay). Not surprisingly, splash screens are now viewed as not need (for most cases), as devices have grown to be as powerful as mid class desktops and Internet connections are as fast as they have ever been.
The two giants of the mobile industry seem to believe that splash screens are unnecessary for most applications:
- Apple is openly non-compliant with the use of splash screens on iOS applications;
- iOS developers are instructed to “As much as possible, avoid displaying a splash screen or other startup experience. It’s best when users can begin using your app immediately.”;
- Apple UX designers uphold the use of launch images (we will discuss these in the next section).
- Previously, Google’s stance on the subject was in line with Apple’s and splash screens were strictly forbidden in their view. The guideline for Android developers translated as “Don’t use splash screens.”;
- However, with the introduction of Material Design, Google changed their posture and took a more neutral stance regarding “splash screens”, which are now referred to as… launch screens!
- Android developers are now encouraged to use launch screens on more resource demanding apps (as Google itself did with the Youtube app, for instance);
- The current splash screen sequence recommended to Android developers is as follows: Branded screen -> UI placeholder -> the app itself.
Interestingly, most of the splash screens used on mobile apps were created by iOS developers for iOS applications. The reason is that the early iPhones could not handle a fast loading of applications and thus the splash screen was needed. The same can be said for Android applications and early Android devices. Despite both companies seeing splash screens as marketing techniques, most iOS and Android developers were forced to push aside the guidelines to favor their client’s desire to push branding when users first open the apps, ensuring that they see their logo each time the app is opened.
This fact, is why splash screens are a constant cause of pain for mobile developers and the very reason for the “war” between different actors of the mobile app development scene.
The Splash Screen <> Launch Image Difference
Splash screens are not the same as Launch Images. This should be made clear and irrevocable, although the distinction is not immediately clear.
Apple’s UX designers are the authors of launch images which the Apple Human Interface Guidelines translate as the following: “… an image very similar to the first screen your app displays. iOS displays this image instantly when the user starts your app and until the app is fully ready to use. As soon as your app is ready for use, your app displays its first screen, replacing the launch placeholder image.” In short, a launch image is a gimmick used to pretend an application launched rapidly and swiftly, with the goal of providing the best user experience possible for the app’s startup stage. On the other hand, splash screens do not explicitly mimic the application’s interface, as launch images do, but instead serve as a placeholder for the application while it is loading. This placeholder can look entirely different than the application’s design! In fact the only instance where a splash screen can (and should) be confused with a launch image is when the splash screen’s placeholder has the exact same look as the initial screen of an application.
As stated earlier, Material Design introduced new guidelines regarding splash screens: the new and improved launch screens, composed of the sequence Branded screen, UI Placeholder and finally the app’s first screen. Inspecting closely, we can see that the UI Placeholder serves a very similar purpose to the Launch images used on iOS apps. The UI Placeholder is meant to present the fewest possible transitions and greatest perceived responsiveness by displaying the core structural elements (such as the status bar, app bar and bottom sheets) without content until the app finishes loading. Thus, we can say that an Android UI Placeholder is the same as an iOS launch image!
Splash Screen Types
By this point we can establish that a splash screen is a means to handle an application’s startup phase, as efficiently and briefly as possible. We can also understand why marketers see them as a technique to display branding information: since there is no content to display, we might as well make sure the user is exposed to the brand! This practice was inspired by games and (historically) by desktop applications, which usually have a heavy loading setup phase. There is no formal definition for splash screen types, but for mobile applications we can distinguish two types: the Image / Logo based splash screen and the Video based splash screen.
Image / Logo Type
The most common splash screen we encounter on mobile applications features some kind of image. Some simply display the company’s or the application’s logo. Others, show decorative images accompanied with the logo.
In an attempt to enhance the UX of the app’s onboarding stage, some splash screens of this type will feature animations and display information through the use of widgets. These widgets translate into progress bars and text indications of the ongoing background work.
This type of splash screen is usually short, timewise.
Video type splash screens are least likely to be used but there are some cases where using such a flashy application entry is a good option (for example, in case the app is custom made for an event). A video type splash screen, as the name implies, plays a video related to either the company / sponsors or the application’s main purpose.
This type of splash screen can also feature animations and display information through the use of widgets. Since the video can be set to loop, this splash screen can be extended to handle the whole onboarding stage of an application allowing for more interactivity than the more common image / logo type splash screens (displaying about screens, tutorial sequences and handling user authentication, etc.).
Hardworking and passionate individual keen on learning and clearing any challenges coming his way.
Working in such a fast paced industry as Application Development, Paulo always aims to try and learn new technologies and new ways to perform his work, either through optimization or efficient process management. He is always open to embrace projects as long as they represent a brand new challenge and learning experience for him.