A cosa ci riferiamo esattamente quando parliamo di applicazioni vocali? D'istinto verrebbe da rispondere: "ogni qualvolta usiamo la voce per interagire con un computer siamo di fronte ad un software vocale, sia che si utilizzi una cuffia con microfono sia che si usi il telefono". Le tecnologie vocali, quindi, possono anche essere utilizzate per accrescere significativamente l'accessibilità delle pagine Web. Ogni webdesigner dovrebbe essere in grado di riconoscerne vantaggi ed ambiti applicativi...
Esistono ad oggi diverse tipologie di applicativi che utilizzano come veicolo la voce: software di dettatura, IVR (Interactive Voice Response), agenti di risposta automatica, post-operatori automatici, eccetera. A livello "anatomico", un'applicazione vocale si riconosce per le seguenti caratteristiche:
• Speech independent: il sistema non necessita di alcun addestramento;
• Linguaggio naturale: l'utente non deve imparare specifici comandi, si esprime in modo naturale come con un operatore umano;
• Interrompibile: l'utente può interrompere in qualsiasi momento l'operatore automatico;
• Mixed initiative: gli alberi del dialogo non sono rigidi: sono costruiti per adattarsi alle risposte date dall'utente;
• Linguaggio XML: il software è realizzato in linguaggi standard XML che hanno dimostrato grande diffusione e affidabilità.
Una volta descritte le principali caratteristiche tipiche, chiariamo quali applicativi di uso comune non sono applicazioni vocali:
• Software per la lettura di siti Web: vengono utilizzati per leggere all'utente porzioni della pagina attraverso un browser standard. Possono essere realizzati incorporando tecnologie quali applet Java, oggetti in Flash, eccetera, ma non sono in grado di accettare input in ingresso, non sono interrompibili e non sono scritti in linguaggi standard XML.
• Software di dettatura: questi software permettono la dettatura di testi, email, note, eccetera. Per essere utilizzati necessitano di una profilazione (addestramento) dell'utente e quindi non sono speech-independent.
• DTMF (Dual Tone Multi-Frequency): sono risponditori automatici che permettono l'interazione attraverso la tastiera del telefono.
• IVR (Interactive Voice Response): analoghi ai precedenti, ma accettano brevi comandi vocali per la navigazione dei menu.
COME FUNZIONA
Per aiutarci a capire come funzionano realmente le applicazioni vocali, proviamo a fare l'esempio di un possibile (ed auspicabile) servizio automatico per la società Autostrade, dove un utente alla guida del proprio mezzo può collegarsi alla nostra applicazione mediante il proprio cellulare e chiedere informazioni sul percorso autostradale da seguire (frase evidenziata in rosso).
Risponditore Automatico (applicazione vocale): Benvenuto nel servizio informativo sul traffico, cosa desidera conoscere?
Utente: Vorrei sapere le condizioni del traffico.
Risponditore: mi dica di quale tratto autostradale desidera conoscere le condizioni e qual è la sua attuale posizione.
Utente: Sono a Genova sulla A12 in direzione Livorno.
Risponditore: Sono spiacente di informarla che ci sono 12 KM di coda in prossimità di La Spezia. Desidera che indichi una strada alternativa?
Utente: Si, grazie!
Risponditore: Quale è la sua destinazione?
Utente: Parma.
Risponditore: Le consigliamo la A7 in direzione Milano, dopo Tortona prosegua sulla A21 in direzione Piacenza, a questo punto prenda la A1 in direzione Parma. Le invio un SMS con il percorso?
Utente: Sì grazie.
Risponditore: Il messaggio è stato inoltrato, la ringrazio di aver chiamato.
Come si può facilmente desumere questa interazione tra utente e applicazione è completamente diversa da quelle esaminate nei casi precedenti e soprattutto dalla maggior parte dei sistemi di riposta automatica in uso presso le aziende. Nella frase "sono a Genova sulla A12 in direzione Livorno", in verità l'utente avrebbe potuto dire anche:
• Sono sulla A12 in direzione Livorno.
• Sono a Genova in direzione Livorno.
• Sto andando verso Livorno sulla A12.
Questo perché un'applicazione vocale deve supportare il linguaggio naturale, quindi la possibilità che l'utente utilizzi differenti espressioni per fornirci la medesima informazione. Questa risposta dell'utente ci dimostra un'ulteriore caratteristica delle applicazioni vocali: la possibilità di fornire più informazioni con un'unica frase. Possiamo, infatti, scomporre la frase in tre parti:
• Sono a Genova: ci fornisce informazioni su dove si trovi l'utente.
• Sulla A12: su quale tratto autostradale.
• In direzione Livorno: il senso di percorrenza del tratto autostradale.
Riassumendo, quindi, un'applicazione vocale è un software in grado fornire informazioni all'utente, attraverso la voce, senza bisogno di addestramento alcuno e di interpretare il linguaggio naturale. Le applicazioni vocali nascono in ambito prettamente telefonico, ma attualmente, anche grazie all'avvento della convergenza tra telefonia e dati, si stanno estendendo all'utilizzo di qualsiasi dispositivo dotato di microfono.
COSA SERVE PER LA REALIZZAZIONE?
Le applicazioni vocali sono una possibile modalità di presentazione dei nostri dati, ma cosa serve per realizzare un'applicazione vocale e renderla disponibile via telefono? Facciamo riferimento allo schema rappresentato in Figura 1.
Figura 1 - Architettura classica di un'applicazione vocale: l'utente si collega direttamente (I) o tramite un Server Vocale (II)
Nella parte superiore è raffigurata una classica applicazione Web, in cui l'utente si collega, attraverso un PC, al nostro server per richiedere una pagina XHTML. Nella parte inferiore della figura, invece, viene aggiunto un Server Vocale (chiamato anche Voice Gateway) che interpreta una serie di pagine in VoiceXML e ne veicola il contenuto attraverso il telefono ad un utente remoto. Questo ci permette di dire che la nostra applicazione vocale rappresenta una verticalizzazione di un'applicazione Web esistente e che può essere scritta senza alterare le logiche applicative preesistenti.
Figura 2 - Possibile interazione tra utente e Server: con GUI (I) e tramite voce (II)
Analizzaimo in dettaglio, invece, la Figura 2. Il punto (I) mostra un tipico form Web per l'autenticazione di un utente, dove il layer di presentazione è una GUI (Graphic User Interface) in XHTML con due campi. I dati vengono collezionati ed inviati ad un'altra pagina (sul server) sotto forma di query string. Sempre in Figura 2, al punto (II), il nostro utente utilizza il telefono ed un dialogo guidato per collezionare i valori dei due campi (in questo caso parleremo di Voice User Interface o VUI) ed inviarli al server, utilizzando il medesimo formalismo. Questo semplice esempio ci permette di capire quale sia la relazione tra la VUI, client-side, il business layer della nostra applicazione e, soprattutto, come sia possibile verticalizzare la nostra soluzione per creare una interfaccia vocale.
I LINGUAGGI STANDARD
Per quanto riguarda i linguaggi per lo sviluppo delle applicazioni vocali, lo standard che si è imposto a livello internazionale è il VoiceXML. L'attività del Voice Browser Working Group è consultabile all'indirizzo www.w3.org/Voice/. La prima cosa che dobbiamo conoscere di un documento VoiceXML è l'intestazione XML che contiene i riferimenti allo schema ed ai namespaces:
<?xml version="1.0" encoding="UTF-8">
< vxml xmlns="http://www.w3.org/2001/vxml"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xsi:schemaLocation= "http://www.w3.org/2001/vxmlhttp://www.w3.org/TR/voicexml20/vxml.xsd" version="2.0">
A questo punto possiamo scrivere il nostro primo documento: una versione modificata del famoso "Hello World":
<?xml version="1.0" encoding="UTF-8"?>
<vxml version="2.0" xml:lang="it-IT">
<form>
<block>
<prompt>Ciao a tutti i lettori di Internet Magazine</prompt>
</block>
</form>
</vxml>
Quando un utente chiamerà, sentirà leggere il testo che abbiamo incluso all'interno del tag <prompt>. Le operazioni di sintesi dell'audio, a partire da un testo, vengono realizzate attraverso un motore di Text to Speech (TTS). Questo ci permette di creare messaggi dinamici al posto dei classici file audio pre-registrati, che poco si adattavano ad applicazioni dinamiche. In VoiceXML è possibile utilizzare file audio al posto (o insieme) dei prompt utilizzando il tag <audio> ed indicando come valore dell'attributo "src" il percorso del file da riprodurre: ...
<form>
<block>
<prompt>Ciao a tutti i lettori di Internet Magazine</prompt>
<audio src="hello.wav"> </audio>
</block>
</form>
</vxml>
INTERAZIONE CON L'APPLICAZIONE
Vi sono due modalità differenti di interazione: i menu ed i form. In un <menu>, come il seguente, leggiamo al nostro utente, sempre attraverso il tag <prompt>, le possibili scelte ed indichiamo come unico possibile metodo di interazione la tastiera del telefono (inputmodes = dtmf):
...
<menu>
<property name="inputmodes" value="dtmf"/>
<prompt> per lo oroscopo premi 1, per le news premi 2, per lo sport premi 3.
</prompt>
<choice dtmf="1"next="http://www.oroscopo.example.com/vxml/start.vxml"/>
<choice dtmf="2" next="http://www.news.example.com/start.vxml"/>
<choice dtmf="3" next="http://www.sport.example.com/start.vxml"/>
</menu>
...
Ad ogni scelta <choice> associamo poi un tasto, attraverso l'attributo DTMF, ed un percorso di destinazione ovvero la URI indicata all'interno dell'attributo next. Ogni qualvolta il nostro utente chiamerà l'applicazione gli verrà chiesto di scegliere tra 1, 2 o 3, per poi essere reindirizzato ad un nuovo file VoiceXML. L'elemento <form>, a differenza del menu (il quale consentiva soltanto la selezione da una sequenza di opzioni predefinite), ci permette di rivolgere all'utente una domanda diretta e di ascoltarne ed interpretarne la risposta. Un form VoiceXML ha le seguenti caratteristiche:
• è composto da campi che si definiscono attraverso il tag <field>,
• supporta sia <prompt> che <audio>,
• necessita della definizione di un dizionario di risposte possibili (detto grammatica di riconoscimento o semplicemente grammatica) attraverso il tag <grammar>.
Quando si invoca un tag <form> all'interno della nostra applicazione, viene letto un prompt (o eseguito un audio) all'utente e il sistema si prepara per ricevere l'input. A questo punto abbiamo tre diverse possibilità:
• evento filled: l'input dell'utente corrisponde ad uno dei valori indicati nella nostra grammatica;
• evento noinput: non viene ricevuto alcun input dell'utente;
• evento nomatch: l'input utente non corrisponde ai valori della nostra grammatica.
DAL DTMF ALLA VOCE
Fino a questo punto nei nostri esempi abbiamo utilizzato come input esclusivamente la tastiera del telefono, ma la vera potenzialità del VoiceXML si evince dall'utilizzo della voce. La parte di "ascolto" degli input viene assolta dai motori di Automatic Speech Recognition (ASR) che trasformano l'audio in testo, confrontandolo con dei dizionari di parole e frasi specifici (grammatiche) scritte utilizzando diversi linguaggi, tra cui ricordiamo quello che attualmente rappresenta lo standard W3C: SRGS (Speech Recognition Grammar Specification). Il livello degli attuali ASR è caratterizzato da una percentuale di riconoscimento superiore al 97%, supporta l'utilizzo del linguaggio naturale e ad oggi un vastissimo numero di lingue. Alcuni dei limiti significativi sono rappresentati dagli ambienti rumorosi e dalle grammatiche con molti elementi (pensate ai cognomi di un elenco telefonico).
TOOL DI SVILUPPO
Ma come fare per pubblicare del codice VoiceXML appena creato per ascoltarlo via telefono? Dove trovo i motori ASR e TTS? Questo compito viene assolto dal Gateway Vocale (Figura 1). Non ci resta quindi che trovare un gateway che ci offra servizi di "housing", possibilmente gratuiti. attualmente sono possibili diverse soluzioni on line gratuite che offrono sia hosting che supporto allo sviluppo, tra cui:
• il sito dell'italiana Loquendo, che attraverso il proprio LoquendoC@fe mette a disposizione un ambiente di sviluppo e debug.
• VoxPilot che rende disponibile un accesso web alla propria piattaforma Open Media Platform.
• Ed ancora TellMe Studio, Voxeo Community ed altri.
Figura 3 - Un'applicazione vocale incorporata nel noto videogame "Prince of Persia", permette di cambiare vista e utilizzare armi (www.nuance.com/speech/demos/)
QUALI VANTAGGI?
Alcuni dei vantaggi dell'introduzione delle applicazioni vocali all'interno delle nostre applicazioni sono:
• Aumento delle possibilità d'impiego per portatori di handicap come ipovedenti o persone con difficoltà di movimento. Rendere disponibili le nostre applicazioni ed i nostri siti all'interazione vocale permette non solo un ampliamento del bacino di utenza, ma soprattutto renderà fruibili le risorse in modo completo ed efficiente da parte di quelle categorie di utenti.
• Maggiore accessibilità: utilizzo da parte di utenti le cui mani sono impegnate o che comunque non possono utilizzare un'interfaccia grafica. Basti pensare ai navigatori satellitari (Figura 4) e ai più moderni computer di bordo installati sulle automobili, oppure ad un operatore di un particolare strumento meccanico che ha le mani impegnate nel manovrarlo.
• Call center 24/24 ore: la maggior parte dei servizi di help desk sono limitati nell'arco della giornata. Se fosse il nostro server a rispondere alle domande degli utenti potremmo rendere disponibile il servizio 24 ore al giorno per 7 giorni alla settimana e 365 giorni all'anno, senza nessun costo aggiuntivo.
La nostra applicazione sarà in grado di filtrare le chiamate, fornendo risposte a quelle più frequenti in modo automatico lasciando libero l'operatore di gestire solo i casi più difficoltosi o particolari. Questo si tradurrebbe in una maggiore fluidità delle evasioni delle chiamate ed eviterebbe all'utente lunghe e snervanti attese (quante volte avente riagganciato il telefono, piuttosto contrariati, dopo aver atteso per alcuni minuti che l'operatore vi rispondesse costretti ad ascoltare la noiosissima musica di attesa in loop).
Figura 4 - Un GPS che permette di ricevere comandi vocali
CONCLUSIONI
Lo stato attuale delle tecnologie di sintesi e di riconoscimento, la diffusione dei telefoni cellulari, l'affermarsi di terminali mobili, lo sviluppo di nuovi protocolli a metà tra mondo telefonico e dati, e la necessità degli utenti di essere sempre connessi e di poter disporre di interfacce semplici e naturali, sono tutti sintomi di una profonda trasformazione in atto. Se a questo si aggiunge la necessità di poter interagire con un computer in modo semplice e naturale e di creare applicazioni a misura d'uomo (e non viceversa...), non è impossibile immaginare un prossimo scenario in cui potremo parlare con il Web e con le nostre applicazioni.