Content Management Strategico

Il problema: i tool non sono polvere magica dei folletti#section1

Qualunque progetto web che sia più complesso di un blog richiede un lavoro di progettazione di un CMS personalizzati. La tentazione di utilizzare tool familiari ed infilarci dentro il contenuto è forte, ma non possiamo scegliere il tool appropriato fin quando non abbiamo capito le necessità specifiche del progetto.

I wireframe sono fantasie a cui aspirare ed ispirarsi#section2

Come dice Karen McGrane, è facile abbozzare una faceted navigation in un wireframe. E’ più complesso implementare un CMS che renda la tassonomia implicita in esso e impegnarsi nel tempo nel continuo mantenimento redazionale. Un wireframe senza una corrispondente content strategy e un progetto per un realistico CMS è un artefatto della fantasia. Un CMS che può realizzare uno di questi wireframe di fantasia ha bisogno di moltissima polvere magica dei folletti. Abbiamo bisogno di una strategia per il contenuto che ci aiuti a decidere quale delle nostre aspirazioni è fattibile; la progettazione del CMS è una parte essenziale di questa decisione.

Usare un processo di progettazione per selezionare e customizzare un CMS#section3

La maggior parte delle volte, selezioniamo un CMS per la sua popolarità, per una certa affinità culturale o per un editto aziendale, ossia, senza aver considerato in maniera appropriata il contenuto che dovremo pubblicare. Questa è una follia! Al contrario, dovremmo usare un processo di design per selezionare e customizzare un CMS, basandoci sulla nostra content strategy e sulle esigenze del team editoriale. Questo articolo vi mostrerà come. Ma prima, facciamo un passo indietro: cos’è esattamente un CMS?

Un CMS è un insieme di features#section4

Definiamo un CMS come un insieme di tool software che permettono alle persone non-tecniche di gestire il proprio contenuto per internet. Ci sono un miliardo di differenti tool CMS là fuori. Di solito vengono venduti per le loro caratteristiche—e ragazzi, ne hanno veramente tante! Eccone un assaggio:

• creazione ed editing di contenuto,
• distribuzione del contenuto,
• gestione della tassonomia,
• cura e composizione della pagina,
• workflow editoriale e
• …continua all’infinito.

Ora, mi piacciono le feature ben fatte di un CMS, ma da sole non possono risolvere i problemi strategici, editoriali o di governance. Troppo spesso, i progetti basati sui CMS diventano solutioneering ossia: gettare la tecnologia addosso problemi. Quindi, cosa ci deve dare un CMS oltre ad un insieme di feature?

Un CMS dovrebbe aggiungere della ricchezza semantica#section5

Perché un CMS ci dia del valore aggiunto, pensate oltre l’editing delle pagine web. Come sostiene Jeff Croft:

…[la gestione del contenuto] dovrebbe includere la strutturazione, organizzazione, la ricerca, il filtraggio e la facile modifica del vostro contenuto… [e] facilitare l’instaurazione di relazioni significative tra i disparati pezzi di contenuto. Dovrebbe rendere il vostro contenuto più utile semplicemente in virtù del fatto che il contenuto è nel sistema.

Le pagine web sono il posto in cui va a finire il nostro contenuto, ma usare un tool che fa solo l’editing delle pagine è come mettere il markup agli heading di un documento usando l’elemento div: potrebbe andar bene in superficie, ma gli elementi di heading con una semantica appropriata sono molto più utili. Quindi un CMS deve avere un modello di contenuto ricco che generi pagine web semantiche.

Un CMS dovrebbe essere personalizzato sulle esigenze di progetto#section6

Un prodotto non può sistemare i problemi relativi al contenuto in maniera eccellente. Ogni CMS ha avuto origine come una soluzione ad uno specifico problema, poi generalizzato per andare bene per un range più ampio di problemi. E’ il segreto di Pulcinella che i tool CMS devono essere personalizzati prima di poter essere usati su un vero sito web. Come sostiene D. Keith Robinson:

