No. 91

Dare una struttura appropriata al contenuto è una delle cose più importanti che possiamo fare, perché più struttura c'è nel contenuto più questo diventa libero. La maggior parte delle volte, le classificazioni e le divisioni del contenuto strutturato permettono la presentazione di tale contenuto su una moltitudine di piattaforme.

Suddividendo il contenuto nei suoi componenti naturali, ne assicuriamo la compatibilità attuale e futura e facciamo in modo che possa essere mostrato su una gran vastità di dispositivi. Gli schemi di metadati di terze parti, come il protocollo Open Graph di Facebook e Twitter Cards, sono basati su questo ideale e stanno rapidamente diventando parte di quello che occorre per avere una presenza online moderna e completa.

Il protocollo Open Graph di Facebook, o OG (da non confondersi con l'album del 1991 di Ice-T "O.G."), si basa sulla nozione di compatibilità, suddividendo in maniera appropriata il contenuto in pezzi, ma dal punto di vista specifico della piattaforma. Anche Twitter ha rilasciato uno schema di metadati proprio, chiamato Twitter Cards. Questi protocolli di metadati assolvono a una funzione simile: forniscono un'esperienza utente migliore attorno al contenuto condiviso sulle piattaforme sociali.

Fondamentalmente, Twitter Cards e OG sono insiemi discreti di metadati. Alcune piattaforme social cercano quei metadati e ne mostrano alcune parti, a seconda di quello che è più appropriato. In Twitter, vengono visualizzati come sommari di articoli, notizie o immagini nel proprio feed. Su Facebook, OG si manifesta chiaramente nell'immagine, titolo e descrizione di un sito web condiviso (si noti che questo aspetto è separato dalla “Graph Search” recentemente lanciata da Facebook: OG fornisce un linguaggio comune per il contenuto, mentre Graph Search permette di ricercare utenti Facebook basandosi sulle relazioni e associazioni all'interno di Facebook stesso).

Ora, se il resto del nostro contenuto è già future-friendly, perché dovremmo aver bisogno di queste cose?

Le persone condividono

Quando vediamo online qualcosa che ci piace davvero, lo condividiamo. Alcuni copiano e incollano l'URL in un'e-mail, altri lo stampano e lo inviano con un francobollo, mentre milioni e milioni di altri usano il proprio social network preferito: Facebook, Twitter, LinkedIn, etc.

Se condividete un link via e-mail, probabilmente darete un minimo di contesto, così che si sappia cosa state inviando. Un URL da solo, che non è stato richiesto, per di più in un'email senza contesto, fa allarmare per tutti i motivi collegati allo spam e al phishing. La maggior parte delle persone evita questa situazione aggiungendo qualcosa del tipo: "Hey, guarda il video di questo gatto. È così carinoooo!". Ma questa operazione richiede un minimo di sforzo.

I produttori di contenuto non hanno molta influenza in questa arena: non ci possiamo portare dietro i metadati della pagina quando si copia l'URL in un'email vuota. Tuttavia, il campo dei social ci dà un po' più di spazio per muoverci.

Gli standard per la condivisione

Ai vecchi tempi, quando il video del gatto veniva condiviso su Facebook, il titolo, la descrizione e l'immagine sarebbero stati riempiti con un qualunque metadato presente sulla pagina. Addirittura, avrebbe potuto trattarsi di un ingarbugliato titolo con del HTML di passaggio contenuto in esso. Probabilmente, avreste visto la descrizione di una homepage del 1998. Oppure come immagine avreste potuto ottenere una versione ritagliata maldestramente del logo. Era chiaro: tutti noi avremmo potuto trarre un gran beneficio da un qualche standard in questo campo.

Quando Facebook cercò di stabilire uno standard per popolare quei piccoli box di contenuti condivisi che vengono mostrati sui vostri feed dei social network, fu così gentile da farlo in maniera aperta. L'amato Dublin Core Metadata Element Set, uno standard del mondo delle biblioteche e dell'informatica, fece da fondamento e da punto di partenza.

Facebook creò questo standard per uso proprio: ha il livello di complessità e le funzioni richieste da Facebook. Tuttavia, altre piattaforme, come LinkedIn e Google+, cominciarono anch'essi a popolare i propri box di condivisione del contenuto con i metadati OG.

Facebook, LinkedIn e Google+ guardarono tutti a OG per gestire il contenuto condiviso, ma in sua assenza, queste piattaforme sociali avrebbero preso qualunque metadato avessero trovato. Questo potrebbe non mostrare la faccia migliore di un'azienda, aggiungendo un'esperienza mediocre per chiunque ne fosse coinvolto.

D'altra parte, Twitter Cards, andava bene per il solo scopo di fornire un'esperienza in Twitter e solo nelle app supportate. La minor differenza tra Twitter Cards e OG sta nel fatto che Twitter si rivolge alle necessità del proprio contenuto e della propria visualizzazione.

