Gestire il CMS

La prima regola dei content management system è che state usando quello sbagliato. Usate WordPress? Siete un bambino di quinta elementare che ha un blog sulle competizioni dei disegni da colorare. Drupal? Dovreste usare WordPress. Una soluzione a pagamento? Siete il Giuda dell’open source.

Questo è l’apparenza, perlomeno se passate del tempo dalle parti dei più coriacei web-dev su Twitter o se gironzolate tra i commenti dei blog. Ma la prima vera regola dei content management system è che non è tanto quale CMS usate quanto in che modo lo usate. Uno dei content management system meno noti, implementato con cura, spesso sarà molto più utile di un sistema molto noto scaricato così com’è e buttato sul proprio server.

Come testo guida per l’implementazione dei content management system, vi rovinerò la giornata presentandovi una citazione da I Fratelli Karamazov di Fyodor Dostoyevsky:

Adattando la citazione ai nostri fini, Dostoyevsky intendeva che la cosa più bella che potete dire ai vostri utenti del CMS è che non hanno la libertà di fare casini. Quando implementate un CMS, cercate di dare ai vostri utenti l’esatto livello di libertà di cui hanno bisogno, ma, se avete dei dubbi, sbagliate pure dando loro leggermente troppo.

Questa è la visione ad ampio spettro della situazione, quando ci si addentra nei dettagli, le cose si complicano: i campi, i WYSIWYG e i permessi. Quello che rende tutto ancor più delicato è che, se pensate all’implementazione del CMS, probabilmente vi trovate in una di queste due situazioni diversissime tra loro:

1. state creando un nuovo sito e il mondo è la vostra ostrica per l’implementazione del CMS,
2. state gestendo o rinnovando un sito esistente e il setup del content management system vi mette addosso una grande tristezza.

Sebbene ciascuna di queste situazioni abbia i suoi peculiari problemi, che vedremo più avanti, sono entrambe governate non solo dalla prima regola dei CMS, ma anche dalla seconda: due implementazioni di CMS non dovrebbero mai essere esattamente uguali. Ogni sito avrà i suoi bisogni e il CMS dovrebbe essere personalizzato per soddisfare quei bisogni.

Tenendo presente questo, invece di un insieme di prescrizioni, vi offro una serie di domande che dovreste porvi per limitare la libertà dei vostri utenti.

Questo elemento può avere il suo campo?#section1

In molti content management system (mi vengono in mente WordPress e Drupal) i tipi di contenuto hanno di default dei grandi campi di testo in cui si può inserire di tutto. Tutto quello che volete! Prendete in considerazione di limitare questa libertà quanto più possibile dando ad elementi discreti input discreti.

Ogni elemento sulla vostra pagina che ha uno scopo diverso da altri elementi dovrebbe avere un suo input field. Nell’elenco dello staff, la professione di una persona e il nome dovrebbero avere dei campi di input separati, anche se appaiono l’uno accanto all’altro sulla pagina. La foto dovrebbe avere un campo separato per caricare l’immagine. L’orario dell’ufficio nella sidebar dovrebbe avere un suo proprio campo. Le informazioni di contatto al di fuori dell’orario dell’ufficio dovrebbero anch’esse avere un proprio campo. Ricordate: solo perché due oggetti sono uno accanto all’altro visivamente non vuol necessariamente dire che siano così collegati l’uno all’altro dal dover condividere un campo.

Per tutti quelli che pensano che suddividere ogni elemento nel suo campo sia eccessivo e inutile: ricordate che vi dà flessibilità per il futuro. Come ha sottolineato Karen McGrane, suddividere in pezzi il contenuto dà struttura a questo, che a sua volta dà libertà a voi web developer. Vi dà la libertà di fare dei piccoli cambiamenti nel design, come spostare le informazioni di contatto sopra agli orari dell’ufficio, semplicemente con un po’ di lavoro di back-end. E vi dà anche la libertà di fare grandi cambiamenti nel modo in cui viene visualizzato il contenuto, che sia sul sito su cui state lavorando, su una nuova iterazione di quel sito o in un prodotto completamente diverso che si aggancia ai contenuti di tale sito. Questo è il tipo di libertà che volete.