In verità la maggior parte dei CMS finiscono con l’essere personalizzati, a prescindere dal motivo per cui sono nati. Da quelli che si definiscono “one-size fits all” [una sola soluzione per tutti i problemi, ndt] a quei sistemi altamente specializzati che hanno a che fare con delle industrie o dei tipi di contenuto molto specifici. E’ solo una questione di quanto hacking serva per ottenere quello che funziona per i vostri clienti.

Quindi, un CMS è un insieme di potenti tool che aggiungono ricchezza semantica al contenuto e che richiedono della personalizzazione per soddisfare i requisiti di uno specifico progetto. Prima di capire come applicarli alla content strategy, facciamo una breve lezione di storia.

La Content Strategy sta scuotendo l’industria dei CMS#section7

La nascita della content strategy sta scuotendo fortemente l’industria del content management. Nell’era del Selvaggio West del web, il CMS era gestito dal dipartimento IT— o a volte dal solitario webmaster che conosceva HTML—così le scelte riguardanti il CMS erano basate sulle features, sul prezzo e sull’adattamento culturale, piuttosto che sul web o sulla content strategy. Era il classico esercizio IT: comitati di selezione, matrici di caratteristiche e lanci aziendali con uomini incravattati.

Come direbbe Bob Dylan, “The times they are a-changin’”. Secondo Lisa Welchman, il web è ora la principale via di comunicazione di un’organizzazione, il principale canale di vendite, di marketing nonché veicolo transazionale primario. Il pubblico target di un produttore di CMS era di solito il direttore del dipartimento IT e un risultato positivo significava che ogni dipartimento poteva aggiornare facilmente il proprio contenuto. Ora, il target di pubblico è l’infrastruttura editoriale interna di ciascuna organizzazione e un risultato di successo è un complesso mix tra il raggiungimento degli obiettivi di business, l’implementazione della content strategy e la progettazione della user experience. Il gioco si è fatto più duro.

Un processo per selezionare e personalizzare un CMS#section8

Scegliamo i tool CMS per delle ragioni folli. Provate a vedere se vi riconoscete in uno qualunque di questi scenari:

• Scegliere un tool perché qualcuno che ammirate lo utilizza— e vi aspettate dei risultati come i loro— è come comprare lo stesso modello di chitarra che suonava Hendrix e sperare di riempire il Madison Square Garden la settimana dopo. (Indizio: “Tutti i ganzi usano il prodotto ACME.”)
• Scegliere un tool basandosi sull’attaccamento culturale ad esso rende il progetto molto più legato a voi che agli obiettivi del vostro cliente e ai bisogni dei vostri utenti. Evitate guerre sante. (Indizio: “Il prodotto ACME dove essere il vostro prossimo CMS.”)
• Scegliere un tool perché il dipartimento IT dice che dovete è come accettare una commessa artistica mentre siete in manette: si può fare un buon lavoro ma siete pronti per fallire (Indizio: “Il cliente richiede il prodotto ACME.”)

E’ come se considerassimo qualunque fattore tranne che il contenuto. Prendiamo il suggerimento di Karen McGrane e Jeff Eaton e “reinquadriamo la conversazione”:

Spostate la discussione riguardante il CMS dalle “features” al “flusso dei task”.

Quindi a cosa assomiglia un processo maturo di selezione del CMS? Ecco il diagramma del flusso di lavoro:

Fig. 1 Flusso di lavoro di progettazione del CMS.

Gli input sono la content strategy, che è fatta di sostanza, struttura, workflow e governance; le nostre risorse di redazione, i.e., l’impegno continuo in termini di tempo del team di redazione; le nostre risorse tecniche, fatte di infrastruttura (e.g., hardware) e l’impegno in termini di tempo del team tecnico. Usando i processi di progettazione complementari del content modeling e dell’analisi dei task, creeremo una piano di selezione & e personalizzazione del CMS, che descrive quali tool usare, come li personalizzeremo e come li manterremo nel tempo. Esaminiamone uno alla volta.

La miniera d’oro: i deliverables della content strategy#section9