L'ambiente unico di Twitter che permette di condividere via retweet creò alcuni problemi di attribuzione. Potrei condividere un link, ma il limite di 140 caratteri non mi permette sempre di commentare o di attribuire in maniera appropriata il contenuto al suo creatore o a chi lo possiede. Twitter Cards cerca di stabilire ufficialmente e di preservare la paternità del contenuto con campi dedicati nello schema di metadati Twitter Cards.

Twitter ha creato in maniera elegante il proprio schema di metadati per mantenere la parità con altre piattaforme social. I creatori del contenuto e i proprietari del sito che incorporano lo schema Twitter Cards possono adesso fornire un'esperienza più ricca di anteprima del contenuto condiviso. Twitter Cards permette alle persone di visualizzare, vedere o ascoltare il contenuto (immagini, video e audio) senza abbandonare l'ambiente di Twitter. Come risultato, le persone si fermano di più su Twitter, cosa che a Twitter piace. (Non solo per gentilezza, ovviamente: in questo modo possono farci vedere più pubblicità).

Content-y fields forever

Come funziona tutto ciò? Se avete percorso la strada del contenuto strutturato, o state per farlo, dovrebbe essere relativamente facile aggiungere gli schemi di metadati di terze parti. Tutto il lavoro viene svolto dal codice messo nella sezione head di ogni pagina. In effetti, trovano la sua ragion d'essere proprio accanto ai meta tag della vecchia scuola.

Quelli della vecchia guardia potrebbero ricordarsi dei tag browser-specific di HTML 3.2 nel 1997. Fortunatamente, OG e Twitter Cards non dipendono da Netscape Navigator. NESSUNA PREOCCUPAZIONE. Ma questo sa ancora un po' di browser wars, costringendoci tutti ad aderire ad uno standard rigido dettato da un'entità esterna. Il contenuto strutturato intende liberare il contenuto, non imbrigliarlo. E cosa succederà quando apparirà un altro schema di metadati?

Certo, ci sono delle similarità tra questi schemi di metadati di terze parti e i tag browser-specific. Implementarli potrebbe sembrare la cosa meno future-friendly da fare. Fondamentalmente, i proprietari di siti peseranno i costi dell'implementazione rispetto alle migliorie all'esperienza d'uso e ai benefici di una significativa base di utenti potenziali (come Facebook e il suo miliardo di utenti). Le opzioni per i campi disponibili in entrambe questi schemi includono formati e tipi multipli. Questa è una buona cosa, dal momento che il contenuto condiviso assume svariate forme: dai video dei gatti alle GIF animate fino alle solite vecchie pagine web.

Per il bene dell'efficienza, è meglio implementare le basi e aggiungere il supporto solo per i formati e i tipi di contenuto che pianificate di pubblicare (e, di conseguenza, incoraggiarne la condivisione). Se l'audio non fa parte dell'inventario, allora non c'è bisogno di impostare il CMS perché gestisca gli schemi di metadati per questo tipo di contenuto.

Sia OG sia Twitter Cards hanno lo scopo di fornire una presentazione appropriata all'interno della piattaforma per il contenuto condiviso nelle sue forme più popolari:

  • Gli articoli avranno un riassunto testuale e una piccola immagine di anteprima
  • I files audio avranno un player audio
  • I video avranno un player video
  • Le immagini avranno un'immagine di anteprima più grande

Gli sviluppatori di OG hanno creato molti oggetti predefiniti - tipi di contenuto come video, file audio, pagine web, etc. - ciascuno con le sue proprietà meta. Quando il tipo dell'oggetto è un file audio o un video, i metadati andranno ad associare a questi il player adeguato, se è possibile. Questa lista di attributi fornisce dei dettagli su ciascun meta tag di un articolo:

<meta property="og:type"	 content="article"> 
<meta property="og:url"		 content="URL of this object">
<meta property="og:site_name"	 content="Name of site hosting article">
<meta property="og:image"	 content="URL to an image">
<meta property="og:title"	 content="Name of article">
<meta property="og:description"  content="Description of object"> 
<meta property="article:author"	 content="URL to Author object">
<meta property="article:section" content="Section of article">
<meta property="article:tag"	 content="Keyword">

Tutto ciò contribuisce a farlo apparire così su Facebook:

Il link di Facebook al sito web della St. Paul Chamber Orchestra

Twitter Cards ha un protocollo simile, con proprietà specifiche stabilite per gli articoli, i video, l'audio e le immagini. I metadati per il contenuto di tipo articolo di Twitter Cards hanno questo aspetto:

