I video delle altre sessioni sono visibili qui: http://channel9.msdn.com/Events/Windows-Phone-8-Developer-Day/Windows-Phone-8-Developer-Day-Italy

Buona visione.

In uno scenario di tipo “in app dialog”, la cosa che dobbiamo tenere sempre a mente è che, l’intero flusso di interazione, deve basarsi esclusivamente su una interazione vocale. La nostra applicazione (o meglio, la funzionalità che decidiamo di implementare), non deve mai richiedere che l’utente usi il dispositivo. Usando questo principio come linea guida, proviamo ad immaginare un workflow per il salvataggio di un appunto vocale.

Il primo passo sarà sicuramente quello di creare un Voice Command adeguato che ci rimandi ad una pagina specifica per l’inserimento del nostro appunto. Esattamente come abbiamo visto qui. Una volta riconosciuto il comando, verremo ridirezionati alla pagina di creazione di una nota. Useremo molto probabilmente la stessa pagina che viene usata nel normale flusso con la differenza che, sapendo che siamo arrivati usando un comando vocale, avvieremo l’interazione vocale anziché aspettarci l’input da tastiera. Questa interazione dovrà basarsi sull’accoppiata Text-To-Speech e riconoscimento vocale per guidare l’utente verso il completamento del task (creare l’appunto vocale). Un ipotesi di flusso per un task semplice come questo potrebbe essere la seguente:

L’interazione, come visibile nel diagramma, è abbastanza semplice: useremo il text to speech per effettuare tutte le varie richieste, i custom grammar per i comandi ed il riconoscitore vocale per il riconoscimento del testo da inserire nella nota.

Vediamone i vari passaggi tradotti in codice. Il primo passaggio è quello di iniziare una interazione vocale se abbiamo avviato l’app usando il Voice Command:

Il metodo StartReco incapsula tutta la parte di interazione vocale quindi, come primo passaggio, predisponiamo il riconoscitore vocale:

ed i comandi:

A questo punto, usiamo il sintetizzatore per chiedere al nostro utente di dettare la nota ed avviamo il riconoscitore vocale

Usando lo SpeechRecognizerUI abbiamo il vantaggio che la rilettura del testo riconosciuto viene fatta automaticamente. A questo punto, non ci resta che richiedere all’utente il comando da eseguire e processarlo correttamente:

A questo punto, sta a noi decidere cosa fare a fine interazione. In questo caso, si viene rimandati alla pagina principale ma potrebbe essere sensato anche chiudere l’applicazione, il tutto usando solo i comandi vocali.

L’interazione mostrata in questo esempio, sebbene completa, è abbastanza semplice da implementare. Qualora doveste trovarvi di fronte a tipi di interazione più complesse, ricordate sempre la regola che, se in uno scenario di tipo in app dialog, non deve mai essere necessario usare il touch screen per chiudere l’interazione e, con questa premessa, implementate il vostro codice.

Lo scopo di questo “mattone”, come è facile da intuire, quello di tradurre l’input vocale recepito dal microfono in testo scritto, utilizzabile nelle nostre applicazioni. Per via della complessità insita nella procedura di riconoscimento vocale, il lavoro di “traduzione” viene eseguito sul cloud da server dedicati allo scopo. La scelta di questa modalità, condivisibile o meno,  è dettata da due fattori fondamentali:

1. precisione: tradurre correttamente la voce in testo è una operazione estremamente complessa e onerosa. Sebbene l’hardware dei nostri smartphone sia di tutto rispetto, un accurato riconoscimento vocale richiede macchine decisamente più potenti
2. velocità: il riconoscimento deve essere una operazione veloce, soprattutto in scenari di in-app dialog. L’hardware degli smartphone attuali (e non solo Windows Phone), non può garantire estrema precisione e velocità di elaborazione in questi contesti specifici

A questi due fattori, si aggiunge un terzo elemento tutt’altro che trascurabile: la durata della batteria. E’ ovvio che più capacità di calcolo chiediamo al processore, maggiore sarà il consumo energetico e minore sarà la durata della batteria. L’elaborazione on line unisce, di fatto, precisione e velocità nel riconoscimento ed un dispendio energetico molto modesto.

Ovviamente, non saremo noi ad occuparci dello scambio dati tra il nostro dispositivo ed i server di riconoscimento vocale. A fare tutto il lavoro se ne occupa l’oggetto SpeechRecognizerUI. Una volta configurato ed istanziato, sarà sufficiente richiamare il metodo RecognizeWithUIAsync per avviare il processo di riconoscimento attraverso l’interfaccia utente a cui siamo ormai abituati.

