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

Alla fine del 2016, Gartner ha previsto che il 30% delle sessioni di navigazione web sarebbero state senza uno schermo entro il 2020. Sempre nello stesso anno ma precedentemente, Comscore aveva predetto che entro il 2020 tutte le ricerche saranno ricerche vocali. Sebbene ci siano delle prove recenti che suggeriscono che il quadro del 2020 possa essere più complicato di quanto implicato da queste proiezioni a grandi linee, stiamo già vedendo l’impatto che hanno le ricerche vocali, l’intelligenza artificiale e gli smart software agent come Alexa e Google Assistant sul modo vengono trovate e consumate le informazioni sul web.

L’articolo prosegue sotto

Oltre alla funzione di indicizzazione svolta dai motori di ricerca tradizionali, gli agenti intelligenti e gli algoritmi di ricerca basati su AI stanno ora introducendo nel mainstream due ulteriori modalità di accesso alle informazioni: aggregazione e inferenza. Di conseguenza, gli sforzi di progettazione che si concentrano sulla creazione di pagine visivamente efficaci non sono più sufficienti per garantire l’integrità o l’accuratezza dei contenuti pubblicati sul web. Piuttosto, concentrandosi sulla fornitura dell’accesso alle informazioni in modo strutturato e sistematico, leggibile sia dagli uomini che dalle macchine, gli editori di contenuti possono garantire che il loro contenuto sia accessibile e accurato in questi nuovi contesti, indipendentemente dal fatto che stiano producendo chatbot o sfruttando direttamente l’intelligenza artificiale. In questo articolo, esamineremo le forme e l’impatto dei contenuti strutturati e chiuderemo con una serie di risorse che possono aiutarvi a partire con un approccio strutturato alla progettazione delle informazioni.

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:

Pagina dei risultati di ricerca di Google per una ricetta di bouillabaisse che include un'immagine, indicazioni numerate e tag.

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

Il tool Google Structured Data Testing mostra il markup di un sito web di ricette di bouillabaisse nella metà sinistra dello schermo e gli attributi dei dati strutturati e i valori per il contenuto strutturato nella metà destra dello schermo.

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.

Combinazione di un editor di codice HTML e finestra di anteprima che mostra il markup e i risultati per i tag HTML heading, ordered list e list item.

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):

La pagina “How to Pay a Parking Ticket” del sito web City of Boston, che mostra una visualizzazione a tab di modi in cui pagare e le istruzioni per il primo di questi modi, pagamento online.

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:

L'app di Google Assistant sull'iPhone con i risultati della query “how do I pay a parking ticket in Boston”, che mostra risultati solo marginalmente correlati al contenuto voluto.

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:

La pagina “Pay My Ticket” del sito web di City of Seattle, che mostra quattro metodi per pagare una multa per divieto di sosta, è un layout semplice, tutto testuale.

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.

La app di Google Assistant sull'iPhone con i risultati della query “how do I pay a parking ticket in Seattle”, che mostra quasi gli stessi risultati della pagina web desktop a cui si è fatto riferimento prima.

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.

La pagina “Pay My Ticket” del sito web City of Seattle, con gli elementi heading HTML delineati ed etichettati come esempio.

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.

La pagina 'Pay My Ticket' del sito Web di City of Seattle, con due elementi heading HTML delineati ed etichettati per fini illustrativi e un pannello di ispezione aperto, in cui è possibile osservare che gli heading sono uguali agli spettatori ma hanno markup diverso nel codice.

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.

Pagina dei risultati di ricerca di Google per Scott Ruhlman, MD, che mostra un elenco di link standard e un'info box con un'immagine, una mappa, dei rating, un indirizzo e recensioni.

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.

Lo strumento di Google Structured Data Testing, che mostra il markup per la pagina del profilo del Dr. Ruhlman sulla sinistra dello schermo e gli attributi e i valori dei dati strutturati per il contenuto strutturato su quella pagina sulla destra dello schermo.

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 info box dei risultati della ricerca di Google per Dr. Ruhlman, mostrano una foto, una mappa, dei rating, un indirizzo, recensioni, pusanti per fare una domanda, lasciare una recensione e aggiungere una foto, insieme ad altre persone su cui sono state fatte ricerche.

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.

La pagina dei risultati di ricerca di Google per Dr. Donion, che mostra un elenco di link standard per Dr. Donion e un link 'Did you mean: Dr Stacy Donlon MD' in cima. C'è una info box di Google, come nell'esempio della precedente pagina dei risultati di ricerca. Ma in questo caso la box non mostra informazioni sulla dottoressa che abbiamo ricercato, Dr. Donion, ma per 'Kaiser Permanente Orthopedics: Morris Joseph MD.'

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:

La app di Google Assistant sull'iPhone con i risultati di una query “what time does dr. ruhlman office close”. I risultati mostrati includono una card con “8:30AM–5:00PM” e l'etichetta “Dr. Ruhlman Scott MD, Tuesday hours”, così come i link per chiamare l'ufficio, cercare su Google, ottenere indicazioni e visitare un sito web. Inoltre, ci sono quattro pulsanti etichettati con le parole “directions”, “phone number” e “address” e una emoji col pollice alzato.

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.

La app di Google Assistant sull'iPhone con i risultati di una query “what time does Doc Dr Stacey donion office close”. I risultati mostrati includono una card con “8AM–5PM” e l'etichetta “MulitCare Neuroscience Center, Monday hours”, insieme ai link per chiamare l'ufficio, cercare su Google, ottenere indicazioni o visitare un sito web.

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:

Sull’autore

Andy Fitzgerald

Andy Fitzgerald è un designer indipendente la cui pratica si concentra sulla user research, sull'architettura dell'informazione, sull'interaction design e sulla prototipazione. Lavora con organizzazioni di ogni dimensione per creare soluzioni eleganti e mirate a problemi complessi di informazione. Andy è un membro attivo delle comunità IA e UX, e parla a conferenze e facilita workshop in tutto il mondo.

Nessun commento

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *

Altro da ALA