Conversazioni con i robot: voce, smart agent e contenuti strutturati

Il ruolo del contenuto strutturato#section1

Nel loro recente libro, Designing Connected Content, Carrie Hane e Mike Atherton definiscono il contenuto strutturato come contenuto che è “pianificato, sviluppato e connesso al di fuori di un’interfaccia, così da essere pronto per qualsiasi interfaccia”. Un approccio di progettazione del contenuto strutturato inquadra le risorse di contenuto, come articoli, ricette, descrizioni dei prodotti, how-to, profili, etc., non come pagine da trovare e leggere, ma come pacchetti composti da piccoli pezzi di dati di contenuto che si riferiscono tutti gli uni agli altri in modi significativi.

In un processo di progettazione del contenuto strutturato, le relazioni tra i blocchi di contenuto sono definite e descritte in modo esplicito. Questo rende i blocchi di contenuto e le relazioni tra loro comprensibili dagli algoritmi. Gli algoritmi possono quindi interpretare un pacchetto di contenuto come la “pagina” che sto cercando, o remixare e adattare lo stesso contenuto per darmi un elenco di istruzioni, il numero di stelle su una recensione, la quantità di tempo rimasto fino alla chiusura di un ufficio e qualsiasi numero di altre risposte concise a domande specifiche.

Il contenuto strutturato è già un pilastro di molti tipi di informazioni sul web. Gli elenchi di ricette, per esempio, sono stati basati su contenuti strutturati per anni. Quando cerco, per esempio, “ricetta della bouillabaisse” su Google, ho a disposizione una lista standard di link alle ricette, oltre a una panoramica delle fasi della ricetta, un’immagine e una serie di tag che descrivono una ricetta di esempio:

Una “featured snippet” per allrecipes.com nella pagina dei risultati di Google.

La stessa pagina di allrecipes.com vista in Google’s Structured Data Testing Tool. Il pannello sulla destra mostra i valori machine-readable.

Questa visualizzazione “featured snippet” è possibile perché l’editore dei contenuti, allrecipes.com, ha suddiviso questa ricetta nei più piccoli frammenti significativi adatti a questo argomento e al pubblico, e ha poi espresso le informazioni relative a tali blocchi e le relazioni tra di essi in un modo machine-readable. In questo esempio, allrecipes.com ha utilizzato sia l’HTML semantico sia i dati linkati per far sì che questo contenuto non fosse solo una pagina, ma anche dati accessibili e comprensibili che possano essere interpretati, adattati e remixati con precisione da algoritmi e smart agents. Diamo un’occhiata a ciascuno di questi elementi per vedere come lavorano insieme nei contesti di indicizzazione, aggregazione e inferenza.

Software agent search e HTML semantico#section2

HTML semantico è markup ch comunica informazioni su relazioni significative tra gli elementi del documento, rispetto a semplicemente descrivere come dovrebbero apparire sullo schermo. Gli elementi semantici come i tag heading e list, per esempio, indicano che il testo che racchiudono è un heading (<h1>) per l’insieme di elementi della lista (<li>) nell’elenco ordinato (<ol>) che segue.

L’HTML strutturato in questo modo è sia di presentazione che semantico perché le persone conoscono l’aspetto e il significato degli heading e delle liste e gli algoritmi possono riconoscerli come elementi con relazioni definite e interpretabili.

Il markup HTML che si concentra solo sugli aspetti presentational di una “pagina” può sembrare perfettamente a posto a un lettore umano ma essere completamente illeggibile per un algoritmo. Prendete, per esempio, il sito web City of Boston, riprogettato alcuni anni fa in collaborazione con partner di progettazione e sviluppo di alto livello. Se volessi trovare informazioni su come pagare una multa per divieto di sosta, un link dalla pagina iniziale mi porta direttamente alla schermata “How to Pay a Parking Ticket” (si è scorso per mostrare i dettagli):

Come umano che legge questa pagina, capisco facilmente quali siano le mie opzioni per pagare: posso pagare online, di persona, per posta o per telefono. Tuttavia, se chiedo a Google Assistant come pagare una multa per divieto di sosta a Boston, le cose diventano un po’ confuse:

Nessuno dei link forniti nei risultati di Google Assistant mi porta direttamente alla pagina “How to Pay a Parking Ticket”, né le descrizioni mi fanno chiaramente capire che sono sulla strada giusta. (Non ho chiesto informazioni sul richiedere un’udienza). Questo accade perché il contenuto della pagina delle multe per divieto di sosta su City of Boston è progettato per comunicare visivamente le relazioni di contenuto ai lettori umani, ma non è strutturato semanticamente in modo che comunichi tali relazioni anche agli algoritmi indagatori.