Per prima cosa, niente panico: il content strategist è qui per aiutarvi. (Non c’è un content strategist? Considerate l’opzione di farlo voi stessi.) L’articolo Content-tious Strategy di Jeffrey MacIntyre è una panoramica pratica sulle varie sfumature della figura del content strategist, con i relativi deliverable. Presi nel loro insieme, questi documenti sono una miniera d’oro per prendere decisioni intelligenti sulla progettazione di un CMS. Eccone una sintesi.

• Una strategia editoriale (“sviluppo del prodotto per il contenuto”) dovrebbe includere un calendario editoriale, un workflow per la redazione e una guida di stile.
• Un’analisi del contenuto potrebbe includere l’inventario del contenuto, la gap analysis, una tassonomia ed un piano di migrazione.
• Le gemme relative al copywriting e alla IAincludono i template per il contenuto (definiti anche tabelle di pagina), copy-decks e wireframes con annotazioni.

I tre tipi di metadati#section10

Non abbiamo menzionato i metadati—comunemente definiti come “dati sui dati”— perché il termine stesso crea confusione. Infatti, Deane Barker sostiene che la distinzione tra i dati ed i metadati non è utile. Ma consideriamo la definizione di Rachel Lovinger (link a un PDF), che definisce tre tipi:

• i metadati descrittivi sono la tassonomia: classificazione dei sistemi per il contenuto;
• i metadati amministrativi specificano lo stato del contenuto dietro le quinte, normalmente gestito dal CMS stesso; e
• i metadati strutturali definiscono il modello di contenuto.

Invece di usare la stessa parola per tre diversi concetti, parleremo di tassonomia, dati amministrativi e modello del contenuto.

Content modeling: tipi, elementi, relazioni…oddio!#section11

Basandoci sulla strategia, progetteremo un modello per descrivere il contenuto del sito: tipi, elementi e relazioni. Potete pensare al modello di contenuto come ad una struttura semantica per il contenuto o ad uno schema database: fa parte dell’architettura dell’informazione. (Non confondetelo con la site map, che specifica la navigazione top-down.) Il content modeling non è un processo immediato e meccanico: richiede esperienza e capacità di giudizio umani, e non c’è un’unica soluzione corretta.

Bilanciare semantica e granularità#section12

Il content modeling riguarda il fare dei compromessi tra la semantica e la granularità. Possiamo incapsularla come la risposta a due domande:

1. Cosa rappresenta questo contenuto? (Semantica)
2. A che livello di dettaglio dobbiamo arrivare? (Granularità)

Per dimostrare ciò, supponete che stiamo progettando un modello di contenuto per un’azienda che fa conferenze. Per prima cosa, considereremo quali tipi di contenuto sono necessari. (Questi non sono i media types come il video o il testo: ogni tipo di contenuto rappresenta una differente entità nel nostro modello.) E’ facile fare brainstorming sui possibili tipi di contenuto: eventi, presentazioni, speakers, partecipanti. Ma di che livello di dettaglio abbiamo bisogno? Dobbiamo creare conferenze con sessioni e orari multipli o le presentazioni e gli speaker sono sufficienti?

Allo stesso tempo considereremo quali tipi di contenuto sono in relazione fra loro e come. Ad esempio, se modelliamo le sessioni, ogni presentazione è in relazione alla sua sessione; senza sessioni, ogni presentazione è direttamente correlata all’evento. Considereremo inoltre se le relazioni sono uno-a-molti o molti-a-molti (il termine tecnico è “cardinalità”). Po considereremo gli elementi: cosa definisce ciascun tipo di contenuto? Nel nostro esempio, abbiamo bisogno di un elemento “URL” per ogni speaker o l’elemento “Biografia” è sufficiente? Infine, decideremo quali tipi di contenuto hanno bisogno di una classificazione e quale tassonomia usare.

Il modello deriva dalla strategia#section13

Se questo suona un po’ astratto, non preoccupatevi. Non staremo seduti qui tutto il giorno discutendo della natura del mondo: abbiamo una strategia per il contenuto da implementare. Basandoci sui deliverables delineati prima, potremmo disegnare questo modello di contenuto:

Fig. 2 Esempio di un diagramma di un modello di contenuto per un sito di conferenze.

