Addestrare il CMS

Riunire il team#section1

Se avete già creato un content template o una tabella della pagina, vi suonerà famigliare l’idea di un documento di istruzioni sulla content strategy. I content template fungono da guida per il modello di contenuto, spiegando lo scopo di ciascun campo e sezione, incluse le informazioni quali il pubblico di destinazione, delle note riguardanti lo stile e un esempio di copy. Il problema è che queste linee guida vivono indipendentemente dal CMS: il modo in cui si avvicinano di più all’integrazione è l’inclusione di alcuni screenshot nell’interfaccia di editing.

Le guide per il contenuto sono generalmente di proprietà e creazione di chiunque sia incaricato del contenuto all’interno di un team. Tuttavia, in realtà l’assemblaggio delle linee guida è uno sforzo collaborativo: un designer contribuisce all’informazione riguardante la lunghezza ideale della descrizione di una foto, l’art direction e la dimensione dell’immagine. Uno sviluppatore conosce tutti i vari posti in cui verrà mostrato un particolare campo. Un project owner o un manager sa chi dovrà essere contattato dall’autore per domande di attribuzione, qual è il pubblico inteso per una descrizione di prodotto e che voce e tono dei documenti sono rilevanti per qualunque tipo di contenuto.

Mettere le linee guida per il contenuto direttamente nel CMS richiede che vengano connesse tutte le discipline, il che lo rende inadatto all’inserimento nei processi della maggior parte dei team. In questo articolo, vi mostrerò come mettere insieme tutti i pezzi per creare delle linee guida che forniscano aiuto quando un autore ne ha bisogno e gli rendano semplice fare bene il proprio lavoro. Lo faremo seguendo tre principi.

I label e le linee guida ben fatti:

• forniscono un contesto, spiegando lo scopo di un campo e in che modo sarà usato,
• sono specifiche, incoraggiano l’accuratezza e l’uniformità eliminando le ipotesi e
• sono positive e di aiuto piuttosto che ostili e proibitive.

Tipi di contenuto#section2

Prima di gettare un autore tra gli infiniti campi di una form di editing, dobbiamo fargli un’introduzione al tipo di contenuto in generale: cos’è, dove e come verrà visualizzato e per chi è.

Supponiamo che gli autori fossero abituati a creare delle nuove pagine per ciascun evento e poi a rimuoverle (quando si ricordavano!) dopo la fine dell’evento. Sostituiamo questo processo con uno content type specifico chiamato “Event”. Per aiutare gli autori nella transizione, potrei includere del testo come questo:

Gli eventi vengono visualizzati nella pagina Calendar e in un blocco in homepage e saranno automaticamente archiviati al loro termine. Il calendario è usato principalmente dai membri che hanno già famigliarità con il nostro lavoro e con i termini interni.

Dove e come funziona questa cosa dipende dal CMS. Per esempio, Drupal ha un campo “Explanation or submission guidelines” per ciascun tipo di contenuto che viene mostrato in cima alla pagina di editing di ogni entry. WordPress vi permette di aggiungere dei meta box per editare le schermate con del codice custom o dei plugin come Advanced Custom Fields, che rende l’informazione più accessibile rispetto a nasconderla in un tab di aiuto contestuale. Se non siete sicuri di come fare questa cosa nel vostro CMS, parlate con i vostri sviluppatori: ci sono buone probabilità che lo rendano possibile una volta che ne avranno capito lo scopo.

Nomi dei campi#section3

Quando assegnate un nome ai campi:

• Siate specifici e descrittivi. Per esempio, in un profilo artista, potreste sostituire i campi “Title” e “Body” di default con “Artist Name” e “Biography”. Anche se sembrano ridondanti, i nomi dei campi come “Event name” e “Event description” aiutano l’autore ad orientarsi e gli ricordano che contenuto va inserito in essi.
• Descrivete il contenuto nel campo, non il formato del campo. Un campo immagine denominato “Image” non dice all’autore che tipo di immagine. Qualcosa del tipo “Featured Photo” va meglio, ma è ancora migliore una descrizione specifica come “Venue or Speaker Photo”.
• Siate consistenti. Per esempio, non mettete un label in forma di domanda (“Open to the public?”) a meno che non usiate consistentemente le domante nei vostri campi e tipi di contenuto.

Prima: nomi di campo generici in una entry form di un CMS.

Dopo: nomi di campo specifici danno il contesto per l’inserimento e aiutano gli autori ad evitare gli errori.

Testo d’aiuto e istruzioni#section4

Dove un nome per il campo descrive quale sia il contenuto, il testo d’aiuto descrive cosa fa. L’obiettivo è di aiutare gli autori a rispettare i bisogni strategici, di formato e di stile del sito e di rispondere a domande come quelle in queste quattro categorie:

Messaggi ed informazioni#section5

• Qual è il messaggio sottostante a questo copy?
• Cosa fa questo contenuto nel contesto del sito? Il punto di questo campo è di informare l’utente, guidarlo ad un’azione o fornire dei metadati per la struttura del sito?
• Ci sono delle cose che questo campo deve o non deve includere?
• Il testo alt dovrebbe descrivere, fornire una caption o spiegare la funzione di questa immagine?
• Qual è l’audience? Sono nuovi al nostro lavoro o hanno famigliarità con il nostro gergo interno?

Stile, voce e tono#section6

• Che struttura grammaticale dovrebbe avere questo testo (es., frase completa, frammento di frase, Tagline. Di. Quattro. Parole.)?
• Il titolo dovrebbe essere diretto o scritto come click-bait? (Suggerimento: No.)
• Deve esserci della punteggiatura alla fine?
• Il numero dei caratteri può essere forzato dal CMS, ma c’è una lunghezza ideale a cui l’autore dovrebbe tendere?
• Ci sono delle regole di stile, come l’uso di acronimi o di maiuscole, che potrebbero entrare in gioco?
• State cercando di cambiare le abitudini attuali di scrittura degli autori? Per esempio, servono dei reminder per non scrivere “clicca qui” o dare riferimenti alle posizioni sulla pagina come “la lista a sinistra”?

Tecnico#section7

• Quali sono i formati permessi per le immagini e il caricamento di file?
• Gli upload hanno una dimensione limite?
• Il nome del file deve seguire un pattern specifico (es., OrpingtonPoster-August2014.pdf)?
• Se un campo usa HTML, quali sono i tag accettati?
• Per un checkbox o per una select list, c’è un limite superiore o inferiore di opzioni di scelta?

Design e visualizzazione#section8

• Il valore di questo campo cambia il modo e la posizione della visualizzazione del contenuto? Per esempio, una checkbox controlla se un articolo verrà messo in homepage?
• Questo campo è visualizzato insieme ad altri campi (e quindi non dovrebbe essere un duplicato) o apparirà da solo (come il testo del teaser)?
• Il CMS scalerà e ridimensionerà le immagini automaticamente o l’autore dovrà di caricarne più versioni?
• Dove verrà mostrata questa immagine? Dimensioni diverse (come le thumbnail) verranno mostrate in posti diversi nel sito?
• Ci sono dei requisiti di art direction per questa immagine? Per esempio, necessita di spazio negativo scuro sulla sinistra per un titolo sovrapposto? Dovrebbe mostrare una persona che guarda direttamente nella macchina fotografica?

Una form del CMS con un mix di linee guida tecniche ed editoriali aiuta gli autori a creare delle entry di contenuto consistenti.

Rendere importante ogni parola#section9

Non si risponde a quelle domande in una volta sola: nessuno leggerà mai tre paragrafi di istruzioni per un singolo campo di testo. Il vostro obiettivo consiste nel sottolineare l’informazione più importante che molto spesso viene dimenticata. Per esempio, un’azienda che molto tempo fa aveva deciso che le immagini dei suoi prodotti sarebbero state in formato PNG non ha bisogno di reminder sui tipi di file appropriati. Potreste ricordare agli utenti di scrivere in seconda persona nel campo “Subtitle”, poi mettere un link all’intero documento che parla della voce e del tono per ulteriori suggerimenti.

Qualunque cosa facciate, usate saggiamente lo spazio: se la label del campo è “Featured Photo”, non scrivete “Qui è dove caricate la featured photo”.

Considerazioni speciali#section10

Fate attenzione al grande WYSIWYG#section11

Anche gli autori meglio intenzionati possono essere sopraffatti alla vista di un grande riquadro bianco vuoto con un milione di pulsanti WYSIWYG e i risultati non sono belli. Le linee guida editoriali contribuiscono a ricordare agli utenti per cosa dovrebbero o non dovrebbero essere usati questi grandi campi di testo.

Se gli autori faranno della formattazione, può essere utile personalizzare il WYSIWYG e fornire delle istruzioni di stile esplicite per tenerli sul giusto percorso.

Campo WYSIWYG con una selezione limitata di pulsanti, con incluse le linee guida editoriali e di formattazione.

Siate accorti con l’uso di interminabili istruzioni che iniziano con “Non”. I reminder positivi e gli esempi di contenuto corretto possono essere altrettanto efficaci e sembrano molto più amichevoli dei divieti.

Rendere le liste contestuali e chiare#section12

I campi delle select e le liste di checkbox fanno parte di molti tipi di contenuto, ma vengono usati per una varietà di funzioni differenti: un campo “Category” può controllare dove viene mostrata una entry sul sito, in che modo si collega al resto del contenuto o perfino che template di layout verrà usato per mostrarla. Istruzioni ben fatte forniscono questo contesto agli autori.