<meta name="twitter:card"	 content="summary">
<meta name="twitter:url"	 content="URL of this content">
<meta name="twitter:title"	 content="Name of article">
<meta name="twitter:description" content="Description of content">
<meta name="twitter:image"	 content="URL to an image">

Questi oggetti opzionali di Twitter Card ci permettono inoltre di attribuire il contenuto a un'organizzazione o all'autore in Twitter:

<meta name="twitter:site"	content="@username">
<meta name="twitter:site:id"	content="Twitter ID">
<meta name="twitter:creator"	content="@username">
<meta name="twitter:creator:id"	content="Twitter ID">

Questo è il suo aspetto su Twitter:

Creare questo contenuto: concentratevi e compilateli

Anche i metadati sono contenuti. Sono soggetti a tutti gli stessi processi, workflow e protocolli di governance che potreste aver già messo in atto. Come sempre, dovrebbero supportare il messaggio principale della pagina. Questi schemi di metadati di terze parti hanno anch'essi dei limiti pratici.

Limiti del campo

Dovete essere coscienti del fatto che alcuni campi hanno dei limiti di visualizzazione sui vari device, in particolar modo i campi di descrizione. Quando scrivete queste descrizioni, rimanete sotto i 160 caratteri e il troncamento automatico (e a volte dipendente dal display) di questo campo non dovrebbe più essere un problema.

Selezione dell'immagine

Immagini appropriate ed efficaci possono fare la differenza tra un amico che evita oppure clicca su un link sul suo news feed. Le linee guida per le immagini per le pagine di tipo articolo in OG sono piuttosto semplici: 200×200px minimo con un aspect ratio di 3:1. Tuttavia, un'immagine quadrata vi permetterà di usare meglio lo spazio. Twitter Cards ridimensiona qualunque immagine oltre i 120×120px, perciò andrete sul sicuro usando la stessa immagine 200×200px che avete già creato per la vostra og:image.

Messaggio

Concentrandovi sul messaggio nella pagina, riassumetelo nei metadati. Se avete realizzato la pagina con una singola idea o un singolo concetto in testa, la descrizione dovrebbe risultare piuttosto semplicemente. Se non è così, date delle priorità e assicuratevi che il messaggio sia consistente. Se una pagina ha quattro punti chiave, concentratevi su uno solo. Il titolo, la descrizione e l'immagine dovrebbero tutti allinearsi con il punto che volete mettere in evidenza in queste piattaforme sociali.

Ad esempio, Il nuovo tablet Surface di Microsoft ha avuto parecchio spazio sulla stampa quando è stato lanciato. La pagina di Surface Windows 8 Pro su Microsoft.com non era stata preparata per il nuovo mondo di Open Graph. (Non usa né OG né Twitter Cards).

Questa pagina ha diversi messaggi, con una gerarchia stabilita dal posizionamento nella pagina:

  1. Comprate questo dispositivo
  2. Potete mettere delle app su questo dispositivo
  3. Questo dispositivo è sicuro
  4. Questo dispositivo ha delle performance stellari
  5. Questo dispositivo ha un bello schermo
  6. Usate uno stilo per scrivere su questo dispositivo come su un Palm Pilot
  7. Comprate questo dispositivo

Tuttavia, questa gerarchia non è rinforzata dai metadati. Microsoft dà alla performance di Surface il massimo intitolando la pagina “Surface Windows 8 Pro è potente.” Ma non vedo nulla riguardante la performance finché non scendo e arrivo al quarto messaggio sulla pagina. Tutto questo è piuttosto disconnesso. La descrizione meta della pagina dice ancora meno.

Provate a condividere questo link su Facebook e questo approccio non mirato diventa ancora più evidente. Le persone possono scegliere tra due immagini a 1280×450px, lungi dalla dimensione o dall'aspect ratio ottimali per essere mostrati nei news feed delle piattaforme social. Contemporaneamente, la ripetizione della call to action "Learn more" impedisce fortunatamente la presenza del vecchio "click here", ma tuttavia sa ancora di modelli di marketing da vecchia scuola.

Cosa avrebbe potuto fare Microsoft in questa situazione? Avrebbe potuto rappresentare meglio la pagina sulle piattaforme social concentrandosi su uno dei messaggi principali della pagina. Quindi:

  • Usare un titolo più convincente e descrittivo. Ovviamente, Surface Windows 8 Pro è potente, ma rispetto a cosa? Rispetto alla concorrenza? A un sollevatore di pesi? A una Ford Mustang? Come potrà aiutarmi a fare quello che devo fare? E non hanno ancora detto che si tratta di un tablet: un dettaglio piuttosto importante.
  • Sfruttare quei 160 caratteri nella descrizione. Riassumervi qui la pagina, poi magari dire "learn more". Cos'altro saprò se visito questa pagina? Posso comprarne uno da qui? Ha il Solitario? Perché dovrei prenderlo in considerazione invece di uno della concorrenza?
  • Fornire un'immagine interessante e rappresentativa. Le piattaforme social sono avare di spazi. Usateli. Create un'immagine che rappresenti e supporti accuratamente il vostro messaggio. E formattatela in maniera appropriata per evitarne il taglio attraverso un crop automatico.
  • Dare alle persone un motivo per cliccare. Presentate una call to action chiara e concisa, adatta alla piattaforma e assicuratevi di dire cosa offrite. (Tutti consigli testati dal tempo).

