Splash screen best practices
Loading screen with passthrough background provide smooth transition from MR Home to MR apps. During such transition, apps can display logos or other loading images. To this end, apps can leverage a system splash screen, implement a custom startup scene, or both. These are great options, but have limitations. The aim of this guide is to flag limitations and help you find the right solution.
Using system splash screen
The OS displays the system splash screen while the app is loading and before it’s able to provide rendered frames for display. There are number of benefits:
- Appears instantly when the user starts an app
- Incurs a minimal amount of performance overhead, minimizing the app loading time
- Shows assets at the most comfortable distance and field of view and ensures it follows the user’s view smoothly
- Operates within a system process and not within the app space, so it remains unaffected by stuttering, even for resource intensive apps.
Before choosing to use system splash screen, you should take the following into account:
- Duration: The app has no direct control on how long the system splash screen is shown, as it disappears as soon as the app starts rendering
- Allows only static 2D images: There is no option to add animated elements like a rotating 3D asset or a progress bar in this phase
- Artwork:
- Size: Keep artwork within 1500x1500px to avoid unwanted cropping at the margins
- Contrast: Lighting conditions in passthrough can vary drastically between users. The artwork should work well on both light and dark backgrounds. Avoid colors and styles elements that clash with the real-world surroundings
- Text Considerations: Do not reduce artwork containing text to a size that generates aliasing artifacts or negatively affects readability. Consider using large, bold fonts, with a contrasting background. If artifacts are visible, consider increasing the font size and weight
- Line Weights: Similar to text, any lines below a certain thickness may suffer anti-aliasing and flicker against the passthrough background. Consider using thicker weights and contrasting background behind any intricate line-work
- Background: An artwork with fine features can be hard to focus on when it occludes a physical object which is closer than the splash screen. Consider layering an opaque or semi-transparent shape underneath the artwork.
Using custom startup scene
Incorporating a separate startup scene into your app provides much more flexibility compared to the system splash screen. You can use arbitrary 3D objects, apply animation, or even let users interact with them.
Consider the following practices:
- Timing: A startup scene doesn’t appear instantly. It usually takes several seconds to initialize the app’s rendering engine. Fill this gap with a system splash image, or it can be plain passthrough with a loading indicator, such as three dots
- Keep the scene lightweight: The more involved the startup scene, the more time a user will have to wait until the scene is ready. If your app performs additional loading steps in the background during the startup scene, the overhead of displaying the startup scene will compete with the former and possibly prolong the loading time
- Visual compatibility with passthrough: Ensure that the design of the app loading experience is compatible with the passthrough background. This means that loading animations, images, logos, and transition effects should seamlessly integrate with indoor environments visible through passthrough. Avoid colors and styles elements that clash with the real-world surroundings
- Fade-in animation: Implement a fade-in animation during the app load instead of abruptly displaying the app’s interface. This not only looks more polished but also eases the transition between the real world and the app.
- 2D artwork: If a 2D asset is used in the scene, consider the Artwork recommendations from the Using System Splash Screen section above.