Ciascun riquadro rappresenta un tipo di contenuto ed elenca alcuni possibili elementi; le linee rappresentano le relazioni tra i pezzi di contenuto. Stiamo facendo un modello di un evento come una serie di sessioni, ciascuna con un certo numero di presentazioni, ognuna presentata da uno speaker. Questa ricchezza semantica ci dà la flessibilità di poter presentare il contenuto in maniera potente. Ad esempio:

• Dalla biografia dello speaker potremmo mettere un link alle presentazioni di questo ad eventi già terminati.
• Per ciascuna presentazione potremmo automaticamente mostrare cosa c’è prima e dopo di questa, e cosa succede in contemporanea nelle altre sessioni.
• La ricerca potrebbe dare dei risultati intelligenti, e.g., uno speaker e gli eventi a cui presenterà.
• C’è l’opportunità di creare un programma della conferenza personalizzato che gli spettatori potranno usare per pianificare la propria giornata.

Non progettate il modello perfetto#section14

Considerate una conferenza a cui avete partecipato: questo modello di contenuto ha senso se applicato a quella conferenza? Probabilmente no: come si applica ad eventi con una sola sessione o con panel con numerosi speaker? O, più significativamente, cosa succede se la strategia editoriale è basata sulla pubblicazione di video ad alta qualità delle presentazioni? Non stiamo cercando il modello definito: abbiamo bisogno di un progetto pragmatico che soddisfi i requisiti del mondo reale della content strategy. Non avremo quello giusto al primo colpo: i modelli di contenuto evolvono, quindi lasceremo dello spazio per l’iterazione e per i cambiamenti futuri.

Analisi dei task: cosa deve fare un redattore?#section15

Tuttavia, un modello non è sufficiente; un redattore deve creare, editare, pubblicare e curare il contenuto che vi vive. Nella vita reale, il redattore avrà poco tempo. Usando l’analisi dei task possiamo rendere il nostro modello del contenuto più realistico considerando la flessibilità. E’ un ottimo modo per identificare le assunzioni riguardanti l’interfaccia del CMS per prima cosa ed inoltre ci permette di informare il team di progetto sui costi reali del contenuto e delle features—prendendo in considerazione il tempo di redazione e tecnico continuo.

I redattori web sono anche utenti#section16

Per i professionisti del web, l’analisi dei task non è cosa nuova. Abbiamo sempre pensato dal punto di vista dell’utente, rendendo i task quanto più immediati possibile. Ma quanto spesso applichiamo lo stesso tipo di ragionamento ai redattori web? Ecco una guida in quattro passi:

1. Fare un brainstorming sui task chiave (basandosi sul modello del contenuto, sul calendario di redazione e sull’inventario del contenuto).

+

2. Abbozzare dei diagrammi di workflow per ciascun task.
3. Abbozzare dei wireframe delle interfacce principali.
4. Stimate il tempo editoriale richiesto per completare ciascun task.

Un esempio di analisi dei task#section17

Continuando con il nostro esempio della conferenza, come regge il confronto con l’analisi dei task il nostro modello di contenuto? E’ immediato elencare i compiti chiave di un redattore: pubblicare una news, aggiungere uno speaker, aggiungere una nuova presentazione, etc. Ecco come potrebbe essere il task flow del CMS per aggiungere una nuova presentazione, dato il nostro modello di contenuto:

Fig. 3 Esempio di flusso dei task per un CMS di un sito di conferenze.

Il diagramma mostra i cinque processi e i due punti di decisione implicati in questo task. Un’implementazione tipica potrebbe includere cinque schermi separati; stimiamo che un redattore ci impiegherà 10-20 minuti per completarlo. Abbozzeremo anche dei semplici wireframe per ciascun processo. (Un lavoro progettato con Ajax potrebbe funzionare meglio? Avremo bisogno di bozze dettagliate che mostrino come l’auto-complete o la magia del mostra/nascondi funzionano).