Workflow e implementazione diventano triage e allenamento

Aggiungere OG e Twitter Cards in pagine esistenti e datate potrebbe essere un po' più complesso che incorporarli nel nuovo contenuto, specialmente se avete migliaia e migliaia di pagine.

Considerate un approccio a fasi per fornire consistenza a tutta l'intera presenza online, facendo con il tempo i miglioramenti alle altre aree di profilo più basso. Concentratevi a mettere le cose a posto prima sulle risorse di grande impatto, come le pagine che vedono già una forte attività di condivisione. Poi, dedicatevi a soddisfare gli standard minimi sulle altre.

Sebbene la maggior parte delle pagine di un sito siano tecnicamente condivisibili, le persone non le condivideranno per forza. Pensate di ottimizzare la pagina "Contatti" per la condivisione? Pessima idea. Mappate le tipologie delle vostre attuali pagine ad alcune divisioni semplici di metadati di terze parti:

Pagine frequentemente condivise

Pagine che supportano campagne attive, blog post, pagine dei prodotti e pagine con profili e traffico alti.

  • Richiede più tempo e risorse.
  • Create dei metadati specifici della pagina con il contributo di esperti in materia. Scrivete con la stessa serietà dell'altro contenuto di marketing o promozionale.
  • Usate titoli, descrizioni e immagini unici.

Pagine condivise raramente

Pagine di transazione, di passaggio o di navigazione.

  • Meno "resource-intensive".
  • Create contenuto in forma di metadati specifico per la sezione o l'argomento per fornire un dettaglio rilevante (ma non a livello di pagina).
  • Usate titoli specifici e descrizioni specifici per le sezioni nelle pagine, ma immagini generiche (come il logo o un'icona).

Pagine che non si vogliono condividere

Tra queste ci sono pagine come i contatti, le informative legali e la mappa del sito.

  • Minore l'impatto sulle risorse, più facile sarà mantenerle.
  • Create contenuti metadati generici per soddisfare gli standard minimi del brand.
  • Usate titoli specifici, ma descrizioni generiche per tutto il sito e immagini generiche (anche il vostro logo o l'icona funzionano bene in questo caso).

Comunicate l'importanza di questi nuovi campi ai creatori di contenuto e a chi lo approva, molti dei quali saranno degli utenti appassionati di Facebook. Mostrategli un buon esempio di un sito che usa con successo OG. Poi mostrategli un sito che non usa affatto OG. Ci sono buone probabilità che capiranno immediatamente.

Una chiara comprensione degli usi dei pezzi di contenuto strutturato gli darà un contesto di cui hanno bisogno per creare del contenuto appropriato. (È importante notare che non si tratta di qualcosa di peculiare a OG o a Twitter Cards: questa comprensione è importante per tutto il contenuto strutturato).

Una parola di (cauto) incoraggiamento

Proprio come con qualsiasi relazione di terze parti, alcune cose sono leggermente fuori dal proprio controllo. Ci siamo abituati a cambiamenti regolari nell'hardware, negli algoritmi di ricerca di Google e alle impostazioni della privacy di Facebook. Questi cambiamenti sono inevitabilmente fastidiosi: tutto ciò costituisce un motivo ulteriore per tenere d'occhio l'evoluzione e lo sviluppo di questi (ed altri) strumenti e piattaforme di terze parti.

Mentre l'implementazione degli schemi di metadati di terze parti aggiungerà un carico di lavoro alla creazione del contenuto, lo sforzo extra fornirà un'esperienza utente molto migliore sulle varie piattaforme e sui numerosi device, sia esistenti che futuri. Suddividere il contenuto in pezzi discreti con un occhio all'applicazione e alla flessibilità universale è la strada per il futuro. "Like" it or not.

Illustrazioni: Carlo Brigatti

Share/Save/Bookmark
 

Discutiamone

Ti sembra interessante? Scrivi tu il primo commento


Cenni sull'autore

Clinton Forry

Clinton Forry è senior content strategist in Ameriprise Financial. Scrive sul contenuto sul suo blog Content-ment. È su Twitter con il nickname @wd45. Quando non pensa al contenuto, probabilmente pensa ai dischi di jazz in vinile. Gli piace indossare cravatte con le sue camice a motivi cachemire e floreali.