{"id":242,"date":"2012-03-18T09:30:35","date_gmt":"2012-03-18T08:30:35","guid":{"rendered":"https:\/\/alistapart.com\/it\/article\/contenuti-pronti-per-il-futuro\/"},"modified":"2012-03-18T09:30:35","modified_gmt":"2012-03-18T08:30:35","slug":"contenuti-pronti-per-il-futuro","status":"publish","type":"article","link":"https:\/\/alistapart.com\/it\/article\/contenuti-pronti-per-il-futuro\/","title":{"rendered":"Contenuti pronti per il futuro"},"content":{"rendered":"<div class=\"paragrafo\">\n<p><img decoding=\"async\" src=\"http:\/\/alistapart.com\/it\/wp-content\/uploads\/sites\/2\/2012\/03\/n46b.png\" border=\"0\" align=\"left\" \/>Il futuro \u00e8 flessibile e noi ci stiamo adattando ad esso. Dal\u00a0<a href=\"http:\/\/www.alistapart.com\/articles\/responsive-web-design\/\" target=\"_blank\" title=\"Responsive Web Design by Ethan Marcotte\" rel=\"noopener noreferrer\">responsive web design<\/a> al pensiero\u00a0<a href=\"http:\/\/www.futurefriend.ly\/\" target=\"_blank\" rel=\"noopener noreferrer\">futurefriend.ly<\/a>, ci stiamo rapidamente dirigendo verso un web pi\u00f9 fluido, meno fisso e pi\u00f9 facilmente accessibile attraverso una moltitudine di dispositivi.<\/p>\n<p>Abbracciando questo cambiamento, dobbiamo anche rinunciare al controllo sul nostro contenuto, liberandolo dai vincoli della pagina web tradizionale per permettergli di adattarsi ai vari display e contesti secondo necessit\u00e0 . Nelle parole di\u00a0<a href=\"http:\/\/bradfrostweb.com\/blog\/web\/for-a-future-friendly-web\/\" target=\"_blank\" title=\"For a Future Friendly Web\" rel=\"noopener noreferrer\">Brad Frost<\/a> di\u00a0<a href=\"http:\/\/futurefriend.ly\/\" target=\"_blank\" rel=\"noopener noreferrer\">futurefriend.ly<\/a>: \u201cpreparate il vostro contenuto perch\u00e8 possa andare ovunque, perch\u00e8 andr\u00e0 ovunque\u201d.<\/p>\n<p>Ma non \u00e8 ancora il momento di mollare i freni: il nostro contenuto \u00e8 ben lontano dall&#8217;essere pronto per il futuro. Quando viene estratto dalle pagine che abbiamo attentamente progettato in cui si trova oggi, la maggior parte del contenuto diventa testo indifferenziato, si perde il suo significato se non si trova nel contenitore dove l&#8217;avevate messo.<\/p>\n<p>Possiamo fare di meglio. Piuttosto che accettare questi \u201cagglomerati di contenuto\u201d, come li definisce\u00a0<a href=\"http:\/\/www.lukew.com\/ff\/entry.asp?1434;\" target=\"_blank\" title=\"Luke Wroblewski\u2019s notes on Karen McGrane at An Event Apart\" rel=\"noopener noreferrer\">Karen McGrane<\/a>, possiamo adottare dei pezzi significativi e modulari pronti per girare tra i vari dispositivi.<\/p>\n<p>Questo \u00e8 un problema di content strategy, vero. Ma ascoltate, designer, developer e &#8220;UXers&#8221;: non avete pi\u00f9 scuse. Questo lavoro implica delle conoscenze editoriali, architetturali e tecniche.<\/p>\n<p>Questo progetto \u00e8 per tutti noi.<\/p>\n<div>\n<h2>Preparare la struttura<\/h2>\n<p>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: \u00e8 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 \u00e8 importante.<\/p>\n<h3>1. Siate significativi<\/h3>\n<p>State gi\u00e0 progettando siti con in mente degli obiettivi riguardanti sia gli utenti sia l&#8217;azienda, giusto? Bene. Ora, dovete tradurre questi obiettivi su una scala pi\u00f9 piccola, applicandoli ad ogni tipo di contenuto che avete: blog post, articoli, contenuto a rotazione o descrizioni di prodotti. Per fare ci\u00f2, dovete essere in grado di rispondere a domande come:<\/p>\n<ul>\n<li>Questo tipo di contenuto in che modo supporta gli obiettivi generali del sito?<\/li>\n<li>Perch\u00e8 un utente ne dovrebbe aver bisogno?<\/li>\n<li>Che cosa ottiene l&#8217;azienda pubblicandolo?<\/li>\n<li>L&#8217;azienda cosa vuole che l&#8217;utente faccia con tale contenuto?<\/li>\n<\/ul>\n<p>Cos\u00ec come \u00e8 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?<\/p>\n<p>(Ora, se realizzate che il vostro contenuto non sta ottenendo alcunch\u00e8 o non sapete con che tipi di contenuto avrete a che fare, avete tra le mani un problema ben pi\u00f9 grande. Prima di fare amicizia con il futuro, andate dal vostro cliente o dal vostro capo e cercate di capire quello che ha importanza).<\/p>\n<h3>2. Rendetelo minuscolo<\/h3>\n<p>Ok, sapete perch\u00e8 esistono gli articoli o le ricette o le poesie umoristiche o qualunque altro tipo di contenuto con cui avete a che fare. Bene, perch\u00e8 adesso \u00e8 il momento di diventare ancor pi\u00f9 granulari, spezzando quei tipi di contenuto nei loro elementi costitutivi.<\/p>\n<p>Gli elementi specifici che dovete considerare cambieranno molto a seconda del tipo di contenuto su cui andrete a lavorare, quindi cominciate con l&#8217;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.<\/p>\n<p>Come esempio, prendiamo dal famoso sito Epicurious\u00a0<a href=\"http:\/\/www.epicurious.com\/recipes\/food\/views\/Asparagus-Fingerling-Potato-and-Goat-Cheese-Pizza-352629\" target=\"_blank\" title=\"title: Asparagus, Fingerling Potato, and Goat Cheese Pizza recipe on epicurious.com\" rel=\"noopener noreferrer\">una ricetta per la pizza con gli asparagi, le patate a spicchi ed il formaggio di capra<\/a>.<\/p>\n<p>Le ricette sono un tipo di contenuto piuttosto comune, quindi potreste aver pensato di sapere gi\u00e0 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:<\/p>\n<ul>\n<li>Titolo<\/li>\n<li>Attribuzione della pubblicazione<\/li>\n<li>Data della pubblicazione<\/li>\n<li>Autori<\/li>\n<li>Per quante persone<\/li>\n<li>Breve descrizione<\/li>\n<li>Immagine<\/li>\n<li>Ingredienti<\/li>\n<li>Preparazione<\/li>\n<li>Abbinamenti di vino<\/li>\n<li>Voti<\/li>\n<li>Revisioni<\/li>\n<li>Ingredienti principali<\/li>\n<li>Tipo di cucina<\/li>\n<li>Considerazioni dietetiche<\/li>\n<li>Collezione di ricette correlate<\/li>\n<\/ul>\n<p>Un information architect o un content strategist tornano di sicuro comodi nel determinare questi attributi, ma tutti nel team devono essere molto coinvolti, perch\u00e8 avrete bisogno di questi pezzi per prendere importanti decisioni riguardo al modo in cui il contenuto risponder\u00e0 ai cambiamenti di device e di display.<\/p>\n<h3>3. Siate significativi<\/h3>\n<p>Capire quali sono i pezzi di contenuto esistenti \u00e8 solo l&#8217;inizio. Adesso dovete capire perch\u00e9 ogni singolo pezzo \u00e8 importante per il tutto e quanto \u00e8 importante. questo ci permette di prendere decisioni sul modo in cui \u00e8 organizzato, come sono assegnate le priorit\u00e0 e come viene visualizzato su monitor con dimensioni diverse, in contesti diversi o per scopi diversi.<\/p>\n<p>Potete cominciare a farlo considerando:<\/p>\n<ul>\n<li>in che modo contribuisce questo elemento allo scopo del contenuto?<\/li>\n<li>che significato si perde se viene tolto questo elemento?<\/li>\n<li>che relazioni esistono tra questo elemento e gli altri?<\/li>\n<\/ul>\n<p>Se questo fosse un mio progetto, io farei grandi ricerche negli obiettivi dell&#8217;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\u00f2 facendo delle supposizioni. Dal momento che Epicurious \u00e8 un editore, assumo che voglia aumentare i page views per far aumentare i ritorni economici degli annunci pubblicitari. Dal momento che \u00e8 un sito di ricette, supponiamo che gli utenti ci arrivino per trovare qualcosa che vogliano cucinare.<\/p>\n<p>Questo scenario potrebbe tradursi in un obiettivo a livello del contenuto tipo \u201cle ricette dovrebbero essere irresistibili, specifiche ed in relazione tra loro, cos\u00ec che gli utenti che vogliano provare a prepararle, siano in grado di capire se soddisfano le proprie necessit\u00e0 e infine vogliano vedere altri contenuti di Epicurious.\u201d<\/p>\n<p>Tenendo ben presente tale obiettivo rispetto a questi elementi di contenuto, emergono alcune interessanti domande:<\/p>\n<ul>\n<li>Rimuovere tutti quegli elementi tra loro correlati potrebbe sembrare un modo semplice per ridurre l&#8217;ammasso di scritte per le dimensioni pi\u00f9 piccole degli schermi, ma fare cos\u00ec potrebbe ridurre il numero di pagine visitate da un utente?<\/li>\n<li>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\u00e9 devono passare attraverso gli ingredienti per arrivare alla valutazione della ricetta?<\/li>\n<li>L&#8217;interesse degli utenti varia se in una ricetta togliamo l&#8217;immagine?<\/li>\n<li>Un titolo, se lo si mostra da qualche altra parte senza la descrizione nel sommario, dice cose sufficientemente significative all&#8217;utente?<\/li>\n<\/ul>\n<p>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.<\/p>\n<p>Probabilmente non si riusciranno mai ad indovinare in anticipo le preferenze di tutti gli utenti, ma pi\u00f9 comprendiamo le relazioni tra le informazioni, pi\u00f9 i compromessi propri di ciascuna decisione del design saranno chiari e saremo pi\u00f9 preparati per quelle difficili telefonate.<\/p>\n<p>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 \u00e8 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.<\/p>\n<p>Questo \u00e8 il punto dell&#8217;adattare il contenuto ai vari layout: ogni caso \u00e8 un caso a parte. Le regole &#8220;una sola per tutti&#8221; 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&#8217;emergere di pi\u00f9 dispositivi e tecnologie, dovrete sviluppare nuove regole e trovare nuovi compromessi.<\/p>\n<p>La buona notizia \u00e8 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.<\/p>\n<h3>4. Organizzatevi<\/h3>\n<p>Il futuro \u00e8 attraente, i content management systems non lo sono. Tuttavia il vostro CMS potrebbe benissimo essere ci\u00f2 che sta fra il vostro contenuto attentamente studiato e la sua capacit\u00e0 di viaggiare. Pensate agli elementi che abbiamo identificato e alle relazioni e priorit\u00e0 che li definiscono. Tra i CMS con cui avete gi\u00e0 lavorato, ce n&#8217;\u00e8 qualcuno pronto per questo livello di contenuto? Se s\u00ec, siete in minoranza. Noi altri dobbiamo fare un po&#8217; di lavoro.<\/p>\n<p>Un&#8217;organizzazione che ha fatto passi da gigante per rendere il proprio CMS pronto per il futuro \u00e8 la National Public Radio. Nel 2009, la NPR lanci\u00f2 una metodologia chiamata\u00a0<a href=\"http:\/\/blog.programmableweb.com\/2009\/10\/13\/cope-create-once-publish-everywhere\" target=\"_blank\" title=\"COPE: Create Once, Publish Anywhere on the Inside NPR Blog\" rel=\"noopener noreferrer\">COPE: Create Once, Publish Everywhere<\/a> [Crea una volta, Pubblica ovunque,\u00a0<em>ndt<\/em>], usando la quale ogni storia viene inserita in un insieme discreto di campi all&#8217;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.<\/p>\n<p>Il CMS di NPR supporta una gran variet\u00e0 di elementi di contenuto, ma solo quattro di questi sono obbligatori: titolo, breve riassunto, descrizione pi\u00f9 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\u00e0 della piattaforma sulla quale la si sta pubblicando.<\/p>\n<p>Se vogliamo sistemi che gestiscano questo tipo di contenuto modulare e che possa muoversi rapidamente, \u00e8 il momento di acquisire pi\u00f9 familiarit\u00e0 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\u00a0<a href=\"http:\/\/www.alistapart.com\/articles\/strategic-content-management\" target=\"_blank\" title=\"Strategic Content Management by Jonathan Kahn\" rel=\"noopener noreferrer\">approccio strategico alla gestione del contenuto<\/a>, che vi aiuter\u00e0 a:<\/p>\n<ul>\n<li>essere sicuri che quelli che si concentrano sulle caratteristiche e sulle capacit\u00e0 del CMS capiscano il vostro contenuto e quello che dovrebbe far ottenere;<\/li>\n<li>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;<\/li>\n<li>comprendere le possibilit\u00e0 ed i limiti del proprio CMS e collaborare alla creazione di modi per gestirli;<\/li>\n<li>sollevare il team tecnico da un peso dandogli delle direttive ragionate e specifiche per informarli sui requisiti del CMS.<\/li>\n<\/ul>\n<p>Questo lavoro di base vi sar\u00e0 molto utile anche se state gestendo un sito web molto semplice, ma appena comincerete a condividere il contenuto attraverso pi\u00f9 dispositivi e canali, diventer\u00e0 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\u00e0 adattare e spostare e avrete a disposizione i sistemi che vi permetteranno di implementarli.<\/p>\n<h3>5. Strutturatevi<\/h3>\n<p>C&#8217;\u00e8 un motivo per cui questo articolo non comincia con un&#8217;introduzione su XML: la tecnologia non vi pu\u00f2 aiutare a prendere delle buone decisioni, vi pu\u00f2 solo aiutare ad implementarle. Tuttavia, gli elementi di contenuto devono alla fine essere tradotti in codice, quindi anche se il vostro lavoro non \u00e8 scrivere markup, dovremmo tutti cominciare a familiarizzare con i tool esistenti che ci permettono di scriverlo.<\/p>\n<p>Il contenuto strutturato non \u00e8 una novit\u00e0: i comunicatori tecnici hanno utilizzato DITA (Darwin Information Typing Architecture) per anni e non ha nulla di particolarmente futuristico. \u00c8 basato su\u00a0<a href=\"http:\/\/www.xml.org\/\" target=\"_blank\" rel=\"noopener noreferrer\">XML<\/a>, un linguaggio di markup che d\u00e0 ai componenti del contenuto un significato intrinseco quando vengono visualizzati al di fuori del loro database,\u00a0<a href=\"http:\/\/dita.xml.org\/\" target=\"_blank\" rel=\"noopener noreferrer\">DITA<\/a> crea e pubblica le informazioni tecniche in moduli di contenuto: piccoli pezzi di informazioni pensati per il riutilizzo e la categorizzazione per argomento.<a name=\"0.1_FNPTR-1\"><\/a><a href=\"https:\/\/mail-attachment.googleusercontent.com\/attachment\/?ui=2&amp;ik=d610865bb4&amp;view=att&amp;th=136223b34866040b&amp;attid=0.1&amp;disp=inline&amp;safe=1&amp;zw&amp;saduie=AG9B_P-n9ruBQgXqQr-OMFf1N_wL&amp;sadet=1332059429166&amp;sads=gSWRWhc2kQuyjfYV9wop2foGock#0.1_FOOTNOTE-1\">[1]<\/a> Progettato da IBM per gestire il contenuto tecnico all&#8217;interno dell&#8217;azienda, \u00e8 usato prevalentemente per cose come la documentazione di riferimento.<\/p>\n<p>Molti nuovi comunicatori tecnici insistono nel dire che DITA dovrebbe essere l&#8217;approccio standard per strutturare, ma non ha mai preso piede. Tra l&#8217;altro non \u00e8 l&#8217;unico modo con cui strutturare il contenuto. Al momento, HTML5 supporta il markup semantico attraverso la sua estensione\u00a0<a href=\"http:\/\/dev.w3.org\/html5\/md\" target=\"_blank\" rel=\"noopener noreferrer\">microdata<\/a>, che va oltre i tradizionali tag di presentazione e permette di usare il markup per il contenuto con HTML standard compliant e semanticamente ricco.<a name=\"0.1_FNPTR-2\"><\/a><a href=\"https:\/\/mail-attachment.googleusercontent.com\/attachment\/?ui=2&amp;ik=d610865bb4&amp;view=att&amp;th=136223b34866040b&amp;attid=0.1&amp;disp=inline&amp;safe=1&amp;zw&amp;saduie=AG9B_P-n9ruBQgXqQr-OMFf1N_wL&amp;sadet=1332059429166&amp;sads=gSWRWhc2kQuyjfYV9wop2foGock#0.1_FOOTNOTE-2\">[2]<\/a> Ovviamente, HTML5 \u00e8 esso stesso una working draft e non \u00e8 chiaro se i microdati si diffonderanno o se offriranno sufficiente specificit\u00e0 per i nostri contenuti. Ad esempio, alla fine dello scorso anno, l&#8217;<a href=\"http:\/\/www.netmagazine.com\/news\/html5-scraps-semantic-time-element-111517\" target=\"_blank\" title=\"HTML5 scraps semantic \u201ctime\u201d element\" rel=\"noopener noreferrer\">elemento \u201ctime\u201d \u00e8 stato rimosso<\/a> in favore del pi\u00f9 generico \u201cdata\u201d.<\/p>\n<p>C&#8217;\u00e8 anche\u00a0<a href=\"http:\/\/schema.org\/\" target=\"_blank\" rel=\"noopener noreferrer\">Schema.org<\/a>, 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\u00a0<a href=\"http:\/\/schema.org\/docs\/gs.html\" target=\"_blank\" title=\"Getting started with schema.org\" rel=\"noopener noreferrer\">tassonomie di tipi di contenuto<\/a> che cominciano genericamente e si specializzano man mano che gli elementi si diramano. I critici, tuttavia, sottolineano che Schema.org \u00e8 un\u00a0<a href=\"http:\/\/manu.sporny.org\/2011\/false-choice\/\" target=\"_blank\" title=\"Manu Sporny, The False Choice of Schema.org\" rel=\"noopener noreferrer\">sistema chiuso<\/a>: sono i motori di ricerca a dirci quali strutture sono importanti, piuttosto che lasciare che siano i proprietari del contenuto a definirle.<\/p>\n<p>Molte persone si sono appassionate al dibattito su quale sia il migliore tra questi approcci e sul perch\u00e9 tutti gli altri sono sbagliati. Io non faccio parte di questo gruppo perch\u00e9 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\u00f9 senso per il vostro progetto e in effetti potrebbe anche implicare che non vi dobbiate preoccupare del markup proprio adesso.<\/p>\n<p>\u00a0<\/p>\n<\/div>\n<div>\n<h2>Dare vita alla struttura<\/h2>\n<p>Il lavoro che mettiamo nell&#8217;arrivarci \u00e8 molto pi\u00f9 importante del markup: le regole e le relazioni determinate analizzando il contenuto da vicino e l&#8217;attenzione verso il suo messaggio ed il suo scopo. Dopo tutto, la &#8220;semantica\u201d definisce, tipicamente, il significato del linguaggio. Qualunque sia il linguaggio di markup che usate, non sar\u00e0 semantico a meno che non porti in primo piano il significato, il che spiega perch\u00e9 non potete cominciare dal markup: \u00e8 il punto d&#8217;arrivo.<\/p>\n<p>Penso che questo sia il motivo per cui il contenuto strutturato \u00e8 spesso stato descritto come troppo tecnico ed utilitaristico per la folla tradizionale del web, perch\u00e9 abbiamo lasciato fuori da queste conversazioni il lato editoriale, quello sperimentale, la parte che d\u00e0 vita al contenuto.<\/p>\n<p>Non si pu\u00f2 continuare cos\u00ec: il contenuto pronto per il futuro non c&#8217;entra con il diventare esperti di XML o con il supporre che i microdati risolveranno i nostri problemi. Riguarda l&#8217;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\u00e0 e ricchezza.<\/p>\n<p>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.<\/p>\n<p>La tecnologia cambier\u00e0, gli standard si evolveranno, ma il bisogno di comprendere il nostro contenuto, il suo scopo, significato, struttura, relazioni e valore rimarr\u00e0. Quando potremo adottare questo modo di pensare, libereremo il nostro contenuto, sicuri che sopravviver\u00e0 intatto nel suo grande viaggio verso un futuro ignoto.<\/p>\n<\/div>\n<div>\n<h2>Riferimenti<\/h2>\n<p><a name=\"0.1_FOOTNOTE-1\"><\/a><a href=\"https:\/\/mail-attachment.googleusercontent.com\/attachment\/?ui=2&amp;ik=d610865bb4&amp;view=att&amp;th=136223b34866040b&amp;attid=0.1&amp;disp=inline&amp;safe=1&amp;zw&amp;saduie=AG9B_P-n9ruBQgXqQr-OMFf1N_wL&amp;sadet=1332059429166&amp;sads=gSWRWhc2kQuyjfYV9wop2foGock#0.1_FNPTR-1\">[1]<\/a> Per un&#8217;introduzione a DITA da una prospettiva tecnico-commerciale, scaricate il white paper del Rockley Group:\u00a0<cite><a href=\"http:\/\/www.rockley.com\/articles\/The%20Rockley%20Group%20-%20DITA%20-%20What%20you%20need%20to%20know.pdf\" target=\"_blank\" rel=\"noopener noreferrer\">Preparing for DITA: What you need to know<\/a><\/cite>.<\/p>\n<p><a name=\"0.1_FOOTNOTE-2\"><\/a><a href=\"https:\/\/mail-attachment.googleusercontent.com\/attachment\/?ui=2&amp;ik=d610865bb4&amp;view=att&amp;th=136223b34866040b&amp;attid=0.1&amp;disp=inline&amp;safe=1&amp;zw&amp;saduie=AG9B_P-n9ruBQgXqQr-OMFf1N_wL&amp;sadet=1332059429166&amp;sads=gSWRWhc2kQuyjfYV9wop2foGock#0.1_FNPTR-2\">[2]<\/a> Vedi\u00a0<cite><a href=\"http:\/\/www.webmonkey.com\/2010\/09\/microdata-html5s-best-kept-secret\" target=\"_blank\" rel=\"noopener noreferrer\">Microdata: HTML5\u2019s Best-Kept Secret<\/a><\/cite> su Web Monkey e\u00a0<cite><a href=\"http:\/\/briancray.com\/2010\/09\/08\/html5-microdata\/\" target=\"_blank\" rel=\"noopener noreferrer\">HTML5 Microdata: Why isn\u2019t anyone talking about it?<\/a><\/cite> di Brian Cray.<\/p>\n<p>Illustrazioni: {carlok}<\/p>\n<\/div>\n<\/div>\n","protected":false},"excerpt":{"rendered":"<p>Il futuro \u00e8 flessibile e ci stiamo piegando con lui. Dal responsive web design al pensiero futurefriend.ly, ci stiamo rapidamente muovendo verso un web che sar\u00e0 pi\u00f9 fluido, meno fisso e pi\u00f9 facilmente accessibile da una moltitudine di dispositivi. Abbracciando il cambiamento, dobbiamo rinunciare al controllo anche sul nostro contenuto, liberandolo dai vincoli di una pagina tradizionale, perch\u00e9 scorra secondo i vari display e contesti. La maggior parte delle conversazioni riguardanti il contenuto strutturato si tuffa per prima cosa nei dettagli tecnici: XML, DITA, microdata, RDF. Tuttavia, la struttura non \u00e8 solo metadati e markup: \u00e8 il significato che hanno i metadati e il markup. Sara Wachter-Boettcher condivide con noi un framework per prendere decisioni intelligenti riguardo la struttura del contenuto.<\/p>\n","protected":false},"author":818,"featured_media":7000648,"comment_status":"open","ping_status":"open","template":"","categories":[254,61,253],"tags":[],"coauthors":[382],"class_list":["post-242","article","type-article","status-publish","has-post-thumbnail","hentry","category-content-strategy","category-numero-46-18-marzo-2012","category-writing"],"jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/article\/242","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/article"}],"about":[{"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/types\/article"}],"author":[{"embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/users\/818"}],"replies":[{"embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/comments?post=242"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/media\/7000648"}],"wp:attachment":[{"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/media?parent=242"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/categories?post=242"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/tags?post=242"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/coauthors?post=242"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}