Contenuti pronti per il futuro

Preparare la struttura#section1

La maggior parte dei discorsi sul contenuto strutturato si buttano a capofitto negli aspetti tecnici: XML, DITA, microdata, RDF. Tuttavia, la struttura non riguarda solo i metadati e il markup: è il significato dei metadati e del markup. Prima di cominciare a buttare in giro degli acronimi, abbiamo bisogno di avvicinarci al contenuto stesso, creando un framework per prendere decisioni intelligenti riguardanti la sua struttura. Solo allora potremo affrontare la tecnologia in modi significativi e utili. Quindi, aspettate un attimo, questa parte è importante.

1. Siate significativi#section2

State già progettando siti con in mente degli obiettivi riguardanti sia gli utenti sia l’azienda, giusto? Bene. Ora, dovete tradurre questi obiettivi su una scala più piccola, applicandoli ad ogni tipo di contenuto che avete: blog post, articoli, contenuto a rotazione o descrizioni di prodotti. Per fare ciò, dovete essere in grado di rispondere a domande come:

• Questo tipo di contenuto in che modo supporta gli obiettivi generali del sito?
• Perchè un utente ne dovrebbe aver bisogno?
• Che cosa ottiene l’azienda pubblicandolo?
• L’azienda cosa vuole che l’utente faccia con tale contenuto?

Così come è di importanza cruciale stabilire gli obiettivi del sito prima di lanciarsi in decisioni di design, dovete sapere quello che si vuole ottenere con ciascun tipo di contenuto prima di prendere decisioni riguardanti il suo trattamento nei diversi contesti. Altrimenti, come potete essere sicuri che il contenuto continui a fare il suo lavoro mentre si sta adattando per soddisfare le esigenze di ciascun dispositivo su cui viene visualizzato?

(Ora, se realizzate che il vostro contenuto non sta ottenendo alcunchè o non sapete con che tipi di contenuto avrete a che fare, avete tra le mani un problema ben più grande. Prima di fare amicizia con il futuro, andate dal vostro cliente o dal vostro capo e cercate di capire quello che ha importanza).

2. Rendetelo minuscolo#section3

Ok, sapete perchè esistono gli articoli o le ricette o le poesie umoristiche o qualunque altro tipo di contenuto con cui avete a che fare. Bene, perchè adesso è il momento di diventare ancor più granulari, spezzando quei tipi di contenuto nei loro elementi costitutivi.

Gli elementi specifici che dovete considerare cambieranno molto a seconda del tipo di contenuto su cui andrete a lavorare, quindi cominciate con l’identificare tutti i pezzi di contenuto che potete trovare in ciascun tipo di informazione. Potrebbe trattarsi di cose come i titoli, i sommari, il contenuto del body, le liste degli ingredienti, le recensioni, le citazioni, gli estratti, le immagini, i video, i sottotitoli, gli articoli correlati, i nomi degli autori, le indicazioni, gli indirizzi e molto altro ancora.

Come esempio, prendiamo dal famoso sito Epicurious una ricetta per la pizza con gli asparagi, le patate a spicchi ed il formaggio di capra.

Le ricette sono un tipo di contenuto piuttosto comune, quindi potreste aver pensato di sapere già come suddividerla: titolo, ingredienti, indicazioni. Ma guardate meglio e vedrete un intero universo di elementi connessi tra loro che contribuiscono a questo singolo pezzo di contenuto:

• Titolo
• Attribuzione della pubblicazione
• Data della pubblicazione
• Autori
• Per quante persone
• Breve descrizione
• Immagine
• Ingredienti
• Preparazione
• Abbinamenti di vino
• Voti
• Revisioni
• Ingredienti principali
• Tipo di cucina
• Considerazioni dietetiche
• Collezione di ricette correlate

Un information architect o un content strategist tornano di sicuro comodi nel determinare questi attributi, ma tutti nel team devono essere molto coinvolti, perchè avrete bisogno di questi pezzi per prendere importanti decisioni riguardo al modo in cui il contenuto risponderà ai cambiamenti di device e di display.

3. Siate significativi#section4