Questo campo può essere più restrittivo?#section2

È una buona idea usare il campo più restrittivo possibile per un dato elemento. Se usate un grande campo di testo, chiedetevi: posso rendere questo campo semplicemente testo invece di HTML in cui si può infilare di tutto? Se è un’immagine, considerate l’uso di un campo image-uploader piuttosto che un media field generico. Se è il nome di una persona, usate un campo di testo semplice. Se è un giorno della settimana, fate scegliere agli utenti uno dei sette giorni della settimana, non fategli inventare il loro.

Restringere i campi rende più semplice l’utilizzo del CMS per fare correttamente e rapidamente il proprio lavoro e può anche essere d’aiuto nel portare consistenza editoriale e visuale al sito. Far scegliere agli utenti il giorno della settimana da un array invece che inserirlo a mano nel campo di testo assicura che tutti i giorni della settimana saranno sempre scritti correttamente e fa sì che le persone non si debbano fermare e ricordare se lo stile dell’azienda è di abbreviare i giorni della settimana o di scriverli per intero. Inoltre, se dovesse cambiare lo stile aziendale, potrete fare dei piccoli aggiustamenti sul backend invece di cambiare il testo in ogni input “giorno della settimana” sul sito.

Restringere i campi è anche uno dei modi più significativi in cui potete far sapere agli utenti del CMS che non possono fare disastri. Usando un campo immagine ristretto, rassicurate implicitamente le persone che se dovessero cercare di caricare il tipo sbagliato di file immagine, il CMS lo rifiuterà. In maniera simile, usare semplice testo invece di un WYSIWYG o del rich text è un modo per far sapere agli utenti che possono copiare il testo da qualunque fonte e incollarlo senza che si creino problemi e che non devono preoccuparsi degli stili del testo.

Tuttavia, ci sono alcune aree in cui essere restrittivi probabilmente fa più male che bene. Per esempio, farà probabilmente più danni di quel che vale l’avere un limite vincolante di caratteri su un campo di testo. Anche se, supponiamo, si tratta di un campo per il nome di una persona nell’elenco dello staff, non causerete molti problemi mettendo il limite dei caratteri a 200 invece che a 40. Inoltre, non guadagnerete granché essendo molto vincolanti con i cosiddetti caratteri speciali. Permetterli potrebbe significare un font file leggermente più grande, ma per la maggior parte dei siti non è possibile o non è consigliabile evitare parole con i diacritici.

Serve questo pulsante nel WYSIWYG?#section3

Così come sono, gli editor WYSIWYG a volte hanno alcune dozzine di pulsanti. Alcuni sono i classici grassetto, corsivo e strikethrough. Alcuni sono degli avanzi provenienti dai giorni dei word processor, come testo giustificato e colore di sfondo. Alcuni sono imperscrutabili: osservando l’intero insieme di pulsanti di CKEditor, vedo un pulsante che ha l’aspetto di una T che porta a spasso una piccola x al guinzaglio, un globo e tre varianti di un blocco per appunti.

La maggior parte dei content management system vi permettono di editare quali pulsanti debbano apparire nel WYSIWYG. Fatelo! Se il campo è un campo di testo che avrà bisogno di un link di tanto in tanto, liberatevi di tutti i pulsanti tranne del pulsante del link. Se una text area ha bisogno solo della formattazione base del testo, lasciate i pulsanti per il grassetto e l’italico e magari le liste ordinate e non ordinate e i link, se è possibile che verranno usati.

Per i campi di testo generici, come le descrizioni dei prodotti o i riepiloghi degli eventi, mi piace tenere quelle stesse opzioni di formattazione. Io spesso tralascio il pulsante per la sottolineatura perché è meglio restringere questo stile ai link, ma includo sempre il pulsante dei link perché i link fanno girare il web.