Per favore, ricordatevi di cambiare i nomi macchina tutti in minuscolo, legati da underscore, concatenati e abbreviati, come “slvrLc_wynd”, in parole reali, come “Silver-Laced Wyandotte”. Le coppie key:label esistono perché gli autori non debbano parlare con il database per riuscire nell’impresa. Usateli.

Ordinate i campi#section13

Molti CMS vi permetteranno di raggruppare i campi, perlopiù in fieldset o tab, per aiutare gli autori a capire quello che vedono. Nella maggior parte dei CMS, l’ordine della visualizzazione del front-end non deve necessariamente essere identico all’ordine della form del back-end, quindi potete organizzare i campi per aiutare gli autori a fare il loro lavoro senza influenzare la modalità di visualizzazione delle cose sul sito live.

Solitamente, dovrete o raggruppare i campi di contenuto simile o sistemare i campi nell’ordine in cui verranno inseriti.

Per esempio, supponiamo che abbiate bisogno di più versioni di un singolo pezzo di informazione, come un titolo breve e un titolo lungo. Aiuta vederli uno di fianco all’altro, con dei reminder sul modo in cui le versioni differiscono nello specifico una dall’altra.

Oppure, supponiamo che il contenuto verrà copiato da un altro sistema, come le specifiche di un produttore o da un database legacy. Far sì che l’ordine dei campi sia uguale a quello della sorgente del contenuto significa che gli autori non dovranno saltare avanti e indietro durante la creazione di una entry. In maniera simile, se i vostri autori inseriscono sempre il contenuto di “Event Location” tra i campi “Presenter Bio” e “Event Date”, la form di editing dovrebbe riprodurre quello, anche se non è l’ordine che per voi ha più senso.

I fieldset aiutano a dare un senso alle entry form complesse dei CMS, organizzando i campi in gruppi che aiutano gli autori a tenere traccia dei diversi tipi di contenuto.

Diventare specifici#section14

La developer che c’è in me vuole creare una libreria di snippet generiche di aiuto riutilizzabili, ma le istruzioni migliori che io produco sono quelle specifiche per un organizzazione interna e i processi di un cliente. Non abbiate timore di includere informazioni come “Contattare Ann Sebright (x8453) per le informazioni di attribuzione della foto” o “Controllate il calendario interno per date in conflitto prima di postare un nuovo evento”.

Realizzarlo#section15

Il workflow di ciascun team è differente, quindi non posso dirvi esattamente come integrare la creazione di queste istruzioni nel vostro progetto. Posso fornirvi alcune domande, però, così che possiate fare delle conversazioni produttive al momento giusto nel vostro processo.

Scegliere un CMS#section16

Se non avete ancora scelto un CMS, prendete in considerazione le domande seguenti quando valutate le opzioni. Se il CMS è già stato scelto, siate attenti alle risposte, così potete aggiustare di conseguenza la strategia per le istruzioni.

• Che formati di aiuto a livello dei campi supporta il CMS? Singole righe di testo, paragrafi, pop-up, hover text?
• Le istruzioni possono contenere HTML? Un po’ di semplice formattazione può dare risultati straordinari in termini di leggibilità.
• Quanto è difficile aggiornare il testo d’aiuto? Dal momento che i bisogni cambiano nel tempo, sistemare le istruzioni sarà fastidioso?
• Potete cambiare le label dei field custom utilizzati nell’interfaccia di amministrazione senza influenzare il nome macchina utilizzato nelle query e nella visualizzazione front-end?

Modellazione del contenuto#section17

I content strategist, i developer, i designer e i clienti o gli esperti “subject-matter” lavorano spesso insieme per creare modelli di contenuto. Ma è importante includere nelle conversazioni, il prima possibile, anche gli autori regolari, non solo i project lead, ma le persone che effettivamente creeranno le entry sul sito.

• Revisionate i modelli di contenuto e i nomi dei campi con gli autori prima di finalizzarli. I nomi dei campi che state usando hanno senso per loro? Comprendono le relazioni tra campi e quello che questo significa per le connessioni tra i pezzi di contenuto?
• Ci sono posti in cui il nuovo modello differisce in maniera significativa dalla concezione attuale che ne hanno gli autori del contenuto? I cambiamenti più grandi richiedono reminder e aiuti più dettagliati.
• Per i campi che sono leggermente diversi gli uni dagli altri: di che tipo di informazione necessiteranno gli autori per distinguerli tra loro e per usarli correttamente?
• Se avete scelto un CMS con una capacità limitata di includere del testo di aiuto, avete semplificato di conseguenza i vostri modelli? Un modello che le persone non ricorderanno come seguire non sarà molto utile per il contenuto.

Piano di migrazione del contenuto#section18

