Could you advise what would be the best approach?
I want to remove WebVR from my project, but I’d still like to have the button and same functionality on non-XR browsers?
I think it’s nice to see and play around in VR even on a desktop browser, informing the user of its existence.
This is what I’m using at the moment and it’s exactly how I’d like it to behave:
Basically I want the vrHelper but using XR only because it’s deprecating?
Don’t use the VR helper, that would be my first recommendation
I need to understand the use case. Why would you want people with no XR-available browser to see that it is an XR experience? Marketing reasons? What happens if they click on the button? Do you expect it to fail or do nothing?
Yea, that’s what I’m trying to solve - give up on VR helped.
I think it’s useful to inform a user who casually browses the web on a laptop, to see that there is that button, and upon pressing it, there is a sort of VR function/experience, and not just a text prompt “VR available”.
Which VR helper does wonderfully. I can see it’s stereoscopic, I can see that it actually works, I might actually consider bookmarking the website to try it later when I get my hands on a headset, or send it to my friend who is a VR-fan, or share online.
There was this one time I showed it to a friend, and he immediatly pressed the button and stayed in VRhelper the whole time because he liked the fish-eye-edness. I was like, man that’s supposed to be for VR headsets… he didn’t care, was cool.
Since there is no reason to support stereoscopic camera we decided not to have it as a fallback in XR. XR supports devices that have XR enabled.
What you can do is detect XR yourself (using the session manager) and fallback yourself to a stereoscopic camera. You will need to add the button as well.
Sadly I have no better solution for you…
Okay, I guess you’re saying to “recreate” what VRhelped does already.
But don’t you agree there should be a way to show people (rather than telling) that XR/VR is available on whatever device they are on?
Isn’t it kind of abrupt to simply remove the button if XR is not supported?
I do understand XR is for XR devices, makes sense.
But from a user point of view it’s nice to see that the project supports it, that is configured, that it works. It would inspire the user to actually try it again on a headset.
Let’s dissect this a bit
- WebXR is supported in almost all browsers apart from safari (well, the big ones, at least). However it is not available if there is no device that supports WebXR connected to the device.
- The XR experience helper makes the assumption that if you use it you want it to work. So if someone presses the button, it will enter XR. if the button is pressed and no device is connected, well, that’s a failure of the framework to deliver the right experience.
- You, as a developer, can device to show anything you want on your web experience. So you can add any buttons you want, and have a callback attached to it that does whatever you think it should do.
- You can manually use the WebXR Enter/Exit UI and implement it the way you see fit. The experience helper is only a collection of helper functions that “connects” what we think should be the default experience of an XR application.
But it doesn’t, does it? From a UX point of view, putting a button that fails (for sure) is not a good idea. Saying that your app supports WebXR on supported devices would be the better approach, no?
We, as a framework, provide functionality. And we make certain expectations as to the environment in which your application is running. If you want to change that, we provide all tools for you to do that.
The VRHelper was implemented in different times. In times where google cardboard was a thing (and didn’t support WebXR or WebVR). this is the only reason to have a functioning stereoscopic camera. We have advanced since then (well, the web has). We now have a standard. and we adhere to the standard.
I am sorry this is not the answer you were looking for. But we will not change the functionality of the WebXR helper to fail on devices not supported. It’s like asking us to provide a fallback image on browsers that don’t support WebGL.
Ok, it does make sense.
It’s “my” decision what to do with unsupported XR devices, and not the frameworks.
Many thanks for clarifying it, really appreciate it.