Per i testi più lunghi, come gli articoli, includo anche i pulsanti per formattare le citazioni, la punteggiatura come il trattino lungo (em dash – non tutti conoscono la scorciatoia da tastiera) e magari le opzione indent e outdent se è possibile che gli utenti abbiano bisogno di creare liste all’interno di liste. Solitamente creo anche dei pulsanti che permettano agli utenti di applicare del markup come gli heading e li etichetto con qualcosa come “Heading 2” piuttosto che “h2”, dal momento che la maggior parte degli utenti di CMS conosce meglio l’Inglese dell’HTML. Generalmente, evito i pulsanti per cambiare font, dimensione, colore o colore di sfondo, che conviene impostare via CSS per tenere separati forma e contenuto.

Questi sono solo alcuni punti di partenza. Oltre a questo dovete conoscere il vostro team editoriale. Se agli scrittori piace usare sarcasticamente lo strikethrough, dategli il pulsante per farlo. O se volete che solo gli editori siano in grado di barrare sarcasticamente le cose che i loro scrittori scrivono, permettete solo agli autori con permesso da editor di avere il pulsante strikethrough.

I pulsanti “vedi sorgente” possono essere complessi. In generale, la mia regola pratica è che gli utenti a livello editore o amministratore dovrebbero avere un pulsante “vedi sorgente” se conoscono HTML. A volte nei WYSIWYG succedono delle cose un po’ bizzarre (rendete qualcosa un heading e l’intero paragrafo diventa un heading) e gli utenti che conoscono HTML troveranno più semplice osservare il codice sorgente e sistemare il markup.

Dovreste usare i WYSIWYG come dei tool di formattazione di base, non come degli strumenti di design. I WYSIWYG a volte hanno una brutta fama perché gli utenti e i clienti li vogliono usare come word processor, uno strumento che dà alla persone il pieno controllo (sebbene un po’ goffo) sull’aspetto delle cose. Dopo tutto, si chiamano “What you see is what you get”. Ma se restringete il WYSIWYG alle sue funzioni essenziali, potete assicurare agli utenti che quello che verrà visualizzato sul sito web andrà bene ogni volta e che non devono preoccuparsi di quello che vedono o di quello che otterranno.

L’utente ha bisogno di questo permesso?#section4

Restringere i permessi di un utente è il modo più semplice per essere sicuri che non possa accidentalmente distruggere il sito. La maggior parte delle persone che aggiorna i contenuti o gli editor non avranno bisogno di trafficare con i permalink, quindi non dategli il permesso di farlo. Se un utente edita solo contenuti esistenti, dovreste evitare di dargli il permesso di creare o cancellare pagine. E così via.

Ecco qualcosa che potete fare per capire di che permessi avrà effettivamente bisogno un utente: quando create un nuovo utente, toglietegli tutti i permessi. Fate login come quell’utente in un browser e come admin in un altro. Nell’account non-admin, cercate di fare tutte le operazioni di cui avrà bisogno quell’utente e aggiungete via via più permessi dall’account admin se ce n’è bisogno.

Come posso cablare l’accessibilità nel sito?#section5

Che cosa c’entra l’accessibilità in un articolo sull’implementazione dei content management system e sui romanzieri russi del XIX secolo? Bene: potete rendere il codice del vostro sito il più accessibile possibile utilizzando gli ARIA roles più cool e testando tutto su uno screen reader, ma se chi aggiorna il contenuto crea un testo grigio su uno sfondo grigio scuro o non si cura del testo dell’alt, il vostro duro lavoro va in fumo. Non potete prevenire tutto ciò, ma potete almeno rendere un po’ più difficile incasinare tutta l’accessibilità del sito.

Anche se non siete alla fine la persona che caricherà un’immagine, per esempio, potete spesso inserire un testo di default per l’attributo alt da back-end. Se state progettando l’elenco dello staff, per esempio, potete prendere il testo di alt da altri campi, in questo modo:

<img src="cool-guy-optimized.jpg" alt="<?php echo name_field; ?>, the <?php echo job_title_field; ?> of Cool Business Guys, LLC" / >