Capire quali sono i pezzi di contenuto esistenti è solo l’inizio. Adesso dovete capire perché ogni singolo pezzo è importante per il tutto e quanto è importante. questo ci permette di prendere decisioni sul modo in cui è organizzato, come sono assegnate le priorità e come viene visualizzato su monitor con dimensioni diverse, in contesti diversi o per scopi diversi.

Potete cominciare a farlo considerando:

• in che modo contribuisce questo elemento allo scopo del contenuto?
• che significato si perde se viene tolto questo elemento?
• che relazioni esistono tra questo elemento e gli altri?

Se questo fosse un mio progetto, io farei grandi ricerche negli obiettivi dell’azienda, tra gli use patterns del contenuto attuale e tra i bisogni degli utenti prima di arrivare a questo punto. Ma per lo scopo di questo esempio, lavorerò facendo delle supposizioni. Dal momento che Epicurious è un editore, assumo che voglia aumentare i page views per far aumentare i ritorni economici degli annunci pubblicitari. Dal momento che è un sito di ricette, supponiamo che gli utenti ci arrivino per trovare qualcosa che vogliano cucinare.

Questo scenario potrebbe tradursi in un obiettivo a livello del contenuto tipo “le ricette dovrebbero essere irresistibili, specifiche ed in relazione tra loro, così che gli utenti che vogliano provare a prepararle, siano in grado di capire se soddisfano le proprie necessità e infine vogliano vedere altri contenuti di Epicurious.”

Tenendo ben presente tale obiettivo rispetto a questi elementi di contenuto, emergono alcune interessanti domande:

• Rimuovere tutti quegli elementi tra loro correlati potrebbe sembrare un modo semplice per ridurre l’ammasso di scritte per le dimensioni più piccole degli schermi, ma fare così potrebbe ridurre il numero di pagine visitate da un utente?
• Se facciamo in modo che il contenuto della sidebar finisca sotto il contenuto principale al ridursi della dimensione dello schermo, gli utenti si sentiranno frustrati perché devono passare attraverso gli ingredienti per arrivare alla valutazione della ricetta?
• L’interesse degli utenti varia se in una ricetta togliamo l’immagine?
• Un titolo, se lo si mostra da qualche altra parte senza la descrizione nel sommario, dice cose sufficientemente significative all’utente?

Si tratta di domande difficili a cui dare delle risposte. Gli abbinamenti dei vini possono risultare estremamente affascinanti per gli aspiranti sommelier e totalmente inutili per un astemio. Gli ingredienti potrebbero essere una prima fermata critica per le persone con allergie alimentari ma secondari per chi non ne soffre.

Probabilmente non si riusciranno mai ad indovinare in anticipo le preferenze di tutti gli utenti, ma più comprendiamo le relazioni tra le informazioni, più i compromessi propri di ciascuna decisione del design saranno chiari e saremo più preparati per quelle difficili telefonate.

Ad esempio, in molti design responsive, le sidebar vengono spostate immediatamente sotto al contenuto principale nel caso in cui le pagine siano visualizzate sui display degli smartphone. Ma questa soluzione è sempre adeguata? Nel nostro caso, le votazioni, le valutazioni e gli ingredienti principali danno ai lettori un mezzo diretto per valutare la ricetta e spostare queste informazioni sotto alle sezioni ingredienti e preparazione potrebbe renderli del tutto inutili.

Questo è il punto dell’adattare il contenuto ai vari layout: ogni caso è un caso a parte. Le regole “una sola per tutti” riguardo a come dovrebbe reagire il contenuto molto probabilmente non saranno utili nel caso dei vostri molteplici contenuti, il che implica che non saranno utili per i bisogni dei vostri utenti e nemmeno per gli obiettivi di business. Inoltre, con l’emergere di più dispositivi e tecnologie, dovrete sviluppare nuove regole e trovare nuovi compromessi.

La buona notizia è che non abbiamo bisogno della sfera di cristallo per cominciare ad agire: possiamo cominciare da subito semplicemente migliorando il modo in cui memorizziamo il nostro contenuto.

