Download - Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale

Transcript
Page 1: Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale

POLITECNICO DI TORINO

III Facoltà di IngegneriaCorso di Laurea in Ingegneria Informatica

Tesi di Laurea Magistrale

Interfaccia utente basata sueye-tracking per sistemi di controllo

ambientale

Relatori:prof. Fulvio Cornodott. Emiliano Castellina

Candidato:Luigi De Russis

Febbraio 2010

Page 2: Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale

Indice

1 Introduzione 11.1 Contesto generale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Gaze tracking, interfacce utente e domotica . . . . . . . . . . . . . . . 21.3 Specifiche COGAIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.4 Struttura della tesi . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2 Obiettivi 9

3 Soluzioni tecniche adottate 173.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.2 Ambiente domotico . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.2.1 DOG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.2.2 DogOnt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.3 Eye Tracking Universal Driver (ETU-Driver) . . . . . . . . . . . . . . 24

4 Tecnologia utilizzata 274.1 Windows Presentation Foundation . . . . . . . . . . . . . . . . . . . . 274.2 XAML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.2.1 Caratteristiche . . . . . . . . . . . . . . . . . . . . . . . . . . 324.2.2 Code-behind . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.3 Compatibilità con le tecnologie precedenti . . . . . . . . . . . . . . . 384.3.1 Integrare controlli Win32 in WPF . . . . . . . . . . . . . . . . 394.3.2 Integrare controlli WPF in Win32 . . . . . . . . . . . . . . . . 404.3.3 Integrare Windows Forms e WPF . . . . . . . . . . . . . . . . 404.3.4 Integrare controlli ActiveX in WPF . . . . . . . . . . . . . . . 41

4.4 Differenze rispetto alle Windows Forms . . . . . . . . . . . . . . . . . 414.4.1 Vantaggi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424.4.2 Svantaggi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

5 Progettazione e implementazione 455.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

II

Page 3: Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale

5.2 Scelte progettuali e funzionalità . . . . . . . . . . . . . . . . . . . . . 485.2.1 “Home Management” ed “Electric Device” . . . . . . . . . . . . 525.2.2 Entertainment . . . . . . . . . . . . . . . . . . . . . . . . . . . 585.2.3 Temperature . . . . . . . . . . . . . . . . . . . . . . . . . . . . 595.2.4 Security e gli allarmi . . . . . . . . . . . . . . . . . . . . . . . 615.2.5 Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 635.2.6 Everything Else . . . . . . . . . . . . . . . . . . . . . . . . . . 645.2.7 Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

5.3 Realizzazione dell’interfaccia utente . . . . . . . . . . . . . . . . . . . 655.3.1 Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 685.3.2 Layout dei tab . . . . . . . . . . . . . . . . . . . . . . . . . . 705.3.3 Interazione con DOG . . . . . . . . . . . . . . . . . . . . . . . 735.3.4 Interazione con l’ETU-Driver . . . . . . . . . . . . . . . . . . 765.3.5 Organizzazione e riusabilità del codice . . . . . . . . . . . . . 78

6 Risultati ottenuti 796.1 Analisi qualitativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . 796.2 Analisi quantitativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . 806.3 Valutazione rispetto alle specifiche COGAIN . . . . . . . . . . . . . . 81

7 Conclusione e sviluppi futuri 857.1 Possibili sviluppi futuri . . . . . . . . . . . . . . . . . . . . . . . . . . 85

A Microsoft Expression Design 88

B Modello della casa utilizzato 91

C Esempio di codice XAML 94

Bibliografia 97

III

Page 4: Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale

Elenco delle tabelle

2.1 Rapporto tra raccomandazioni e interfacce utente per il controllodomotico esistenti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.2 Linee guida COGAIN per la realizzazione di un’applicazione di con-trollo ambientale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

4.1 Alcune comuni keyword XAML . . . . . . . . . . . . . . . . . . . . . 354.2 Vantaggi e svantaggi di WPF . . . . . . . . . . . . . . . . . . . . . . 445.1 Attribuzione dei colori ai bottoni dell’UI in base alla loro funzione . . 525.2 I principali pannelli presenti in XAML . . . . . . . . . . . . . . . . . 706.1 Specifiche computer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 806.2 Utilizzo della RAM da parte di DOGeye . . . . . . . . . . . . . . . . 806.3 Utilizzo della CPU da parte di DOGeye . . . . . . . . . . . . . . . . . 816.4 Valutazione di DOGeye secondo le linee guida COGAIN . . . . . . . 82

IV

Page 5: Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale

Elenco delle figure

1.1 Un esempio di eye-tracker commerciale: MyTobii P10 . . . . . . . . . 31.2 Un programma per la video-scrittura, basato su eye-tracking . . . . . 52.1 Vista, ad alto livello, del contesto in cui si colloca l’interfaccia utente

da realizzare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.2 Due interfacce utente per ambienti domotici . . . . . . . . . . . . . . 103.1 Come l’interfaccia utente è connessa a DOG e all’eye-tracker . . . . . 173.2 Un esempio di architettura logica di ambiente domotico . . . . . . . . 183.3 L’architettura logica di DOG . . . . . . . . . . . . . . . . . . . . . . . 203.4 L’ontologia DogOnt . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233.5 Parte dell’architettura dell’ETU-Driver . . . . . . . . . . . . . . . . . 244.1 Le tecnologie incluse nel framework .NET . . . . . . . . . . . . . . . 285.1 L’architettura generale dell’ambiente . . . . . . . . . . . . . . . . . . 455.2 La versione preliminare di DOGeye . . . . . . . . . . . . . . . . . . . 465.3 Il mock-up di DOGeye . . . . . . . . . . . . . . . . . . . . . . . . . . 485.4 L’interfaccia DOGeye . . . . . . . . . . . . . . . . . . . . . . . . . . . 495.5 Aspetto di DOGeye quando l’utente necessita qualche tipo di aiuto . 505.6 La planimetria della casa, così come viene visualizzata in “Home

Management” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 535.7 I tre possibili comportamenti ottenibili selezionando una stanza nei

primi due tab di DOGeye . . . . . . . . . . . . . . . . . . . . . . . . 555.8 Un esempio di interazione: aprire una porta . . . . . . . . . . . . . . 575.9 Un’esempio di notifica . . . . . . . . . . . . . . . . . . . . . . . . . . 575.10 Caratteristica di “Entertainment” . . . . . . . . . . . . . . . . . . . . 595.11 Esempio di come viene indicata la temperatura di una stanza, in

“Temperature” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 595.12 Esempio di come si imposta la temperatura del riscaldamento di tutta

la casa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 605.13 Il tab “Security” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 615.14 Esempio di gestione di un allarme . . . . . . . . . . . . . . . . . . . . 625.15 L’architettura generale di DOGeye . . . . . . . . . . . . . . . . . . . 68A.1 Microsoft Expression Design . . . . . . . . . . . . . . . . . . . . . . . 88

V

Page 6: Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale

Capitolo 1

Introduzione

1.1 Contesto generale

Secondo l’indagine ISTAT sulla “Condizione di salute e il ricorso ai servizi sanitari”del 2004-2005, in Italia ci sono 2 790 134 persone di età superiore a 6 anni afflitteda disabilità, considerando anche le persone residenti nei presidi socio-sanitari. Qui,per disabilità si intende qualsiasi limitazione o perdita della capacità di compiereun’attività nel modo o nell’ampiezza considerati normali per un essere umano.

Per i disabili, quindi, possono risultare difficili o impossibili anche operazionirelativamente semplici; riferendoci a un ambiente domestico, per esempio, potrebberisultare difficoltoso anche il gesto di premere un interruttore per accendere una lucedi una stanza, a causa dell’impossibilità di raggiungere la posizione del pulsante oper l’assenza della forza necessaria a premerlo. In questo contesto, si possono inserirei concetti di controllo dell’ambiente domestico e di usabilità.

Il controllo dell’ambiente domestico è il controllo, l’interazione e il monitoraggiodi un ambiente attraverso una tecnologia intermediaria, come un computer; ci siriferisce a esso anche con il termine domotica. Per un disabile, un sistema di controlloambientale potrebbe essere l’unico modo per interagire con la sua casa, mantenendocosì la propria indipendenza. Lo scopo di un sistema domotico, allora, è quello diridurre il carico di lavoro giornaliero dell’occupante di una casa e permettergli divivere il più possibile autonomamente.

È stato detto che la domotica necessita di una tecnologia, come un computer,che si ponga tra i dispositivi veri e propri della casa e il suo occupante.

Il computer, a sua volta, può avere diverse modalità di interazione verso l’uten-te, come mouse e tastiera, per citare le più comuni. Non tutti questi dispositivi diinput, però, possono essere utilizzati con facilità da una persona disabile. Bisogna,quindi, valutare una modalità di interazione differente ed, eventualmente, modifi-care o riscrivere del tutto l’interfaccia utente che, in questo caso, è il componente

1

Page 7: Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale

1 – Introduzione

utilizzato dall’utente per interagire con la sua casa attraverso il computer.Qui entra in gioco il concetto di usabilità, definita dall’ISO (International Orga-

nisation for Standardisation), come l’efficacia, l’efficienza e la soddisfazione con lequali determinati utenti raggiungono determinati obiettivi in determinati contesti.In pratica essa definisce il grado di facilità e soddisfazione con cui l’interazione traun essere umano e una macchina si compie.

Riferendosi in particolare a questa interfaccia utente, l’usabilità può essere defi-nita come lo strumento che indica quanto le funzionalità dell’interfaccia si adattinoai bisogni e alle aspettative, fisiche e mentali, dell’utente disabile che, tramite essa,vuole controllare la propria abitazione.

Quindi l’apprendimento delle varie funzionalità dell’interfaccia e il loro successivoutilizzo dovrebbe essere un processo estremamente semplice e intuitivo, così che essapossa davvero essere adatta al modello mentale e alle differenti esigenze di ogniutente che la voglia usare.

1.2 Gaze tracking, interfacce utente e domotica

Nel paragrafo precedente si affermava la necessità di valutare modalità di interazionetra l’utente e il computer differenti dai classici mouse e tastiera.

Ci possono essere diverse alternative, ognuna che presenta dei vantaggi e deglisvantaggi: per questo progetto è stato scelto il gaze tracking (chiamato anche, initaliano, tracciamento del punto fissato), che è una tecnica utilizzata per poter con-trollare il computer tramite la stima del punto osservato sullo schermo dall’utente.In questo caso specifico esso si basa sul tracciamento degli occhi, prendendo così ilnome di eye-tracking.

L’eye-tracking, o tracciamento oculare, è una tecnica utilizzata in molti cam-pi, tra cui le scienze cognitive, la psicologia, l’informatica e l’interazione uomo-computer, per registrare i movimenti degli occhi. In particolare, vengono misurate eanalizzate la posizione degli occhi e il loro movimento relativo alla testa, utilizzan-do svariati metodi: alcuni prevedono l’utilizzo di immagini video dalle quali vieneestratta la posizione dell’occhio mediante tecniche di computer vision; altri utilizzanola tecnica del riflesso corneale, che consiste nell’inviare un piccolo fascio luminosoinfrarosso al centro della pupilla e dedurre dalle variazioni del riflesso ottenuto imovimenti effettuati dall’occhio, solo per citarne un paio.

Gli strumenti che permettono di eseguire queste misurazioni si chiamano eye-tracker e si possono distinguere in due categorie:

• sistemi a postazione fissa, che sono cioè posizionati su un supporto di qualchetipo, distante dall’utente;

2

Page 8: Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale

1 – Introduzione

• sistemi indossabili, quindi a diretto contatto con l’utente, in genere sottoformadi visori da utilizzare come fossero degli occhiali.

Figura 1.1: Un esempio di eye-tracker commerciale: MyTobii P10

A titolo di esempio, si considerino gli eye-tracker a postazione fissa, come quellomostrato in figura 1.1. Questi eye-tracker, generalmente, sono personal computer atutti gli effetti, che integrano anche un paio di emettitori a raggi infrarossi e unatelecamera ad alta definizione, sensibile agli infrarossi: il sistema utilizza la tecnicadel riflesso corneale per stabilire il punto dello schermo osservato.

Non tutto il sistema funziona, però, grazie all’eye-tracking: ne usufruiscono soloalcune applicazioni, in genere pre-installate all’interno della macchina. Il sistemaoperativo, che nell’eye-tracker mostrato in figura è Windows XP, a titolo di esem-pio, e nativamente funziona grazie al mouse e alla tastiera; questo accade poichél’interazione basata su eye-tracking necessita che le interfacce utente dei programmiche la vogliano utilizzare abbiano alcune caratteristiche particolari, dettate dallanatura stessa di questo tipo di interazione.

È possibile utilizzare Windows anche con l’eye-tracker, ma è necessario utilizzareun apposito programma che permetta di provare a compiere tutte le operazioni chenormalmente si effettuerebbero con l’ausilio del mouse e che, in alcune occasioni,permetta anche di ingrandire certi oggetti che risultano troppo piccoli per essereselezionati col tracciamento dello sguardo.

3

Page 9: Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale

1 – Introduzione

In generale, infatti, non è possibile utilizzare l’eye-tracking come sostituto com-pleto del mouse: ciò non è fattibile per il modo in cui agiscono i nostri occhi e perla scarsa affidabilità dei sistemi di eye-tracking esistenti.

In particolare, l’eye-tracking:

è veloce e semplice poiché gli occhi si possono muovere molto più velocemente diqualsiasi altro dispositivo;

rivela il punto di attenzione poiché basta calcolare il punto in cui l’utente staguardando per capire dov’è diretta la sua attenzione;

risente del tocco di Mida poiché lo sguardo non fornisce l’equivalente dei pul-santi di un mouse, non è possibile sapere se l’utente sta guardando un puntointenzionalmente oppure se sta solo spostando lo sguardo lungo lo schermo;bisogna pertanto utilizzare altri metodi di selezione, come il dwell time, checonsiste in un tempo di pausa, generalmente personalizzabile, durante il qualel’utente dovrà fissare l’oggetto dell’interfaccia con cui vuole interagire e poi,trascorso quel tempo, il sistema effettuerà l’azione collegata all’oggetto chel’utente stava fissando;

è sempre on poiché l’input fornito dallo sguardo è sempre continuo, fintanto chesi rimane davanti al monitor;

non è invasivo poiché il punto osservato viene rilevato senza bisogno di alcun tipodi contatto fisico; anche per questo l’eye-tracking è una buona scelta per idisabili che, magari, non possono utilizzare le mani;

richiede calibrazione poiché un sistema di eye-tracking, per essere usato con suc-cesso e al massimo delle sue possibilità, richiede di individuare correttamentela posizione degli occhi e il loro movimento durante una fase di test preliminareguidata.

La figura 1.2 mostra una semplice interfaccia grafica realizzata per un programmadi video-scrittura da eseguirsi tramite eye-tracking. Com’è possibile vedere, essadifferisce molto dalle tipiche interfacce utente utilizzate, anche solo da quella diWindows, che si intravede sul fondo dell’immagine.

Quest’interfaccia condivide con altre interfacce basate su eye-tracking certe ca-ratteristiche, alcune delle quali sono molto evidenti.

• La dimensione degli oggetti: sono molto grandi. Questo perché l’eye-trackingè, in linea generale, meno preciso di altri dispositivi di puntamento, come ilmouse, per esempio.

4

Page 10: Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale

1 – Introduzione

Figura 1.2: Un programma per la video-scrittura, basato su eye-tracking

• La semplicità e l’ordine dell’interfaccia: nella parte alta dello schermo si trovaun rettangolo di colore bianco che visualizza il testo man mano che lo si inse-risce, mentre nella parte bassa si trovano otto rettangoli equidistanziati l’unodall’altro che permettono la scrittura.

• La facilità di navigazione: è tutto lì. Opzioni più avanzate si possono trovare,probabilmente, selezionando l’elemento “Tools”.

• La divisione a livelli : si immagini, ad esempio, di voler scrivere la parola “ciao”.Il primo passo da compiere sarà quello di selezionare il primo quadrato, poichécontiene la prima lettera che serve. Una volta selezionato il primo quadrato,verranno visualizzati altri quadrati che conterranno un sottinsieme delle lettereselezionate. A questo punto, si potrà selezionare direttamente la lettera “c” osi dovrà selezionare un altro oggetto che, sempre per esempio, potrà contenerele lettere “cd”. E così via. Bisognerà, quindi, navigare per livelli: infatti,visualizzare tutte le lettere dell’alfabeto sullo schermo renderebbe i pulsantitroppo piccoli e si incorrerebbe in errori di scrittura molto frequentemente.

• La mancanza del puntatore: studi dimostrano che la presenza di un puntatoresempre presente sullo schermo potrebbe distrarre l’utente, introducendo cosìdegli errori. Pertanto, l’utente non sa dove sta guardando finché non guardaun oggetto che è selezionabile. A quel punto, infatti, entra in gioco il dwelltime e viene visualizzato un qualche tipo di feedback per indicare all’utentequanto tempo manca prima che l’oggetto sia effettivamente selezionato.

La scelta di utilizzare questo sistema di interazione nasce, inoltre, dal fatto che ilPolitecnico di Torino, dal 2004, è entrato a far parte di COGAIN (Communicationby Gaze Interaction), una rete di eccellenza per lo sviluppo e la ricerca di tecnologieper l’interazione fra utenti disabili e computer.

5

Page 11: Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale

1 – Introduzione

COGAIN è un consorzio finanziato dall’Unione Europea, costituito da ricercatori,imprese e associazioni di utenti, che ha come scopo il miglioramento della qualitàdella vita per le persone afflitte da disordini nel controllo motorio.

Da allora il Politecnico, con il gruppo di ricerca e-lite, lavora per realizzareun sistema domotico controllabile con eye-tracking e rispondente alle specifiche diquesto consorzio.

Sistema di controllo domotico che nasce soprattutto per risolvere il problema delbasso livello di standardizzazione delle soluzioni domotiche, problema introdotto dalfatto che sono presenti molti produttori e molti dispositivi domotici che funzionanocon protocolli diversi, ognuno dei quali incompatibile con l’altro. Manca, cioè, unasoluzione di alto livello che, da un lato, permetta a questi dispositivi di comunicaresenza problemi tra di loro e, dall’altro, consenta di avere un unico punto di accessoper tutte le tecniche di gaze control che si vogliono implementare.

Questo sistema di controllo ambientale esiste, è in continua evoluzione, è sta-to sviluppato proprio dal Politecnico di Torino e si chiama DOG (Domotic OSGiGateway).

1.3 Specifiche COGAIN

Tra i vari documenti realizzati da COGAIN, quattro sono quelli che, principalmente,riguardano la gaze interaction applicata a un ambiente domotico in generale (ea DOG, in particolare), analizzandone problematiche, caratteristiche e requisiti.Questi documenti prendono il nome di deliverable e sono indicati dalla lettera “D”seguita da un numero.

Il report D2.4, intitolato “A Survey of Existing ’de facto’ Standars and Systemsof Environmental Control ”, fornisce la definizione di controllo ambientale, presen-tandone il rapporto con la disabilità e analizzando differenti metodi di interazione,tra cui il gaze control. Presenta, inoltre, anche alcuni prodotti commerciali e nonche possono essere considerati standard de-facto, evidenziando gli aspetti positivi equelli negativi della loro adozione. Infine, propone la creazione di un sistema ad-hocper applicazioni domotiche basate su gaze tracking.

Il report D2.5, intitolato “Draft Standars for gaze based environmental control ”,presenta alcune architetture di sistemi di controllo domotico basati su eye-trackinge propone una propria architettura, chiamata appunto DOG, fornendo anche alcunicasi di studio esemplificativi per meglio comprendere il funzionamento di tale sistemada parte dell’utente disabile.

Inoltre, espone la differenza tra vista strutturale e vista funzionale per l’orga-nizzazione dell’interfaccia grafica: la prima mostra i dispositivi raggruppati come losono nella casa reale (cioè per stanze), mentre la seconda li raggruppa in base alla

6

Page 12: Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale

1 – Introduzione

loro funzione logica, a discapito della loro posizione effettiva. Trovare un equilibriotra queste due viste è essenziale.

Infine, elenca una serie di requisiti necessari e consigliati che un’interfaccia uten-te basata su eye-tracking per un ambiente domotico dovrebbe implementare e cheverranno riportati, dato il particolare interesse di questo elenco, nel capitolo succes-sivo.

Il report D3.1, intitolato “User requirements report with observations of difficul-ties users are experiencing”, presenta la necessità di porre l’utente finale al centrodegli obiettivi di COGAIN. Fornisce, inoltre, alcune informazioni su chi può utilizza-re la tecnologia di eye-tracking e chi, invece, non può, mettendo a confronto ciò chela letteratura specialistica dice e ciò che l’evidenza sperimentale dimostra. Infine,elenca qualche alternativa all’eye-tracking, indicando i vari aspetti positivi e nega-tivi e mostrando con quale percentuale di successo delle persone disabili possonoutilizzare un sistema di gaze interaction.

Per ultimo, il report D3.2, dal titolo “Report on features of the different sys-tems and development needs”, presenta alcune caratteristiche chiave dei sistemi dieye-tracking, sia per quanto riguarda la loro componente hardware che per quantoriguarda la componente software, analizzando diversi approcci e diverse possibiliscelte riguardanti l’interazione come, per esempio, la possibilità di utilizzare la vo-ce come strumento da affiancare all’eye-tracking o la scelta nell’utilizzo di alcunisimboli per rappresentare elementi nell’interfaccia piuttosto che altri.

1.4 Struttura della tesi

In questo primo capitolo, si è cercato di introdurre il contesto e fornire alcuni stru-menti base per comprendere il punto da cui è partita la realizzazione dell’interfacciautente basata su eye-tracking che è il prodotto finale di questo progetto.

Nei prossimi tre capitoli, la tesi è organizzata per presentare gli obiettivi e ap-profondire alcuni aspetti, seppur di background, necessari a comprendere appienoil come e il perché si è realizzata l’interfaccia utente; nei capitoli seguenti, inve-ce, si mostreranno le fasi di progettazione e di implementazione del progetto e sipresenteranno i risultati ottenuti.

In dettaglio:

• nel capitolo DUE “Obiettivi ”, si riprenderanno e si approfondiranno alcuniconcetti presentati in questo primo capitolo per focalizzare gli obiettivi chesi vogliono ottenere nello realizzare questa interfaccia utente, basata su eye-tracking, per applicazioni domotiche;

7

Page 13: Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale

1 – Introduzione

• nel capitolo TRE “Soluzioni tecniche adottate”, verrà descritto l’ambiente do-motico proposto da COGAIN e dal Politecnico di Torino, cioè DOG, analiz-zando brevemente l’ontologia che racchiude lo schema della casa e dei suoidispositivi.

Inoltre, si presenterà l’Eye Tracking Universal Driver, un driver universale,sempre proposto da COGAIN, che serve per utilizzare le tecniche di traccia-mento degli occhi necessarie per questa applicazione di controllo domotico.

