POLITECNICO DI TORINO


                 III Facoltà di Ingegneria
             Corso di Laurea in Ingegneria Informatica
...
Indice

1 Introduzione                                                                                                    ...
5.2   Scelte progettuali e funzionalità . . . . . . . . .   .   .   .   .   .   .   .   .   .   .   .   .   48
         5....
Elenco delle tabelle

 2.1   Rapporto tra raccomandazioni e interfacce utente per il controllo
       domotico esistenti ....
Elenco delle figure

 1.1    Un esempio di eye-tracker commerciale: MyTobii P10 . . . . . . . .            .    3
 1.2    U...
Capitolo 1

Introduzione

1.1     Contesto generale
Secondo l’indagine ISTAT sulla “Condizione di salute e il ricorso ai s...
1 – Introduzione


utilizzato dall’utente per interagire con la sua casa attraverso il computer.
    Qui entra in gioco il...
1 – Introduzione


   • sistemi indossabili, quindi a diretto contatto con l’utente, in genere sottoforma
     di visori d...
1 – Introduzione


    In generale, infatti, non è possibile utilizzare l’eye-tracking come sostituto com-
pleto del mouse...
1 – Introduzione




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


   • La semplicità e l...
1 – Introduzione


    COGAIN è un consorzio finanziato dall’Unione Europea, costituito da ricercatori,
imprese e associazi...
1 – Introduzione


loro funzione logica, a discapito della loro posizione effettiva. Trovare un equilibrio
tra queste due v...
1 – Introduzione


   • nel capitolo TRE “Soluzioni tecniche adottate”, verrà descritto l’ambiente do-
     motico propost...
Capitolo 2

Obiettivi

L’obiettivo principale della tesi è lo studio, la progettazione e la realizzazione di
un’interfacci...
2 – Obiettivi


    Assumendo di non avere alcun tipo di problema nel collegare una qualsiasi inter-
faccia utente al sist...
2 – Obiettivi


 Raccomandazione                               LC Technologies      Domotica Labs
 Creare interfacce utent...
2 – Obiettivi


incompatibili l’un l’altro.
    Il fatto di dover usare l’ETU-Driver è un altro motivo che ha influito note...
2 – Obiettivi


Linea guida                        Descrizione                            Priorità
    1.3       Fornire u...
2 – Obiettivi


Linea guida                        Descrizione                           Priorità
    2.3       Fornire un...
2 – Obiettivi


Linea guida                        Descrizione                            Priorità
    3.3       Eseguire ...
2 – Obiettivi


Linea guida                        Descrizione                            Priorità
    4.3       Fornire u...
Capitolo 3

Soluzioni tecniche adottate

3.1      Introduzione
Prima di parlare del progetto dell’interfaccia utente reali...
3 – Soluzioni tecniche adottate


    Nei paragrafi seguenti, si tratteranno in maniera più dettagliata le caratteristiche
...
3 – Soluzioni tecniche adottate


per esempio, gli scenari, cioè un elenco di attività riguardanti determinati dispositivi...
3 – Soluzioni tecniche adottate




                     Figura 3.3: L’architettura logica di DOG


    Come illustrato ne...
3 – Soluzioni tecniche adottate


   • Status è una sorta di cache che contiene lo status dei dispositivi presen-
     ti ...
3 – Soluzioni tecniche adottate


   Una ontologia è una rappresentazione formale di una interpretazione condivisa di
uno ...
3 – Soluzioni tecniche adottate




                           Figura 3.4: L’ontologia DogOnt


che ci possono essere nell...
3 – Soluzioni tecniche adottate


