Tra un numero e l’altro una rivista bimestrale stampata lascia sessanta giorni di silenzio, e un portale web è il modo più economico per riempirli senza ristampare niente. Questo vincolo decide tutto il resto: il sito non deve ricopiare la rivista, deve cucire insieme due impaginazioni che escono ogni due mesi.

Contesto

Il caso concreto è il portale di una rivista su start-up e innovazione, edita da un parco scientifico-tecnologico. La rivista esce su carta, il PDF si scarica liberamente, e tra un numero e il successivo il sito ospita articoli brevi, segnalazioni di eventi, commenti dei lettori e i feed di sindacazione. La redazione non è fatta di sviluppatori: chi scrive deve pubblicare senza mettere mano all’HTML, e questo da solo orienta quasi ogni decisione tecnica.

Il vincolo redazionale stringe più di quello tecnico. Un giornalista che impagina la rivista non ha voglia di imparare un linguaggio di template per pubblicare una notizia di duecento parole, e ogni passaggio manuale tra redazione e sito online è un punto in cui qualcosa si rompe. La domanda di progetto, allora, è quanto del flusso si possa affidare alla redazione in autonomia senza consegnarle un sistema che poi nessuno sa tenere in piedi.

Architettura

Il motore è un CMS open-source maturo. A febbraio 2009 le opzioni sensate per un portale editoriale di questa scala sono in pratica due: Drupal, la cui versione 6.0 è uscita il 13 febbraio 2008 (drupal.org), e WordPress, arrivato alla 2.7 l’11 dicembre 2008 (wordpress.org). A questa data la differenza pratica tra i due sta nel modello dei contenuti.

WordPress 2.7 è costruito attorno a post e pagine, con un pannello di amministrazione riscritto da poco — la barra di navigazione laterale arriva proprio in quella versione. Una redazione abituata a scrivere prosa lo impara in poche ore. Drupal 6 ragiona invece per tipi di contenuto e tassonomie: un «articolo», un «evento», una «start-up segnalata» sono entità distinte con campi propri, e il sistema di menu riscritto da zero nella 6.0 le tiene in ordine. Per un portale che mescola generi editoriali diversi — testi lunghi, schede, agenda — il modello a entità di Drupal riduce il lavoro di struttura, al prezzo di una curva più ripida per chi pubblica.

Sopra il CMS stanno tre componenti che non dipendono dalla scelta del motore.

Il primo è la sindacazione. Un portale di settore vive di lettori che non passano ogni giorno: i feed sono il canale che li raggiunge. La scelta è tra RSS 2.0, diffusissimo, e Atom 1.0, standardizzato dall’IETF come RFC 4287 nel dicembre 2005 (ietf.org). Atom chiude alcune ambiguità storiche di RSS — la distinzione esplicita tra contenuto e sommario, le date in formato RFC 3339, l’obbligo di identificatori stabili per ogni voce — ma nel 2009 i lettori di feed leggono entrambi i formati senza intoppi, quindi la decisione è pragmatica più che dottrinale. Pubblicarli tutti e due non costa quasi niente e copre i due lati dell’ecosistema.

Il secondo è la distribuzione del PDF. La rivista cartacea esiste già come file di stampa; metterlo online a scaricamento libero chiude il cerchio tra carta e web nel modo più diretto. La questione tecnica è quale PDF servire. Un PDF generato per la stampa si porta dietro font incorporati solo in parte e dipendenze dal flusso di prestampa; per la conservazione conviene il profilo PDF/A-1, standardizzato come ISO 19005-1:2005, che impone l’incorporamento completo dei font e vieta gli elementi che rendono un file illeggibile dopo qualche anno (iso.org). Per un archivio che deve restare consultabile numero dopo numero, è la garanzia che il PDF di oggi si apra ancora tra dieci anni.

Il terzo è lo strato di interazione: commenti agli articoli, modulo di contatto con la redazione, moderazione. Qui il rischio non è tecnico ma di gestione: i commenti aperti su un sito di settore attirano spam automatico dal primo giorno indicizzato. Senza moderazione preventiva o una coda di approvazione la sezione commenti diventa illeggibile in poche settimane.

Il punto critico

Il problema più difficile non sta in nessuno dei tre componenti, sta nella cadenza. Una rivista bimestrale ha un ritmo di pubblicazione lento e prevedibile; un portale che dovrebbe tenere viva la conversazione tra un numero e l’altro ha bisogno di un ritmo rapido e costante. I due ritmi sono in tensione, e la tecnologia da sola non li mette d’accordo.

Un CMS facile da usare abbassa l’attrito della pubblicazione quotidiana, ma non genera i contenuti. Se la redazione cartacea non ha tempo o mandato per scrivere anche sul web, il portale meglio progettato si svuota dopo qualche settimana e il feed RSS smette di aggiornarsi — il segnale più visibile di un sito abbandonato. La parte tecnica del progetto consiste nell’abbassare quell’attrito fino al punto in cui pubblicare sul web costa meno che non farlo; tutto il resto è una decisione editoriale che nessuna scelta di stack può prendere al posto della redazione.

Implicazioni

Ne segue che la metrica di successo del portale non è il numero di funzioni, è la frequenza di aggiornamento che la redazione reale riesce a sostenere. Le priorità di progetto si rovesciano. Conviene consegnare meno funzioni ma con un flusso di pubblicazione che un giornalista non sviluppatore percorre in due minuti, piuttosto che un sistema ricco che chiede un passaggio tecnico a ogni uscita.

Lo stesso vale per la scelta open-source. Un CMS come Drupal o WordPress si sceglie per la competenza diffusa che lo circonda, non per il costo di licenza nullo: chiunque, anche un’altra agenzia, può subentrare senza ricostruire da capo. Per un committente che è un ente pubblico-privato, la portabilità della manutenzione vale più di qualsiasi funzione su misura. Un portale costruito su questi vincoli per la rivista Innov’azione del Polo Tecnologico di Navacchio è raccontato nell’insight pubblicato da noze: https://www.noze.it/insights/portale-innovazione-online/.

Limiti

Quanto sopra descrive un portale del 2009 e va letto a quella data. I CMS citati sono alle versioni del momento — Drupal 6, WordPress 2.7 — e molte integrazioni che oggi si darebbero per scontate (autenticazione delegata, API pubbliche, distribuzione su CDN) qui sono fuori scala o non ancora pratica corrente per un sito di queste dimensioni. Le scelte di sindacazione e di archiviazione poggiano invece su standard pubblicati — RFC 4287, ISO 19005-1 — e durano più a lungo del software che le serve. La parte fragile dell’architettura non è lo stack, è il presupposto editoriale: che ci sia qualcuno, ogni settimana, con qualcosa da dire tra un numero e l’altro.

https://www.drupal.org/forum/general/news-and-announcements/2008-02-13/drupal-60-released https://wordpress.org/news/2008/12/coltrane/ https://www.ietf.org/rfc/rfc4287.txt https://www.iso.org/standard/38920.html

Immagine di copertina: Matt Mullenweg, co-fondatore di WordPress, mentre parla al WordCamp di Jena (2009) — foto di Sebastian Wallroth, pubblico dominio — https://commons.wikimedia.org/wiki/File:MattMullenwegWordCampJena2009_001.jpg