• nel capitolo QUATTRO “Tecnologia utilizzata”, si illustrerà la recente tec-nologia Microsoft, inclusa nel Framework .NET 3.x, utilizzata per realizzarel’interfaccia grafica, dal nome di Windows Presentation Foundation, presen-tando la sua maggiore innovazione, XAML, ed elencando le differenze rispettoalla tecnologia Microsoft della generazione precedente.

• nel capitolo CINQUE “Progettazione e implementazione”, si presenterà l’archi-tettura generale del sistema di controllo ambientale, le scelte progettuali e lefunzionalità inserite nell’interfaccia utente realizzata e, talvolta, si scenderà neldettaglio specificando quali componenti principali delle Windows PresentationFoundation si sono utilizzati e perché si è fatta proprio quella scelta.

• nel capitolo SEI “Risultati ottenuti ”, si presenterà qualche risultato qualitativoe quantitativo derivato dall’utilizzo dell’interfaccia, soffermandosi in partico-lare ad analizzare quali delle specifiche COGAIN si sono rispettate e qualino.

• nel capitolo SETTE “Conclusione e sviluppi futuri ”, verranno elencati alcunisviluppi futuri che il progetto descritto in questa tesi potrà avere.

Infine, negli appendici, verrà illustrato il rapporto tra il software Microsoft Ex-pression Design, utilizzato per realizzare la maggior parte degli elementi graficidell’interfaccia grafica, e le immagini utilizzabili nel linguaggio XAML; seguirà unesempio del modello della casa utilizzato e uno di parte del codice prodotto.

8

Page 14: Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale

Capitolo 2

Obiettivi

L’obiettivo principale della tesi è lo studio, la progettazione e la realizzazione diun’interfaccia utente basata su dispositivi di eye-tracking per funzionalità di con-trollo domotico.Si consideri, a tal proposito, l’immagine seguente:

Figura 2.1: Vista, ad alto livello, del contesto in cui si colloca l’interfaccia utente darealizzare

Essa mostra un utente che interagisce con la propria casa (ambiente domotico)attraverso un eye-tracker. Per interagire con efficacia, però, necessita di un’inter-faccia utente che, da una parte, si possa collegare all’ambiente domotico e dall’altrasia utilizzabile con l’eye-tracking.

9

Page 15: Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale

2 – Obiettivi

Assumendo di non avere alcun tipo di problema nel collegare una qualsiasi inter-faccia utente al sistema di controllo domotico proposto da COGAIN nel deliverable2.5, cioè a DOG, si può notare che qualche problema sorge proprio nel trovare un’in-terfaccia utente che sia utilizzabile con un eye-tracker, che abbia un numero suffi-ciente di funzionalità e che risponda a quei principi di usabilità che si accennavanonel capitolo precedente.

Si considerino, come esempio, le seguenti interfacce utente commerciali (figura2.2):

(a) LC Technologies - Light and Appliances. (b) Domotica Labs - KonneXion.

Figura 2.2: Due interfacce utente per ambienti domotici

La prima fa parte di un software sviluppato da LC Technologies relativa al con-trollo di dispositivi domotici. Fornisce un controllo basilare di luci e altri dispositivipiù avanzati, ovunque essi siano presenti nella casa, permettendo semplicemente diaccenderli o spegnerli ed è utilizzabile tramite eye-tracking.

La seconda è un’interfaccia di un software per il controllo ambientale sviluppatoda Domotica Labs. Permette un’interazione più completa rispetto al programma diLC Technologies, è basata sul web ma non è utilizzabile con eye-tracking, soprattuttoper la presenza dei menù e a causa della ridotta dimensione dei pulsanti.

In particolare, le interfacce utente esistenti, non rispettano in pieno nessuna delleraccomandazioni proposte da COGAIN o da altri enti. Si riportano, nella tabella2.1, quelle più significative, evidenziando il comportamento delle due interfacce difigura 2.2 rispetto a esse.

È quindi necessario creare da zero un’interfaccia utente, che sia usabile, che sipossa collegare a DOG e sia pronta per l’eye-tracking. Interfaccia a cui, d’ora inpoi, ci si riferirà anche con il nome di DOGeye, visto che unisce DOG all’EYEinteraction.

10

Page 16: Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale

2 – Obiettivi

Raccomandazione LC Technologies Domotica Labs

Creare interfacce utente consistenti Sì NoCreare scelte standard di interfaccedifferenti, adattabili a piacere

No Possibile

Fornire funzionalità di sicurezza in casodi guasto del sistema

No Possibile

Convergenza di diversi modi operativi No PossibileUtilizzare un insieme di metodi di input,tra cui l’eye-tracking

Sì No

Possibilità di scegliere la lingua dautilizzare

Sì Possibile

Fornire una visualizzazione della po-sizione dei dispositivi all’interno dellacasa

No Sì

Usare colori, testo e icone per evidenzia-re un cambiamento di stato

No Parzialmente

Tabella 2.1: Rapporto tra raccomandazioni e interfacce utente per il controllodomotico esistenti

Per farlo, ci si pone un altro obiettivo, quello cioè di realizzare un’interfacciagrafica con le ultime tecnologie a disposizione, in modo che sia moderna per l’at-tuale stato dell’arte. Qui entra in gioco la tecnologia della Microsoft, introdotta apartire dal framework .NET 3.0, chiamata Windows Presentation Foundation e lasua componente più rilevante, XAML.

Con questa tecnologia, di cui si parlerà più approfonditamente nei prossimi ca-pitoli, si possono realizzare interfacce utenti in maniera semplice, potente, creandocodice estremamente leggibile e permettendo la separazione quasi totale della partedi design (cioè, come l’interfaccia appare) dalla parte di logica (quali sono i meccani-smi per far sì che svolga i suoi compiti). La parte di design, infatti, viene realizzatainteramente in XAML, un linguaggio derivato da XML, mentre la parte di logicaviene realizzato col cosiddetto code-behind che, essenzialmente, può essere un qual-siasi linguaggio appartenente alla piattaforma .NET. Per i propositi di questa tesi,si utilizzerà il linguaggio C#.

Inoltre, dovendo l’interfaccia rispettare le specifiche COGAIN, per realizzare l’in-terazione con l’eye-tracking si utilizzerà un driver universale, sempre proposto daCOGAIN, dal nome ETU-Driver, che permetterà di utilizzare l’interfaccia anche insimulazione (senza un eye-tracker vero e proprio, insomma) e che fornirà un’am-pia compatibilità con diversi modelli di eye-tracker, i cui driver sono generalmente

11

Page 17: Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale

2 – Obiettivi

incompatibili l’un l’altro.Il fatto di dover usare l’ETU-Driver è un altro motivo che ha influito notevol-

mente nella scelta di utilizzare la piattaforma .NET: il driver è composto da oggettidi tipo COM e quindi è possibile integrarlo in maniera semplice e veloce.

COGAIN, infine, ha pubblicato alcune linee guida che verranno utilizzate comerequisiti (riportati in tabella 2.2) per la realizzazione dell’interfaccia utente e perla sua valutazione. Questi requisiti sono divisi in quattro categorie e hanno comeobiettivo principale quello di promuovere la sicurezza e l’accessibilità:

1. sicurezza delle applicazioni di controllo;

2. metodi di input per l’applicazione di controllo;

3. caratteristiche operative delle applicazioni di controllo;

4. usabilità delle applicazioni di controllo.

Ogni linea guida ha un livello di priorità basato sul suo impatto sulla sicurezzae sull’accessibilità nei confronti dell’utente:

priorità 1 - un’applicazione di controllo domotico DEVE soddisfare questa lineaguida;

priorità 2 - un’applicazione di controllo domotico DOVREBBE soddisfare questalinea guida.

Ai fini di questo progetto, l’obiettivo è quello di soddisfare almeno i requisiti chehanno priorità 1.

Tabella 2.2: Linee guida COGAIN per la realizzazione di un’applicazione di controlloambientale

Linea guida Descrizione Priorità

1.1 Fornire un sistema di notifiche per gli allarmi veloce,facile da capire e multimodale.L’applicazione di controllo dovrebbe notificare un al-larme il prima possibile e in diversi modi, per esempiocon suoni, icone lampeggianti e messaggi di testo.

1

1.2 Fornire all’utente solo poche e chiare opzioni pergestire eventi di allarme.Molti eye-tracker sono poco accurati quando l’utenteè agitato, quindi in caso di allarme l’applicazione dicontrollo dovrebbe fornire solo un limitato ma chiaroinsieme di opzioni (al massimo tre).

2

Continua. . .12

Page 18: Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale

2 – Obiettivi

Linea guida Descrizione Priorità

1.3 Fornire un’azione di default per affrontare un eventodi allarme.In caso di emergenza, l’utente potrebbe perdere il con-trollo del dispositivo di input, quindi l’applicazione dicontrollo dovrebbe prendere la decisione più sicura do-po che è scattato un timeout. La lunghezza del timeoutè dipendete dal tipo di allarme.

1

1.4 Fornire una richiesta di conferma per le operazionicritiche e possibilmente dannose.Con un inaccurato o mal configurato eye-tracker, l’er-rore del tocco di Mida può essere frequente, cioè ognioggetto o comando guardato dall’utente è selezionato oeseguito, quindi l’applicazione di controllo dovrebbe ri-chiedere una conferma per le operazioni che potrebberoessere dannose.

1

1.5 Fornire una funzionalità di STOP che interrompa ognioperazione.In alcune occasioni, il sistema domotico può esegui-re azioni che l’utente non vuole, per esempio per viadi una selezione di un comando errato o l’esecuzio-ne di uno scenario pre-impostato. L’applicazione dicontrollo dovrebbe permettere un metodo di stop perinterrompere ogni operazione.

1

2.1 Fornire una connessione con il COGAIN ETU-Driver.Il COGAIN ETU-Driver è uno standard di comunica-zione per la gaze interaction che permette ad appli-cazioni di terze parti di essere comandate da un ran-ge di diversi sistemi harware di eye-tracker. Usandoquesto driver, non c’è bisogno di cambiare o ricom-pilare nessuna applicazione nel caso in cui si cambieye-tracker.

1

2.2 Supportare differenti metodi di input.L’eye-tracker, sfortunatamente, potrebbe rompersi,quindi l’applicazione di controllo dovrebbe supportareanche altri metodi di input, come la tastiera, il mouse,ecc.

2

Continua. . .

13

Page 19: Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale

2 – Obiettivi

Linea guida Descrizione Priorità

2.3 Fornire un layout riconfigurabile, appropriato perdiverse performance dell’eye-tracking e per diverseesigenze degli utenti.Gli eye-tracker hanno un range di performance mol-to ampio; quindi un’applicazione di controllo dovrebbeavere un’interfaccia grafica riconfigurabile in base allediverse risoluzioni e precisioni degli eye-tracker.

2

2.4 Supportare più metodi di input allo stesso tempo(interazione multimodale).L’utente potrebbe essere capace di usare canali di inputalternativi all’eye-tracking, come la voce o i movimen-ti delle dita, per esempio. L’applicazione di control-lo dovrebbe supportare la combinazione di più meto-di di input contemporaneamente, come ad esempio laselezione con l’occhio e il click con il mouse.

2

2.5 Gestire la perdita del controllo dell’input fornendoazioni di default automatiche.L’applicazione di controllo dovrebbe capire quando l’u-tente ha perso il controllo dell’eye-tracker e dovreb-be eseguire azioni di default (come effettuare unaricalibrazione o far suonare un allarme).

2

3.1 Rispondere agli eventi e ai comandi dell’ambientedomotico nel giusto tempo.L’applicazione di controllo dovrebbe essere reattiva:dovrebbe gestire gli eventi e i comandi con un ritardoaccettabile.

1

3.2 Gestire eventi con diversa priorità temporale.L’applicazione di controllo dovrebbe distinguere traeventi con priorità differente. Gli eventi temporalmen-te critici devono essere eseguiti con un breve perio-do di attesa (per esempio, l’allarme antincendio o ilrilevamento di un’intrusione).

1

Continua. . .

14

Page 20: Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale

2 – Obiettivi

Linea guida Descrizione Priorità

3.3 Eseguire comandi con diversa priorità.I sistemi domotici ricevono più comandi contempora-neamente, a causa di diversi utenti o degli scenari,per esempio. L’applicazione di controllo dovrebbe di-scriminare comandi con priorità differente e dovrebbeadottare un comportamento prestabilito.

1

3.4 Fornire un feedback quando vengono eseguite operazio-ni e comandi automatici.Gli scenari, selezionati dall’utente, potrebbero inclu-dere molti comandi da eseguire. L’applicazione dicontrollo dovrebbe mostrare l’azione in progresso einformare l’utente quando uno scenario è terminato.

2

3.5 Gestire (creare, modificare, cancellare) scenari.Ripetere una lunga sequenza di comandi per eseguireun compito frequente potrebbe essere noioso per l’uten-te. E’ necessario raccoglierli in una lista di comandi egestirli come se fossero uno solo. L’applicazione di con-trollo dovrebbe permettere la creazione, la modifica ela cancellazione di questi scenari.

2

3.6 Conoscere lo stato corrente di ogni dispositivo.L’applicazione di controllo dovrebbe conoscere lo sta-to corrente di ogni dispositivo della casa, per mostrarequesta informazione e per prendere decisioni automati-che intelligenti (per esempio, prevenire una condizionedannosa o attivare un piano di risparmio energetico).

2

4.1 Fornire una chiara visualizzazione di ciò che accadenella casa.L’interfaccia dell’applicazione di controllo dovrebbefornire una visualizzazione chiara e facile da capire delprogresso dell’esecuzione del comando.

1

4.2 Fornire un’interfaccia elegante e chiara.Un layout consistente, con un linguaggio facile da capi-re e una grafica riconoscibile, avvantaggia ogni utente.L’applicazione di controllo dovrebbe fornire un’inter-faccia elegante e chiara, possibilmente utilizzando siaimmagini che testo.

2

Continua. . .

15

Page 21: Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale

2 – Obiettivi

Linea guida Descrizione Priorità

4.3 Fornire una visualizzazione dello stato e della posizionedei dispositivi della casa.L’applicazione di controllo dovrebbe mostrare la map-pa della casa contenente, per ogni stanza, unarappresentazione dei dispositivi e il loro stato.

2

4.4 Usare colori, icone e testo per evidenziare uncambiamento di stato.L’interfaccia dell’applicazione di controllo dovrebbeevidenziare un cambiamento di stato di un dispositivoutilizzando immagini, testo e suoni.

2

4.5 Fornire un metodo di selezione facile da imparare.Anche se l’applicazione di controllo potrebbe presen-tare caratteristiche e funzionalità complesse, dovrebbepure fornire un metodo di interazione usabile e facileda imparare.

2

16

Page 22: Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale

Capitolo 3

Soluzioni tecniche adottate

3.1 Introduzione

Prima di parlare del progetto dell’interfaccia utente realizzata è doveroso dedicareun po’ di tempo per presentare sufficientemente nel dettaglio le soluzioni tecnichecon cui l’applicativo deve interagire.

In particolare, nei capitoli precedenti, si è parlato di un sistema di controllodell’ambiente domotico chiamato DOG e di un driver universale per l’eye-trackingchiamato ETU-Driver. Entrambi questi componenti, proposti o consigliati da CO-GAIN, hanno un ruolo essenziale per il progetto trattato in questa dissertazione edentrambi sono strettamente correlati con l’interfaccia utente, nel modo rappresentatonella figura 3.1:

Figura 3.1: Come l’interfaccia utente è connessa a DOG e all’eye-tracker

17

Page 23: Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale

3 – Soluzioni tecniche adottate

Nei paragrafi seguenti, si tratteranno in maniera più dettagliata le caratteristichedell’ambiente domotico e dell’ETU-Driver, procedendo quindi a un “ingrandimento”di alcune parti della figura 3.1.

3.2 Ambiente domoticoIl termine domotica (o Smart Home) è un neologismo derivante dalla parola latinadomus (che, appunto, significa casa) e la parola informatica.

La domotica, quindi, è la disciplina che si occupa di studiare tecnologie informa-tiche e appartenenti all’area dell’automazione per poterle utilizzarle negli ambientidomestici, al fine di migliorarne il comfort, l’abitabilità e di semplificare la vita dellepersone mentre vivono in questi ambienti.

Figura 3.2: Un esempio di architettura logica di ambiente domotico

La domotica si può intendere in differenti modi: da una parte, essa si occupadi automatizzare semplici funzioni della casa come, per esempio, l’accensione e lospegnimento delle luci; dall’altra cerca di sviluppare servizi più “intelligenti” come,

18

Page 24: Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale

3 – Soluzioni tecniche adottate

per esempio, gli scenari, cioè un elenco di attività riguardanti determinati dispositividomestici che possono venire attivati o disattivati tutti insieme in un certo momentodella giornata, a scelta dell’utilizzatore.

Un ambiente domotico, pertanto, è un ambiente opportunamente progettato etecnologicamente attrezzato, in cui sono presenti impianti e dispositivi che sfruttanotecnologie che li rendono controllabili da remoto ed eventualmente anche in gradodi comunicare tra di loro.Anche se il termine “da remoto” può dare l’idea che la casa venga controllata da unaltro posto, al di fuori dell’abitazione, in questo contesto si intende semplicementeche un oggetto o una funzionalità della casa può essere controllata senza il bisognodi maneggiare o toccare fisicamente l’oggetto in questione. Quindi, l’oggetto puòanche trovarsi di fronte all’utente ma esso lo controlla in remoto grazie a un sistemadi eye-tracking o attraverso lo schermo di un computer.

Inoltre, un ambiente domotico come quello mostrato in figura 3.2 è composto dauna serie di componenti hardware e software.

Le componenti hardware sono gli impianti domotici, che comprendono alcunidispositivi e un gateway, che gestisce la comunicazione con ogni dispositivo appar-tenente al proprio impianto e con l’House Manager. I gateway dei vari impiantidomotici, a loro volta, sono collegati con un Domotic House Gateway che gestiscela rete di comunicazione tra i diversi gateway.

La componente software, invece, è il cuore del sistema domotico perché ha ilcompito di gestire i dispositivi della casa, non importa in quale impianto essi sitrovino: tale componente prende il nome di House Manager.

L’House Manager si occupa anche di fornire servizi intelligenti e alcune appli-cazioni che permettano all’utente di interagire con la casa. L’House Manager, nelcontesto che stiamo considerando, altro non è che DOG, proposto da COGAIN esviluppato dal gruppo di ricerca del Politecnico e-lite.

3.2.1 DOG

DOG (Domotic OSGi Gateway) è una piattaforma che permette l’interfacciamento,la gestione e l’integrazione di dispositivi domotici di diversi costruttori in un singolosistema software.

Realizzato con tecnologia OSGi, fornisce un ambiente per gli sviluppatori orien-tato ai servizi e basato su componenti, offrendo così modi standardizzati di gestireil ciclo di vita del software stesso. Fornisce un framework Java stabile, sicuro egeneral-purpose che supporta lo sviluppo di applicazioni di servizio estensibili chia-mate bundle o, in italiano, moduli, che sono facili da integrare: basta, infatti, chesiano conformi ai vincoli di comunicazione definiti nel framework stesso.

19

Page 25: Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale

3 – Soluzioni tecniche adottate

Figura 3.3: L’architettura logica di DOG

Come illustrato nella figura 3.3, DOG è composto da differenti moduli, che hannoi vari usi e ruoli descritti di seguito:

• Network Drivers permette l’interazione diretta con le componenti hardwaredell’ambiente domotico. È necessario un driver differente per ogni protocollodi basso livello utilizzato dalle varie componenti.Attualmente è formato da tre bundle: ND Konnex per i sistemi KNX, NDBTicino per i sistemi MyHome BTicino e ND Emulator che permette di emu-lare i dispositivi fisicamente non disponibili, consentendo così di utilizzare ilsoftware anche in assenza di un ambiente domotico reale, cioè in simulazione;

• Message Dispatcher effettua il routing degli eventi in arrivo dai Network Dri-vers e i comandi in arrivo dall’Executor; contiene, quindi, una tabella di rou-ting per mappare la corrispondenza tra i dispositivi e i Network Drivers chepossono comandarli;

• Executor riceve i comandi dal modulo API, ne controlla la correttezza intera-gendo con il modulo Status e li esegue inviando i nuovi comandi al CommandDispatcher;

• House Model contiene la rappresentazione della casa e dei dispositivi apparte-nenti all’ontologia DogOnt, descritta nel prossimo sotto-paragrafo;

20

Page 26: Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale

3 – Soluzioni tecniche adottate

• Status è una sorta di cache che contiene lo status dei dispositivi presen-ti nel sistema; risponde alle richieste mandate dal modulo API, restituendoinformazioni sui vari dispositivi;

• Platform Manager gestisce l’installazione, l’avvio e la sospensione dei bundleall’interno della piattaforma OSGi, fornisce informazioni sullo stato dei bundlee gestisce la sequenza di bootstrap di sistema;

• Configurator Registry fornisce i dati di configurazione necessari al funziona-mento dei singoli moduli;

• API è il punto di accesso esterno al sistema; fornisce una serie di servizi comel’elenco dei dispositivi presenti nella casa, la possibilità di eseguire comandi equella di registrarsi come listener per ricevere determinati eventi e conoscerelo stato di uno o più dispositivi;

• XmlRpcConnector espone i servizi offerti dal modello API sottoforma di end-point XML-RPC: l’interfaccia utente utilizzerà questo modulo e il protocolloXML-RPC per interagire con DOG;

• DogLibrary, infine, specifica le interfacce dei servizi offerti dai bundle, definen-do e implementando le classi di sistema e le eccezioni.

L’interfaccia utente comunicherà con DOG principalmente durante due fasi, quel-la iniziale in cui l’interfaccia riceverà il modello della casa con tutti i suoi dispositivi,insieme con il loro stato e la loro descrizione; e quella operativa in cui l’interfacciacomunicherà a DOG i comandi che vuole compiere (per esempio, accendere una lu-ce) e DOG risponderà restituendo l’esito dell’operazione che gli è stata richiesta (“laluce si è accesa”).

Sempre nella fase operativa, DOG potrebbe comunicare all’interfaccia che il ve-rificarsi di un evento (qualcuno ha premuto un pulsante e la luce si è accesa) el’interfaccia tratterà questa informazione di conseguenza, generalmente producendouna notifica destinata all’utente.

La fase operativa, come è facile intuire, è una fase che viene ripetuta diversevolte, fintanto che DOG e l’interfaccia sono entrambi in funzione e qualcosa capitaall’interno dell’ambiente domotico.

3.2.2 DogOnt

DogOnt è il modello formale per la rappresentazione di un ambiente domotico,composto da due elementi: un’ontologia e un insieme di regole.

21

Page 27: Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale

3 – Soluzioni tecniche adottate

Una ontologia è una rappresentazione formale di una interpretazione condivisa diuno specifico dominio di conoscenza. Non esistendo l’ontologia perfetta, la rappre-sentazione di un determinato dominio può essere formalizzata in una moltitudine dimodi e dipende dallo scopo per cui viene creata. Un’ontologia assume normalmenteuna struttura a grafo connesso con concetti e relazioni che li collegano.