La configurabilità di questo componente è relativa ad alcuni aspetti della UI di riconoscimento e del comportamento del riconoscitore. Nello specifico:

Una volta avviato il riconoscitore, non ci resta che gestire il risultato. Esso sarà contenuto in un oggetto di tipo SpeechRecognitionUIResult al cui interno, oltre al testo riconosciuto, troveremo altre informazioni come il livello di confidence.

Dal punto di vista del codice, il tutto si traduce in poche righe di codice:

Il livello di confidence, accessibile dalla property result.RecognitionResult.TextConfidence, può avere i valori High, Medium, Low e Rejected e può essere utile a gestire eventuali interazioni in caso di riconoscimento “incerto”. Nell’eventualità il livello di confidence sia diverso da High, abbiamo la possibilità di recuperare una serie di alternative attraverso il metodo GetAlternates().

L’utilizzo della UI in fase di riconoscimento, sebbene sia molto comodo ed utile, diventa scomodo e di intralcio quando, ad esempio, dobbiamo gestire eventuali comandi. Pensiamo alla nostra applicazione per prendere appunti: se per riconoscere il comando di salvataggio o di annullamento dobbiamo scomodare tutto il flusso del riconoscimento vocale (cloud compreso), l’applicazione diventerebbe inusabile. Per ovviare a questo problema, è stato introdotto il concetto di Speech Recognition Grammar. Grazie ad esso, abbiamo la possibilità di creare un set limitato di parole che verranno riconosciute localmente (quindi senza scomodare il cloud) e senza la necessità di utilizzare la UI. Lo scenario tipico è appunto quello di poter definire dei comandi o delle parole chiave per compiere action specifiche nella nostra applicazione.

Anche l’utilizzo delle custom grammar è molto semplice: innanzitutto definiamo e registriamo i nostri comandi in questo modo:

Quando dobbiamo utilizzarli, sarà sufficiente usare l’oggetto  RecognizeAsync() che, come il RecognizeUIAsync visto in precedenza, restituirà il testo riconosciuto che poi potremmo gestire:

Ora che abbiamo tutti gli elementi, non ci resta che impostare il vero e proprio “in app dialog”, che vedremo nel prossimo post.

Ma per poter implementare uno degli scenari più interessanti su Windows Phone 8, l’In App Dialog, ci manca una parte fondamentale: il text to speech.

In Windows Phone 8, la sintesi vocale è demandata all’oggetto SpeechSyntesizer e precisamente al metodo SpeakTextAsync.

Il metodo SpeakTextAsync accetta in ingresso il testo da sistetizzare, ed il device provvederà a leggerlo. Di default, il sintetizzatore userà la lingua ed il tipo di voce selezionati nelle impostazioni del sistema operativo:

Se l’impostazione di default non è quella che vogliamo, possiamo comunque configurare il sintetizzatore, impostando genere e lingua via codice.

Resta inteso che, prima di effettuare queste operazioni, dobbiamo verificare che la lingua desiderata sia installata nel sistema.

Per farlo, sarà necessario interrogare l’oggetto Windows.Phone.Speech.Synthesis.VoiceInformation alla ricerca del tipo di voce di cui abbiamo bisogno.

La lettura del testo passato come stringa, come è facile immaginare, non avrà cadenze o inflessioni particolari. Il testò verrà letto in modo abbastanza “piatto”. Sebbene la voce sia abbastanza naturale e va benissimo nella maggior parte dei casi, ci sono scenari in cui più essere necessario impostare il sintetizzatore per dare enfasi particolari, pause, voci diverse etc. Ovviamente, in questi casi, una semplice stringa non è sufficiente a descrivere correttamente il modo in cui vogliamo che il nostro testo venga letto. Ad aiutarci, in questi casi, c’è lo Speech Synthesis Markup Language (SSML). Usando un markup standardizzato, possiamo infatti passare al sintetizzatore non solo il testo da leggere ma anche il “modo” in cui il testo deve essere letto. Un elenco completo degli elementi utilizzabili è consultabile qui.

Una volta “costruito” il nostro elemento vocale, dobbiamo passarlo al sintetizzatore in modo che possa essere letto dal dispositivo. Per farlo, abbiamo a disposizione 2 metodi:

• SpeakSsmlAsync: a qui passiamo il nostro xml
• SpeakSsmlFromUriAsync: a cui passiamo il path del file da riprodurre.

Ad esempio:

Il primo caso, è utile soprattutto quando dobbiamo costruire a runtime il messaggio da far leggere al sintetizzatore. Il secondo invece, torna estremamente comodo per salvare tutte le frasi statiche che la nostra applicazione dovrà gestire.