4. Organizzatevi#section5

Il futuro è attraente, i content management systems non lo sono. Tuttavia il vostro CMS potrebbe benissimo essere ciò che sta fra il vostro contenuto attentamente studiato e la sua capacità di viaggiare. Pensate agli elementi che abbiamo identificato e alle relazioni e priorità che li definiscono. Tra i CMS con cui avete già lavorato, ce n’è qualcuno pronto per questo livello di contenuto? Se sì, siete in minoranza. Noi altri dobbiamo fare un po’ di lavoro.

Un’organizzazione che ha fatto passi da gigante per rendere il proprio CMS pronto per il futuro è la National Public Radio. Nel 2009, la NPR lanciò una metodologia chiamata COPE: Create Once, Publish Everywhere [Crea una volta, Pubblica ovunque, ndt], usando la quale ogni storia viene inserita in un insieme discreto di campi all’interno del CMS e poi resa disponibile per altre piattaforme (come il sito NPR, le applicazioni per ogni device specifico tipo iPad e iPhone, il sito di musica di NPR ed i siti delle stazioni locali affiliate a NPR) attraverso una API.

Il CMS di NPR supporta una gran varietà di elementi di contenuto, ma solo quattro di questi sono obbligatori: titolo, breve riassunto, descrizione più lunga e data, come ci spiega Zach Brand, il capo del reparto tecnico di NPR Digital Media. Attributi aggiuntivi come immagini, audio o autori sono tutti opzionali. Una volta inserita nel CMS la storia viene distribuita via API ed infine pubblicata usando varie combinazioni di elementi determinati dalle necessità della piattaforma sulla quale la si sta pubblicando.

Se vogliamo sistemi che gestiscano questo tipo di contenuto modulare e che possa muoversi rapidamente, è il momento di acquisire più familiarità con i nostri CMS e con le persone che li sviluppano, di integrarli e modificarli. Forti delle nozioni che abbiamo acquisito grazie a delle analisi approfondite, avete adesso gli strumenti per adottare un approccio strategico alla gestione del contenuto, che vi aiuterà a:

• essere sicuri che quelli che si concentrano sulle caratteristiche e sulle capacità del CMS capiscano il vostro contenuto e quello che dovrebbe far ottenere;
• spiegare i tipi di contenuto di cui avrete bisogno e quali elementi richiedono, nello stesso modo in cui NPR ha definito gli attributi delle sue storie;
• comprendere le possibilità ed i limiti del proprio CMS e collaborare alla creazione di modi per gestirli;
• sollevare il team tecnico da un peso dandogli delle direttive ragionate e specifiche per informarli sui requisiti del CMS.

Questo lavoro di base vi sarà molto utile anche se state gestendo un sito web molto semplice, ma appena comincerete a condividere il contenuto attraverso più dispositivi e canali, diventerà critico. Con un CMS organizzato attorno a pezzi di contenuto modulari e significativi, sarete pronti per crere regole che descrivano come quel contenuto si dovrà adattare e spostare e avrete a disposizione i sistemi che vi permetteranno di implementarli.

5. Strutturatevi#section6

C’è un motivo per cui questo articolo non comincia con un’introduzione su XML: la tecnologia non vi può aiutare a prendere delle buone decisioni, vi può solo aiutare ad implementarle. Tuttavia, gli elementi di contenuto devono alla fine essere tradotti in codice, quindi anche se il vostro lavoro non è scrivere markup, dovremmo tutti cominciare a familiarizzare con i tool esistenti che ci permettono di scriverlo.

Il contenuto strutturato non è una novità: i comunicatori tecnici hanno utilizzato DITA (Darwin Information Typing Architecture) per anni e non ha nulla di particolarmente futuristico. È basato su XML, un linguaggio di markup che dà ai componenti del contenuto un significato intrinseco quando vengono visualizzati al di fuori del loro database, DITA crea e pubblica le informazioni tecniche in moduli di contenuto: piccoli pezzi di informazioni pensati per il riutilizzo e la categorizzazione per argomento.[1] Progettato da IBM per gestire il contenuto tecnico all’interno dell’azienda, è usato prevalentemente per cose come la documentazione di riferimento.

