Riutilizzo il sistema, non il sito

Tre progetti personali come banco di prova

Un template può far risparmiare tempo nel modo sbagliato. Si cambia il logo, si sostituisce un colore, si spostano due blocchi e il sito precedente viene consegnato a un’altra attività. Il codice è riutilizzato, ma lo sono anche le decisioni. È così che nascono siti formalmente diversi e sostanzialmente identici.

Volevo verificare il contrario. Ho confrontato il mio sito professionale, gianlucapartengo.it ↗, e Animals in Black ↗. Il primo deve presentare servizi, lavori, strumenti e contenuti in due lingue. Il secondo è un sito d’autore monolingua, con opere, biografia e una direzione editoriale notturna. Il terzo è un archivio fotografico bilingue che comprende catalogo, ricerca, carrello e pagamenti.

Condividono alcune responsabilità tecniche e una parte del codice. Non condividono la gerarchia delle pagine, il tono, la navigazione, la grafica o il modello dei dati. Anche il modo in cui chiedono un’azione è diverso, perché diversi sono il pubblico e lo scopo.

Questi tre progetti personali mi hanno permesso di mettere alla prova la nuova base su esigenze molto lontane tra loro. Dopo questa verifica, lo stesso metodo è entrato anche nei siti che realizzo e mantengo per i clienti: ogni attività riceve struttura, contenuti, identità e funzioni proprie, mentre le responsabilità tecniche già risolte restano sotto controllo.

Se per riconoscere il progetto precedente basta cambiare logo e fotografie, non ho costruito un sistema riutilizzabile. Ho costruito uno stampino.

La parte comune è quella che deve funzionare sempre

Ogni sito ha bisogno di una struttura HTML corretta, URL puliti, intestazioni di sicurezza, canonical, sitemap, gestione dei temi, navigazione da tastiera e moduli che non perdano i dati al primo errore. Se il progetto è multilingua, ogni lingua deve avere percorsi, metadati e collegamenti coerenti. Se è monolingua, non deve trascinarsi dietro un multilingua spento.

Queste attività non rendono un brand riconoscibile. Rendono il sito governabile. Sono anche i punti in cui una piccola incoerenza può propagarsi ovunque: un helper sbagliato può generare canonical errati, una regola di routing può creare URL duplicate, un componente accessibile solo con il mouse può compromettere tutte le pagine che lo usano.

Per questo ho trasformato quelle responsabilità in una base sorgente mantenuta e verificabile. Le correzioni generali vengono studiate nella base comune e riportate sui siti esistenti confrontando il comportamento, senza sostituire alla cieca i file personalizzati. I test controllano la struttura attesa per il profilo scelto, il markup fondamentale e le funzioni comuni.

Il vantaggio non consiste nell’avere meno cose da fare. Consiste nel sapere quali decisioni sono già state affrontate, dove si trovano e come verificarle prima che una modifica raggiunga il sito pubblico.

Quattro livelli impediscono alla base di diventare una gabbia

Ho separato ciò che appartiene a tutti i progetti da ciò che deve restare specifico. Non è una distinzione teorica: determina quali file vengono generati, quali componenti esistono e dove una personalizzazione può intervenire senza rompere il resto.

La base comune stabilisce, per esempio, che un controllo debba avere un nome accessibile e funzionare da tastiera. Non decide che aspetto debba avere su un sito fotografico o su quello di uno scrittore. Definisce come vengono costruiti canonical e lingue alternative, ma non stabilisce quali pagine debbano esistere né che cosa debbano raccontare.

Questa separazione mi permette di intervenire sul livello giusto. Una correzione di sicurezza non dovrebbe riscrivere l’identità visiva. Una nuova scelta grafica non dovrebbe alterare il routing. Una funzione specifica di un e-commerce non deve apparire in un sito che non vende nulla.

Monolingua e multilingua non sono lo stesso sito con un interruttore

La distinzione fra profilo monolingua e multilingua è uno degli esempi più concreti del metodo. Sarebbe semplice preparare un unico pacchetto pieno di funzioni e nascondere quelle inutilizzate attraverso la configurazione. Il sito continuerebbe però a contenere dispatcher, dizionari, selettori e regole che non gli servono.