Per scenari più complessi, lo SpeechSyntesizer, ci fornisce anche 2 eventi che possiamo gestire:

• SpeechStarted: viene sollevato quando il dispositivo inizia a sintetizzare il testo
• BookmarkReached: è utilizzabile solo quando usiamo lo SpeakSsml e viene sollevato quando raggiungiamo l’elemento <mark> nel nostro file.

Sebbene alquanto semplice, l’implementazione del Text to Speech su Windows Phone ci permette di implementare scenari abbastanza evoluti e, come specificato all’inizio, è parte fondamentale dello scenario di In App Dialog.

Nel prossimo post vedremo il terzo pilastro fondamentale, ovvero il riconoscimento vocale e poi passeremo a mettere tutto insieme per realizzare un vero e proprio dialogo con la 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

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)

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:

Recuperabili poi semplicemente con

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.

Vi ricordo che su questa pagina trovate l’index dei vari post in lavorazione con la relativa programmazione.

Colgo l’occasione per chiedervi una cosa: attualmente gli articoli sono schedulati con cadenza settimanale. Secondo voi, 7 giorni sono troppi o troppo pochi?

Per rispondere potete usare i commenti o usare il form di contatto.

Grazie

Se siete interessati, le slide e demo sono disponibili qui.

Il codice è abbastanza commentato ma, se avete domande, dubbi o perplessità, non esitate a contattarmi qui o su twitter!

Visto il poco tempo a disposizione (20 minuti sono saltati a causa di problemi con il video), non sono riuscito ad approfondire alcuni aspetti. Cercherò di farlo prossimamente su questo blog.

Colgo l’occasione per ringraziare tutti i partecipanti!

Alla prossima!

The Player Framework is an open source video player available for Silverlight, HTML5, and Xbox, as well as Windows 8 apps and Windows Phone apps. It allows you to play both progressive download videos and Smooth Streaming videos.

Download the Player Framework

http://playerframework.codeplex.com/releases/view/97645

Fonte: Microsoft Media Platform – Player Framework

L’operazione, di per se, è molto semplice: si tratta di una sola riga di codice:

E’ sufficiente chiamare il metodo InstallCommandSetFromFileAsync dell’oggetto VoiceCommandService per effettuare la registrazione. Sebbene sia sufficiente eseguire questo metodo solo una volta, questo approccio è sconsigliabile per un semplice motivo: backup/restore del device.

In caso di restore infatti, il file non risulterà registrato e non saranno utilizzabili i comandi vocali. Per risolvere questa problematica, l’approccio consigliato è quello di registrare il file ad ogni avvio dell’applicazione inserendo la chiamata nel metodo Application_Launching del file App.Xaml.cs.

Un approccio più evoluto potrebbe inoltre essere quello di memorizzare, in un setting, l’avvenuta registrazione.

E’ inoltre buona norma inserire la registrazione del file VCD all’interno di un blocco Try/Catch in quanto potrebbero verificarsi problemi in fase di registrazione. Il problemi più comuni sono 2 (entrambi già individuabili in fase di debug). Il primo, in cui in genere si incappa la prima volta, è un errore di tipo UnauthorizedAccessException. Accade perchè, per il corretto funzionamento del riconoscimento vocale, dobbiamo impostare 2 capability specifiche:

• ID_CAP_MICROPHONE
• ID_CAP_SPEECH_RECOGNITION

Il secondo problema “comune” è l’utilizzo, come CommandPrefix, di una parola riservata. Il CommandPrefix, come abbiamo visto qui, serve a definire il nome “pronunciabile” della nostra applicazione. Ma, come sappiamo, esistono una serie di comandi nativi come “chiama”, “apri”, “cerca” etc. Se usassimo uno di questi nomi, otterremo una eccezione di tipo System.Execption su System.Collections.ListDictionaryInternal .

Nel blocco try/catch, è comunque buona norma prevedere un sistema di logging ed invio degli errori (questo vale in generale, e non solo per la registrazione del file VCD).

Una volta registrato il file, i nostri comandi saranno disponibili all’interno del sistema di riconoscimento vocale di Windows Phone 8 (tenendo premuto il pulsante start)

Come è possibile vedere nelle immagini, le informazioni e gli esempi sono esattamente quelli che avevamo definito nel nostro file VCD.

Nel prossimo post, vedremo come gestire l’arrivo dei comandi vocali nella nostra applicazione.

Ovviamente non copiate tutto ma solo gli assembly mancanti al fine di compilare la vostra documentazione!