La pagina “Pay My Ticket” di City of Seattle, sebbene manchi della ricercatezza dello stile visuale del sito di Boston, comunica anch’essa in maniera chiara le modalità di pagamento delle multe per divieto di sosta ai visitatori umani:

Tuttavia, l’equivalente ricerca con Google Assistant, offre un risultato molto più utile di quello che abbiamo visto per Boston. In questo caso, il risultato di Google Assistant ci collega direttamente alla pagina “Pay My Ticket” e inoltre elenca molti modi in cui posso pagare la multa: online, via posta e di persona.

Nonostante la semplicità visiva della pagina delle multe per divieto di sosta di City of Seattle, assicura in maniera più efficace l’integrità del suo contenuto in vari contesti perché è composta da contenuto strutturato e ha un markup semantico. “Pay My Ticket” è un heading di livello uno (<h1>) e ognuna delle opzioni sottostanti è costituita da un heading di livello due (<h2>), che indica che si tratta di subordinate all’elemento di livello uno.

Questi elementi, se ben progettati, comunicano la gerarchia e le relazioni delle informazioni visivamente ai lettori e semanticamente agli algoritmi. Questa struttura consente a Google Assistant di supporre ragionevolmente che il testo in questi heading <h2> rappresenti le opzioni di pagamento sotto l’intestazione <h1> “Pay My Ticket”.

Mentre questo uso dell’HTML semantico offre vantaggi distinti rispetto allo stile di “visualizzazione della pagina” che abbiamo visto sul sito della City of Boston, la pagina di Seattle mostra anche una debolezza tipica degli approcci manuali all’HTML semantico. Noterete che, nei risultati di Google Assistant, l’opzione “Pay by Phone” che abbiamo visto nella pagina Web non è stata elencata. Se osserviamo il markup di questa pagina, possiamo vedere che mentre le tre opzioni trovate da Google Assistant sono racchiuse in entrambi i tag <strong> e <h2>, “Pay by Phone” è contrassegnato solo con un <h2>. Questa irregolarità nella struttura semantica potrebbe essere ciò che induce Google Assistant a omettere questa opzione dai suoi risultati.

Sebbene ognuno di questi elementi appaia identico a un umano vedente che stia creando questa pagina, la macchina che lo interpreta trova una differenza. Sebbene i campi di inserimento testo WYSIWYG teoricamente supportano l’HTML semantico, in pratica troppo spesso sono preda delle idiosincrasie perfino degli autori di contenuto maggiormente ben intenzionati. Rendendo la struttura dei contenuti significativa un elemento centrale del sistema di gestione dei contenuti di un sito, le organizzazioni possono creare HTML semanticamente corretto per ogni elemento, ogni volta. Questo è anche il fondamento che consente di trarre benefici dalle ricche descrizioni delle relazioni fornite dai dati collegati.

Linked data e aggregazione del contenuto#section3

Oltre a trovare ed estrarre informazioni, come i passaggi di una ricetta o le opzioni di pagamento di una multa per divieto di sosta, gli algoritmi di ricerca e i software agent adesso aggregano anche il contenuto proveniente da più sorgenti usando i linked data.

Nella sua forma più semplice, linked data è “un insieme di best practice per collegare i dati strutturati sul web”. Linked data si estende oltre le capacità di base dell’HTML semantico descrivendo non solo che cosa sia un elemento di una pagina (“Pay My Ticket” è un <h1>), ma anche il concetto del mondo reale che quella cosa rappresenta: questo <h1> rappresenta una “azione di pagamento”, che eredita le caratteristiche strutturali delle “azioni commerciali” (lo scambio di beni e servizi con i soldi) e “azioni” (attività svolte da un agente su un oggetto). Linked data crea una descrizione più ricca e con maggiori sfumature della relazione tra gli elementi della pagina e fornisce le informazioni strutturali e concettuali che servono agli algoritmi per mettere insieme dati provenienti dalle sorgenti più disparate.

Supponiamo, per esempio, che io voglia raccogliere più informazioni su due raccomandazioni che mi sono state fatte sui chirurghi ortopedici. Una ricerca per la prima raccomandazione, Scott Ruhlman, MD, fa emergere un insieme di link così come una info box Knowledge Graph che contiene una foto, un luogo, orari, numero di telefono e recensioni dal web.

Se passiamo la pagina del profilo del Dr. Ruhlman dello Swedish Hospital al Structured Data Testing Tool di Google, possiamo vedere che il contenuto che lo riguarda è strutturato in piccoli elementi discreti, ciascuno dei quali ha un markup con tipi e attributi descrittivi che comunicano sia il significato dei valori di quegli attributi sia il modo in cui si integrano nel loro complesso, il tutto in un formato machine-readable.

