WebXR: entrare nella realtà virtuale con un link

Ricevi un link. Lo apri e, invece di leggere soltanto una descrizione, puoi osservare uno spazio, scegliere dove andare e avvicinarti ai dettagli. Con un visore compatibile, quello stesso progetto può offrire anche un’esperienza immersiva.

Per chi deve presentare un immobile, mostrare un prodotto o far provare uno scenario, il primo vantaggio è molto concreto: rendere più semplice l’incontro tra la persona e il contenuto. L’accesso dal browser evita, in questi casi, l’installazione di un’app dedicata. Ma aprire una scena 3D sul telefono e trovarsi dentro quella scena con un visore sono due esperienze diverse.

Che cos’è WebXR, in parole semplici

WebXR è l’insieme di interfacce web con cui un’applicazione può accedere alle capacità dei dispositivi di realtà virtuale e aumentata. È il collegamento tra il contenuto nel browser e funzioni come la posizione del visore o gli input disponibili. La specifica WebXR Device API del W3C è attualmente una Candidate Recommendation Draft: un lavoro di standardizzazione in corso, non una garanzia che ogni funzione sia disponibile ovunque.

Una scena tridimensionale può essere visualizzata anche su un normale schermo. WebXR permette di aggiungere una modalità immersiva quando il sistema la supporta. Il browser deve verificarne la disponibilità; l’avvio della sessione richiede un’azione esplicita della persona, normalmente un pulsante. Il contenuto resta da progettare: ambienti, interazioni, istruzioni e obiettivi non vengono creati automaticamente dalla tecnologia.

Un contenuto, tre modi di esplorarlo

Prima di scegliere il formato conviene descrivere cosa farà la persona. Deve consultare un dettaglio, comprendere la distribuzione di una stanza oppure esercitare una scelta? Le modalità di accesso possono convivere, ma ciascuna va progettata e provata.

Anche un tour panoramico a 360° e un ambiente 3D navigabile hanno caratteristiche differenti. Per approfondire questa distinzione, abbiamo preparato la guida Virtual tour 360 o realtà virtuale: quali sono le differenze?.

La compatibilità si verifica sul dispositivo reale

“Funziona sul web” è una promessa troppo generica. Bisogna indicare quali dispositivi sono stati provati, con quale browser e per quali attività. La documentazione di Meta Quest Browser raccomanda di verificare a runtime le singole funzioni e il supporto WebXR prima di proporre una sessione immersiva.

Un esempio aiuta a capire il problema: WebKit documenta il supporto alle sessioni immersive-vr in Safari 18 su visionOS 2. La piattaforma conta: questo annuncio non dimostra che lo stesso progetto funzioni in VR su tutti i dispositivi che usano Safari. Non pubblichiamo quindi una lista universale di compatibilità: va verificata rispetto alla versione e alle funzioni del progetto.

Chiedi una prova sul dispositivo che utilizzerai, includendo apertura del link, ingresso nell’esperienza, navigazione e uscita. È una verifica più utile di un elenco di loghi. Controlli con controller, mani o altri input devono essere concordati: non sono intercambiabili per il solo fatto di usare WebXR.

Quando il browser è una scelta interessante

Il browser può essere adatto quando la priorità è far raggiungere il contenuto a persone diverse con pochi passaggi. Pensiamo a tre possibili brief di progetto, non a funzioni già presenti in ogni prodotto R.E.N.E.E.

• Presentazione di spazi: un collegamento a un ambiente esplorabile da condividere prima di un incontro o di una visita.
• Dimostrazione di un prodotto: osservare configurazioni e dettagli, affiancando al modello descrizioni e materiali utili.
• Scenario formativo circoscritto: introdurre una situazione, proporre alcune interazioni e discutere le scelte con un formatore.

Altri requisiti possono orientare verso un’applicazione dedicata o una soluzione diversa: integrazioni specifiche, gestione di un parco visori, uso senza rete, scenari complessi o funzioni hardware particolari. La scelta richiede una prova tecnica sul contesto d’uso. WebXR non determina da solo costi, tempi o qualità; ridurre i passaggi di accesso non significa eliminare il lavoro di progettazione.

Una buona demo deve essere fluida e comprensibile

Una scena ricca di dettagli può essere piacevole da guardare e difficile da utilizzare. Nel nostro criterio progettuale, il primo controllo riguarda il compito: la persona capisce dove si trova e cosa può fare? Il secondo riguarda la continuità dell’esperienza: caricamenti, risposta dei comandi e leggibilità vanno osservati sul dispositivo previsto, con una connessione rappresentativa.

Il peso dei modelli e delle texture, la quantità di elementi mostrati e la complessità delle interazioni sono scelte da bilanciare. Una demo veloce sul computer di sviluppo non è una prova sufficiente per un visore o uno smartphone. Conviene concordare prima della consegna quali scene e operazioni verranno testate, invece di giudicare il progetto soltanto da un video.

Anche l’accessibilità richiede decisioni concrete. La nota XR Accessibility User Requirements del W3C raccoglie esigenze legate, fra le altre cose, a modalità alternative di input, orientamento, personalizzazione e sottotitoli. Non è una certificazione. È un riferimento utile per discutere quali persone e quali condizioni d’uso il progetto deve considerare.

Nella valutazione iniziale proponiamo di includere istruzioni brevi, un’uscita facile da trovare, tempi controllabili e contenuti equivalenti per chi non usa il visore. Non tutto si risolve rendendo più grande un pulsante: il percorso alternativo deve permettere di comprendere le informazioni essenziali.

Cinque domande prima di approvare il progetto

• Quale attività deve riuscire a svolgere la persona, e come riconosceremo che ci è riuscita?
• Quali combinazioni di dispositivo e browser saranno provate e mantenute?
• Cosa vedrà e potrà fare chi non entra in modalità immersiva?
• Come valuteremo caricamento, risposta dei comandi e chiarezza del percorso?
• Chi aggiornerà i contenuti e controllerà il funzionamento dopo le successive versioni dei browser?

Per un progetto pubblicato sul web, la specifica WebXR richiede un contesto sicuro: normalmente HTTPS. Le funzioni immersive coinvolgono inoltre autorizzazioni e dati del dispositivo, aspetti da esaminare nel progetto. Riferimento: W3C — WebXR Device API. Nel brief va chiarito se esistono account, report o raccolta di dati e quali informazioni servono davvero: il link è soltanto la porta d’ingresso.

Dall’accesso semplice a un’esperienza utile

Nel lavoro di R.E.N.E.E. partiamo da persone, contesto e obiettivo. Con HomeVerse affrontiamo la presentazione di immobili e spazi; con DE-ESCAPE la simulazione di scelte comunicative. Sono bisogni differenti, da cui possono nascere requisiti tecnici differenti. Questa guida non attribuisce automaticamente a entrambi i progetti una distribuzione WebXR.

Il valore di un’esperienza immersiva si riconosce quando qualcuno riesce a capire, esplorare o esercitare qualcosa che gli serve. Se il browser è il modo più adatto per raggiungere quell’obiettivo, WebXR merita di entrare nella valutazione. Il passaggio successivo è costruire una piccola prova sul contesto reale e usarla per decidere.