Le componenti fondamentali di una ontologia sono:

Classi - insiemi, collezioni o tipi di oggetti;

Attributi - proprietà, caratteristiche o parametri che gli oggetti possono avere econdividere;

Relazioni - modi in cui gli oggetti possono essere messi in relazione gli uni con glialtri;

Individui - istanze del modello, che sono gli elementi di base.

Le classi di un’ontologia sono concetti astratti che esprimono una classificazionedelle entità rilevanti del dominio.

L’ontologia ha generalmente una classe radice chiamata Thing da cui discendonotutte le altre. Le classi nell’ontologia seguono il principio dell’ereditarietà padre-figlioa livello di classe e proprietà.

Analizzando la figura 3.4, si può notare che l’ontologia di DogOnt si sviluppalungo cinque rami principali:

• Building Thing : rappresenta gli oggetti disponibili (controllabili, come unaluce, oppure no);

• Building Environment : rappresenta dove gli oggetti sono collocati;

• State: rappresenta le configurazioni stabili (gli stati, come “acceso” o “spento”)che gli oggetti controllabili possono assumere;

• Functionality : rappresenta cosa gli oggetti controllabili possono fare (accender-si e spegnersi, sempre per esempio); la maggior parte degli oggetti istanziabilinon ha funzionalità comandabili con più di tre comandi.

• Domotic Network Component : rappresenta delle caratteristiche peculiari diogni impianto domotico.

Ogni ramo, a sua volta, avrà un certo numero di altri rami figli, a seconda di cosadeve rappresentare: “Building Thing”, che è uno dei rami dell’ontologia più interes-santi poiché contiene tutti i dispositivi, gli elementi di mobilio e quelli architetturali

22

Page 28: Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale

3 – Soluzioni tecniche adottate

Figura 3.4: L’ontologia DogOnt

che ci possono essere nella casa, si divide in Controllable e Uncontrollable, per sepa-rare gli oggetti che sono controllabili da quelli che, come il tavolo del soggiorno, nonlo sono.

DogOnt, inoltre, rappresenta ogni dispositivo come un oggetto che possiede uninsieme di funzionalità e di stati.

Le funzionalità sono automaticamente aggiunte a ogni istanza del dispositivo,in base alle restrizioni definite al livello di classe. Esse sono condivise da tutti idispositivi della stessa classe: pertanto, diversi tipi di lampade appartenenti allastessa classe potranno avere delle funzionalità in comune. D’altra parte, invece, glistati sono peculiari a ogni dispositivo.

Quindi, se si volesse ottenere un modello della casa personalizzato e “virtuale”,per esempio per eseguire alcune simulazioni, basterebbe creare una istanza per ognicamera che si vuole avere nella casa (le stanze si trovano nel ramo “Building En-vironment”); dopodiché basterebbe creare le istanze dei dispositivi che si vogliono

23

Page 29: Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale

3 – Soluzioni tecniche adottate

avere nelle singole stanze, come luci, interruttori o elettrodomestici (si trovano tut-ti in “Building Thing” > “Controllable” > “White Goods”) e assegnargli i tipi difunzionalità e i tipi di stato che sono previsti nelle loro classi.

L’assegnazione dei singoli stati e delle singole funzionalità per ogni dispositi-vo istanziato nell’ontologia viene fatto in maniera automatica proprio grazie alragionamento basato su regole offerto da DogOnt.

Le regole di DogOnt, pertanto, facilitano il processo di modellazione generan-do automaticamente gli stati adeguati e le funzionalità dei dispositivi domotici, eassociandoli al corretto dispositivo attraverso relazioni di tipo semantico.

Fornendo alcune modalità di ragionamento, inoltre, DogOnt è in grado di fornirela posizione di un dispositivo domotico nella casa, elencare l’insieme delle sue carat-teristiche, fornire le caratteristiche tecnologie necessarie per interfacciarsi con queldispositivo, dire come è composto l’ambiente domestico e presentare gli elementiarchitetturali e di mobilio che sono presenti nella casa.

Ci sarebbe ancora molto da dire riguardo questo argomento ma, per gli obiettividi questa tesi non è necessario sapere altro: l’interfaccia utente si collega diretta-mente con DOG che gli fornisce il modello della casa con tutti i suoi dispositivi e nonha bisogno di modificare né l’ontologia né le regole di DogOnt. È sufficiente saperecos’è un’ontologia, che i vari dispositivi hanno delle funzionalità e degli stati e cheDOG prende da qui il modello della casa, senza il quale nulla potrebbe funzionare.

3.3 Eye Tracking Universal Driver (ETU-Driver)

Il driver universale di COGAIN Eye Tracking Universal Driver (ETU-Driver), uti-lizzato in questo progetto, è stato sviluppato da Oleg Špakov e si presenta comeun livello che si pone fra il driver vero e proprio di alcuni modelli di eye-tracker ele applicazioni di terze parti, al fine di permettere il loro utilizzo su eye-tracker diproduttori differenti.

Figura 3.5: Parte dell’architettura dell’ETU-Driver

24

Page 30: Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale

3 – Soluzioni tecniche adottate

Il driver, la cui architettura è rappresentata nella figura 3.5, è costituito da unaserie di oggetti COM che implementano un’unica interfaccia per alcuni eye-trackersupportati e da un set di librerie (chiamate API-Converters), che convertono le APIoriginali dei vari produttori in una API comune utilizzata, appunto, da questo driveruniversale.

Attualmente, il driver universale contiene gli API-Converters dei seguenti eye-tracker:

• ITU GazeTracker;

• LC EyeGaze;

• SR EyeLink I/II;

• SMI iViewX v1.2x e v2.0;

• Tobii Technologies 1750, P10, D10, T60, T120 e X120.

Inoltre, sono disponibili tre API-Converters di simulazione che possono essereutilizzati per scopi di debug, per eseguire applicativi di dimostrazione o per mostrareil comportamento di un’interazione basata su eye-tracking in assenza di un eye-tracker vero e proprio.

Questi tre convertitori sono:

• Mouse, utilizza la posizione del puntatore del mouse sullo schermo come puntoosservato in quell’istante. Questa API contiene un algoritmo di fixation de-tection, i cui parametri sono completamente configurabili tramite le opzionidell’ETU-Driver.

• Gaze-data file, legge e interpreta un file contenente i dati sullo sguardo registra-to precedentemente dal driver universale utilizzando un altro API-Converter,mostrandoli sullo schermo.

• Simulator, genera scan-path casuali, cioè memorizza su file dei dati casuali,generati come se appartenessero allo sguardo di un utente “virtuale”.

Il driver universale dispone anche di alcuni filtri che sono in gradi di modificare,bloccare o generare dati relativi allo sguardo prima che questi vengano inviati alleapplicazioni utente.

Tali filtri sono:

EyeMouse - questo filtro collega sguardo e mouse, ovvero il puntatore si muoveseguendo con il punto osservato.

25

Page 31: Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale

3 – Soluzioni tecniche adottate

ThinOut - questo filtro accetta solo un campione ogni N, con N impostabile apiacere.

FixationDetector - questo filtro utilizza lo strumento di fixation detection svilup-pato da Oleg Špakov, che permette di rilevare quando l’utente fissa lo sguardoin un punto, tramite opportuni algoritmi.

Il vantaggio di utilizzare un driver universale consiste nel fatto che una qualsiasiapplicazione implementata con questo driver può interfacciarsi con un nuovo eye-tracker semplicemente utilizzando l’opportuno API-Converter.

Senza l’ausilio dell’ETU-Driver, ogni volta che un’applicazione dovesse essereeseguita su un nuovo modello di eye-tracker, bisognerebbe ricompilarla con i driverdel nuovo dispositivo di eye-tracking: bisognerebbe, cioè, realizzare una versione delprogramma per ogni eye-tracker su cui lo si volesse utilizzare.

26

Page 32: Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale

Capitolo 4

Tecnologia utilizzata

Esistono diverse tecnologie e diversi linguaggi adatti a realizzare un’interfaccia uten-te. All’interno della piattaforma .NET, utilizzata per questo progetto, ne esisto-no principalmente due: Windows Forms e le più moderne Windows PresentationFoundation.

In questo capitolo, si presenteranno le caratteristiche peculiari proprio di Windo-ws Presentation Foundation, soffermandosi in maniera particolare ad analizzare quel-la che potrebbe essere considerata la sua componente principale, cioè il linguaggioXAML, ed evidenziando le differenze con la tecnologia Microsoft della generazioneprecedente.

4.1 Windows Presentation Foundation

Il cinema hollywoodiano ci ha, da sempre, abituati a vedere personaggi che appaionopiù attraenti, più reattivi e più determinati della maggior parte delle persone che siincontrano nella vita di tutti i giorni.

La stessa cosa potrebbe essere detta anche riguardo al software che questi perso-naggi utilizzano, soprattutto nei film, non di fantascienza, realizzati negli anni ’90:mi vengono in mente client di posta elettronica che mostrano scritte tridimensio-nali, che avvisano della ricezione di nuove e-mail visualizzando delle animazioni eriproducendo la frase “You’ve got mail! ”, e così via.

In confronto ai client di posta elettronica “reali”, esistenti quando quei film ve-nivano realizzati, quelli erano molto più belli e, per certi versi, “irresistibili”, ancheconsiderando alcuni aspetti legati all’usabilità.

Solo in questi ultimi anni, si è visto un avvicinamento tra gli standard del softwarereale e quelli del software presentato nei film: è sufficiente pensare agli effetti di MacOS X, a quelli di Compix su Linux, a quelli introdotti da Windows Vista in poi o,

27

Page 33: Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale

4 – Tecnologia utilizzata

sul web, a quelli di Adobe Flash, senza dimenticare quelli che verranno introdottida HTML 5, solo per fare qualche esempio.

Gli utenti, stimolati forse anche dai film che vedono, hanno aspettative semprecrescenti sulla cosidetta software experience e quindi si aspettano di poter utilizza-re dei programmi che abbiano le funzionalità che necessitano ma che siano ancheintuitivi, stabili e, perché no, eleganti e chiari.

A questo punto entra in gioco Microsoft con una soluzione che può aiutare glisviluppatori a creare “software del ventunesimo secolo” (Adam Nathan, 2006), sen-za sprecare troppo tempo e troppe risorse: questa soluzione è, appunto, WindowsPresentation Foundation (WPF), introdotta a partire dal framework .NET versione3.0.

Figura 4.1: Le tecnologie incluse nel framework .NET

La maggior parte delle interfacce utente utilizzate oggigiorno in Windows sonorealizzate usando il sottosistema grafico che prende il nome di GDI+, la versioneavanzata di Graphics Device Interface (GDI), che fornisce gli strumenti base per leinterfacce che vogliano utilizzare la grafica 2D ma che presenta alcune limitazioni,dovute soprattutto al fatto che tale sottosistema è nato nel 1985, un tempo davveromolto lontano, tecnologicamente parlando.

28

Page 34: Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale

4 – Tecnologia utilizzata

Tali limitazioni sono state superate da WPF, di cui si riportano alcune tra le suecaratteristiche più importanti:

• ampia integrazione - Prima di WPF, uno sviluppatore che volesse usarecomponenti 3D, video o vocali in aggiunta alla normale grafica bidimensiona-le e agli usuali controlli, doveva utilizzare tecnologie indipendenti dalle GDIche avevano un gran numero di inconsistenze e davano alcuni problemi dicompatibilità.

WPF copre tutte queste aree (e anche altre, come la gestione e la vista avan-zata di documenti testuali) con un modello di programmazione consistente euna buona integrazione tra i diversi tipi di oggetti. Inoltre, buona parte del-le tecniche che si possono utilizzare in una determinata area possono essereutilizzate direttamente anche in altre.

• indipendenza dalla risoluzione - Un’interfaccia sviluppata prima di WPFè, generalmente, dipendente dalla risoluzione del monitor su cui viene visua-lizzata. Se, per esempio, essa veniva sviluppata per un Ultra-Mobile PC (che,tipicamente, ha un monitor da quattro a sette pollici e una risoluzione ade-guata) e poi veniva utilizzata su un computer con uno schermo da 20” (conuna risoluzione più elevata, ovviamente), i vari elementi grafici dell’interfacciautente apparivano “sgranati” oppure piccolissimi. E viceversa.

WPF offre, invece, la possibilità di ridurre e allargare gli elementi sullo schermoin maniera indipendente dalla risoluzione. Molte di queste possibilità sonoofferte grazie all’orientamento di WPF verso la grafica vettoriale: ingrandendoun elemento di un’interfaccia realizzata con WPF, esso rimane pulito e visibilesenza alcun tipo di sgranatura o imprecisione.

• accelerazione hardware - Anche se WPF è una nuova tecnologia, essa ècostruita sopra Direct3D, appartenente alle DirectX. Questo significa che ilcontenuto di un’applicazione WPF, sia esso 2D o 3D, grafico o testuale, vieneconvertito in triangoli 3D, texture e altri oggetti Direct3D e poi renderizzatovia hardware. Questo è sempre più vero per sempre più contenuti man manoche il framework .NET evolve da una versione all’altra. Quindi, le applicazioniWPF sfruttano i benefici dell’accelerazione video per avere una grafica piùliscia, più morbida e, di conseguenza, miglior performance, utilizzando per glielementi grafici la GPU della scheda video invece che la CPU. Inoltre, questoassicura che le applicazioni WPF possano ricevere il massimo beneficio dainuovi hardware e driver.

Se, però, non fosse disponibile hardware grafico di alto livello, WPF offreanche una pipeline di rendering grafico via software. Questo, inoltre, permettedi sfruttare funzionalità che non sono ancora supportate dall’hardware attuale

29

Page 35: Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale

4 – Tecnologia utilizzata

e può anche essere utilizzato come un meccanismo di protezione (di fallback,a voler essere precisi) nel caso in cui un’applicazione venga eseguita su uncomputer con risorse hardware inadeguate per essa.

• programmazione dichiarativa - Prima di WPF i programmi che utilizza-vano la piattaforma .NET avevano la possibilità di includere diversi tipi diattributi, file di risorse e file di configurazione basati su linguaggi dichiarativi1come l’eXtensible Markup Language (XML).

WPF porta la programmazione dichiarativa per le interfacce grafiche a tutt’al-tro livello, introducendo l’eXtensible Application Markup Language (XAML).La combinazione di WPF con XAML fornisce una grande espressività che siestende anche oltre i confini della produzione di interfacce utente; WPF uti-lizza XAML anche come un formato per alcuni documenti, per rappresentaremodelli 3D, immagini e molto altro. Il risultato è che i designer grafici possonocosì contribuire direttamente al look-and-feel delle applicazioni, lasciando poiai programmatori la realizzazione della parte logica del programma.

• personalizzazione e composizione evoluta - I controlli WPF sono estre-mamente personalizzabili e componibili l’un l’altro: si può, per esempio, creareun bottone che abbia all’interno un video. Anche se alcune di queste persona-lizzazioni possono suonare terribili, il fatto importante è che esse siano possibilida realizzare senza scrivere tonnellate di codice, in maniera semplice e in pocherighe. Inoltre, è possibile dichiarare questi controlli personalizzati in un unicopunto del codice e poi riutilizzarli tutte le volte che si ha bisogno.

• sviluppo facile - WPF fornisce opzioni per sviluppare sia applicazioni desktopper Windows sia per ospitare applicazioni all’interno di un browser web e ancheoffrire opzioni di navigazione simili a quelle di un browser all’interno di unaapplicazione desktop.

In breve, WPF si pone come obiettivo quello di combinare le migliori caratteri-stiche di vari sistemi, come DirectX (per il 3D e l’accelerazione hardware), WindowsForms (per la produttività dello sviluppatore), Adobe Flash (per il supporto alleanimazioni) e HTML (per il linguaggi dichiarativi e la semplicità di sviluppo).

WPF, in termini di funzionalità, ovviamente, non permette di fare cose che inprecedenza non si sarebbero potute fare. Le permette di fare, però, in un modopiù semplice, più veloce, più stabile, più sicuro e senza ricorrere a tante tecnologiediverse che potrebbero dare problemi nel momento in cui esse vengono integrate.

1linguaggi che si focalizzano sulla descrizione delle proprietà della soluzione desiderata (il cosa),lasciando indeterminato o poco determinato l’algoritmo da usare per trovare la soluzione (il come).

30

Page 36: Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale

4 – Tecnologia utilizzata

Avendo, inoltre, citato DirectX, non bisogna pensare che questa tecnologia siamorta, visto che adesso esiste WPF: sono due cose distinte che agiscono a livellidiversi, più alto WPF e più basso DirectX. La scelta di utilizzare l’una o l’altra perapplicazioni che utilizzino molto la grafica, dipende dagli obiettivi che si voglionoottenere e dalle possibilità di testing che si hanno. Per gli scopi di questa tesi, lepossibilità offerte da WPF sono più che sufficienti.

Infine, c’è ancora da spendere alcune parole a proposito di Adobe Flash. WPFnon utilizza né direttamente né direttamente la tecnologia introdotta da Flash, cheattualmente è l’opzione più popolare per creare contenuti web evoluti. Le appli-cazioni WPF possono essere eseguite all’interno di un browser web, ma richiedonoWindows e il framework .NET 3.0 o superiore installato. Per Flash, invece, bastaun plug-in che è disponibile per molte piattaforme diverse, non solo per Windows.

L’alternativa Microsoft a Flash esiste e consiste in un sottoinsieme di WPF: il suonome è Silverlight, è disponibile come un plug-in ufficiale per Mac e Windows (e unonon ufficiale per sistemi Linux), supporta XAML, JavaScript e alcune caratteristichedella piattaforma .NET. In questa dissertazione non si parlerà più di Silverlightma, vista la stretta parentela esistente tra WPF e questa tecnologia, è sembratoopportuno almeno citarne l’esistenza.

4.2 XAML

XAML, la cui pronuncia corretta è “Zammel ”, è uno strumento molto importanteper integrare designer grafici nel processo di sviluppo di un applicativo e permettedi creare interfacce utente in un modo innovativo e molto produttivo.

Infatti:

• XAML è generalmente il modo più conciso di rappresentare interfacce utenteo altre gerarchie di oggetti;

• l’uso di XAML incoraggia la separazione tra come il programma appare e comefunziona (la sua logica, cioè) ed è una cosa molto utile per la manutenzione el’aggiornamento del software;

• XAML può essere utilizzato in strumenti come XamlPad, presente nell’SDKdi Windows, o in Visual Studio 2008 e successivi per vedere in real-time ilrisultato di ciò che si sta scrivendo;

• XAML è il linguaggio prodotto dalla maggior parte degli strumenti legati aWPF.

31

Page 37: Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale

4 – Tecnologia utilizzata

In questo paragrafo non si intende insegnare a programmare in XAML o con leWPF, in quanto esula dagli scopi di questa dissertazione, ma solo presentare alcunecaratteristiche peculiari di XAML in modo da permetterne la comprensione generale.

Alcuni altri dettagli su XAML verranno poi forniti nel capitolo 5, dedicato al-la realizzazione di DOGeye; in ogni caso, si rimanda alla documentazione dellaMicrosoft, disponibile su MSDN, per ulteriori informazioni e dettagli.

4.2.1 Caratteristiche

XAML è, come già detto nel paragrafo precedente, un linguaggio di programmazionedichiarativo atto a costruire e inizializzare oggetti .NET, incluso nel framework .NETa partire dalla versione 3.0, insieme a un suo compilatore, a un parser che agisce atempo di esecuzione e a un plug-in che consente di visualizzare file XAML (chiamati“pagine XAML libere” o, in inglese “ loose XAML pages”) all’interno del browserInternet Explorer.

XAML è un modo di utilizzare le API appartenenti al .NET e consiste di regoleche indicano come i parser e i compilatori devono trattare XML e alcune parolechiave, ma non definisce nessun elemento XML interessante.

Anche se XAML è stato originariamente sviluppato e pensato per WPF, bisognatenere presente che le due tecnologie possono essere utilizzate in maniera indipen-dente l’una dall’altra: per fare un esempio, XAML si può utilizzare anche con leWindows Workflow Foundation e, addirittura, stanno nascendo plug-in per poterutilizzare XAML per realizzare interfacce utente con il linguaggio Java. Inoltre,tutto quello che può essere fatto in XAML può anche essere fatto con un qualunquelinguaggio .NET, perdendo però tutti i suoi benefici: pertanto è raro vedere WPFsenza XAML.

Le specifiche di XAML definiscono, perciò, regole che mappano i vari namespace,tipi, proprietà ed eventi appartententi a .NET in namespace, elementi e attributidi tipo XML. Questo si può vedere dal semplice esempio che segue e che mette aconfronto lo stesso codice scritto in XAML e in C#:

XAML:

<Button xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"Content="OK" />

C#:

System.Windows.Controls.Button b = new System.Windows.Controls.Button();b.Content = "OK";

Anche se le due porzioni di codice precedente sono uguali, si può vedere istan-taneamente il risultato del codice XAML salvando un file con estensione .xaml e

32

Page 38: Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale

4 – Tecnologia utilizzata

aprendolo in Internet Explorer, mentre per il C# bisognerebbe prima compilaretutto. Il risultato di entrambi è la creazione di un bottone che avrà come contenutola parola “OK”.

Com’è possibile vedere dall’esempio, dichiarare un elemento XML in XAML,chiamato object element, è equivalente a istanziare il corrispondente oggetto .NETattraverso il suo costruttore di default.

Impostare un attributo, invece, equivale a impostare una proprietà con le stessonome, nel qual caso si parla di attributo di proprietà, o assegnare un handler per unevento dello stesso nome, cioè un attributo di evento.

Inoltre XAML, come il linguaggio C#, è un linguaggio case-sensitive, cioè nonè la stessa cosa scrivere una parola in maiuscolo o in minuscolo.

Facendo sempre riferimento all’esempio precedente, si può notare che nella pri-ma riga di XAML compare l’identificatore xmlns, seguito quello che sembra un in-dirizzo Internet: quello è il namespace XML associato al namespace .NET System.Windows.Controls. Come per ogni namespace XML, non si trova nessuna web pagea quell’indirizzo: è solo una stringa arbitraria.

Il namespace XAML dell’esempio contiene tutti i seguenti namespace C#, rea-lizzando quindi un mapping molti-a-uno:

• System.Windows;

• System.Windows.Automation;

• System.Windows.Controls;

• System.Windows.Controls.Primitives;

• System.Windows.Data;

• System.Windows.Documents;

• System.Windows.Forms.Integration;

• System.Windows.Ink;

• System.Windows.Input;

• System.Windows.Media;

• System.Windows.Media.Animation;

• System.Windows.Media.Effects;

• System.Windows.Media.Imaging;

33

Page 39: Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale

4 – Tecnologia utilizzata

• System.Windows.Media.Media3D;

• System.Windows.Media.TextFormatting;

• System.Windows.Navigation;

