Web VR UX and fullscreen on iOS

For today’s Cardboctober entry I wanted to go back to basics and try to improve the setup user experience for Web VR.

Setup UX

I’ve rewritten the code that manages the initial user experience, and I’m planning to release this as an open source package in the future.

The main goal for this was to make the experience quick, clear and device agnostic.

From the start I have always wanted to make sure people can choose how they view a VR experience. People may not have a VR viewer, or might not have a compatible phone so it’s important to be flexible. The first thing the user is asked is this:

This is largely the same as my original verison, but I’ve tweaked this to say “VR viewer” — as most people aren’t familiar with the the term “viewer”. I’ve added “Yes/No” text to help link the question to the choices and I’ve also added a desktop computer graphic next to the phone to make it less ambiguous for computer users.

If the user picks “Yes” here, I use this point to try to activate fullscreen mode (…unless they’re on iOS, I’ll get to that later). Otherwise I let the user decide whether they want to use fullscreen mode with a toggle button at the top of the screen.

If they are using a viewer, the next step is to check if the device is the right orientation, I show them a message asking the user to rotate their phone sideways, as soon as they do that the message changes:

This message is critical because it allows the user time to set up the viewer before starting the experience. The message has to be stereoscopic so they can still read it after putting the phone in the viewer. This is also a convenient way of telling the user the viewer has a button.

Fullscreen on iOS

Unfortunately iOS doesn’t support fullscreen mode, and while it normally hides the URL bar as the user scrolls, this doesn’t work on pages which are the height of the screen.

My solution was to make the page slightly larger than the screen, and then set the VR canvas as position: fixed, so the user can scroll without the content moving. The final step was to add a prompt for iOS users to swipe, we detect when they’ve swiped, and move on to the next step.

Conclusions

I’m really happy with the flow now, but I’ll need to test it out on more people and more devices to iron out the kinks.