Da tre quiz statici a una piattaforma editoriale completa.
Un progetto nato per gioco e diventato un esercizio reale di product design, architettura e gestione evolutiva: backend PHP/MySQL, API, contenuti multilingua, CMS, preview dei draft, pipeline immagini, SEO, analytics first-party e privacy by design.
La sfida non era aggiungere funzionalità, ma far evolvere il sistema senza perdere ciò che già funzionava: identità visiva, semplicità d’uso e URL esistenti.
Oggi nuovi quiz possono essere creati, tradotti, testati e pubblicati dal browser, senza modificare il frontend.
Il risultato non è un sito con tre quiz.
È un sistema capace di produrre il quarto.
Il punto di partenza
La prima versione di Sai che Boh? era volutamente semplice.
Ogni quiz viveva quasi come un piccolo prodotto indipendente:
- contenuti definiti nel frontend
- domande e risultati gestiti direttamente nel codice
- immagini inserite manualmente
- nessun vero livello editoriale
- nessuna separazione tra contenuti e presentazione
Per tre quiz funzionava.
Ma il limite era evidente: ogni nuovo contenuto avrebbe richiesto di intervenire nuovamente sul codice.
A quel punto la domanda non era più “come aggiungo un altro quiz?”, ma:
qual è l’architettura corretta se questo progetto deve poter crescere davvero?
La sfida
La reingegnerizzazione aveva un vincolo molto preciso:
non cambiare ciò che già funzionava.
In particolare:
- mantenere l’identità visiva originale
- preservare gli URL già esistenti
- non trasformare il sito in una generica web application
- evitare WebView o scorciatoie in vista di una futura app iOS
- separare contenuti e presentazione
- rendere i quiz gestibili senza modificare il codice
- mantenere una piattaforma compatibile con un hosting PHP/MySQL tradizionale
- costruire un backend che potesse essere utilizzato sia dal sito sia da client futuri
La parte più delicata non era aggiungere tecnologia.
Era aggiungerla senza farla diventare il centro del progetto.
La scelta architetturale
Il principio adottato è stato semplice:
il database diventa la fonte dei contenuti, l’API il contratto, il frontend il modo in cui quei contenuti vengono vissuti.
Da qui è nata una separazione netta tra:
Contenuti
Quiz, traduzioni, domande, risposte, scoring e risultati vengono gestiti nel database.
Logica
Un’API REST espone i contenuti in una forma stabile e indipendente dal client.
Esperienza
Il frontend continua a occuparsi della presentazione, dell’interazione e del carattere visivo del progetto.
Questa separazione ha cambiato completamente la natura del sistema.
Prima, contenuto e codice erano la stessa cosa.
Dopo, il sito è diventato uno dei possibili client della piattaforma.
L’evoluzione
Il progetto è stato trasformato progressivamente.
Quiz statici
↓
Database editoriale
↓
API REST
↓
Frontend dinamico
↓
CMS amministrativo
↓
Multilingua
↓
Preview dei draft
↓
Pipeline automatica immagini
↓
SEO
↓
Analytics proprietaria
↓
Privacy e produzione
L’obiettivo non era costruire tutto subito.
Ogni passaggio doveva risolvere un problema reale del passaggio precedente.
Un modello dati pensato per crescere
La prima decisione importante è stata smettere di considerare un quiz come una pagina.
Un quiz è diventato un insieme di entità:
- quiz
- traduzioni
- domande
- risposte
- risultati
- punteggi risposta/risultato
- stato editoriale
- ordinamento
- target di età
- asset visuali
Questo permette di aggiungere un nuovo quiz senza creare nuove strutture nel frontend.
La logica di scoring non è codificata dentro la pagina: è configurabile attraverso il contenuto.
Lo stesso vale per le traduzioni.
L’API come contratto
Uno degli obiettivi principali era evitare di costruire un backend pensato solo per il sito.
Per questo i contenuti vengono esposti tramite API.
L’API restituisce:
- metadati del quiz
- testi localizzati
- domande
- risposte
- matrice di scoring
- risultati
- immagini nelle diverse varianti
Questo approccio rende il web client indipendente dalla sorgente dei dati e prepara il sistema a un uso futuro da parte di altri client, in particolare l’app iPhone.
Non è stata quindi costruita un’API “perché suona bene”.
È stata costruita perché rimuove dipendenze.
Un CMS volutamente semplice
Una piattaforma editoriale è utile soltanto se creare contenuti è più semplice che modificare il codice.
L’area amministrativa permette di:
- creare un quiz
- modificare i suoi metadati
- gestire italiano e inglese
- creare domande
- creare risposte
- definire lo scoring
- creare risultati
- impostare draft, published e archived
- ordinare i contenuti
- caricare immagini
- provare il quiz prima della pubblicazione
La scelta è stata evitare un CMS generalista.
L’interfaccia conosce esattamente il dominio che deve gestire.
Questo riduce la complessità sia tecnica sia operativa.
La preview: pubblicare non deve essere il modo di testare
Una delle funzionalità più importanti è arrivata abbastanza tardi nel progetto: la preview reale.
Prima della pubblicazione, un quiz può essere eseguito integralmente:
- con contenuti ancora in draft
- nella lingua scelta
- con lo stesso frontend del sito pubblico
- con domande, scoring e risultati effettivi
La preview è autenticata e non indicizzata.
Questo permette di separare finalmente due momenti molto diversi:
sto costruendo il contenuto
e
sto pubblicando il contenuto.
È un dettaglio che cambia molto l’esperienza editoriale.
La pipeline delle immagini
La gestione manuale delle immagini era un altro punto di attrito.
Il sistema oggi conserva tre versioni dello stesso asset:
- full — master originale
- web — versione ottimizzata per le pagine
- thumb — versione per listing e anteprime
Quando un’immagine viene caricata dall’admin:
- viene validata
- viene salvato il master
- viene generata automaticamente la variante web
- viene generata automaticamente la thumbnail
- il riferimento corretto viene salvato nel database
Questo elimina un passaggio manuale e rende più difficile pubblicare asset fuori standard.
Compatibilità prima dell’eleganza
Durante la reingegnerizzazione è stata fatta una scelta precisa:
non rompere gli URL esistenti solo per rendere tutto più uniforme.
I primi tre quiz mantengono quindi i loro percorsi storici.
I nuovi contenuti utilizzano invece una route generica.
È una soluzione meno “pura” dal punto di vista estetico dell’architettura, ma migliore dal punto di vista del prodotto.
Questo principio è stato applicato più volte:
quando l’eleganza tecnica entra in conflitto con la continuità del servizio, la continuità ha la precedenza.
Multilingua senza duplicare il prodotto
Italiano e inglese non sono due siti separati.
Le traduzioni fanno parte del modello editoriale.
Titolo, descrizione, testo introduttivo, call to action, share prompt e contenuti dei quiz vengono gestiti per locale.
Questo permette di avere:
- stessa struttura
- stesso scoring
- stessi asset
- testi realmente localizzati
- URL pubblici specifici per lingua
Inoltre canonical e hreflang mantengono coerente la rappresentazione SEO delle diverse versioni.
Analytics: misurare senza profilare
Per un progetto di questo tipo non aveva senso introdurre una piattaforma analytics molto più grande del problema.
È stata quindi sviluppata un’analytics first-party minimale.
Vengono registrati soltanto eventi come:
- apertura del quiz
- inizio
- completamento
- risultato finale
- condivisione
- download della card
Non vengono registrati:
- account
- identificatori utente
- identificatori di sessione
- fingerprint
- risposte individuali
- user agent nella tabella analytics
- cronologia personale di navigazione
L’analytics serve a rispondere a domande di prodotto.
Non a costruire un profilo della persona che gioca.
Privacy come vincolo progettuale
La privacy non è stata aggiunta alla fine sotto forma di pagina legale.
Ha influenzato direttamente alcune decisioni.
Ad esempio:
- nessun SDK social caricato automaticamente
- nessun cookie analytics
- nessuna profilazione
- nessuna memorizzazione delle singole risposte
- retention limitata degli eventi analytics
- area amministrativa separata
- privacy e cookie policy coerenti con il comportamento reale del sistema
La conseguenza interessante è che non serve nemmeno un banner cookie nell’area pubblica.
La soluzione più semplice da spiegare è spesso anche quella più semplice da progettare.
Quello che non ha funzionato
Il progetto non è cresciuto senza errori.
E alcuni sono stati particolarmente istruttivi.
Una pagina completamente bianca
Una funzione SEO veniva invocata prima che il relativo modulo PHP fosse caricato.
Il risultato non era un layout rotto o un warning visibile.
Era una pagina bianca.
Il problema ha ricordato una cosa molto semplice: quando aumentano i livelli del sistema, l’ordine delle dipendenze diventa parte dell’architettura.
Un pulsante apparentemente morto
Il pulsante SCOPRILO sembrava non reagire.
Il problema non era nel pulsante.
Un errore durante l’inizializzazione di un oggetto JavaScript interrompeva l’esecuzione del file prima che i listener venissero registrati.
L’interfaccia era perfettamente visibile.
La logica dietro era già morta.
Un buon esempio di quanto sia pericoloso diagnosticare un problema partendo soltanto da ciò che appare sullo schermo.
Le share card e il CORS
Le immagini dei risultati venivano utilizzate per generare card attraverso Canvas.
Una differenza apparentemente innocua tra hostname e URL degli asset rendeva però il Canvas non esportabile.
La soluzione non è stata “aggiungere un workaround”.
È stato necessario capire quale fosse realmente l’origine dell’asset dal punto di vista del browser.
Preview e URL pubblico sono due cose diverse
Durante il test di un quiz in draft, la pagina si trova sotto /admin/.
Ma quella URL non deve mai finire in una condivisione.
È stato quindi separato esplicitamente:
- URL dell’esperienza di preview
- URL pubblico destinato alla condivisione
Una piccola decisione, ma necessaria per evitare che un dettaglio interno diventasse parte dell’esperienza utente.
SEO e produzione
Quando l’architettura si è stabilizzata, il progetto è stato portato a uno stato realmente pubblicabile.
Sono stati introdotti:
- canonical
- hreflang IT/EN
- Open Graph
- sitemap dinamica
- robots.txt
- gestione degli URL duplicati
- redirect canonici
- cache per gli asset statici
- pagina 404
- meta description
- pagine Privacy, Cookie e FAQ
Il principio è stato lo stesso utilizzato nel resto del progetto:
automatizzare ciò che può essere derivato dai dati invece di mantenerlo manualmente.
La sitemap, ad esempio, viene generata dal database e include soltanto quiz e traduzioni pubblicati.
Il risultato
Oggi un nuovo quiz può essere creato senza modificare il frontend.
Il flusso è:
- creare il quiz nell’admin
- compilare italiano e inglese
- aggiungere risultati
- aggiungere domande e risposte
- configurare lo scoring
- caricare immagini
- provare tutto in preview
- pubblicare
Il web client lo renderà automaticamente disponibile.
La stessa API potrà essere utilizzata da un’app nativa.
Il sistema non è stato progettato per tre quiz.
È stato progettato perché il numero dei quiz smettesse di essere un problema tecnico.
Cosa dimostra questo progetto
Sai che Boh? è volutamente leggero come prodotto.
Ma il processo dietro non lo è.
Il progetto mi ha permesso di lavorare su temi che incontro anche in contesti molto più grandi:
Evoluzione senza regressione
Cambiare l’architettura preservando ciò che funziona già.
Separazione delle responsabilità
Contenuto, logica, presentazione e operation hanno esigenze diverse.
Scelte proporzionate
Non serve introdurre una tecnologia se non risolve un problema reale.
Manutenibilità
Una soluzione è davvero utile quando il prossimo cambiamento costa meno del precedente.
Osservabilità
Errori, analytics e preview non sono accessori: aiutano a capire cosa sta realmente succedendo.
Product thinking
La domanda importante non è “cosa possiamo aggiungere?”, ma “cosa rende più semplice il prossimo passo?”.
Stack
Backend
PHP · MySQL · PDO
Frontend
HTML · CSS · JavaScript
Architecture
REST API · database-driven content · reusable quiz frontend
Content management
Custom CMS · draft/publish workflow · localized content
Media
Image upload · automatic WebP generation · full/web/thumb pipeline
Production
SEO · sitemap · Open Graph · hreflang · privacy · first-party analytics
Stato del progetto
In produzione
La piattaforma web è operativa e il modello editoriale permette di aggiungere nuovi quiz senza interventi sul frontend.
La successiva evoluzione prevista è un client iOS nativo basato sulle stesse API.
La cosa che terrei bene in evidenza
Un progetto nato per gioco può comunque essere progettato seriamente.
È probabilmente proprio questa la parte che mi interessava verificare.