• System.Windows.Shapes;

Degni di nota sono soprattutto i namespace appartenenti a Controls che conten-gono i controlli principali XAML (come i bottoni, per esempio), Forms.Integrationche introduce alcuni metodi per l’integrazione di XAML con elementi creati con leWindows Forms e Media che contiene tutti gli strumenti per integrare audio, video,animazioni e oggetti 3D in XAML.

Proseguendo con le caratteristiche di XAML, bisogna osservare che l’oggettoradice di un file XAML deve specificare almeno un namespace che è necessario perqualificare sé stesso e tutti i suoi figli. In XAML si utilizza, generalmente, anche unsecondo namespace, che include anche il prefisso x; si utilizzerà poi tale prefisso perindicare che un oggetto o una proprietà appartiene proprio a quel preciso namespace:

xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml/"

Questo è il namespace del linguaggio XAML che mappa i tipi del namespaceC# System.Windows.Markup e definisce alcune direttive speciali per il compilatore oil parser XAML. Queste direttive appaiono spesso come attributi di elementi XML,sembrando proprietà dell’elemento senza però esserlo. I più comuni sono riportatinella tabella 4.1.

In maniera simile, si possono anche usare degli oggetti dichiarati in una classeC#, associando il namespace della classe a un prefisso inventato e utilizzando ilprefisso per creare un nuovo elemento.

L’ultima caratteristica di XAML che si vuole presentare in questo sotto-paragrafoè quella legata alla personalizzazione degli oggetti, accennata nel paragrafo prece-dente.

Per farlo, si ipotizzi di voler costruire un bottone che abbia, come contenuto, ilsimbolo dello “stop” presente nei normali lettori musicali.

Con XAML, è sufficiente utilizzare i cosidetti elementi di proprietà; in questocaso, come è possibile vedere nell’esempio che segue, si inserisce un quadrato di lato40 pixel e di colore nero all’interno del bottone, utilizzando l’elemento di proprietàButton.Content, dove Button è il nome del tipo mentre Content è il nome dellaproprietà:

<Button xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"><Button.Content>

<Rectangle Height="40" Width="40" Fill="Black" /></Button.Content>

34

Page 40: Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale

4 – Tecnologia utilizzata

Keyword Descrizione

x:Name Associa un nome a un elemento così che possa essere richiamato dalcodice procedurale.

x:Class Definisce una classe per l’elemento radice che deriva da unnamespace .NET creato ad-hoc.

x:Key Specifica la chiave di un oggetto quando viene aggiunto a undizionario.

x:Uid Segna un elemento con un identificativo utilizzabile per lalocalizzazione in più lingue.

x:Null Rappresenta un riferimento a null.x:Static Associa un elemento a una proprietà, un campo, una costante o a un

valore di enumerazione statico definito nel linguaggio procedurale.

Tabella 4.1: Alcune comuni keyword XAML

</Button>

Lo stesso risultato si può anche ottenere omettendo l’elemento di proprietà perchéoggetti come i bottoni utilizzano i loro figli come contenuto effettivo del bottone:

<Button xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"><Rectangle Height="40" Width="40" Fill="Black" />

</Button>

Collegato al discorso della personalizzazione degli elementi XAML è dovero-so parlare anche di dizionari, control template e stili, visto che si sono utilizzatiabbondantemente in DOGeye.

Uno stile è un’entità WPF relativamente semplice. La sua funzione principaleè quella di raggruppare insieme valori di proprietà che altrimenti potrebbero essereimpostate singolarmente. L’intento di questa entità è quello di poter condividerequesto gruppo di valori tra più elementi, senza così doverli riscrivere tutte le volte eper ogni singolo elemento.

Per esempio, si potrebbe definire uno stile in cui si stabilisce che la dimensionedel font della scritta che compare in un bottone deve essere di 22 punti, che il suosfondo deve essere di colore arancione, che la scritta deve essere bianca e che ilbottone deve essere ruotato di un angolo pari a 10 gradi. In questo modo:

<Style x:Key="buttonStyle"><Setter Property="Button.FontSize" Value="22" /><Setter Property="Button.Background" Value="Orange" /><Setter Property="Button.Foreground" Value="White" /><Setter Property="Button.RenderTransform">

35

Page 41: Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale

4 – Tecnologia utilizzata

<Setter.Value><RotateTransform Angle="10" />

</Setter.Value></Setter>

</Style>

Definendo poi questo stile all’interno delle risorse dell’elemento che può conteneredei bottoni (o dell’elemento radice, se si vuole poter applicare lo stile a tutto il fileXAML), cioè scrivendolo per esempio in <Window.Resource>, si possono assegnarequeste proprietà a qualsivoglia bottone.

A un certo punto, quindi, si potrà scrivere:

<Button Style="{StaticResource buttonStyle}" Content="Hello" /><Button Style="{StaticResource buttonStyle}" Content="Ciao" />

creando così due bottoni diversi ma con lo stesso aspetto in base alle proprietàche si ha valorizzato definendo lo stile “buttonStyle”.

Il markup StaticResource permette di andare a recuperare la risorsa (lo stile, inquesto caso) il cui nome è dichiarato subito dopo e di applicarlo alla proprietà chelo invoca (nell’esempio, la proprietà Style).

Uno stile, inoltre, può essere ereditato da un’altro stile grazie alla proprietàBasedOn.

Se si volesse, invece, cambiare totalmente l’aspetto di un elemento WPF, peresempio un bottone, bisognerebbe utilizzare i control template. Tramite i con-trol template, infatti, è possibile cambiare forma a un bottone, rendendolo magarirotondo.

I control template, poi, si possono utilizzare all’interno di uno stile così da poterusufruire delle caratteristiche di entrambi. In questo modo, cioè, ogni controllo WPFpuò essere stilizzato nuovamente in maniera del tutto personalizzabile.

Se poi si volessero raggruppare tutti gli stili in un unico file, in modo da poterlitrasferire da un progetto all’altro o in modo da permettere all’utente di cambiareaspetto all’applicazione in base alle sue preferenze, basta utilizzare i dizionari, cheservono proprio a questo scopo.

Come si è potuto vedere viene naturale rappresentare un’interfaccia utente inXAML a causa della sua natura gerarchica, derivata da XML. In WPF, infatti, leinterfacce utente sono costruite da un albero di oggetti chiamato albero logico, danon confondere con l’albero visuale.

Grazie all’albero logico, i modelli di contenuto possono scorrere prontamente ipossibili elementi figlio e quindi essere estendibili. Inoltre, l’albero logico fornisceun framework per alcune notifiche, come il caso in cui tutti gli elementi dell’alberologico vengono caricati ed esso viene così utilizzato per la ricerca delle risorse.

36

Page 42: Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale

4 – Tecnologia utilizzata

L’albero visuale, invece, è un’espansione dell’albero logico, in cui i nodi sonosviluppati nei rispettivi componenti visuali, mostrando cioè i dettagli della loroimplementazione visuale.

Per esempio, un bottone è logicamente un solo controllo, ma nella sua rappre-sentazione visuale è composto da più elementi primitivi, come un bordo, una caselladi testo per il suo contenuto e così via.

4.2.2 Code-behind

Introducendo le caratteristiche di XAML, si è mostrato un semplice esempio in cuiveniva creato un bottone che conteneva, all’interno, la scritta OK. Quel bottone,però, una volta cliccato non produceva alcuna operazione, non faceva niente.

Per far sì che un bottone esegua un qualche tipo di operazione una volta cliccato,è necessario assegnargli un handler a un evento. In XAML, questo risultato si ottienenel modo seguente:

<Button xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"Content="OK" Click="button_Click" />

L’equivalente, in C#, sarebbe:

System.Windows.Controls.Button b = new System.Windows.Controls.Button();b.Click += new System.Windows.RoutedEventHandler(button_Click);b.Content = "OK";

Oltre a vedere la praticità nello scrivere in XAML, da questi esempi si possonoosservare altre due caratteristiche proprie di WPF:

• l’evento Click riportato in XAML richiama il metodo button_Click, che vadichiarato nel codice procedurale;

• nell’esempio scritto in C# si nota che il metodo button_Click viene richiama-to da un RoutedEventHandler; gli eventi in WPF, infatti, sono tutti di tipoRouted, cioè un evento figlio richiama gli eventi che lo precedono nell’alberodei controlli, se esistono dello stesso tipo e se non gli è stato imposto di nonfarlo.

Il codice procedurale che sta “dietro” a XAML e nel quale si dovrà dichiarareil metodo button_Click prende il nome di code-behind e può essere un qualsiasilinguaggio appartenente alla piattaforma .NET, anche se generalmente si prediligel’utilizzo di C# o di VB.NET.

Quando si crea, con Visual Studio, un nuovo progetto WPF, viene automatica-mente creato un file XAML che ha come radice l’elemento Window (a indicare chequello è un file XAML creato per realizzare un’applicazione desktop) e un file di

37

Page 43: Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale

4 – Tecnologia utilizzata

codice procedurale, per esempio C#, che conterrà una classe parziale che ereditaproprio dal file XAML.

Eccone un esempio:

<Window xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"x:Class="MyNamespace.Window1">...

</Window>

namespace MyNamespace{partial class Window1 : Window{public Window1{InitializeComponent();//Necessario per inizializzare gli elementi XAML...

}...//Altri metodi, come gli eventi dei bottoni, per esempio

}}

In fase di compilazione, poi, il file XAML verrà convertito in un formato binariospeciale, chiamato BAML (Binary Application Markup Language), verrà inseritoil contenuto di tale file come risorsa binaria dell’assembly costruito dal C# e sieffettueranno le connessioni automatiche tra XAML e il codice procedurale.

Nonostante il fatto che tutto quello che si può fare in XAML si può realizzareanche nel suo code-behind, ci sono alcuni meccanismi e strumenti che sono ottimizzatiper XAML e che richiederebbero la scrittura di molto codice in C#; d’altra parte,esistono metodi che si possono utilizzare solo nel codice procedurale.

La raccomandazione che viene fatta è quella di cercare di rispettare il più possibilel’idea che sta dietro all’accoppiata XAML e code-behind, quella cioè di utilizzareXAML per scrivere come appare l’interfaccia utente e il codice procedurale perrealizzare la logica di questa interfaccia.

4.3 Compatibilità con le tecnologie precedentiWindows Presentation Foundation è pienamente compatibile e può interoperare conle seguenti tecnologie:

38

Page 44: Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale

4 – Tecnologia utilizzata

• Win32 - è possibile inserire controlli Win32 in applicazioni WPF e controlliWPF in applicazioni Win32;

• Windows Forms - è possibile inserire controlli Windows Forms in applicazioniWPF e controlli WPF in applicazioni Windows Forms;

• ActiveX - è possibile inserire controlli ActiveX in applicazioni WPF.

Anche se ci sono chiari benefici ad avere una interfaccia utente tutta realizzatacon WPF, questa possibilità di interazione può essere una cosa molto utile, soprat-tutto nel caso in cui si sia già realizzato un controllo e non lo si voglia o non lo sipossa riscrivere da zero. Per realizzare DOGeye, ci si è ispirati ad alcune di questetecniche per integrare l’ETU-Driver che, ricordiamolo, è composto da oggetti COMe sfrutta il sottosistema grafico GDI+ per le sue necessità interne.

Un altro motivo per cui si può voler integrare WPF con una delle tecnologieprecedenti, può essere perché si vuole utilizzare qualche caratteristica del sistemaoperativo come, per esempio, l’effetto “glass” introdotto da Windows Vista in poi.

Un discorso un po’ a parte richiede l’interazione con HTML, in quanto non èpropriamente una tecnologia precedente a WPF. In ogni caso, è possibile integrareuna pagina HTML dentro un controllo WPF chiamato Frame e anche un controlloWPF dentro HTML, creando una XAML Browser Application oppure come unapagina XAML libera, utilizzando il controllo iFrame di HTML.

WPF, inoltre, è compatibile con tutte le tecnologie già utilizzabili con la piatta-forma .NET.

Nei prossimi sotto-paragrafi, si fornirà una panoramica di come queste interazionisono possibili, analizzandole caso per caso.

4.3.1 Integrare controlli Win32 in WPF

In Win32, tutti i controlli sono considerati come “finestre” e le API di Win32 inte-ragiscono con loro attraverso degli handle conosciuti come HWND. Tutte le tecnologiebasate su Windows, come DirectX, MFC e così via, usano HWND a qualche livello,così l’abilità di lavorare con HWND offre a WPF la possibilità di interagire con tuttequeste tecnologie.

Anche se i sottosistemi di WPF, come quello di layout o quello di animazione,non sanno come interagire con HWND, WPF definisce un FrameworkElement (una delleclassi più alte e generali nella gerarchia delle classi WPF) che può ospitare proprioun HWND.

Questo FrameworkElement si chiama System.Windows.Interop.HwndHost e permet-te di utilizzare questi controlli proprio come se fossero controlli nativi WPF.

39

Page 45: Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale

4 – Tecnologia utilizzata

L’unico “problema” è che questi controlli sono generalmente scritti in C++, e do-vrà essere incluso in un altro file C++ in modalità managed che, però, non supportala compilazione di XAML.

4.3.2 Integrare controlli WPF in Win32

Sono molte le funzionalità interessanti di WPF che possono essere integrate in un’ap-plicazione Win32: il 3D, il supporto avanzato per i documenti, l’animazione e cosìvia.

Anche se non si ha bisogno di tali funzionalità, ci si può avvantaggiare utilizzandoaltre caratteristiche di WPF, come il suo layout flessibile e l’indipendenza dallarisoluzione.

L’interoperabilità di WPF con HWND è bidirezionale, così che i controlli WPFpossono essere inseriti nelle applicazioni Win32 più o meno allo stesso modo in cuii controlli Win32 sono inseriti in applicazioni WPF: si utilizza, in questo caso, laclasse HwndSource, che espone ogni controllo visuale di WPF come un HWND.

Questa classe si può utilizzare anche in un’applicazione pura WPF per risponderead alcuni messaggi di Windows che, magari, si ha bisogno di intercettare.

4.3.3 Integrare Windows Forms e WPF

Siccome i controlli Windows Forms sono facilmente esponibili come controlli Win32,si potrebbero utilizzare le stesse tecniche presentate in precedenza per realizzarequesto tipo di interazione.

WPF, però, offre anche altre opportunità in modo da fornire un’interazione piùricca e completa con Windows Forms, siccome entrambi sono basati su oggetti .NETche hanno proprietà ed eventi molto simili.

Questa interazione è costruita sopra l’interoperabilità con Win32 ma è resa piùsemplice introducendo molte altre funzionalità, senza bisogno di scrivere alcuna rigadi codice non gestito.

Come per l’interoperabilità conWin32, WPF definisce una coppia di classi per co-prire entrambe le direzioni dell’interazione. L’equivalente di HwndHost prende il nomedi WindowsFormsHost e fa parte del namespace System.Windows.Forms.Integration.

L’host di integrazione va creato all’interno di un nuovo metodo privato che vienechiamato dall’evento Loaded di WPF. Tale evento dice non solo che l’albero logi-co dell’applicazione è costruito e inizializzato, cosa che tra l’altro fa già l’eventodi inizializzazione richiamato dal metodo InitializeComponent(), ma anche che illayout deve agire su di esso, che i dati sono stati tutti collegati, che è stato connessoa una superficie di rendering (la finestra) e che è sul punto di essere renderizzatocompletamente.

40

Page 46: Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale

4 – Tecnologia utilizzata

Il controllo Windows Forms va inserito proprio in quel punto poiché necessitadi avere già tutte le informazioni relative alla finestra e al suo rendering, essendobasato su un sottosistema grafico diverso da quello di WPF.

Inoltre, aggiungendo un manifest file, è possibile applicare anche ai controlliWindows Forms le eventuali modifiche stilistiche che sono state effettuate ai controlliWPF, facendo sì che tutta l’interfaccia abbia lo stesso look-and-feel.

Per integrare, invece, un controllo WPF in un’applicazione Windows Forms siutilizza la classe ElementHost, un controllo Windows Forms che, internamente, sacome trattare contenuti WPF.

4.3.4 Integrare controlli ActiveX in WPF

L’integrazione con i controlli ActiveX è un esempio di retro-compatibilità piuttostoche di innovazione: WPF, infatti, eredita questa possibilità da Windows Forms. Inpratica, si utilizza Windows Forms come livello intermedio tra ActiveX e WPF.

L’integrazione può essere fatta in due modi differenti:

• eseguendo l’ActiveX Importer, un’utility inclusa nella SDK di Windows, sullaDLL ActiveX;

• aggiungendo il controllo ActiveX in un progetto Windows Forms tramite ildesigner di Visual Studio; questo causerà la chiamata dell’ActiveX Importerda parte di Visual Studio.

Indipendentemente da quale approccio si voglia seguire, come risultato si ottienela generazione di due DLL. Per ottenere l’interoperabilità tra le due tecnologie, bastaaggiungerle al progetto WPF e predisporlo per l’integrazione con le Windows Forms,richiamando poi i metodi necessari dalla seconda DLL ActiveX (quella il cui nomeinizia con “Ax”).

L’integrazione di controlli WPF in ActiveX, invece, non può essere fatta conmeccanismi simili ai precedenti: gli sviluppatori di WPF non hanno predispostoquesta eventualità.

È però possibile creare un controllo ActiveX con qualche tecnologia non-WPF,come Active Template Library (ATL), e innettarvi contenuto WPF al suo interno.

4.4 Differenze rispetto alle Windows Forms

Arrivati a questo punto del capitolo, le differenze tra Windows Presentation Foun-dation e Windows Forms (in seguito, abbreviato con WinForms) dovrebbero essereabbastanza evidenti, anche se WPF non nasce per sostituire Windows Forms.

41

Page 47: Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale

4 – Tecnologia utilizzata

Allo stesso modo, dovrebbe essere evidente quale delle due preferire, se nonsi hanno particolari esigenze e si vuole costruire un’interfaccia utente moderna epotente, risparmiando tempo e risorse.

In questo paragrafo, si riassumeranno queste differenze, sottolineando prima ivantaggi che si ottengono utilizzando WPF e poi gli svantaggi, facendo sempreriferimento alle Windows Forms come termine di paragone.

4.4.1 Vantaggi

I vantaggi nell’utilizzare WPF invece di WinForms possono essere:

1. la possibilità di avere una struttura potente per realizzare layout complicati apiacere e con lo stile che si vuole: se si preferisce o si deve mantenere lo stiledell’interfaccia utente perfettamente coerente con l’interfaccia di Windows sipuò fare; se la si vuole stravolgere completamente, pure.

Questo strumento, di per sé, potrebbe essere anche uno svantaggio, se usatosenza cognizione, creando così interfacce scarsamente usabili.

2. la semplicità con cui è possibile creare un proprio look-and-feel nell’interfac-cia utente che si sta realizzando; addirittura esiste un programma, chiamatoMicrosoft Expression Blend, che permette di costruire la parte XAML del-l’interfaccia senza scrivere una riga di codice dichiarativo. Ovviamente, cometutti i programmi che producono codice automaticamente, non produce uncodice pulito come uno scritto a mano, ma può essere un buon punto di inizio.

3. il supporto alle Windows Forms, attraverso l’interoperabilità di cui si è parlatobrevemente nel paragrafo precedente.

4. WPF rappresenta la futura tecnologia per sviluppare applicazioni per Windowsutilizzando la piattaforma .NET. Quindi può essere una buona idea dedicarcidel tempo.

5. la possibilità di riutilizzare il codice esistente prodotto con il framework .NET:in alcuni casi, i cambiamenti del codice C# da WinForms a WPF sono davverominimi; in altri, addirittura inesistenti. Quindi, con poco sforzo, si possonoriadattare parti di applicativi per essere utilizzati con WPF, anche se poibisogna comunque sviluppare la parte in XAML.

6. il databinding nettamente superiore rispetto a quello di WinForms, dove perdatabinding si intende un modo per gli sviluppatori di creare un collegamentodi lettura/scrittura tra i controlli dell’interfaccia utente e i dati necessari perla parte logica dell’applicazione.

42

Page 48: Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale

4 – Tecnologia utilizzata

7. l’integrazione semplice e potente di diversi tipi di media nell’interfaccia uten-te. Per esempio, se c’è bisogno di includere un video o un documento o uncontenuto 3D o una transizione animata tra una sequenza di immagini o unacombinazione dei precedenti.

8. la possibilità offerta da XAML di essere visualizzato direttamente in un browserweb e in tempo reale, senza necessità di compilazione.

9. la possibilità di caricare dinamicamente solo una porzione di una interfacciautente da un servizio Web o se si vuole creare un’applicazione desktop conun sistema di navigazione simile a quello che si utilizza per i browser (avanti,indietro, cronologia, ecc.).

10. la possibilità di separare la parte visuale dell’interfaccia utente da quella logica;la prima sarà prodotta in XAML, mentre la seconda nel code-behind.

11. la possibilità di avere parti dell’interfaccia grafica virtualizzate: viene cioè cari-cata (e scaricata) la parte di un controllo utente che interessa solo nel momentoin cui essa viene visualizzata. Per esempio, si immagini di avere una lista dicentomila elementi, magari rappresentati con delle immagini. Sull’interfacciautente, se ne possono visualizzare dieci alla volta, per il semplice fatto chetutti e centomila sullo schermo non ci stanno. La virtualizzazione consistenel caricare in memoria solo i dieci elementi visibili e di non caricare tutti glialtri. Appena si andrà avanti nella lista, gli elementi non più visibili sarannoscaricati, mentre quelli visibili verranno caricati.

12. il supporto interno al 3D e alle operazioni grafiche di base (rotazione, trasla-zioni, effetti bitmap e così via).

4.4.2 Svantaggi

Tra gli svantaggi derivati dall’utilizzo di WPF nei confronti di WinForms, è neces-sario ricordare:

1. un’applicazione prodotta con WPF richiede almeno il framework .NET versio-ne 3.0, installato di default a partire da Windows Vista ma disponibile ancheper Windows XP.

2. la necessità di avere una scheda grafica compatibile con le DirectX 9, se si vuoleusufruire di alcuni aspetti avanzati della grafica e della possibilità di utilizzarela GPU per determinate operazioni, invece che la CPU.

43

Page 49: Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale

4 – Tecnologia utilizzata

3. la curva di apprendimento di WPF; se si volesse rappresentare con una curvamatematica, si potrebbe utilizzare la funzione esponenziale: l’apprendimentoè molto semplice all’inizio ma, man mano che si apprendono cose nuove e sinecessita di funzionalità sempre più avanzate, l’apprendimento diventa moltodifficoltoso.

4. la “gioventù” di WPF rispetto a WinForms: queste ultime hanno certamentepiù controlli di terze parti disponibili, risorse online, comunità di sviluppatorie così via.

5. gli strumenti per il design dell’interfaccia inclusi in Visual Studio 2008 funzio-nano molto meglio per WinForms che per XAML.

6. interoperabilità non ancora perfetta di WPF con componenti perfettamentefunzionanti se utilizzate con WinForms.

