Ogni nostra demo esiste in sedici versioni, e l'interfaccia cambia ogni settimana. Gli strumenti di demo già pronti registrano lo schermo, quindi ogni modifica obbliga a rifare tutto. Demo Studio registra invece i gesti dell'operatore e li riesegue sul prodotto vero.
Sedici versioni per ogni demo
L'applicazione ha un tema chiaro e uno scuro, ed è tradotta in otto lingue: italiano, inglese, francese, tedesco, spagnolo, olandese, portoghese e polacco. Due per otto fa sedici. Servono tutte perché un commercialista di Bologna e una notaia di Lione vedano il prodotto come sul proprio schermo.
L'interfaccia, poi, cambia di continuo: un'etichetta più chiara, un pulsante spostato. Ogni modifica, quasi sempre giusta, rende inesatte le demo girate prima. Con dieci demo in catalogo, una settimana normale di lavoro lascia centosessanta video da rigirare. Un'azienda delle nostre dimensioni non li rigira, e le demo finiscono per mostrare un prodotto che non esiste più.
Che cosa fanno bene gli strumenti di registrazione
Arcade, Storylane, Supademo e Trupeer sono strumenti diffusi e funzionano. Catturano ciò che l'operatore vede sullo schermo, ne ricavano un video o una sequenza di schermate e aggiungono note e passaggi guidati. Per un software con una lingua, un tema e un'interfaccia stabile è la scelta ragionevole: si registra in un pomeriggio.
Il loro oggetto, però, è l'aspetto dello schermo in un dato momento. Quanto gestiscano più lingue o temi lo spiega la loro documentazione meglio di noi. Il nostro problema, rifare sedici versioni a ogni modifica, nasce nella cattura stessa, e nessuna funzione aggiunta dopo lo risolve.
Registrare i gesti dell'operatore
Abbiamo cambiato una sola cosa, e il resto ne discende. Gli strumenti di cattura registrano l'aspetto dello schermo. Demo Studio registra che cosa ha fatto l'operatore: apri questo documento, premi Rileva, seleziona una riga nella Revisione, scegli Codifica. È un elenco di gesti, ciascuno riferito a un elemento dell'interfaccia, senza un solo pixel.
Demo Studio riesegue questo elenco sull'interfaccia vera, una volta per combinazione: chiaro in italiano, scuro in italiano, chiaro in tedesco, fino a sedici. Tema e lingua diventano parametri del rendering. Se un'etichetta cambia, il gesto «premi Rileva» resta identico: si rilancia il rendering e le versioni escono aggiornate. Una modifica all'interfaccia costa così tempo macchina invece di ore di riprese.
C'è un limite. Se un passaggio sparisce dal prodotto, il gesto che lo usava non trova più il suo bersaglio e l'elenco va corretto a mano. Per noi è giusto così: una demo che mostra un passaggio inesistente deve smettere di funzionare. Se una nostra demo mostra un pulsante che nell'applicazione non c'è, ci farebbe piacere saperlo.
Il prodotto vero dentro una pagina web
La route /demo del sito monta nel browser il frontend reale dell'applicazione desktop: stessi componenti React, stessi fogli di stile, stessi file di traduzione. Next.js li raggiunge con un alias di webpack, @desktop/*, che punta alla cartella del frontend. Nessun componente viene copiato o riscritto.
In un browser mancano due cose: il motore locale che rileva e codifica, e la shell Tauri che apre file e finestre. NormalModuleReplacementPlugin sostituisce quelle chiamate in compilazione con moduli che rispondono con dati preparati. I PDF li rende pdf.js, direttamente nel browser.
Così non c'è niente da tenere allineato: una modifica all'interfaccia desktop entra in /demo alla compilazione successiva, senza interventi a mano. La demo resta vicina al prodotto perché è il prodotto stesso, con dati diversi.
A che cosa serve /demo
Su questo ci siamo confusi anche noi. La pagina /demo è attiva, ma il suo compito è fare da base ai rendering di Demo Studio. Chi vuole valutare promptShield non viene mandato lì: usa l'app web gratuita su app.promptshield.ca, con i propri file, e il documento resta sulla sua macchina. C'è anche la prova gratuita dell'applicazione desktop, che non richiede un account.
Una demo è un racconto guidato su dati preparati, una prova è il prodotto alle prese con i documenti di chi prova. Confonderle porta a giudicare l'una con i criteri dell'altra.
Dati inventati, con la forma giusta
I documenti delle demo italiane sono costruiti apposta: un contratto e un prospetto finanziario con nomi inventati. I codici fiscali hanno la struttura giusta e nessun titolare reale, l'IBAN comincia per IT, c'è un numero di tessera sanitaria. La forma conta: un codice fiscale di sedici caratteri non somiglia a un identificativo americano, che a uno studio di Torino non direbbe nulla.
Le demo mostrano anche la Revisione: nessun modello locale coglie ogni identificativo, e per impostazione predefinita il file si scarica solo dopo un controllo umano. Saltarla venderebbe un prodotto più comodo di quello reale.
Non usare documenti veri evita anche un problema giuridico. Chi conserva una registrazione con il fascicolo di un cliente ne diventa responsabile del trattamento. L'art. 28 del GDPR chiede allora un contratto scritto con il titolare. Sullo sfondo restano il Codice Privacy, il Garante per la protezione dei dati personali e il segreto professionale, che nessun contratto scioglie.
Acquistare o sviluppare in proprio
Abbiamo spiegato altrove perché abbiamo costruito anche il motore di rilevamento, cioè ciò che vendiamo. Con una lingua, un tema e un'interfaccia stabile, però, uno strumento in abbonamento costa meno e chiede meno attenzione.
Il conto si rovescia quando le varianti si moltiplicano e il prodotto cambia ogni settimana. Allora il costo vero non è il canone: sono le ore di chi rigira, oppure la distanza crescente fra demo e prodotto.
Demo Studio l'ha costruito in pochi giorni una sola persona, il fondatore, con i modelli di IA che usa ogni giorno. Non c'è un reparto, e la pagina del team lo dice. Per uno strumento interno come questo, il costo di sviluppo è ormai alla portata di un'impresa di una persona. Resta la manutenzione: se Demo Studio si rompe, non c'è un fornitore da chiamare.
Domande frequenti
Perché non usare uno strumento di registrazione dello schermo?
Per molti prodotti è la scelta giusta. Da noi ogni demo esiste in sedici versioni, due temi per otto lingue, e l'interfaccia cambia ogni settimana. Registrare lo schermo vorrebbe dire rigirare tutto a ogni modifica.
Che cosa succede quando cambia l'interfaccia?
Se cambia l'aspetto, basta rilanciare il rendering e le sedici versioni escono aggiornate. Se un passaggio scompare, il gesto che lo usava va corretto a mano, perché una demo non deve mostrare ciò che l'applicazione non fa più.
Come si tengono allineate otto lingue?
Senza intervento manuale: /demo usa gli stessi file di traduzione dell'applicazione desktop, e l'elenco descrive gesti, mai parole sullo schermo. Con il polacco, l'ottava lingua, le versioni di ogni demo sono passate da quattordici a sedici, senza registrare nulla di nuovo.