In questo modo, l’alt text ci sarà sempre (e sarà anche più utile e accurato) e chi aggiorna i contenuti non dovrà preoccuparsene.

Oppure, se avete dato elementi discreti a campi di inserimento discreti, potete garantire che tutto abbia una struttura appropriata e accessibile. La maggior parte dei content management system fa questo naturalmente per gli headings h1: mettono il titolo della pagina in un h1 a meno che non specifichiate diversamente. Potete estendere questa funzionalità ad altri oggetti. Mettete quel testo callout in un aside. Mettete quell’orario in un time.

Quanto devo rendere facile l’upload di un’immagine?#section6

Come web developer, siete probabilmente aggiornati su tutte le ultime tecnologie delle immagini. Sapete quando dovreste usare img srcset (la maggior parte delle volte) e quando dovreste usare picture (solo quando dovete fare qualcosa che ricada vagamente nell’art direction). Conoscete i migliori plugin di ottimizzazione delle immagini che sono disponibili solo su quel sito di plugin che avete trovato quella volta. Quando qualcuno vi chiede di creare un SVG in Photoshop, gli direte che non si chiama Vectorshop e riderete della vostra stessa battuta e deciderete di passare un po’ di tempo all’aria aperta questo week-end.

La persona che aggiorna i contenuti probabilmente non conosce queste cose. Anche se siete voi stessi una persona che aggiorna il contenuto, non dovrete ricordarvi questo quando starete semplicemente cercando di caricare una foto della vostra rucola. Questo è il motivo per cui dovreste programmare tutto questo nel vostro sistema. Quando è possibile, ogni immagine sul vostro sito dovrebbe avere il suo campo image-uploader e voi dovreste essere in grado di inserirvi un’immagine di qualunque dimensione in quel campo uploader e far sì che si ridimensioni, ottimizzi e venga inserita nell’appropriato markup responsive.

Tutte queste cose dei content management system richiedono un po’ di lavoro, ma potete farcela. Io credo in voi. Ho visto quanto è robusta la vostra rucola.

Alcune altre domande che potreste ritrovarvi a fare#section7

Ho un problema di implementazione di CMS assolutamente impossibile. Qualche idea?#section8

Fatemi indovinare: state gestendo degli articoli che hanno delle immagini e dei Tweet integrati e magari anche un grafico interattivo. Inoltre, la persona che crea l’articolo avrà bisogno di riposizionare quegli elementi in ogni articolo. Questo è uno dei problemi più delicati e più comuni dei CMS. Lasciate che vi indichi “La battaglia per il campo body” di Jeff Eaton per avere alcune risposte. Questo tipo di problema è totalmente risolvibile con un CMS e, mentre la mia linea guida vi manda nella giusta direzione, Jeff sottolinea alcuni modi in cui si può affrontare questo caso specifico.

Se il problema che vi trovate di fronte è che volete che l’implementazione finale del vostro CMS faccia sì che chiunque la usi ne proclami la sua genialità, “Addestrare il CMS” di Eileen Webb fa al caso vostro. Tra le altre cose, ha alcune idee magnifiche per rendere utile il setup delle vostre pagine editoriali e per renderle semplici da usare.

A volte, quando vi imbattete in quello che sembra un problema ingestibile con un CMS è perché state pensando a come apparirà il vostro contenuto in una pagina particolare e non all’interno della struttura complessiva contenuti/dati. Per questo, guardate la talk di Karen McGrane “Content in a Zombie Apocalypse”. Vi aiuterà a ripensare al modello del contenuto e fa anche delle battute divertenti sui WYSIWYG.

Ok, ottimo, ma da dove comincio?#section9

All’inizio, ho detto che le implementazioni dei CMS sono di due tipi: con la prima, cominciate da zero, il mondo è la vostra piccola, delicata, fredda ostrica: non farete gli stessi errori questa volta; con la seconda, state rinnovando un CMS, le cose non funzionano, l’amore non è vero, Dio è morto, eccetera. Da dove cominciare a porvi queste domande dipende dalla situazione in cui vi trovate.