C’è però da dire che la maggior parte di questi svantaggi o non sono così rilevantio sono derivati dalla relativa gioventù di questa tecnologia. E quest’ultimo aspettosarà superato dal trascorrere del tempo. . .

Tabella 4.2: Vantaggi e svantaggi di WPF

Vantaggi Svantaggi

alta personalizzazione dell’aspettodella UI

designer di Visual Studio 2008 perfe-zionabile

separazione tra UI e logica delprogramma

necessità di scheda video compati-bile con DirectX 9 per performancemigliori

futura tecnologia .NET curva di apprendimento molto ripidapossibilità di riutilizzare codice proce-durale .NET

ancora poche risorse di terze partidisponibili

databinding estremamente potente necessita .NET 3.0 o superioreorientato al webintegrabile con dei servizi webadatto a contenuti multimediali e 3Dpossibilità di avere parti della UIvirtualizzate

44

Page 50: Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale

Capitolo 5

Progettazione e implementazione

In questo capitolo verranno presentate le varie fasi che hanno portato alla realizza-zione dell’interfaccia utente DOGeye (nome formato da DOG più EYE interaction,ndr), mostrando l’architettura dell’ambiente in cui andrà a collocarsi, esponendo emotivando le scelte progettuali fatte e analizzando gli aspetti più interessanti del-la sua realizzazione da punto di vista della programmazione con le WPF e conl’ambiente .NET in generale.

5.1 Introduzione

DOGeye è stato sviluppato in base a due vincoli principali, come già accennatonel capitolo 2 di questa tesi: da una parte l’applicazione deve essere in grado diinteragire con la piattaforma DOG; dall’altra deve rispettare le specifiche COGAIN.A livello di architettura, in particolare, deve poter interagire con l’ETU-Driver.

Figura 5.1: L’architettura generale dell’ambiente

45

Page 51: Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale

5 – Progettazione e implementazione

La figura 5.1 mostra tale architettura: l’applicazione comunica con l’ambientedomotico attraverso DOG (a sinistra), grazie al protocollo XML-RPC che gli per-mette di avere tutte le informazioni di cui ha bisogno sulla casa e i suoi dispositivi,nonché di comandarli; e con il livello dell’ETU-Driver (a destra), per controllarel’eye-tracking, sia esso simulato dal driver stesso o reale.

Facendo riferimento alle specifiche COGAIN, in particolare al Deliverable 2.5, ilvincolo sull’ETU-Driver è imposto dalla linea guida 2.1.

La realizzazione della versione di DOGeye presentata come risultato finale diquesto progetto, inoltre, ha richiesto tre fasi preliminari:

• lo studio delle caratteristiche di DOG, dell’ETU-Driver e delle specifiche CO-GAIN, riportate nei capitoli precedenti;

• la realizzazione di una versione preliminare dell’interfaccia;

• la realizzazione del mock-up di DOGeye.

La versione preliminare (visibile in figura 5.2), è servita principalmente per com-prendere i meccanismi di funzionamento di DOG, testarne i requisiti per il collega-mento con l’interfaccia e comprendere come effettuare tale collegamento; per iniziarea lavorare con WPF e XAML e, infine, per integrare l’ETU-Driver e verificarne ilfunzionamento.

Figura 5.2: La versione preliminare di DOGeye

46

Page 52: Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale

5 – Progettazione e implementazione

Il collegamento con DOG, effettuato grazie a XML-RPC, non ha dato alcun tipodi problema.

Viceversa, l’integrazione con l’ETU-Driver ha presentato qualche difficoltà: il suocreatore, infatti, insieme al driver mette a disposizione il codice di programma scrittoin C# in cui è possibile vedere come inserire il driver all’interno di un’interfacciautente (scritta utilizzando Windows Forms) e come utilizzarne le funzionalità.

Il problema è che, integrando il driver nel modo suggerito, l’interfaccia utentescritta in WPF non funzionava per niente, invocando un’eccezione e chiudendosisenza dare la possibilità di svolgere alcun tipo di operazione.

La soluzione è stata trovata studiano i meccanismi di interazione offerti da WPF,in particolare prendendo spunto sia da quelli che offrono l’interoperabilità con Win32che con quelli utilizzati per l’interoperabilità con Windows Forms: tale soluzione,adottata anche per DOGeye, verrà presentata nel paragrafo 5.3.4.

Per realizzare DOGeye, quindi, si sono riutilizzati i metodi e le soluzioni messein atto realizzando questa versione preliminare dell’interfaccia.

È il caso di spendere due parole per descrivere questa interfaccia utente prelimi-nare; essa è divisa, orizzontalmente, in tre aree:

la prima che contiene l’elenco delle stanze presente nella casa;

la seconda che contiene l’elenco dei dispositivi e un’area per comandarli;

la terza che rappresenta l’area di log e contiene i pulsanti necessari per utilizzarel’eye-tracking come meccanismo di interazione.

La seconda area orizzontale, a sua volta, è divisa in due parti: la prima checontiene l’elenco dei dispositivi presenti nella stanza selezionata e la seconda (adestra) che appare quando viene selezionato un dispositivo e che contiene lo statodel dispositivo e dei bottoni per comandarlo.

Se non è possibile comandarlo dall’interfaccia (perché DOG stabilisce che è undispositivo comandabile solo dalla casa reale, come accade per gli interruttori, peresempio), l’area di destra presenta solo lo stato attuale del dispositivo.

La terza area orizzontale, invece, contiene un log testuale che mostra in cimal’ultima operazione compiuta dall’interfaccia utente o dalla casa e tre pulsanti perimpostare alcune preferenze dell’ETU-Driver (il bottone Options), per avviare lacalibrazione dell’eye-tracker (Calibration) e per avviare l’eye-tracker (Start).

Nel caso in cui non sia presente un eye-tracker vero e proprio, è possibile selezio-nare la modalità di simulazione dell’ETU-Driver dalle opzioni e avviare il traccia-mento che, in questo caso, sarà simulato dalla posizione del puntatore del mouse.

L’interfaccia, in ogni caso, è utilizzabile sia attraverso l’eye-tracking che attra-verso il mouse.

47

Page 53: Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale

5 – Progettazione e implementazione

Questa interfaccia preliminare, però, nasce solo per scopi di apprendimento e ditesting, e non rispetta quasi nessuna delle linea guida offerte dal COGAIN.

Inoltre, essa offriva solo alcune funzionalità di base e non si erano studiatefunzionalità più evolute.

È stato, quindi, necessario pensare un’interfaccia utente totalmente nuova, DO-Geye appunto, che si descriverà nel paragrafo successivo e della quale si riporta, infigura 5.3, il mock-up che è stato realizzato con carta e matita prima di iniziarne losviluppo effettivo a computer.

Figura 5.3: Il mock-up di DOGeye

5.2 Scelte progettuali e funzionalitàL’interfaccia DOGeye, rappresentata in figura 5.4, è suddivisa in quattro aree logi-che:

Tabs area (o area dei tab) - è la parte dell’interfaccia che contiene i tab con i qualisi realizzano diverse viste dell’ambiente, in base al tipo di dispositivo che sivuole utilizzare. Rappresenta la vista funzionale della casa.

Selection area (o area di selezione) - è la parte dell’interfaccia che si occupa dellepossibilità di selezione e visualizzazione: della stanza, del dispositivo e cosìvia. Rappresenta la vista strutturale della casa.

48

Page 54: Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale

5 – Progettazione e implementazione

Command area (o area di comando) - è la parte dell’interfaccia che contienei comandi che si possono impartire ai dispositivi della casa e all’interfacciastessa.

Notification area (o area di notifica) - è l’area che si occupa di visualizzare lenotifiche e gli allarmi all’utente.

Figura 5.4: L’interfaccia DOGeye

Le prime due aree nascono dall’esigenza, sottolineata dal Deliverable 2.5 diCOGAIN, di trovare un giusto equilibrio tra la vista funzionale e la vista strutturale.

In questo modo, si realizzano due livelli gerarchici di interazione: il primo per-mette di scegliere il tipo di dispositivo o il tipo di operazione che si vuole fare (vistafunzionale); il secondo permette di scegliere il dispositivo all’interno della casa o dicompiere l’operazione vera e propria, nel caso si tratti di un’operazione di più altolivello, come per i già citati scenari.

La terza area nasce dall’esigenza di rispondere alla linea guida 1.4 che raccoman-da di “fornire una richiesta di conferma per le operazioni critiche e possibilmentedannose”: avere un’area apposita nella quale si possano comandare i dispositivi edeffettuare altre operazioni solo dopo aver selezionato un oggetto offre, a diversi li-velli, le stesse funzionalità di una richiesta di conferma, sia utilizzando DOGeye con

49

Page 55: Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale

5 – Progettazione e implementazione

il mouse che con un eye-tracker, dove l’errore introdotto dal tocco di Mida vieneminimizzato utilizzando la tecnica del dwell time.

La quarta area, infine, offre la possibilità di realizzare le linee guida 3.4 e 4.1,che trattano entrambe del feedback da restituire all’utente quando viene eseguitaqualche operazione all’interno della casa.

Prima di analizzare nel dettaglio i vari tab e le loro funzionalità specifiche, èdoveroso soffermarsi su alcuni aspetti e funzionalità generali dell’interfaccia.

Il primo consiste nell’utilizzo del sistema di sintesi vocale di Windows all’internodi DOGeye, come modalità di output supplementare rispetto alla visualizzazionegrafica: quando si dà il comando per entrare in una stanza e quando si comandaun dispositivo, oltre alla notifica visiva dell’operazione, viene emessa anche unanotifica audio. Quindi, per esempio, accendendo la lampada chiamata, all’internodella casa, “Lamp1”, si sentirà la frase “Lamp1 switched on”. Attualmente DOGeye èlocalizzato in inglese e quindi anche la sintesi vocale è nello stesso linguaggio. Questafunzionalità è stata ispirata dalla linea guida 4.4 che, nella sua descrizione, suggeriscedi “evidenziare un cambiamento di stato di un dispositivo utilizzando immagini, testoe suoni ”.

Il secondo aspetto è una funzionalità di allarme che può essere invocata dall’u-tente nel caso in cui abbia bisogno di un qualche tipo di aiuto: è collocato sul latodestro dell’area di notifica come un pulsante che rimane invisibile fintanto che nonlo si guarda (o non ci si passa il mouse sopra).

Interagendo con esso, viene riprodotto un suono di allarme e viene visualizzatauna finestra in primo piano che impedisce di eseguire qualsiasi tipo di operazione inDOGeye fintanto che non viene premuto il pulsante di stop:

Figura 5.5: Aspetto di DOGeye quando l’utente necessita qualche tipo di aiuto

50

Page 56: Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale

5 – Progettazione e implementazione

Il terzo riguarda i tab:• ognuno è indipendente dall’altro: se si sta, per esempio, spegnendo una luce

attraverso il primo tab e ci si sposta in un altro, ritornando al primo si ritroveràtutto nella situazione in cui lo si è lasciato. Non si perde, quindi, nessunaselezione eseguita.

• ognuno è rappresentato da un’icona di colore differente e da un testo esplica-tivo: studi dimostrano, infatti, che associare un’icona a un’etichetta di testoriduce notevolmente la possibilità di cattiva interpretazione e di errore da partedi un utente, rispetto all’utilizzare solo un’icona o solo un breve testo.

• per sapere quale tipo di dispositivo deve essere collocato in un determinatotab, viene consultato un file testuale di configurazione. Questa caratteristicapotrà essere integrata in DOG, in futuro.

Il quarto e ultimo aspetto generale riguarda la scelta del colore dei bottoni uti-lizzati nell’interfaccia utente, scelta che non è casuale ed è coerente lungo tuttal’interfaccia: si è cercato, infatti, di abbinare un colore diverso in base alle diversefunzioni dei bottoni, cercando di mantenere anche un soddisfacente aspetto estetico,in modo che l’interfaccia sia elegante e chiara (linea guida 4.2).

Dopo aver scelto uno sfondo scuro (dal nero sfuma gradualmente e orizzontal-mente verso il grigio chiaro), si sono divisi i pulsanti nelle cinque aree funzionaliriportate in tabella 5.1 e, per ognuno, si è associato un colore opportuno.

È necessario, ancora, spendere due parole riguardo alla modalità di interazionecon DOGeye. Oltre alla semplice interazione con il mouse, si è detto, questa inter-faccia è utilizzabile anche con l’ausilio dell’eye-tracking. Per non incorrere nell’erroredel tocco di Mida, all’inizio di questo paragrafo si diceva di utilizzare la tecnica deldwell time. Questo tempo di attesa è impostabile a piacere dall’utente, in base allasua esperienza nell’utilizzare l’eye-tracker e alle sue capacità fisiche.

Non tutta l’interfaccia, però, utilizza questa tecnica: essa viene utilizzata so-prattutto dove ci sono comandi dati alla casa, piuttosto che operazioni che riman-gono interne all’interfaccia in quanto, in caso di errore, non si è commessa nessunaoperazione né reale né critica o dannosa.

Pertanto, le operazioni di selezione, come la selezione di una stanza, avvengonosenza l’ausilio del dwell time; operazioni di comando sui dispositivi della casa e ope-razioni che utilizzano dei bottoni, invece, sì. Tali operazioni vengono anche indicatevisivamente da un grafico a torta che compare sul bottone con il quale si sta inte-ragendo, grafico che si completerà pian piano fino al raggiungimento del dwell timefissato. A quel punto, l’azione collegata al pulsante verrà eseguita.

D’ora in avanti non si farà più questa distinzione e per indicare un’interazionecon un oggetto dell’interfaccia utente si utilizzerà il termine “click ” e i suoi derivati,come se si agisse sempre con il mouse.

51

Page 57: Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale

5 – Progettazione e implementazione

Tabella 5.1: Attribuzione dei colori ai bottoni dell’UI in base alla loro funzione

Funzione Descrizione Colore

Comando positivo Rientrano in questa categoria i coman-di come “accendi” o “apri”, quelli cioèche danno l’idea di un’azione positiva

Verde

Comando negativo Rientrano in questa categoria i coman-di come “spegni” o “chiudi”, ma an-che quelli che rappresentano la fine diun’operazione in corso, come “stop”

Rosso

Comando neutro Rientrano in questa categoria i coman-di che non possono essere inseriti nellecategorie precedenti o quelli che posso-no rappresentare più comportamenti,come il comando “imposta a. . . ”

Grigio

Selezione Rientrano in questa categoria i pulsan-ti che attivano/disattivano le funziona-lità di selezione di stanze o dispositiviall’interno dell’interfaccia

Nero

Comandi di interfaccia Rientrano in questa categoria i coman-di relativi all’interfaccia che non svol-gono alcuna azione reale nella casa,come “Entra nella stanza”

Blu

5.2.1 “Home Management” ed “Electric Device”

Per analizzare più in dettaglio le scelte progettuali e le funzionalità dei tab, si è sceltodi fare un unico discorso per i primi due, in quanto essi hanno le stesse caratteristichee le stesse funzionalità.

Quello che cambia è il tipo di dispositivi che comprendono:

• in Home Management compaiono i dispositivi basilari di un’abitazione, comegli interruttori, le tapparelle, le luci, le porte, ecc.;

• in Electric Device, invece, compaiono tutti quei dispositivi che si collegano auna spina di corrente, come una macchinetta del caffè. Se sono sufficientementeevoluti e riescono a dichiarare che elettrodomestico sono, vengono visualizzatiper quello che sono; altrimenti appaiono rappresentati come “spine” (plug).

Per semplicità, quindi, in questo sotto-paragrafo ci si riferirà a entrambi i tabcome se fossero uno solo.

52

Page 58: Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale

5 – Progettazione e implementazione

Appena si clicca sopra il tab, viene mostrata nell’area di selezione, la planimetriadella casa con delle miniature dei dispositivi presenti nelle stanze (fig. 5.6): l’areadi controllo rimane invisibile così come l’area di notifica.

Figura 5.6: La planimetria della casa, così come viene visualizzata in “HomeManagement”

Le informazioni disponibili sulle stanze e sui vari dispositivi al loro interno vengo-no comunicati da DOG non appena si clicca, per la prima volta, sul tab in questione.L’attuale implementazione di DOG, però, non fornisce né la posizione delle stanzeall’interno della casa né le loro dimensioni.

Per realizzare questa funzionalità, pertanto, si è creato un file XML contenentela dimensione in metri delle stanze e la loro posizione relativa, del quale se ne riportauna parte:

<?xml version="1.0" encoding="UTF-8"?><housedescription><room uri="bedroom" type="bedroom"><height>5</height><width>7</width><position><X>0</X><Y>0</Y>

<position></room><room uri="storageroom" type="storageroom"><height>3</height>

53

Page 59: Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale

5 – Progettazione e implementazione

<width>3</width><position><X>11</X><Y>5</Y>

<position></room>

</housedescription>

Come si può vedere, una stanza è definita dal suo nome (uri) e dal suo tipo (type)poiché anche DOG la definisce nello stesso modo. La stanza ha un’altezza heighte una larghezza width entrambe definite in metri; ha poi una posizione lungo X elungo Y, anch’essa definita in metri. La posizione (0,0) è rappresentata nel sistemaortogonale proprio delle interfacce grafiche, cioè nell’angolo in alto a sinistra dellafinestra.

DOGeye, all’avvio, legge la configurazione della casa da DOG e unisce le infor-mazioni contenute in questo file. Dopodiché, converte le dimensioni delle stanze inmodo tale da poter visualizzare interamente la planimetria della casa nell’area diselezione.

Questa funzionalità è stata implementata per migliorare l’aspetto di DOGeye eper fornire una visualizzazione immediata degli stati e della posizione dei dispositiviall’interno della casa (linea guida 4.3).

Selezionando una stanza, il comportamento dell’interfaccia varia in base al nu-mero di dispositivi che contiene, in modo da non richiedere all’utente di interagirecon l’interfaccia più di quanto ci sia davvero bisogno.

Se la stanza:

• non contiene nessun dispositivo, nell’area di controllo viene visualizzata ladescrizione della stanza selezionata, fornita da DOG;

• contiene un dispositivo solo, nell’area di controllo viene visualizzata la de-scrizione della stanza selezionata, il nome e lo stato (sia graficamente chetestualmente) dell’unico dispositivo presente e vengono mostrati i bottoni percomandarlo;

• contiene più di un dispositivo, nell’area di controllo viene visualizzata la descri-zione della stanza selezionata, un pulsante “Go in! ” per accedere alla stanza evisualizzare tutti i dispositivi in essa contenuti, e due bottoni che permettonodi eseguire semplici operazioni su tutti i dispositivi di un certo tipo contenutinella stanza.

Questi tre casi sono rappresentati in figura 5.7.Per completezza, si ipotizzi di aver selezionato una stanza che contiene più di

un dispositivo. In tal caso, se si vogliono compiere operazioni poco dettagliate,

54

Page 60: Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale

5 – Progettazione e implementazione

(a) Nessun disposi-tivo.

(b) Un solo disposi-tivo.

(c) Più di un dispo-sitivo.

Figura 5.7: I tre possibili comportamenti ottenibili selezionando una stanza nei primidue tab di DOGeye

semplici e di gruppo (come accendere tutte le luci della stanza) è sufficiente cliccaresul bottone “Turn on devices. . . ” o, se si vuole compiere l’operazione opposta, su“Turn off devices. . . ”. In questo modo, si potrà selezionare il tipo di dispositivo sulquale si vuole agire e ottenere il risultato desiderato.

Altrimenti, basta premere il pulsante “Go in! ” per entrare nella stanza. Entratinella stanza, nell’area di selezione compaiono i dispositivi presenti in essa e, in basso,due pulsanti che consentono rispettivamente di selezionare tutti i dispositivi per tipoe di eseguire una selezione multipla, sempre tra dispositivi dello stesso tipo: nonavrebbe senso, infatti, voler comandare una porta e una luce fornendo a entrambilo stesso comando da eseguire.

Cliccando sul bottone di selezione multipla, esso cambia nome, permettendocosì di ritornare alla selezione singola. L’area di selezione, intanto, rimane identicafinché non si seleziona un dispositivo. A quel punto, tutti i dispositivi di tipo diversodiventano “opachi” e non sono più selezionabili.

Per renderli nuovamente selezionabili bisogna de-selezionare tutto (cliccando nuo-vamente sui dispositivi già selezionati) o cliccare sul pulsante di selezione singola.Queste funzionalità di selezione non sono altro che un’estensione delle funzionali-tà già esistenti in Windows; pertanto possono essere classificate come “semplici daimparare”, rispettando così la linea guida 4.5.

55

Page 61: Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale

5 – Progettazione e implementazione

Inoltre, nel caso in cui siano presenti molti dispositivi all’interno di una stanza,viene introdotta una scrollbar, anch’essa comandabile con l’eye-tracking.

Cliccando su un dispositivo, poi, nell’area di comando vengono visualizzati:

• il nome del dispositivo;

• lo stato del dispositivo, rappresentato tramite icona e tramite etichetta ditesto;

• i bottoni per comandare il dispositivo.

• il nome della stanza in cui ci si trova;

• il pulsante “Go out! ”, per uscire dalla stanza e ritornare alla planimetria dellacasa.

La scelta di avere un dispositivo rappresentato in forma testuale e in forma graficaderiva dal fatto che è più semplice e intuitivo riconoscere lo stato di un dispositivodalla sua immagine; in caso, però, di incomprensione, avere un’etichetta di testo cheriassuma le stesse informazione diventa essenziale. Inoltre, offre i requisiti per rispet-tare la linea guida 4.4 (“usare colori, icone e testo per evidenziare un cambiamentodi stato”).

Si immagini, ora, di voler comandare l’attuatore che controlla l’apertura e lachiusura di una porta. In particolare, si vuole aprire questa porta. Una voltaselezionato l’attuatore in questione, nell’area di controllo appare quanto visualizzatonella figura 5.8 (a).

Come si può vedere dalla figura, l’unico bottone selezionabile è “Open”: nonavrebbe infatti senso cercare di chiudere una porta già chiusa.

Agendo sul bottone “Open”, si può vedere, grazie alla figura 5.8 (b), che essodiventa impossibile da selezionare, mentre è selezionabile il bottone “Close”; inoltre,il nuovo stato aggiorna immediatamente l’icona della porta e la sua etichetta ditesto. Allo stesso tempo, vengono anche aggiornate le icone presenti nell’area diselezione e, tornando alla planimetria della casa, anche la miniatura lì presente.

Infine, il sintetizzatore vocale annuncia il cambiamento di stato e nell’area dinotifica compare un elemento che indica che proprio quella porta è stata aperta,come è possibile vedere in figura 5.9.

Questa funzionalità rispetta le linee guida 4.4, citata poc’anzi; 4.3, per quantoriguarda la visualizzazione dello stato dei dispositivi; 4.1, fornendo una chiara vi-sualizzazione di ciò che accade nella casa; 3.6, permettendo di conoscere lo statocorrente di ogni dispositivo; e 3.1 poiché, data l’immediatezza delle operazioni, per-mette di rispondere agli eventi e ai comandi dell’ambiente domotico praticamentein tempo reale.

