Show message when an experience is served over HTTP

[dmarcos]

I saw tons of confusion among devs and users that don't understand why a site is not entering VR over WebXR. We could show a message next or above the VR button to indicate that the content is served over HTTP and that VR mode is only available over HTTPS. @thedart76 @brendanciccone in case you're interested.

My crappy sketch:

[thedart76]

How about using a customisable modal, consistent with the "This Immersive Website requires access to your device motion sensors" one?

The modal would be displayed whenever the user clicks on the VR icon, but VR mode is not entered because the content is being served over HTTP.
Basically, it would show up if the enter-vr event is not fired after clicking on the VR icon.

[mkungla]

Why not to add disabled state to vr button when not served over https and have a (?) icon to trigger modal which can be customized?

I think that would be good new feature for component vr-mode-ui

[brendanciccone]

I like Marko’s idea quite a bit - I think the VR button should definitely have more than one state. A modal triggered by something would be great because it’s reusable for whatever.

…

On Dec 17, 2019, at 10:57 AM, Marko Kungla ***@***.***> wrote:  Why not to add disabled state to vr button when not served over https and have a (?) icon to trigger modal which can be customized? I think that would be good new feature for component vr-mode-ui — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[dmarcos]

• The VR button should be still active / enabled and will trigger fullscreen over HTTP
• I think a modal might be too intrusive because the experience is still completely functional in 2D mode. The goal of the bubble / message is just to inform the user / dev why VR mode is not working as expected.

[brendanciccone]

Do you think the bubble will be too small on mobile/smaller devices? 🤔

…

On Dec 17, 2019, at 11:31 AM, Diego Marcos ***@***.***> wrote:  The VR button should be still active / enabled and will trigger fullscreen over HTTP I think a modal might be too intrusive because the experience is still completely functional in 2D mode. The goal of the bubble / message is just to inform the user / dev why VR mode is not working as expected. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[thedart76]

...too intrusive because the experience is still completely functional in 2D mode...
Good point.

If you care about not cluttering the screen, another option could be to display the bubble/message only when the VR button is clicked (since you can't hover on it on mobile devices).

By doing so:
a) If the user/dev is unsuccessfully trying to enter VR mode, they would receive the solution to their problem.
b) If the user/dev simply wants to enjoy the experience fullscreen, they would be provided with an educational reminder.

[thedart76]

Not sure if you are trying to find an alternative solution to the bubble/message itself, instead, because you believe that it might not be the best option.

[MK-LucidWeb]

IMHO it feels like we force the UX down the throat of the developer. I agree with @davimello28 who said about the iOS 13 popup:

The DeviceMotion permission is something that the developer using the platform should deal with. It means that aframe itself should not be responsible to make this request.

Although, I think that we should do add the banner as an option to be inserted when aframe loads and use it in the exemples provided. This will help developers to get things done.

For example, in our build we use window.AFRAME_PRELOAD_OPTS to optionally declare some options before we load A-Frame (ie. disable the css). It's useful but maybe too complicated.

If this is to improve the development experience, can't we just get away with a fullscreen fallback and a warning in the console? Basically educate the developer without forcing any UX.

[dmarcos]

@mako-lw Notice that the device permission dialog is both CSS customizable or can be turned off all together with a single attribute: https://aframe.io/docs/1.0.0/components/device-orientation-permission-ui.html#sidebar

Nice defaults is one of the main A-Frame value propositions. Most devs tinkering with VR are not expected to know about the quirks and differences across browsers.

For the HTTP dialog. It’s the most common question I’ve been answering the last couple of months from both users and developers. Why A-Frame is not entering VR in Chrome? Why gyro is not working in Android / Safari? A hard to miss message will help clarify. If a site is served over HTTPS the message will stay out of the way. I’m leaning towards a modal dialog as @thedart76 @brendanciccone suggested either at load or when the enter VR is clicked

[thedart76]

Nice defaults is one of the main A-Frame value propositions. Most devs tinkering with VR are not expected to know about the quirks and differences across browsers.

I like this approach. Giving the devs the possibility to choose what to display sounds like a more modular and effective UX, ensuring different levels of assistance for both 1st-time/non-dev users and less-experienced WebXR devs.

Think of it like the default settings you find in many racing simulations video games: they set most (if not all) the driving assists ON; then it's up to you to customise the driving experience by turning ABS, TCS, Automatic Transmission, Breaking Line, and anything else OFF.