Improvement: new value for reveal to allow users to display only the AR button

[hd-esteban]

In our case we already have some image galleries so the viewer is not needed since we just want to display the AR button to use that functionality if the mobile device is an AR candidate.

At te moment we're using the reveal='interaction' attribute, and we are hiding the poster until AR button is tapped , for that case if AR fails we're displaying it otherwise it keeps hidden for all the user interaction.

So would be great to have a new value for the reveal attribute, to allow us as users to decide if we just want to have the AR button functionality.

[cdata]

@Esteban26 we have talked about potentially adding a reveal="manual" mode, where the model will only be loaded and revealed if you (the content author) invokes a JavaScript API like modelViewer.reveal() or modelViewer.dismissPoster(). Does that sound suitable?

(I also mentioned this in https://github.com/GoogleWebComponents/model-viewer/issues/502#issuecomment-486856384)

[hd-esteban]

But for that case will the AR button be displayed?

As you can see on this screenshot, for that example we already have a viewer, that viewer was built with images so we don't need the model or poster to be displayed.

So, we just need the AR button to trigger the Scene viewer and if it fails then its ok if poster is displayed on fullscreen, but it should be hidden again when fullscreen is disabled.

[cdata]

Yes, in the case I described, the AR button will be displayed. It is always displayed on top of the poster.

If we can come up with a good event to signal that there are no external AR apps available (via #567), that event could be used as a signal to begin inline rendering.

[mikkoh]

For context sharing I'd like to bring up my suggestion of using playsinline #502

Although I think using something like reveal="manual" is extremely flexible it does add the extra constraint of having to write JS to handle this case where using something like AR Quicklook by default requires no knowledge of JS.

I'm still processing this stuff but to me it might make sense to handle this case through an html attribute or a combo of attributes.

playsinline came from iOS not rendering video inline in the page. It would open a native video player that you could not customize. I believe this was done for performance/ux reasons on early devices that were low power/resolution. playsinline was introduced to allow developers to allow video rendering inline as screen resolutions and device capabilities increased.

[hd-esteban]

Hi @mikkoh looks good, just one comment... we also had some problems with the ARQuickLook implementation, because they didn't allow us to modify/remove their AR button and our clients wanted to modify it, so it was a little tricky to create a custom AR button because they force us to use an image as an AR link. Hopefully , we were able solve that issue by creating an with the src attribute empty... but IMO that behavior should be extremely flexible so we can decide which element and event will open the AR view. What I think the easiest and flexible way to handle AR on ecommerce sites is to make public and document the Android Intent implementation you already have for the model-viewer / Scene viewer integration.