56

Page 62: Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale

5 – Progettazione e implementazione

(a) Prima: portachiusa.

(b) Poi: porta aper-ta.

Figura 5.8: Un esempio di interazione: aprire una porta

Figura 5.9: Un’esempio di notifica

La cosa interessante di questa funzionalità di aggiornamento dello stato di undispositivo, in qualunque parte dell’interfaccia esso si trovi, è quella di essere sta-ta realizzata sfruttando una caratteristica di WPF. Tale feature è implementatadall’interfaccia INotifyPropertyChanged.

Per utilizzarla è stato sufficiente ereditare tale interfaccia nella classe C# chedefinisce la struttura dati del singolo dispositivo. Dopodiché è stato necessarioaggiungere alla parte set della proprietà Img, quella cioè che contiene l’immaginedel dispositivo) la seguente stringa:

OnPropertyChanged("Img");

e, sempre nella stessa classe, il seguente metodo ed evento:

public event PropertyChangedEventHandler PropertyChanged;

protected void OnPropertyChanged(string propertyName){if(this.PropertyChanged != null)

57

Page 63: Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale

5 – Progettazione e implementazione

PropertyChanged(this, new PropertyChangedEventArgs(propertyName));}

Così facendo si è creato un evento di notifica per la proprietà Img. La stessacosa viene fatta per l’immagine che compare nell’area di notifica e per la stringa cherappresenta lo stato del dispositivo nell’area di comando.

Quando si verifica un cambiamento di stato di un dispositivo, ogni controlloXAML che prende il proprio contenuto da quella proprietà, ovunque esso sia, siaggiorna automaticamente, come se eseguisse un refresh su se stesso.

Questa funzionalità, insieme al comportamento dell’area di comando quando undispositivo viene selezionato e al comportamento dell’area di notifica, è comune aquasi tutti i tab e, pertanto, non verrà ripresa nel seguito.

5.2.2 Entertainment

Questo tab si potrebbe considerare di tipo sperimentale: esso, infatti, contiene idispositivi legati allo svago e al divertimento, come i media center, che hanno lacaratteristica di avere molti stati e molti comandi disponibili.

Tali dispositivi, però, non sono supportati dall’attuale versione di DogOnt epertanto le sue funzionalità si sono sviluppate senza poterle sperimentare attraversoDOG.

La sua area di selezione mostra, come nei tab precedenti, la planimetria dellacasa con le miniature dei dispositivi distribuiti nelle varie stanze. Se una stanza noncontiene dispositivi, selezionandola, sarà possibile visualizzare solo la sua descrizione.

Se, invece, ne contiene almeno uno, sarà possibile entrare nella stanza. In questocaso, a differenza dei tab precedenti, se è presente un solo dispositivo non lo si potràcontrollare direttamente senza accedere alla stanza, proprio per il fatto che questidispositivi hanno molteplici comandi possibili.

Entrando nella stanza, quindi, si visualizzano i dispositivi in essa contenuti.Selezionando un dispositivo, nell’area di comando verrà visualizzato solo un pulsanteper uscire dalla stanza mentre compariranno, nell’area di selezione, altre icone: esserappresentano i modi in cui ogni comando è raggruppato con quelli a lui simili.Per esempio, riferendosi a figura 5.10, i comandi per controllare l’esecuzione deiCD inseriti in un media center sono rappresentati con un’icona apposita e separatida quelli per controllare l’esecuzione degli MP3, sempre attraverso lo stesso mediacenter.

Selezionando una di queste icone-gruppo, nell’area di comando compariranno isingoli comandi che si potranno impartire.

Questo è necessario poiché, a causa dell’elevato numero di comandi possibili, essinon potrebbero essere visualizzati tutti nell’area di comando con una dimensionesufficiente a essere selezionati attraverso il tracciamento dell’occhio.

58

Page 64: Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale

5 – Progettazione e implementazione

Figura 5.10: Caratteristica di “Entertainment”

5.2.3 Temperature

Nel tab “Temperature”, è possibile gestire il sistema di riscaldamento della casa,agendo sulla temperatura dell’intera casa, di gruppi di camere o di una singolastanza.

Il tab si apre mostrando nell’area di selezione la planimetria della casa. A diffe-renza del solito, però, essa non contiene la miniatura dei dispositivi né, selezionandouna stanza, è possibile entrarvi per comandare i dispositivi al suo interno.

Figura 5.11: Esempio di come viene indicata la temperatura di una stanza, in“Temperature”

59

Page 65: Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale

5 – Progettazione e implementazione

Essa mostra, semplicemente, un quadratino nell’angolo in basso a destra di ognisingola stanza; in questo quadratino è rappresentata la temperatura impostata al-l’interno della stanza o, se il riscaldamento è spento, uno sfondo di colore rosso (fig.5.11).

Selezionando una stanza, pertanto, è possibile comandare il termosifone o ildispositivo di riscaldamento di quella stanza direttamente tramite l’area di comando.Comandi possibili possono essere “On”, “Off” e “Set”, che permette di impostare latemperatura all’interno della camera, scegliendo tra valori compresi tra 15 e 26 gradi.

La scelta di tale valore da parte dell’utente avviene mostrando, a centro schermo,un’altra finestra, bloccante rispetto a quella principale di DOGeye, che contiene unbottone per ogni valore impostabile e il pulsante Cancel nel caso in cui non si vogliafare alcuna modifica alla temperatura.

Nell’area di selezione, inoltre, sono disponibili due pulsanti, uno predisposto perla selezione multipla delle stanze e uno per selezionarle tutte, in modo da poterimpostare la temperatura dell’intera casa in un colpo solo, come mostrato in figura5.12.

Figura 5.12: Esempio di come si imposta la temperatura del riscaldamento di tuttala casa

60

Page 66: Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale

5 – Progettazione e implementazione

5.2.4 Security e gli allarmi

Il tab “Security” è, nuovamente, un tab sperimentale in quando si occupa di gestiregli impianti di allarme (antifurto, anti-incendio, sensore di fumo e così via) dellacasa e di fornire all’utente un allarme nel caso in cui uno di questi impianti vengaazionato, per esempio perché c’è una fuga di gas in una stanza. Attualmente, però,DOG non è in grado di gestire alcun tipo di allarme, quindi, anche in questo caso,sono state adottate soluzioni che non è stato possibile verificare se non agendo inlocale all’interno di DOGeye.

Figura 5.13: Il tab “Security”

La selection area di questo tab mostra, come il solito, la planimetria della casa,indicando eventuali sistemi di allarme presenti nelle stanze. Tali sistemi possonoessere comandabili da DOGeye oppure no, in base al dispositivo analizzato: unsensore di rilevazione per le fughe di gas sarà sempre attivo e quindi non potrà esserecomandato, mentre un impianto antifurto necessiterà di essere attivato quando gliabitanti della casa lasciano l’abitazione e disattivato al loro ritorno.

Inoltre, essendo questo un tab che si propone di gestire la sicurezza all’internodella casa, esso è predisposto per effettuare lo streaming video di ciò che capita nellevarie stanze, a patto che la stanza venga selezionata dalla planimetria della casa eche contenga una videocamera predisposta a questo scopo.

61

Page 67: Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale

5 – Progettazione e implementazione

Questa funzionalità può essere utile soprattutto quando viene scatenato un al-larme: l’utente può così verificare cosa sta capitando all’interno della stanza eintraprendere l’azione più consona alla situazione.

Questo tab, pertanto, dopo aver selezionato una stanza che contiene un dispo-sitivo di sicurezza non comandabile (un sensore per la rivelazione di fumo) e lavideocamera per lo streaming, appare come mostrato in figura 5.13.

Inoltre, cliccando sopra il riquadro contenente lo streaming video, esso verràallargato a tutto schermo, permettendo così all’utente di osservare con più dettagliociò che accade nella stanza.

Questa stessa funzionalità viene anche utilizzata di default quando scatta unallarme. Per semplicità, si consideri il seguente esempio: l’utente si trova in cuci-na e vuole comandare un dispositivo elettrico che si trova nel corridoio della suaabitazione.

Pertanto, accede a DOGeye, va nel tab “Electric Device” e seleziona la stanza cherappresenta il corridoio. A quel punto, però, scatta un allarme (figura 5.14). L’ope-razione che sta eseguendo l’utente viene interrotta, in quanto l’allarme ha prioritàmaggiore (linea guida 3.3) e compare una finestra in primo piano, accompagnata daun suono di allarme e dalla presenza, nell’area di notifica, del messaggio che indical’attivazione di un sensore di fumo; tale messaggio differisce dalle normali notifichepoiché è colorato di rosso.

Figura 5.14: Esempio di gestione di un allarme

62

Page 68: Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale

5 – Progettazione e implementazione

Questa funzionalità, introdotta in questo modo, rispetta la linea guida 1.1, chesuggerisce di “fornire un sistema di notifiche per gli allarmi veloce, facile da capire emultimodale”: essa è veloce, semplice e coinvolge modalità di allarme diverse, quellaaudio e quella visuale.

Analizzando un po’ più nel dettaglio la figura 5.14, si può notare che essa ècomposta di:

• l’indicazione di che dispositivo ha scatenato l’allarme e della posizione in cuisi trova (in questo caso, “SmokeSensor in livingroom”);

• lo streaming video della stanza, se disponibile;

• due pulsanti, uno per chiamare i soccorsi e uno per annullare l’allarme perché,per esempio, si è visto che il sensore è scattato a causa di un malfunzionamento.

È importante avere solo due pulsanti perché un utente, in una situazione diallarme, ha bisogno di poche e chiare opzioni per gestire l’emergenza, onde evitaredi agitarsi e non sapere che azione intraprendere. Inoltre, questo fatto è anchesuggerito dalla linea guida 1.2.

Quando l’utente decide per una delle due azioni messe a disposizione dalla fi-nestra di notifica dell’allarme, il sistema di sintesi vocale ripete la scelta effettuatae chiude la finestra, permettendo così all’utente di ritornare a utilizzare DOGeyeesattamente nello stesso punto in cui lo aveva lasciato.

Nel caso in cui, invece, l’utente non riesca a decidere quale azione intraprendereper rispondere all’allarme, perché si agita o perché perde il controllo dell’eye-tracker,DOGeye è predisposto per prendere la decisione più sicura al suo posto, chiudendopoi la finestra di allarme: nell’esempio, allo scadere di un certo time-out, il sistemachiamerà i soccorsi e lo notificherà all’utente attraverso la sintesi vocale. Quest’altrafunzionalità rispetta la linea guida 1.3.

5.2.5 Scenarios

Anche il tab “Scenarios” rientra nella categoria dei tab sperimentali, in quanto DOGnon supporta ancora questo tipo di caratteristica.

Uno scenario, come già accennato in precedenza, è un elenco di attività riguar-danti determinati dispositivi domestici che possono venire attivati o disattivati tuttiinsieme in un certo momento della giornata, in base alla scelta dell’utente.

Questo tab fornisce una prima risposta alla linea guida 3.5 che raccomanda diinserire nell’interfaccia utente la possibilità di creare, modificare e cancellare scenari.

In questo caso, DOGeye gestisce solo dei semplici scenari: permette, cioè, disalvare su un file testuale l’attuale configurazione dei dispositivi della casa, di as-segnargli un nome e di poterla caricare ed eseguire ogni qual volta l’utente lodesideri.

63

Page 69: Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale

5 – Progettazione e implementazione

Una gestione più completa degli scenari, però, dovrebbe prevedere la possibilitàdi salvare solo alcuni dispositivi a scelta e non tutti quelli della casa, la possibilità dieseguire automaticamente uno scenario a un orario prestabilito e quella di poterneinterrompere l’esecuzione.

Non essendo DOG predisposto per questo tipo di funzionalità, tutto questo nonè possibile se non in simulazione: pertanto, si è preferito mostrare solo una ver-sione semplificata, per evitare di produrre una certa quantità codice che, alla fine,andrebbe buttato.

5.2.6 Everything Else

All’inizio di questo capitolo, si accennava al fatto che l’informazione che permettevadi assegnare ogni dispositivo al corretto tab è memorizzata in un file di configurazionetestuale.Tale file può essere così composto:

SimpleLamp=HMButton=HMDoorActuator=HMShutterActuator=HMDimmerLamp=HM

Plug=EDCoffeeMaker=ED

GasHeather=Temp

SmokeSensor=SD

La stringa che si trova a sinistra del segno di uguale rappresenta il tipo di di-spositivo, mentre la stringa che si trova a destra dell’uguale indica il tab in cui taledispositivo va inserito.

Si supponga, ora, di collegare alla casa un nuovo dispositivo e di dimenticarsidi aggiungerlo a tale elenco: per quanto detto finora, questo nuovo dispositivo nonverrebbe visualizzato in nessun tab.

Il tab “Everything Else” nasce proprio per rimediare a questa dimenticanza:esso colleziona tutti i dispositivi che non appartengono a nessuno degli altri tab, seesistono.

Esso mostra la planimetria della casa con, all’interno di ogni stanza, gli eventualidispositivi che non compaiono nel file di configurazione, fornendo anche la possibi-lità di comandarli e di vederne lo stato. Non offre, però, tecniche più avanzate diselezione, come la selezione multipla, poiché è da intendersi come una collocazione

64

Page 70: Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale

5 – Progettazione e implementazione

provvisoria: il dispositivo, infatti, dovrebbe essere collocato al più presto nel tabcorretto.

5.2.7 Settings

Il tab “Settings”, infine, presenta le impostazioni necessarie a DOGeye, a DOG eall’ETU-Driver. Esso è il tab selezionato di default quando viene avviata l’interfacciautente.

In particolare, esso contiene:

• l’indirizzo IP del server su cui si trova DOG;

• l’indirizzo IP del listener, cioè della macchina su cui è in esecuzione DOGeye;

• l’impostazione della durata del dwell time;

• un pulsante per accedere alle opzioni dell’ETU-Driver, uno per calibrare l’eye-tracker e uno per avviare il tracciamento dell’occhio;

• un pulsante per collegarsi a DOG.

Questo tab potrà contenere, in futuro, anche un campo per impostare la lingua incui si vuole visualizzare DOGeye e uno per cambiare l’aspetto visuale dell’interfaccia.

5.3 Realizzazione dell’interfaccia utenteNel paragrafo precedente, si sono mostrate le funzionalità e le caratteristiche del-l’interfaccia utente creata, indicando le motivazioni alla base di tali scelte, talvoltacitando anche le linee guida COGAIN rispettate da una certa caratteristica.

In alcune occasioni, inoltre, si è evidenziato come viene realizzata tale carat-teristica, soprattutto per sottolineare come WPF ha permesso la sua creazione inmaniera semplice.

In questo paragrafo, si abbandonerà la parte progettuale e si analizzeranno gliaspetti più generali o rilevanti dell’implementazione di DOGeye.

Come primo aspetto, si considerino gli elementi grafici dell’interfaccia: icone deitab, aspetto dei pulsanti e icone dei dispositivi.

Tali elementi sono stati realizzati con il software Microsoft Expression Design, unprogramma di grafica vettoriale di cui si parlerà nell’Appendice A. Tale programmapermette di esportare gli oggetti che si producono in diversi formati: JPEG, PNGe così via.

Tali formati grafici, però, non sono vettoriali, cioè “sgranano” quando vengonoingranditi. Questo è un peccato, considerando che WPF, invece, supporta la grafica

65

Page 71: Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale

5 – Progettazione e implementazione

vettoriale. Tale programma, pertanto, permette di esportare gli oggetti creati anchein formato XAML, permettendo così di sfruttare le funzionalità di grafica vettorialedi WPF.

Tali oggetti XAML, dopo un paio di modifiche, possono venire utilizzate all’in-terno del programma come se fossero delle comune immagini. A titolo di esempioe per delineare alcune funzionalità di WPF utilizzate, si riporta il codice XAML diuno di essi, particolarmente semplice ma completo:

<ResourceDictionary xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"xmlns:PresentationOptions="http://schemas.microsoft.com/winfx/2006/xaml/

presentation/options"xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"mc:Ignorable="PresentationOptions">

<DrawingImage x:Key="CloseDoorActuator"PresentationOptions:Freeze="True"><DrawingImage.Drawing><DrawingGroup><DrawingGroup.Children><ImageDrawing ImageSource="DoorActuator_files/border0.png"Rect="9,52,31,665"/>

<ImageDrawing ImageSource="DoorActuator_files/border1.png"Rect="293,52,33,665"/>

<ImageDrawing ImageSource="DoorActuator_files/border2.png"Rect="9,18,317,38"/>

<GeometryDrawing Brush="#FFDDC3A2" Geometry="F1 M 39.7639,711.333L43.764,711.333L 43.764,57.3334L 39.7639,57.3334L

39.7639,711.333 Z "/><GeometryDrawing Brush="#FFDDC3A2" Geometry="F1 M 290.5,711.333L

294.5,711.333L 294.5,57.3335L 290.5,57.3335L 290.5,711.333 Z "/>

<GeometryDrawing Brush="#FFDDC3A2" Geometry="F1 M 39.7779,54.3333L294.778,54.3333L 294.778,57.3333L 39.7779,57.3333L

39.7779,54.3333 Z "/><GeometryDrawing Brush="#FF52372C" Geometry="F1 M 45,58.6667L

287.667,58.6667L 287.667,714.667L 45,714.667L 45,58.6667 Z "/><ImageDrawing ImageSource="DoorActuator_files/handle3.png"Rect="49,395,15,16"/>

<ImageDrawing ImageSource="DoorActuator_files/handle4.png"Rect="50,366,46,12"/>

</DrawingGroup.Children>

66

Page 72: Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale

5 – Progettazione e implementazione

</DrawingGroup></DrawingImage.Drawing>

</DrawingImage></ResourceDictionary>

Il codice di esempio è quello che rappresenta lo stato di porta chiusa. Il suoelemento radice, ResourceDictionary, indica che tale elemento grafico è inserito inun dizionario, così da essere disponibile all’intera applicazione attraverso la chiaveCloseDoorActuator.

Una prima caratteristica di questa immagine è rappresentata dalla proprietàFreeze="True": tale proprietà indica che l’immagine non è modificabile dopo ilsuo primo utilizzo e, pertanto, XAML ne ottimizza l’uso e l’inserimento all’internodell’interfaccia utente.

L’immagine creata attraverso XAML è del tipo DrawingImage, uno dei tanti tipidi immagini disponibili in WPF. Essa specifica la proprietà Drawing che permettedi disegnare un solo oggetto grafico al suo interno. Avendo bisogno di rappresentarediversi oggetti grafici, li si unisce in un DrawingGroup.

I figli di tale DrawingGroup, possono essere oggetti geometrici, cioè compostida linee, punti, curve, ecc., e immagini bitmap. Nel caso considerato, sono pre-senti cinque immagini di formato PNG (ImageDrawing) e tre oggetti geometrici(GeometryDrawing), rappresentati da un colore e da un insieme di coordinate chene definiscono la forma.

Si è, però, detto di preferire l’utilizzo di XAML invece di immagini bitmap comequelle in formato PNG perché XAML è vettoriale. Nel codice d’esempio, d’altraparte, si vedono cinque immagini PNG e, quindi, verrebbe da pensare che si perdonoi vantaggi di utilizzare XAML.

Non è così. Utilizzando immagini bitmap all’interno di una DrawingImage siottiene comunque una scalabilità dell’immagine maggiore rispetto all’utilizzare l’im-magine PNG direttamente all’interno dell’interfaccia utente.

Inoltre, viene utilizzata un’immagine di formato PNG perché è l’unica, tra quellesupportate da WPF, che permette di non definire uno sfondo nell’immagine: inquesto modo, l’immagine si può utilizzare su qualsiasi colore di sfondo l’applicazioneutilizzi.

Quasi tutti gli elementi grafici utilizzati in DOGeye sono realizzati in questomodo: alcuni sono una combinazione di immagini PNG e di oggetti geometrici, altrisono solo oggetti geometrici (come i bottoni, per esempio) e altri ancora, sono soloimmagini PNG utilizzate però all’interno di una DrawingImage.

Questa differenza nasce, da una parte, dalla modalità in cui Expression Designesporta e, dall’altra, dalla presenza di dispositivi nella casa la cui rappresentazionegrafica era troppo “complicata” e, pertanto, si è preferito utilizzare immagini giàesistenti reperibili su Internet.

67

Page 73: Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale

5 – Progettazione e implementazione

Si consideri ora l’architettura generale di DOGeye, visibile in figura 5.15.

Figura 5.15: L’architettura generale di DOGeye

Essa è composta da vari moduli, interconnessi tra di loro e con l’esterno. Neiprossimi sotto-paragrafi si tratterà del layout dei moduli realizzati in XAML, dell’in-terazione con l’ETU-Driver (modulo Eye based interaction), con DOG (utilizzandoil modulo DOGleash, già fornito) e, infine, si parlerà della Common Library.

5.3.1 Layout

Il layout di più alto livello di DOGeye, la Main Window di figura 5.15, è statorealizzato utilizzando tre pannelli di WPF:

• DockPanel, introdotto da WPF;

• Grid, anch’esso introdotto da WPF;

• TabPanel, già esistente in Windows Forms, che è utilizzato per implementareil controllo TabControl.

Una panoramica sui principali pannelli di XAML è disponibile in tabella 5.2.Avendo XAML una struttura di tipo gerarchico, il layout generale di DOGeye è

realizzato nel seguente modo:

<Window>

<DockPanel>

<Grid/>

68

Page 74: Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale

5 – Progettazione e implementazione

<TabControl/>

</DockPanel>

</Window>

Il pannello DockPanel è il pannello al livello gerarchico più alto; questo pannellopermette di effettuare il docking degli elementi a un intero lato del pannello, even-tualmente allargandoli per riempire la sua larghezza o altezza. La posizione deipannelli e dei controlli figli viene assegnata tramite la proprietà Dock, che può averei seguenti valori:

Top - posiziona l’elemento figlio attaccato al lato superiore del pannello;

Left - posiziona l’elemento figlio attaccato al lato sinistro del pannello;

Right - posiziona l’elemento figlio attaccato al lato destro del pannello;

Bottom - posiziona l’elemento figlio attaccato al lato inferiore del pannello.

Per realizzare il layout di DOGeye, Grid è stato posizionato sul lato inferioredell’interfaccia (e contiene l’area di notifica), mentre il controllo TabControl occupatutto il resto dello spazio.

Il pannello Grid è, forse, il pannello più utilizzato in XAML perché è molto poten-te e versatile: infatti, opportunamente configurato, permette di realizzare l’aspettodi tutti gli altri pannelli principali di WPF. Visual Studio, addirittura, lo usa comepannello di default quando vengono creati nuovi progetti WPF.

Questo pannello permette di disporre i suoi figli in una disposizione multi-rigae multi-colonna, assomigliando molto a una tabella e, in particolare, al controlloTable di HTML. Pertanto, esso può essere utilizzato per ospitare figli in uno spaziounico, così come disporli in righe e colonne pre-assegnate e di dimensioni a sceltadel programmatore.

