{"id":370,"date":"2013-04-10T15:12:00","date_gmt":"2013-04-10T13:12:00","guid":{"rendered":"https:\/\/alistapart.com\/it\/article\/contenuto-like-abile-diffondere-messaggio-con-metadai\/"},"modified":"2013-04-10T15:12:00","modified_gmt":"2013-04-10T13:12:00","slug":"contenuto-like-abile-diffondere-messaggio-con-metadai","status":"publish","type":"article","link":"https:\/\/alistapart.com\/it\/article\/contenuto-like-abile-diffondere-messaggio-con-metadai\/","title":{"rendered":"Contenuto “Like”-abile: diffondete il vostro messaggio con i metadati di terze parti"},"content":{"rendered":"

Dare una struttura appropriata al contenuto \u00e8 una delle cose pi\u00f9 importanti che possiamo fare, perch\u00e9 pi\u00f9 struttura c’\u00e8 nel contenuto pi\u00f9 questo diventa libero. La maggior parte delle volte, le classificazioni e le divisioni del contenuto strutturato<\/a> permettono la presentazione di tale contenuto su una moltitudine di piattaforme.<\/p>\n

Suddividendo il contenuto nei suoi componenti naturali, ne assicuriamo la compatibilit\u00e0 attuale e futura e facciamo in modo che possa essere mostrato su una gran vastit\u00e0 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.<\/p>\n

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\u00e0, 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<\/a>, chiamato Twitter Cards. Questi protocolli di metadati assolvono a una funzione simile: forniscono un’esperienza utente migliore attorno al contenuto condiviso sulle piattaforme sociali.<\/p>\n

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 \u00e8 pi\u00f9 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 \u00e8 separato dalla \u201cGraph Search\u201d 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).<\/p>\n

Ora, se il resto del nostro contenuto \u00e8 gi\u00e0 future-friendly, perch\u00e9 dovremmo aver bisogno di queste cose?<\/p>\n

\n

Le persone condividono<\/h2>\n

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.<\/p>\n

Se condividete un link via e-mail, probabilmente darete un minimo di contesto, cos\u00ec che si sappia cosa state inviando. Un URL da solo, che non \u00e8 stato richiesto, per di pi\u00f9 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. \u00c8 cos\u00ec carinoooo!”. Ma questa operazione richiede un minimo di sforzo.<\/p>\n

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\u00e0 un po’ pi\u00f9 di spazio per muoverci.<\/p>\n<\/div>\n

\n

Gli standard per la condivisione<\/h2>\n

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.<\/p>\n

Quando Facebook cerc\u00f2 di stabilire uno standard per popolare quei piccoli box di contenuti condivisi che vengono mostrati sui vostri feed dei social network, fu cos\u00ec gentile da farlo in maniera aperta. L’amato Dublin Core Metadata Element Set<\/a>, uno standard del mondo delle biblioteche e dell’informatica, fece da fondamento e da punto di partenza.<\/p>\n

Facebook cre\u00f2 questo standard per uso proprio: ha il livello di complessit\u00e0 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.<\/p>\n

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.<\/p>\n

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\u00e0 del proprio contenuto e della propria visualizzazione.<\/p>\n

L’ambiente unico di Twitter che permette di condividere via retweet cre\u00f2 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\u00e0 del contenuto con campi dedicati nello schema di metadati Twitter Cards.<\/p>\n

Twitter ha creato in maniera elegante il proprio schema di metadati per mantenere la parit\u00e0 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\u00f9 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\u00f9 su Twitter, cosa che a Twitter piace. (Non solo per gentilezza, ovviamente: in questo modo possono farci vedere pi\u00f9 pubblicit\u00e0).<\/p>\n<\/div>\n

\n

Content-y fields forever<\/h2>\n

Come funziona tutto ci\u00f2? 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.<\/p>\n

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\u00e0 esterna. Il contenuto strutturato intende liberare il contenuto, non imbrigliarlo. E cosa succeder\u00e0 quando apparir\u00e0 un altro schema di metadati?<\/p>\n

Certo, ci sono delle similarit\u00e0 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 \u00e8 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.<\/p>\n

Per il bene dell’efficienza, \u00e8 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’\u00e8 bisogno di impostare il CMS perch\u00e9 gestisca gli schemi di metadati per questo tipo di contenuto.<\/p>\n

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\u00f9 popolari:<\/p>\n