Se applichiamo l’analisi dei task all’intero sistema, possiamo derivare delle stime sensibili del tempo di redazione richiesto per completare ciascun task. Possiamo quindi assegnare delle priorità al nostro campo d’azione basandoci sul tempo effettivo a disposizione. Possiamo quindi togliere quelle parti del modello di contenuto che sono troppo ambiziose, mentre altri bisogni potranno essere estesi. Questo processo ci aiuta a trovare un equilibrio realistico tra la modellazione ed il task flow basandoci sulle priorità strategiche piuttosto che su assunzioni azzardate.

Ci sono anche altri benefici: identificare le assunzioni all’interno di un modello di contenuto all’interno del processo di pubblicazione. Ad esempio, il nostro task flow richiede che il redattore selezioni una sessione prima di inserire una presentazione. Si tratta di un’assunzione valida? Cosa succede se dobbiamo pubblicare una presentazione prima che le sessioni siano decise in maniera definitiva? E come potrà il front-end presentare comunque le sessioni? Scoprire queste assunzioni prima dell’implementazione fa risparmiare tempo, denaro e dolore.

Il momento delle decisioni: la scelta del CMS ed il piano di personalizzazione#section18

A questo punto, abbiamo un modello di contenuto revisionato ed un’analisi dei task che specifica come i redattori interagiranno con il CMS. Sappiamo anche quali task sono più importanti, quali ci aiuteranno ad assegnare delle priorità allo sviluppo dell’interfaccia di backend. Questo ci mette in una posizione di forza per fare una breve lista e scegliere i tool CMS e per dare un raggio d’azione alla personalizzazione.

Non c’è una soluzione miracolosa per la scelta del CMS. La chiave sta nello specificare il problema nella maniera più chiara possibile e poi di insistere sulle stime realistiche del tempo necessario per la personalizzazione e l’implementazione. Dobbiamo essere pronti a porci le seguenti domande:

1. Questo tool può gestire il nostro modello di contenuto? In maniera nativa o con delle customizzazioni?
2. Quanta personalizzazione sarà necessaria per implementare questo task flow? Quanto tempo ci vorrà, date le nostre risorse tecniche?

Se non siete dei tecnici esperti, avrete bisogno di consultare il vostro team tecnico, i produttori o le comunità online. Sebbene ci siano altri fattori importanti da considerare quando scegliete un CMS (e.g., le piattaforme, le licenze, l’hosting), non lasciate che nessuno li usi come una scusa per evitare di rispondere a queste domande base. Se il tool può fare quello che avete delineato e ci sono abbastanza soldi e tempo per personalizzarlo, allora andrà bene. Altrimenti, o consideriamo un tool diverso o riduciamo i nostri piani in maniera che sia fattibile. Un progetto CMS ha bisogno di risorse tecniche anche dopo il giorno del lancio, quindi assicuratevi di stimare i cambi di progetto e la maintenance continua.

L’output di questo processo è un piano di progetto. Sappiamo quali tool stiamo usando e abbiamo definito un raggio d’azione per il lavoro richiesto per fare in modo che questi vadano bene per le nostre esigenze. Adesso, prendetevi qualcosa da bere!

Quella freccia finale: torniamo alla lavagna#section19

Eppure non abbiamo ancora finito: non possiamo semplicemente metterci un po’ di content strategy, customizzare il CMS e lasciare tutto. Il progetto del CMS è parte di un processo costante ed iterativo: il piano di scelta e personalizzazione fornisce delle informazioni riguardanti la fattibilità che influenzerà la content strategy stessa. In pratica, sogneremo di piani ambiziosi che richiedono quantità irreali di tempo della redazione e dei tecnici per implementarla. Quindi, dobbiamo usare la freccia finale del diagramma del workflow, tornare alla lavagna e ridimensionare i nostri piani per renderli più realistici.

Riprendere il controllo del CMS#section20

I nostri siti web sono stati tenuti a freno per troppo tempo da publishing tool troppo scarsi. In questo articolo ho esplorato alcuni modi per applicare il pensiero strategico alla scelta del CMS e alla sua personalizzazione, attraverso il progetto. E’ tempo di riprendere il controllo dei nostri sistemi di gestione del contenuto sfruttando il potere della content strategy.

Illustrazioni: {carlok}