In DOGeye, questo pannello contiene la ListBox, opportunamente ri-stilizzata,che si occupa di gestire le notifiche e gli allarmi dei dispositivi; inoltre, contiene ilbottone con il quale l’utente può far suonare un allarme, in caso di necessità.

Il controllo TabControl, anch’esso con uno stile e un template personalizzato, peradattarsi alle caratteristiche dell’interfaccia e dell’interazione con l’eye-tracker, è il“cuore” del layout generale perché contiene tutti i tab di DOGeye, senza i quali nonci sarebbe alcun contenuto nell’interfaccia.

Esso è composto da nove TabItem, uno per ogni tab più uno vuoto e invisibileper separare “Settings” dagli altri tab. Ogni TabItem ha un header che è un oggettocomposto da un’icona e da un’etichetta di testo, mentre il loro contenuto è costituito

69

Page 75: Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale

5 – Progettazione e implementazione

da una pagina XAML, racchiusa in un controllo di tipo Frame, uno dei controlli WPFche può ospitare una pagina.

La scelta è ricaduta sul controllo Frame poiché altri controlli fornivano funziona-lità di navigazione simili a quelle utilizzate nei browser web che non erano necessarieper realizzare DOGeye.

Tabella 5.2: I principali pannelli presenti in XAML

Nome Descrizione

Canvas È il pannello più semplice. Si possono posizionare gli ele-menti figli dovunque si voglia, specificando la distanza dalmargine superiore e laterale del pannello.

StackPanel È un pannello abbastanza utilizzato. Come suggerisce ilsuo nome, esso dispone i suoi figli a stack, impilandoliorizzontalmente o verticalmente.

WrapPanel Simile allo StackPanel ma, oltre a impilare i suoi figli, con-sente anche di disporli su più righe o colonne, quando si èesaurito lo spazio a disposizione.

DockPanel Permette un ancoraggio degli elementi suoi figli lungo i suoilati.

Grid È il pannello più versatile e può simulare il comportamentodi tutti gli altri. Dispone i suoi figli in celle organizzate inrighe e colonne impostate dal programmatore.

5.3.2 Layout dei tab

Ogni tab, quindi, è compreso in una pagina a sé stante. Una pagina, si può dire,è la controparte dell’elemento Window, in quanto svolge una funzione molto simile,solo che può anche essere utilizzata come suo figlio. Inoltre, è l’elemento radice cheviene usato per realizzare applicazioni Silverlight e, quindi, la sua parte XAML èvisualizzabile all’interno di un browser web.

Infatti una pagina, come una finestra, è composta da due file: un file XAML eun file di code-behind, scritto in C#, in questo contesto.

Il layout dei tab di DOGeye, però, varia sensibilmente in base alle caratteristichedel tab stesso; qui di seguito si riporterà la struttura che quasi tutti i tab hanno incomune, tralasciando le funzionalità più avanzate o peculiari del singolo elemento.

Il layout generale di un tab, quindi, rappresentato gerarchicamente in XAML,risulta essere:

<Page>

70

Page 76: Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale

5 – Progettazione e implementazione

<DockPanel>

<Grid DockPanel.Dock="Right"/>

<Grid DockPanel.Dock="Left"/>

</DockPanel>

</Page>

Come probabilmente era facile intuire, la pagina inizia con un altro DockPanelche, questa volta, definisce due aree:

• quella destra, contenente una Grid, che ospita una serie di altri pannelli, oppor-tunamente resi invisibili in base alla situazione, per visualizzare la commandarea;

• quella sinistra, che contiene le ListBox che rappresentato rispettivamente laplanimetria della casa e l’elenco dei dispositivi.

È il caso, ora, di spendere alcune parole sulla ListBox che contiene la planimetriadella casa che, come è possibile vedere dalle immagini dell’interfaccia presentate nelparagrafo precedente, non ha più l’aspetto di una ListBox classica.

Per realizzarla, è stato modificato pesantemente lo stile e il template della ListBoxche, in genere, rappresenta i suoi elementi di solo testo ordinati verticalmente, dal-l’alto in basso. In questo caso, c’era la necessità di poter collocare liberamente nellaListBox i suoi elementi, visto che le stanze della casa hanno una posizione prestabi-lita; inoltre, ogni stanza doveva essere rappresentata da una serie di immagini e dielementi di testo.

Innanzitutto, è stato impostato uno stile per l’intera ListBox, sempre all’internodi un dizionario XAML:

<Style x:Key="HouseDesign" TargetType="{x:Type ListBox}"><Setter Property="Background" Value="Transparent"/><Setter Property="BorderBrush" Value="Transparent"/><Setter Property="ScrollViewer.HorizontalScrollBarVisibility"Value="Disabled" />

<Setter Property="ItemsPanel"><Setter.Value><ItemsPanelTemplate><Canvas Margin="10" />

</ItemsPanelTemplate></Setter.Value>

71

Page 77: Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale

5 – Progettazione e implementazione

</Setter><Setter Property="ItemContainerStyle"Value="{DynamicResource RoomDesign}"/>

</Style>

In questa porzione di codice viene:

• creato lo stile la cui chiave nel dizionario è HouseDesign;

• assegnato uno sfondo trasparente alla ListBox che si vuole stilizzare;

• assegnato un bordo trasparente alla ListBox;

• disabilitata la ScrollBar orizzontale, poiché si vuole che la casa venga rappre-sentata per intero nello spazio a disposizione;

• assegnato il pannello Canvas come pannello da utilizzare per ospitare gli ele-menti della ListBox;

• assegnato lo stile degli elementi della ListBox, dicendo di recuperare dal dizio-nario lo stile che ha come chiave RoomDesign.

Lo stile del singolo elemento della ListBox, quindi, risulta essere:

<Style x:Key="RoomDesign" TargetType="{x:Type ListBoxItem}"><Setter Property="Template"><Setter.Value><ControlTemplate TargetType="{x:Type ListBoxItem}"><Border x:Name="ItemBorder"CornerRadius="1"Background="Transparent"BorderBrush="{Binding Source={StaticResource RoomWall},Path=BorderBrush}"

BorderThickness="{Binding Source={StaticResource RoomWall},Path=BorderThickness}" >

<ContentPresenter /></Border><ControlTemplate.Triggers><Trigger Property="IsSelected" Value="true"><Setter TargetName="ItemBorder" Property="Background"Value="CornflowerBlue" />

</Trigger></ControlTemplate.Triggers>

</ControlTemplate></Setter.Value>

</Setter>

72

Page 78: Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale

5 – Progettazione e implementazione

<Setter Property="Canvas.Top" Value="{Binding Path=PosY}"/><Setter Property="Canvas.Left" Value="{Binding Path=PosX}" />

</Style>

In quest’altra porzione di codice, oltre a definire lo stile che avrà chiave Room-Design, viene:

• definito un nuovo template, cioè vengono indicati gli elementi grafici di cui ècomposto l’oggetto contenuto nella ListBox, che prende il nome di ListBoxItem;tale template:

– è composto da un bordo, con gli angoli leggermente arrotondati (proprie-tà CornerRadius), con lo sfondo trasparente (in modo da rendere l’interastanza selezionabile), con un colore e uno spessore definiti nella risor-sa RoomWall; all’interno di questo bordo dovranno essere visualizzati glielementi della ListBox (parola chiave ContentPresenter);

– ha un trigger, che specifica alcuni comportamenti da effettuare quandouna determinata proprietà ha un certo valore; in questo caso, quando unListBoxItem viene selezionato, bisogna cambiare il colore di sfondo datrasparente a CornflowerBlue;

• definita la distanza dal bordo superiore di ogni ListBoxItem, in base al valorePosY, impostato dalla logica di DOGeye;

• definita la distanza dal bordo sinistro di ogni ListBoxItem, in base al valore diPosX, impostato anch’esso dalla parte di logica di DOGeye.

Realizzare tutto questo in una tecnologia precedente a XAML voleva dire definirecompletamente un nuovo controllo utente, producendo decisamente molto più codiceche, di conseguenza, produce molte più possibilità di errore e di bug.

5.3.3 Interazione con DOG

L’interazione di DOGeye, come già detto, avviene attraverso il livello delle API edè realizzata con tecnologia XML-RPC. A sua volta DOGeye, per utilizzare XML-RPC, interagisce con delle API di comunicazione che prendono il nome di DOGleash,realizzate dal gruppo di ricerca e-lite; tale libreria è stata lievemente modificata perquesto progetto solo per introdurre alcune funzionalità, come la planimetria dellacasa letta da file XML.

Per interagire con DOG non si utilizza XAML ma il suo code-behind ; in partico-lare, si possono individuare due momenti in cui DOG e DOGeye comunicano:

• una fase iniziale, in cui DOG comunica all’interfaccia le informazioni sulla casae sui dispositivi che essa contiene;

73

Page 79: Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale

5 – Progettazione e implementazione

• una fase operativa, in cui DOG comunica all’interfaccia eventuali eventi chesono capitati all’interno della casa (accensione di una luce, per esempio) eDOGeye comunica a DOG, invece, che l’utente vuole effettuare qualche tipodi operazione sui dispositivi domotici.

Nella prima fase, DOGeye crea un oggetto di tipo DogHouse che aprirà la con-nessione con DOG e riceverà le informazioni sulle varie stanze contenute all’internodella casa, con i loro dispositivi; inoltre si registrerà come listener per ricevere edinviare informazioni sugli stati e sui comandi da impartire ai vari dispositivi:

namespace DOGeye{

public partial class Window1 : Window{

internal Hashtable rooms = new Hashtable();internal DogHouse houseClient;internal Hashtable deviceClasses = new Hashtable();...

public Window1(){

//Write house client object from config filehouseClient = new DogHouse();

//Connection to DOG...houseClient.connectToDog();rooms = houseClient.Rooms;deviceClasses = houseClient.DeviceClasses;houseClient.statusUpdateListers += new

DogHouse.statusUpdateDeviceListenerDel(houseClient_statusUpdateListers);

...}...

}}

La seconda fase si realizza con la definizione del metodo di listener e con unmetodo di UpdateCallBack che provvederà a cambiare gli stati dei dispositivi nelcaso in cui qualcuno di esso venga comandato e, nello stesso tempo, a inserire ilcambiamento di stato nell’area di notifica dell’interfaccia:

namespace DOGeye{

public partial class Window1 : Window

74

Page 80: Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale

5 – Progettazione e implementazione

{...//The listener for the command given from DOG or from the housevoid houseClient_statusUpdateListers(Device[] devices){

foreach (Device dev in devices){

foreach (Room room in houseClient.Rooms.Values){

foreach (Device de in room.Devices.Values){

if (de.Uri.Equals(dev.Uri)){

//Take the modified device and set the newproperties in the current device

de.State = dev.State;server_statusUpdateLister(de);

}}

}}

}

//Allow to call the UI elements from the houseClient listenerdelegate void SetUpdateCallback(Device current);

void server_statusUpdateLister(Device current){

if (this.Dispatcher.Thread != System.Threading.Thread.CurrentThread)

{this.Dispatcher.BeginInvoke(DispatcherPriority.Normal, new

SetUpdateCallback(server_statusUpdateLister), current);}else{

//Pass in this way the device from the previous methodDevice dev = current;Security sec = Security.Content as Security;

if (TypeList[dev.Type].Equals("ED")){

75

Page 81: Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale

5 – Progettazione e implementazione

ElectricDevice ed = ElectricDevice.Content asElectricDevice;

ed.UpdateCallBack(dev);}else if ...

//Update the history events’ list (FIFO)...AddToLog(dev);

}}...

}}

Ogni tab, poi, definirà un proprio metodo di “UpdateCallBack” per gestire ilcambiamento di stato dei propri dispositivi in base alle loro funzionalità.

5.3.4 Interazione con l’ETU-Driver

LaMain Window, che è la classe principale di DOGeye, interagisce con l’ETU-Driverattraverso un evento, richiamato subito dopo aver invocato il metodo InitializeComponent, necessario per inizializzare gli elementi XAML con cui è stata costruita l’interfaccia:

this.Loaded += new RoutedEventHandler(LoadETUDriver);

Tale evento dice non solo che l’albero logico dell’applicazione è costruito e ini-zializzato, ma anche che il layout deve agire su di esso, che i dati sono stati tutticollegati, che è stato connesso a una superficie di rendering (la finestra) e che è sulpunto di essere renderizzato completamente.

Senza questa dichiarazione, l’ETU-Driver porta il programma a non partire:essendo, infatti, realizzato in oggetti COM e utilizzando internamente la libreriaGDI+, necessita delle informazioni di rendering prima di poter iniziare a operare.

Il metodo LoadETUDriver non fa altro che occuparsi dell’interfacciamento diDOGeye con l’ETU-Driver principalmente mediante i due seguenti metodi, che sitrovano in un modulo apposito:

public ETUClass(Window actual, int time)private void iETUDriver_OnDataEvent (EiETUDGazeEvent aEventID,

ref int aData, ref int aResult)

• ETUClass(): questo metodo, in realtà, è il costruttore della classe che contienel’interazione con l’ETU-Driver; esso si occupa dell’inizializzazione del driveruniversale e della lettura delle impostazioni dal file di configurazione (se esiste);

76

Page 82: Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale

5 – Progettazione e implementazione

• iETUDriver_OnDataEvent(): è il metodo che si occupa di ricevere gli eventiinviati dal driver e di elaborarli.

aEventID rappresenta il tipo di evento e può essere di tipo geFixationStart(l’eye-tracker ha individuato l’inizio di una fissazione), geFixationUpdate (lafissazione sta continuando), geFixationEnd (l’eye-tracker ha individuato la fi-ne della fissazione corrente), geSample (l’eye-tracker ha inviato un sample) ,geBlinkStart (inizio di un blink) e geBlinkEnd (fine di un blink).

Il dwell time viene implementato effettuando un controllo sulla durata dellafissazione grazie all’evento geFixationUpdate. Gli altri eventi, pertanto non vengonointercettati in quanto non necessari ai fini del progetto.

Ogni evento fornisce le coordinate a cui si è verificato, utilizzando internamentela libreria GDI+, e queste vengono utilizzate in modo opportuno per capire cheoggetto si sta guardando e intraprendere le azioni collegate a esso.

Per farlo, si utilizzava la funzione Windows Forms ClientRectangle, con la qualesi otteneva il rettangolo che contiene un determinato controllo utente, e si verificavache la posizione del punto fissato con lo sguardo fosse all’interno del rettangolo cosìottenuto.

Purtroppo, in WPF tale funzione non esiste più. Pertanto, vista la grande impor-tanza di tale funzione, ho provveduto a scriverne una nuova versione, chiamandolaGetBoundingBox():

private Rect GetBoundingBox(FrameworkElement element, WindowcontainerWindow)

{GeneralTransform transform = element.TransformToAncestor(

containerWindow);Point topLeft = transform.Transform(new Point(0, 0));Point bottomRight = transform.Transform(new Point(element.ActualWidth,

element.ActualHeight));return new Rect(topLeft, bottomRight);

}

Tale funzione riceve come argomenti il controllo del quale si vuole ottenere il ret-tangolo e la finestra a cui questo controllo appartiene. Essa trasforma le coordinatedel controllo, calcolandole nel sistema di coordinate del suo progenitore, la finestraappunto.

Dopodiché, in questo nuovo sistema di riferimento, calcola la posizione di duepunti: l’angolo in alto a sinistra e quello in basso a destra del controllo così trasfor-mato.

Utilizzando questi due punti, costruisce e restituisce al metodo che l’ha chiamatoil rettangolo finale che sarà proprio l’area che ci serve.

77

Page 83: Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale

5 – Progettazione e implementazione

5.3.5 Organizzazione e riusabilità del codice

Nel realizzare questa versione di DOGeye si è posta particolare attenzione a produrrecodice leggibile, ben documentato e riutilizzabile.

Per raggiungere tale scopo si è pensato a una certa modularità all’interno delprogetto, come già visto all’inizio di questo paragrafo; questo è un altro motivo percui l’utilizzo di un layout a tab si è rivelato una buona scelta.

Infatti, il contenuto di ogni tab è ospitato da una pagina XAML diversa, che haun suo file di code-behind. Inoltre, i metodi e le funzionalità in comune tra più tabsono state inserite in una classe statica che prende il nome di “Commons”. In questomodo, se si volesse creare un nuovo tab basterebbe prendere la pagina XAML di untab già esistente e utilizzarla come struttura base.

Anche l’ETU-Driver è stato collocato in una classe a sé stante, collegata allaclasse principale di DOGeye: se si decidesse, pertanto, di non utilizzare più l’ETU-Driver perché, per esempio, è stato sostituito da qualche altro componente, baste-rebbe cancellarne la classe ed eliminare una riga di codice dal code-behind dellaMain Windows di DOGeye.

In questo processo di modularizzazione, un grande aiuto è venuto dai dizionariXAML: ogni “variabile globale” utilizzata in XAML, ogni oggetto grafico, sia essoun bottone o un’icona, viene definita all’interno di un dizionario. Inserendo, poi,ogni dizionario di questo progetto all’interno di un unico dizionario che agisce dacontenitore, è possibile cambiare totalmente l’aspetto dell’applicazione, sostituendosolo questo dizionario.

Un discorso equivalente vale per i singoli elementi grafici: se si decidesse dicambiarne uno, si tratta sempre di avere a che fare con un unico documento e nondi andare a cercare all’interno di diverse classi.

78

Page 84: Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale

Capitolo 6

Risultati ottenuti

In questo capitolo si presenteranno alcuni risultati ottenuti dall’analisi dell’interfac-cia utente DOGeye. In particolare, ci si soffermerà su qualche analisi qualitativa,quantitativa e si valuterà l’interfaccia rispetto alle specifiche COGAIN presentatenel Deliverable 2.5 e riportate in maniera estesa nel capitolo 2.

6.1 Analisi qualitativa

Pur non avendo condotto dei test di usabilità, DOGeye è stata mostrata a un grupporistretto di utenti (5 persone), non omogeneo per età e per competenze.

Osservando come tali utenti interagivano con l’interfaccia, anche se attraverso ilmouse, è stato possibile ricavare alcuni risultati preliminari di tipo qualitativo.

La totalità degli utenti, innanzitutto, ha apprezzato la chiarezza e l’eleganzadell’interfaccia nel suo complesso ed è riuscita a utilizzarla senza grossi problemi.L’immediatezza dell’utilizzo si è vista soprattutto nel momento in cui dovevanointeragire con la planimetria della casa: l’accedere alle stanze tramite quel modellovisivo è stato, per tutti, una cosa assolutamente naturale.

Un po’ di spiegazione è stata necessaria per chiarire il significato e la presenzadei tab che permettono di unire la vista funzionale a quella strutturale, utilizzatacomunemente. In ogni caso, dopo una breve panoramica, quasi tutti gli utenti sonostati capaci di individuare immediatamente in quale tab si trovava un determinatodispositivo.

Una funzionalità poco usata, invece, è stata quella che permette di comandarei dispositivi in base al loro tipo, presente in “Home Management” e in “ElectricDevice” non appena si seleziona una stanza che contiene al suo interno più di undispositivo.

79

Page 85: Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale

6 – Risultati ottenuti

Infine, qualcuno ha trovato un po’ piccola la scritta che indica la luminosi-tà attualmente impostata per le lampade di tipo DimmerLamp, nel tab “HomeManagement”.

Nel complesso, quindi, l’interfaccia ha suscitato commenti positivi in quantofunzionale, abbastanza intuitiva nell’utilizzo e veloce a rispondere ai comandi datidall’utente.

6.2 Analisi quantitativaSono stati effettuati alcuni test sperimentali per verificare l’utilizzo delle risorsedel computer da parte di DOGeye, utilizzando il computer le cui specifiche sonoriportate in tabella 6.1 e utilizzando un modello della casa di medie dimensioni (cfr.Appendice B).

In particolare, si è osservato l’utilizzo di memoria RAM e del processore. Inoltre,si sono anche misurati i tempi di avvio dell’interfaccia utente.

CPU Intel Core 2 Duo (2,4 GHz)RAM 2 GBO.S. Windows 7

Tabella 6.1: Specifiche computer

Per quanto riguarda l’utilizzo di memoria RAM, si sono effettuate 10 misurazionifacendo partire l’applicazione senza caricare l’ETU-Driver e 10 misurazioni caricandoanche l’ETU-Driver, in modo da poter valutare quale sia il peso dell’interfaccia dasola e quale quello di questo componente.

I risultati, riportati in tabella 6.2, sono stati ottenuti calcolando la media delle10 misurazioni eseguite nei due casi.

Condizione Utilizzo Utilizzocon ETU-Driver senza ETU-Driver

(MB) (MB)

Avvio 22 12Caricamento primo tab 32 22Caricamento primi quattro tab 35 26

Tabella 6.2: Utilizzo della RAM da parte di DOGeye

Come si può vedere, quindi, l’utilizzo di memoria da parte di DOGeye non èmolto: basti pensare, per un raffronto, che DOG, all’avvio, richiede circa 72 MB.

80

Page 86: Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale

6 – Risultati ottenuti

La percentuale di utilizzo del processore è un dato importante da rilevare percapire l’efficienza di un programma: i risultati di tale misurazione sono visibile in ta-bella 6.3. In questo caso, la percentuale di utilizzo della CPU con e senza ETU-Driverè praticamente la stessa, pertanto non si farà questa distinzione, contrariamente aquanto si è fatto per le misurazioni sull’occupazione di memoria RAM.

Condizione Utilizzo(%)

Avvio 8-9Caricamento primo tab 7-8Cambiamento di tab 3-4

Tabella 6.3: Utilizzo della CPU da parte di DOGeye

Ovviamente, nel tempo in cui l’interfaccia utente rimane inutilizzata, cioè nonvengono eseguite operazioni né in DOGeye né nella casa, la percentuale di utilizzodel processore è quasi sempre nulla.

Anche il tempo di avvio di DOGeye non è elevato:

• con l’ETU-Driver caricato, è di circa 527 ms;

• senza ETU-Driver caricato, è di circa 310 ms.

Per fare un confronto, DOG si avvia in circa 28 secondi. . .

6.3 Valutazione rispetto alle specifiche COGAIN

Durante il capitolo 5, descrivendo le varie componenti e funzionalità dell’interfacciautente realizzata, si affermava, talvolta, che una certa caratteristica nasce da unalinea guida COGAIN o che, comunque, la rispettava.

In tabella 6.4, è possibile trovare il dettaglio e il riassunto di quali linee guidal’interfaccia rispetta in pieno, parzialmente o per niente, ricordando che l’obiettivoiniziale era quello di rispettare, per quanto le funzionalità di DOG permettessero,quelle indicazioni che erano classificate come di priorità 1, cioè quelle caratteristicheche l’interfaccia utente DEVE avere.

Quando DOGeye implementa una funzionalità che non è ancora supportata pie-namente da DOG, essa viene etichettata come supportata “parzialmente (DOG)”,per indicare che il limite al rispetto di quella linea guida è l’attuale implementazionedi DOG.