Quando avete una quantità significativa di contenuto legacy, pianificate la migrazione affinché abbia una sua propria fase nel progetto. Parlate di che tipo di linee guida renderanno più indolore lo spostamento del contenuto nel nuovo CMS.

• Se parti dell’attuale sito vengono divise in pezzi che lo compongono, posizionate i campi di quei componenti gli uni vicino agli altri durante la migrazione, dal momento che derivano tutti dalla stessa sorgente.
• Create un insieme di entry di esempio perfette così che gli autori possano consultarle durante la migrazione. Un insieme di contenuto reale, specialmente che mostrino come l’informazione dal vecchio sito venga riadattata nel nuovo modello, è uno strumento di riferimento di grande valore.
• Prendete in considerazione l’idea di aggiungere delle istruzioni e dei raggruppamenti per campi per la “fase di migrazione”, con un insieme separato di linee guida del “sito live” da mettere in atto dopo che sarà stata completata la migrazione. Il tipo di reminder necessari mentre si sposta il contenuto non sono sempre gli stessi del testo di aiuto per il contenuto creato da zero.

Design e development#section19

Man mano che il design e il CMS prendono forma, i designer e i developer si trovano nella posizione giusta per scovare delle potenziali insidie.

• Ci sono delle parti del contenuto che allertano il vostro sesto senso? Ci sono delle immagini modificabili dall’autore che hanno particolari necessità di art direction? Ci sono delle funzioni del sito (es., “solo un pezzo di contenuto alla volta può essere messo in prima pagina e promuovere un nuovo contenuto rimuoverà dalla prima pagina il contenuto attualmente presente”) che vi sembra di essere gli unici a comprendere? Prendete nota di qualunque pezzo di contenuto del sito che vi rende nervosi e condivideteli con il vostro team così che le linee guida gestiscano la questione.
• Chi inserirà il testo di aiuto nel CMS stesso? Se le istruzioni sono più tattiche, potrebbe essere il team di sviluppo ad occuparsene perché stanno creando i modelli di contenuto. Il content strategist potrebbe diventare il lead per le linee guida più editoriali: in molti CMS, il testo di aiuto può essere inserito mediante una GUI piuttosto che tramite codice, quindi il suo inserimento non deve necessariamente essere fatto da un developer.
• L’help text merita il suo QA. È incredibilmente importante vedere le istruzioni in un contesto, non c’è altro modo per realizzare che un particolare tipo di testo è troppo lungo o che si perde nel disordine, o che l’ordine dei campi non ha senso nella form. I team di sviluppo e quello del cliente dovrebbero entrambe revisionare le form di edit per ciascun tipo di contenuto, per assicurarsi che tutte le informazioni importanti siano state catturate.

Aggiustamenti continui#section20

Ricontrollate regolarmente il vostro lavoro, sia con il vostro team sia con il vostro cliente o con lo sponsor del progetto. Sistemare il testo d’aiuto o ridisporre i campi non richiederà molto tempo, ma può fare un’enorme differenza nella qualità sia dell’esperienza dell’autore sia del contenuto risultante.

• Revisionate le pagine live, specialmente quelle con layout complessi. Se trovate che delle immagini non stiano seguendo l’art direction o del testo che non fornisce le informazioni necessarie, aggiungete del help text più specifico riguardante tali questioni.
• Parlate con gli autori che usano il sistema e fate dei ritocchi basandovi sul loro feedback. C’è qualcosa di fastidioso nella form di edit? I campi sono nell’ordine che a loro sta bene? Ci sono posti in cui un link che li porti alla style guide o alla pagina intranet farebbe risparmiare loro del tempo? Piccoli cambiamenti all’interfaccia posso fare una gran differenza nel workflow generale di un autore.

Preparare gli autori per il successo#section21

Pensavo fosse inevitabile: dopo alcuni mesi dal lancio, avrei sicuramente trovato dei campi usati in maniera errata e dei titoli disorientanti a scombinare il sito, quel tipo particolare di confusione che si genera dalla combinazione di un CMS potente con degli amministratori del sito non addestrati. Ma una volta spostate le linee guida per il contenuto all’interno del CMS stesso, durante i miei controlli post-lancio non faccio più sospiri infastiditi ma noto al contrario dei piccoli miglioramenti.

Quando mettiamo le istruzioni nel posto in cui sono cruciali e più utili, aiutiamo gli autori a crearsi delle buone abitudini e delle sicurezze. Gli permettiamo di mantenere ed espandere un sito complesso senza sentirsi sopraffatti. Un sito web che appare perfetto nel giorno del lancio è una cosa meravigliosa, ma quando miglioriamo l’esperienza dell’autore, miglioriamo il contenuto per sempre e questo dà molte più soddisfazioni.

Illustrazioni: {carlok}