avere nelle singole stanze, come luci, interruttori o elettrodomestici (si trovano tut-
...
3 – Soluzioni tecniche adottate


    Il driver, la cui architettura è rappresentata nella figura 3.5, è costituito da una
...
3 – Soluzioni tecniche adottate


ThinOut - questo filtro accetta solo un campione ogni N, con N impostabile a
    piacere....
Capitolo 4

Tecnologia utilizzata

Esistono diverse tecnologie e diversi linguaggi adatti a realizzare un’interfaccia uten...
4 – Tecnologia utilizzata


sul web, a quelli di Adobe Flash, senza dimenticare quelli che verranno introdotti
da HTML 5, ...
4 – Tecnologia utilizzata


   Tali limitazioni sono state superate da WPF, di cui si riportano alcune tra le sue
caratter...
4 – Tecnologia utilizzata


         e può anche essere utilizzato come un meccanismo di protezione (di fallback,
        ...
4 – Tecnologia utilizzata


    Avendo, inoltre, citato DirectX, non bisogna pensare che questa tecnologia sia
morta, vist...
4 – Tecnologia utilizzata


    In questo paragrafo non si intende insegnare a programmare in XAML o con le
WPF, in quanto...
4 – Tecnologia utilizzata


aprendolo in Internet Explorer, mentre per il C# bisognerebbe prima compilare
tutto. Il risult...
4 – Tecnologia utilizzata


   • System.Windows.Media.Media3D;

   • System.Windows.Media.TextFormatting;

   • System.Win...
4 – Tecnologia utilizzata


  Keyword      Descrizione
    x:Name     Associa un nome a un elemento così che possa essere ...
4 – Tecnologia utilizzata


       <Setter.Value>
              <RotateTransform Angle="10" />
       </Setter.Value>
    ...
4 – Tecnologia utilizzata


    L’albero visuale, invece, è un’espansione dell’albero logico, in cui i nodi sono
sviluppat...
4 – Tecnologia utilizzata


codice procedurale, per esempio C#, che conterrà una classe parziale che eredita
proprio dal fi...
4 – Tecnologia utilizzata


   • Win32 - è possibile inserire controlli Win32 in applicazioni WPF e controlli
     WPF in ...
4 – Tecnologia utilizzata


    L’unico “problema” è che questi controlli sono generalmente scritti in C++, e do-
vrà esse...
4 – Tecnologia utilizzata


    Il controllo Windows Forms va inserito proprio in quel punto poiché necessita
di avere già...
Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale
Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale
Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale
Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale
Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale
Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale
Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale
Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale
Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale
Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale
Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale
Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale
Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale
Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale
Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale
Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale
Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale
Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale
Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale
Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale
Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale
Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale
Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale
Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale
Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale
Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale
Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale
Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale
Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale
Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale
Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale
Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale
Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale
Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale
Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale
Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale
Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale
Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale
Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale
Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale
Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale
Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale
Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale
Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale
Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale
Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale
Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale
Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale
Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale
Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale
Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale
Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale
Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale
Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale
Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale
Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale
Upcoming SlideShare
Loading in...5
×

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

2,359

Published on

Tesi di laurea magistrale in Ingegneria Informatica realizzata con il gruppo di ricerca e-Lite del Politecnico di Torino (http://elite.polito.it)

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
2,359
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
28
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Transcript of "Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale"

  1. 1. 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
  2. 2. Indice 1 Introduzione 1 1.1 Contesto generale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.2 Gaze tracking, interfacce utente e domotica . . . . . . . . . . . . . . . 2 1.3 Specifiche COGAIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.4 Struttura della tesi . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2 Obiettivi 9 3 Soluzioni tecniche adottate 17 3.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 3.2 Ambiente domotico . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 3.2.1 DOG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.2.2 DogOnt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 3.3 Eye Tracking Universal Driver (ETU-Driver) . . . . . . . . . . . . . . 24 4 Tecnologia utilizzata 27 4.1 Windows Presentation Foundation . . . . . . . . . . . . . . . . . . . . 27 4.2 XAML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 4.2.1 Caratteristiche . . . . . . . . . . . . . . . . . . . . . . . . . . 32 4.2.2 Code-behind . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 4.3 Compatibilità con le tecnologie precedenti . . . . . . . . . . . . . . . 38 4.3.1 Integrare controlli Win32 in WPF . . . . . . . . . . . . . . . . 39 4.3.2 Integrare controlli WPF in Win32 . . . . . . . . . . . . . . . . 40 4.3.3 Integrare Windows Forms e WPF . . . . . . . . . . . . . . . . 40 4.3.4 Integrare controlli ActiveX in WPF . . . . . . . . . . . . . . . 41 4.4 Differenze rispetto alle Windows Forms . . . . . . . . . . . . . . . . . 41 4.4.1 Vantaggi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 4.4.2 Svantaggi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 5 Progettazione e implementazione 45 5.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 II
  3. 3. 5.2 Scelte progettuali e funzionalità . . . . . . . . . . . . . . . . . . . . . 48 5.2.1 “Home Management” ed “Electric Device” . . . . . . . . . . . . 52 5.2.2 Entertainment . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 5.2.3 Temperature . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 5.2.4 Security e gli allarmi . . . . . . . . . . . . . . . . . . . . . . . 61 5.2.5 Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 5.2.6 Everything Else . . . . . . . . . . . . . . . . . . . . . . . . . . 64 5.2.7 Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 5.3 Realizzazione dell’interfaccia utente . . . . . . . . . . . . . . . . . . . 65 5.3.1 Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 5.3.2 Layout dei tab . . . . . . . . . . . . . . . . . . . . . . . . . . 70 5.3.3 Interazione con DOG . . . . . . . . . . . . . . . . . . . . . . . 73 5.3.4 Interazione con l’ETU-Driver . . . . . . . . . . . . . . . . . . 76 5.3.5 Organizzazione e riusabilità del codice . . . . . . . . . . . . . 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
  4. 4. Elenco delle tabelle 2.1 Rapporto tra raccomandazioni e interfacce utente per il controllo domotico esistenti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.2 Linee guida COGAIN per la realizzazione di un’applicazione di con- trollo ambientale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.1 Alcune comuni keyword XAML . . . . . . . . . . . . . . . . . . . . . 35 4.2 Vantaggi e svantaggi di WPF . . . . . . . . . . . . . . . . . . . . . . 44 5.1 Attribuzione dei colori ai bottoni dell’UI in base alla loro funzione . . 52 5.2 I principali pannelli presenti in XAML . . . . . . . . . . . . . . . . . 70 6.1 Specifiche computer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 6.2 Utilizzo della RAM da parte di DOGeye . . . . . . . . . . . . . . . . 80 6.3 Utilizzo della CPU da parte di DOGeye . . . . . . . . . . . . . . . . . 81 6.4 Valutazione di DOGeye secondo le linee guida COGAIN . . . . . . . 82 IV
  5. 5. Elenco delle figure 1.1 Un esempio di eye-tracker commerciale: MyTobii P10 . . . . . . . . . 3 1.2 Un programma per la video-scrittura, basato su eye-tracking . . . . . 5 2.1 Vista, ad alto livello, del contesto in cui si colloca l’interfaccia utente da realizzare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.2 Due interfacce utente per ambienti domotici . . . . . . . . . . . . . . 10 3.1 Come l’interfaccia utente è connessa a DOG e all’eye-tracker . . . . . 17 3.2 Un esempio di architettura logica di ambiente domotico . . . . . . . . 18 3.3 L’architettura logica di DOG . . . . . . . . . . . . . . . . . . . . . . . 20 3.4 L’ontologia DogOnt . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 3.5 Parte dell’architettura dell’ETU-Driver . . . . . . . . . . . . . . . . . 24 4.1 Le tecnologie incluse nel framework .NET . . . . . . . . . . . . . . . 28 5.1 L’architettura generale dell’ambiente . . . . . . . . . . . . . . . . . . 45 5.2 La versione preliminare di DOGeye . . . . . . . . . . . . . . . . . . . 46 5.3 Il mock-up di DOGeye . . . . . . . . . . . . . . . . . . . . . . . . . . 48 5.4 L’interfaccia DOGeye . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 5.5 Aspetto di DOGeye quando l’utente necessita qualche tipo di aiuto . 50 5.6 La planimetria della casa, così come viene visualizzata in “Home Management” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 5.7 I tre possibili comportamenti ottenibili selezionando una stanza nei primi due tab di DOGeye . . . . . . . . . . . . . . . . . . . . . . . . 55 5.8 Un esempio di interazione: aprire una porta . . . . . . . . . . . . . . 57 5.9 Un’esempio di notifica . . . . . . . . . . . . . . . . . . . . . . . . . . 57 5.10 Caratteristica di “Entertainment” . . . . . . . . . . . . . . . . . . . . 59 5.11 Esempio di come viene indicata la temperatura di una stanza, in “Temperature” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 5.12 Esempio di come si imposta la temperatura del riscaldamento di tutta la casa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 5.13 Il tab “Security” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 5.14 Esempio di gestione di un allarme . . . . . . . . . . . . . . . . . . . . 62 5.15 L’architettura generale di DOGeye . . . . . . . . . . . . . . . . . . . 68 A.1 Microsoft Expression Design . . . . . . . . . . . . . . . . . . . . . . . 88 V
  6. 6. 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’uten- te, 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, modifi- care o riscrivere del tutto l’interfaccia utente che, in questo caso, è il componente 1
  7. 7. 1 – Introduzione utilizzato dall’utente per interagire con la sua casa attraverso il computer. Qui entra in gioco il concetto di usabilità, definita dall’ISO (International Orga- nisation for Standardisation), come l’efficacia, l’efficienza e la soddisfazione con 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 defi- nita 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 con- trollare il computer tramite la stima del punto osservato sullo schermo dall’utente. In questo caso specifico esso si basa sul tracciamento degli occhi, prendendo così il nome di eye-tracking. L’eye-tracking, o tracciamento oculare, è una tecnica utilizzata in molti cam- pi, tra cui le scienze cognitive, la psicologia, l’informatica e l’interazione uomo- computer, per registrare i movimenti degli occhi. In particolare, vengono misurate e analizzate la posizione degli occhi e il loro movimento relativo alla testa, utilizzan- do 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 eye- tracker 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
  8. 8. 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 esem- pio, e nativamente funziona grazie al mouse e alla tastiera; questo accade poiché l’interazione basata su eye-tracking necessita che le interfacce utente dei 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
  9. 9. 1 – Introduzione In generale, infatti, non è possibile utilizzare l’eye-tracking come sostituto com- pleto del mouse: ciò non è fattibile per il modo in cui agiscono i nostri occhi e 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 pul- santi 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 suc- cesso 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 ca- ratteristiche, alcune delle quali sono molto evidenti. • La dimensione degli oggetti: sono molto grandi. Questo perché l’eye-tracking è, in linea generale, meno preciso di altri dispositivi di puntamento, come il mouse, per esempio. 4
  10. 10. 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 inse- risce, 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
  11. 11. 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, è sta- to 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, presen- tandone il rapporto con la disabilità e analizzando differenti metodi di interazione, tra cui il gaze control. Presenta, inoltre, anche alcuni prodotti commerciali e 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’orga- nizzazione 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
  12. 12. 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 uten- te basata su eye-tracking per un ambiente domotico dovrebbe implementare e che verranno riportati, dato il particolare interesse di questo elenco, nel capitolo succes- sivo. Il report D3.1, intitolato “User requirements report with observations of difficul- ties users are experiencing”, presenta la necessità di porre l’utente finale al centro degli obiettivi di COGAIN. Fornisce, inoltre, alcune informazioni su chi può utilizza- re la tecnologia di eye-tracking e chi, invece, non può, mettendo a confronto ciò 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 nega- tivi 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 sys- tems 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 vo- ce 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 stru- menti 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 ap- profondire alcuni aspetti, seppur di background, necessari a comprendere appieno il come e il perché si è realizzata l’interfaccia utente; nei capitoli seguenti, inve- ce, si mostreranno le fasi di progettazione e di implementazione del progetto e 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 eye- tracking, per applicazioni domotiche; 7
  13. 13. 1 – Introduzione • nel capitolo TRE “Soluzioni tecniche adottate”, verrà descritto l’ambiente do- motico proposto da COGAIN e dal Politecnico di Torino, cioè DOG, analiz- zando brevemente l’ontologia che racchiude lo schema della casa e dei suoi dispositivi. Inoltre, si presenterà l’Eye Tracking Universal Driver, un driver universale, sempre proposto da COGAIN, che serve per utilizzare le tecniche di traccia- mento degli occhi necessarie per questa applicazione di controllo domotico. • nel capitolo QUATTRO “Tecnologia utilizzata”, si illustrerà la recente tec- nologia Microsoft, inclusa nel Framework .NET 3.x, utilizzata per realizzare l’interfaccia grafica, dal nome di Windows Presentation Foundation, presen- tando 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’archi- tettura 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 partico- lare 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 Ex- pression 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
  14. 14. 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 con- trollo domotico. Si consideri, a tal proposito, l’immagine seguente: Figura 2.1: Vista, ad alto livello, del contesto in cui si colloca l’interfaccia utente 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’inter- faccia utente che, da una parte, si possa collegare all’ambiente domotico e dall’altra sia utilizzabile con l’eye-tracking. 9
  15. 15. 2 – Obiettivi Assumendo di non avere alcun tipo di problema nel collegare una qualsiasi inter- faccia utente al sistema di controllo domotico proposto da COGAIN nel deliverable 2.5, cioè a DOG, si può notare che qualche problema sorge proprio nel trovare un’in- terfaccia utente che sia utilizzabile con un eye-tracker, che abbia un numero suffi- ciente di funzionalità e che risponda a quei principi di usabilità che si 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 con- trollo 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
  16. 16. 2 – Obiettivi Raccomandazione LC Technologies Domotica Labs Creare interfacce utente consistenti Sì No Creare scelte standard di interfacce No Possibile differenti, adattabili a piacere Fornire funzionalità di sicurezza in caso No Possibile di guasto del sistema Convergenza di diversi modi operativi No Possibile Utilizzare un insieme di metodi di input, Sì No tra cui l’eye-tracking Possibilità di scegliere la lingua da Sì Possibile utilizzare Fornire una visualizzazione della po- No Sì sizione dei dispositivi all’interno della casa Usare colori, testo e icone per evidenzia- No Parzialmente re un cambiamento di stato 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’at- tuale 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 ca- pitoli, 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 meccani- smi 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 qual- siasi linguaggio appartenente alla piattaforma .NET. Per i propositi di questa tesi, si utilizzerà il linguaggio C#. Inoltre, dovendo l’interfaccia rispettare le specifiche COGAIN, per realizzare l’in- terazione con l’eye-tracking si utilizzerà un driver universale, sempre proposto 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’am- pia compatibilità con diversi modelli di eye-tracker, i cui driver sono generalmente 11
  17. 17. 2 – Obiettivi incompatibili l’un l’altro. Il fatto di dover usare l’ETU-Driver è un altro motivo che ha influito notevol- mente nella scelta di utilizzare la piattaforma .NET: il driver è composto da 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 Descrizione Priorità 1.1 Fornire un sistema di notifiche per gli allarmi veloce, 1 facile da capire e multimodale. L’applicazione di controllo dovrebbe notificare un al- larme il prima possibile e in diversi modi, per esempio con suoni, icone lampeggianti e messaggi di testo. 1.2 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. . .
  18. 18. 2 – Obiettivi Linea guida Descrizione Priorità 1.3 Fornire un’azione di default per affrontare un evento 1 di allarme. In caso di emergenza, l’utente potrebbe perdere il con- trollo del dispositivo di input, quindi l’applicazione di controllo dovrebbe prendere la decisione più sicura do- po che è scattato un timeout. La lunghezza del timeout è dipendete dal tipo di allarme. 1.4 Fornire una richiesta di conferma per le operazioni 1 critiche e possibilmente dannose. Con un inaccurato o mal configurato eye-tracker, l’er- rore del tocco di Mida può essere frequente, cioè ogni oggetto o comando guardato dall’utente è selezionato o eseguito, quindi l’applicazione di controllo dovrebbe ri- chiedere una conferma per le operazioni che potrebbero essere dannose. 1.5 Fornire una funzionalità di STOP che interrompa ogni 1 operazione. In alcune occasioni, il sistema domotico può esegui- re azioni che l’utente non vuole, per esempio per via di una selezione di un comando errato o l’esecuzio- ne di uno scenario pre-impostato. L’applicazione di controllo dovrebbe permettere un metodo di stop per interrompere ogni operazione. 2.1 Fornire una connessione con il COGAIN ETU-Driver. 1 Il COGAIN ETU-Driver è uno standard di comunica- zione per la gaze interaction che permette ad appli- cazioni di terze parti di essere comandate da un ran- ge di diversi sistemi harware di eye-tracker. Usando questo driver, non c’è bisogno di cambiare o ricom- pilare nessuna applicazione nel caso in cui si cambi eye-tracker. 2.2 Supportare differenti metodi di input. 2 L’eye-tracker, sfortunatamente, potrebbe rompersi, quindi l’applicazione di controllo dovrebbe supportare anche altri metodi di input, come la tastiera, il mouse, ecc. Continua. . . 13
  19. 19. 2 – Obiettivi Linea guida Descrizione Priorità 2.3 Fornire un layout riconfigurabile, appropriato per 2 diverse performance dell’eye-tracking e per diverse esigenze degli utenti. Gli eye-tracker hanno un range di performance mol- to ampio; quindi un’applicazione di controllo dovrebbe avere un’interfaccia grafica riconfigurabile in base alle diverse risoluzioni e precisioni degli eye-tracker. 2.4 Supportare più metodi di input allo stesso tempo 2 (interazione multimodale). L’utente potrebbe essere capace di usare canali di input alternativi all’eye-tracking, come la voce o i movimen- ti delle dita, per esempio. L’applicazione di control- lo dovrebbe supportare la combinazione di più meto- di di input contemporaneamente, come ad esempio la selezione con l’occhio e il click con il mouse. 2.5 Gestire la perdita del controllo dell’input fornendo 2 azioni di default automatiche. L’applicazione di controllo dovrebbe capire quando l’u- tente ha perso il controllo dell’eye-tracker e dovreb- be eseguire azioni di default (come effettuare una ricalibrazione o far suonare un allarme). 3.1 Rispondere agli eventi e ai comandi dell’ambiente 1 domotico nel giusto tempo. L’applicazione di controllo dovrebbe essere reattiva: dovrebbe gestire gli eventi e i comandi con un ritardo accettabile. 3.2 Gestire eventi con diversa priorità temporale. 1 L’applicazione di controllo dovrebbe distinguere tra eventi con priorità differente. Gli eventi temporalmen- te critici devono essere eseguiti con un breve perio- do di attesa (per esempio, l’allarme antincendio o il rilevamento di un’intrusione). Continua. . . 14
  20. 20. 2 – Obiettivi Linea guida Descrizione Priorità 3.3 Eseguire comandi con diversa priorità. 1 I sistemi domotici ricevono più comandi contempora- neamente, a causa di diversi utenti o degli scenari, per esempio. L’applicazione di controllo dovrebbe di- scriminare comandi con priorità differente e dovrebbe adottare un comportamento prestabilito. 3.4 Fornire un feedback quando vengono eseguite operazio- 2 ni e comandi automatici. Gli scenari, selezionati dall’utente, potrebbero inclu- dere molti comandi da eseguire. L’applicazione di controllo dovrebbe mostrare l’azione in progresso e informare l’utente quando uno scenario è terminato. 3.5 Gestire (creare, modificare, cancellare) scenari. 2 Ripetere una lunga sequenza di comandi per eseguire un compito frequente potrebbe essere noioso per l’uten- te. E’ necessario raccoglierli in una lista di comandi e gestirli come se fossero uno solo. L’applicazione di con- trollo dovrebbe permettere la creazione, la modifica e la cancellazione di questi scenari. 3.6 Conoscere lo stato corrente di ogni dispositivo. 2 L’applicazione di controllo dovrebbe conoscere lo sta- to corrente di ogni dispositivo della casa, per mostrare questa informazione e per prendere decisioni automati- che intelligenti (per esempio, prevenire una condizione dannosa o attivare un piano di risparmio energetico). 4.1 Fornire una chiara visualizzazione di ciò che accade 1 nella casa. L’interfaccia dell’applicazione di controllo dovrebbe fornire una visualizzazione chiara e facile da capire del progresso dell’esecuzione del comando. 4.2 Fornire un’interfaccia elegante e chiara. 2 Un layout consistente, con un linguaggio facile da capi- re e una grafica riconoscibile, avvantaggia ogni utente. L’applicazione di controllo dovrebbe fornire un’inter- faccia elegante e chiara, possibilmente utilizzando sia immagini che testo. Continua. . . 15
  21. 21. 2 – Obiettivi Linea guida Descrizione Priorità 4.3 Fornire una visualizzazione dello stato e della posizione 2 dei dispositivi della casa. L’applicazione di controllo dovrebbe mostrare la map- pa della casa contenente, per ogni stanza, una rappresentazione dei dispositivi e il loro stato. 4.4 Usare colori, icone e testo per evidenziare un 2 cambiamento di stato. L’interfaccia dell’applicazione di controllo dovrebbe evidenziare un cambiamento di stato di un dispositivo utilizzando immagini, testo e suoni. 4.5 Fornire un metodo di selezione facile da imparare. 2 Anche se l’applicazione di controllo potrebbe presen- tare caratteristiche e funzionalità complesse, dovrebbe pure fornire un metodo di interazione usabile e facile da imparare. 16
  22. 22. 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 CO- GAIN, 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
  23. 23. 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 informa- tiche 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
  24. 24. 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 appar- tenente 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 appli- cazioni 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 orien- tato 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 chia- mate bundle o, in italiano, moduli, che sono facili da integrare: basta, infatti, che siano conformi ai vincoli di comunicazione definiti nel framework stesso. 19
  25. 25. 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 emu- lare 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 Dri- vers e i comandi in arrivo dall’Executor; contiene, quindi, una tabella di rou- ting per mappare la corrispondenza tra i dispositivi e i Network Drivers che possono comandarli; • Executor riceve i comandi dal modulo API, ne controlla la correttezza intera- gendo con il modulo Status e li esegue inviando i nuovi comandi al Command Dispatcher; • House Model contiene la rappresentazione della casa e dei dispositivi apparte- nenti all’ontologia DogOnt, descritta nel prossimo sotto-paragrafo; 20
  26. 26. 3 – Soluzioni tecniche adottate • Status è una sorta di cache che contiene lo status dei dispositivi presen- ti nel sistema; risponde alle richieste mandate dal modulo API, 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 funziona- mento 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 end- point 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, definen- do e implementando le classi di sistema e le eccezioni. L’interfaccia utente comunicherà con DOG principalmente durante due fasi, quel- la iniziale in cui l’interfaccia riceverà il modello della casa con tutti i suoi dispositivi, insieme con il loro stato e la loro descrizione; e quella operativa in cui l’interfaccia comunicherà a DOG i comandi che vuole compiere (per esempio, accendere una lu- ce) e DOG risponderà restituendo l’esito dell’operazione che gli è stata richiesta (“la luce si è accesa”). Sempre nella fase operativa, DOG potrebbe comunicare all’interfaccia che il ve- rificarsi di un evento (qualcuno ha premuto un pulsante e la luce si è accesa) 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
  27. 27. 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 rappre- sentazione 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 (accender- si 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ù interes- santi poiché contiene tutti i dispositivi, gli elementi di mobilio e quelli architetturali 22
  28. 28. 3 – Soluzioni tecniche adottate Figura 3.4: L’ontologia DogOnt che ci possono essere nella casa, si divide in Controllable e Uncontrollable, per sepa- rare gli oggetti che sono controllabili da quelli che, come il tavolo del soggiorno, 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 En- vironment”); dopodiché basterebbe creare le istanze dei dispositivi che si vogliono 23
  29. 29. 3 – Soluzioni tecniche adottate avere nelle singole stanze, come luci, interruttori o elettrodomestici (si trovano tut- ti in “Building Thing” > “Controllable” > “White Goods”) e assegnargli i tipi di funzionalità e i tipi di stato che sono previsti nelle loro classi. L’assegnazione dei singoli stati e delle singole funzionalità per ogni dispositi- vo istanziato nell’ontologia viene fatto in maniera automatica proprio grazie al ragionamento basato su regole offerto da DogOnt. Le regole di DogOnt, pertanto, facilitano il processo di modellazione generan- do automaticamente gli stati adeguati e le funzionalità dei dispositivi domotici, 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 carat- teristiche, 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 diretta- mente 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), uti- lizzato 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
  30. 30. 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 eye- tracker: • ITU GazeTracker; • LC EyeGaze; • SR EyeLink I/II; • SMI iViewX v1.2x e v2.0; • Tobii Technologies 1750, P10, D10, T60, T120 e X120. Inoltre, sono disponibili tre API-Converters di simulazione che possono 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 eye- tracker 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 de- tection, 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 registra- to precedentemente dal driver universale utilizzando un altro API-Converter, mostrandoli sullo schermo. • Simulator, genera scan-path casuali, cioè memorizza su file dei dati casuali, generati come se appartenessero allo sguardo di un utente “virtuale”. Il driver universale dispone anche di alcuni filtri che sono in gradi di modificare, bloccare o generare dati relativi allo sguardo prima che questi vengano inviati alle applicazioni utente. Tali filtri sono: EyeMouse - questo filtro collega sguardo e mouse, ovvero il puntatore si muove seguendo con il punto osservato. 25
  31. 31. 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 svilup- pato 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 eye- tracker 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
  32. 32. Capitolo 4 Tecnologia utilizzata Esistono diverse tecnologie e diversi linguaggi adatti a realizzare un’interfaccia uten- te. All’interno della piattaforma .NET, utilizzata per questo progetto, ne esisto- no principalmente due: Windows Forms e le più moderne Windows Presentation Foundation. In questo capitolo, si presenteranno le caratteristiche peculiari proprio di Windo- ws Presentation Foundation, soffermandosi in maniera particolare ad analizzare quel- la che potrebbe essere considerata la sua componente principale, cioè il 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 perso- naggi utilizzano, soprattutto nei film, non di fantascienza, realizzati negli anni ’90: mi vengono in mente client di posta elettronica che mostrano scritte tridimensio- nali, che avvisano della ricezione di nuove e-mail visualizzando delle animazioni e riproducendo la frase “You’ve got mail! ”, e così via. In confronto ai client di posta elettronica “reali”, esistenti quando quei film ve- nivano realizzati, quelli erano molto più belli e, per certi versi, “irresistibili”, 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
  33. 33. 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 utilizza- re 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), sen- za 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
  34. 34. 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 bidimensiona- le 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 avan- zata di documenti testuali) con un modello di programmazione consistente e una buona integrazione tra i diversi tipi di oggetti. Inoltre, buona parte del- le 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 visua- lizzata. Se, per esempio, essa veniva sviluppata per un Ultra-Mobile PC (che, tipicamente, ha un monitor da quattro a sette pollici e una risoluzione ade- guata) e poi veniva utilizzata su un computer con uno schermo da 20” (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
  35. 35. 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 utilizza- vano 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’al- tro 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 uti- lizza 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 estre- mamente 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 persona- lizzazioni 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 caratteri- stiche 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
  36. 36. 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 appli- cazioni 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
  37. 37. 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 al- la 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 indipen- dente 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 istan- taneamente il risultato del codice XAML salvando un file con estensione .xaml e 32
  38. 38. 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 pri- ma riga di XAML compare l’identificatore xmlns, seguito quello che sembra un in- dirizzo Internet: quello è il namespace XML associato al namespace .NET System. Windows.Controls. Come per ogni namespace XML, non si trova nessuna web page a quell’indirizzo: è solo una stringa arbitraria. Il namespace XAML dell’esempio contiene tutti i seguenti namespace C#, rea- lizzando quindi un mapping molti-a-uno: • System.Windows; • System.Windows.Automation; • System.Windows.Controls; • System.Windows.Controls.Primitives; • System.Windows.Data; • System.Windows.Documents; • System.Windows.Forms.Integration; • System.Windows.Ink; • System.Windows.Input; • System.Windows.Media; • System.Windows.Media.Animation; • System.Windows.Media.Effects; • System.Windows.Media.Imaging; 33
  39. 39. 4 – Tecnologia utilizzata • System.Windows.Media.Media3D; • System.Windows.Media.TextFormatting; • System.Windows.Navigation; • System.Windows.Shapes; Degni di nota sono soprattutto i namespace appartenenti a Controls che conten- gono i controlli principali XAML (come i bottoni, per esempio), Forms.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 prece- dente. 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
  40. 40. 4 – Tecnologia utilizzata Keyword Descrizione x:Name Associa un nome a un elemento così che possa essere richiamato dal codice procedurale. x:Class Definisce una classe per l’elemento radice che deriva da un namespace .NET creato ad-hoc. x:Key Specifica la chiave di un oggetto quando viene aggiunto a un dizionario. x:Uid Segna un elemento con un identificativo utilizzabile per la localizzazione in più lingue. x:Null Rappresenta un riferimento a null. x:Static Associa un elemento a una proprietà, un campo, una costante o a un valore di enumerazione statico definito nel linguaggio procedurale. Tabella 4.1: Alcune comuni keyword XAML </Button> Lo stesso risultato si può anche ottenere omettendo l’elemento di proprietà perché oggetti come i bottoni utilizzano i loro figli come contenuto effettivo del bottone: <Button xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"> <Rectangle Height="40" Width="40" Fill="Black" /> </Button> Collegato al discorso della personalizzazione degli elementi XAML è dovero- so parlare anche di dizionari, control template e stili, visto che si sono 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
  41. 41. 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 con- trol 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
  42. 42. 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 rappre- sentazione 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 richiama- to 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 automatica- mente 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
  43. 43. 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
  44. 44. 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, soprat- tutto 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 piatta- forma .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 inte- ragiscono 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 permet- te di utilizzare questi controlli proprio come se fossero controlli nativi WPF. 39
  45. 45. 4 – Tecnologia utilizzata L’unico “problema” è che questi controlli sono generalmente scritti in C++, e do- vrà essere incluso in un altro file C++ in modalità managed che, però, non 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’ap- plicazione Win32: il 3D, il supporto avanzato per i documenti, l’animazione e così via. Anche se non si ha bisogno di tali funzionalità, ci si può avvantaggiare 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 co- prire 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 logi- co 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
  46. 46. 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 Foun- dation e Windows Forms (in seguito, abbreviato con WinForms) dovrebbero essere abbastanza evidenti, anche se WPF non nasce per sostituire Windows Forms. 41

×