In questo esempio, il profilo del Dr. Ruhlman è marcato con microdati basati sul vocabolario schema.org. Schema.org è un lavoro collaborativo sostenuto da Google, Yahoo, Bing e Yandex che mira a creare un linguaggio comune per le risorse digitali sul web. Questa base di contenuti strutturati fornisce la base semantica su cui è possibile costruire relazioni di contenuto aggiuntive. La info box del Knowledge Graph, per esempio, include recensioni di Google, che non fanno parte del profilo del Dr. Ruhlman, ma che sono state aggregate in questa panoramica, che include anche una mappa interattiva, resa possibile dal fatto che la posizione dell’ufficio del Dr. Ruhlman è machine-readable.

La ricerca di una seconda raccomandazione, Stacey Donion, MD, fornisce un’esperienza diversa. Come il sito City of Boston di cui sopra, il profilo di Dr. Donion sul sito web Kaiser Permanents è perfettamente intellegibile da un lettore umano vedente. Ma poiché il suo markup è interamente presentational, il suo contenuto è virtualmente invisibile ai software agents.

In questo esempio, possiamo vedere che Google è in grado di trovare moltissimi link per Dr. Donion nei suoi risultati indicizzati standard, ma non è in grado di “comprendere” le informazioni su quelle fonti sufficientemente bene per presentare un risultato aggregato. In questo caso, il Knowledge Graph sa che Dr. Donion è un medico di Kaiser Permanents, ma richiama la posizione sbagliata e il nome del medico sbagliato nel tentativo di creare una visualizzazione Knowledge Graph.

Noterai anche che mentre Dr. Stacey Donion è una corrispondenza esatta in tutti i risultati di ricerca elencati, che sono abbastanza numerosi da riempire la prima pagina dei risultati, viene mostrato un link “did you mean” per un altro medico. Stacy Donlon, MD, è un neurologo che pratica presso MultiCare Neuroscience Center, che non è affiliato con Kaiser Permanente. Multicare, tuttavia, fornisce profili semantici e collegati ai dati per i loro medici.

Query vocali e inferenza del contenuto#section4

La crescente diffusione della voce come modalità di accesso alle informazioni rende ancora più importante fornire contenuti strutturati e comprensibili alle macchine. I voice and smart software agent non solo liberano gli utenti dalle tastiere, ma modificano il comportamento degli utenti. Secondo LSA Insider, ci sono diverse differenze importanti tra le query vocali e le query digitate. Le query vocali tendono ad essere:

• più lunghe;
• è più probabile che chiedano chi, cosa e dove;
• più colloquiali;
• più specifiche.

Al fine di adattare i risultati a queste query formulate più specificamente, gli agenti software hanno iniziato a dedurre le intenzioni e quindi a utilizzare i linked data a loro disposizione per assemblare una risposta mirata e concisa. Se chiedo a Google Assistant a che ora chiude l’ufficio del Dr. Ruhlman, per esempio, mi risponde: “L’ufficio del Dr. Ruhlman chiude alle 17:00” e mostra questo risultato:

Questi risultati non sono solo aggregati da fonti disparate, ma sono interpretati e remixati per fornire una risposta personalizzata alla mia specifica domanda. Ottenere indicazioni, effettuare una telefonata e accedere alla pagina del profilo del Dr. Ruhlman su swedish.org sono tutti a mia disposizione.

Quando chiedo a Google Assistant a che ora chiude l’ufficio di Dr. Donion, il risultato non è solo meno utile, ma in realtà mi indirizza nella direzione sbagliata. Invece di una selezione mirata di azioni mirate per dare seguito alla mia query, mi vengono presentate le ore di apertura e le informazioni di contatto per MultiCare Neuroscience Center.

Il MultiCare Neuroscience Center, come ricorderete, è dove lavora il dottor Donlon, il neuroscienziato che Google pensa io stia cercando, non il chirurgo ortopedico che sto cercando. La pagina del profilo del Dr. Donlon, proprio come quella del Dr. Ruhlman, è strutturata semanticamente e contrassegnata con linked data.

Ad essere onesti, le prove successive di questa ricerca hanno prodotto l’ubicazione generica (e parzialmente incorretta) del luogo di lavoro di Dr. Donion (“Kaiser Permanente Orthopedics: Morris Joseph MD”). È possibile che tramite esposizione ripetuta ai termini di ricerca “Dr. Stacey Donion”, Google Asistant affini le risposte che fornisce. Il risultato iniziale, tuttavia, suggerisce che gli smart agent sono, almeno in parte, sensibili alla stessa Euristica della disponibilità che influenza gli umani, in cui l’informazione più semplice da richiamare sembra spesso la più corretta.

