Tieni le slide sotto controllo: usa file di testo e Git per versionarle

“final”, “final-v2”, “final-really-final-JM-edits” fanno perdere commenti, sovrascrivono cambiamenti e confondono l’ultima versione mostrata. Gli sviluppatori hanno risolto problemi simili con Git. Lo stesso approccio funziona quando le presentazioni si scrivono in HTML o Markdown¹.

I pacchetti di slide tradizionali sono binari: un sistema di controllo versione li conserva, ma non mostra con facilità cosa cambia tra due revisioni. Con sorgenti testuali succede il contrario: ogni modifica appare come righe aggiunte o rimosse, leggibili. Si vede chi cambia una frase, si discute un intervento puntuale, si annulla un errore in pochi secondi¹.

Per abilitare questo flusso serve scrivere le slide come testo. L’articolo cita tre opzioni consolidate: reveal.js, Slidev e Marp. Oggi molte soluzioni di intelligenza artificiale generano direttamente slide in HTML, e questo abbassa la soglia d’ingresso per flussi basati su file testuali¹.

La revisione migliora perché si lavora su differenze chiare, non su copie con suffissi diversi. La cronologia rende espliciti gli interventi e riduce ambiguità. Il progetto resta leggibile perché i cambiamenti toccano solo le righe necessarie, senza formati opachi che nascondono dettagli¹.

L’organizzazione dei file conta. Una struttura semplice aiuta a trovare le cose e a mantenere ordine: una cartella slides/ per i sorgenti principali del deck, una cartella assets/ per immagini, loghi e grafici, una cartella exports/ per i file generati per la distribuzione¹.

Il titolo dell’articolo indica un’azione concreta: a ogni rilascio esportare un file PPTX. L’idea è affiancare ai sorgenti testuali un artefatto binario per la condivisione a valle, mantenendo la lavorabilità e la tracciabilità del contenuto in formato testo¹.

Un flusso minimo, applicabile subito, può seguire questo schema: scrivi o genera le slide in HTML o Markdown con uno degli strumenti citati; salva i sorgenti in slides/ e le risorse in assets/; rivedi le modifiche come differenze riga per riga; quando chiudi una versione, esporta un PPTX e salvalo in exports/. Così chi deve presentare ha un file pronto all’uso, mentre chi collabora continua a lavorare su testo controllabile¹.

Ci sono limiti pratici. I PPTX restano binari: Git li archivia, ma non mostra il diff interno. Conviene quindi tenere i sorgenti come verità di riferimento e usare gli esportati solo come output di consegna. In questo modo la cronologia resta leggibile e l’artefatto distribuito non spezza il flusso di lavoro¹.

Se il team adotta questa disciplina leggera, ottiene due risultati con poco sforzo: differenze leggibili per ogni modifica e un pacchetto di distribuzione coerente a ogni rilascio, generato dagli stessi sorgenti e parcheggiato nella cartella exports/ pronta all’uso¹.