UX-D1: Users can focus on objects and read necessary text
Objects must be placed far enough away from the user that they can visually converge on an object and not see a double image. If the object in question is required text, it must also be large enough to be legible on a Daydream Ready phone.
We recommend you start by placing objects more than 0.5m away from the user, and making sure all font sizes take up at least 1.5 degrees of the user’s visual field of view.
UX-D2: App maintains head tracking
Your app must maintain head-tracking, and all virtual objects must be locked relative to the world, not to the user’s head. Large head-locked objects give the impression that the user has a large screen attached to their head, as opposed to feeling like they are in a virtual environment.
UX-D3: App has a stable horizon line
Your app cannot have sudden camera oscillations that cause the horizon line to move unexpectedly, and the ground the user is standing on can't be significantly slanted. This can be extremely disorienting and nauseating for users.
UX-D4: Camera movement must be user-initiated
Apps should not take control of the camera (which is also the user) and move it (them) unexpectedly. Users should feel in control of their movements by clicking or otherwise showing clear intent before the camera moves. For example, the user could aim at and select teleportation targets, or use the touchpad to move the camera.
This criterion does not mean that the user must always be in direct control of the camera’s motion, but rather they must initiate the moments when they are not in control. For instance, the user must click to begin riding a rollercoaster, at which point it’s okay for the coaster track to take control of the user’s movement away from the user.
UX-D5: App does not interfere with system-level recentering behavior
When users long-press the Home button on the Daydream controller to recenter the app, the system automatically performs a recenter, that is, the controller and headset's current pose will be redefined as "forward".
Your app must not interfere with this process or apply any offsets to the cursor position. After recentering is complete, the following must be true:
- The cursor is shown directly in front of the user, without any lateral offset (not off to a side or behind the user). If you are rendering the cursor in the wrong position after a recenter, it is because you are not handling the cursor's position properly.
- The headset is now facing the application's "preferred forward" direction. In a game where the player is sitting in an airplane cockpit, for instance, the "preferred forward" is facing towards the nose of the plane. If your app is a "360 app" with no preferred forward direction, the direction the user is facing should remain the same: your app must compensate for the recentering by rotating the scene/camera to ensure that the same object that was in front of the user before the recenter remains in front of the user after the recenter. When performing this compensation, be careful not to violate the item above (the cursor must be directly in front of the user after the recenter).
UX-D6: App recenters appropriately with respect to the experience
If the app has a central UI element that the user should always be facing, such as the YouTube UI, then on recenter, the app’s world and UI must be properly re- aligned with the headset and controller. This means that after the recenter the camera should be facing the central element in your UI and the controller's cursor should be centered on the view. This is what happens by default in the SDK. All you have to do is place your central element aligned with the Z axis, and this behavior will be automatic.
If the app involves your user moving around a 360° environment with no strong notion of which way is "forward" (for example, StreetView), then on recenter your app must preserve the user’s orientation with respect to the environment at the time of the recenter. When the user starts the recenter operation, the app should compute the offset needed to correct the controller’s position, and then, before drawing the next frame, rotate the environment by said offset. From the user’s perspective, the controller is now recentered and their orientation with respect to the environment hasn’t changed. That is, the object that was in front of the user before the recenter is the same object that is in front of the user after the recenter.
UX-D7: App's forward direction is consistent with the platform's global forward direction
When the user recenters by long-pressing the Home button, the controller and home UI should be oriented to respect the system-wide global north.
This means that, after a recenter, the "forward" direction in your app should coincide with the system-wide global forward direction, which is where the Daydream app's menu is rendered. To test if this is the case, recenter and face your app's "forward" direction, then single-click the Home button to return to Daydream. You should see the Daydream launcher menu directly in front of you. If it's off to the side or behind you, it's because your "forward" direction is not correctly matching the system's global forward direction.
UX-D8: App uses a neck model
Apps should use the default neck model that the SDK provides. If you are creating an Unreal or Unity application, this will be done automatically.
The neck model must be present when appropriate, but there are some instances where you will want to disable the neck model, such as when viewing spherical videos. There are also instances where you may want to override the existing neck model to modify it, for instance if you have decided to render a visible avatar.
UX-D9: App never goes to 2D unexpectedly
When in VR, your app should never display any 2D images. These might include permissions dialog boxes, splash screens, hardware volume control sliders, and dialog boxes controlled by other software on the device. See the example below.
While Daydream apps are expected to be entirely standalone and self-contained experiences, there are a few cases where you may have to transition users from inside of VR to your 2D monoscopic app, and then back again.
This is meant to be a very rare occurrence, and only for a small set of circumstances. One reason might be needing to prompt the user to accept a dangerous permission. Unfortunately, currently dangerous permissions can only be accepted with 2D monoscopic dialog boxes. This won’t be addressed with in-VR dialog boxes until the next version of Android. Another reason might be displaying a webview, for a login process with a third party that requires the web.
When making this transition, your app must do the following:
- Prompt the user to remove their phone.
- Detect the orientation change to portrait to switch over to 2D.
- Provide the user with a button to return them to VR.
We recommend that you return the user to nearly the same state in VR that they were in before they removed their phone, so that the transition feels more seamless.
UX-C1: Controller must be used as a laser pointer when clicking on UI targets
Apps are required to use the Daydream controller as a laser pointer when interacting with traditional UI controls, such as menu screens, pause screens, and any other situation where you have a 2D interface panel floating in space in front of the user for them to click on. This criterion does not affect the gameplay of your application, which can involve aspects of head gaze.
When interacting with UI elements, several specific behaviors of the controller must be consistent across applications:
- Use an arm model.
- Lower the laser ray an additional 15°
- (Recommended) Render the controller in the scene
- (Recommended) Display a laser ray.
Use an arm model
Note that an arm model is designed for general pointing (not throwing or hitting) and bringing the controller closer to view tooltips placed on it.
Lower the laser ray an additional 15°
This is important for consistency between the OS and applications, and for the user to be able to maintain muscle memory without having to compensate for variations when they move between applications.
(Recommended) Render the controller in the scene
While not a requirement, we recommend that you leverage our official 3D model of the controller when users are interacting with UI elements in your application. Advantages of rendering the controller in scene include:
- Greater sense of presence by bringing an element of the real world into VR.
- Provides an opportunity for tooltips/instructions on controller buttons.
- Helps to remind the user what buttons are available.
- Provides visual feedback on button presses.
- Leverages consistency across the platform.
(Recommended) Display a laser ray
The benefits of the laser are:
- Faster to notice and follow than just a cursor.
- Best way to communicate the angle of the ray and help with the intuitive feel of how the orientation of the controller input affects the ray.
- Realtime feedback.
- After using another interaction mode (driving, flying, rolling), showing the laser is a clear indication that the interaction mode has changed to ray-based UI input.
UX-C2: App uses hand preference
Daydream has a system-level preference for whether the user is right or left handed. When using an arm model in your application, you must respect this user preference. Additionally, your app should not expose custom UI controls for changing this preference only in the context of your app.
UX-C3: Scrolling through large sets of items must be done by swiping on the touchpad
In cases where there are large scrollable sets of items, such as YouTube video search results, we require scrolling by swiping on the touchpad of the Daydream controller.
UX-C4: Cursor displays at the same depth as objects being targeted
If the Daydream controller is casting a cursor out into the scene, render it at the same distance as objects that it is appearing over. If your app does not do this, and the cursor and object are drawn at different distances, the user will either get double vision of the cursor, or double vision of the object, depending on the one that they are visually focusing on at any given time.
UX-C5: App does not interfere with system controls
The app must not interfere with the functionality of the home and volume buttons on the controller.