Molti nuovi comunicatori tecnici insistono nel dire che DITA dovrebbe essere l’approccio standard per strutturare, ma non ha mai preso piede. Tra l’altro non è l’unico modo con cui strutturare il contenuto. Al momento, HTML5 supporta il markup semantico attraverso la sua estensione microdata, che va oltre i tradizionali tag di presentazione e permette di usare il markup per il contenuto con HTML standard compliant e semanticamente ricco.[2] Ovviamente, HTML5 è esso stesso una working draft e non è chiaro se i microdati si diffonderanno o se offriranno sufficiente specificità per i nostri contenuti. Ad esempio, alla fine dello scorso anno, l’elemento “time” è stato rimosso in favore del più generico “data”.

C’è anche Schema.org, un approccio basato sui microdati lanciato nel 2010 da Bing, Google e Yahoo!. Pensato per creare un linguaggio comune tra i motori di ricerca, Schema.org sistema i microdati in tassonomie di tipi di contenuto che cominciano genericamente e si specializzano man mano che gli elementi si diramano. I critici, tuttavia, sottolineano che Schema.org è un sistema chiuso: sono i motori di ricerca a dirci quali strutture sono importanti, piuttosto che lasciare che siano i proprietari del contenuto a definirle.

Molte persone si sono appassionate al dibattito su quale sia il migliore tra questi approcci e sul perché tutti gli altri sono sbagliati. Io non faccio parte di questo gruppo perché siamo molto lontani da un metodo di markup definitivo e comunque al momento nessuno di questi supporta tutti i tipi di contenuto. Usate quello che attualmente ha più senso per il vostro progetto e in effetti potrebbe anche implicare che non vi dobbiate preoccupare del markup proprio adesso.

Dare vita alla struttura#section7

Il lavoro che mettiamo nell’arrivarci è molto più importante del markup: le regole e le relazioni determinate analizzando il contenuto da vicino e l’attenzione verso il suo messaggio ed il suo scopo. Dopo tutto, la “semantica” definisce, tipicamente, il significato del linguaggio. Qualunque sia il linguaggio di markup che usate, non sarà semantico a meno che non porti in primo piano il significato, il che spiega perché non potete cominciare dal markup: è il punto d’arrivo.

Penso che questo sia il motivo per cui il contenuto strutturato è spesso stato descritto come troppo tecnico ed utilitaristico per la folla tradizionale del web, perché abbiamo lasciato fuori da queste conversazioni il lato editoriale, quello sperimentale, la parte che dà vita al contenuto.

Non si può continuare così: il contenuto pronto per il futuro non c’entra con il diventare esperti di XML o con il supporre che i microdati risolveranno i nostri problemi. Riguarda l’osservazione delle strutture attraverso la lente del significato e dello storytelling e creare relazioni tra le discipline in modo tale che i nostri database riflettano questa complessità e ricchezza.

Non abbiamo tutte le risposte ma sappiamo bene da dove cominciare: dal contenuto stesso. Man mano che suddividiamo il nostro contenuto ne analizziamo gli elementi e documentiamo le relazioni che fanno diventare questi elementi un insieme significativo, possiamo cominciare a creare e gestire il contenuto in maniera duratura, pronto per qualsiasi cosa il futuro abbia in serbo per noi.

La tecnologia cambierà, gli standard si evolveranno, ma il bisogno di comprendere il nostro contenuto, il suo scopo, significato, struttura, relazioni e valore rimarrà. Quando potremo adottare questo modo di pensare, libereremo il nostro contenuto, sicuri che sopravviverà intatto nel suo grande viaggio verso un futuro ignoto.

Riferimenti#section8

[1] Per un’introduzione a DITA da una prospettiva tecnico-commerciale, scaricate il white paper del Rockley Group: Preparing for DITA: What you need to know.

[2] Vedi Microdata: HTML5’s Best-Kept Secret su Web Monkey e HTML5 Microdata: Why isn’t anyone talking about it? di Brian Cray.

Illustrazioni: {carlok}