{"id":324,"date":"2012-11-21T14:45:13","date_gmt":"2012-11-21T13:45:13","guid":{"rendered":"https:\/\/alistapart.com\/it\/article\/il-vostro-contenuto-da-ora-in-poi-mobile\/"},"modified":"2012-11-21T14:45:13","modified_gmt":"2012-11-21T13:45:13","slug":"il-vostro-contenuto-da-ora-in-poi-mobile","status":"publish","type":"article","link":"https:\/\/alistapart.com\/it\/article\/il-vostro-contenuto-da-ora-in-poi-mobile\/","title":{"rendered":"Il vostro contenuto, d’ora in poi mobile"},"content":{"rendered":"

Siamo lieti di presentarvi questo estratto dal Capitolo 1 di Content Strategy for Mobile<\/a> di Karen McGrane, ora disponibile da A Book Apart<\/a>. \u2014Ed.<\/em><\/p>\n

Quando parliamo di come creare prodotti e servizi per il mobile, la conversazione tende a concentrarsi sulle sfide della progettazione e dello sviluppo. Come cambia l’estetica del design quando abbiamo a che fare con schermi pi\u00f9 piccoli (o a risoluzione maggiore)? Come impieghiamo (e insegniamo) le nuove interazioni gestuali che sfruttano le capacit\u00e0 dei touchscreen? Come (e chi) scriver\u00e0 il codice per tutte quelle svariate piattaforme e come le manterremo tutte?<\/p>\n

Tutte ottime domande, ma concentrarsi solo sulle domande sulla progettazione e sullo sviluppo ci fa dimenticare una questione importante: come possiamo fare in modo che il nostro contenuto si veda in maniera appropriata sui dispositivi mobile?<\/p>\n

La buona notizia \u00e8 che la risposta a questa domanda vi aiuter\u00e0, indipendentemente dal sistema operativo, dalle capacit\u00e0 del device o dalla risoluzione dello schermo. Se vi prendete del tempo per trovare il giusto modo per pubblicare il vostro contenuto, avrete la libert\u00e0 (e la flessibilit\u00e0) di farlo arrivare ovunque. Potrete tornare a pensare ai modi pi\u00f9 giusti per approcciare il design e lo sviluppo per ogni piattaforma perch\u00e9 avete gi\u00e0 una base di contenuto riutilizzabile da cui partire.<\/p>\n

La cattiva notizia \u00e8 che questo non \u00e8 un problema superficiale. Risolverlo non \u00e8 qualcosa che potete fare da soli, mettendo un sottoinsieme del vostro contenuto nella versione sandbox del sito mobile o della app. La soluzione richiede che osserviate da vicino il vostro CMS, il vostro workflow editoriale, perfino la vostra struttura aziendale. Potreste aver bisogno di strumenti diversi, di processi differenti e di modi diversi per comunicare.<\/p>\n

Non disperate! C’\u00e8 anche una notizia migliore<\/em> alla fine di questo arcobaleno! Prendendovi il tempo per esaminare il contenuto e per strutturarlo per la massima flessibilit\u00e0 e il massimo riutilizzo, sarete (meglio) preparati la prossima volta che spunter\u00e0 un nuovo gadget. Avrete eliminato tutti i rami secchi, potando il contenuto superato, scritto male e irrilevante, il che significa che tutti i vostri utenti avranno un’esperienza migliore. Avrete rivisto e aggiornato i vostri processi e strumenti per gestire e mantenere il contenuto, il che significa che tutto il contenuto che create in ciascun canale (stampa, desktop, mobile, TV, social) sar\u00e0 governato pi\u00f9 da vicino.<\/p>\n

Mobile non vuol dire versione \u201clite\u201d<\/h3>\n
\n

A quanto pare ti trovi su un treno. Vuoi che ti mostri un sito mobile cos\u00ec semplificato da essere irritante?<\/p>\n

\u2014Cennydd Bowles (http:\/\/bkaprt.com\/csm\/15<\/a>)<\/p>\n<\/blockquote>\n

Se le persone vogliono fare qualcosa su internet, vogliono farlo usando i propri device mobile. Punto.<\/p>\n

I confini tra le \u201coperazioni desktop\u201d e le \u201coperazioni mobile\u201d sono fluidi, guidati tanto dalla comodit\u00e0 del device quanto dalla facilit\u00e0 di portare a termine un task. Avete mai provato a cercare un’informazione con il tablet solo perch\u00e9 siete troppo pigri per alzarvi e andare al computer? Avete mai scritto una lunga email sul BlackBerry mentre siete seduti alla scrivania, dimenticandovi temporaneamente che esiste la tastiera? Avete mai trovato che il processo per prenotare un biglietto con il telefonino \u00e8 pi\u00f9 semplice<\/em> che usando il desktop (ce l’ho con te, Amtrak!) perch\u00e9 hanno tolto tutta la confusione?<\/p>\n

Avete notato che il device che avete scelto per una certa attivit\u00e0 non implica necessariamente il vostro contesto d’uso?<\/p>\n

Le persone usano qualunque device in qualunque posto, in qualunque contesto. Usano i dispositivi mobile nei ristoranti e sul sofa. Usano i tablet con grande attenzione nelle riunioni e la domenica mattina pigrando a letto. Usano i laptop con le connessioni a banda larga fornite dal datore di lavoro e con la costosa connessione wi-fi dell’hotel, che fa passare i bit con il contagocce. Usano le workstation desktop sulla spiaggia\u2014ok, in realt\u00e0 usano i desktop tradizionali solo alle loro scrivanie. Mi avete beccato.<\/p>\n

Conoscere il tipo di dispositivo che l’utente usa non vi dice nulla sulle intenzioni dell’utente. Conoscere la posizione di qualcuno non vi dice niente sui vostri obiettivi. Non potete fare assunzioni su quello che l’utente vuole fare solo perch\u00e9 ha uno schermo pi\u00f9 piccolo. In effetti, tutto quello che sapete \u00e8: ha uno schermo piccolo.<\/p>\n

Il contesto immobile<\/h4>\n

Gli utenti da sempre accedono ai contenuti utilizzando una variet\u00e0 di schermi, con differenti dimensioni e risoluzioni. I dati riportati da SecureCube mostrano che nel Gennaio del 2000 la maggior parte degli utenti usava per navigare un browser con la risoluzione 800\u00d7600, ma una minoranza significativa (il 29%) \u00e8 entrato nel sito con risoluzione 1024\u00d7768 o superiore, con una percentuale pi\u00f9 piccola (11%) che ha visto il sito a 640\u00d7468 (http:\/\/bkaprt.com\/csm\/16<\/a>; fig 1.1). Allora le decisioni su come fosse meglio presentare il contenuto costituivano delle sfide del design e gli sviluppatori cercavano di fornire ai propri utenti una buona esperienza di lettura a tutte le risoluzioni, discutendo sui modi appropriati per aggiustare le larghezze delle colonne e i layout dello schermo al riposizionarsi del contenuto passando da schermi piccoli fino a quelli pi\u00f9 grandi.<\/p>\n

\"Figure<\/p>\n

Fig 1.1: Abbiamo molta esperienza nell’offrire contenuto per una serie di risoluzioni di schermo. Perch\u00e9 dobbiamo assumere che gli schermi mobile indichino necessariamente un contesto differente?<\/p>\n<\/div>\n

Quello di cui i designer non avevano sentito parlare era il \u201ccontesto 640\u00d7480\u201d e in che modo differiva dal \u201ccontesto 1024\u00d7768\u201d. Nessuno ha mai cercato di intuire quali task sarebbero pi\u00f9 importanti per gli utenti che navigano con la risoluzione a 800\u00d7600, cos\u00ec che si potessero nascondere loro le opzioni meno importanti. Nessuno ha ipotizzato che la forma mentale, i task e gli obiettivi delle persone potessero essere differenti semplicemente perch\u00e9 avevano un monitor di una dimensione diversa.<\/p>\n

Perch\u00e9 assumiamo che il mobile sia diverso?<\/p>\n

Task mobile, contenuto mobile<\/h3>\n

Recentemente ho lasciato Austin, Texas, per un viaggio con tre amici. Dal momento che siamo arrivati in aeroporto leggermente in anticipo, volevo andare a rilassarmi nel comfort dello United Club, lontano dalle masse brulicanti. Mi sembrava scortese abbandonare i miei amici al loro destino fuori dal Club e cos\u00ec volevo sapere quanti ospiti avrei potuto portare con me nel club.<\/p>\n

Una semplice ricerca su Google avrebbe chiarito il problema. Come previsto, trovai rapidamente un link che sembrava promettere bene (fig. 1.2).<\/p>\n

\"Figure<\/p>\n

Fig 1.2: Cercando \u201cUnited Club Membership\u201d mostra l’esistenza del contenuto sul sito desktop. Ma siccome il sito mobile fa redirect dell’URL, gli utenti finiscono sulla homepage del sito mobile.<\/p>\n<\/div>\n

Purtroppo, seguendo il link per la United Club Membership sono finita sulla homepage mobile.united.com<\/a>. Quando gli utenti fanno una ricerca da un dispositivo mobile, United reindirizza automaticamente i link da Google al suo sito mobile, senza controllare se il contenuto sia disponibile su mobile. Se il contenuto non esiste sul mobile, l’utente viene rimandato alla homepage del sito mobile senza troppi complimenti. Reindirizzamento mobile che fa fallire una ricerca: come pu\u00f2 essere una buona esperienza utente?<\/p>\n

Ovviamente, c’\u00e8 un link al sito desktop completo, che per\u00f2 mi rimanda alla homepage desktop. Avrei potuto cercare di usare la ricerca interna al sito United, ma sono finita a fare “pinch and zoom” tra i risultati di varie ricerche formattati solo per il desktop. E onestamente, perch\u00e9 dovrei? Una risposta che potrei trovare con un tap sui risultati di Google non dovrebbe richiedere di cercare e visitare diverse pagine sia sul sito mobile sia su quello dektop.<\/p>\n

Quindi, sono andata a chiedere al rappresentante al desk (La risposta corretta \u00e8 due ospiti).<\/p>\n

Non ho menzionato questa storia solo perch\u00e9 voglio far vergognare la United perch\u00e9 fanno ingiustificatamente il redirect dei link verson un URL mobile quando il contenuto non \u00e8 disponibile sul loro sito mobile. (\u00c8 una cosa terribile da fare ma viene dopo una lunga lista di altre cose pessime per cui vorrei rimproverare la United Airlines). No, uso questo esempio per illustrare un’idea sbagliata riguardante i device mobile, ossia che dovrebbero offrire solo funzionalit\u00e0 basate sui task piuttosto che sulla ricerca di informazioni nel contenuto.<\/p>\n

La ricerca di informazioni \u00e8 un task<\/h4>\n

Luke Wroblewski, nel suo libro Mobile First<\/cite>, ci racconta che la Southwest Airlines sta facendo la cosa giusta concentrandosi solo sui task che riguardano il viaggio (fig 1.3):<\/p>\n

\n

L’esperienza mobile \u2026 si concentra in modo scrupoloso sui bisogno dei clienti e su quello che fa la Southwest: prenotare viaggi, fare il check-in, controllare lo stato dei voli, controllare le miglia ed essere avvisati. Non c’\u00e8 spazio per null’altro, c’\u00e8 solo quello che \u00e8 pi\u00f9 importante.<\/p>\n<\/blockquote>\n

\"Figure<\/p>\n

Fig 1.3: L’applicazione iPhone della Southwest Airlines ha spazio solo per quello che importa veramente\u2026 Se quello che conta non \u00e8 cercare informazioni.<\/p>\n<\/div>\n

Gli esperti di mobile e i designer di app per le linee aeree non possono decidere quello che \u00e8 \u201cdavvero importante\u201d. Le cose importanti sono quelle che importano all’utente ed \u00e8 tanto probabile che sia la ricerca di un’informazione cos\u00ec come il completamento di un task.<\/p>\n

Lo 86% dei proprietari di smartphone ha usato il proprio telefono nel mese precedente per cercare delle informazioni, sia che si trattasse di risolvere un problema, di calmare una discussione, di ottenere delle informazioni dell’ultimo minuto come le notizie sul traffico o i risultati sportivi o di decidere di andare in un certo ristorante (http:\/\/bkaprt.com\/csm\/27<\/a>). Non mi credete? Guardate lo storico delle ricerche sul vostro dispositivo mobile: probabilmente avete cercato di rispondere a un variegato insieme di domande cercando le informazioni sul vostro telefono.<\/p>\n

Il sito desktop di Southwest Airlines include informazioni sulle loro policy riguardanti il bagaglio, ivi comprese le politiche per i bagagli imbarcati, i bagagli a mano e gli animali domestici, cos\u00ec come per i lost and found, i bagagli in ritardo e una gran variet\u00e0 di altre informazioni per i viaggiatori, come ad esempio le procedure da seguire in caso di smarrimento del biglietto, di necessit\u00e0 di riprenotazione o cosa fare se il volo \u00e8 overbooked. Include anche delle informazioni per i genitori che stanno cercando di prenotare un viaggio per i propri figli minorenni non accompagnati e sui modi in cui la Southwest gestisce i passeggeri disabili o anziani.<\/p>\n

L’esperienza mobile non fa tutto questo. Chi siamo noi per dire che questo contenuto in realt\u00e0 non \u00e8 importante?<\/p>\n

Va bene ottimizzare l’esperienza mobile per i task pi\u00f9 comuni, ma questo non significa che dovete escludere del contenuto rilevante.<\/p>\n

Il mobile \u00e8 social<\/h4>\n

Avete mai cliccato su un link da Facebook o Twitter sul vostro telefono? E su un link che qualcuno vi ha inviato via email?<\/p>\n

\"Figure<\/p>\n

Fig 1.4: \u201cNessun contenuto mobile trovato. Volete visitare la nostra versione desktop del sito?\u201d Chiede The Guardian<\/cite>. Riuscite a indovinare la risposta?<\/p>\n<\/div>\n

Ovviamente avete indovinato. La condivisione del contenuto con i nostri amici e colleghi \u00e8 uno dei modi fondamentali con cui comunichiamo in questi giorni. Gli utenti non fanno distinzioni tra l’accesso all’e-mail, a Facebook, a Twitter o a altri servizi social sul desktop o su mobile: li scelgono in scioltezza, a seconda del device a cui sono pi\u00f9 vicini in quel preciso istante. In realt\u00e0, a Giugno 2012, quasi il 20% dei membri di Facebook lo usava solo su mobile (http:\/\/bkaprt.com\/csm\/28<\/a>).<\/p>\n

Se il vostro contenuto non \u00e8 disponibile su mobile, o d\u00e0 un cattiva esperienza di lettura, state perdendo uno dei modi pi\u00f9 convincenti per farlo leggere alle persone. Il vostro sito \u00e8 pieno di icone che cercano di far condividere il vostro contenuto con le persone? Se i vostri lettori ottengono un messaggio di errore quando visualizzano il contenuto condiviso, \u00e8 inutile tutta la fatica che fate per incoraggiare la condivisione sociale (fig 1.4).<\/p>\n

Progettare per il contesto<\/h3>\n

\u201cContesto\u201d \u00e8 il termine che tutti usano quando parlano di mobile. Durante la conferenza South by Southwest Interactive del 2011, il panel intitolato \u201cDesigning for context\u201d [\u201cProgettare per il contesto\u201d, ndr<\/em>] \u00e8 stato la sessione “must-see” secondo .net Magazine<\/cite> (http:\/\/bkaprt.com\/csm\/29<\/a>).<\/p>\n

Il sogno \u00e8 quello di poter creare un contenuto su misura basandosi sul contesto dell’utente: la posizione, il momento della giornata, l’ambiente sociale, le preferenze personali. A seconda di quello che sapete dell’utente, potete personalizzare dinamicamente l’esperienza, cos\u00ec che si adatti ai suoi bisogni.<\/p>\n

Oggi, usiamo la scusa del \u201cprogettare per il contesto mobile\u201d per fare del mobile un’esperienza minore. Le aziende vogliono investire il minor tempo e il minor sforzo possibili nel mobile finch\u00e9 non riusciranno a dimostrarne un ritorno degli investimenti. I progettisti credono di poter indovinare quale sottoinsieme di informazioni o funzionalit\u00e0 vogliano gli utenti. Tutti sostengono di progettare per il \u201cmobile use case\u201d.<\/p>\n

Attenti alle interfacce personalizzate<\/h4>\n

\u00c8 pericoloso presumendo che il \u201cdesigner sappia sicuramente\u201d quando scegliere il modo in cui offrire contenuto o funzionalit\u00e0 personalizzate. Siamo notoriamente dei pessimi indovini delle preferenze altrui, anche se armati di dati reali \u00e8 probabile che fare le ipotesi sbagliate quando decideremo di mostrare alcune cose e di nasconderne altre.<\/p>\n

Microsoft Office prov\u00f2 questa strategia alla fine degli anni ’90 del secolo scorso. Office 97 offriva molte nuove feature e numerosi miglioramenti, che resero pi\u00f9 complessa l’interfaccia utente. La presenza di lunghi menu e di toolbar dense di funzionalit\u00e0 dava l’impressione che l’interfaccia fosse \u201cstraripante\u201d (http:\/\/bkaprt.com\/csm\/30<\/a>). (La situazione \u00e8 simile per i siti desktop, sapete?)<\/p>\n

Come risposta, Microsoft sviluppo dei \u201cmenu personalizzati\u201d e delle \u201crafted toolbar\u201d che mostravano per prima cosa le voci pi\u00f9 popolari (fig 1.5). Sebbene Microsoft avesse in suo possesso dei dati validi e un algoritmo potente per determinare quali voci sarebbero state da presentare per prime, scopr\u00ec che agli utenti non piace che si facciano supposizioni sulle loro preferenze. Trovarono che fosse pi\u00f9 frustrante passare per un processo a due stage, cercare tra menu multipli per trovare quello che stavano cercando. I menu personalizzati violavano uno dei principi del design utente: dare il controllo agli utenti.<\/p>\n

\"Figure<\/p>\n

Fig 1.5: I menu personalizzati di Office 97 cercarono di dare delle priorit\u00e0 solo le opzioni che Microsoft riteneva fossero quelle volute dagli utenti. Furono un fallimento.<\/p>\n<\/div>\n

Ora immaginate che invece di cliccare una freccina in fondo al menu per espanderlo, l’utente dovesse cliccare un link per il \u201csito desktop completo\u201d e poi dovesse cercare nella navigazione strizzando gli occhi su uno schermo minuscolo. Se la versione mobile del vostro sito mobile offre solo un sottoinsieme del vostro contenuto, state dando agli utenti la stessa esperienza frustrante. Solo peggiore.<\/p>\n

Non avete dei buoni dati<\/h4>\n

Microsoft aveva una tonnellata di dati sulle opzioni usate pi\u00f9 frequentemente dalle persone. Svilupparono un algoritmo complesso per presentare il menu \u201cshort\u201d di default basato sulle voci che le persone probabilmente vogliono maggiormente, sfruttando anni di storia e ricerca con iterazioni multiple dei loro prodotti. Nonostante ci\u00f2, hanno fatto degli errori.<\/p>\n

Le scelte che fate su quale sottoinsieme di contenuto volete offrire probabilmente non sono supportate da buoni dati. Potrebbero non essere sostenute addirittura<\/em> da alcuna ricerca, ma solo da una sensazione su quali opzioni immaginate che siano pi\u00f9 importanti per il mitico utente in movimento.<\/p>\n

Anche se avete dei dati statistici riguardanti il contenuto che le persone cercano sul mobile, \u00e8 poco probabile che abbiate un’immagine accurata di quello che le persone vogliono davvero<\/em>. Le esperienze mobile non proprio perfette del giorno d’oggi sono dei terreni di test inadeguati per valutare quello che le persone desidererebbero fare sul mobile. Come afferma Jason Grigsby, cofondatore di CloudFour.com e MobilePortland.com:<\/p>\n

\n

Non possiamo prevedere il comportamento futuro partendo da un’esperienza che fa schifo. (http:\/\/bkaprt.com\/csm\/31<\/a>).<\/p>\n<\/blockquote>\n

Se la vostra idea del mobile \u00e8 progettare per il contesto, allora il primo passo che dovete fare \u00e8 mettere tutto il vostro contenuto nei dispositivi mobile.<\/p>\n

Tutto? Veramente?<\/h3>\n

Davvero. La vostra strategia per il contenuto per il mobile non dovrebbe consistere nello sviluppare un satellite per il vostro sito desktop, mostrando solo un sottoinsieme del contenuto che avete deciso che sar\u00e0 utile all’utente mobile. Non funzioner\u00e0, perch\u00e9:<\/p>\n

    \n
  • Le persone si muovono senza soluzione di continuit\u00e0 tra i device, scegliendo spesso un device mobile anche se hanno accesso a un computer desktop. Non pensate di poter progettare per \u201cl’utente in movimento\u201d perch\u00e9 le persone usano i propri dispositivi mobile ovunque e comunque.<\/li>\n
  • Anche gli utenti mobile-only vogliono e hanno bisogno di leggere il vostro contenuto! Non trattateli come cittadini di serie B solo perch\u00e9 non usano mai (o raramente) un computer. Anche se pensate a loro come utenti \u201cmobile-mostly\u201d, ricordatevi che non potete decidere quale dispositivo devono usare per accedere al vostro contenuto. Sono loro a decidere.<\/li>\n
  • Il mobile supporta la lettura del contenuto cos\u00ec come supporta i task funzionali. Non dovete ritenervi soddisfatti solo perch\u00e9 avete reso mobile alcune feature chiave: c’\u00e8 pi\u00f9 lavoro da fare con il contenuto.<\/li>\n
  • Il contesto \u00e8 una via di fuga. Non usate il contesto come una giustificazione per nascondere il contenuto a meno che non abbiate ricerche e date reali riguardanti quello che serve agli utenti in una data situazione o in un ambiente. Se non li avete, farete delle assunzioni sbagliate. (E anche se li avete, date le pessime esperienze che si fanno oggi sul mobile, probabilmente sbaglierete comunque).<\/li>\n<\/ul>\n

    Non forzate mai gli utenti ad andare sul sito desktop per il contenuto che stanno cercando su un dispositivo mobile. Al contrario, il vostro scopo deve essere la parit\u00e0 di contenuto tra le vostre esperienze desktop e mobile, magari non esattamente lo stesso contenuto presentato nello stesso identico modo, ma sostanzialmente la stessa esperienza.<\/p>\n

    La vostra mission \u00e8 di pubblicare il vostro contenuto su qualunque piattaforma, in qualunque formato il vostro pubblico desidera fruirne. I vostri utenti decidono come, quando e dove vogliono leggere il vostro contenuto. \u00c8 la vostra sfida ed \u00e8 responsabilit\u00e0 vostra offrire loro una buona esperienza.<\/p>\n","protected":false},"excerpt":{"rendered":"

    Non \u00e8 facile rendere mobile-ready il contenuto, ma se vi prendete del tempo per esaminare il contenuto e per strutturarlo per la massima flessibilit\u00e0 e per il massimo riutilizzo, avrete tolto tutti i pezzi irrilevanti e sarete meglio preparati per quando arriver\u00e0 sul mercato il prossimo gadget. Questo estratto dal nuovo libro di Karen McGrane, citeContent Strategy for Mobile\/cite, vi aiuter\u00e0 a cominciare.<\/p>\n","protected":false},"author":818,"featured_media":7000680,"comment_status":"open","ping_status":"open","template":"","categories":[254,273,79,253],"tags":[],"coauthors":[380],"class_list":["post-324","article","type-article","status-publish","has-post-thumbnail","hentry","category-content-strategy","category-mobile-multidevice","category-numero-64-22-novembre-2012","category-writing"],"jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/article\/324","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=324"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/media\/7000680"}],"wp:attachment":[{"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/media?parent=324"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/categories?post=324"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/tags?post=324"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/coauthors?post=324"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}