Non ci sono prove sufficienti in questo piccolo campione per supportare un’affermazione generica che gli algoritmi hanno pregiudizi “cognitivi”, ma anche quando permettiamo variabili che potenzialmente confondano, possiamo vedere i molteplici problemi in cui rischiamo di imbatterci ignorando il contenuto strutturato. “Donlon”, per esempio, potrebbe essere un nome più comune di “Donion” e potrebbe essere facilmente scritto in modo errato su una tastiera QWERTY. Indipendentemente da ciò, il risultato Kaiser Permanente che ci viene dato sopra per Dr. Donion è per il medico sbagliato. Inoltre, nella ricerca vocale dell’Assistente Google, il formato di interazione non verifica se intendessimo il Dr. Donlon: ci fornisce solo le informazioni di contatto della sua struttura. In questi casi, fornire contenuti chiari e machine-readable può andare solo a nostro vantaggio.

Il business case per la progettazione di contenuti strutturati#section5

Nel 2012, la content strategist Karen McGrane ha scritto che “non dovete decidere quale piattaforma o dispositivo i vostri clienti useranno per accedere ai vostri contenuti: sono loro a scegliere“.

Questa affermazione aveva lo scopo di aiutare i designer, gli strategist e le aziende a prepararsi per l’imminente ascesa dei dispositivi mobili. Continua a suonare vero per l’era dei linked data. Con la crescente prevalenza di smart assistant e query vocali, è sempre meno probabile che, con i rich content, il sito Web di un’organizzazione sia il primo incontro di un potenziale visitatore. In molti casi, come ad esempio trovare informazioni sulla posizione, orari, numeri di telefono e valutazioni, questo coinvolgimento pre-visita potrebbe essere l’unica interazione dell’utente con una fonte di informazioni.

Questi tipi di interazioni rapide, tuttavia, sono solo una piccola parte di una questione molto più ampia: i linked data sono sempre più importanti per mantenere l’integrità dei contenuti online. Le organizzazioni che ho utilizzato come esempi, ossia gli ospedali, le agenzie governative e le università con cui ho lavorato come consulente per anni, non misurano il successo del loro lavoro di comunicazione nelle visualizzazioni di pagina o nei clic sugli annunci. Il successo per loro significa connettere pazienti, componenti e membri della comunità con servizi e informazioni accurate sull’organizzazione, ovunque tali informazioni possano essere trovate. Questa definizione di successo basata sulla comunicazione si applica prontamente a qualsiasi tipo di organizzazione che lavora per promuovere i propri obiettivi commerciali sul web.

Il modello di creazione di pagine per poi aspettarsi che gli utenti scoprano e analizzino tali pagine per rispondere alle domande, benché collaudate nel tempo nell’era pre-vocale, sta diventando rapidamente insufficiente per una comunicazione efficace. Preclude alle organizzazioni di partecipare a modelli emergenti di ricerca e scoperta di informazioni. E, come abbiamo visto nel caso della ricerca di informazioni sui medici, può indurre gli agenti software a fare inferenze basate su informazioni insufficienti o errate, potenzialmente indirizzando i clienti verso concorrenti che comunicano in modo più efficace.

Comunicando chiaramente in un contesto digitale che ora include l’aggregazione e l’inferenza, le organizzazioni sono in grado di parlare più efficacemente ai propri utenti dove effettivamente si trovano gli utenti, che sia su un sito Web, su una pagina dei risultati dei motori di ricerca, o con un assistente digitale a comando vocale. Sono inoltre in grado di mantenere un maggiore controllo sull’accuratezza dei loro messaggi garantendo che il contenuto corretto possa essere trovato e comunicato attraverso i vari contesti.

Cominciare: chi e come#section6

Le pratiche di progettazione che creano collegamenti tra le esigenze degli utenti e i requisiti tecnologici per soddisfare gli obiettivi di business sono fondamentali per rendere questa visione una realtà. Architetti dell’informazione, content strategist, sviluppatori ed experience designer hanno tutti un ruolo da svolgere nella progettazione e nella fornitura di soluzioni di contenuti strutturati efficaci.

I professionisti di tutta la design community hanno condiviso negli ultimi anni una vasta gamma di risorse sulla creazione di sistemi di contenuti che funzionano sia per gli umani sia per gli algoritmi. Questi libri e articoli sono un ottimo punto di partenza per saperne di più sull’implementazione di un approccio al contenuto strutturato per la vostra organizzazione:

• Content Everywhere, Sara Wachter-Boettcher
• “Il content modelling: una capacità da avere”, Rachel Lovinger
• Content Strategy for Mobile, Karen McGrane
• Designing Connected Content, Carrie Hane e Mike Atherton