An overview to VR best practices

More and more is being discovered and written each day about the dos and don'ts when designing and developing for VR. Google provides a couple of resources to help developers build great VR experiences, including the following:

• Designing for Google Cardboard is a best practice document that helps you focus on overall usability as well as avoid common VR pitfalls (http://www.google.com/design/spec-vr/designing-for-google-cardboard/a-new-dimension.html).
• Cardboard Design Lab is a Cardboard app that directly illustrates the principles of designing for VR which you can explore in Cardboard itself. At Vision Summit 2016, the Cardboard team announced that they have released the source (Unity) project for developers to examine and extend (https://play.google.com/store/apps/details?id=com.google.vr.cardboard.apps.designlab and https://github.com/googlesamples/cardboard-unity/tree/master/Samples/CardboardDesignLab).

VR motion sickness is a real symptom and concern for virtual reality caused in part by a lag in screen updates, or latency, when you're moving your head. Your brain expects the world around you to change exactly in sync with your actual motion. Any perceptible delay can make you feel uncomfortable, to say the least, and possibly nauseous. Latency can be reduced by faster rendering of each frame to maintain the recommended frames per second. Desktop VR apps are held to the high standard of 90 FPS, enabled by a custom HMD screen. On mobile devices, the screen hardware often limits refresh rates to 60 FPS, or in the worst case, 30 FPS.

There are additional causes of VR motion sickness and other user discomforts, which can be mitigated by following these design guidelines:

• Always maintain head tracking. If the virtual world seems to freeze or pause, this may cause users to feel ill.
• Display user interface elements, such as titles and buttons, in 3D virtual space. If rendered in 2D, they'll seem to be "stuck to your face" and you will feel uncomfortable.
• When transitioning between scenes, fade to black. Cut scenes will be very disorienting. Fading to white might be uncomfortably bright for your users.
• Users should remain in control of their movement within the app. Something about initiating camera motion yourself helps reduce motion sickness. Try to avoid "artificially" rotating the camera.
• Avoid acceleration and deceleration. As humans, we feel acceleration but not constant velocity. If you are moving the camera inside the app, keep it at a constant velocity. Rollercoasters are fun, but even in real life they can make you feel sick.
• Keep your users grounded. Being a virtual floating point in space can make you feel sick, whereas feeling like you're standing on the ground or sitting in a cockpit provides a sense of stability.
• Maintain a reasonable distance from the eye for UI elements, such as buttons and reticle cursors. If objects are too close, the user may have to look cross-eyed and can experience eye strain. Some items that are too close may not converge at all and cause "double-vision."

Applications for virtual reality also differ from conventional Android apps in other ways, such as:

• When transitioning from a 2D application into VR, it is recommended that you provide a headset icon for the user to tap, as shown in the following image:
  
• To exit VR, the user can hit the back button in the system bar (if present) or the home button. The cardboard sample apps use a "tilt-up" gesture to return to the main menu, which is a fine approach if you want to allow a "back" input without forcing the user to remove the phone from the device.
• Make sure that you build your app to run in fullscreen mode (and not in Android's Lights Out mode).
• Do not perform any API calls that will present the user with a 2D dialog box. The user will be forced to remove the phone from the viewer to respond.
• Provide audio and haptic (vibration) feedback to convey information and indicate that the user input is recognized by the app.

So, let's say that you've got your awesome Cardboard app done and it is ready to publish. Now what? There's a line you can put in the AndroidManifest file that marks the app as a Cardboard app. Google's Cardboard app includes a Google Play Store browser used to find a Cardboard app. Then just publish it as you would do for any normal Android application.