Se vi trovate nella prima situazione, per certi aspetti la vita è molto più semplice. Tenere a mente quelle domande quando state mettendo il vostro design nei template del CMS renderà più semplice la parte relativa ai campi, e cominciare con dei pulsanti WYSIWYG ragionevoli, con un sistema di caricamento immagini funzionale e con l’accessibilità built-in darà al sito una base solida con cui trafficare in seguito.

La parte difficile è prevedere esattamente in che modo verrà usato il sito. È facile pensare che potrete sostituire il campo della sidebar con un location field e un campo per le informazioni di contatto, ma cosa succede se qualcuno vuole mettere un messaggio speciale riguardante la chiusura festiva nella sidebar ma non ha un posto per farlo? Se state facendo il redesign di un nuovo sito, raccomando di usare come contenuto di esempio il contenuto più fastidioso e più caso limite possibile che trovate sull’attuale sito. Questo di solito vi eviterà di porre troppi limiti. Se il sito non ha ancora contenuti, questo non è un buon modo per costruire un sito web, ma se vivete nel mondo reale e dovete comunque farlo, dovrete avventurarvi nel dare agli utenti troppa libertà e poi restringere più tardi se potete.

Se vi trovate nella seconda situazione, rallegratevi. Non dovete demolire il vostro sito attuale per implementare tutto questo, potete scivolarci dentro gradualmente. Alcune parti sono più semplici da fare di altre e alcune sono più importanti. Se avete un pomeriggio libero, potete sistemare in maniera appropriata tutti i permessi utente e rimuovere i pulsanti dal WYSIWYG. Potreste addirittura essere in grado di aggiustare il vostro sistema di caricamento immagini senza distruggere le immagini già presenti sul sito. Ma probabilmente sarà più difficile dividere gli elementi discreti in campi discreti o restringere i tipi dei campi. I database sono così sensibili! Ma la prossima volta che creerete un nuovo tipo di contenuto, potrete assicurarvi che abbia dei campi discreti e che li avrete ristretti appropriatamente. Anche facendo solo dei pezzetti di queste cose potrete rendere il vostro CMS più efficace.

E le politiche?#section10

Per entrambe le situazioni, in realtà per la maggior parte delle situazioni di web development, la parte tecnica sarà più semplice della parte politica. Come vendete al cliente o al vostro capo le due settimane o poco più extra che passerete a rendere migliore il CMS? Avete scelto un pessimo CMS o cosa?

Nella mia esperienza, non solo è possibile ottenere l’approvazione per il tempo speso in questo modo, ma potete anche ottenere assoluta gratitudine. Raccomando di farne un caso finanziario: passare un certo numero di ore x sul CMS adesso vi farà risparmiare cinque volte tanto lo stesso numero di ore in seguito. Più sarete specifici, più sarete persuasivi. Per esempio, se stimate 16 ore di lavoro per implementare un sistema di caricamento immagini che si occupi dietro le quinte di tutte le dimensioni delle immagini, potete stimare quanto tempo impiegherebbe il content editor per salvare tre diverse dimensioni di immagini, ottimizzarle e caricarle ogni volta che un’immagine deve essere cambiata.

Se questo non dovesse funzionare, ecco alcune frasi sicure che potete usare:

• “Questa è un’organizzazione speciale, unica nel suo genere, quindi ci vuole un po’ più di tempo per essere sicuri che il CMS soddisfi i suoi bisogni unici.”
• “Avete uno staff di talenti che fanno un lavoro importante e noi non vogliamo che passino il loro prezioso tempo a risolvere errori sul sito web.”
• “Vogliamo essere sicuri che non ci sia un modo in cui possiate fare disastri sul sito. In questo modo non dovrete più pagarci di nuovo.”
• “Vedete questa pagina in cui qualcuno ha caricato una GIF di un cane e ha scritto del testo rosso lampeggiante? Posso impedire che accada di nuovo.”

Basta non citare Dostoyevsky e pensare che sia sufficiente.

Illustrazioni: {carlok}