Return to site

Guidelines for WebVR Applications

A quick report after scanning through bunches of VR sites

After spending weeks examining through a bunch of VR sites, reading their code, and picking out ones that work well, I'd like to share some basic tips for what many WebVR applications could be improved.

Then let us know if you'd like to showcase your VR site in Supermedium! We'd also love to volunteer feedback, or test your application on headsets you might not have. Feel free to email us at [email protected].

Present VR Immediately on Page Load

Many VR sites are focused on the traditional 2D Web. Someone navigates to a page, waits for a loading spinner, clicks several buttons, and only then it enters VR mode. We need less 2D loading screens. Pages should also start loading their assets immediately versus waiting for a visibility change. On the VR Web, when someone is navigating from another VR site within the headset, we want to display VR content immediately. Often, I would get stuck in Steam or Oculus loading purgatory. It can be a black screen that says Loading. But just show anything.

Handle Link Traversal

Link traversal allows for us to remain in VR as we navigate from site to site. In the WebVR specficiation, the window emits a vrdisplayactivate event which the application should listen to and automatically enter VR. If we're using a library like A-Frame or currently the dev branch of three.js, this is automatically handled for us. Otherwise, our app should enter VR on the vrdisplayactivate event versus waiting for a user gesture.

Without handling this, if a user navigates to your VR application from another site, your application won't automatically enter VR, and the user is stuck in purgatory and forced to exit the headset. Don't rely solely on a 2D enter VR button.

Show the Hands

WebVR applications should support showing of the hands, even if they don't use them. We can show even just a cube or some particles, but being able to see your hands provides presence points. In A-Frame, it's a matter of adding two lines of HTML with the hand-controls component. In three.js, it's a matter of adding THREE.ViveController (which sort of supports Oculus).

Support the Major Headsets

For desktop, handle all the controllers, at least showing the pose. There is not as much to be done for mobile as it is just head-tracking. It is unfortunate though to have a WebVR experience be Oculus or Vive only, and then for us we have to flag some off for certain headsets. Most people don't have all the headsets to test on, but sometimes it's easy to add code and will probably most likely work (e.g., for A-Frame, have <a-entity vive-controls oculus-touch-controls windows-motion-controls>).

We are also happy to test your WebVR application on headsets that you don't have.

Add Audio

Add any form of audio. I've been downloading .mp3s from http://freemusicarchive.org/

and just dropping a single <audio autoplay> tag in the HTML. There are also other free sound resources online such as Free Sound or Facebook's Sound Kit. But anything is better than complete silence.

Don't be "Only Available on Chrome"

I've run into many VR sites that are Sorry, only available on Chrome. Browsers run on top of the same standards so it's confusing when I see this. It's been bad since VR on desktop Chrome was intermittently working for most of the year, and many of these sites now no longer work. For desktop WebVR, test on at least Firefox and Chrome Canary.

Reach Out to Us

We'd love to see the VR Web take off. You can reach out to us if you need any help or feedback on your WebVR applications at [email protected]. And of course, we'll continue providing support for A-Frame if that's framework of choice!

All Posts
×

Almost done…

We just sent you an email. Please click the link in the email to confirm your subscription!

OKSubscriptions powered by Strikingly