81

Page 87: Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale

6 – Risultati ottenuti

Inoltre, sempre il report D2.5 riporta altri suggerimenti che possono essere uti-lizzati per valutare questa interfaccia utente.

Essi sono la riduzione del trade-off tra la vista strutturale e la vista funzionaledell’interfaccia e la localizzazione in diverse lingue.

Per quanto riguarda il primo suggerimento, si è cercato di trovare un giustoequilibrio utilizzando entrambe le viste e strutturando l’interfaccia a due livelli ge-rarchici: uno più elevato che rappresenta la vista funzionale e uno più basso cherappresenta quella strutturale.

Per il secondo suggerimento si può dire che l’interfaccia utente è predisposta allalocalizzazione in più lingue, utilizzando i metodi semi-automatici esposti da WPFe Visual Studio o utilizzando altre modalità che, però, sono da creare partendo dazero o utilizzando qualche funzionalità di WPF.

Tabella 6.4: Valutazione di DOGeye secondo le linee guida COGAIN

Descrizione Priorità Rispettata?

1.1 Fornire un sistema di notifi-che per gli allarmi veloce, facileda capire e multimodale.

1 Sì, utilizzaaudio, video e testo

1.2 Fornire all’utente solo pochee chiare opzioni per gestire eventidi allarme.

2 Sì, ne utilizza due

1.3 Fornire un’azione di de-fault per affrontare un evento diallarme.

1 Sì, dopo un time-outsceglie l’opzione più sicura

1.4 Fornire una richiesta di con-ferma per le operazioni critiche epossibilmente dannose.

1 Sì

1.5 Fornire una funzionalità diSTOP che interrompa ogni opera-zione.

1 Parzialmente (DOG):non tutte le operazioni sipossono interrompere

2.1 Fornire una connessione conil COGAIN ETU-Driver.

1 Sì

2.2 Supportare differenti metodidi input.

2 Sì,attualmente mouse, tastiera,eye-tracking e multi-touch

Continua. . .

82

Page 88: Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale

6 – Risultati ottenuti

Descrizione Priorità Rispettata?

2.3 Fornire un layout riconfigura-bile, appropriato per diverse per-formance dell’eye-tracking e perdiverse esigenze degli utenti.

2 Parzialmente:il layout attuale non è to-talmente riconfigurabile, maè possibile cambiarne il look(anche ingrandendo/rimpic-ciolendo i vari elementi gra-fici) ed è adattabile a diverserisoluzioni dello schermo

2.4 Supportare più metodi di in-put allo stesso tempo (interazionemultimodale).

2 Sì,attualmente mouse, tastiera,eye-tracking e multi-touch

2.5 Gestire la perdita del control-lo dell’input fornendo azioni didefault automatiche.

2 No

3.1 Rispondere agli eventi e ai co-mandi dell’ambiente domotico nelgiusto tempo.

1 Sì,l’interfaccia è reattiva

3.2 Gestire eventi con diversapriorità temporale.

1 Sì,per esempio gli eventi criti-ci, come gli allarmi, hanno laprecedenza sugli altri

3.3 Eseguire comandi con diversapriorità.

1 Parzialmente (DOG)

3.4 Fornire un feedback quan-do vengono eseguite operazioni ecomandi automatici.

2 Parzialmente (DOG):attualmente avviene solo pergli allarmi; gli scenari nonsono ancora pienamente sup-portati da DOG

3.5 Gestire (creare, modificare,cancellare) scenari.

2 Parzialmente (DOG):gli scenari non sono anco-ra pienamente supportati daDOG

3.6 Conoscere lo stato corrente diogni dispositivo.

2 Sì

4.1 Fornire una chiara visualiz-zazione di ciò che accade nellacasa.

1 Sì

Continua. . .

83

Page 89: Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale

6 – Risultati ottenuti

Descrizione Priorità Rispettata?

4.2 Fornire un’interfaccia elegan-te e chiara.

2 Sì

4.3 Fornire una visualizzazionedello stato e della posizione deidispositivi della casa.

2 Sì

4.4 Usare colori, icone e testoper evidenziare un cambiamentodi stato.

2 Sì,utilizza immagini colorate,testo e sintesi vocale

4.5 Fornire un metodo di selezio-ne facile da imparare.

2 Sì

Come si può vedere, vengono rispettate tutte le linee guida, parzialmente o total-mente, tranne una, andando così ben oltre l’obiettivo di rispettare solo le specifichecon priorità più alta.

84

Page 90: Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale

Capitolo 7

Conclusione e sviluppi futuri

L’interfaccia utente progettata ha le potenzialità per diventare l’interfaccia proto-tipale per molte altre interfacce utente, basate su eye-tracking, per il controllo diambienti domotici da parte di utenti disabili.

Essa è unica nel suo genere, non esistendo interfacce utente che, da una parte,rispettino a questo livello le specifiche e le linee guida di COGAIN e, dall’altra, sianoall’avanguardia sia per quanto riguarda lo stato dell’arte della tecnologia utilizzabileper realizzare interfacce grafiche (WPF in ambito .NET e XAML più in generale)sia per quanto riguarda i pattern di interazione.

Inoltre, essendo estremamente personalizzabile e ampliabile, anche grazie allastruttura modulare con cui l’interfaccia è composta, l’attuale versione di DOGeyepuò fornire un’ottima base per eventuali miglioramenti, modifiche e funzionalitàaggiuntive.

Infine, essa presenta alcune nuove tecniche (come quelle di selezione multipla, peresempio) che potranno permettere all’utente di utilizzare l’interfaccia con maggiorecomfort e migliorare le performance del sistema in generale.

Nel prossimo paragrafo, per concludere questa dissertazione, si presenterannoalcuni possibili sviluppi futuri, tralasciando gli eventuali miglioramenti del sistemastesso in termini di funzionalità già esistenti e le caratteristiche dell’interfaccia utenteche non si è potuto implementare completamente a causa di alcune limitazioni dellaversione di DOG utilizzata per questo progetto come, per esempio, gli scenari.

7.1 Possibili sviluppi futuri

Alcune nuove caratteristiche e funzionalità introducibili in DOGeye, potrebberoessere le seguenti:

• localizzazione

85

Page 91: Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale

7 – Conclusione e sviluppi futuri

DOGeye è predisposto per supportare la localizzazione in diversi linguaggi.Questa funzionalità è disponibile attraverso un tool semi-automatico inclusoin Visual Studio o adottando altri meccanismi ad-hoc.

• personalizzazione grafica

L’interfaccia è predisposta per offrire la possibilità di cambiare il suo look-and-feel al volo, in base alle preferenze dell’utente. Questo è possibile creandodiversi dizionari di stili XAML e permettendo all’utente di scegliere quello chepreferisce utilizzare.

• altre modalità di interazione

L’interfaccia utente offre la possibilità di utilizzare, al momento, mouse, tastie-ra ed eye-tracking per controllare e comandare l’applicazione. Si potrebberointrodurre altre modalità di interazione, come gli switch, che offrono una mo-dalità di selezione a scansione, passando cioè da un elemento dell’interfacciautente a un altro premendo un pulsante fisico o girando una manopola e inmodo sequenziale.

DOGeye, utilizzando principalmente delle liste per contenere i vari dispositividella casa e le sue stanze, offre già una buona base di partenza per l’adozione ditale metodo di interazione, in quanto le liste forniscono di default una basilaremodalità di scansione, quella che, per esempio, può essere utilizzata con i tasticursore della tastiera.

• applicazione web

Questa interfaccia utente, si è detto, utilizza delle pagine XAML per contenerei vari tab. Tali pagine, per quanto riguarda gli elementi dell’interfaccia gra-fica scritti in XAML, sono visualizzabili anche all’interno di un browser web.Inoltre, è possibile utilizzare WPF per creare applicazioni web. Ancora, latecnologia Silverlight della Microsoft, il cui funzionamento è all’incirca quellodi Adobe Flash e quindi nasce per il web, altro non è che un sotto-insieme diWPF, con il quale, quindi, condivide molti metodi e molte funzionalità.

Pertanto, partendo dall’attuale interfaccia si potrebbe realizzare un suo por-ting (sempre come applicazione WPF o come applicazione Silverlight) in modotale che essa possa funzionare anche attraverso un browser web, sia in localeche su un server apposito.

• interazione col sistema operativo sottostante

È possibile fornire le funzionalità del sistema operativo nonché alcuni suoi pro-grammi all’interfaccia utente in modo che si possano svolgere alcune operazionisenza dover chiudere DOGeye.

86

Page 92: Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale

7 – Conclusione e sviluppi futuri

Per fare un esempio, visto che le pagine XAML utilizzate in questo progettopossono contenere anche codice HTML, sarebbe possibile inserire una paginacon le funzionalità di navigazione dei più comuni browser web e permettere,così, di navigare in rete direttamente da DOGeye.

• gesture multi-touch

Avendo a disposizione un computer che supporti il multi-touch, è già possi-bile utilizzare questa interfaccia utente con i gesti più semplici, visto che glielementi grafici di DOGeye sono sufficientemente grandi per essere utilizzatianche con le dita.

Visto il supporto delle ultime versioni di Windows per il multi-touch e datala possibilità di utilizzarlo anche in WPF, sarebbe possibile implementare nel-l’interfaccia utente realizzata anche alcune gesture più avanzate, come il pinchper ingrandire un’immagine, solo per fare un esempio.

• realtà aumentata

Considerando il fatto che alcuni modelli di eye-tracker sono, per così dire,“portabili” (nel senso che possono essere montati su una carrozzina e muoversiinsieme all’utente), si potrebbe realizzare una versione di DOGeye che forniscafunzionalità di realtà aumentata combinata a un’interazione con l’eye-tracking.

L’utente, in questo caso, vedrebbe l’immagine reale della casa, trasmessa daun webcam anch’essa montata sull’eye-tracker e, in corrispondenza dei dispo-sitivi comandabili dall’interfaccia utente, vedrebbe comparire le informazionirelative al loro stato e alcuni pulsanti per interagire con essi.

Tralasciando per un attimo l’eye-tracking, questo potrebbe essere anche unaltro progetto, da realizzare per dispositivi portatili e con altre tecnologie, peresempio su iPhone/iPod Touch o Android.

87

Page 93: Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale

Appendice A

Microsoft Expression Design

Microsoft Expression Design, nella sua ultima versione, è stato utilizzato per realiz-zare quasi tutti gli elementi grafici che compaiono nell’interfaccia utente.

È l’applicativo Microsoft dedicato al disegno facente parte della suite ExpressionStudio, che recentemente è arrivata alla versione 3. Esso è un programma ibrido,pensato anche per supportare lo sviluppo di interfacce utente per applicativi desktope siti Web. È principalmente un software vettoriale, anche se è dotato di alcunefunzionalità ed effetti tipici dei programmi bitmap. Gli strumenti di disegno sonotutti vettoriali, e sono basati sia sulle curve di bezier, sia sulle b-spline (queste ultimetipiche della grafica 3D).

Figura A.1: Microsoft Expression Design

Microsoft Expression Design permette di esportare i propri lavori in vari formati:

bitmap - PNG, JPEG, GIF, TIFF, BMP,WDP, Photoshop PSD e PDF;

88

Page 94: Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale

A – Microsoft Expression Design

vettoriali - XAML Silverlight 3 Canvas, XAML WPF Canvas e XAML WPFResource Dictionary.

L’aspetto interessante è quello dato dalla possibilità proprio di esportare in for-mato XAML, per utilizzare poi le immagini all’interno di progetti WPF/Silverlight.

Concentrandoci sull’esportazione XAML, il formato forse più utilizzato per appli-cazioni WPF è quello che permette di ottenere un dizionario con all’interno l’imma-gine realizzata con Expression Design. Purtroppo, l’immagine contenuta nel diziona-rio esportato in questo modo è scarsamente utilizzabile all’interno di un programmaWPF, soprattutto perché non è possibile utilizzarla all’interno del contenitore Image,l’oggetto più comunemente usato per contenere delle immagini.

Pertanto, si riportano i passi necessari per ottenere un’immagine utilizzabile,immaginando di aver realizzato un’immagine di qualche tipo in Expression Design(versione 3 inglese) e di essere pronti per esportarla in XAML:

1. selezionare il menù File, poi Export ;

2. nella schermata che apparirà, individuare l’area intitolata “Export Properties”(sulla destra) e selezionare, dal menù a tendina Format, l’opzione XAML WPFResource Dictionary ;

3. il pannello “Export Properties”, a questo punto, cambierà leggermente di aspet-to; dal menù a tendina Group by, che permette di scegliere come si vuole chei vari elementi dell’immagine creata siano raggruppati in XAML, selezionarel’opzione che si preferisce, regolandosi in base alle proprie necessità e aiutandosicon l’anteprima mostrata nell’area a sinistra; si immagini di scegliere l’opzioneDocument che permette di avere un unico elemento nel dizionario risultante;

4. scegliere come si vogliono ottenere i Live effect, se rasterizzare tutto o con-vertirli in effetti XAML; questi sono gli effetti bitmap che si sono utilizzatinella creazione dell’immagine e i risultati graficamente migliori si ottengonoselezionando Convert to XAML effects ;

5. scegliere nell’area inferiore della finestra dove si vuole salvare il dizionarioXAML e premere Export All ;

6. a questo punto è possibile chiudere il programma e andare nella posizione incui si è salvato il dizionario appena creato e aprirlo; tale dizionario apparirànel modo seguente:

<ResourceDictionaryxmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"><DrawingBrush x:Key="ObjectName" Stretch="Uniform">

89

Page 95: Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale

A – Microsoft Expression Design

<DrawingBrush.Drawing><DrawingGroup><DrawingGroup.Children>... qui comparirà il codice XAML corrispondente all’immagine

realizzata...</DrawingGroup.Children>

</DrawingGroup></DrawingBrush.Drawing>

</DrawingBrush></ResourceDictionary>

tale oggetto, identificato dalla chiave ObjectName, come già detto, non èutilizzabile come un’immagine qualsiasi;

7. per rendere questo oggetto un’immagine utilizzabile al pari di una di formatoPNG o JPEG, senza perdere il vantaggio dato dalla grafica vettoriale, occorre:

• sostituire DrawingBrush con DrawingImage;

• eliminare la proprietà Stretch che non è più utilizzabile;

• sostituire DrawingBrush.Drawing con DrawingImage.Drawing.

90

Page 96: Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale

Appendice B

Modello della casa utilizzato

Il modello della casa utilizzato in questo progetto è composto da sette camere:

1. Bedroom (Camera da letto) che contiene:

• uno ShutterActuator, per comandare una tapparella;

• due bottoni;

• un DoorActuator, per comandare una porta;

• una SimpleLamp;

• una DimmerLamp, che differisce dalla SimpleLamp per il fatto che èpossibile regolarne la luminosità;

• due spine elettriche (Plug);

• un termosifone a gas (GasHeater);

2. Bathroom (Bagno) che contiene:

• uno ShutterActuator;

• un DoorActuator;

• due bottoni;

• due SimpleLamp;

• un Plug;

• un GasHeater.

3. Lobby (Ingresso) che contiene:

• un DoorActuator;

• otto bottoni;

91

Page 97: Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale

B – Modello della casa utilizzato

• tre SimpleLamp;

• due Plug;

• un GasHeater.

4. Storageroom (Sgabuzzino) che contiene:

• un DoorActuator;

• una SimpleLamp;

• un GasHeater.

5. Livingroom (Sala) che contiene:

• due ShutterActuator;

• un DoorActuator;

• tre bottoni;

• una SimpleLamp;

• due DimmerLamp;

• tre Plug;

• un MediaCenter;

• un GasHeater;

• un sensore per il rilevamento del fumo (SmokeSensor).

6. Diningroom (Sala da pranzo) che contiene:

• uno ShutterActuator;

• un DoorActuator;

• due bottoni;

• due SimpleLamp;

• un Plug;

• un GasHeater.

7. Kitchen (Cucina) che contiene:

• uno ShutterActuator;

• un DoorActuator;

• una SimpleLamp;

• due Plug;

92

Page 98: Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale

B – Modello della casa utilizzato

• una macchinetta per il caffè (CoffeeMaker);

• un GasHeater;

• un SmokeSensor.

In totale, sono presenti 66 dispositivi.

93

Page 99: Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale

Appendice C

Esempio di codice XAML

Data la vastità del codice dell’applicazione risulta improponibile riportare integral-mente il codice. Lo scopo questa Appendice è quello di mostrare il codice dellapagina XAML contenuta all’interno del tab “Home Management”, senza riportare laparte di code-behind.

<Page x:Class="DOGeye.HomeManagement"xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"Title="HomeManagement">

<DockPanel LastChildFill="True"><Grid DockPanel.Dock="Right">

<StackPanel x:Name="HMRoomAction" Visibility="Hidden"><TextBlock Text="{Binding SelectedItem.Description,

ElementName=HMhouse}" TextWrapping="Wrap" Foreground="White" TextAlignment="Center" Width="125" Margin="10,30,10,30" />

<Button Content="Go in!" Style="{StaticResourceICmdButtonStyle}" Click="EnterRoom_Click" />

<Border BorderBrush="Transparent" Margin="20"/><Button Content="Turn on devices..." Style="{StaticResource

OnButtonStyle}" Click="OnOffbyType_Click" /><Button Content="Turn off devices..." Style="{StaticResource

OffButtonStyle}" Click="OnOffbyType_Click" /></StackPanel>

<StackPanel x:Name="HMInsideRoom" Visibility="Hidden" ><TextBlock x:Name="HMRoomName" TextWrapping="Wrap" Foreground

="White" TextAlignment="Center" Width="125" Margin="10,30,10,10" />

94

Page 100: Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale

C – Esempio di codice XAML

<Button Content="Go out!" Style="{StaticResourceICmdButtonStyle}" Click="ExitRoom_Click" />

</StackPanel>

<StackPanel x:Name="HomeDeviceProp" Visibility="Hidden"><Grid Margin="10, 20, 10, 20" HorizontalAlignment="Center"

DataContext="{Binding ElementName=HMDevices}"><Grid.RowDefinitions>

<RowDefinition Height="*" /><RowDefinition Height="*" /><RowDefinition Height="*" />

</Grid.RowDefinitions><Grid.ColumnDefinitions>

<ColumnDefinition Width="Auto"/><ColumnDefinition Width="*"/>

</Grid.ColumnDefinitions><TextBlock x:Name="HMMDevName" Grid.Column="1" Grid.Row="

0" FontSize="14" Foreground="White" VerticalAlignment="Center" />

<Image x:Name="HMDevImg" Source="{Binding SelectedItem.Img}" Grid.Column="0" Grid.Row="0" Grid.RowSpan="2"Stretch="Uniform" MaxHeight="50" Margin="0,0,10,0"/>

<TextBlock x:Name="HMDevName" Text="{Binding SelectedItem}" Grid.Column="1" Grid.Row="0" FontSize="14"Foreground="White" VerticalAlignment="Center" />

<TextBlock x:Name="HMDevStateName" Text="{BindingSelectedItem.State.Name}" Grid.Column="1" Grid.Row="1" FontSize="14" Foreground="White" VerticalAlignment="Center" />

<TextBlock x:Name="HMDevStatus" Grid.Column="1" Grid.Row="2" FontSize="12" Foreground="White"VerticalAlignment="Center" />

</Grid><StackPanel x:Name="HomeDeviceCmds" /><Border BorderBrush="Transparent" Margin="20"/><TextBlock Text="{Binding ElementName=HMRoomName, Path=Text}"

TextWrapping="Wrap" Foreground="White"TextAlignment="Center" Width="125" Margin="

10,0,10,0" /><Button Content="Go out!" Style="{StaticResource

ICmdButtonStyle}" Click="ExitRoom_Click" /></StackPanel>

</Grid>

95

Page 101: Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale

C – Esempio di codice XAML

<Grid DockPanel.Dock="Left"><Grid.RowDefinitions>

<RowDefinition Height="*"/><RowDefinition Height="Auto"/>

</Grid.RowDefinitions><ListBox x:Name="HMhouse" Style="{StaticResource HouseDesign}"

ItemTemplate="{DynamicResource RoomMultipleContent}" Grid.Row="0" SelectionChanged="RoomChanged" />

<ListBox x:Name="HMDevices" Grid.Row="0" Style="{StaticResourceSingleRoomDevices}" Visibility="Hidden" SelectionChanged="DeviceSelected" />

<StackPanel Orientation="Horizontal" HorizontalAlignment="Center" Grid.Row="1"><Button Content="Multiple Selection" Width="130" Style="{

DynamicResource ISelButtonStyle}" Visibility="{BindingElementName=HMDevices, Path=Visibility}" Click="MultipleSelection_Click"/>

<Button Content="Select all by type..." Width="130" Style="{DynamicResource ISelButtonStyle}" Visibility="{BindingElementName=HMDevices, Path=Visibility}" Click="SelectionByType_Click"/>

</StackPanel>

</Grid></DockPanel>

</Page>

96

Page 102: Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale

Bibliografia

[1] Communication by gaze interaction: COGAIN. http://www.cogain.org.

[2] Oleg Špakov’s personal page: Eye-Tracking Universal Driver.http://www.cs.uta.fi/~oleg/etud.html.

[3] Domotica Labs. http://www.domoticalabs.com.

[4] LC Technologies - Eyegaze Systems. http://www.eyegaze.com.

[5] Disabilità in cifre (ISTAT). http://www.disabilitaincifre.it/

[6] Wikipedia. http://en.wikipedia.org/wiki/Eye_tracking.

[7] Wikipedia. http://en.wikipedia.org/wiki/Usability.

[8] Adam Nathan (2007), Windows Presentation Foundation Unleashed, SamsPublishing, United States of America.

[9] A. Dix, J. Finlay, G. D. Abowd, R. Beale (2004), Human-Computer Interaction,3rd edition, Pearson Education.

[10] R. Bates, G. Daunys, A. Villanueva, E. Castellina, G. Hong, H. Istance, A.Gale, V. Lauruska, O. Špakov, P. Majaranta (2006), D2.4 A Survey of Existing’de-facto’ Standards and Systems of Environmental Control, Communicationby gaze interaction (COGAIN).

[11] F. Corno, E. Castellina, R. Bates, P. Majaranta, H. Istance, M. Donegan (2007),D2.5 Draft standards for gaze based environmental control, Communication bygaze interaction (COGAIN).

[12] M. Donegan, L. Oosthuizen, R. Bates, G. Daunys, J. P. Hansen, M. Joos, P.Majaranta, I. Signorile (2005), D3.1 User requirements report with observa-tions of difficulties users are experiencing, Communication by gaze interaction(COGAIN).

[13] M. Donegan et al. (2006), D3.2 Report on features of the different systems anddevelopment needs, Communication by gaze interaction (COGAIN).

[14] F. Razzak, E. Castellina, F. Corno (2009), Environmental Control Applicationcompliant with Cogain Guidelines, Politecnico di Torino.

97