POLITECNICO DI TORINO
III Facoltà di Ingegneria
Corso di Laurea in Ingegneria Informatica
Tesi di Laurea Magistrale
Interfaccia utente basata su
eye-tracking per sistemi di controllo
ambientale
Relatori:
prof. Fulvio Corno
dott. Emiliano Castellina
Candidato:
Luigi De Russis
Febbraio 2010
Indice
1 Introduzione
1.1 Contesto generale . . . . . . . . . . . . . . .
1.2 Gaze tracking, interfacce utente e domotica .
1.3 Specifiche COGAIN . . . . . . . . . . . . . .
1.4 Struttura della tesi . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2 Obiettivi
3 Soluzioni tecniche adottate
3.1 Introduzione . . . . . . . . . .
3.2 Ambiente domotico . . . . . .
3.2.1 DOG . . . . . . . . . .
3.2.2 DogOnt . . . . . . . .
3.3 Eye Tracking Universal Driver
1
1
2
6
7
9
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
(ETU-Driver)
4 Tecnologia utilizzata
4.1 Windows Presentation Foundation . . . . .
4.2 XAML . . . . . . . . . . . . . . . . . . . .
4.2.1 Caratteristiche . . . . . . . . . . .
4.2.2 Code-behind . . . . . . . . . . . . .
4.3 Compatibilità con le tecnologie precedenti
4.3.1 Integrare controlli Win32 in WPF .
4.3.2 Integrare controlli WPF in Win32 .
4.3.3 Integrare Windows Forms e WPF .
4.3.4 Integrare controlli ActiveX in WPF
4.4 Differenze rispetto alle Windows Forms . .
4.4.1 Vantaggi . . . . . . . . . . . . . . .
4.4.2 Svantaggi . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
17
17
18
19
21
24
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
27
27
31
32
37
38
39
40
40
41
41
42
43
5 Progettazione e implementazione
45
5.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
II
5.2
5.3
Scelte progettuali e funzionalità . . . . . . . . .
5.2.1 “Home Management” ed “Electric Device”
5.2.2 Entertainment . . . . . . . . . . . . . . .
5.2.3 Temperature . . . . . . . . . . . . . . . .
5.2.4 Security e gli allarmi . . . . . . . . . . .
5.2.5 Scenarios . . . . . . . . . . . . . . . . .
5.2.6 Everything Else . . . . . . . . . . . . . .
5.2.7 Settings . . . . . . . . . . . . . . . . . .
Realizzazione dell’interfaccia utente . . . . . . .
5.3.1 Layout . . . . . . . . . . . . . . . . . . .
5.3.2 Layout dei tab . . . . . . . . . . . . . .
5.3.3 Interazione con DOG . . . . . . . . . . .
5.3.4 Interazione con l’ETU-Driver . . . . . .
5.3.5 Organizzazione e riusabilità del codice .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
48
52
58
59
61
63
64
65
65
68
70
73
76
78
6 Risultati ottenuti
79
6.1 Analisi qualitativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
6.2 Analisi quantitativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
6.3 Valutazione rispetto alle specifiche COGAIN . . . . . . . . . . . . . . 81
7 Conclusione e sviluppi futuri
85
7.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
Elenco delle tabelle
2.1
2.2
4.1
4.2
5.1
5.2
6.1
6.2
6.3
6.4
Rapporto tra raccomandazioni e interfacce utente per il controllo
domotico esistenti . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Linee guida COGAIN per la realizzazione di un’applicazione di controllo ambientale . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Alcune comuni keyword XAML . . . . . . . . . . . . . . . . . . . .
Vantaggi e svantaggi di WPF . . . . . . . . . . . . . . . . . . . . .
Attribuzione dei colori ai bottoni dell’UI in base alla loro funzione .
I principali pannelli presenti in XAML . . . . . . . . . . . . . . . .
Specifiche computer . . . . . . . . . . . . . . . . . . . . . . . . . . .
Utilizzo della RAM da parte di DOGeye . . . . . . . . . . . . . . .
Utilizzo della CPU da parte di DOGeye . . . . . . . . . . . . . . . .
Valutazione di DOGeye secondo le linee guida COGAIN . . . . . .
IV
. 11
.
.
.
.
.
.
.
.
.
12
35
44
52
70
80
80
81
82
Elenco delle figure
1.1
1.2
2.1
2.2
3.1
3.2
3.3
3.4
3.5
4.1
5.1
5.2
5.3
5.4
5.5
5.6
5.7
5.8
5.9
5.10
5.11
5.12
5.13
5.14
5.15
A.1
Un esempio di eye-tracker commerciale: MyTobii P10 . . . . . . . .
Un programma per la video-scrittura, basato su eye-tracking . . . .
Vista, ad alto livello, del contesto in cui si colloca l’interfaccia utente
da realizzare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Due interfacce utente per ambienti domotici . . . . . . . . . . . . .
Come l’interfaccia utente è connessa a DOG e all’eye-tracker . . . .
Un esempio di architettura logica di ambiente domotico . . . . . . .
L’architettura logica di DOG . . . . . . . . . . . . . . . . . . . . . .
L’ontologia DogOnt . . . . . . . . . . . . . . . . . . . . . . . . . . .
Parte dell’architettura dell’ETU-Driver . . . . . . . . . . . . . . . .
Le tecnologie incluse nel framework .NET . . . . . . . . . . . . . .
L’architettura generale dell’ambiente . . . . . . . . . . . . . . . . .
La versione preliminare di DOGeye . . . . . . . . . . . . . . . . . .
Il mock-up di DOGeye . . . . . . . . . . . . . . . . . . . . . . . . .
L’interfaccia DOGeye . . . . . . . . . . . . . . . . . . . . . . . . . .
Aspetto di DOGeye quando l’utente necessita qualche tipo di aiuto
La planimetria della casa, così come viene visualizzata in “Home
Management” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
I tre possibili comportamenti ottenibili selezionando una stanza nei
primi due tab di DOGeye . . . . . . . . . . . . . . . . . . . . . . .
Un esempio di interazione: aprire una porta . . . . . . . . . . . . .
Un’esempio di notifica . . . . . . . . . . . . . . . . . . . . . . . . .
Caratteristica di “Entertainment” . . . . . . . . . . . . . . . . . . .
Esempio di come viene indicata la temperatura di una stanza, in
“Temperature” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Esempio di come si imposta la temperatura del riscaldamento di tutta
la casa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Il tab “Security” . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Esempio di gestione di un allarme . . . . . . . . . . . . . . . . . . .
L’architettura generale di DOGeye . . . . . . . . . . . . . . . . . .
Microsoft Expression Design . . . . . . . . . . . . . . . . . . . . . .
V
.
.
3
5
.
.
.
.
.
.
.
.
.
.
.
.
.
9
10
17
18
20
23
24
28
45
46
48
49
50
. 53
.
.
.
.
55
57
57
59
. 59
.
.
.
.
.
60
61
62
68
88
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 afflitte
da disabilità, considerando anche le persone residenti nei presidi socio-sanitari. Qui,
per disabilità si intende qualsiasi limitazione o perdita della capacità di compiere
un’attività nel modo o nell’ampiezza considerati normali per un essere umano.
Per i disabili, quindi, possono risultare difficili o impossibili anche operazioni
relativamente semplici; riferendoci a un ambiente domestico, per esempio, potrebbe
risultare difficoltoso anche il gesto di premere un interruttore per accendere una luce
di una stanza, a causa dell’impossibilità di raggiungere la posizione del pulsante o
per l’assenza della forza necessaria a premerlo. In questo contesto, si possono inserire
i concetti di controllo dell’ambiente domestico e di usabilità.
Il controllo dell’ambiente domestico è il controllo, l’interazione e il monitoraggio
di un ambiente attraverso una tecnologia intermediaria, come un computer; ci si
riferisce a esso anche con il termine domotica. Per un disabile, un sistema di controllo
ambientale potrebbe essere l’unico modo per interagire con la sua casa, mantenendo
così la propria indipendenza. Lo scopo di un sistema domotico, allora, è quello di
ridurre il carico di lavoro giornaliero dell’occupante di una casa e permettergli di
vivere 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’utente, come mouse e tastiera, per citare le più comuni. Non tutti questi dispositivi di
input, però, possono essere utilizzati con facilità da una persona disabile. Bisogna,
quindi, valutare una modalità di interazione differente ed, eventualmente, modificare o riscrivere del tutto l’interfaccia utente che, in questo caso, è il componente
1
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 Organisation for Standardisation), come l’efficacia, l’efficienza e la soddisfazione con le
quali determinati utenti raggiungono determinati obiettivi in determinati contesti.
In pratica essa definisce il grado di facilità e soddisfazione con cui l’interazione tra
un essere umano e una macchina si compie.
Riferendosi in particolare a questa interfaccia utente, l’usabilità può essere definita come lo strumento che indica quanto le funzionalità dell’interfaccia si adattino
ai 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 successivo
utilizzo dovrebbe essere un processo estremamente semplice e intuitivo, così che essa
possa davvero essere adatta al modello mentale e alle differenti esigenze di ogni
utente che la voglia usare.
1.2
Gaze tracking, interfacce utente e domotica
Nel paragrafo precedente si affermava la necessità di valutare modalità di interazione
tra l’utente e il computer differenti dai classici mouse e tastiera.
Ci possono essere diverse alternative, ognuna che presenta dei vantaggi e degli
svantaggi: per questo progetto è stato scelto il gaze tracking (chiamato anche, in
italiano, tracciamento del punto fissato), che è una tecnica utilizzata per poter controllare 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ì il
nome di eye-tracking.
L’eye-tracking, o tracciamento oculare, è una tecnica utilizzata in molti campi, tra cui le scienze cognitive, la psicologia, l’informatica e l’interazione uomocomputer, per registrare i movimenti degli occhi. In particolare, vengono misurate e
analizzate la posizione degli occhi e il loro movimento relativo alla testa, utilizzando svariati metodi: alcuni prevedono l’utilizzo di immagini video dalle quali viene
estratta la posizione dell’occhio mediante tecniche di computer vision; altri utilizzano
la tecnica del riflesso corneale, che consiste nell’inviare un piccolo fascio luminoso
infrarosso al centro della pupilla e dedurre dalle variazioni del riflesso ottenuto i
movimenti effettuati dall’occhio, solo per citarne un paio.
Gli strumenti che permettono di eseguire queste misurazioni si chiamano eyetracker e si possono distinguere in due categorie:
• sistemi a postazione fissa, che sono cioè posizionati su un supporto di qualche
tipo, distante dall’utente;
2
1 – Introduzione
• sistemi indossabili, quindi a diretto contatto con l’utente, in genere sottoforma
di 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 quello
mostrato in figura 1.1. Questi eye-tracker, generalmente, sono personal computer a
tutti gli effetti, che integrano anche un paio di emettitori a raggi infrarossi e una
telecamera ad alta definizione, sensibile agli infrarossi: il sistema utilizza la tecnica
del riflesso corneale per stabilire il punto dello schermo osservato.
Non tutto il sistema funziona, però, grazie all’eye-tracking: ne usufruiscono solo
alcune applicazioni, in genere pre-installate all’interno della macchina. Il sistema
operativo, che nell’eye-tracker mostrato in figura è Windows XP, a titolo di esempio, e nativamente funziona grazie al mouse e alla tastiera; questo accade poiché
l’interazione basata su eye-tracking necessita che le interfacce utente dei programmi
che la vogliano utilizzare abbiano alcune caratteristiche particolari, dettate dalla
natura stessa di questo tipo di interazione.
È possibile utilizzare Windows anche con l’eye-tracker, ma è necessario utilizzare
un apposito programma che permetta di provare a compiere tutte le operazioni che
normalmente si effettuerebbero con l’ausilio del mouse e che, in alcune occasioni,
permetta anche di ingrandire certi oggetti che risultano troppo piccoli per essere
selezionati col tracciamento dello sguardo.
3
1 – Introduzione
In generale, infatti, non è possibile utilizzare l’eye-tracking come sostituto completo del mouse: ciò non è fattibile per il modo in cui agiscono i nostri occhi e per
la 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 di
qualsiasi altro dispositivo;
rivela il punto di attenzione poiché basta calcolare il punto in cui l’utente sta
guardando per capire dov’è diretta la sua attenzione;
risente del tocco di Mida poiché lo sguardo non fornisce l’equivalente dei pulsanti di un mouse, non è possibile sapere se l’utente sta guardando un punto
intenzionalmente oppure se sta solo spostando lo sguardo lungo lo schermo;
bisogna pertanto utilizzare altri metodi di selezione, come il dwell time, che
consiste in un tempo di pausa, generalmente personalizzabile, durante il quale
l’utente dovrà fissare l’oggetto dell’interfaccia con cui vuole interagire e poi,
trascorso quel tempo, il sistema effettuerà l’azione collegata all’oggetto che
l’utente stava fissando;
è sempre on poiché l’input fornito dallo sguardo è sempre continuo, fintanto che
si rimane davanti al monitor;
non è invasivo poiché il punto osservato viene rilevato senza bisogno di alcun tipo
di contatto fisico; anche per questo l’eye-tracking è una buona scelta per i
disabili che, magari, non possono utilizzare le mani;
richiede calibrazione poiché un sistema di eye-tracking, per essere usato con successo e al massimo delle sue possibilità, richiede di individuare correttamente
la posizione degli occhi e il loro movimento durante una fase di test preliminare
guidata.
La figura 1.2 mostra una semplice interfaccia grafica realizzata per un programma
di video-scrittura da eseguirsi tramite eye-tracking. Com’è possibile vedere, essa
differisce molto dalle tipiche interfacce utente utilizzate, anche solo da quella di
Windows, che si intravede sul fondo dell’immagine.
Quest’interfaccia condivide con altre interfacce basate su eye-tracking certe caratteristiche, 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 il
mouse, per esempio.
4
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 trova
un rettangolo di colore bianco che visualizza il testo man mano che lo si inserisce, mentre nella parte bassa si trovano otto rettangoli equidistanziati l’uno
dall’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 lettere
selezionate. A questo punto, si potrà selezionare direttamente la lettera “c” o
si dovrà selezionare un altro oggetto che, sempre per esempio, potrà contenere
le lettere “cd”. E così via. Bisognerà, quindi, navigare per livelli: infatti,
visualizzare tutte le lettere dell’alfabeto sullo schermo renderebbe i pulsanti
troppo piccoli e si incorrerebbe in errori di scrittura molto frequentemente.
• La mancanza del puntatore: studi dimostrano che la presenza di un puntatore
sempre presente sullo schermo potrebbe distrarre l’utente, introducendo così
degli errori. Pertanto, l’utente non sa dove sta guardando finché non guarda
un oggetto che è selezionabile. A quel punto, infatti, entra in gioco il dwell
time e viene visualizzato un qualche tipo di feedback per indicare all’utente
quanto tempo manca prima che l’oggetto sia effettivamente selezionato.
La scelta di utilizzare questo sistema di interazione nasce, inoltre, dal fatto che il
Politecnico di Torino, dal 2004, è entrato a far parte di COGAIN (Communication
by Gaze Interaction), una rete di eccellenza per lo sviluppo e la ricerca di tecnologie
per l’interazione fra utenti disabili e computer.
5
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 realizzare
un sistema domotico controllabile con eye-tracking e rispondente alle specifiche di
questo consorzio.
Sistema di controllo domotico che nasce soprattutto per risolvere il problema del
basso livello di standardizzazione delle soluzioni domotiche, problema introdotto dal
fatto che sono presenti molti produttori e molti dispositivi domotici che funzionano
con protocolli diversi, ognuno dei quali incompatibile con l’altro. Manca, cioè, una
soluzione di alto livello che, da un lato, permetta a questi dispositivi di comunicare
senza problemi tra di loro e, dall’altro, consenta di avere un unico punto di accesso
per tutte le tecniche di gaze control che si vogliono implementare.
Questo sistema di controllo ambientale esiste, è in continua evoluzione, è stato sviluppato proprio dal Politecnico di Torino e si chiama DOG (Domotic OSGi
Gateway).
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 (e
a 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 Systems
of Environmental Control ”, fornisce la definizione di controllo ambientale, presentandone il rapporto con la disabilità e analizzando differenti metodi di interazione,
tra cui il gaze control. Presenta, inoltre, anche alcuni prodotti commerciali e non
che possono essere considerati standard de-facto, evidenziando gli aspetti positivi e
quelli negativi della loro adozione. Infine, propone la creazione di un sistema ad-hoc
per 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-tracking
e propone una propria architettura, chiamata appunto DOG, fornendo anche alcuni
casi di studio esemplificativi per meglio comprendere il funzionamento di tale sistema
da parte dell’utente disabile.
Inoltre, espone la differenza tra vista strutturale e vista funzionale per l’organizzazione dell’interfaccia grafica: la prima mostra i dispositivi raggruppati come lo
sono nella casa reale (cioè per stanze), mentre la seconda li raggruppa in base alla
6
1 – Introduzione
loro funzione logica, a discapito della loro posizione effettiva. Trovare un equilibrio
tra queste due viste è essenziale.
Infine, elenca una serie di requisiti necessari e consigliati che un’interfaccia utente basata su eye-tracking per un ambiente domotico dovrebbe implementare e che
verranno riportati, dato il particolare interesse di questo elenco, nel capitolo successivo.
Il report D3.1, intitolato “User requirements report with observations of difficulties users are experiencing”, presenta la necessità di porre l’utente finale al centro
degli obiettivi di COGAIN. Fornisce, inoltre, alcune informazioni su chi può utilizzare la tecnologia di eye-tracking e chi, invece, non può, mettendo a confronto ciò che
la letteratura specialistica dice e ciò che l’evidenza sperimentale dimostra. Infine,
elenca qualche alternativa all’eye-tracking, indicando i vari aspetti positivi e negativi e mostrando con quale percentuale di successo delle persone disabili possono
utilizzare un sistema di gaze interaction.
Per ultimo, il report D3.2, dal titolo “Report on features of the different systems and development needs”, presenta alcune caratteristiche chiave dei sistemi di
eye-tracking, sia per quanto riguarda la loro componente hardware che per quanto
riguarda la componente software, analizzando diversi approcci e diverse possibili
scelte riguardanti l’interazione come, per esempio, la possibilità di utilizzare la voce come strumento da affiancare all’eye-tracking o la scelta nell’utilizzo di alcuni
simboli 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 strumenti base per comprendere il punto da cui è partita la realizzazione dell’interfaccia
utente basata su eye-tracking che è il prodotto finale di questo progetto.
Nei prossimi tre capitoli, la tesi è organizzata per presentare gli obiettivi e approfondire alcuni aspetti, seppur di background, necessari a comprendere appieno
il come e il perché si è realizzata l’interfaccia utente; nei capitoli seguenti, invece, si mostreranno le fasi di progettazione e di implementazione del progetto e si
presenteranno i risultati ottenuti.
In dettaglio:
• nel capitolo DUE “Obiettivi ”, si riprenderanno e si approfondiranno alcuni
concetti presentati in questo primo capitolo per focalizzare gli obiettivi che
si vogliono ottenere nello realizzare questa interfaccia utente, basata su eyetracking, per applicazioni domotiche;
7
1 – Introduzione
• nel capitolo TRE “Soluzioni tecniche adottate”, verrà descritto l’ambiente domotico proposto da COGAIN e dal Politecnico di Torino, cioè DOG, analizzando brevemente l’ontologia che racchiude lo schema della casa e dei suoi
dispositivi.
Inoltre, si presenterà l’Eye Tracking Universal Driver, un driver universale,
sempre proposto da COGAIN, che serve per utilizzare le tecniche di tracciamento degli occhi necessarie per questa applicazione di controllo domotico.
• nel capitolo QUATTRO “Tecnologia utilizzata”, si illustrerà la recente tecnologia Microsoft, inclusa nel Framework .NET 3.x, utilizzata per realizzare
l’interfaccia grafica, dal nome di Windows Presentation Foundation, presentando la sua maggiore innovazione, XAML, ed elencando le differenze rispetto
alla tecnologia Microsoft della generazione precedente.
• nel capitolo CINQUE “Progettazione e implementazione”, si presenterà l’architettura generale del sistema di controllo ambientale, le scelte progettuali e le
funzionalità inserite nell’interfaccia utente realizzata e, talvolta, si scenderà nel
dettaglio specificando quali componenti principali delle Windows Presentation
Foundation si sono utilizzati e perché si è fatta proprio quella scelta.
• nel capitolo SEI “Risultati ottenuti”, si presenterà qualche risultato qualitativo
e quantitativo derivato dall’utilizzo dell’interfaccia, soffermandosi in particolare ad analizzare quali delle specifiche COGAIN si sono rispettate e quali
no.
• nel capitolo SETTE “Conclusione e sviluppi futuri ”, verranno elencati alcuni
sviluppi futuri che il progetto descritto in questa tesi potrà avere.
Infine, negli appendici, verrà illustrato il rapporto tra il software Microsoft Expression Design, utilizzato per realizzare la maggior parte degli elementi grafici
dell’interfaccia grafica, e le immagini utilizzabili nel linguaggio XAML; seguirà un
esempio del modello della casa utilizzato e uno di parte del codice prodotto.
8
Capitolo 2
Obiettivi
L’obiettivo principale della tesi è lo studio, la progettazione e la realizzazione di
un’interfaccia utente basata su dispositivi di eye-tracking per funzionalità di controllo 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 da
realizzare
Essa mostra un utente che interagisce con la propria casa (ambiente domotico)
attraverso un eye-tracker. Per interagire con efficacia, però, necessita di un’interfaccia utente che, da una parte, si possa collegare all’ambiente domotico e dall’altra
sia utilizzabile con l’eye-tracking.
9
2 – Obiettivi
Assumendo di non avere alcun tipo di problema nel collegare una qualsiasi interfaccia utente al sistema di controllo domotico proposto da COGAIN nel deliverable
2.5, cioè a DOG, si può notare che qualche problema sorge proprio nel trovare un’interfaccia utente che sia utilizzabile con un eye-tracker, che abbia un numero sufficiente di funzionalità e che risponda a quei principi di usabilità che si accennavano
nel capitolo precedente.
Si considerino, come esempio, le seguenti interfacce utente commerciali (figura
2.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 controllo di dispositivi domotici. Fornisce un controllo basilare di luci e altri dispositivi
più avanzati, ovunque essi siano presenti nella casa, permettendo semplicemente di
accenderli o spegnerli ed è utilizzabile tramite eye-tracking.
La seconda è un’interfaccia di un software per il controllo ambientale sviluppato
da Domotica Labs. Permette un’interazione più completa rispetto al programma di
LC Technologies, è basata sul web ma non è utilizzabile con eye-tracking, soprattutto
per la presenza dei menù e a causa della ridotta dimensione dei pulsanti.
In particolare, le interfacce utente esistenti, non rispettano in pieno nessuna delle
raccomandazioni proposte da COGAIN o da altri enti. Si riportano, nella tabella
2.1, quelle più significative, evidenziando il comportamento delle due interfacce di
figura 2.2 rispetto a esse.
È quindi necessario creare da zero un’interfaccia utente, che sia usabile, che si
possa collegare a DOG e sia pronta per l’eye-tracking. Interfaccia a cui, d’ora in
poi, ci si riferirà anche con il nome di DOGeye, visto che unisce DOG all’EYE
interaction.
10
2 – Obiettivi
Raccomandazione
Creare interfacce utente consistenti
Creare scelte standard di interfacce
differenti, adattabili a piacere
Fornire funzionalità di sicurezza in caso
di guasto del sistema
Convergenza di diversi modi operativi
Utilizzare un insieme di metodi di input,
tra cui l’eye-tracking
Possibilità di scegliere la lingua da
utilizzare
Fornire una visualizzazione della posizione dei dispositivi all’interno della
casa
Usare colori, testo e icone per evidenziare un cambiamento di stato
LC Technologies
Domotica Labs
Sì
No
No
Possibile
No
Possibile
No
Sì
Possibile
No
Sì
Possibile
No
Sì
No
Parzialmente
Tabella 2.1: Rapporto tra raccomandazioni e interfacce utente per il controllo
domotico esistenti
Per farlo, ci si pone un altro obiettivo, quello cioè di realizzare un’interfaccia
grafica con le ultime tecnologie a disposizione, in modo che sia moderna per l’attuale stato dell’arte. Qui entra in gioco la tecnologia della Microsoft, introdotta a
partire dal framework .NET 3.0, chiamata Windows Presentation Foundation e la
sua componente più rilevante, XAML.
Con questa tecnologia, di cui si parlerà più approfonditamente nei prossimi capitoli, si possono realizzare interfacce utenti in maniera semplice, potente, creando
codice estremamente leggibile e permettendo la separazione quasi totale della parte
di design (cioè, come l’interfaccia appare) dalla parte di logica (quali sono i meccanismi per far sì che svolga i suoi compiti). La parte di design, infatti, viene realizzata
interamente in XAML, un linguaggio derivato da XML, mentre la parte di logica
viene realizzato col cosiddetto code-behind che, essenzialmente, può essere un qualsiasi 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’interazione con l’eye-tracking si utilizzerà un driver universale, sempre proposto da
COGAIN, dal nome ETU-Driver, che permetterà di utilizzare l’interfaccia anche in
simulazione (senza un eye-tracker vero e proprio, insomma) e che fornirà un’ampia compatibilità con diversi modelli di eye-tracker, i cui driver sono generalmente
11
2 – Obiettivi
incompatibili l’un l’altro.
Il fatto di dover usare l’ETU-Driver è un altro motivo che ha influito notevolmente nella scelta di utilizzare la piattaforma .NET: il driver è composto da oggetti
di tipo COM e quindi è possibile integrarlo in maniera semplice e veloce.
COGAIN, infine, ha pubblicato alcune linee guida che verranno utilizzate come
requisiti (riportati in tabella 2.2) per la realizzazione dell’interfaccia utente e per
la sua valutazione. Questi requisiti sono divisi in quattro categorie e hanno come
obiettivo 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 sicurezza
e sull’accessibilità nei confronti dell’utente:
priorità 1 - un’applicazione di controllo domotico DEVE soddisfare questa linea
guida;
priorità 2 - un’applicazione di controllo domotico DOVREBBE soddisfare questa
linea guida.
Ai fini di questo progetto, l’obiettivo è quello di soddisfare almeno i requisiti che
hanno priorità 1.
Tabella 2.2: Linee guida COGAIN per la realizzazione di un’applicazione di controllo
ambientale
Linea guida
1.1
1.2
Descrizione
Priorità
Fornire un sistema di notifiche per gli allarmi veloce,
1
facile da capire e multimodale.
L’applicazione di controllo dovrebbe notificare un allarme il prima possibile e in diversi modi, per esempio
con suoni, icone lampeggianti e messaggi di testo.
Fornire all’utente solo poche e chiare opzioni per
2
gestire eventi di allarme.
Molti eye-tracker sono poco accurati quando l’utente
è agitato, quindi in caso di allarme l’applicazione di
controllo dovrebbe fornire solo un limitato ma chiaro
insieme di opzioni (al massimo tre).
12
Continua. . .
2 – Obiettivi
Linea guida
Descrizione
Priorità
1.3
Fornire un’azione di default per affrontare un evento
di allarme.
In caso di emergenza, l’utente potrebbe perdere il controllo del dispositivo di input, quindi l’applicazione di
controllo dovrebbe prendere la decisione più sicura dopo che è scattato un timeout. La lunghezza del timeout
è dipendete dal tipo di allarme.
Fornire una richiesta di conferma per le operazioni
critiche e possibilmente dannose.
Con un inaccurato o mal configurato eye-tracker, l’errore del tocco di Mida può essere frequente, cioè ogni
oggetto o comando guardato dall’utente è selezionato o
eseguito, quindi l’applicazione di controllo dovrebbe richiedere una conferma per le operazioni che potrebbero
essere dannose.
Fornire una funzionalità di STOP che interrompa ogni
operazione.
In alcune occasioni, il sistema domotico può eseguire azioni che l’utente non vuole, per esempio per via
di una selezione di un comando errato o l’esecuzione di uno scenario pre-impostato. L’applicazione di
controllo dovrebbe permettere un metodo di stop per
interrompere ogni operazione.
Fornire una connessione con il COGAIN ETU-Driver.
Il COGAIN ETU-Driver è uno standard di comunicazione per la gaze interaction che permette ad applicazioni di terze parti di essere comandate da un range di diversi sistemi harware di eye-tracker. Usando
questo driver, non c’è bisogno di cambiare o ricompilare nessuna applicazione nel caso in cui si cambi
eye-tracker.
Supportare differenti metodi di input.
L’eye-tracker, sfortunatamente, potrebbe rompersi,
quindi l’applicazione di controllo dovrebbe supportare
anche altri metodi di input, come la tastiera, il mouse,
ecc.
1
1.4
1.5
2.1
2.2
1
1
1
2
Continua. . .
13
2 – Obiettivi
Linea guida
Descrizione
Priorità
2.3
Fornire un layout riconfigurabile, appropriato per
diverse performance dell’eye-tracking e per diverse
esigenze degli utenti.
Gli eye-tracker hanno un range di performance molto ampio; quindi un’applicazione di controllo dovrebbe
avere un’interfaccia grafica riconfigurabile in base alle
diverse risoluzioni e precisioni degli eye-tracker.
Supportare più metodi di input allo stesso tempo
(interazione multimodale).
L’utente potrebbe essere capace di usare canali di input
alternativi all’eye-tracking, come la voce o i movimenti delle dita, per esempio. L’applicazione di controllo dovrebbe supportare la combinazione di più metodi di input contemporaneamente, come ad esempio la
selezione con l’occhio e il click con il mouse.
Gestire la perdita del controllo dell’input fornendo
azioni di default automatiche.
L’applicazione di controllo dovrebbe capire quando l’utente ha perso il controllo dell’eye-tracker e dovrebbe eseguire azioni di default (come effettuare una
ricalibrazione o far suonare un allarme).
Rispondere agli eventi e ai comandi dell’ambiente
domotico nel giusto tempo.
L’applicazione di controllo dovrebbe essere reattiva:
dovrebbe gestire gli eventi e i comandi con un ritardo
accettabile.
Gestire eventi con diversa priorità temporale.
L’applicazione di controllo dovrebbe distinguere tra
eventi con priorità differente. Gli eventi temporalmente critici devono essere eseguiti con un breve periodo di attesa (per esempio, l’allarme antincendio o il
rilevamento di un’intrusione).
2
2.4
2.5
3.1
3.2
2
2
1
1
Continua. . .
14
2 – Obiettivi
Linea guida
Descrizione
Priorità
3.3
Eseguire comandi con diversa priorità.
I sistemi domotici ricevono più comandi contemporaneamente, a causa di diversi utenti o degli scenari,
per esempio. L’applicazione di controllo dovrebbe discriminare comandi con priorità differente e dovrebbe
adottare un comportamento prestabilito.
Fornire un feedback quando vengono eseguite operazioni e comandi automatici.
Gli scenari, selezionati dall’utente, potrebbero includere molti comandi da eseguire. L’applicazione di
controllo dovrebbe mostrare l’azione in progresso e
informare l’utente quando uno scenario è terminato.
Gestire (creare, modificare, cancellare) scenari.
Ripetere una lunga sequenza di comandi per eseguire
un compito frequente potrebbe essere noioso per l’utente. E’ necessario raccoglierli in una lista di comandi e
gestirli come se fossero uno solo. L’applicazione di controllo dovrebbe permettere la creazione, la modifica e
la cancellazione di questi scenari.
Conoscere lo stato corrente di ogni dispositivo.
L’applicazione di controllo dovrebbe conoscere lo stato corrente di ogni dispositivo della casa, per mostrare
questa informazione e per prendere decisioni automatiche intelligenti (per esempio, prevenire una condizione
dannosa o attivare un piano di risparmio energetico).
Fornire una chiara visualizzazione di ciò che accade
nella casa.
L’interfaccia dell’applicazione di controllo dovrebbe
fornire una visualizzazione chiara e facile da capire del
progresso dell’esecuzione del comando.
Fornire un’interfaccia elegante e chiara.
Un layout consistente, con un linguaggio facile da capire e una grafica riconoscibile, avvantaggia ogni utente.
L’applicazione di controllo dovrebbe fornire un’interfaccia elegante e chiara, possibilmente utilizzando sia
immagini che testo.
1
3.4
3.5
3.6
4.1
4.2
2
2
2
1
2
Continua. . .
15
2 – Obiettivi
Linea guida
Descrizione
Priorità
4.3
Fornire una visualizzazione dello stato e della posizione
dei dispositivi della casa.
L’applicazione di controllo dovrebbe mostrare la mappa della casa contenente, per ogni stanza, una
rappresentazione dei dispositivi e il loro stato.
Usare colori, icone e testo per evidenziare un
cambiamento di stato.
L’interfaccia dell’applicazione di controllo dovrebbe
evidenziare un cambiamento di stato di un dispositivo
utilizzando immagini, testo e suoni.
Fornire un metodo di selezione facile da imparare.
Anche se l’applicazione di controllo potrebbe presentare caratteristiche e funzionalità complesse, dovrebbe
pure fornire un metodo di interazione usabile e facile
da imparare.
2
4.4
4.5
16
2
2
Capitolo 3
Soluzioni tecniche adottate
3.1
Introduzione
Prima di parlare del progetto dell’interfaccia utente realizzata è doveroso dedicare
un po’ di tempo per presentare sufficientemente nel dettaglio le soluzioni tecniche
con cui l’applicativo deve interagire.
In particolare, nei capitoli precedenti, si è parlato di un sistema di controllo
dell’ambiente domotico chiamato DOG e di un driver universale per l’eye-tracking
chiamato ETU-Driver. Entrambi questi componenti, proposti o consigliati da COGAIN, hanno un ruolo essenziale per il progetto trattato in questa dissertazione ed
entrambi sono strettamente correlati con l’interfaccia utente, nel modo rappresentato
nella figura 3.1:
Figura 3.1: Come l’interfaccia utente è connessa a DOG e all’eye-tracker
17
3 – Soluzioni tecniche adottate
Nei paragrafi seguenti, si tratteranno in maniera più dettagliata le caratteristiche
dell’ambiente domotico e dell’ETU-Driver, procedendo quindi a un “ingrandimento”
di alcune parti della figura 3.1.
3.2
Ambiente domotico
Il termine domotica (o Smart Home) è un neologismo derivante dalla parola latina
domus (che, appunto, significa casa) e la parola informatica.
La domotica, quindi, è la disciplina che si occupa di studiare tecnologie informatiche e appartenenti all’area dell’automazione per poterle utilizzarle negli ambienti
domestici, al fine di migliorarne il comfort, l’abitabilità e di semplificare la vita delle
persone 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 occupa
di automatizzare semplici funzioni della casa come, per esempio, l’accensione e lo
spegnimento delle luci; dall’altra cerca di sviluppare servizi più “intelligenti” come,
18
3 – Soluzioni tecniche adottate
per esempio, gli scenari, cioè un elenco di attività riguardanti determinati dispositivi
domestici che possono venire attivati o disattivati tutti insieme in un certo momento
della giornata, a scelta dell’utilizzatore.
Un ambiente domotico, pertanto, è un ambiente opportunamente progettato e
tecnologicamente attrezzato, in cui sono presenti impianti e dispositivi che sfruttano
tecnologie che li rendono controllabili da remoto ed eventualmente anche in grado
di comunicare tra di loro.
Anche se il termine “da remoto” può dare l’idea che la casa venga controllata da un
altro posto, al di fuori dell’abitazione, in questo contesto si intende semplicemente
che un oggetto o una funzionalità della casa può essere controllata senza il bisogno
di 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 sistema
di eye-tracking o attraverso lo schermo di un computer.
Inoltre, un ambiente domotico come quello mostrato in figura 3.2 è composto da
una serie di componenti hardware e software.
Le componenti hardware sono gli impianti domotici, che comprendono alcuni
dispositivi e un gateway, che gestisce la comunicazione con ogni dispositivo appartenente al proprio impianto e con l’House Manager. I gateway dei vari impianti
domotici, a loro volta, sono collegati con un Domotic House Gateway che gestisce
la rete di comunicazione tra i diversi gateway.
La componente software, invece, è il cuore del sistema domotico perché ha il
compito di gestire i dispositivi della casa, non importa in quale impianto essi si
trovino: tale componente prende il nome di House Manager.
L’House Manager si occupa anche di fornire servizi intelligenti e alcune applicazioni che permettano all’utente di interagire con la casa. L’House Manager, nel
contesto che stiamo considerando, altro non è che DOG, proposto da COGAIN e
sviluppato 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 singolo
sistema software.
Realizzato con tecnologia OSGi, fornisce un ambiente per gli sviluppatori orientato ai servizi e basato su componenti, offrendo così modi standardizzati di gestire
il ciclo di vita del software stesso. Fornisce un framework Java stabile, sicuro e
general-purpose che supporta lo sviluppo di applicazioni di servizio estensibili chiamate bundle o, in italiano, moduli, che sono facili da integrare: basta, infatti, che
siano conformi ai vincoli di comunicazione definiti nel framework stesso.
19
3 – Soluzioni tecniche adottate
Figura 3.3: L’architettura logica di DOG
Come illustrato nella figura 3.3, DOG è composto da differenti moduli, che hanno
i vari usi e ruoli descritti di seguito:
• Network Drivers permette l’interazione diretta con le componenti hardware
dell’ambiente domotico. È necessario un driver differente per ogni protocollo
di basso livello utilizzato dalle varie componenti.
Attualmente è formato da tre bundle: ND Konnex per i sistemi KNX, ND
BTicino per i sistemi MyHome BTicino e ND Emulator che permette di emulare i dispositivi fisicamente non disponibili, consentendo così di utilizzare il
software anche in assenza di un ambiente domotico reale, cioè in simulazione;
• Message Dispatcher effettua il routing degli eventi in arrivo dai Network Drivers e i comandi in arrivo dall’Executor; contiene, quindi, una tabella di routing per mappare la corrispondenza tra i dispositivi e i Network Drivers che
possono comandarli;
• Executor riceve i comandi dal modulo API, ne controlla la correttezza interagendo con il modulo Status e li esegue inviando i nuovi comandi al Command
Dispatcher;
• House Model contiene la rappresentazione della casa e dei dispositivi appartenenti all’ontologia DogOnt, descritta nel prossimo sotto-paragrafo;
20
3 – Soluzioni tecniche adottate
• Status è una sorta di cache che contiene lo status dei dispositivi presenti nel sistema; risponde alle richieste mandate dal modulo API, restituendo
informazioni sui vari dispositivi;
• Platform Manager gestisce l’installazione, l’avvio e la sospensione dei bundle
all’interno della piattaforma OSGi, fornisce informazioni sullo stato dei bundle
e gestisce la sequenza di bootstrap di sistema;
• Configurator Registry fornisce i dati di configurazione necessari al funzionamento dei singoli moduli;
• API è il punto di accesso esterno al sistema; fornisce una serie di servizi come
l’elenco dei dispositivi presenti nella casa, la possibilità di eseguire comandi e
quella di registrarsi come listener per ricevere determinati eventi e conoscere
lo stato di uno o più dispositivi;
• XmlRpcConnector espone i servizi offerti dal modello API sottoforma di endpoint XML-RPC: l’interfaccia utente utilizzerà questo modulo e il protocollo
XML-RPC per interagire con DOG;
• DogLibrary, infine, specifica le interfacce dei servizi offerti dai bundle, definendo e implementando le classi di sistema e le eccezioni.
L’interfaccia utente comunicherà con DOG principalmente durante due fasi, quella 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’interfaccia
comunicherà a DOG i comandi che vuole compiere (per esempio, accendere una luce) e DOG risponderà restituendo l’esito dell’operazione che gli è stata richiesta (“la
luce si è accesa”).
Sempre nella fase operativa, DOG potrebbe comunicare all’interfaccia che il verificarsi di un evento (qualcuno ha premuto un pulsante e la luce si è accesa) e
l’interfaccia tratterà questa informazione di conseguenza, generalmente producendo
una notifica destinata all’utente.
La fase operativa, come è facile intuire, è una fase che viene ripetuta diverse
volte, fintanto che DOG e l’interfaccia sono entrambi in funzione e qualcosa capita
all’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
3 – Soluzioni tecniche adottate
Una ontologia è una rappresentazione formale di una interpretazione condivisa di
uno specifico dominio di conoscenza. Non esistendo l’ontologia perfetta, la rappresentazione di un determinato dominio può essere formalizzata in una moltitudine di
modi e dipende dallo scopo per cui viene creata. Un’ontologia assume normalmente
una 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 e
condividere;
Relazioni - modi in cui gli oggetti possono essere messi in relazione gli uni con gli
altri;
Individui - istanze del modello, che sono gli elementi di base.
Le classi di un’ontologia sono concetti astratti che esprimono una classificazione
delle entità rilevanti del dominio.
L’ontologia ha generalmente una classe radice chiamata Thing da cui discendono
tutte le altre. Le classi nell’ontologia seguono il principio dell’ereditarietà padre-figlio
a livello di classe e proprietà.
Analizzando la figura 3.4, si può notare che l’ontologia di DogOnt si sviluppa
lungo cinque rami principali:
• Building Thing: rappresenta gli oggetti disponibili (controllabili, come una
luce, 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 (accendersi e spegnersi, sempre per esempio); la maggior parte degli oggetti istanziabili
non ha funzionalità comandabili con più di tre comandi.
• Domotic Network Component: rappresenta delle caratteristiche peculiari di
ogni impianto domotico.
Ogni ramo, a sua volta, avrà un certo numero di altri rami figli, a seconda di cosa
deve rappresentare: “Building Thing”, che è uno dei rami dell’ontologia più interessanti poiché contiene tutti i dispositivi, gli elementi di mobilio e quelli architetturali
22
3 – Soluzioni tecniche adottate
Figura 3.4: L’ontologia DogOnt
che ci possono essere nella casa, si divide in Controllable e Uncontrollable, per separare gli oggetti che sono controllabili da quelli che, come il tavolo del soggiorno, non
lo sono.
DogOnt, inoltre, rappresenta ogni dispositivo come un oggetto che possiede un
insieme 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 i
dispositivi della stessa classe: pertanto, diversi tipi di lampade appartenenti alla
stessa classe potranno avere delle funzionalità in comune. D’altra parte, invece, gli
stati 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 ogni
camera che si vuole avere nella casa (le stanze si trovano nel ramo “Building Environment”); dopodiché basterebbe creare le istanze dei dispositivi che si vogliono
23
3 – Soluzioni tecniche adottate
avere nelle singole stanze, come luci, interruttori o elettrodomestici (si trovano tutti in “Building Thing” > “Controllable” > “White Goods”) e assegnargli i tipi di
funzionalità e i tipi di stato che sono previsti nelle loro classi.
L’assegnazione dei singoli stati e delle singole funzionalità per ogni dispositivo istanziato nell’ontologia viene fatto in maniera automatica proprio grazie al
ragionamento basato su regole offerto da DogOnt.
Le regole di DogOnt, pertanto, facilitano il processo di modellazione generando automaticamente gli stati adeguati e le funzionalità dei dispositivi domotici, e
associandoli al corretto dispositivo attraverso relazioni di tipo semantico.
Fornendo alcune modalità di ragionamento, inoltre, DogOnt è in grado di fornire
la posizione di un dispositivo domotico nella casa, elencare l’insieme delle sue caratteristiche, fornire le caratteristiche tecnologie necessarie per interfacciarsi con quel
dispositivo, dire come è composto l’ambiente domestico e presentare gli elementi
architetturali e di mobilio che sono presenti nella casa.
Ci sarebbe ancora molto da dire riguardo questo argomento ma, per gli obiettivi
di questa tesi non è necessario sapere altro: l’interfaccia utente si collega direttamente con DOG che gli fornisce il modello della casa con tutti i suoi dispositivi e non
ha bisogno di modificare né l’ontologia né le regole di DogOnt. È sufficiente sapere
cos’è un’ontologia, che i vari dispositivi hanno delle funzionalità e degli stati e che
DOG 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), utilizzato in questo progetto, è stato sviluppato da Oleg Špakov e si presenta come
un livello che si pone fra il driver vero e proprio di alcuni modelli di eye-tracker e
le applicazioni di terze parti, al fine di permettere il loro utilizzo su eye-tracker di
produttori differenti.
Figura 3.5: Parte dell’architettura dell’ETU-Driver
24
3 – Soluzioni tecniche adottate
Il driver, la cui architettura è rappresentata nella figura 3.5, è costituito da una
serie di oggetti COM che implementano un’unica interfaccia per alcuni eye-tracker
supportati e da un set di librerie (chiamate API-Converters), che convertono le API
originali dei vari produttori in una API comune utilizzata, appunto, da questo driver
universale.
Attualmente, il driver universale contiene gli API-Converters dei seguenti eyetracker:
• 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 essere
utilizzati per scopi di debug, per eseguire applicativi di dimostrazione o per mostrare
il comportamento di un’interazione basata su eye-tracking in assenza di un eyetracker vero e proprio.
Questi tre convertitori sono:
• Mouse, utilizza la posizione del puntatore del mouse sullo schermo come punto
osservato in quell’istante. Questa API contiene un algoritmo di fixation detection, i cui parametri sono completamente configurabili tramite le opzioni
dell’ETU-Driver.
• Gaze-data file, legge e interpreta un file contenente i dati sullo sguardo registrato 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 alle
applicazioni utente.
Tali filtri sono:
EyeMouse - questo filtro collega sguardo e mouse, ovvero il puntatore si muove
seguendo con il punto osservato.
25
3 – Soluzioni tecniche adottate
ThinOut - questo filtro accetta solo un campione ogni N, con N impostabile a
piacere.
FixationDetector - questo filtro utilizza lo strumento di fixation detection sviluppato da Oleg Špakov, che permette di rilevare quando l’utente fissa lo sguardo
in un punto, tramite opportuni algoritmi.
Il vantaggio di utilizzare un driver universale consiste nel fatto che una qualsiasi
applicazione implementata con questo driver può interfacciarsi con un nuovo eyetracker semplicemente utilizzando l’opportuno API-Converter.
Senza l’ausilio dell’ETU-Driver, ogni volta che un’applicazione dovesse essere
eseguita su un nuovo modello di eye-tracker, bisognerebbe ricompilarla con i driver
del nuovo dispositivo di eye-tracking: bisognerebbe, cioè, realizzare una versione del
programma per ogni eye-tracker su cui lo si volesse utilizzare.
26
Capitolo 4
Tecnologia utilizzata
Esistono diverse tecnologie e diversi linguaggi adatti a realizzare un’interfaccia utente. All’interno della piattaforma .NET, utilizzata per questo progetto, ne esistono principalmente due: Windows Forms e le più moderne Windows Presentation
Foundation.
In questo capitolo, si presenteranno le caratteristiche peculiari proprio di Windows Presentation Foundation, soffermandosi in maniera particolare ad analizzare quella che potrebbe essere considerata la sua componente principale, cioè il linguaggio
XAML, ed evidenziando le differenze con la tecnologia Microsoft della generazione
precedente.
4.1
Windows Presentation Foundation
Il cinema hollywoodiano ci ha, da sempre, abituati a vedere personaggi che appaiono
più attraenti, più reattivi e più determinati della maggior parte delle persone che si
incontrano nella vita di tutti i giorni.
La stessa cosa potrebbe essere detta anche riguardo al software che questi personaggi utilizzano, soprattutto nei film, non di fantascienza, realizzati negli anni ’90:
mi vengono in mente client di posta elettronica che mostrano scritte tridimensionali, che avvisano della ricezione di nuove e-mail visualizzando delle animazioni e
riproducendo la frase “You’ve got mail! ”, e così via.
In confronto ai client di posta elettronica “reali”, esistenti quando quei film venivano realizzati, quelli erano molto più belli e, per certi versi, “irresistibili”, anche
considerando alcuni aspetti legati all’usabilità.
Solo in questi ultimi anni, si è visto un avvicinamento tra gli standard del software
reale e quelli del software presentato nei film: è sufficiente pensare agli effetti di Mac
OS X, a quelli di Compix su Linux, a quelli introdotti da Windows Vista in poi o,
27
4 – Tecnologia utilizzata
sul web, a quelli di Adobe Flash, senza dimenticare quelli che verranno introdotti
da HTML 5, solo per fare qualche esempio.
Gli utenti, stimolati forse anche dai film che vedono, hanno aspettative sempre
crescenti sulla cosidetta software experience e quindi si aspettano di poter utilizzare dei programmi che abbiano le funzionalità che necessitano ma che siano anche
intuitivi, stabili e, perché no, eleganti e chiari.
A questo punto entra in gioco Microsoft con una soluzione che può aiutare gli
sviluppatori a creare “software del ventunesimo secolo” (Adam Nathan, 2006), senza sprecare troppo tempo e troppe risorse: questa soluzione è, appunto, Windows
Presentation Foundation (WPF), introdotta a partire dal framework .NET versione
3.0.
Figura 4.1: Le tecnologie incluse nel framework .NET
La maggior parte delle interfacce utente utilizzate oggigiorno in Windows sono
realizzate usando il sottosistema grafico che prende il nome di GDI+, la versione
avanzata di Graphics Device Interface (GDI), che fornisce gli strumenti base per le
interfacce che vogliano utilizzare la grafica 2D ma che presenta alcune limitazioni,
dovute soprattutto al fatto che tale sottosistema è nato nel 1985, un tempo davvero
molto lontano, tecnologicamente parlando.
28
4 – Tecnologia utilizzata
Tali limitazioni sono state superate da WPF, di cui si riportano alcune tra le sue
caratteristiche più importanti:
• ampia integrazione - Prima di WPF, uno sviluppatore che volesse usare
componenti 3D, video o vocali in aggiunta alla normale grafica bidimensionale e agli usuali controlli, doveva utilizzare tecnologie indipendenti dalle GDI
che avevano un gran numero di inconsistenze e davano alcuni problemi di
compatibilità.
WPF copre tutte queste aree (e anche altre, come la gestione e la vista avanzata di documenti testuali) con un modello di programmazione consistente e
una buona integrazione tra i diversi tipi di oggetti. Inoltre, buona parte delle tecniche che si possono utilizzare in una determinata area possono essere
utilizzate direttamente anche in altre.
• indipendenza dalla risoluzione - Un’interfaccia sviluppata prima di WPF
è, generalmente, dipendente dalla risoluzione del monitor su cui viene visualizzata. Se, per esempio, essa veniva sviluppata per un Ultra-Mobile PC (che,
tipicamente, ha un monitor da quattro a sette pollici e una risoluzione adeguata) e poi veniva utilizzata su un computer con uno schermo da 20” (con
una risoluzione più elevata, ovviamente), i vari elementi grafici dell’interfaccia
utente apparivano “sgranati” oppure piccolissimi. E viceversa.
WPF offre, invece, la possibilità di ridurre e allargare gli elementi sullo schermo
in maniera indipendente dalla risoluzione. Molte di queste possibilità sono
offerte grazie all’orientamento di WPF verso la grafica vettoriale: ingrandendo
un elemento di un’interfaccia realizzata con WPF, esso rimane pulito e visibile
senza alcun tipo di sgranatura o imprecisione.
• accelerazione hardware - Anche se WPF è una nuova tecnologia, essa è
costruita sopra Direct3D, appartenente alle DirectX. Questo significa che il
contenuto di un’applicazione WPF, sia esso 2D o 3D, grafico o testuale, viene
convertito in triangoli 3D, texture e altri oggetti Direct3D e poi renderizzato
via hardware. Questo è sempre più vero per sempre più contenuti man mano
che il framework .NET evolve da una versione all’altra. Quindi, le applicazioni
WPF sfruttano i benefici dell’accelerazione video per avere una grafica più
liscia, più morbida e, di conseguenza, miglior performance, utilizzando per gli
elementi grafici la GPU della scheda video invece che la CPU. Inoltre, questo
assicura che le applicazioni WPF possano ricevere il massimo beneficio dai
nuovi hardware e driver.
Se, però, non fosse disponibile hardware grafico di alto livello, WPF offre
anche una pipeline di rendering grafico via software. Questo, inoltre, permette
di sfruttare funzionalità che non sono ancora supportate dall’hardware attuale
29
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 un
computer con risorse hardware inadeguate per essa.
• programmazione dichiarativa - Prima di WPF i programmi che utilizzavano la piattaforma .NET avevano la possibilità di includere diversi tipi di
attributi, file di risorse e file di configurazione basati su linguaggi dichiarativi1
come l’eXtensible Markup Language (XML).
WPF porta la programmazione dichiarativa per le interfacce grafiche a tutt’altro livello, introducendo l’eXtensible Application Markup Language (XAML).
La combinazione di WPF con XAML fornisce una grande espressività che si
estende anche oltre i confini della produzione di interfacce utente; WPF utilizza XAML anche come un formato per alcuni documenti, per rappresentare
modelli 3D, immagini e molto altro. Il risultato è che i designer grafici possono
così contribuire direttamente al look-and-feel delle applicazioni, lasciando poi
ai programmatori la realizzazione della parte logica del programma.
• personalizzazione e composizione evoluta - I controlli WPF sono estremamente personalizzabili e componibili l’un l’altro: si può, per esempio, creare
un bottone che abbia all’interno un video. Anche se alcune di queste personalizzazioni possono suonare terribili, il fatto importante è che esse siano possibili
da realizzare senza scrivere tonnellate di codice, in maniera semplice e in poche
righe. Inoltre, è possibile dichiarare questi controlli personalizzati in un unico
punto del codice e poi riutilizzarli tutte le volte che si ha bisogno.
• sviluppo facile - WPF fornisce opzioni per sviluppare sia applicazioni desktop
per Windows sia per ospitare applicazioni all’interno di un browser web e anche
offrire opzioni di navigazione simili a quelle di un browser all’interno di una
applicazione desktop.
In breve, WPF si pone come obiettivo quello di combinare le migliori caratteristiche di vari sistemi, come DirectX (per il 3D e l’accelerazione hardware), Windows
Forms (per la produttività dello sviluppatore), Adobe Flash (per il supporto alle
animazioni) e HTML (per il linguaggi dichiarativi e la semplicità di sviluppo).
WPF, in termini di funzionalità, ovviamente, non permette di fare cose che in
precedenza non si sarebbero potute fare. Le permette di fare, però, in un modo
più semplice, più veloce, più stabile, più sicuro e senza ricorrere a tante tecnologie
diverse che potrebbero dare problemi nel momento in cui esse vengono integrate.
1
linguaggi 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
4 – Tecnologia utilizzata
Avendo, inoltre, citato DirectX, non bisogna pensare che questa tecnologia sia
morta, visto che adesso esiste WPF: sono due cose distinte che agiscono a livelli
diversi, più alto WPF e più basso DirectX. La scelta di utilizzare l’una o l’altra per
applicazioni che utilizzino molto la grafica, dipende dagli obiettivi che si vogliono
ottenere e dalle possibilità di testing che si hanno. Per gli scopi di questa tesi, le
possibilità offerte da WPF sono più che sufficienti.
Infine, c’è ancora da spendere alcune parole a proposito di Adobe Flash. WPF
non utilizza né direttamente né direttamente la tecnologia introdotta da Flash, che
attualmente è l’opzione più popolare per creare contenuti web evoluti. Le applicazioni WPF possono essere eseguite all’interno di un browser web, ma richiedono
Windows e il framework .NET 3.0 o superiore installato. Per Flash, invece, basta
un 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 suo
nome è Silverlight, è disponibile come un plug-in ufficiale per Mac e Windows (e uno
non ufficiale per sistemi Linux), supporta XAML, JavaScript e alcune caratteristiche
della piattaforma .NET. In questa dissertazione non si parlerà più di Silverlight
ma, vista la stretta parentela esistente tra WPF e questa tecnologia, è sembrato
opportuno almeno citarne l’esistenza.
4.2
XAML
XAML, la cui pronuncia corretta è “Zammel ”, è uno strumento molto importante
per integrare designer grafici nel processo di sviluppo di un applicativo e permette
di creare interfacce utente in un modo innovativo e molto produttivo.
Infatti:
• XAML è generalmente il modo più conciso di rappresentare interfacce utente
o altre gerarchie di oggetti;
• l’uso di XAML incoraggia la separazione tra come il programma appare e come
funziona (la sua logica, cioè) ed è una cosa molto utile per la manutenzione e
l’aggiornamento del software;
• XAML può essere utilizzato in strumenti come XamlPad, presente nell’SDK
di Windows, o in Visual Studio 2008 e successivi per vedere in real-time il
risultato di ciò che si sta scrivendo;
• XAML è il linguaggio prodotto dalla maggior parte degli strumenti legati a
WPF.
31
4 – Tecnologia utilizzata
In questo paragrafo non si intende insegnare a programmare in XAML o con le
WPF, in quanto esula dagli scopi di questa dissertazione, ma solo presentare alcune
caratteristiche peculiari di XAML in modo da permetterne la comprensione generale.
Alcuni altri dettagli su XAML verranno poi forniti nel capitolo 5, dedicato alla realizzazione di DOGeye; in ogni caso, si rimanda alla documentazione della
Microsoft, disponibile su MSDN, per ulteriori informazioni e dettagli.
4.2.1
Caratteristiche
XAML è, come già detto nel paragrafo precedente, un linguaggio di programmazione
dichiarativo atto a costruire e inizializzare oggetti .NET, incluso nel framework .NET
a partire dalla versione 3.0, insieme a un suo compilatore, a un parser che agisce a
tempo 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 browser
Internet Explorer.
XAML è un modo di utilizzare le API appartenenti al .NET e consiste di regole
che indicano come i parser e i compilatori devono trattare XML e alcune parole
chiave, ma non definisce nessun elemento XML interessante.
Anche se XAML è stato originariamente sviluppato e pensato per WPF, bisogna
tenere presente che le due tecnologie possono essere utilizzate in maniera indipendente l’una dall’altra: per fare un esempio, XAML si può utilizzare anche con le
Windows Workflow Foundation e, addirittura, stanno nascendo plug-in per poter
utilizzare XAML per realizzare interfacce utente con il linguaggio Java. Inoltre,
tutto quello che può essere fatto in XAML può anche essere fatto con un qualunque
linguaggio .NET, perdendo però tutti i suoi benefici: pertanto è raro vedere WPF
senza XAML.
Le specifiche di XAML definiscono, perciò, regole che mappano i vari namespace,
tipi, proprietà ed eventi appartententi a .NET in namespace, elementi e attributi
di tipo XML. Questo si può vedere dal semplice esempio che segue e che mette a
confronto 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 istantaneamente il risultato del codice XAML salvando un file con estensione .xaml e
32
4 – Tecnologia utilizzata
aprendolo in Internet Explorer, mentre per il C# bisognerebbe prima compilare
tutto. Il risultato di entrambi è la creazione di un bottone che avrà come contenuto
la parola “OK”.
Com’è possibile vedere dall’esempio, dichiarare un elemento XML in XAML,
chiamato object element, è equivalente a istanziare il corrispondente oggetto .NET
attraverso il suo costruttore di default.
Impostare un attributo, invece, equivale a impostare una proprietà con le stesso
nome, nel qual caso si parla di attributo di proprietà, o assegnare un handler per un
evento 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 prima riga di XAML compare l’identificatore xmlns, seguito quello che sembra un indirizzo Internet: quello è il namespace XML associato al namespace .NET System.
Windows.Controls. Come per ogni namespace XML, non si trova nessuna web page
a quell’indirizzo: è solo una stringa arbitraria.
Il namespace XAML dell’esempio contiene tutti i seguenti namespace C#, realizzando 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
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 contengono i controlli principali XAML (come i bottoni, per esempio), Forms.Integration
che introduce alcuni metodi per l’integrazione di XAML con elementi creati con le
Windows 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’oggetto
radice di un file XAML deve specificare almeno un namespace che è necessario per
qualificare sé stesso e tutti i suoi figli. In XAML si utilizza, generalmente, anche un
secondo namespace, che include anche il prefisso x; si utilizzerà poi tale prefisso per
indicare 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 namespace
C# System.Windows.Markup e definisce alcune direttive speciali per il compilatore o
il parser XAML. Queste direttive appaiono spesso come attributi di elementi XML,
sembrando proprietà dell’elemento senza però esserlo. I più comuni sono riportati
nella tabella 4.1.
In maniera simile, si possono anche usare degli oggetti dichiarati in una classe
C#, associando il namespace della classe a un prefisso inventato e utilizzando il
prefisso 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 precedente.
Per farlo, si ipotizzi di voler costruire un bottone che abbia, come contenuto, il
simbolo dello “stop” presente nei normali lettori musicali.
Con XAML, è sufficiente utilizzare i cosidetti elementi di proprietà; in questo
caso, come è possibile vedere nell’esempio che segue, si inserisce un quadrato di lato
40 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 della
proprietà:
<Button xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation">
<Button.Content>
<Rectangle Height="40" Width="40" Fill="Black" />
</Button.Content>
34
4 – Tecnologia utilizzata
Keyword
x:Name
x:Class
x:Key
x:Uid
x:Null
x:Static
Descrizione
Associa un nome a un elemento così che possa essere richiamato dal
codice procedurale.
Definisce una classe per l’elemento radice che deriva da un
namespace .NET creato ad-hoc.
Specifica la chiave di un oggetto quando viene aggiunto a un
dizionario.
Segna un elemento con un identificativo utilizzabile per la
localizzazione in più lingue.
Rappresenta un riferimento a null.
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 è doveroso parlare anche di dizionari, control template e stili, visto che si sono utilizzati
abbondantemente in DOGeye.
Uno stile è un’entità WPF relativamente semplice. La sua funzione principale
è quella di raggruppare insieme valori di proprietà che altrimenti potrebbero essere
impostate singolarmente. L’intento di questa entità è quello di poter condividere
questo gruppo di valori tra più elementi, senza così doverli riscrivere tutte le volte e
per ogni singolo elemento.
Per esempio, si potrebbe definire uno stile in cui si stabilisce che la dimensione
del font della scritta che compare in un bottone deve essere di 22 punti, che il suo
sfondo deve essere di colore arancione, che la scritta deve essere bianca e che il
bottone 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
4 – Tecnologia utilizzata
<Setter.Value>
<RotateTransform Angle="10" />
</Setter.Value>
</Setter>
</Style>
Definendo poi questo stile all’interno delle risorse dell’elemento che può contenere
dei bottoni (o dell’elemento radice, se si vuole poter applicare lo stile a tutto il file
XAML), cioè scrivendolo per esempio in <Window.Resource>, si possono assegnare
queste 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, in
questo caso) il cui nome è dichiarato subito dopo e di applicarlo alla proprietà che
lo 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, per
esempio un bottone, bisognerebbe utilizzare i control template. Tramite i control template, infatti, è possibile cambiare forma a un bottone, rendendolo magari
rotondo.
I control template, poi, si possono utilizzare all’interno di uno stile così da poter
usufruire delle caratteristiche di entrambi. In questo modo, cioè, ogni controllo WPF
può essere stilizzato nuovamente in maniera del tutto personalizzabile.
Se poi si volessero raggruppare tutti gli stili in un unico file, in modo da poterli
trasferire da un progetto all’altro o in modo da permettere all’utente di cambiare
aspetto all’applicazione in base alle sue preferenze, basta utilizzare i dizionari, che
servono proprio a questo scopo.
Come si è potuto vedere viene naturale rappresentare un’interfaccia utente in
XAML a causa della sua natura gerarchica, derivata da XML. In WPF, infatti, le
interfacce utente sono costruite da un albero di oggetti chiamato albero logico, da
non confondere con l’albero visuale.
Grazie all’albero logico, i modelli di contenuto possono scorrere prontamente i
possibili elementi figlio e quindi essere estendibili. Inoltre, l’albero logico fornisce
un framework per alcune notifiche, come il caso in cui tutti gli elementi dell’albero
logico vengono caricati ed esso viene così utilizzato per la ricerca delle risorse.
36
4 – Tecnologia utilizzata
L’albero visuale, invece, è un’espansione dell’albero logico, in cui i nodi sono
sviluppati nei rispettivi componenti visuali, mostrando cioè i dettagli della loro
implementazione visuale.
Per esempio, un bottone è logicamente un solo controllo, ma nella sua rappresentazione visuale è composto da più elementi primitivi, come un bordo, una casella
di testo per il suo contenuto e così via.
4.2.2
Code-behind
Introducendo le caratteristiche di XAML, si è mostrato un semplice esempio in cui
veniva 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 ottiene
nel 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 possono
osservare altre due caratteristiche proprie di WPF:
• l’evento Click riportato in XAML richiama il metodo button_Click, che va
dichiarato nel codice procedurale;
• nell’esempio scritto in C# si nota che il metodo button_Click viene richiamato da un RoutedEventHandler; gli eventi in WPF, infatti, sono tutti di tipo
Routed, cioè un evento figlio richiama gli eventi che lo precedono nell’albero
dei controlli, se esistono dello stesso tipo e se non gli è stato imposto di non
farlo.
Il codice procedurale che sta “dietro” a XAML e nel quale si dovrà dichiarare
il metodo button_Click prende il nome di code-behind e può essere un qualsiasi
linguaggio appartenente alla piattaforma .NET, anche se generalmente si predilige
l’utilizzo di C# o di VB.NET.
Quando si crea, con Visual Studio, un nuovo progetto WPF, viene automaticamente creato un file XAML che ha come radice l’elemento Window (a indicare che
quello è un file XAML creato per realizzare un’applicazione desktop) e un file di
37
4 – Tecnologia utilizzata
codice procedurale, per esempio C#, che conterrà una classe parziale che eredita
proprio 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 binario
speciale, chiamato BAML (Binary Application Markup Language), verrà inserito
il contenuto di tale file come risorsa binaria dell’assembly costruito dal C# e si
effettueranno le connessioni automatiche tra XAML e il codice procedurale.
Nonostante il fatto che tutto quello che si può fare in XAML si può realizzare
anche nel suo code-behind, ci sono alcuni meccanismi e strumenti che sono ottimizzati
per 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ù possibile
l’idea che sta dietro all’accoppiata XAML e code-behind, quella cioè di utilizzare
XAML per scrivere come appare l’interfaccia utente e il codice procedurale per
realizzare la logica di questa interfaccia.
4.3
Compatibilità con le tecnologie precedenti
Windows Presentation Foundation è pienamente compatibile e può interoperare con
le seguenti tecnologie:
38
4 – Tecnologia utilizzata
• Win32 - è possibile inserire controlli Win32 in applicazioni WPF e controlli
WPF in applicazioni Win32;
• Windows Forms - è possibile inserire controlli Windows Forms in applicazioni
WPF 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 realizzata
con WPF, questa possibilità di interazione può essere una cosa molto utile, soprattutto nel caso in cui si sia già realizzato un controllo e non lo si voglia o non lo si
possa riscrivere da zero. Per realizzare DOGeye, ci si è ispirati ad alcune di queste
tecniche per integrare l’ETU-Driver che, ricordiamolo, è composto da oggetti COM
e sfrutta il sottosistema grafico GDI+ per le sue necessità interne.
Un altro motivo per cui si può voler integrare WPF con una delle tecnologie
precedenti, può essere perché si vuole utilizzare qualche caratteristica del sistema
operativo 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 integrare
una pagina HTML dentro un controllo WPF chiamato Frame e anche un controllo
WPF dentro HTML, creando una XAML Browser Application oppure come una
pagina XAML libera, utilizzando il controllo iFrame di HTML.
WPF, inoltre, è compatibile con tutte le tecnologie già utilizzabili con la piattaforma .NET.
Nei prossimi sotto-paragrafi, si fornirà una panoramica di come queste interazioni
sono 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 interagiscono con loro attraverso degli handle conosciuti come HWND. Tutte le tecnologie
basate 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 tutte
queste 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 delle
classi più alte e generali nella gerarchia delle classi WPF) che può ospitare proprio
un HWND.
Questo FrameworkElement si chiama System.Windows.Interop.HwndHost e permette di utilizzare questi controlli proprio come se fossero controlli nativi WPF.
39
4 – Tecnologia utilizzata
L’unico “problema” è che questi controlli sono generalmente scritti in C++, e dovrà essere incluso in un altro file C++ in modalità managed che, però, non supporta
la compilazione di XAML.
4.3.2
Integrare controlli WPF in Win32
Sono molte le funzionalità interessanti di WPF che possono essere integrate in un’applicazione 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 utilizzando
altre caratteristiche di WPF, come il suo layout flessibile e l’indipendenza dalla
risoluzione.
L’interoperabilità di WPF con HWND è bidirezionale, così che i controlli WPF
possono essere inseriti nelle applicazioni Win32 più o meno allo stesso modo in cui
i controlli Win32 sono inseriti in applicazioni WPF: si utilizza, in questo caso, la
classe HwndSource, che espone ogni controllo visuale di WPF come un HWND.
Questa classe si può utilizzare anche in un’applicazione pura WPF per rispondere
ad 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 realizzare
questo 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 .NET
che 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 riga
di codice non gestito.
Come per l’interoperabilità con Win32, WPF definisce una coppia di classi per coprire entrambe le direzioni dell’interazione. L’equivalente di HwndHost prende il nome
di WindowsFormsHost e fa parte del namespace System.Windows.Forms.Integration.
L’host di integrazione va creato all’interno di un nuovo metodo privato che viene
chiamato dall’evento Loaded di WPF. Tale evento dice non solo che l’albero logico dell’applicazione è costruito e inizializzato, cosa che tra l’altro fa già l’evento
di inizializzazione richiamato dal metodo InitializeComponent(), ma anche che il
layout deve agire su di esso, che i dati sono stati tutti collegati, che è stato connesso
a una superficie di rendering (la finestra) e che è sul punto di essere renderizzato
completamente.
40
4 – Tecnologia utilizzata
Il controllo Windows Forms va inserito proprio in quel punto poiché necessita
di avere già tutte le informazioni relative alla finestra e al suo rendering, essendo
basato su un sottosistema grafico diverso da quello di WPF.
Inoltre, aggiungendo un manifest file, è possibile applicare anche ai controlli
Windows Forms le eventuali modifiche stilistiche che sono state effettuate ai controlli
WPF, facendo sì che tutta l’interfaccia abbia lo stesso look-and-feel.
Per integrare, invece, un controllo WPF in un’applicazione Windows Forms si
utilizza la classe ElementHost, un controllo Windows Forms che, internamente, sa
come trattare contenuti WPF.
4.3.4
Integrare controlli ActiveX in WPF
L’integrazione con i controlli ActiveX è un esempio di retro-compatibilità piuttosto
che di innovazione: WPF, infatti, eredita questa possibilità da Windows Forms. In
pratica, 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, sulla
DLL ActiveX;
• aggiungendo il controllo ActiveX in un progetto Windows Forms tramite il
designer di Visual Studio; questo causerà la chiamata dell’ActiveX Importer
da parte di Visual Studio.
Indipendentemente da quale approccio si voglia seguire, come risultato si ottiene
la generazione di due DLL. Per ottenere l’interoperabilità tra le due tecnologie, basta
aggiungerle al progetto WPF e predisporlo per l’integrazione con le Windows Forms,
richiamando poi i metodi necessari dalla seconda DLL ActiveX (quella il cui nome
inizia con “Ax”).
L’integrazione di controlli WPF in ActiveX, invece, non può essere fatta con
meccanismi simili ai precedenti: gli sviluppatori di WPF non hanno predisposto
questa 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 Foundation e Windows Forms (in seguito, abbreviato con WinForms) dovrebbero essere
abbastanza evidenti, anche se WPF non nasce per sostituire Windows Forms.
41
4 – Tecnologia utilizzata
Allo stesso modo, dovrebbe essere evidente quale delle due preferire, se non
si hanno particolari esigenze e si vuole costruire un’interfaccia utente moderna e
potente, risparmiando tempo e risorse.
In questo paragrafo, si riassumeranno queste differenze, sottolineando prima i
vantaggi che si ottengono utilizzando WPF e poi gli svantaggi, facendo sempre
riferimento 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 a
piacere e con lo stile che si vuole: se si preferisce o si deve mantenere lo stile
dell’interfaccia utente perfettamente coerente con l’interfaccia di Windows si
può fare; se la si vuole stravolgere completamente, pure.
Questo strumento, di per sé, potrebbe essere anche uno svantaggio, se usato
senza cognizione, creando così interfacce scarsamente usabili.
2. la semplicità con cui è possibile creare un proprio look-and-feel nell’interfaccia utente che si sta realizzando; addirittura esiste un programma, chiamato
Microsoft Expression Blend, che permette di costruire la parte XAML dell’interfaccia senza scrivere una riga di codice dichiarativo. Ovviamente, come
tutti i programmi che producono codice automaticamente, non produce un
codice 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 è parlato
brevemente nel paragrafo precedente.
4. WPF rappresenta la futura tecnologia per sviluppare applicazioni per Windows
utilizzando la piattaforma .NET. Quindi può essere una buona idea dedicarci
del 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 davvero
minimi; in altri, addirittura inesistenti. Quindi, con poco sforzo, si possono
riadattare parti di applicativi per essere utilizzati con WPF, anche se poi
bisogna comunque sviluppare la parte in XAML.
6. il databinding nettamente superiore rispetto a quello di WinForms, dove per
databinding si intende un modo per gli sviluppatori di creare un collegamento
di lettura/scrittura tra i controlli dell’interfaccia utente e i dati necessari per
la parte logica dell’applicazione.
42
4 – Tecnologia utilizzata
7. l’integrazione semplice e potente di diversi tipi di media nell’interfaccia utente. Per esempio, se c’è bisogno di includere un video o un documento o un
contenuto 3D o una transizione animata tra una sequenza di immagini o una
combinazione dei precedenti.
8. la possibilità offerta da XAML di essere visualizzato direttamente in un browser
web e in tempo reale, senza necessità di compilazione.
9. la possibilità di caricare dinamicamente solo una porzione di una interfaccia
utente da un servizio Web o se si vuole creare un’applicazione desktop con
un 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è caricata (e scaricata) la parte di un controllo utente che interessa solo nel momento
in cui essa viene visualizzata. Per esempio, si immagini di avere una lista di
centomila elementi, magari rappresentati con delle immagini. Sull’interfaccia
utente, se ne possono visualizzare dieci alla volta, per il semplice fatto che
tutti e centomila sullo schermo non ci stanno. La virtualizzazione consiste
nel caricare in memoria solo i dieci elementi visibili e di non caricare tutti gli
altri. Appena si andrà avanti nella lista, gli elementi non più visibili saranno
scaricati, mentre quelli visibili verranno caricati.
12. il supporto interno al 3D e alle operazioni grafiche di base (rotazione, traslazioni, effetti bitmap e così via).
4.4.2
Svantaggi
Tra gli svantaggi derivati dall’utilizzo di WPF nei confronti di WinForms, è necessario ricordare:
1. un’applicazione prodotta con WPF richiede almeno il framework .NET versione 3.0, installato di default a partire da Windows Vista ma disponibile anche
per Windows XP.
2. la necessità di avere una scheda grafica compatibile con le DirectX 9, se si vuole
usufruire di alcuni aspetti avanzati della grafica e della possibilità di utilizzare
la GPU per determinate operazioni, invece che la CPU.
43
4 – Tecnologia utilizzata
3. la curva di apprendimento di WPF; se si volesse rappresentare con una curva
matematica, si potrebbe utilizzare la funzione esponenziale: l’apprendimento
è molto semplice all’inizio ma, man mano che si apprendono cose nuove e si
necessita di funzionalità sempre più avanzate, l’apprendimento diventa molto
difficoltoso.
4. la “gioventù” di WPF rispetto a WinForms: queste ultime hanno certamente
più controlli di terze parti disponibili, risorse online, comunità di sviluppatori
e così via.
5. gli strumenti per il design dell’interfaccia inclusi in Visual Studio 2008 funzionano molto meglio per WinForms che per XAML.
6. interoperabilità non ancora perfetta di WPF con componenti perfettamente
funzionanti se utilizzate con WinForms.
C’è però da dire che la maggior parte di questi svantaggi o non sono così rilevanti
o sono derivati dalla relativa gioventù di questa tecnologia. E quest’ultimo aspetto
sarà superato dal trascorrere del tempo. . .
Tabella 4.2: Vantaggi e svantaggi di WPF
Vantaggi
Svantaggi
alta personalizzazione dell’aspetto designer di Visual Studio 2008 perfedella UI
zionabile
separazione tra UI e logica del necessità di scheda video compatiprogramma
bile con DirectX 9 per performance
migliori
futura tecnologia .NET
curva di apprendimento molto ripida
possibilità di riutilizzare codice proce- ancora poche risorse di terze parti
durale .NET
disponibili
databinding estremamente potente
necessita .NET 3.0 o superiore
orientato al web
integrabile con dei servizi web
adatto a contenuti multimediali e 3D
possibilità di avere parti della UI
virtualizzate
44
Capitolo 5
Progettazione e implementazione
In questo capitolo verranno presentate le varie fasi che hanno portato alla realizzazione dell’interfaccia utente DOGeye (nome formato da DOG più EYE interaction,
ndr ), mostrando l’architettura dell’ambiente in cui andrà a collocarsi, esponendo e
motivando le scelte progettuali fatte e analizzando gli aspetti più interessanti della sua realizzazione da punto di vista della programmazione con le WPF e con
l’ambiente .NET in generale.
5.1
Introduzione
DOGeye è stato sviluppato in base a due vincoli principali, come già accennato
nel capitolo 2 di questa tesi: da una parte l’applicazione deve essere in grado di
interagire 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
5 – Progettazione e implementazione
La figura 5.1 mostra tale architettura: l’applicazione comunica con l’ambiente
domotico attraverso DOG (a sinistra), grazie al protocollo XML-RPC che gli permette 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 controllare
l’eye-tracking, sia esso simulato dal driver stesso o reale.
Facendo riferimento alle specifiche COGAIN, in particolare al Deliverable 2.5, il
vincolo sull’ETU-Driver è imposto dalla linea guida 2.1.
La realizzazione della versione di DOGeye presentata come risultato finale di
questo progetto, inoltre, ha richiesto tre fasi preliminari:
• lo studio delle caratteristiche di DOG, dell’ETU-Driver e delle specifiche COGAIN, 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 comprendere i meccanismi di funzionamento di DOG, testarne i requisiti per il collegamento con l’interfaccia e comprendere come effettuare tale collegamento; per iniziare
a lavorare con WPF e XAML e, infine, per integrare l’ETU-Driver e verificarne il
funzionamento.
Figura 5.2: La versione preliminare di DOGeye
46
5 – Progettazione e implementazione
Il collegamento con DOG, effettuato grazie a XML-RPC, non ha dato alcun tipo
di problema.
Viceversa, l’integrazione con l’ETU-Driver ha presentato qualche difficoltà: il suo
creatore, infatti, insieme al driver mette a disposizione il codice di programma scritto
in C# in cui è possibile vedere come inserire il driver all’interno di un’interfaccia
utente (scritta utilizzando Windows Forms) e come utilizzarne le funzionalità.
Il problema è che, integrando il driver nel modo suggerito, l’interfaccia utente
scritta in WPF non funzionava per niente, invocando un’eccezione e chiudendosi
senza 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 Win32
che 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 messe
in atto realizzando questa versione preliminare dell’interfaccia.
È il caso di spendere due parole per descrivere questa interfaccia utente preliminare; 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 utilizzare
l’eye-tracking come meccanismo di interazione.
La seconda area orizzontale, a sua volta, è divisa in due parti: la prima che
contiene l’elenco dei dispositivi presenti nella stanza selezionata e la seconda (a
destra) che appare quando viene selezionato un dispositivo e che contiene lo stato
del dispositivo e dei bottoni per comandarlo.
Se non è possibile comandarlo dall’interfaccia (perché DOG stabilisce che è un
dispositivo comandabile solo dalla casa reale, come accade per gli interruttori, per
esempio), l’area di destra presenta solo lo stato attuale del dispositivo.
La terza area orizzontale, invece, contiene un log testuale che mostra in cima
l’ultima operazione compiuta dall’interfaccia utente o dalla casa e tre pulsanti per
impostare alcune preferenze dell’ETU-Driver (il bottone Options), per avviare la
calibrazione 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 selezionare la modalità di simulazione dell’ETU-Driver dalle opzioni e avviare il tracciamento che, in questo caso, sarà simulato dalla posizione del puntatore del mouse.
L’interfaccia, in ogni caso, è utilizzabile sia attraverso l’eye-tracking che attraverso il mouse.
47
5 – Progettazione e implementazione
Questa interfaccia preliminare, però, nasce solo per scopi di apprendimento e di
testing, e non rispetta quasi nessuna delle linea guida offerte dal COGAIN.
Inoltre, essa offriva solo alcune funzionalità di base e non si erano studiate
funzionalità più evolute.
È stato, quindi, necessario pensare un’interfaccia utente totalmente nuova, DOGeye appunto, che si descriverà nel paragrafo successivo e della quale si riporta, in
figura 5.3, il mock-up che è stato realizzato con carta e matita prima di iniziarne lo
sviluppo 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 logiche:
Tabs area (o area dei tab) - è la parte dell’interfaccia che contiene i tab con i quali
si realizzano diverse viste dell’ambiente, in base al tipo di dispositivo che si
vuole utilizzare. Rappresenta la vista funzionale della casa.
Selection area (o area di selezione) - è la parte dell’interfaccia che si occupa delle
possibilità di selezione e visualizzazione: della stanza, del dispositivo e così
via. Rappresenta la vista strutturale della casa.
48
5 – Progettazione e implementazione
Command area (o area di comando) - è la parte dell’interfaccia che contiene
i comandi che si possono impartire ai dispositivi della casa e all’interfaccia
stessa.
Notification area (o area di notifica) - è l’area che si occupa di visualizzare le
notifiche e gli allarmi all’utente.
Figura 5.4: L’interfaccia DOGeye
Le prime due aree nascono dall’esigenza, sottolineata dal Deliverable 2.5 di
COGAIN, 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 permette di scegliere il tipo di dispositivo o il tipo di operazione che si vuole fare (vista
funzionale); il secondo permette di scegliere il dispositivo all’interno della casa o di
compiere l’operazione vera e propria, nel caso si tratti di un’operazione di più alto
livello, come per i già citati scenari.
La terza area nasce dall’esigenza di rispondere alla linea guida 1.4 che raccomanda di “fornire una richiesta di conferma per le operazioni critiche e possibilmente
dannose”: avere un’area apposita nella quale si possano comandare i dispositivi ed
effettuare altre operazioni solo dopo aver selezionato un oggetto offre, a diversi livelli, le stesse funzionalità di una richiesta di conferma, sia utilizzando DOGeye con
49
5 – Progettazione e implementazione
il mouse che con un eye-tracker, dove l’errore introdotto dal tocco di Mida viene
minimizzato 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 eseguita
qualche 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’interno
di DOGeye, come modalità di output supplementare rispetto alla visualizzazione
grafica: quando si dà il comando per entrare in una stanza e quando si comanda
un dispositivo, oltre alla notifica visiva dell’operazione, viene emessa anche una
notifica audio. Quindi, per esempio, accendendo la lampada chiamata, all’interno
della casa, “Lamp1”, si sentirà la frase “Lamp1 switched on”. Attualmente DOGeye è
localizzato in inglese e quindi anche la sintesi vocale è nello stesso linguaggio. Questa
funzionalità è stata ispirata dalla linea guida 4.4 che, nella sua descrizione, suggerisce
di “evidenziare un cambiamento di stato di un dispositivo utilizzando immagini, testo
e suoni”.
Il secondo aspetto è una funzionalità di allarme che può essere invocata dall’utente nel caso in cui abbia bisogno di un qualche tipo di aiuto: è collocato sul lato
destro dell’area di notifica come un pulsante che rimane invisibile fintanto che non
lo si guarda (o non ci si passa il mouse sopra).
Interagendo con esso, viene riprodotto un suono di allarme e viene visualizzata
una finestra in primo piano che impedisce di eseguire qualsiasi tipo di operazione in
DOGeye fintanto che non viene premuto il pulsante di stop:
Figura 5.5: Aspetto di DOGeye quando l’utente necessita qualche tipo di aiuto
50
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, nessuna
selezione eseguita.
• ognuno è rappresentato da un’icona di colore differente e da un testo esplicativo: studi dimostrano, infatti, che associare un’icona a un’etichetta di testo
riduce notevolmente la possibilità di cattiva interpretazione e di errore da parte
di un utente, rispetto all’utilizzare solo un’icona o solo un breve testo.
• per sapere quale tipo di dispositivo deve essere collocato in un determinato
tab, viene consultato un file testuale di configurazione. Questa caratteristica
potrà essere integrata in DOG, in futuro.
Il quarto e ultimo aspetto generale riguarda la scelta del colore dei bottoni utilizzati nell’interfaccia utente, scelta che non è casuale ed è coerente lungo tutta
l’interfaccia: si è cercato, infatti, di abbinare un colore diverso in base alle diverse
funzioni 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 orizzontalmente verso il grigio chiaro), si sono divisi i pulsanti nelle cinque aree funzionali
riportate in tabella 5.1 e, per ognuno, si è associato un colore opportuno.
È necessario, ancora, spendere due parole riguardo alla modalità di interazione
con DOGeye. Oltre alla semplice interazione con il mouse, si è detto, questa interfaccia è utilizzabile anche con l’ausilio dell’eye-tracking. Per non incorrere nell’errore
del tocco di Mida, all’inizio di questo paragrafo si diceva di utilizzare la tecnica del
dwell time. Questo tempo di attesa è impostabile a piacere dall’utente, in base alla
sua esperienza nell’utilizzare l’eye-tracker e alle sue capacità fisiche.
Non tutta l’interfaccia, però, utilizza questa tecnica: essa viene utilizzata soprattutto dove ci sono comandi dati alla casa, piuttosto che operazioni che rimangono interne all’interfaccia in quanto, in caso di errore, non si è commessa nessuna
operazione né reale né critica o dannosa.
Pertanto, le operazioni di selezione, come la selezione di una stanza, avvengono
senza l’ausilio del dwell time; operazioni di comando sui dispositivi della casa e operazioni che utilizzano dei bottoni, invece, sì. Tali operazioni vengono anche indicate
visivamente da un grafico a torta che compare sul bottone con il quale si sta interagendo, grafico che si completerà pian piano fino al raggiungimento del dwell time
fissato. A quel punto, l’azione collegata al pulsante verrà eseguita.
D’ora in avanti non si farà più questa distinzione e per indicare un’interazione
con un oggetto dell’interfaccia utente si utilizzerà il termine “click ” e i suoi derivati,
come se si agisse sempre con il mouse.
51
5 – Progettazione e implementazione
Tabella 5.1: Attribuzione dei colori ai bottoni dell’UI in base alla loro funzione
Funzione
Comando positivo
Comando negativo
Comando neutro
Selezione
Comandi di interfaccia
5.2.1
Descrizione
Colore
Rientrano in questa categoria i comandi come “accendi” o “apri”, quelli cioè
che danno l’idea di un’azione positiva
Rientrano in questa categoria i comandi come “spegni” o “chiudi”, ma anche quelli che rappresentano la fine di
un’operazione in corso, come “stop”
Rientrano in questa categoria i comandi che non possono essere inseriti nelle
categorie precedenti o quelli che possono rappresentare più comportamenti,
come il comando “imposta a. . . ”
Rientrano in questa categoria i pulsanti che attivano/disattivano le funzionalità di selezione di stanze o dispositivi
all’interno dell’interfaccia
Rientrano in questa categoria i comandi relativi all’interfaccia che non svolgono alcuna azione reale nella casa,
come “Entra nella stanza”
Verde
Rosso
Grigio
Nero
Blu
“Home Management” ed “Electric Device”
Per analizzare più in dettaglio le scelte progettuali e le funzionalità dei tab, si è scelto
di fare un unico discorso per i primi due, in quanto essi hanno le stesse caratteristiche
e le stesse funzionalità.
Quello che cambia è il tipo di dispositivi che comprendono:
• in Home Management compaiono i dispositivi basilari di un’abitazione, come
gli interruttori, le tapparelle, le luci, le porte, ecc.;
• in Electric Device, invece, compaiono tutti quei dispositivi che si collegano a
una spina di corrente, come una macchinetta del caffè. Se sono sufficientemente
evoluti e riescono a dichiarare che elettrodomestico sono, vengono visualizzati
per quello che sono; altrimenti appaiono rappresentati come “spine” (plug).
Per semplicità, quindi, in questo sotto-paragrafo ci si riferirà a entrambi i tab
come se fossero uno solo.
52
5 – Progettazione e implementazione
Appena si clicca sopra il tab, viene mostrata nell’area di selezione, la planimetria
della casa con delle miniature dei dispositivi presenti nelle stanze (fig. 5.6): l’area
di controllo rimane invisibile così come l’area di notifica.
Figura 5.6: La planimetria della casa, così come viene visualizzata in “Home
Management”
Le informazioni disponibili sulle stanze e sui vari dispositivi al loro interno vengono 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 stanze
all’interno della casa né le loro dimensioni.
Per realizzare questa funzionalità, pertanto, si è creato un file XML contenente
la dimensione in metri delle stanze e la loro posizione relativa, del quale se ne riporta
una 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
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 height
e una larghezza width entrambe definite in metri; ha poi una posizione lungo X e
lungo Y, anch’essa definita in metri. La posizione (0,0) è rappresentata nel sistema
ortogonale proprio delle interfacce grafiche, cioè nell’angolo in alto a sinistra della
finestra.
DOGeye, all’avvio, legge la configurazione della casa da DOG e unisce le informazioni contenute in questo file. Dopodiché, converte le dimensioni delle stanze in
modo tale da poter visualizzare interamente la planimetria della casa nell’area di
selezione.
Questa funzionalità è stata implementata per migliorare l’aspetto di DOGeye e
per fornire una visualizzazione immediata degli stati e della posizione dei dispositivi
all’interno della casa (linea guida 4.3).
Selezionando una stanza, il comportamento dell’interfaccia varia in base al numero di dispositivi che contiene, in modo da non richiedere all’utente di interagire
con l’interfaccia più di quanto ci sia davvero bisogno.
Se la stanza:
• non contiene nessun dispositivo, nell’area di controllo viene visualizzata la
descrizione della stanza selezionata, fornita da DOG;
• contiene un dispositivo solo, nell’area di controllo viene visualizzata la descrizione della stanza selezionata, il nome e lo stato (sia graficamente che
testualmente) dell’unico dispositivo presente e vengono mostrati i bottoni per
comandarlo;
• contiene più di un dispositivo, nell’area di controllo viene visualizzata la descrizione della stanza selezionata, un pulsante “Go in! ” per accedere alla stanza e
visualizzare tutti i dispositivi in essa contenuti, e due bottoni che permettono
di eseguire semplici operazioni su tutti i dispositivi di un certo tipo contenuti
nella 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
5 – Progettazione e implementazione
(a) Nessun dispositivo.
(b) Un solo dispositivo.
(c) Più di un dispositivo.
Figura 5.7: I tre possibili comportamenti ottenibili selezionando una stanza nei primi
due tab di DOGeye
semplici e di gruppo (come accendere tutte le luci della stanza) è sufficiente cliccare
sul 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 sul
quale si vuole agire e ottenere il risultato desiderato.
Altrimenti, basta premere il pulsante “Go in! ” per entrare nella stanza. Entrati
nella 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 tipo
e di eseguire una selezione multipla, sempre tra dispositivi dello stesso tipo: non
avrebbe senso, infatti, voler comandare una porta e una luce fornendo a entrambi
lo stesso comando da eseguire.
Cliccando sul bottone di selezione multipla, esso cambia nome, permettendo
così di ritornare alla selezione singola. L’area di selezione, intanto, rimane identica
finché non si seleziona un dispositivo. A quel punto, tutti i dispositivi di tipo diverso
diventano “opachi” e non sono più selezionabili.
Per renderli nuovamente selezionabili bisogna de-selezionare tutto (cliccando nuovamente sui dispositivi già selezionati) o cliccare sul pulsante di selezione singola.
Queste funzionalità di selezione non sono altro che un’estensione delle funzionalità già esistenti in Windows; pertanto possono essere classificate come “semplici da
imparare”, rispettando così la linea guida 4.5.
55
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 di
testo;
• 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 della
casa.
La scelta di avere un dispositivo rappresentato in forma testuale e in forma grafica
deriva dal fatto che è più semplice e intuitivo riconoscere lo stato di un dispositivo
dalla sua immagine; in caso, però, di incomprensione, avere un’etichetta di testo che
riassuma le stesse informazione diventa essenziale. Inoltre, offre i requisiti per rispettare la linea guida 4.4 (“usare colori, icone e testo per evidenziare un cambiamento
di stato”).
Si immagini, ora, di voler comandare l’attuatore che controlla l’apertura e la
chiusura di una porta. In particolare, si vuole aprire questa porta. Una volta
selezionato l’attuatore in questione, nell’area di controllo appare quanto visualizzato
nella figura 5.8 (a).
Come si può vedere dalla figura, l’unico bottone selezionabile è “Open”: non
avrebbe infatti senso cercare di chiudere una porta già chiusa.
Agendo sul bottone “Open”, si può vedere, grazie alla figura 5.8 (b), che esso
diventa impossibile da selezionare, mentre è selezionabile il bottone “Close”; inoltre,
il nuovo stato aggiorna immediatamente l’icona della porta e la sua etichetta di
testo. Allo stesso tempo, vengono anche aggiornate le icone presenti nell’area di
selezione e, tornando alla planimetria della casa, anche la miniatura lì presente.
Infine, il sintetizzatore vocale annuncia il cambiamento di stato e nell’area di
notifica 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 quanto
riguarda la visualizzazione dello stato dei dispositivi; 4.1, fornendo una chiara visualizzazione di ciò che accade nella casa; 3.6, permettendo di conoscere lo stato
corrente di ogni dispositivo; e 3.1 poiché, data l’immediatezza delle operazioni, permette di rispondere agli eventi e ai comandi dell’ambiente domotico praticamente
in tempo reale.
56
5 – Progettazione e implementazione
(a) Prima:
chiusa.
porta
(b) Poi: porta aperta.
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 un
dispositivo, in qualunque parte dell’interfaccia esso si trovi, è quella di essere stata realizzata sfruttando una caratteristica di WPF. Tale feature è implementata
dall’interfaccia INotifyPropertyChanged.
Per utilizzarla è stato sufficiente ereditare tale interfaccia nella classe C# che
definisce la struttura dati del singolo dispositivo. Dopodiché è stato necessario
aggiungere alla parte set della proprietà Img, quella cioè che contiene l’immagine
del 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
5 – Progettazione e implementazione
PropertyChanged(this, new PropertyChangedEventArgs(propertyName));
}
Così facendo si è creato un evento di notifica per la proprietà Img. La stessa
cosa viene fatta per l’immagine che compare nell’area di notifica e per la stringa che
rappresenta lo stato del dispositivo nell’area di comando.
Quando si verifica un cambiamento di stato di un dispositivo, ogni controllo
XAML che prende il proprio contenuto da quella proprietà, ovunque esso sia, si
aggiorna automaticamente, come se eseguisse un refresh su se stesso.
Questa funzionalità, insieme al comportamento dell’area di comando quando un
dispositivo viene selezionato e al comportamento dell’area di notifica, è comune a
quasi 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 i
dispositivi legati allo svago e al divertimento, come i media center, che hanno la
caratteristica di avere molti stati e molti comandi disponibili.
Tali dispositivi, però, non sono supportati dall’attuale versione di DogOnt e
pertanto le sue funzionalità si sono sviluppate senza poterle sperimentare attraverso
DOG.
La sua area di selezione mostra, come nei tab precedenti, la planimetria della
casa con le miniature dei dispositivi distribuiti nelle varie stanze. Se una stanza non
contiene dispositivi, selezionandola, sarà possibile visualizzare solo la sua descrizione.
Se, invece, ne contiene almeno uno, sarà possibile entrare nella stanza. In questo
caso, 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 questi
dispositivi 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 pulsante
per uscire dalla stanza mentre compariranno, nell’area di selezione, altre icone: esse
rappresentano 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 dei
CD inseriti in un media center sono rappresentati con un’icona apposita e separati
da quelli per controllare l’esecuzione degli MP3, sempre attraverso lo stesso media
center.
Selezionando una di queste icone-gruppo, nell’area di comando compariranno i
singoli comandi che si potranno impartire.
Questo è necessario poiché, a causa dell’elevato numero di comandi possibili, essi
non potrebbero essere visualizzati tutti nell’area di comando con una dimensione
sufficiente a essere selezionati attraverso il tracciamento dell’occhio.
58
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 singola
stanza.
Il tab si apre mostrando nell’area di selezione la planimetria della casa. A differenza del solito, però, essa non contiene la miniatura dei dispositivi né, selezionando
una 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
5 – Progettazione e implementazione
Essa mostra, semplicemente, un quadratino nell’angolo in basso a destra di ogni
singola stanza; in questo quadratino è rappresentata la temperatura impostata all’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 il
dispositivo di riscaldamento di quella stanza direttamente tramite l’area di comando.
Comandi possibili possono essere “On”, “Off” e “Set”, che permette di impostare la
temperatura 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 un
bottone per ogni valore impostabile e il pulsante Cancel nel caso in cui non si voglia
fare alcuna modifica alla temperatura.
Nell’area di selezione, inoltre, sono disponibili due pulsanti, uno predisposto per
la selezione multipla delle stanze e uno per selezionarle tutte, in modo da poter
impostare la temperatura dell’intera casa in un colpo solo, come mostrato in figura
5.12.
Figura 5.12: Esempio di come si imposta la temperatura del riscaldamento di tutta
la casa
60
5 – Progettazione e implementazione
5.2.4
Security e gli allarmi
Il tab “Security” è, nuovamente, un tab sperimentale in quando si occupa di gestire
gli impianti di allarme (antifurto, anti-incendio, sensore di fumo e così via) della
casa e di fornire all’utente un allarme nel caso in cui uno di questi impianti venga
azionato, 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 in
locale 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 possono
essere comandabili da DOGeye oppure no, in base al dispositivo analizzato: un
sensore di rilevazione per le fughe di gas sarà sempre attivo e quindi non potrà essere
comandato, mentre un impianto antifurto necessiterà di essere attivato quando gli
abitanti della casa lasciano l’abitazione e disattivato al loro ritorno.
Inoltre, essendo questo un tab che si propone di gestire la sicurezza all’interno
della casa, esso è predisposto per effettuare lo streaming video di ciò che capita nelle
varie stanze, a patto che la stanza venga selezionata dalla planimetria della casa e
che contenga una videocamera predisposta a questo scopo.
61
5 – Progettazione e implementazione
Questa funzionalità può essere utile soprattutto quando viene scatenato un allarme: l’utente può così verificare cosa sta capitando all’interno della stanza e
intraprendere l’azione più consona alla situazione.
Questo tab, pertanto, dopo aver selezionato una stanza che contiene un dispositivo di sicurezza non comandabile (un sensore per la rivelazione di fumo) e la
videocamera 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ù dettaglio
ciò che accade nella stanza.
Questa stessa funzionalità viene anche utilizzata di default quando scatta un
allarme. Per semplicità, si consideri il seguente esempio: l’utente si trova in cucina e vuole comandare un dispositivo elettrico che si trova nel corridoio della sua
abitazione.
Pertanto, accede a DOGeye, va nel tab “Electric Device” e seleziona la stanza che
rappresenta il corridoio. A quel punto, però, scatta un allarme (figura 5.14). L’operazione 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 da
un suono di allarme e dalla presenza, nell’area di notifica, del messaggio che indica
l’attivazione di un sensore di fumo; tale messaggio differisce dalle normali notifiche
poiché è colorato di rosso.
Figura 5.14: Esempio di gestione di un allarme
62
5 – Progettazione e implementazione
Questa funzionalità, introdotta in questo modo, rispetta la linea guida 1.1, che
suggerisce di “fornire un sistema di notifiche per gli allarmi veloce, facile da capire e
multimodale”: essa è veloce, semplice e coinvolge modalità di allarme diverse, quella
audio 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 cui
si 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 di
allarme, ha bisogno di poche e chiare opzioni per gestire l’emergenza, onde evitare
di agitarsi e non sapere che azione intraprendere. Inoltre, questo fatto è anche
suggerito dalla linea guida 1.2.
Quando l’utente decide per una delle due azioni messe a disposizione dalla finestra di notifica dell’allarme, il sistema di sintesi vocale ripete la scelta effettuata
e chiude la finestra, permettendo così all’utente di ritornare a utilizzare DOGeye
esattamente nello stesso punto in cui lo aveva lasciato.
Nel caso in cui, invece, l’utente non riesca a decidere quale azione intraprendere
per 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, chiudendo
poi la finestra di allarme: nell’esempio, allo scadere di un certo time-out, il sistema
chiamerà i soccorsi e lo notificherà all’utente attraverso la sintesi vocale. Quest’altra
funzionalità rispetta la linea guida 1.3.
5.2.5
Scenarios
Anche il tab “Scenarios” rientra nella categoria dei tab sperimentali, in quanto DOG
non supporta ancora questo tipo di caratteristica.
Uno scenario, come già accennato in precedenza, è un elenco di attività riguardanti determinati dispositivi domestici che possono venire attivati o disattivati tutti
insieme 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 di
inserire nell’interfaccia utente la possibilità di creare, modificare e cancellare scenari.
In questo caso, DOGeye gestisce solo dei semplici scenari: permette, cioè, di
salvare su un file testuale l’attuale configurazione dei dispositivi della casa, di assegnargli un nome e di poterla caricare ed eseguire ogni qual volta l’utente lo
desideri.
63
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à di
eseguire automaticamente uno scenario a un orario prestabilito e quella di poterne
interrompere 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 versione 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 permetteva
di assegnare ogni dispositivo al corretto tab è memorizzata in un file di configurazione
testuale.
Tale file può essere così composto:
SimpleLamp=HM
Button=HM
DoorActuator=HM
ShutterActuator=HM
DimmerLamp=HM
Plug=ED
CoffeeMaker=ED
GasHeather=Temp
SmokeSensor=SD
La stringa che si trova a sinistra del segno di uguale rappresenta il tipo di dispositivo, mentre la stringa che si trova a destra dell’uguale indica il tab in cui tale
dispositivo va inserito.
Si supponga, ora, di collegare alla casa un nuovo dispositivo e di dimenticarsi
di aggiungerlo a tale elenco: per quanto detto finora, questo nuovo dispositivo non
verrebbe 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, se
esistono.
Esso mostra la planimetria della casa con, all’interno di ogni stanza, gli eventuali
dispositivi che non compaiono nel file di configurazione, fornendo anche la possibilità di comandarli e di vederne lo stato. Non offre, però, tecniche più avanzate di
selezione, come la selezione multipla, poiché è da intendersi come una collocazione
64
5 – Progettazione e implementazione
provvisoria: il dispositivo, infatti, dovrebbe essere collocato al più presto nel tab
corretto.
5.2.7
Settings
Il tab “Settings”, infine, presenta le impostazioni necessarie a DOGeye, a DOG e
all’ETU-Driver. Esso è il tab selezionato di default quando viene avviata l’interfaccia
utente.
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’eyetracker 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 in
cui si vuole visualizzare DOGeye e uno per cambiare l’aspetto visuale dell’interfaccia.
5.3
Realizzazione dell’interfaccia utente
Nel paragrafo precedente, si sono mostrate le funzionalità e le caratteristiche dell’interfaccia utente creata, indicando le motivazioni alla base di tali scelte, talvolta
citando anche le linee guida COGAIN rispettate da una certa caratteristica.
In alcune occasioni, inoltre, si è evidenziato come viene realizzata tale caratteristica, soprattutto per sottolineare come WPF ha permesso la sua creazione in
maniera semplice.
In questo paragrafo, si abbandonerà la parte progettuale e si analizzeranno gli
aspetti più generali o rilevanti dell’implementazione di DOGeye.
Come primo aspetto, si considerino gli elementi grafici dell’interfaccia: icone dei
tab, aspetto dei pulsanti e icone dei dispositivi.
Tali elementi sono stati realizzati con il software Microsoft Expression Design, un
programma di grafica vettoriale di cui si parlerà nell’Appendice A. Tale programma
permette di esportare gli oggetti che si producono in diversi formati: JPEG, PNG
e così via.
Tali formati grafici, però, non sono vettoriali, cioè “sgranano” quando vengono
ingranditi. Questo è un peccato, considerando che WPF, invece, supporta la grafica
65
5 – Progettazione e implementazione
vettoriale. Tale programma, pertanto, permette di esportare gli oggetti creati anche
in formato XAML, permettendo così di sfruttare le funzionalità di grafica vettoriale
di WPF.
Tali oggetti XAML, dopo un paio di modifiche, possono venire utilizzate all’interno del programma come se fossero delle comune immagini. A titolo di esempio
e per delineare alcune funzionalità di WPF utilizzate, si riporta il codice XAML di
uno 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.333L
43.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.3333L
294.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
5 – Progettazione e implementazione
</DrawingGroup>
</DrawingImage.Drawing>
</DrawingImage>
</ResourceDictionary>
Il codice di esempio è quello che rappresenta lo stato di porta chiusa. Il suo
elemento radice, ResourceDictionary, indica che tale elemento grafico è inserito in
un dizionario, così da essere disponibile all’intera applicazione attraverso la chiave
CloseDoorActuator.
Una prima caratteristica di questa immagine è rappresentata dalla proprietà
Freeze="True": tale proprietà indica che l’immagine non è modificabile dopo il
suo primo utilizzo e, pertanto, XAML ne ottimizza l’uso e l’inserimento all’interno
dell’interfaccia utente.
L’immagine creata attraverso XAML è del tipo DrawingImage, uno dei tanti tipi
di immagini disponibili in WPF. Essa specifica la proprietà Drawing che permette
di disegnare un solo oggetto grafico al suo interno. Avendo bisogno di rappresentare
diversi oggetti grafici, li si unisce in un DrawingGroup.
I figli di tale DrawingGroup, possono essere oggetti geometrici, cioè composti
da linee, punti, curve, ecc., e immagini bitmap. Nel caso considerato, sono presenti cinque immagini di formato PNG (ImageDrawing) e tre oggetti geometrici
(GeometryDrawing), rappresentati da un colore e da un insieme di coordinate che
ne definiscono la forma.
Si è, però, detto di preferire l’utilizzo di XAML invece di immagini bitmap come
quelle in formato PNG perché XAML è vettoriale. Nel codice d’esempio, d’altra
parte, si vedono cinque immagini PNG e, quindi, verrebbe da pensare che si perdono
i vantaggi di utilizzare XAML.
Non è così. Utilizzando immagini bitmap all’interno di una DrawingImage si
ottiene comunque una scalabilità dell’immagine maggiore rispetto all’utilizzare l’immagine PNG direttamente all’interno dell’interfaccia utente.
Inoltre, viene utilizzata un’immagine di formato PNG perché è l’unica, tra quelle
supportate da WPF, che permette di non definire uno sfondo nell’immagine: in
questo modo, l’immagine si può utilizzare su qualsiasi colore di sfondo l’applicazione
utilizzi.
Quasi tutti gli elementi grafici utilizzati in DOGeye sono realizzati in questo
modo: alcuni sono una combinazione di immagini PNG e di oggetti geometrici, altri
sono solo oggetti geometrici (come i bottoni, per esempio) e altri ancora, sono solo
immagini PNG utilizzate però all’interno di una DrawingImage.
Questa differenza nasce, da una parte, dalla modalità in cui Expression Design
esporta e, dall’altra, dalla presenza di dispositivi nella casa la cui rappresentazione
grafica era troppo “complicata” e, pertanto, si è preferito utilizzare immagini già
esistenti reperibili su Internet.
67
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. Nei
prossimi sotto-paragrafi si tratterà del layout dei moduli realizzati in XAML, dell’interazione con l’ETU-Driver (modulo Eye based interaction), con DOG (utilizzando
il 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, è stato
realizzato utilizzando tre pannelli di WPF:
• DockPanel, introdotto da WPF;
• Grid, anch’esso introdotto da WPF;
• TabPanel, già esistente in Windows Forms, che è utilizzato per implementare
il 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
5 – Progettazione e implementazione
<TabControl/>
</DockPanel>
</Window>
Il pannello DockPanel è il pannello al livello gerarchico più alto; questo pannello
permette di effettuare il docking degli elementi a un intero lato del pannello, eventualmente allargandoli per riempire la sua larghezza o altezza. La posizione dei
pannelli e dei controlli figli viene assegnata tramite la proprietà Dock, che può avere
i 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 inferiore
dell’interfaccia (e contiene l’area di notifica), mentre il controllo TabControl occupa
tutto il resto dello spazio.
Il pannello Grid è, forse, il pannello più utilizzato in XAML perché è molto potente e versatile: infatti, opportunamente configurato, permette di realizzare l’aspetto
di tutti gli altri pannelli principali di WPF. Visual Studio, addirittura, lo usa come
pannello di default quando vengono creati nuovi progetti WPF.
Questo pannello permette di disporre i suoi figli in una disposizione multi-riga
e multi-colonna, assomigliando molto a una tabella e, in particolare, al controllo
Table di HTML. Pertanto, esso può essere utilizzato per ospitare figli in uno spazio
unico, così come disporli in righe e colonne pre-assegnate e di dimensioni a scelta
del 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 il
bottone 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, per
adattarsi 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 non
ci sarebbe alcun contenuto nell’interfaccia.
Esso è composto da nove TabItem, uno per ogni tab più uno vuoto e invisibile
per separare “Settings” dagli altri tab. Ogni TabItem ha un header che è un oggetto
composto da un’icona e da un’etichetta di testo, mentre il loro contenuto è costituito
69
5 – Progettazione e implementazione
da una pagina XAML, racchiusa in un controllo di tipo Frame, uno dei controlli WPF
che può ospitare una pagina.
La scelta è ricaduta sul controllo Frame poiché altri controlli fornivano funzionalità di navigazione simili a quelle utilizzate nei browser web che non erano necessarie
per realizzare DOGeye.
Tabella 5.2: I principali pannelli presenti in XAML
Nome
Descrizione
Canvas
È il pannello più semplice. Si possono posizionare gli elementi figli dovunque si voglia, specificando la distanza dal
margine superiore e laterale del pannello.
È un pannello abbastanza utilizzato. Come suggerisce il
suo nome, esso dispone i suoi figli a stack, impilandoli
orizzontalmente o verticalmente.
Simile allo StackPanel ma, oltre a impilare i suoi figli, consente anche di disporli su più righe o colonne, quando si è
esaurito lo spazio a disposizione.
Permette un ancoraggio degli elementi suoi figli lungo i suoi
lati.
È il pannello più versatile e può simulare il comportamento
di tutti gli altri. Dispone i suoi figli in celle organizzate in
righe e colonne impostate dal programmatore.
StackPanel
WrapPanel
DockPanel
Grid
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 che
viene 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 e
un file di code-behind, scritto in C#, in questo contesto.
Il layout dei tab di DOGeye, però, varia sensibilmente in base alle caratteristiche
del tab stesso; qui di seguito si riporterà la struttura che quasi tutti i tab hanno in
comune, 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
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 DockPanel
che, questa volta, definisce due aree:
• quella destra, contenente una Grid, che ospita una serie di altri pannelli, opportunamente resi invisibili in base alla situazione, per visualizzare la command
area;
• quella sinistra, che contiene le ListBox che rappresentato rispettivamente la
planimetria della casa e l’elenco dei dispositivi.
È il caso, ora, di spendere alcune parole sulla ListBox che contiene la planimetria
della casa che, come è possibile vedere dalle immagini dell’interfaccia presentate nel
paragrafo precedente, non ha più l’aspetto di una ListBox classica.
Per realizzarla, è stato modificato pesantemente lo stile e il template della ListBox
che, in genere, rappresenta i suoi elementi di solo testo ordinati verticalmente, dall’alto in basso. In questo caso, c’era la necessità di poter collocare liberamente nella
ListBox i suoi elementi, visto che le stanze della casa hanno una posizione prestabilita; inoltre, ogni stanza doveva essere rappresentata da una serie di immagini e di
elementi di testo.
Innanzitutto, è stato impostato uno stile per l’intera ListBox, sempre all’interno
di 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
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 rappresentata per intero nello spazio a disposizione;
• assegnato il pannello Canvas come pannello da utilizzare per ospitare gli elementi della ListBox;
• assegnato lo stile degli elementi della ListBox, dicendo di recuperare dal dizionario 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
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 RoomDesign, 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 (proprietà CornerRadius), con lo sfondo trasparente (in modo da rendere l’intera
stanza selezionabile), con un colore e uno spessore definiti nella risorsa RoomWall; all’interno di questo bordo dovranno essere visualizzati gli
elementi della ListBox (parola chiave ContentPresenter);
– ha un trigger, che specifica alcuni comportamenti da effettuare quando
una determinata proprietà ha un certo valore; in questo caso, quando un
ListBoxItem viene selezionato, bisogna cambiare il colore di sfondo da
trasparente a CornflowerBlue;
• definita la distanza dal bordo superiore di ogni ListBoxItem, in base al valore
PosY, impostato dalla logica di DOGeye;
• definita la distanza dal bordo sinistro di ogni ListBoxItem, in base al valore di
PosX, impostato anch’esso dalla parte di logica di DOGeye.
Realizzare tutto questo in una tecnologia precedente a XAML voleva dire definire
completamente un nuovo controllo utente, producendo decisamente molto più codice
che, 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 XMLRPC, interagisce con delle API di comunicazione che prendono il nome di DOGleash,
realizzate dal gruppo di ricerca e-lite; tale libreria è stata lievemente modificata per
questo progetto solo per introdurre alcune funzionalità, come la planimetria della
casa letta da file XML.
Per interagire con DOG non si utilizza XAML ma il suo code-behind ; in particolare, si possono individuare due momenti in cui DOG e DOGeye comunicano:
• una fase iniziale, in cui DOG comunica all’interfaccia le informazioni sulla casa
e sui dispositivi che essa contiene;
73
5 – Progettazione e implementazione
• una fase operativa, in cui DOG comunica all’interfaccia eventuali eventi che
sono capitati all’interno della casa (accensione di una luce, per esempio) e
DOGeye comunica a DOG, invece, che l’utente vuole effettuare qualche tipo
di operazione sui dispositivi domotici.
Nella prima fase, DOGeye crea un oggetto di tipo DogHouse che aprirà la connessione con DOG e riceverà le informazioni sulle varie stanze contenute all’interno
della casa, con i loro dispositivi; inoltre si registrerà come listener per ricevere ed
inviare 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 file
houseClient = 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 un
metodo di UpdateCallBack che provvederà a cambiare gli stati dei dispositivi nel
caso in cui qualcuno di esso venga comandato e, nello stesso tempo, a inserire il
cambiamento di stato nell’area di notifica dell’interfaccia:
namespace DOGeye
{
public partial class Window1 : Window
74
5 – Progettazione e implementazione
{
...
//The listener for the command given from DOG or from the house
void 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 new
properties in the current device
de.State = dev.State;
server_statusUpdateLister(de);
}
}
}
}
}
//Allow to call the UI elements from the houseClient listener
delegate 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 method
Device dev = current;
Security sec = Security.Content as Security;
if (TypeList[dev.Type].Equals("ED"))
{
75
5 – Progettazione e implementazione
ElectricDevice ed = ElectricDevice.Content as
ElectricDevice;
ed.UpdateCallBack(dev);
}
else if ...
//Update the history events’ list (FIFO)...
AddToLog(dev);
}
}
...
}
}
Ogni tab, poi, definirà un proprio metodo di “UpdateCallBack” per gestire il
cambiamento di stato dei propri dispositivi in base alle loro funzionalità.
5.3.4
Interazione con l’ETU-Driver
La Main Window, che è la classe principale di DOGeye, interagisce con l’ETU-Driver
attraverso 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 inizializzato, ma anche che il layout deve agire su di esso, che i dati sono stati tutti
collegati, che è stato connesso a una superficie di rendering (la finestra) e che è sul
punto 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 libreria
GDI+, necessita delle informazioni di rendering prima di poter iniziare a operare.
Il metodo LoadETUDriver non fa altro che occuparsi dell’interfacciamento di
DOGeye con l’ETU-Driver principalmente mediante i due seguenti metodi, che si
trovano 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 contiene
l’interazione con l’ETU-Driver; esso si occupa dell’inizializzazione del driver
universale e della lettura delle impostazioni dal file di configurazione (se esiste);
76
5 – Progettazione e implementazione
• iETUDriver_OnDataEvent(): è il metodo che si occupa di ricevere gli eventi
inviati 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 (la
fissazione sta continuando), geFixationEnd (l’eye-tracker ha individuato la fine 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 della
fissazione grazie all’evento geFixationUpdate. Gli altri eventi, pertanto non vengono
intercettati in quanto non necessari ai fini del progetto.
Ogni evento fornisce le coordinate a cui si è verificato, utilizzando internamente
la libreria GDI+, e queste vengono utilizzate in modo opportuno per capire che
oggetto si sta guardando e intraprendere le azioni collegate a esso.
Per farlo, si utilizzava la funzione Windows Forms ClientRectangle, con la quale
si otteneva il rettangolo che contiene un determinato controllo utente, e si verificava
che 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 importanza di tale funzione, ho provveduto a scriverne una nuova versione, chiamandola
GetBoundingBox():
private Rect GetBoundingBox(FrameworkElement element, Window
containerWindow)
{
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 rettangolo e la finestra a cui questo controllo appartiene. Essa trasforma le coordinate
del controllo, calcolandole nel sistema di coordinate del suo progenitore, la finestra
appunto.
Dopodiché, in questo nuovo sistema di riferimento, calcola la posizione di due
punti: l’angolo in alto a sinistra e quello in basso a destra del controllo così trasformato.
Utilizzando questi due punti, costruisce e restituisce al metodo che l’ha chiamato
il rettangolo finale che sarà proprio l’area che ci serve.
77
5 – Progettazione e implementazione
5.3.5
Organizzazione e riusabilità del codice
Nel realizzare questa versione di DOGeye si è posta particolare attenzione a produrre
codice leggibile, ben documentato e riutilizzabile.
Per raggiungere tale scopo si è pensato a una certa modularità all’interno del
progetto, come già visto all’inizio di questo paragrafo; questo è un altro motivo per
cui 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 ha
un suo file di code-behind. Inoltre, i metodi e le funzionalità in comune tra più tab
sono state inserite in una classe statica che prende il nome di “Commons”. In questo
modo, se si volesse creare un nuovo tab basterebbe prendere la pagina XAML di un
tab già esistente e utilizzarla come struttura base.
Anche l’ETU-Driver è stato collocato in una classe a sé stante, collegata alla
classe principale di DOGeye: se si decidesse, pertanto, di non utilizzare più l’ETUDriver perché, per esempio, è stato sostituito da qualche altro componente, basterebbe cancellarne la classe ed eliminare una riga di codice dal code-behind della
Main Windows di DOGeye.
In questo processo di modularizzazione, un grande aiuto è venuto dai dizionari
XAML: ogni “variabile globale” utilizzata in XAML, ogni oggetto grafico, sia esso
un 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 da
contenitore, è possibile cambiare totalmente l’aspetto dell’applicazione, sostituendo
solo questo dizionario.
Un discorso equivalente vale per i singoli elementi grafici: se si decidesse di
cambiarne uno, si tratta sempre di avere a che fare con un unico documento e non
di andare a cercare all’interno di diverse classi.
78
Capitolo 6
Risultati ottenuti
In questo capitolo si presenteranno alcuni risultati ottenuti dall’analisi dell’interfaccia utente DOGeye. In particolare, ci si soffermerà su qualche analisi qualitativa,
quantitativa e si valuterà l’interfaccia rispetto alle specifiche COGAIN presentate
nel 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 gruppo
ristretto di utenti (5 persone), non omogeneo per età e per competenze.
Osservando come tali utenti interagivano con l’interfaccia, anche se attraverso il
mouse, è stato possibile ricavare alcuni risultati preliminari di tipo qualitativo.
La totalità degli utenti, innanzitutto, ha apprezzato la chiarezza e l’eleganza
dell’interfaccia nel suo complesso ed è riuscita a utilizzarla senza grossi problemi.
L’immediatezza dell’utilizzo si è vista soprattutto nel momento in cui dovevano
interagire con la planimetria della casa: l’accedere alle stanze tramite quel modello
visivo è stato, per tutti, una cosa assolutamente naturale.
Un po’ di spiegazione è stata necessaria per chiarire il significato e la presenza
dei tab che permettono di unire la vista funzionale a quella strutturale, utilizzata
comunemente. In ogni caso, dopo una breve panoramica, quasi tutti gli utenti sono
stati capaci di individuare immediatamente in quale tab si trovava un determinato
dispositivo.
Una funzionalità poco usata, invece, è stata quella che permette di comandare
i dispositivi in base al loro tipo, presente in “Home Management” e in “Electric
Device” non appena si seleziona una stanza che contiene al suo interno più di un
dispositivo.
79
6 – Risultati ottenuti
Infine, qualcuno ha trovato un po’ piccola la scritta che indica la luminosità attualmente impostata per le lampade di tipo DimmerLamp, nel tab “Home
Management”.
Nel complesso, quindi, l’interfaccia ha suscitato commenti positivi in quanto
funzionale, abbastanza intuitiva nell’utilizzo e veloce a rispondere ai comandi dati
dall’utente.
6.2
Analisi quantitativa
Sono stati effettuati alcuni test sperimentali per verificare l’utilizzo delle risorse
del computer da parte di DOGeye, utilizzando il computer le cui specifiche sono
riportate 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 GB
O.S.
Windows 7
Tabella 6.1: Specifiche computer
Per quanto riguarda l’utilizzo di memoria RAM, si sono effettuate 10 misurazioni
facendo partire l’applicazione senza caricare l’ETU-Driver e 10 misurazioni caricando
anche l’ETU-Driver, in modo da poter valutare quale sia il peso dell’interfaccia da
sola e quale quello di questo componente.
I risultati, riportati in tabella 6.2, sono stati ottenuti calcolando la media delle
10 misurazioni eseguite nei due casi.
Condizione
Utilizzo
con ETU-Driver
(MB)
Utilizzo
senza ETU-Driver
(MB)
22
32
35
12
22
26
Avvio
Caricamento primo tab
Caricamento primi quattro tab
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
6 – Risultati ottenuti
La percentuale di utilizzo del processore è un dato importante da rilevare per
capire l’efficienza di un programma: i risultati di tale misurazione sono visibile in tabella 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 a
quanto si è fatto per le misurazioni sull’occupazione di memoria RAM.
Condizione
Utilizzo
(%)
Avvio
Caricamento primo tab
Cambiamento di tab
8-9
7-8
3-4
Tabella 6.3: Utilizzo della CPU da parte di DOGeye
Ovviamente, nel tempo in cui l’interfaccia utente rimane inutilizzata, cioè non
vengono eseguite operazioni né in DOGeye né nella casa, la percentuale di utilizzo
del 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’interfaccia
utente realizzata, si affermava, talvolta, che una certa caratteristica nasce da una
linea guida COGAIN o che, comunque, la rispettava.
In tabella 6.4, è possibile trovare il dettaglio e il riassunto di quali linee guida
l’interfaccia rispetta in pieno, parzialmente o per niente, ricordando che l’obiettivo
iniziale era quello di rispettare, per quanto le funzionalità di DOG permettessero,
quelle indicazioni che erano classificate come di priorità 1, cioè quelle caratteristiche
che l’interfaccia utente DEVE avere.
Quando DOGeye implementa una funzionalità che non è ancora supportata pienamente da DOG, essa viene etichettata come supportata “parzialmente (DOG)”,
per indicare che il limite al rispetto di quella linea guida è l’attuale implementazione
di DOG.
81
6 – Risultati ottenuti
Inoltre, sempre il report D2.5 riporta altri suggerimenti che possono essere utilizzati per valutare questa interfaccia utente.
Essi sono la riduzione del trade-off tra la vista strutturale e la vista funzionale
dell’interfaccia e la localizzazione in diverse lingue.
Per quanto riguarda il primo suggerimento, si è cercato di trovare un giusto
equilibrio utilizzando entrambe le viste e strutturando l’interfaccia a due livelli gerarchici: uno più elevato che rappresenta la vista funzionale e uno più basso che
rappresenta quella strutturale.
Per il secondo suggerimento si può dire che l’interfaccia utente è predisposta alla
localizzazione in più lingue, utilizzando i metodi semi-automatici esposti da WPF
e Visual Studio o utilizzando altre modalità che, però, sono da creare partendo da
zero 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 notifiche per gli allarmi veloce, facile
da capire e multimodale.
1.2 Fornire all’utente solo poche
e chiare opzioni per gestire eventi
di allarme.
1.3 Fornire un’azione di default per affrontare un evento di
allarme.
1.4 Fornire una richiesta di conferma per le operazioni critiche e
possibilmente dannose.
1.5 Fornire una funzionalità di
STOP che interrompa ogni operazione.
1
Sì, utilizza
audio, video e testo
2
Sì, ne utilizza due
1
Sì, dopo un time-out
sceglie l’opzione più sicura
1
Sì
1
Parzialmente (DOG):
non tutte le operazioni si
possono interrompere
2.1 Fornire una connessione con
il COGAIN ETU-Driver.
2.2 Supportare differenti metodi
di input.
1
Sì
2
Sì,
attualmente mouse, tastiera,
eye-tracking e multi-touch
Continua. . .
82
6 – Risultati ottenuti
Descrizione
Priorità
Rispettata?
Parzialmente:
il layout attuale non è totalmente riconfigurabile, ma
è possibile cambiarne il look
(anche ingrandendo/rimpicciolendo i vari elementi grafici) ed è adattabile a diverse
risoluzioni dello schermo
Sì,
attualmente mouse, tastiera,
eye-tracking e multi-touch
No
2.3 Fornire un layout riconfigurabile, appropriato per diverse performance dell’eye-tracking e per
diverse esigenze degli utenti.
2
2.4 Supportare più metodi di input allo stesso tempo (interazione
multimodale).
2.5 Gestire la perdita del controllo dell’input fornendo azioni di
default automatiche.
2
3.1 Rispondere agli eventi e ai comandi dell’ambiente domotico nel
giusto tempo.
3.2 Gestire eventi con diversa
priorità temporale.
1
Sì,
l’interfaccia è reattiva
1
3.3 Eseguire comandi con diversa
priorità.
3.4 Fornire un feedback quando vengono eseguite operazioni e
comandi automatici.
1
Sì,
per esempio gli eventi critici, come gli allarmi, hanno la
precedenza sugli altri
Parzialmente (DOG)
3.5 Gestire (creare, modificare,
cancellare) scenari.
2
3.6 Conoscere lo stato corrente di
ogni dispositivo.
2
Parzialmente (DOG):
attualmente avviene solo per
gli allarmi; gli scenari non
sono ancora pienamente supportati da DOG
Parzialmente (DOG):
gli scenari non sono ancora pienamente supportati da
DOG
Sì
4.1 Fornire una chiara visualizzazione di ciò che accade nella
casa.
1
Sì
2
2
Continua. . .
83
6 – Risultati ottenuti
Descrizione
Priorità
4.2 Fornire un’interfaccia elegante e chiara.
4.3 Fornire una visualizzazione
dello stato e della posizione dei
dispositivi della casa.
4.4 Usare colori, icone e testo
per evidenziare un cambiamento
di stato.
4.5 Fornire un metodo di selezione facile da imparare.
Rispettata?
2
Sì
2
Sì
2
Sì,
utilizza immagini colorate,
testo e sintesi vocale
Sì
2
Come si può vedere, vengono rispettate tutte le linee guida, parzialmente o totalmente, tranne una, andando così ben oltre l’obiettivo di rispettare solo le specifiche
con priorità più alta.
84
Capitolo 7
Conclusione e sviluppi futuri
L’interfaccia utente progettata ha le potenzialità per diventare l’interfaccia prototipale per molte altre interfacce utente, basate su eye-tracking, per il controllo di
ambienti 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, siano
all’avanguardia sia per quanto riguarda lo stato dell’arte della tecnologia utilizzabile
per 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 alla
struttura modulare con cui l’interfaccia è composta, l’attuale versione di DOGeye
può fornire un’ottima base per eventuali miglioramenti, modifiche e funzionalità
aggiuntive.
Infine, essa presenta alcune nuove tecniche (come quelle di selezione multipla, per
esempio) che potranno permettere all’utente di utilizzare l’interfaccia con maggiore
comfort e migliorare le performance del sistema in generale.
Nel prossimo paragrafo, per concludere questa dissertazione, si presenteranno
alcuni possibili sviluppi futuri, tralasciando gli eventuali miglioramenti del sistema
stesso in termini di funzionalità già esistenti e le caratteristiche dell’interfaccia utente
che non si è potuto implementare completamente a causa di alcune limitazioni della
versione di DOG utilizzata per questo progetto come, per esempio, gli scenari.
7.1
Possibili sviluppi futuri
Alcune nuove caratteristiche e funzionalità introducibili in DOGeye, potrebbero
essere le seguenti:
• localizzazione
85
7 – Conclusione e sviluppi futuri
DOGeye è predisposto per supportare la localizzazione in diversi linguaggi.
Questa funzionalità è disponibile attraverso un tool semi-automatico incluso
in Visual Studio o adottando altri meccanismi ad-hoc.
• personalizzazione grafica
L’interfaccia è predisposta per offrire la possibilità di cambiare il suo lookand-feel al volo, in base alle preferenze dell’utente. Questo è possibile creando
diversi dizionari di stili XAML e permettendo all’utente di scegliere quello che
preferisce utilizzare.
• altre modalità di interazione
L’interfaccia utente offre la possibilità di utilizzare, al momento, mouse, tastiera ed eye-tracking per controllare e comandare l’applicazione. Si potrebbero
introdurre altre modalità di interazione, come gli switch, che offrono una modalità di selezione a scansione, passando cioè da un elemento dell’interfaccia
utente a un altro premendo un pulsante fisico o girando una manopola e in
modo sequenziale.
DOGeye, utilizzando principalmente delle liste per contenere i vari dispositivi
della casa e le sue stanze, offre già una buona base di partenza per l’adozione di
tale metodo di interazione, in quanto le liste forniscono di default una basilare
modalità di scansione, quella che, per esempio, può essere utilizzata con i tasti
cursore della tastiera.
• applicazione web
Questa interfaccia utente, si è detto, utilizza delle pagine XAML per contenere
i vari tab. Tali pagine, per quanto riguarda gli elementi dell’interfaccia grafica scritti in XAML, sono visualizzabili anche all’interno di un browser web.
Inoltre, è possibile utilizzare WPF per creare applicazioni web. Ancora, la
tecnologia Silverlight della Microsoft, il cui funzionamento è all’incirca quello
di Adobe Flash e quindi nasce per il web, altro non è che un sotto-insieme di
WPF, con il quale, quindi, condivide molti metodi e molte funzionalità.
Pertanto, partendo dall’attuale interfaccia si potrebbe realizzare un suo porting (sempre come applicazione WPF o come applicazione Silverlight) in modo
tale che essa possa funzionare anche attraverso un browser web, sia in locale
che su un server apposito.
• interazione col sistema operativo sottostante
È possibile fornire le funzionalità del sistema operativo nonché alcuni suoi programmi all’interfaccia utente in modo che si possano svolgere alcune operazioni
senza dover chiudere DOGeye.
86
7 – Conclusione e sviluppi futuri
Per fare un esempio, visto che le pagine XAML utilizzate in questo progetto
possono contenere anche codice HTML, sarebbe possibile inserire una pagina
con 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à possibile utilizzare questa interfaccia utente con i gesti più semplici, visto che gli
elementi grafici di DOGeye sono sufficientemente grandi per essere utilizzati
anche con le dita.
Visto il supporto delle ultime versioni di Windows per il multi-touch e data
la possibilità di utilizzarlo anche in WPF, sarebbe possibile implementare nell’interfaccia utente realizzata anche alcune gesture più avanzate, come il pinch
per 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 muoversi
insieme all’utente), si potrebbe realizzare una versione di DOGeye che fornisca
funzionalità di realtà aumentata combinata a un’interazione con l’eye-tracking.
L’utente, in questo caso, vedrebbe l’immagine reale della casa, trasmessa da
un webcam anch’essa montata sull’eye-tracker e, in corrispondenza dei dispositivi comandabili dall’interfaccia utente, vedrebbe comparire le informazioni
relative al loro stato e alcuni pulsanti per interagire con essi.
Tralasciando per un attimo l’eye-tracking, questo potrebbe essere anche un
altro progetto, da realizzare per dispositivi portatili e con altre tecnologie, per
esempio su iPhone/iPod Touch o Android.
87
Appendice A
Microsoft Expression Design
Microsoft Expression Design, nella sua ultima versione, è stato utilizzato per realizzare quasi tutti gli elementi grafici che compaiono nell’interfaccia utente.
È l’applicativo Microsoft dedicato al disegno facente parte della suite Expression
Studio, che recentemente è arrivata alla versione 3. Esso è un programma ibrido,
pensato anche per supportare lo sviluppo di interfacce utente per applicativi desktop
e siti Web. È principalmente un software vettoriale, anche se è dotato di alcune
funzionalità ed effetti tipici dei programmi bitmap. Gli strumenti di disegno sono
tutti vettoriali, e sono basati sia sulle curve di bezier, sia sulle b-spline (queste ultime
tipiche 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
A – Microsoft Expression Design
vettoriali - XAML Silverlight 3 Canvas, XAML WPF Canvas e XAML WPF
Resource Dictionary.
L’aspetto interessante è quello dato dalla possibilità proprio di esportare in formato XAML, per utilizzare poi le immagini all’interno di progetti WPF/Silverlight.
Concentrandoci sull’esportazione XAML, il formato forse più utilizzato per applicazioni WPF è quello che permette di ottenere un dizionario con all’interno l’immagine realizzata con Expression Design. Purtroppo, l’immagine contenuta nel dizionario esportato in questo modo è scarsamente utilizzabile all’interno di un programma
WPF, 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 WPF
Resource Dictionary;
3. il pannello “Export Properties”, a questo punto, cambierà leggermente di aspetto; dal menù a tendina Group by, che permette di scegliere come si vuole che
i vari elementi dell’immagine creata siano raggruppati in XAML, selezionare
l’opzione che si preferisce, regolandosi in base alle proprie necessità e aiutandosi
con l’anteprima mostrata nell’area a sinistra; si immagini di scegliere l’opzione
Document che permette di avere un unico elemento nel dizionario risultante;
4. scegliere come si vogliono ottenere i Live effect, se rasterizzare tutto o convertirli in effetti XAML; questi sono gli effetti bitmap che si sono utilizzati
nella creazione dell’immagine e i risultati graficamente migliori si ottengono
selezionando Convert to XAML effects;
5. scegliere nell’area inferiore della finestra dove si vuole salvare il dizionario
XAML e premere Export All ;
6. a questo punto è possibile chiudere il programma e andare nella posizione in
cui si è salvato il dizionario appena creato e aprirlo; tale dizionario apparirà
nel modo seguente:
<ResourceDictionary
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
<DrawingBrush x:Key="ObjectName" Stretch="Uniform">
89
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 formato
PNG 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
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
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
B – Modello della casa utilizzato
• una macchinetta per il caffè (CoffeeMaker);
• un GasHeater;
• un SmokeSensor.
In totale, sono presenti 66 dispositivi.
93
Appendice C
Esempio di codice XAML
Data la vastità del codice dell’applicazione risulta improponibile riportare integralmente il codice. Lo scopo questa Appendice è quello di mostrare il codice della
pagina XAML contenuta all’interno del tab “Home Management”, senza riportare la
parte 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="{StaticResource
ICmdButtonStyle}" 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
C – Esempio di codice XAML
<Button Content="Go out!" Style="{StaticResource
ICmdButtonStyle}" 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="{Binding
SelectedItem.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
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="{StaticResource
SingleRoomDevices}" Visibility="Hidden" SelectionChanged="
DeviceSelected" />
<StackPanel Orientation="Horizontal" HorizontalAlignment="Center
" Grid.Row="1">
<Button Content="Multiple Selection" Width="130" Style="{
DynamicResource ISelButtonStyle}" Visibility="{Binding
ElementName=HMDevices, Path=Visibility}" Click="
MultipleSelection_Click"/>
<Button Content="Select all by type..." Width="130" Style="{
DynamicResource ISelButtonStyle}" Visibility="{Binding
ElementName=HMDevices, Path=Visibility}" Click="
SelectionByType_Click"/>
</StackPanel>
</Grid>
</DockPanel>
</Page>
96
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, Sams
Publishing, 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, Communication
by 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 by
gaze 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 observations 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 and
development needs, Communication by gaze interaction (COGAIN).
[14] F. Razzak, E. Castellina, F. Corno (2009), Environmental Control Application
compliant with Cogain Guidelines, Politecnico di Torino.
97