Stato della connessione

Per l’esecuzione di una serie di prove, in particolare per emulare l’invio

da parte della Centrale Operativa di un alert, si `e dotata la MainActivity

di un pulsando che quando premuto codifica un messaggio opportunamente costruito, il quale una volta ricevuto viene interpretato definendo i contenuti dell’alert visualizzata dall’operatore.

110 CAPITOLO 8. SVILUPPO PROTOTIPALE DEL SISTEMA

Figura 8.11: Gestione delle connessioni server side.

Per evitare una serie di errori runtime, si `e dovuto gestire lo stato della con-

nessione con il sistema client side evitando ad esempio di inviare informazioni se la socket non fosse stata creata, questi ed altri controlli vengono eseguiti dal componente, ancora attualmente in versione base, che permette l’uscita di un messaggio solo dopo aver verificato tutte le condizioni necessarie. Per fare

Considerazioni sull’usabilit`a e

validazione del prototipo

Lo scopo del seguente capitolo `e tra gli altri quello di raccogliere una serie

di dati che permettano di validare il lavoro svolto in modo da poter creare una prima base di conoscenza in un’area di interesse ancora giovane e per la quale

non si hanno dati per un confronto diretto. La fase di valutazione sull’usabilit`a

del sistema avviene in riferimento ad una serie di principi guida che di seguito verranno discussi ed in relazione ai quali verranno creati questionari che per-

mettano di valutare l’usabilit`a del prototipo costruito in differenti situazioni

cercando di identificare gli scenari particolari di utilizzo. La valutazione av-

verr`a tramite una serie di test da parte di utente con background differenti in

modo da rendere valido il campione scelto per la valutazione.

9.1

Principi per il corretto design: euristiche

di Nielsen

Nielsen defin`ı una serie di principi guida per la progettazione di interfacce grafiche, questo pur non essendo precisamente il campo di interesse in quanto

l’obiettivo `e la progettazione di interfacce per sistemi wearable accedibili me-

diante interazione hands free, ricoprono comunque un ruolo di riferimento e per completezza vengono citate e riproposti i concetti

• Visibilit`a dello stato del sistema: il sistema deve sempre fare in

modo di tenere informato l’utente in relazione a quanto sta succedendo nel sistema stesso attraverso una serie di feedback utili allo stesso e in un intervallo temporale adeguato all’utilizzo del sistema che se ne vuole fare;

112 CAPITOLO 9. VALIDAZIONE DEL PROTOTIPO • Relazione tra il sistema e il mondo reale: le notazioni usate dal sistema devono essere sempre comprensibili all’utente deve quindi utiliz- zare frasi, parole e concetti familiari all’utente piuttosto che al sistema stesso. Seguendo inoltre le convenzioni presenti nel mondo reale permette di avere informazioni appaiano in un ordine logico e naturale;

• Controllo utente e libert`a: l’utente tende a attivare delle funzionalit`a

del sistema per errore occorre quindi garantire all’utente una sorta di “uscita di sicurezza” per fare in modo di lasciare attivi i soli cambiamenti voluti alleggerendolo dal compito di ricordarsi i passi, magari sbagliati,

che lo hanno portato all’attivazione di funzionalit`a non richieste. In

poche parole occorre gestire con un supporto ad hoc le operazioni di “undo”;

• Standardizzazione e consistenza: occorre fare in modo che l’uten- te non senta il bisogno di chiedersi se con operazioni diverse da quelle effettuate si riesca a raggiungere comunque lo stesso obiettivo. Biso- gna quindi associare delle operazioni prestabilite e seguire le eventuali convenzioni presenti sulla piattaforma di utilizzo;

• Prevenzione degli errori: si sa che un buon messaggio di errore o di prevenzione dello stesso possa mettere in guardia l’utente sull’operazio-

ne che sta per eseguire e le sue conseguenze sul sistema; occorre per`o

ricordare come una buona progettazione possa essere la base dello stesso

garantendo delle fondamenta ancora pi`u solide dal punto di vista proget-

tuale. Inoltre pi`u che informare l’utente a posteriori del verificarsi dell’er-

rore, occorrerebbe gestirle evitando il verificarsi dello stesso se possibile o avvertire l’utente con opzioni di conferma prima che un’operazione venga eseguita;

• Riconoscimento piuttosto che richiamo: occorre fare in modo che il carico di memoria a fronte dell’utilizzo del sistema sull’utente sia minimo: non deve essere l’utente a ricordare delle informazioni per l’utilizzo del sistema o per la navigazione dello stesso ma sia quest’ultimo a mantenere un pool di informazioni essenziali sempre visibili e comunque facilmente accedibili e contestuali allo stato del sistema;

• Flessibilit`a e facilit`a d’uso: occorre considerare il target di utenza

del sistema questo vuol dire che lo stesso deve poter permettere ad un utente esperto una completa personalizzazione degli aspetti riguardanti

l’usabilit`a, mantenendo comunque una semplicit`a di utilizzo per l’utente

• Estetica e design minimalista: le informazioni fornite dall’applica-

zioni devono essere chiare e non minare la semplicit`a d’uso del sistema

precedentemente citata, ogni informazione extra non presentata secondo i giusti criteri rischia di ottenere un effetto negativo sull’utente portando confusione piuttosto che chiarezza;

• Aiutare l’utente ad identificare l’errore: i messaggi di questo tipo, ovvero quelli che indicano il verificarsi di una situazione di errore devono permettere di identificare precisamente il punto del sistema in cui inter- venire suggerendo una soluzione, non presentando informazioni inutili o ancora peggio del codice;

• Documentazione: anche se non necessaria per l’utilizzo del sistema, ri- copre un ruolo fondamentale la documentazione, questa deve essere facil- mente consultabile e improntata sul task dell’utente, fornendo soluzioni chiare basate su step successivi.