[#wpdev] Speech API: Gestione del Voice Command

Nel precedente post, ci siamo lasciati con il VoiceCommandDefinition file registrato nel nostro sistema. Adesso siamo finalmente pronti a ricevere i nostri comandi vocali tradotti nella nostra applicazione.

Come abbiamo visto nel post relativo all’anatomia del file VCD, una volta che il nostro comando viene interpretato dal riconoscitore vocale integrato in Windows Phone, verrà aperta la pagina specificata nel nodo “Navigate” accodando in querystring gli eventuali parametri riconosciuti

30-01-2013 21.43

A questo punto, appare evidente che, la gestione del comando vocale da parte nostra, è soggetta alle stesse regole della gestione di una normale navigazione tra le pagine della nostra applicazione. In funzione del comando ricevuto, andiamo a recuperare dalla querystring gli eventuali parametri ed eseguiamo il nostro codice.

Questa modalità di gestione è decisamente molto furba: ci permette infatti di aggiungere i comandi alla nostra applicazione, senza dover stravolgere il normale flusso di navigazione della nostra applicazione. Prendiamo ad esempio una applicazione per la gestione delle nostre note: avremo sicuramente una pagina per aggiungere i nostri appunti ed una pagina di dettaglio che, recuperando l’identificativo della nota, ce ne mostrerà tutti i dettagli. Se volessimo aggiungere l’apertura tramite i comandi vocali, il flusso di navigazione resterebbe inalterato ed i nostri metodi già implementati sarebbero riutilizzabili anche per l’iterazione vocale.

Unica differenza è l’aggiunta di una ulteriore chiave alla querystring chiamata voiceCommandName.

La sua presenza ha una duplice funzionalità:

  1. ci da evidenza dell’apertura della pagina attraverso i comandi vocali
  2. contiene il comando che è stato inviato (specificato nel file VCD)

03-03-2013 10.28

Come è evidenziato nell’immagine qui sopra, da parte nostra è sufficiente controllare la presenza della chiave voiceCommandName per discriminare l’arrivo in pagina attraverso un comando vocale e, se necessario, possiamo poi estrarre il comando e reagire di conseguenza.

Se abbiamo strutturato il nostro file VCD per interpretare anche dei parametri, troveremo anche essi nella nostra querystring con la stessa chiave specificata nel nostro file:

03-03-2013 11.07

Recuperabili poi semplicemente con

03-03-2013 11.17

E’ importante differenziare l’arrivo da un comando vocale per modificare il comportamento della nostra applicazione e rendere l’esperienza utente conforme con il tipo di interazione richiesto. Ad esempio, se il comando richiesto è quello di aggiungere una nota, è evidente che la nostra applicazione dovrà comportarsi in modo diverso se stiamo usando i comandi vocali piuttosto che la normale interazione touch.

Nel primo caso, ci si aspetta infatti che l’applicazione riceva il testo attraverso appunto la nostra voce (dettatura) mentre, nel secondo, la nota andrà scritta usando la tastiera.

Ho evidenziato questo punto in quanto lo ritengo decisamente importante (e non scontato) ai fini dello sviluppo di una buona applicazione che faccia uso dei comandi vocali. Fermo restando che la logica implementativa della vostra applicazione deve restare invariata (per non impazzire), l’esperienza utente deve essere differenziata. Il nostro codice per salvare, recuperare, modificare etc,, non va assolutamente modificato (se avete fatto un buon lavoro di progettazione, sarà sufficientemente astratto per per non doverlo riscrivere), ma prestate attenzione al tipo di interazione:

in nessun caso, se il tipo di interazione è vocale, deve essere chiesto all’utente di premere qualche controllo per completare la sua interazione, fatta eccezione per i problemi di interpretazione dei comandi. In questo caso, onde evitare di perdere il lavoro svolto dall’utente, può essere necessario passare all’interazione manuale.

Il riconoscimento vocale infatti, per sua natura, è soggetto a possibili errori di interpretazione. Basta infatti un rumore di fondo per renderlo poco preciso. Sebbene si possa gestire il livello di confidence (lo vedremo più avanti), non è detto che ci si trovi nelle condizioni ambientali adatte per questo tipo di interazione. Qualora si verificassero queste condizioni durante una interazione vocale già iniziata (siamo nel traffico, stiamo dettando una nota e passa un mezzo di soccorso a sirene accese), è buona norma gestire questa condizione e permettere agli utenti di passare ai comandi manuali.

A questo punto, la nostra applicazione con interazione vocale inizia a prendere forma. Abbiamo definito i comandi con cui “arrivare” nelle pagine della nostra applicazione, li abbiamo registrati sul nostro sistema ed abbiamo capito come gestirli all’interno della nostra applicazione. Queste sono le basi per impostare quello che viene definito “in app dialog”, ovvero la possibilità di interagire vocalmente con la nostra applicazione in modo bidirezionale.

Nel prossimo post, vedremo come “far parlare” la nostra applicazione per poi tornare al riconoscimento vocale ed instaurare un vero e proprio dialogo con l’app.

,