Il 31 agosto 2026 Runway ha annunciato Solaris, definendolo «il primo modello di una nuova famiglia di sistemi AI che chiamiamo Interface World Models». La promessa è vertiginosa: un’interfaccia che non viene scritta in codice e poi disegnata dal browser, ma generata direttamente, fotogramma dopo fotogramma, mentre l’utente ci interagisce. Niente HTML, niente CSS, niente JavaScript come rappresentazione intermedia. Il modello dipinge lo schermo e, nello stesso gesto, decide come lo schermo risponde al clic.
Da qui alla domanda che campeggia in ogni commento, è la fine dell’HTML?, il passo è breve. È anche, come vedremo, un passo sbagliato. Questa guida usa Solaris come caso di punta per capire una categoria più larga e più duratura: la generative UI, cioè le interfacce generate in tempo reale da un modello invece che composte da componenti scritti a mano. È una categoria che nel 2026 ha smesso di essere speculazione: Google DeepMind, Runway e diversi laboratori ci hanno messo dentro modelli funzionanti. Ed è una categoria che arriva, con un tempismo notevole, proprio nell’anno in cui il web ha superato una soglia storica: la maggioranza delle richieste HTTP verso contenuti HTML non viene più da esseri umani.
Una premessa di onestà, perché conta. Solaris è in early access chiuso, su modulo di richiesta. Non ha API pubbliche, non ha prezzi, non ha una data di uscita, e nessuno in redazione ha potuto provarlo. Quello che segue non è una recensione: è la ricostruzione di come funziona la categoria, di cosa è stato effettivamente misurato, e di cosa cambia, davvero, per chi progetta e sviluppa interfacce.
In questo articolo scoprirai:
- Che cos'è un interface world model, spiegato senza giri di parole
- Come nasce oggi un'interfaccia: il percorso dal codice ai pixel
- Generazione frame per frame: cosa Runway ha misurato davvero su Solaris
- «La fine dell'HTML»: perché la domanda è posta male
- Interfacce generate e screen reader: la lezione del canvas di Google Docs
- Perché i bot al 57,2% del traffico HTML cambiano il calcolo
- Perché addestrare gli agenti dentro mondi generati al volo
- Da dove arriva Solaris: Gen-4.5, GWM-1 e la genealogia dei modelli
- Solaris, GWM-1 e Genie 3 a confronto: disponibilità, accesso e prezzi
- Cosa conviene fare adesso, se progetti o sviluppi interfacce
Che cos’è un interface world model, spiegato senza giri di parole
Un interface world model è un modello generativo che produce l’interfaccia come sequenza di fotogrammi, gestendo insieme due cose che oggi sono separate: il rendering (cosa appare sullo schermo) e la risposta agli input (cosa succede quando l’utente clicca, scorre, digita). Non esiste un file HTML da qualche parte che descrive il pulsante. Esiste un modello che, dato lo stato precedente e l’azione dell’utente, predice il fotogramma successivo, e in quel fotogramma il pulsante risulta premuto.
La formulazione di Runway è precisa su questo punto: Solaris «genera l’interfaccia stessa, fotogramma dopo fotogramma», eliminando la rappresentazione intermedia in codice. È la differenza fra uno spartito e un’improvvisazione. Nel modello classico, il codice è lo spartito: esiste prima, è ispezionabile, è deterministico, e l’esecutore (il browser) lo interpreta allo stesso modo ogni volta. In un interface world model non c’è spartito. C’è un esecutore che ha ascoltato milioni di ore di musica e continua a suonare in modo plausibile.
Questa plausibilità è il punto tecnico centrale, ed è anche il limite strutturale. Il modello non sa che quel rettangolo è un pulsante: sa che, statisticamente, dopo un clic su un rettangolo di quell’aspetto arriva un fotogramma in cui il rettangolo è schiacciato e sotto compare una nuova schermata. La coerenza non è garantita da una regola, è emersa dall’addestramento.
Interface world model e world model: che differenza c’è
I world model, i cosiddetti modelli del mondo, sono un filone di ricerca che punta a far imparare a un sistema una rappresentazione interna dell’ambiente, fisica, geometria, causalità, abbastanza buona da poterci simulare dentro. Genie 3 di DeepMind genera mondi navigabili in prima persona; GWM Robotics di Runway genera scene per la manipolazione robotica.
Un interface world model applica la stessa idea a un ambiente molto particolare: non una stanza o una strada, ma lo schermo di un software. Le leggi da imparare non sono la gravità e l’occlusione, ma le convenzioni delle interfacce: i menu a tendina si aprono verso il basso, i campi di testo mostrano un cursore lampeggiante, un carrello che riceve un articolo incrementa il contatore. È un dominio più povero di fisica e molto più ricco di convenzioni arbitrarie, il che lo rende, per certi versi, più facile da simulare e molto più facile da sbagliare in modo vistoso.
Come nasce oggi un’interfaccia: il percorso dal codice ai pixel
Per capire cosa Solaris salta, bisogna sapere con precisione cosa c’è nel percorso attuale. Vale la pena ricostruirlo, perché quasi tutte le discussioni sulla «fine dell’HTML» lo trattano come un unico blocco indistinto, mentre è una catena di passaggi con funzioni diverse.
Il browser riceve HTML e lo trasforma in un DOM, una struttura ad albero in cui ogni nodo è un elemento con un significato dichiarato: questo è un titolo, questo è un link, questo è un campo obbligatorio. Riceve il CSS e costruisce in parallelo il CSSOM, le regole di presentazione. I due alberi si combinano nel render tree, che contiene solo ciò che è visibile. Segue il layout, che calcola posizione e dimensione di ogni scatola; poi il paint, che riempie i pixel; poi il compositing, che sovrappone i livelli. JavaScript, nel frattempo, può modificare il DOM in qualsiasi momento, e ogni modifica fa ripartire la parte di catena necessaria.
Descritta così, la catena sembra puro overhead, ed è esattamente l’impressione che alimenta l’entusiasmo per la generazione diretta. Ma quella catena produce molto più dei pixel.
Il ramo che quasi nessuno disegna: dal DOM all’accessibility tree
Dal DOM si dirama un secondo albero, che non finisce mai negli schemi che circolano sui social: l’accessibility tree. La documentazione di MDN lo descrive come una struttura che i browser costruiscono a partire dal DOM e che alimenta le API di accessibilità del sistema operativo. Ogni nodo porta quattro proprietà fondamentali: name (come ci si riferisce all’elemento), description (informazioni estese), role (che tipo di cosa è: pulsante, barra di navigazione, lista) e state (spuntato o no, espanso o collassato). Più l’informazione su cosa si può fare con quell’elemento: un link si può seguire, un campo di testo si può riempire.
Questo albero non contiene alcuna informazione visiva: né colori, né font, né posizioni. Contiene solo struttura e significato. Ed è quello che consumano gli screen reader, i display braille, i sistemi di controllo vocale e, questo è il punto che torna più avanti, gli agenti software.
Come spiega A List Apart ricostruendo la catena completa, l’informazione passa dal markup al motore di rendering, alle API di accessibilità della piattaforma (UIA su Windows, NSAccessibility su macOS, AT-SPI su Linux), fino alla tecnologia assistiva: «un pulsante è un pulsante è un pulsante, per quanto riguarda le tecnologie assistive», che sia in una pagina web o nella barra di un’applicazione nativa. L’HTML non è un formato di disegno: è un contratto semantico, e il rendering è solo uno dei suoi consumatori.
Generazione frame per frame: cosa Runway ha misurato davvero su Solaris
Runway ha pubblicato numeri, ed è più di quanto facciano molti annunci. Vale la pena leggerli con attenzione, perché dicono cose precise e non dicono altre cose altrettanto precise.
Sul fronte tecnico, la pagina di lancio indica 720p come risoluzione di riferimento e colloca la soglia critica della latenza con una frase che è quasi una definizione di prodotto: «le interazioni smettono di sembrare interattive intorno al mezzo secondo di ritardo». È una soglia onesta e verificabile nell’esperienza di chiunque: sotto i 500 millisecondi il nesso causa-effetto regge, sopra si rompe e l’utente inizia a cliccare due volte. Solaris è costruito sul modello video Gen-4.5 e, nelle parole di Runway, «segue il percorso aperto con GWM-1».
Sul fronte della valutazione, Runway ha condotto uno studio con esseri umani: 250 partecipanti, 30 esempi di interazione e quasi 7.500 giudizi a coppie. I risultati riportati sono due. Sul seguire le istruzioni, le interfacce generate da Solaris sono state preferite nel 61% dei confronti contro il 24% delle interfacce scritte in codice. Sulla naturalezza del comportamento, 71% contro 21%.
Che cosa dimostrano (e cosa non dimostrano) i numeri 61% e 71%
Sono numeri buoni e vanno presi sul serio. Ma vanno letti per quello che sono: giudizi di preferenza soggettiva su 30 esempi, espressi da valutatori che guardano. Non sono tassi di completamento di un compito, non sono misure di correttezza funzionale, non sono test su sessioni lunghe. La differenza è sostanziale. Un’interfaccia può essere preferita perché è più bella, più fluida, più «naturale» nell’animazione, e allo stesso tempo portare l’utente a sbagliare l’ordine o a perdere i dati inseriti.
C’è poi un’asimmetria nel confronto che conviene notare: il termine di paragone sono «interfacce scritte in codice» prodotte per quegli stessi 30 esempi. La qualità di quel baseline decide metà del risultato, e non è documentata pubblicamente. Questo non invalida lo studio, è un protocollo ragionevole per una ricerca in fase iniziale, ma impedisce di trasformarlo nella frase che sta circolando, cioè «le interfacce generate sono migliori di quelle programmate». Quello che è stato misurato è che, su una trentina di scenari, delle persone che guardavano hanno preferito il risultato del modello. È un ottimo punto di partenza e non è una prova di superiorità funzionale.
Infine, ciò che Runway non ha dichiarato: nessun frame rate, nessun numero di parametri, nessuna informazione sui dati di addestramento, nessun costo per frame, nessun benchmark comparativo con altri world model. Su questi punti l’unica risposta corretta è che non si sa.
«La fine dell’HTML»: perché la domanda è posta male
Arriviamo al cuore. L’ipotesi implicita in quella domanda è che l’HTML serva a far apparire le cose sullo schermo. Se è così, un modello che fa apparire le cose sullo schermo senza HTML lo rende superfluo. Il sillogismo funziona, tranne che per la premessa, che è falsa.
L’HTML produce quattro cose contemporaneamente, e il rendering è solo la prima. Produce la semantica che alimenta l’accessibility tree e quindi ogni tecnologia assistiva. Produce la struttura indicizzabile che motori di ricerca e sistemi di risposta AI leggono per capire di cosa parla una pagina. Produce la superficie di automazione su cui lavorano estensioni, script, strumenti di test e agenti. E produce uno stato ispezionabile: si apre il pannello sviluppatore, si vede esattamente cosa c’è, e si può dimostrare perché il sistema si è comportato in un certo modo.
Un modello che genera pixel sostituisce il primo dei quattro. Gli altri tre non li sostituisce: li fa sparire. E la differenza fra «sostituire» e «far sparire» è tutta la sostanza della questione.
Solaris e il ruolo di HTML, CSS e JavaScript
La risposta breve, allo stato attuale delle informazioni pubbliche: no, e Runway stessa non lo afferma nei termini in cui è stato raccontato. Quello che Runway afferma è che il modello genera l’interfaccia senza usare il codice come rappresentazione intermedia. È una frase sull’architettura interna del sistema, non una previsione sulla scomparsa del web.
La risposta lunga è più interessante. Esistono contesti dove l’assenza di semantica non costa quasi nulla: una demo, un prototipo da mostrare a uno stakeholder, un ambiente di gioco, una simulazione usata per addestrare un agente. Ed esistono contesti dove costa tantissimo: un servizio pubblico, un e-commerce, una banca, qualunque prodotto soggetto a obblighi di accessibilità, qualunque pagina che debba essere trovata. La generative UI non arriverà come un’ondata uniforme: arriverà prima dove la semantica non serve, e potrebbe non arrivare mai dove serve, a meno di reintrodurre esattamente ciò che dichiara di eliminare. Che è, storicamente, quello che è già successo.
Interfacce generate e screen reader: la lezione del canvas di Google Docs
Non è una domanda ipotetica, perché il web ha già fatto questo esperimento. Nel 2021 Google ha annunciato il passaggio di Google Docs dal rendering basato su DOM a quello basato su canvas: invece di comporre il documento con elementi HTML, Docs lo «dipinge» su una tela. Le motivazioni erano legittime e tecnicamente solide, come riportava The New Stack il 24 maggio 2021, un word processor online ha «requisiti estremamente specifici di layout, rendering e aggiornamento incrementale» che il DOM fatica a soddisfare, con problemi noti su cose come l’evidenziazione di testo bidirezionale misto.
Il parallelo con Solaris è quasi esatto: si abbandona il markup per ottenere controllo, prestazioni e coerenza sul risultato visivo. E il risultato di quell’esperimento è documentato.
Google ha dovuto costruire un «side DOM»: un albero HTML nascosto, invisibile, mantenuto in parallelo al canvas, con ARIA live regions e l’Accessibility Object Model, al solo scopo di parlare con gli screen reader. In altre parole: per rendere accessibile un’interfaccia dipinta, è stato necessario ricostruire il markup che si era appena eliminato. WebAIM, che ha testato il prototipo, è stata netta: «i nostri test hanno rivelato un supporto solo rudimentale alle tecnologie assistive, e ci hanno portato a concludere che serviranno miglioramenti significativi». La loro conclusione generale è la lezione da portarsi via: l’accessibilità deve stare nelle fondamenta di un progetto, non essere aggiunta dopo.
Cosa chiede la WCAG a un’interfaccia che non ha markup
Le Web Content Accessibility Guidelines, nella versione 2.2 pubblicata il 5 ottobre 2023 e aggiornata il 12 dicembre 2024, organizzano 13 linee guida attorno a quattro principi: percepibile, utilizzabile, comprensibile e robusto. È l’ultimo a essere decisivo qui: robusto significa che il contenuto deve funzionare in modo affidabile con tecnologie diverse, comprese quelle assistive, presenti e future.
Un flusso di pixel generato al volo è, per costruzione, il contrario della robustezza così intesa. Non espone ruoli, non espone stati, non espone nomi accessibili; e il fotogramma successivo non è garantito identico a quello di ieri. Il problema non è che sia difficile renderlo conforme: è che la conformità richiede una rappresentazione semantica stabile, e la rappresentazione semantica stabile è precisamente ciò che l’architettura ha rimosso. Qualunque soluzione passerà da un side DOM, cioè da un ritorno del markup nel ruolo che non aveva mai smesso di avere. Per chi lavora in Europa, dove il quadro regolatorio su accessibilità digitale e sistemi di AI si è fatto più stringente, questo non è un dettaglio filosofico ma un vincolo di progetto.
Il web è già per metà abitato dalle macchine: perché gli agenti leggono il markup, non i pixel
C’è un secondo argomento, meno discusso del primo e forse più dirimente, e riguarda chi visita le pagine. Secondo i dati di Cloudflare Radar citati da Search Engine Journal, nella settimana fra il 30 maggio e il 5 giugno 2026 il 57,2% delle richieste HTTP verso contenuti HTML proveniva da bot automatici, contro il 42,8% di esseri umani. La soglia della maggioranza è stata superata con circa un anno di anticipo sulle previsioni di settore.
E qui sta il paradosso. Gli agenti software che navigano il web non guardano i pixel: leggono l’accessibility tree. Per due ragioni entrambe pratiche. La prima è economica: gli screenshot consumano quantità rilevanti di token per essere interpretati da un modello visivo, mentre «l’accessibility tree è testo compatto». La seconda è di affidabilità: l’albero dichiara esplicitamente che quell’elemento è un pulsante e cosa fa, mentre «un modello visivo deve indovinare quali pixel formino un controllo cliccabile».
Un’interfaccia generata frame per frame offre agli agenti soltanto pixel. Li costringe cioè, proprio nel momento in cui diventano la maggioranza del traffico, a tornare al metodo più costoso e meno affidabile a disposizione.
Generative UI e AI visibility: cosa succede a una pagina che non emette semantica
Lo stato dell’arte, del resto, non è incoraggiante nemmeno senza world model. I dati del report WebAIM Million di febbraio 2026, ripresi da Search Engine Journal, rilevano errori di accessibilità sul 95,9% delle home page analizzate, con una media di 56,1 errori per pagina, in crescita del 10,1% rispetto ai 51 dell’anno precedente. Nel dettaglio: link vuoti nel 46,3% dei casi, pulsanti vuoti nel 30,6%, etichette di form mancanti nel 51%, testo alternativo assente nel 53,1%.
L’osservazione più acuta dell’analisi di Search Engine Journal è che un attributo vuoto o sbagliato «non lascia l’accessibility tree vuoto: lo riempie di informazioni sicure di sé e potenzialmente errate, il che per un agente è peggio di una lacuna onesta». Visitatori umani e visitatori automatici inciampano sullo stesso ostacolo.
Per chi ragiona in termini di visibilità sui motori e sui sistemi di risposta AI, la conseguenza è diretta: una pagina che non emette struttura semantica non è male indicizzata, è invisibile allo strato di software che sta rapidamente diventando il lettore prevalente. Adottare un’interfaccia generata senza uno strato semantico parallelo significa scegliere, consapevolmente, di uscire da quel circuito.
Perché addestrare gli agenti dentro mondi generati al volo
Runway indica un secondo uso di Solaris, e a nostro avviso è quello dove la tecnologia ha oggi il caso d’uso più solido: addestrare agenti AI in ambienti dinamici, con esempi come prenotare un hotel o ordinare la spesa.
L’idea non è nuova ed è bene sapere da dove viene. Nel 2018 David Ha e Jürgen Schmidhuber pubblicarono World Models, il lavoro che ha dato il nome al filone. L’architettura era a tre componenti, Vision (un autoencoder variazionale che comprime le osservazioni), Memory (una rete ricorrente che predice il futuro nello spazio latente) e Controller (un modello lineare minimale), ma il risultato memorabile era un altro, riassunto nell’abstract: «possiamo perfino addestrare il nostro agente interamente dentro l’ambiente onirico generato dal suo world model, e trasferire questa politica nell’ambiente reale». Su VizDoom, l’agente addestrato solo nel sogno otteneva 1.092 ± 556 contro una soglia di 750; su CarRacing-v0 arrivava a 906 ± 21, contro i 591-652 dei metodi precedenti. L’idea che un agente possa imparare dentro una simulazione generata dal modello stesso ha otto anni e funziona. Solaris la applica a un ambiente nuovo: lo schermo.
Il problema degli ambienti di training: i numeri di OSWorld 2.0
Perché serva, lo dicono i benchmark. OSWorld 2.0 valuta agenti su flussi di lavoro reali e di lungo respiro, distribuiti su 31 servizi web self-hosted e applicazioni desktop. La differenza di scala rispetto alla versione precedente è drastica: il compito mediano richiede circa 1,6 ore di lavoro attivo a un utente umano esperto, quarantotto volte i due minuti mediani di OSWorld 1.0, e circa il 70% dei compiti supera l’ora.
I risultati sono impietosi e istruttivi. Il sistema migliore, Claude Opus 4.8 con thinking al massimo, completa il 20,6% dei compiti in valutazione binaria (54,8% come punteggio parziale) entro un budget di 500 passi; GPT-5.5 si ferma al 13,0%. Gli autori individuano il tipo di fallimento: gli agenti «lasciano cadere vincoli dichiarati, mancano informazioni che arrivano a metà compito, tirano a indovinare invece di chiedere all’utente» e saltano la verifica. Dedicano meno del 7% del budget a rilevare e riparare i propri errori. Il problema non è il controllo dell’interfaccia: è mantenere lo stato nascosto lungo sessioni lunghe.
Perché mancano ambienti di addestramento per gli agenti AI
E qui emerge il vincolo che rende attraente la generazione di ambienti: come scrivono gli autori di OSWorld 2.0, i flussi di lavoro reali «sono raramente condivisi pubblicamente, perché coinvolgono spesso dati sensibili, toolchain proprietarie o convenzioni specifiche di dominio». Gli ambienti di addestramento sono scarsi perché il lavoro vero è riservato. Un modello che genera interfacce plausibili a volontà aggira il collo di bottiglia, con l’avvertenza, tutt’altro che secondaria, che un agente addestrato su interfacce verosimili impara le regolarità di quelle interfacce, non quelle del software reale.
Da dove arriva Solaris: Gen-4.5, GWM-1 e la genealogia dei modelli generativi
Solaris non nasce dal nulla: è l’ultimo anello di una catena tecnologica precisa, e ricostruirla aiuta a stimare quanto sia maturo.
Alla base c’è la generazione video. I modelli che hanno imparato a produrre sequenze di fotogrammi coerenti, la stessa famiglia a cui appartengono Sora e il suo successore Sora 2, e per Runway la linea Gen-4, hanno dovuto sviluppare, per forza di cose, una rappresentazione implicita di come le cose si muovono e persistono. È il motivo per cui i modelli video si sono rivelati la base naturale dei world model: chi sa predire il fotogramma successivo ha già imparato qualcosa sulla struttura del mondo.
Se questo meccanismo di predizione non vi è familiare, conviene partire da come funziona l’intelligenza artificiale generativa e da cosa accade dentro un modello dal testo che entra alla risposta che esce: la logica è la stessa, cambia solo l’oggetto predetto.
Dal video generato al mondo navigabile: cosa cambia nell’architettura
Il salto dal video al world model è l’action conditioning. Un modello video genera una sequenza decisa in partenza; un world model genera il fotogramma successivo condizionato da un’azione che arriva in tempo reale dall’esterno. È la differenza fra un film e un videogioco, ed è una differenza architetturale, non di grado.
GWM-1, presentato da Runway l’11 dicembre 2025, è il passaggio intermedio: un modello autoregressivo costruito su Gen-4.5, a 720p, per sequenze fino a due minuti, condizionato su posa della camera, comandi robotici, eventi e voce. Esiste in tre varianti post-addestrate separatamente, GWM Worlds per ambienti esplorabili, GWM Avatars per personaggi conversazionali, GWM Robotics per la manipolazione robotica, che Runway dichiara di voler unificare. L’analisi indipendente di The Batch aggiunge il dettaglio dei 24 fotogrammi al secondo a 1280×720 e lo qualifica come «modello di diffusione autoregressivo basato su Gen-4.5», notando anche che Runway non ha divulgato numero di parametri, dati e metodi di addestramento, prezzi, date di rilascio né metriche di performance.
Solaris, per ammissione di Runway, «segue il percorso aperto con GWM-1». La sequenza è quindi: generazione video, poi mondi navigabili condizionati dall’azione, poi interfacce. L’interfaccia è trattata come un ambiente fra gli altri.
Solaris, GWM-1 e Genie 3 a confronto: cosa sappiamo e cosa Runway non ha detto
La domanda ricorrente è in cosa differiscano i tre modelli che occupano questo spazio. Le differenze sono nette e riguardano l’ambiente simulato più che la tecnologia.
Genie 3, annunciato da Google DeepMind il 5 agosto 2025, genera mondi fisici navigabili da una descrizione testuale, a 720p e 24 fps, «largamente coerenti per diversi minuti», con una memoria visiva che «si estende fino a un minuto indietro». Include i promptable world events, che permettono di cambiare il mondo in corsa, il meteo, nuovi oggetti, nuovi personaggi, ed è stato testato con l’agente SIMA che invia azioni di navigazione al modello.
DeepMind è notevolmente esplicita sui limiti, e sono limiti che conviene tenere a mente anche leggendo Solaris: la gamma di azioni eseguibili dagli agenti è «attualmente limitata»; modellare le interazioni fra più agenti indipendenti è «una sfida di ricerca ancora aperta»; il modello non riproduce luoghi reali con accuratezza geografica; e, dettaglio rivelatore per chiunque pensi alle interfacce, «il testo chiaro e leggibile viene generato spesso solo quando è fornito nella descrizione del mondo in input». Un modello che fatica a produrre testo leggibile in modo affidabile ha un problema non banale con le interfacce, che di testo sono fatte.
GWM-1 sta nel mezzo: ambienti, avatar e robotica, due minuti, 24 fps. Solaris si specializza sullo schermo, ed è l’unico dei tre per cui Runway abbia pubblicato uno studio di preferenza umana strutturato.
Solaris: disponibilità, accesso, prezzi e data di uscita
Allo stato attuale, Solaris non è disponibile pubblicamente. Runway dichiara di «lavorare con partner chiave per lanciare Solaris pubblicamente» e ha aperto un modulo di richiesta di accesso anticipato sulla pagina dell’annuncio. È l’unica via di accesso comunicata.
Su tutto il resto la risposta corretta è: non è stato dichiarato. Non esiste un prezzo pubblico, né un modello di pricing indicato anche solo per grandi linee. Non esiste una data di rilascio. Non esiste documentazione di API pubbliche. Non è stato comunicato il frame rate di Solaris, né il costo computazionale per fotogramma, né i termini di licenza per uso commerciale. Chi vi propone stime su questi punti le sta deducendo, non riportando. Nel dubbio, la fonte primaria è una sola ed è la pagina di annuncio di Runway.
Cosa conviene fare adesso, se progetti o sviluppi interfacce
La reazione sbagliata a Solaris è entrambe quelle che si vedono in giro: liquidarlo come demo e ignorarlo, oppure annunciare la fine del mestiere. Ecco una lettura più utile, divisa per orizzonte, con la stessa avvertenza che vale per ogni tecnologia generativa in azienda, dove il divario fra promessa e ritorno economico nasce quasi sempre dal processo, non dal modello.
Nel breve, la generative UI che si può spedire oggi non è quella di Solaris: è quella a livello di componente, in cui un modello sceglie e compone elementi di un design system esistente in base al contesto dell’utente. Il markup resta, la semantica resta, l’accessibilità resta, e il modello decide quale forma assuma la pagina. È molto meno spettacolare e molto più adottabile. Nielsen Norman Group definisce la generative UI come «un’interfaccia utente generata dinamicamente in tempo reale dall’intelligenza artificiale per fornire un’esperienza personalizzata sui bisogni e sul contesto dell’utente», una definizione che non impone affatto di abbandonare il codice.
E proprio NN/g solleva l’obiezione di usabilità che nessun benchmark cattura: «gran parte della comprensione che gli utenti hanno delle interfacce moderne è radicata negli standard di design», per cui «interfacce in continuo cambiamento causeranno problemi di usabilità». Il rischio è che «il continuo riapprendimento dell’interfaccia generi frustrazione», cancellando la memoria spaziale e la prevedibilità su cui si fonda l’efficienza di chi usa un software tutti i giorni. Un’interfaccia perfettamente adattata a ogni singolo utente è anche un’interfaccia che nessuno può imparare una volta per tutte, che nessuno può documentare e su cui nessun collega può darti indicazioni al telefono.
Le competenze su cui investire nella generative UI
Il mestiere che questa tecnologia sposta non è «scrivere CSS»: è definire i vincoli entro cui un sistema generativo può muoversi. NN/g lo dice chiaramente: i designer diventeranno «progettisti di parametri e vincoli», incaricati di far capire al sistema gli obiettivi dell’utente e del business attraverso guard rail e categorie di requisiti. È esattamente la competenza che serve anche per governare gli agenti, ed è il motivo per cui vale la pena guardare il quadro più ampio di quali competenze siano strategiche oggi invece di inseguire il singolo annuncio.
Le tre priorità pratiche: semantica, prototipi e criteri di progetto
Tre indicazioni concrete. Primo: la semantica è l’investimento con il rendimento più sicuro dei prossimi anni, con i bot al 57,2% del traffico HTML, un markup pulito serve simultaneamente a utenti con disabilità, motori di ricerca, sistemi di risposta AI e agenti, e nessuna delle tecnologie in arrivo lo rende obsoleto. Secondo: sperimentare la generazione di interfacce dove il costo dell’errore è basso, prototipi, ambienti di test, ambienti per addestrare agenti su misura, e non in produzione. Terzo: chi lavora nel design, come già visto con gli strumenti generativi applicati alla creatività, guadagna più a spostarsi a monte, sui criteri, che a difendere l’esecuzione a valle.
Solaris è una ricerca importante e un prodotto che nessuno ha ancora potuto usare. La sua idea forte, trattare l’interfaccia come un ambiente da simulare anziché come un documento da descrivere, è genuinamente nuova e avrà conseguenze. Ma la domanda del titolo merita una risposta secca: l’HTML non finisce, perché il suo lavoro non è disegnare. Il suo lavoro è dire cosa sono le cose, e quel lavoro, in un web dove più di metà dei visitatori sono macchine, non è mai stato così richiesto.
Fonti:
- Runway, Introducing Solaris
- Runway, Introducing GWM-1
- Google DeepMind, Genie 3, a new frontier for world models
- MDN, Accessibility tree
- A List Apart, Semantics to Screen Readers
- W3C WAI, Web Content Accessibility Guidelines (WCAG)
- WebAIM, A Seismic Shift in Google Docs accessibility
- The New Stack, Google Docs passa al rendering su canvas
- Search Engine Journal, L’accessibility tree è il modo in cui gli agenti AI leggono il tuo sito
- Ha & Schmidhuber, World Models (2018)
- OSWorld 2.0, benchmark per agenti su flussi di lavoro reali
- The Batch, I modelli GWM-1 di Runway
- Nielsen Norman Group, Generative UI