Ho scelto invece due profili fisicamente distinti. Prima di generare un progetto devo dichiarare lingue, lingua principale e locali. Il profilo monolingua riceve un solo dizionario e non contiene infrastruttura multilingua. Il profilo multilingua costruisce URL localizzate, canonical, hreflang, selettore e sitemap a partire dalla stessa mappa, controllando anche le collisioni fra gli slug.

Non è una funzione aggiunta per impressionare il cliente. Riduce ambiguità e codice inattivo. Soprattutto, costringe a prendere una decisione architetturale prima di cominciare a riempire le pagine.

Un sito deve contenere ciò che gli serve davvero. La modularità ha valore quando sa anche lasciare fuori il resto.

Tre progetti personali, tre identità riconoscibili

Sul mio sito professionale la struttura serve a far convivere servizi, lavori, strumenti e due formati editoriali. Il design è netto, tecnico e orientato alla consultazione. La ricerca interna attraversa contenuti molto diversi e il routing deve risolverli correttamente in italiano e in inglese.

Su gianlucapartengo.it il centro sono i libri, la scrittura e la biografia. Non esiste un selettore di lingua perché il sito è realmente monolingua. Tipografia, spazi, immagini e movimenti costruiscono un’esperienza editoriale, non una variante cromatica del sito con cui vendo servizi.

Animals in Black usa ancora un’altra grammatica. Il nero fa parte del progetto fotografico, gli animali sono il centro dell’interfaccia e la stessa architettura deve collegare specie, fotografie, stampe, varianti commerciali e pagamenti. Qui il dato non serve soltanto a comporre una pagina: deve restare coerente fra archivio, shop, feed e sistemi esterni.

Questi tre progetti dimostrano che l’infrastruttura può essere condivisa senza imporre lo stesso risultato, purché sia stata progettata per separare responsabilità e identità. Nei siti dei clienti applico lo stesso principio: il metodo resta, il risultato appartiene all’attività.

Non tutti i siti ricevono tutto

Riutilizzare un sistema non significa installare ogni sua possibilità. La ricerca interna ha senso quando esiste un patrimonio di contenuti da attraversare. Un catalogo serve a chi possiede prodotti o opere strutturate. Il multilingua deve esistere soltanto se verrà mantenuto come un percorso completo. Funzioni inutili sono dipendenze da aggiornare, controllare e proteggere senza produrre alcun valore.

Per questo i componenti opzionali vengono aggiunti quando il progetto li richiede. Non restano nascosti in attesa di un eventuale futuro. La base comune definisce il modo corretto per integrarli; il lavoro sul sito decide se debbano esserci.

Anche le personalizzazioni rimangono nel progetto che le ha generate. Il catalogo di Animals in Black non viene promosso a funzione universale. Le componenti editoriali del sito d’autore non diventano blocchi da distribuire ovunque. Possono suggerire una soluzione, ma prima devono essere separate dal contesto e dimostrare di avere una responsabilità davvero comune.

Questa disciplina evita che la base comune cresca come un deposito di tutto ciò che ho già costruito. Deve contenere ciò che so mantenere e verificare per più progetti, non la somma indiscriminata dei progetti precedenti.

Che cosa riceve davvero il cliente

Chi mi affida un progetto non finanzia un nuovo esperimento su ogni elemento di base e non riceve la copia del sito precedente. Riceve un’architettura che parte da regole già verificate e viene poi adattata alle responsabilità concrete della sua attività.

Questo significa poter distinguere con chiarezza ciò che appartiene al sistema da ciò che è stato costruito su misura: identità, contenuti, funzioni, dati e percorsi. Significa anche limitare le dipendenze alle sole parti che servono e sapere dove intervenire quando il sito deve evolvere.

Per me un template professionale non è una collezione di pagine pronte. È il luogo in cui conservo le decisioni che devono restare affidabili, così ogni nuovo progetto può concentrarsi sulle decisioni che nessun altro sito può prendere al suo posto.

Riutilizzo il sistema proprio perché ogni sito merita di essere progettato come un caso unico.