UNIVERSITÀ DEGLI STUDI DI PISA Dipartimento di Filologia, Letteratura e Linguistica Corso di Laurea Magistrale in Informatica Umanistica
USABILITÀ NELLA CREAZIONE
DI REGOLE DI PERSONALIZZAZIONE
DIPENDENTI DAL CONTESTO
RELATORE Prof. Fabio Paternò
Candidato Gabriella Lucci
1
Indice
1 INTRODUZIONE ... 3 2 STATO DELL’ARTE ... 7 2.1 TagTrainer ... 8 2.2 Keep Doing It ... 10 2.3 Puzzle ... 13 2.4 Zipato ... 142.5 Edison Smart Living ... 16
2.6 AutomateIt ... 18 2.7 MacroDroid ... 20 2.8 IFTTT ... 23 2.9 Zapier ... 25 2.10 Droid Automation ... 27 2.11 Trigger ... 30 3 LE APP ANALIZZATE ... 35 3.1 Atooma ... 35 3.2 Locale ... 38 3.3 Tasker ... 40 4 TEST DI USABILITÀ ... 43 4.1 Espressività ... 44 4.2 Test utente ... 49 4.2.1 Esecuzione test ... 51 4.2.2 Esito ... 53
4.2.3 Tempo medio di esecuzione ... 56
4.2.4 Errori e suggerimenti gravi ... 58
4.3 Conclusioni ... 61
5 CARD SORTING ... 67
6 EVOLUZIONE DEL SETTORE ... 79
6.1 Atooma ... 79
6.2 Locale ... 87
6.3 Tasker ... 88
7 CREAZIONE DEL MOCKUP ... 94
7.1 EvA ... 95
7.1.1 Categorie ed elementi ... 96
7.1.2 Espressività ... 98
7.1.3 Creazione di una regola ... 99
7.2 Principi generali ... 118
8 CONCLUSIONI ... 124
2
APPENDICE A ... 131
A.1 Profilo utenti ... 131
A.2 Esito task ... 132
A.3 Tempi di esecuzione ... 133
APPENDICE B ... 134
B.1 Tabelle funzionalità mockup ... 134
3
CAPITOLO 1
INTRODUZIONE
Gli smartphone si sono insediati talmente tanto a fondo nelle nostre vite che oggi sentiamo addirittura parlare della nascita di veri e propri stati di dipendenza dai dispositivi mobili. La rapida espansione della tecnologia mobile ha infatti fornito nuovi importanti stimoli al settore della progettazione informatica. In breve tempo il web si è adeguato alle dimensioni dei nuovi schermi mobili e sono nate innumerevoli applicazioni capaci di sfruttare le crescenti potenzialità del nuovo dispositivo per soddisfare esigenze più o meno reali di un bacino di utenza sempre più esteso e variegato.
L'utilizzo quotidiano degli smartphone da parte di tipologie di utenti estremamente eterogenee ha aperto nuovi campi d'applicazione per l'End User Development (EUD), cresciuto anche in ambiente mobile con lo scopo di fornire agli utenti senza alcuna esperienza informatica i mezzi per creare, modificare o adattare un prodotto software. La progettazione EUD fornisce quindi ad ogni utente la possibilità di diventare autore di un sottoprogramma altamente personalizzato, creato senza la necessità di conoscere alcun linguaggio di programmazione [10].
Parallelamente, le caratteristiche proprie della tecnologia mobile e l'utilizzo di sensori sempre più sofisticati hanno provocato la nascita di software capaci di andare incontro a necessità di adattamento che coinvolgono tanto lo smartphone quanto l’ambiente che ci circonda. L’EUD ha quindi affrontato il confronto con l’Internet of Things (IoT), l’utilizzo della rete da parte degli oggetti, cosiddetti smart object, capaci di fornire informazioni e comunicare tra loro. Gli smart object sfruttano la rete internet per raccogliere dati su se stessi, monitorando così il loro stato e ponendosi in collegamento diretto con la realtà. Fanno parte dell’Internet delle cose tutti quegli apparecchi che sono in grado di interagire con la realtà fisica; come
4
un condizionatore che si attiva quando si supera una certa temperatura; una sveglia che suona se c’è molto traffico o una lampadina che si accende in condizioni di scarsa luminosità. I campi di applicazione dell’Internet delle cose sono potenzialmente infiniti; l’intelligenza ambientale (Aml) infatti è ormai una realtà concreta sia a livello domestico che professionale.
Tendenzialmente l’impiego dell’IoT è legato alla computazione
context-aware, il paradigma di programmazione che consente
l’esecuzione di attività in base a eventi che avvengono all’interno di essi o nell’ambiente circostante. Le tecnologie dipendenti dal contesto si configurano quindi come sistemi capaci di reagire ai cambiamenti per andare incontro alle più disparate necessità.
Lo sviluppo di applicazioni context-aware ha coinvolto anche l’ambiente mobile che in breve tempo si è arricchito di applicazioni che consentono la programmazione di regole per eseguire attività automatiche che agiscono sia sul telefono cellulare, che nell’ambiente, che all’interno delle piattaforme social. Con questo genere di applicazioni, l’utente dispone dello strumento con cui comunicare ad un sistema cosa vuole che accada in particolari circostanze. Potrebbe ad esempio voler pubblicare una foto sul proprio account facebook ogni volta che questa viene caricata su un cloud; disabilitare o abilitare la connessione dati lontano da casa; accendere l’irrigazione in un momento preciso della giornata e così via.
Consentire a chiunque di essere programmatore delle proprie regole di adattamento, come richiedono i sistemi di End User Development, non può prescindere dalla progettazione di interfacce context-aware intuitive. Inoltre la possibilità data ad ogni utente di creare regole altamente personalizzabili racchiude in sé due aspetti cruciali: non solo l’usabilità di un’applicazione ma anche la capacità espressiva che questa possiede.
Allo scopo di approfondire questi studi si è eseguito un test di usabilità su tre applicazioni Android dipendenti dal contesto attualmente in uso e disponibili sul Play Store: Atooma, Locale e Tasker. Le versioni delle app sottoposte al test sono state rispettivamente la 1.2.6; la 5.0 e la 4.2.
5
La fase preliminare è stata la misurazione del grado di espressività delle tre applicazioni, cioè il valore numerico che indica la quantità di funzionalità posseduto da ognuna. Questo dato è stato utile per scoprire, al termine del test utenti, l’esistenza di una relazione tra il numero di funzionalità di un’app e la sua usabilità. Si è quindi proceduto a sviluppare una classificazione degli elementi che potesse rendere confrontabili le tre app vista la loro differente organizzazione interna e si sono successivamente conteggiate le funzionalità presenti in ognuna di esse.
Lo studio di usabilità si è svolto attraverso un test utente utilizzando la tecnica del think aloud. Ai partecipanti è stato quindi chiesto di riferire a voce ciò a cui stavano pensando e le operazioni che stavano compiendo durante l’interazione con le app. I diciotto partecipanti, di età compresa tra i 19 e i 32 anni, sono utenti con discreto livello di familiarità nell’utilizzo di applicazioni interattive mobili ma senza alcuna competenza nel campo della programmazione. Dopo una prima fase di apprendimento del contesto di riferimento, ad ogni utente è stato chiesto di svolgere due task di difficoltà crescente su tutte e tre le app Android in esame e di compilare un questionario finale per esprimere i propri pareri e proporre eventuali suggerimenti. Durante l’esecuzione del test si è registrato il tempo impiegato da ogni utente per lo svolgimento dei task assegnati nonché il numero e il tipo di errori commessi (gravi, medi, trascurabili). I dati quantitativi e qualitativi raccolti hanno condotto alla formulazione di ipotesi di miglioramento di un’interfaccia dipendente dal contesto. Si è osservato come alcune caratteristiche grafiche e funzionali possano influenzare la percezione di un sistema da parte dell’utente, portandolo ad avere impressioni differenti riguardo la sua difficoltà di utilizzo.
Dopo l’analisi dell’interazione con le tre interfacce si è cercato di realizzare una categorizzazione razionale degli elementi evento (ciò che fa scattare una regola) e azione (operazioni svolte dalla regola) attraverso la metodologia del card sorting. La precedente misurazione dell’espressività delle app è tornata utile anche nell’individuazione degli elementi da categorizzare che sono risultati essere in totale 39. Sono stati quindi
6
realizzati i cartoncini da sottoporre agli utenti coinvolti; si è chiesto loro di raggruppare secondo criteri propri, prima i cartoncini riferiti agli eventi, poi quelli riferiti agli elementi azione e di associare un nome ad ogni gruppo creato. Le classificazioni degli utenti sono state riportate all’interno del software UXSort, uno strumento di analisi gratuito che esamina le classificazioni di più utenti e ne analizza l'omogeneità mediante cluster analysis, generando il corrispondente dendrogramma. L’interpretazione dei dendrogramma e l’analisi dei nomi dei gruppi ha condotto alla generazione di tre risultati di classificazione ugualmente attendibili, che differiscono per l’organizzazione di pochi elementi e per il nome attribuito ad alcune categorie.
I dati emersi dallo studio di usabilità e dal card sorting hanno permesso di ottenere delle linee guida che riguardano tanto le attività di interazione con un’interfaccia dipendente dal contesto che la strutturazione interna dei suoi contenuti. Da sottolineare che in seguito alcune app hanno subìto aggiornamenti che rispettano i principi di usabilità e raggruppamento emersi dal nostro studio. In particolare Atooma ha modificato il posizionamento di un elemento e Tasker rallegrato il colore della sua interfaccia e aggiunto una nuova modalità di visualizzazione degli elementi.
Grazie ai dati raccolti in fase di analisi si sono potuti ottenere informazioni utili alla costruzione di un’interfaccia dipendente dal contesto che rispecchiasse i risultati acquisiti. Tenendo conto quindi delle interazioni degli utenti coinvolti nel test, delle loro considerazioni e dei raggruppamenti generati, si è realizzato un mockup che contenesse le caratteristiche di usabilità raccolte. Nascono così gli screen del prototipo EvA, nome scelto per l’accostamento delle vocali iniziali nelle parole “Evento” e “Azione” nonché per il riferimento cattolico al concetto di creazione. Gli screen del mockup EvA sono stati realizzati con il software grafico Adobe Photoshop Cs6 mentre per la costruzione del mockup è stato scelto InVision, tool di prototipazione largamente utilizzato nel campo dell’UI design.
7
CAPITOLO 2
STATO DELL’ARTE
Negli ultimi tempi il fondamento nello sviluppo di sistemi automatici interattivi si basa sempre più sulla necessità di porre al primo posto le esigenze dell’utente.
Concentrarsi sui bisogni concreti dell’utente finale vuol dire creare applicazioni che permettano ad una pluralità di persone estremamente diverse tra loro, la creazione regole di automazione in grado di agevolarli nelle attività che svolgono quotidianamente.
La programmazione di applicazioni adattabili al contesto (context-aware) si è concretizzata nello sviluppo di sistemi liberamente personalizzabili, utilizzabili anche da persone che non possiedono specifiche conoscenze informatiche (End User Development).
Oggi la tecnologia non ci consente solo di gestire automaticamente il comportamento del nostro smartphone, ma anche di controllare, attraverso l’uso di dispositivi e sensori, lo stato dell’ambiente circostante, andando così incontro ad esigenze di adattamento sempre più articolate. Attraverso la rete infatti, l’internet delle cose (IoT) e il concetto di l’intelligenza ambientale (AmI) ci permettono di gestire in autonomia il funzionamento degli oggetti che abbiamo intorno, come nel caso della smart home, che sfrutta i progressi nel campo della domotica consentendo a chi dimora in un’abitazione di controllare e gestire a distanza tutte le apparecchiature elettroniche al suo interno.
In un quadro di così ampio respiro per l’End User Development (EUD), visto l’aumentare della complessità e delle funzionalità esprimibili attraverso sistemi dipendenti dal contesto, la progettazione di interfacce usabili risulta un fattore sempre più determinante per il successo di un’applicazione.
8
Di seguito vengono prese in esame alcune applicazioni web e/o mobili più o meno recenti, sviluppate in settori diversi per soddisfare le medesime esigenze di usabilità e insieme, di personalizzazione.
2.1 TagTrainer
Sviluppato nel 2014, TagTrainer si inserisce nel campo medico della riabilitazione fisica. È una piattaforma che utilizzando la tecnologia RFID, consente ai fisioterapisti di creare esercizi riabilitativi per pazienti con problemi di mobilità a mani e braccia, basandosi sulla manipolazione di oggetti di uso quotidiano [18].
Lo spazio di lavoro è costituito da una tavoletta fisica che fornendo feedback di tipo audiovisivo, guida e monitora l'interazione del paziente con l'oggetto – o le parti dell'oggetto – a cui è stato apposto il tag RFID.
L'ambiente è stato progettato per creare programmi di
addestramento composti di attività sequenziali: i pazienti affrontano il programma di riabilitazione motoria eseguendo uno dopo l'altro gli esercizi indicati dalla “TagTrainer Patient Interface” (TTPI), che risponde ai progressi fornendo i feedback audiovisivi specificati dal terapista in fase di progettazione.
I terapisti possono creare e modificare gli esercizi di riabilitazione attraverso la “TagTrainter Exercise Creator” (TEC): nello spazio di lavoro posizionato al centro dello schermo è presente una timeline che contiene la sequenza di tutte le azioni associate agli oggetti coinvolti nell'esercizio.
Le azioni (es. “Lift object”, “Move object” ecc.) sono memorizzate in un'apposita libreria, corredate da un'icona, visualizzate in una finestra collocata sulla sinistra e associabili all'oggetto tramite trascinamento nell'area di lavoro. A seconda dell'azione selezionata (es. “Place object”), una finestra posta sul lato destro dà la possibilità di specificarne le proprietà, come l'esatta posizione che l'oggetto deve assumere sulla tavola in un dato momento. Oltre alle azioni di manipolazione visualizzate,
9
possono esserne usate altre, come l'introduzione di istruzioni e pause (fig. 2.1).
Figura 2.1: TagTrainer Exercise Creator software. Timeline nell'area di lavoro centrale (A) in cui vengono trascinate le azioni relative agli oggetti coinvolti nell'esercizio (“Measuring cup”, “Cup”). Le azioni, corredate da icone, sono mostrate nel pannello posto a sinistra dell'area di lavoro (B). Il pannello sulla destra (C), consente di specificare le proprietà dell'azione selezionata (“Place object”).
. L'interfaccia di TagTrainer visualizza tutte le operazioni nella stessa schermata, dividendola in sezioni ridimensionabili: l'esercizio viene sviluppato nell'area di lavoro centrale dove una timeline comunica la possibilità di mettere in sequenza delle azioni; le icone e le etichette di quelle disponibili sono collocate in un panello sulla sinistra e associabili tramite trascinamento all'oggetto a cui è stato precedentemente applicato un tag RFID.
Le proprietà disponibili per l'azione selezionata, tra cui l'inserimento di pause o di specifiche istruzioni, vengono chieste in input nella parte destra della schermata utilizzando menù a tendina e check box o, nel caso di azioni riferite a spostamenti, attraverso un'immagine che riproduce la tavoletta fisica in miniatura.
Pur essendo pensato per soddisfare esigenze specifiche nel campo della riabilitazione motoria, il terapista che utilizza la “TagTrainter Exercise
10
Creator” deve creare programmi personalizzati collegando tra loro un certo numero e tipo di task.
2.2 Keep Doing It
Keep Doing It, realizzato all’inizio del 2014 alla Pontificia Università Cattolica di Rio de Janeiro, utilizza la metodologia della “Programmazione per dimostrazione” in ambiente mobile. La “Programmazione per dimostrazione” (Programming by demonstration) è una delle tecniche usate dall’EUD per la creazione di comportamenti automatizzati, in cui i compiti da eseguire non vengono appresi dal dispositivo sulla base di specifiche istruzioni ricevute in input dall'utente, ma dedotti a seconda delle interazioni che egli esegue abitualmente con il proprio dispositivo. In sostanza nei sistemi basati sulla programmazione per dimostrazione (PbD), la selezione delle operazioni che costituiscono un comportamento sono inferite dall'uso stesso che l'utente fa del dispositivo [15].
Keep Doing It è un tool che consente all'utente di generare regole di automazione dipendenti dal contesto in base alla cronologia di utilizzo del dispositivo: il sistema memorizza le interazioni dell'utente con l'apparecchio all'interno di un database (es. disattivazione del Wi-Fi, inserimento degli auricolari, apertura di un'applicazione ecc.); al lancio dell'applicazione essa propone una serie di comportamenti generati utilizzando un algoritmo di inferenza che segue il formato ECA (Event-Condition-Action), dove perciò ogni regola può essere composta da: un evento, zero o più condizioni, una o più azioni.
Le regole sono proposte testualmente per esteso ed espresse in linguaggio naturale: l'evento è anticipato dalla congiunzione temporale “When”, le eventuali condizioni dalla particella “If”, e le azioni attraverso il verbo imperativo che le esprime (fig. 2.2).
Se il sistema non rileva alcuna regola, attraverso una finestra temporale l'utente può richiedere al programma di considerare solo le
11
interazioni effettuate nell'arco di un certo intervallo: 15, 30, 45 o 60 secondi prima (figura 2.3).
Figura 2.2: Interfaccia “My rules” di Keep Doing It (sinistra). Una volta premuto il tasto “+”, il sistema propone l'automazione di due regole (destra). Gli eventi sono riportati con icone di colore rosso, le condizioni in giallo e le azioni in verde. La congiunzione tra un evento e una condizione è rappresentata dal tasto +, mentre il legame con le azioni corrispondenti dal simbolo →
Nella descrizione testuale di una regola le proprietà o gli stati di eventi e azioni sono riportati in grassetto; in aggiunta ai termini “When” e “If”, l'interfaccia distingue il ruolo delle tre componenti della regola da automatizzare utilizzando icone di diverso colore: il rosso rappresenta l'evento mentre il giallo e verde rappresentano rispettivamente condizione e azione. Se una regola è composta da un evento e una o più condizioni, la loro unione è rappresentata graficamente dal simbolo +. Il legame con le azioni corrispondenti (anch'esse unite graficamente dal +) è invece rappresentato dal simbolo di una freccia (fig. 2.2).
Se il sistema inferisce una regola che non soddisfa pienamente le esigenze dell'utente, egli può modificarla selezionando ed eliminando indipendentemente eventi, condizioni e azioni che la compongono.
Keep Doing It va incontro alle esigenze dell'EUD offrendo la possibilità di creare regole di automazione sia basandosi sulle interazioni precedenti dell'utente con il dispositivo (e in un certo intervallo temporale), sia attraverso l'editing manuale (fig. 2.4).
12
Figura 2.3: Quando il sistema non rileva alcuna interazione (sinistra) l'utente può eseguire il refresh (icona in alto a destra) o specificare dal menù a tendina della finestra temporale l'arco di tempo trascorso dall'ultima interazione (15, 30, 45 o 60 secondi).
Fig. 2.4. Esempio di editing manuale della condizione “If a wired headset is not connected”. Da “Add a condition” l'utente accede all'elenco degli attributi disponibili per quel tipo di operazione. Scegliendo “Headset” passa all'impostazione dei suoi possibili stati o proprietà e infine con “Done” torna alla schermata di partenza, dove la condizione appena impostata viene associata alla rispettiva icona ed espressa per esteso in linguaggio naturale.
I risultati ottenuti al termine del test utenti su quest’applicazione dimostrano che gli utilizzatori apprezzano la facilità d’uso dell’interfaccia, seppure alcuni avrebbero preferito la presenza di una piccola guida di utilizzo e la possibilità di stabilire un intervallo temporale di inferenza arbitrario [6]. A differenza di altre applicazioni inoltre, l'utente non può memorizzare e successivamente rintracciare una regola creata scegliendo un nome significativo che la rappresenti.
13
2.3 Puzzle
Il framework Puzzle è stato realizzato nel 2012 presso il laboratorio HISS (Human Interface in Information Systems) del Cnr di Pisa. È dedicato alla creazione di applicazioni automatiche eseguibili sia su oggetti fisici che in ambienti mobili touch-based, dove il collegamento tra le componenti di un'applicazione – sequenze di azioni – è rappresentato dalla metafora grafica dei pezzi di puzzle.
I pezzi di puzzle sono organizzati in 7 categorie estendibili (“Social”, “Gallery”, “Location”, “Phone”, “Widget”, “Voice”, “Operators”), selezionabili da un menù a scorrimento verticale posto sul lato sinistro dello schermo (fig. 2.5). Ogni pezzo contenuto in una categoria è identificato da: una forma che esplicita la possibilità o meno di essere collegato a un altro, un'etichetta che la descrive (es. “Send Txt Msg”, “Facebook”) e un cerchietto, il cui colore stabilisce a quali altri pezzi può essere connesso (solo i pezzi contraddistinti da cerchietti dello stesso colore possono essere collegati).
L'ambiente per la creazione e la modifica di un'applicazione (“Authoring Tool”) dispone in fila gli oggetti appartenenti a una categoria tramite menù a scorrimento orizzontale sul fondo della pagina; da qui i pezzi possono essere trascinati nello spazio di lavoro e collegati tra loro (fig. 2.6).
Cliccando su un pezzo è possibile specificarne o editarne le proprietà. Il programma esegue una sequenza di azioni leggendo i pezzi di puzzle connessi tra loro da sinistra verso destra e dall'alto verso il basso.
Possiede anche un pezzo chiamato “Loop” (rappresentato dalla rispettiva icona) attraverso cui l'utente può iterare una certa sequenza di azioni un numero arbitrario di volte (fig. 2.6) [5].
Puzzle automatizza una serie di operazioni ma non consente di specificare gli eventi e le condizioni in base ai quali eseguirle. Inoltre, a causa delle ridotte dimensioni degli schermi mobili, il metodo del drag and drop potrebbe non essere la soluzione più conveniente per la selezione e il collegamento dei pezzi di puzzle. I risultati dello studio di usabilità
14
condotto [4] dimostrano inoltre che nonostante il puzzle sia la metafora grafica di interazione più coinvolgente per l’utente, essa produce problemi di visibilità e comprensione generale delle regole.
2.4 Zipato
Zipato è una piattaforma nata a Zagabria che consente lo sviluppo di regole per il controllo e l’automazione dell’ambiente domestico a distanza [21]. Agisce su numerose apparecchiature consentendo il controllo da remoto del sistema dall’allarme, di irrigazione, dell’illuminazione, oltre al monitoraggio della temperatura e dei consumi energetici al fine di ottimizzare le prestazioni domestiche e ridurre i costi. Grazie al controller Zipatile, lo stato e le condizioni dell’ambiente vengono monitorate costantemente e l’utente attraverso l’app dedicata può modificarne le impostazioni da remoto in base alle proprie necessità.
Il sistema funziona tramite l’utilizzo del gateway Zipabox a cui vengono collegati sensori ed attuatori in grado di rilevare i cambiamenti
Figura 2.5. Impostazione dell'azione “Image” appartenente alla categoria “Gallery”, selezionata precedentemente dal menù a scorrimento verticale.
Figura 2.6: Authoring Tool. Esempio di applicazione che, iterativamente, copia una citazione e la invia come sms e come post facebook.
15
che avvengono in casa (come temperatura, intrusioni, fughe di gas, illuminamento, consumi ecc.). Il controllo a distanza non avviene solo con il settaggio manuale: Zipato consente infatti la possibilità di costruire delle regole che effettuino i cambiamenti desiderati in modo del tutto automatico. È possibile monitorare, modificare o eliminare una regola da remoto utilizzando il proprio smartphone.
Le regole che gestiscono l’automazione a distanza vengono create accedendo all’ambiente visuale di programmazione web “Rule Creator” [22] da computer o tablet. L’interfaccia grafica del tool è basata sul progetto Scratch sviluppato al MIT e sfrutta il meccanismo dei pezzi di puzzle come metafora della combinazione tra eventi, condizioni e azioni.
L’utente può quindi sviluppare le proprie regole trascinando dal menù posto a destra i pezzi di puzzle di diversa forma e colore corrispondenti agli elementi che desidera inserirvi (fig. 2.7).
Le regole che è possibile creare con Zipato possono assumere diversi livelli di complessità. Tutte iniziano con i blocchi di controllo di colore verde, introdotti dall’istruzione “When” e terminano con i blocchi azione di color arancio (fig. 2.8). Oltre alla specifica degli eventi che determinano l’esecuzione della regola (le istruzioni “When”), il blocco di controllo può contenere anche una serie di “If” (condizioni che, se verificate, fanno scattare la regola); la struttura “If/Else” (condizioni che, se non verificate, eseguono le azioni “Else”) e l’istruzione “Repeat” che consente di ripetere le azioni un numero fissato di volte. Inoltre con le istruzioni “Join” e “Stop” è possibile rispettivamente interrompere le esecuzioni successive della regola o interrompere l’esecuzione della regola corrente.
16
Figura 2.7: Zipato “Rule Creator”. Esempio di sviluppo di una regola creata assemblando pezzi di puzzle trascinati dal menù a destra.
Figura 2.8: ingrandimento di fig. 2.7. Il blocco di colore verde identificato dalla parola “WHEN” contiene tutta la regola cioè la condizione sul sensore relativo alla porta (pezzo azzurro) impostato su “open” e le due azioni (di colore arancione) che impostano rispettivamente la luminosità della lampadina a led al valore 50 e il colore della tonalità rgb specificata.
2.5 Edison Smart Living
Progettato dall’azienda italiana Edison, anche il sistema Smart Living attraverso un hub dedicato permette di controllare e gestire gli ambienti domestici in cui vi siano inseriti dispositivi e sensori di qualche tipo (prese di accensione elettrodomestici, rilevazione apertura porte, movimento, temperatura ecc.) [16].
17
Da tablet o smartphone, utilizzando l’applicazione dedicata gratuita ed accedendo al proprio gateway, è possibile controllare e settare a distanza stato e impostazioni dei dispositivi connessi.
La prima operazione richiesta in fase di creazione è la scelta di un nome che la identifichi, seguita dalla possibilità di specificare giorni ed orari in cui eseguirla. Dai campi successivi “Se”, si possono inserire una o più condizioni: cliccandoci l’utente sceglie da una lista il sensore o il dispositivo su cui desidera impostare il trigger e il relativo stato. A questo punto dal campo “Allora” è possibile scegliere una sola azione da eseguire, selezionando il dispositivo interessato e l’attività che deve svolgere. La creazione delle regole in Smart Living consente di specificare un tempo di ritardo tra il verificarsi degli eventi e l’esecuzione dell’azione corrispondente e di ricevere, se l’utente desidera, tre tipi di notifica all’avvio della regola (fig. 2.9).
Figura 2.9: creazione della regola “se il sensore della porta finestra si attiva, avvia registrazione della cam per due secondi”. Dal campo “Ritardo” è possibile specificare dopo quanto tempo si desidera attivare la regola; la notifica della regola può essere ricevuta via e-mail o con notifiche push e audio.
18
2.6 AutomateIt
Parallelamente al largo aumento di piattaforme in grado gestire automaticamente le funzioni dei luoghi fisici che l’utente frequenta più abitualmente, continuano a nascere applicazioni dedicate esclusivamente all’automazione mobile.
Tra le applicazioni di automazione pensate specificatamente per Android c’è AutomateIt, il cui numero di download oscilla tra un milione e cinque milioni di utenti [2]. Il limite evidente della versione free è che permette la creazione di regole che possono essere composte da un solo evento e una sola azione. È possibile sviluppare regole con un maggiore numero di trigger e azioni sbloccando questa funzionalità: aquistando l’app al costo di 1,68€ o raggiungendo il punteggio minimo di 25, accumulabile grazie alla condivisione delle regole con i propri contatti e tramite canali social.
Lo studio di usabilità [3] ha di recente evidenziato come gli utenti preferiscano avere una maggiore libertà di combinazione di trigger e azioni. Dallo stesso studio è risultato altrettanto importante che un’applicazione permetta la condivisione delle regole all’interno di una comunità. AutomateIt, pur non possedendo una vera e propria community, permette di condividere le regole create con i propri contatti e di esportale in formato CSV.
All’avvio AutomateIt propone un set di sei regole preimpostate e già attive, identificate da un nome e dalle icone rispettivamente dell’evento e dell’azione al suo interno. Selezionando una regola appare il menù sottostante a scorrimento da cui è possibile eliminarla, disattivarla (in questo caso la regola comparirà nel tab “Disabilitate”), condividerla, eseguirla e copiarla. Dallo stesso menù è anche possibile visualizzare lo storico delle sue attività di esecuzione o caricare una regola (fig. 2.10).
19
Figure 2.10, 2.11, 2.12: visualizzazione delle regole preimpostate e navigazione dei tab “Evento” e “Azione”. In figura 2.10 l’apertura della regola “Silenzioso la notte” e il click sul pulsante “+” che conduce alla pagina “Nuova regola” da dove è possibile spostarsi liberamente tra i tab “Evento” e “Azione”. In figura 2.11 l’elenco degli elementi “Evento” (divisi nelle due categorie “Comune” e “Bloccato”); in figura 2.12 la lista degli elementi “Azione” (divisi nelle due categorie “Comune” e “Bloccato”).
La creazione delle regole avviene cliccando sull’icona del “+” in basso a destra di figura 2.10. L’utente può passare arbitrariamente dalla schermata “Evento” alla schermata “Azione”: l’ordine di selezione delle due componenti è indifferente; in entrambi i casi un messaggio avverte che è necessario selezionare un elemento dalla lista (con la dicitura “Bisogna scegliere un evento/azione”). Inoltre l’icona del punto interrogativo (al cui posto andrà l’icona dell’elemento scelto), rende chiaro che non è ancora stato selezionato alcunché (figg. 2.11 e 2.12).
Nella versione gratuita alcuni elementi Evento e Azione sono bloccati, così come la possibilità di collegare più condizioni tramite l’operatore OR (la regola viene eseguita se una delle condizioni risulta verificata).
Una volta selezionate un evento e un’azione è possibile nominare la regola, decidere se si vuole visualizzare un pop up una volta attivata e stabilire un tempo di ritardo nella sua esecuzione.
Come evidenziato dallo studio [4] gli elenchi filtrati sembrano bilanciare meglio dei blocchi di puzzle il rapporto tra l’usabilità di un’interfaccia e l’espressività che quel sistema è in grado di offrire. In
20
questo caso gli elementi Evento e Azione sono elencati tutti in lista, con una prima categorizzazione sommaria e fissa, e non organizzati in alcuna sottocategoria (figg. 2.11 e 2.12).
2.7 MacroDroid
Creata esclusivamente per Android e largamente utilizzata, MacroDroid è anch’essa un’applicazione per il controllo automatico delle funzionalità del proprio smartphone [13].
MacroDroid presenta le proprie voci tramite la visualizzazione di 6 pulsanti diversamente colorati di forma quadrata. Definisce le regole con il termine “Macro” (parola che nel gergo informatico indica un insieme di istruzioni eseguite al verificarsi di un evento). Queste ultime possono essere aggiunte e create premendo sul pulsante rosso “Nuova Macro” (fig. 2.13).
Per creare una Macro sono messi a disposizione i tab “Eventi”, “Azioni” e “Vincoli”, cioè condizioni da soddisfare affinché la Macro si attivi. Inserendo più di un vincolo è possibile scegliere tra gli operatori logici AND e OR.
Figura 2.13: schermata principale di MacroDroid. Le possibilità offerte da MacroDroid sono rappresentate da 6 pulsanti colorati di forma quadrata. In particolare il pulsante rosso “Nuova Macro” permette di procedere nella creazione di una regola.
21
Anche in questo caso la versione free limita alcune funzionalità consentendo la creazione di un massimo di cinque Macro. L’ordine di inserimento delle tre componenti è indifferente, l’utente può infatti navigare liberamente tra i tab e decidere arbitrariamente che tipo di elemento selezionare per primo. Per questo motivo tramite l’icona in basso a destra è possibile salvare una regola in qualsiasi schermata ci si trovi, purché si siano inserite almeno un evento e un’azione (figg. 2.14, 2.15 e 2.16).
Aprendo una categoria i suoi elementi interni sono visualizzati come pulsanti dello stesso colore che identifica il tab corrispondente e identificati da un’icona (fig. 2.17). In alto a destra di ogni schermata è presente l’icona del punto interrogativo che, per ogni elemento, permette di avere una descrizione testuale delle sue funzionalità (fig. 2.18).
Al termine della creazione di una Macro è richiesto di attribuirle un nome e, se l’utente desidera, una categoria tra quelle proposte dal sistema. La Macro viene poi visualizzata in sintesi (fig. 2.19); cliccandoci si passa alla schermata di modifica o aggiunta degli elementi (fig. 2.20). Dalla stessa schermata è possibile aggiungere una descrizione, provare la Macro e le azioni selezionate, duplicarla, condividerla, disattivarla, eliminarla e utilizzare la più complessa operazione di configurazione di variabili di diverso tipo.
A differenza delle altre applicazioni - fatta eccezione per Tasker - MacroDroid può potenzialmente raggiungere livelli di complessità elevati e più adatti a persone con un minimo background informatico, sia per la creazione di variabili, sia vista la possibilità di associare ad ogni azione delle condizioni proprie (“sottovincoli”) e di collegarle tramite gli operatori E/O/XER/NON.
L’applicazione non organizza in alcun modo gli elementi di “Eventi”, “Azioni” e “Vincoli” ma li espone in lunghe liste ordinate alfabeticamente, aiutando l’utente nel reperimento della componente desiderata tramite ricerca testuale.
22
Figure 2.14, 2.15, 2.16: in figura 2.14 l’elenco degli “Eventi” identificato dal colore rosso; in 2.15 la lista delle “Azioni” di colore azzurro e in figura 2.16 la finestra dei “Vincoli” di colore verde, liberamente navigabili.
Figura 2.17: apertura della categoria “Applicazioni” del tab “Eventi”. Gli elementi della categoria sono visualizzati con pulsanti dello stesso colore del tab ognuno rappresentato da un’icona.
23
2.8 IFTTT
È un’applicazione web gratuita ma anche un’app per dispositivi Android e iOS che conta un numero elevatissimo di utilizzatori [9].
Le regole in IFTTT vengono definite “Applets”. La particolarità di questa applicazione sta nel fatto che oltre ad avere trigger e svolgere attività automatiche che riguardano le funzionalità mobili più usate, consente di creare Applets basati sullo stato interno di centinaia e centinaia di servizi web, tra cui ovviamente i principali social network. I servizi web disponibili sono per l’appunto chiamati “Services”.
IFTTT è l’acronimo di “If This Then That” (Se Questo Allora Quello), proposizione condizionale usata per guidare l’utente nel processo di creazione dell’Applet.
Figura 2.19: visualizzazione di una Macro terminata, che permette l’upload
dell’ultima foto scattata dalla fotocamera attraverso lo scuotimento del telefono. La Macro risulta senza categoria perché nessuna tra quelle proposte le è stata assegnata.
Figura 2.20: apertura della Macro precedentemente creata per modificarne indipendentemente nome, categoria, “Eventi”, “Azioni” e “Vincoli”. Figura 2.18: descrizione
testuale a scomparsa che, cliccando sull’icona del “?”, spiega il funzionamento di ogni elemento della categoria “Applicazioni” del tab “Eventi”.
24
Cliccando sul pronome dimostrativo “this” si può selezionare il Services su cui impostare un determinato trigger (figg. 2.21-2.23); lo stesso meccanismo avviene per la scelta di un Services azione, che può essere svolta solo successivamente cliccando sul pronome “that” (fig. 2.23). Al termine della creazione, l’Applet apparirà identificata dall’icona e dal colore della funzionalità o servizio impostato come trigger e da una spiegazione testuale del suo funzionamento (figg. 2.25, 2.26).
Una delle limitazioni di IFTTT è la possibilità di associare un solo trigger (this) ad una singola azione (that), caratteristica che, come dimostrato nello studio [3] si rivela poco efficace quando il sistema viene paragonato ad applicazioni che permettono la creazione di regole con un numero maggiore di elementi. Dallo studio infatti è emerso che gli utenti preferiscono le possibilità offerta dall’app Atooma, che permette di specificare di più trigger e azioni all’interno della stessa regola e che si distingue inoltre per la sua facilità e rapidità di utilizzo.
Un altro aspetto che nello stesso studio è risultato essere poco apprezzato dagli utenti è infatti il protrarsi dei tempi di creazione di un Applet, dovuto alla necessaria connessione dei propri account e dei relativi servizi, sebbene la possibilità di accedervi sia stata valutata positivamente, come pure la possibilità di condividere gli Applet creati e conseguentemente di scaricare quelli sviluppati dagli altri utenti.
Figure 2.21, 2.22, 2.23: selezione del trigger per la creazione dell’Applet “If any new photo by me (su Instagram), then upload from my gmail account”. In fig. 2.21 la selezione dell’evento “this”. In fig. 2.22 la scelta del service Instagram. In fig. 2.23 la selezione dell’azione “that”.
25
Figure 2.24, 2.25, 2.26: specifica delle preferenze del trigger per la creazione dell’Applet “If any new photo by me (Instagram), then upload from my gmail account”. In fig. 2.24 la selezione del pulsante “Any photo by me”; nelle figure 2.25 e 2.26 rispettivamente la sintesi dell’applet creata e la pagina “My Applets” dove vengono elencate tutte le applet create o scaricate.
2.9 Zapier
Un altro tool in grado di automatizzare operazioni eseguibili sui servizi web è Zapier, uno strumento di cloud che consente di accedere a più di 1000 applicazioni [20].
Le regole su Zapier vengono chiamate “Zap” e contengono un solo trigger e un numero variabile di azioni.
Il piano gratuito permette di creare cinque Zap per un massimo di 100 azioni mentre quelli a pagamento, piuttosto costosi, vanno da un minimo di 20$ a un massimo di 125$ mensili per avere più Zap e opzioni a disposizione.
L’interfaccia di Zapier è piuttosto intuitiva: la creazione dello Zap avviene al centro dello schermo mentre nella parte sinistra una timeline verticale indica cosa è stato impostato e il tipo di informazioni che verranno richieste successivamente (fig. 2.27). Dopo aver selezionato un trigger e una o più azioni in ordine indipendente (fig. 2.28) è possibile impostare dei filtri, ovvero condizioni che vincolano in qualche modo l’esecuzione della regola, basati sia su stati di altri servizi che su attributi
26
preimpostati del sistema. I filtri aggiunti possono essere collegati dagli operatori logici AND e OR (fig. 2.29).
Con Zapier i servizi web disponibili in fase di creazione della regola dipendono dalla connessione dei rispettivi account, operazione che l’utente deve svolgere preventivamente, a differenza di IFTTT dove invece l’attivazione viene eseguita durante il processo di realizzazione.
Zapier si configura come un servizio largamente utilizzato soprattutto per automatizzare operazioni in ambito lavorativo, dove il risparmio di tempo nell’esecuzione rapida di attività quotidiane giustifica il prezzo che l’utente è disposto a pagare.
Figura 2.27: creazione della Zap “Quando manca un giorno a un impegno segnato su Calendar, avvisami tramite mail”. A destra la scelta dell’app su cui si basa il trigger; a sinistra la timeline che indica i successivi passi da compiere perché il trigger sia impostato (“Event Start”, “Choose Account” e “Test”).
27
Figura 2.28: fase finale di creazione della Zap “Quando manca un giorno ad un impegno segnato su Calendar, avvisami tramite mail”. La Zap può essere nominata e/o attivata. La timeline a sinistra indica la possibilità di estendere il trigger precedentemente impostato, comprimere la porzione “Action” e inserire un filtro, cliccando sull’icona del + presente tra le due sezioni.
Figura 2.29: aggiunta di un filtro basata su opzioni fornite dal sistema. Cliccando su “+OR” viene aggiunto un filtro usando quell’operatore logico, anziché quello di partenza (AND).
2.10 Droid Automation
Con l’aggiornamento più recente datato 12 gennaio 2019, anche l’app Droid Automation trova il suo posto nel Play Store di Google con la versione gratuita di base e quella Pro al costo di 2,99€ [8].
28
Su Droid Automation una regola viene definita “Profilo”. A differenza delle altre applicazioni l’interfaccia di Droid Automation non usa nessun colore per differenziare i domini degli eventi e delle azioni; il bianco e il nero sono infatti gli unici colori presenti (fatta eccezione per la riga di selezione gialla che indica semplicemente la selezione di un determinato tab visibile in fig. 2.32).
Per creare un Profilo occorre premere l’icona del “+” posta nella parte superiore destra della prima schermata. L’operazione che viene immediatamente richiesta è l’inserimento di un nome che rappresenti il Profilo che si sta creando. Dopodiché l’utente può navigare liberamente tra i tab “Inneschi” (gli eventi che fanno scattare il Profilo), “Tasks” (azioni da eseguire) e “Opzioni” (figg. 2.30-2.32).
Gli elementi del tab “Inneschi” sono visualizzati in elenco e identificati da icone nere racchiuse in forme quadrate dello stesso colore. Gli elementi sono inoltre dotati di un breve testo che ne descrive il funzionamento. Una volta impostato l’innesco prescelto, questo si posiziona nell’omonimo tab, da cui è possibile aggiungere altri inneschi oppure modificare o cancellare quello appena impostato (figg. 2.33-2.35).
Figure 2.30, 2.31, 2.32: creazione di un Profilo. Cliccando sull’icona del + nella parte alta della schermata “Miei profili” si passa all’inserimento del nome del Profilo (“batteria”) e successivamente alla navigazione libera tra i tab “Inneschi”, “Task” e” Opzioni”.
29
Figure 2.33, 2.34, 2.35: impostazione dell’innesco “Livello batteria” nel Profilo “batteria” creato. Gli elementi del tab “Inneschi” sono presentati in elenco e identificati dalle rispettive icone inserite in forme quadrate e da una breve spiegazione del funzionamento. Gli elementi che possiedono ulteriori impostazioni da settare presentano l’icona della freccia. L’innesco impostato si posiziona nel tab “Inneschi”, sotto l’icona di una freccia accompagnata dalla frase “Avvia il tuo profilo quando QUALSIASI commutazione avviene”. Dal tab “Inneschi” è possibile aggiungerne degli altri, oppure eliminare o modificare quello appena impostato.
La selezione di un Task avviene all’interno dell’omonimo tab in modo analogo agli Inneschi; le differenze sostanziali sono il cambiamento delle icone (non più racchiuse in cornici quadrate di colore nero) e la presenza di vere e proprie categorie in elenco (es. “Rete”, “Suoni e Musica”, “Schermo”, “Configurazione”,” Applicazioni”, “Telefono” ecc.) che contengono al loro interno numerosi elementi in lista.
Il Task impostato si posiziona nel tab omonimo da dove è possibile ancora una volta eliminarlo, modificarne gli attributi o aggiungerne un altro (figg. 2.36-2.39).
Premendo il pulsante della freccia nella parte superiore sinistra di figura 38, il Profilo impostato compare nella pagina “Miei profili” identificato dall’icona dell’applicazione, dal nome e dal numero di trigger e task che contiene. Dal tab Opzioni è possibile agire sul Profilo creato, eliminandolo, rinominandolo, abilitandolo ecc. (figg. 2.39, 2.40).
Da sottolineare che il salvataggio di un Profilo può avvenire anche qualora non sia stato selezionato alcun innesco o task. In questo caso il profilo non si attiverebbe ma comparirebbe comunque nella lista dei profili creati riportando la cifra 0 in corrispondenza degli attributi mancanti.
30
Figure 2.36, 2.37, 2.38: impostazione del Task che riguarda la “Luminosità”. La categoria Task “Schermo” contiene l’elemento “Luminosità” che, una volta impostato al 55%, si posiziona nel tab “Tasks”.
Figure 2.39, 2.40: visualizzazione del Profilo “batteria” creato e del tab “Opzioni”. Il Profilo “batteria” si colloca all’interno della pagina “Miei profili” e viene identificato dall’icona di Droid Automation e dal numero di trigger e task che contiene. Il tab “Opzioni” consente di abilitare o disabilitare il Profilo, rinominarlo, eliminarlo, esportarlo o eseguirlo.
2.11 Trigger
Un’altra app di recente aggiornamento (18 febbraio 2019) disponibile sul Play Store è Trigger [19] che consente la creazione di regole chiamate “Attività”. La versione gratuita contiene un limitato numero di funzionalità rispetto a quella Pro che sblocca trigger primari come quelli basati sul livello della batteria, l’orario, la posizione, gli auricolari ecc.
2.36 2.37 2.38
31
Premendo il pulsante “Crea un’attività” l’utente deve anzitutto scegliere il trigger desiderato. Non è possibile quindi eseguire l’aggiunta di eventi e azioni in ordine arbitrario. Le schermate trigger sono identificate dal colore verde dell’header e contengono elementi identificati da icone e spiegazioni del loro funzionamento. Gli unici trigger disponibili della versione gratuita riguardano le connessioni Wifi, Bluetooth e gli NFC. Impostato un trigger, premendo il pulsante “Successivo” posto nella parte inferiore destra della pagina di configurazione, è possibile proseguire nella creazione dell’Attività (figg. 2.40-2.42).
Trigger consente di specificare immediatamente le restrizioni in base alle quali far scattare l’Attività. Oltre ai trigger impostati anche le restrizioni ad esso collegate dovranno essere soddisfatte perché la regola possa essere eseguita. Le schermate delle restrizioni hanno lo stesso colore dei trigger (verde) e possono riguardare l’intervallo orario, il giorno, le connessioni Wifi e Bluetooth, il tipo e lo stato dell’alimentazione e la modalità aereo. Le restrizioni selezionate sono connesse al trigger scelto precedentemente e si posizionano sotto di esso precedute dalla congiunzione “E” (figg. 2.43, 2.44). La possibilità di aggiungere delle restrizioni viene data anche a posteriori qualora si voglia modificare l’Attività impostata.
Figure 2.40, 2.41, 2.42: selezione e impostazione del trigger “Wifi” per la creazione di un’Attività. Le schermate relative agli elementi trigger e all’impostazione delle loro funzionalità sono identificate dal colore verde. Il pulsante “Successivo” posto nella parte inferiore destra della pagina di specifica delle preferenze consente di procedere nella creazione dell’Attività.
2.40 2.41
32
Se si aggiunge un altro trigger, questo viene sempre collegato al precedente dalla congiunzione disgiuntiva “Oppure” che corrisponde all’operatore logico OR. In questo caso l’Attività verrà perciò eseguita quando almeno uno dei trigger impostati (e le sue eventuali restrizioni) risulterà soddisfatto.
Proseguendo nel processo di creazione attraverso il pulsante “Successivo” di figura 2.44 si è reindirizzati nell’elenco delle categorie “Azione”, identificate da icone poste stavolta sulla destra e le cui schermate presentano l’header di color arancio. Ogni categoria “Azione” può essere aperta per permettere tramite check box la selezione di uno o più elementi in essa contenuti.
Figure 2.43, 2.44: aggiunta delle restrizioni “Ora” e “Giorni”. Le restrizioni impostate si collocano sotto il trigger a cui sono collegate precedute dalla congiunzione “E”. Ancora una volta il pulsante “Successivo” consente di proseguire nella creazione dell’Attività.
Interessante notare non solo la possibilità di selezionare più elementi all’interno delle stessa categoria, ma anche di aprire simultaneamente più categorie per selezionare qualsiasi elemento, ovunque esso si trovi.
La configurazione di tutti gli elementi selezionati tramite check box (appartenenti o meno alla stessa categoria) avviene nella successiva schermata di configurazione dove sono presentate in elenco tutte le funzionalità esprimibili sugli elementi selezionati. Premendo il pulsante “Aggiungi all’Attività” si prosegue nel salvataggio della stessa (figg.
2.43
33
2.47). La fig. 2.48 mostra che la digitazione del nome dell’Attività creata avviene nella schermata dove si collocano le azioni appena impostate e da dove è possibile aggiungerne di nuove. Dando conferma, l’Attività così nominata compare nella pagina “Le mie attività” accompagnata dall’icona del trigger scelto e dall’azione selezionata (figg. 2.48, 2.49).
Figure 2.45, 2.46, 2.47: configurazione dell’Azione del testo di notifica “Connesso a Wifi”. Aprendo ogni categoria, tramite check box si selezionano gli elementi azione che si desidera impostare, che possono appartenere anche a categorie differenti. Una successiva finestra di configurazione permette di settare una ad una le funzionalità degli elementi selezionati e di aggiungerle all’Attività premendo l’omonimo pulsante.
Figure 2.48, 2.49: salvataggio dell’Attività “sveglia con messaggio Wifi” e visualizzazione dell’Attività creata. Il nome dell’Attività viene richiesto in fondo alla schermata dove viene posizionata l’azione appena impostata. Premendo il pulsante “Fatto” si viene reindirizzati alla pagina “Le mie attività” dove compare la regola creata identificata dal nome, dall’icona del trigger scelto e dall’azione impostata. Da qui è possibile disattivarla, modificarla, eliminarla, eseguirla o crearne una nuova.
2.45 2.46 2.47
34
Abbiamo visto piattaforme e applicazioni web e mobili che realizzano sistemi di automazione utilizzati per scopi differenti; dal campo medico, all’ambiente domestico, dallo smartphone alla gestione dei servizi web e social.
Qualunque sia il campo di riferimento, la possibilità di personalizzazione di un sistema si lega a filo doppio con la sua semplicità di utilizzo poiché esso deve poter essere fruito da una pluralità di utenti con differenti background tecnici e culturali. Ciò comporta la costruzione di interfacce il più possibile familiari ed intuitive; principi ancora più importanti all’interno dell’ambiente mobile caratterizzato da numerosissime app che svolgono le medesime funzioni.
Le applicazioni mobili dipendenti dal contesto mostrate nel capitolo danno prova di come sia variegato l’universo di questo genere di applicazioni: ognuna possiede caratteristiche proprie e capacità di adattamento a diversi livelli. Alcune applicano i principi della programmazione per dimostrazione utilizzando sistemi in grado di inferire le regole di personalizzazione di cui l’utente necessita, altre invece permettono agli utilizzatori di crearle manualmente. Ognuna di loro si riferisce alle regole adottando una diversa terminologia (“Profilo”, “Situazione”, “Applet”, “Trigger” e così via); usa processi di creazione propri, liberi o guidati; si configura per il controllo degli ambienti, dei dispositivi mobili o degli account web; ammette un differente grado di complessità attraverso l’impiego di operatori logici e l’aggiunta di condizioni.
Ciò che quasi tutte hanno in comune è la navigazione degli insieme evento e azione sotto forma di tab; l’ordinamento in elenco di categorie ed elementi; l’utilizzo di icone rappresentative; l’inclusione delle funzionalità più comunemente utilizzate dagli utenti (connessione, posizione, orario, alimentazione, notifiche ecc.) e una descrizione testuale della regola creata.
35
CAPITOLO 3
LE APP ANALIZZATE
Atooma, Locale e Tasker sono le tre app per sistemi Android sensibili al contesto su cui è stato eseguito il test utente. Come già detto, esse richiedono che l’utente rintracci, selezioni e imposti arbitrariamente, gli eventi e le azioni che costruiranno la propria regola
Poiché ogni app è stata sottoposta a continue modifiche e aggiornamenti, è opportuno specificare il numero di versione su cui il test è stato condotto:
. Atooma versione 1.2.6 . Locale versione 5.0 . Tasker versione 4.2
Per avere una prima idea di come fossero strutturate, nei paragrafi seguenti riportiamo i passi necessari per lo sviluppo della regola:
Quando una connessione wi-fi è attiva (evento) mostrami una notifica (azione)
3.1 Atooma
Atooma nasce dal lavoro di una giovane startup composta da quattro ragazzi italiani. La sua apparizione risale al settembre del 2012, quando l’applicazione diviene disponibile sull’Android Market e può essere scaricata gratuitamente. Durante il World Mobile Congress del 2014, Atooma si è fatta notare nella competizione del Mobile Premier Award, ottenendo il primo posto tra più di mille applicazioni concorrenti.
36
Atooma rappresenta il modello evento/azione recuperando dal mondo dell’informatica i concetti di “If…Do…” (“Se… Fai…”) e usa la forma del cerchio per rappresentare e disporre categorie ed elementi.
Il processo di creazione di una regola (definita con il termine “Atooma”) si sviluppa sequenzialmente partendo dalla definizione degli eventi:
Figure 3.1 -3.4: procedura per la selezione e l’impostazione dell’evento “Wifi on” con Atooma.
Le figure 3.1-3.4 presentano la fase di creazione della condizione riguardante una connessione wi-fi attiva. Lo stato “On” dell’elemento “Wifi” non prevede la possibilità di impostare ulteriori preferenze ma, come mostra la figura 3.8, per alcune tipologie di condizioni (e azioni), la scelta di uno stato è seguita dalla specifica di parametri aggiuntivi.
È importante specificare che un’applicazione creata con Atooma può possedere al massimo 5 eventi.
Le figure 3.5-3.8 mostrano la fase di creazione della notifica da visualizzare in corrispondenza dell’evento impostato precedentemente. Anche in questo caso va specificato che Atooma vincola l’utente a impostare un numero di azioni eseguibili all’interno della stessa regola non superiore a 5 (come avviene per gli eventi).
La schermata iniziale di Atooma comprende anche i tab “Bacheca” e “Profilo” (figura 3.11), da cui è possibile rispettivamente scaricare le
37
Atooma create e condivise da altri utenti e avere informazioni sul proprio profilo (indirizzo email, versione dell’applicazione in uso ecc.).
Figure 3.5-3.8: procedura per la selezione e l’impostazione dell’azione “Notifica” con Atooma.
Figure 3.9-3.11: salvataggio e visualizzazione dell’Atooma “Wifi notification” creata.
3.5 3.6 3.7 3.8
38
3.2 Locale
Al contrario di Atooma, Locale, rilasciata nel 2008, non è un’applicazione gratuita ma può essere acquistata alla cifra di 7 euro e 99 centesimi. In Locale ogni regola prende il nome di “Situazione”.
La principale caratteristica di Locale è l’estendibilità: l’applicazione infatti possiede un limitato numero di elementi integrati ma consente di estendere le sue funzionalità attraverso l’utilizzo di oltre 400 plugin scaricabili dal sito dell’Android Market (gratuitamente o a pagamento).
Il processo di creazione di una Situazione non è sequenziale:l’utente può decidere arbitrariamente l’ordine di selezione degli attributi poiché l’interfaccia dell’applicazione è progettata in maniera tale da mostrare contemporaneamente (cioè nella stessa schermata) i pulsanti per l’aggiunta di eventi e azioni (all’interno dell’app queste ultime vengono chiamate “Impostazioni”).
Le figure 3.12-3.15 mostrano la procedura per impostare l’evento riguardante una connessione wifi attiva.
Con Locale non esiste una quantità massima di condizioni da includere all’interno di una Situazione, ma va ricordato che più è elevato il numero di condizioni, più è probabile che quella Situazione non si attivi mai.
Una funzionalità molto interessante in Locale è la possibilità di selezionare più volte lo stesso elemento condizionale. Condizioni multiple dello stesso tipo (cioè impostate sullo stesso elemento) vengono trattate come OR. Avremmo ad esempio potuto aggiungere una seconda
condizione utilizzando l’elemento “Wifi”,ma impostandone lo stato su“Not Connected” (figura 3.14). In questo modo la nostra situazione verrebbe eseguita in presenza di una connessione wifi attiva o disattivata.
L’aggiunta dell’impostazione (che nel nostro esempio è rappresentata dall’azione Notifica), segue lo stesso procedimento esposto nelle figure precedenti: partendo dal pulsante “Aggiungi Impostazioni” si rintraccia nell’elenco l’elemento di interesse; si inseriscono titolo e testo
39
della notifica da visualizzare e, infine, l’azione così impostata, compare nella schermata principale (figura 3.16).
La figura 3.17 evidenzia un altro interessante aspetto di Locale: la possibilità di specificare delle “Impostazioni predefinite”, ovvero azioni da eseguire quando nessuna delle Situazionicreate è in esecuzione.
Figure 3.16, 3.17: visualizzazione della notifica impostata e della Situazione “Wifi notification” creata con Locale. Nella pagina “Situazioni” vi è la possibilità di settare le Impostazioni Predefinite da eseguire quando nessuna delle Situazioni create è attiva.
Figure 3.12-3.15: procedura per la selezione e l’impostazione dell’elemento “Wifi Connection” con Locale.
3.12 3.13 3.14 3.15
40
3.3 Tasker
Tasker deriva dall’evoluzione di un’applicazione pensata per personalizzare le funzionalità dei palmari Palm OS disponibile dal 2007 e conosciuta col nome di APT.
Lo sviluppo di Tasker, iniziato nel 2009, è partito quindi dall’idea di estendere le funzionalità di APT e renderle compatibili con i dispositivi Android. Alla fine dello stesso anno Tasker si è aggiudicato il terzo posto nella Android Developer Challenge 2. È disponibile sul Play Store di Google al costo di 2.99 euro.
In Tasker ogni regola è identificata con il termine “Profilo”. Un profilo Tasker può contenere un totale di 4 eventi. La creazione di un Profilo avviene attraverso un processo semi-sequenziale (dopo la selezione di un evento si è obbligati a selezionare un task azione; l’aggiunta di ulteriori eventi può essere svolta solo successivamente) che può partire indiscriminatamente dalla definizione degli eventi o da quella delle azioni.
Nell’esempio mostrato di seguito assumiamo che il processo inizi dalla definizione dell’elemento evento.
Figure 3.18-3.21: procedura per l’impostazione dello stato “Wifi Connected” con Tasker.
41
Un particolare aspetto di Tasker è che la conferma di ogni operazione va data utilizzando il tasto freccia indietro posizionato nella barra di navigazione del dispositivo.
La figura 3.18 mostra poi una differenza sostanziale rispetto ad Atooma e Locale: la differenziazione degli elementi evento in quelli che vengono chiamati “Contesti” (“Application”, “Day”, “Event”, “Location”, “State”, e “Time”).
Prima di terminare l’esempio è necessario specificare che Tasker possiede una serie di funzionalità più adatte ad utenti esperti che ne amplificano nettamente le potenzialità espressive. Pur non essendo mostrato in figura, la finestra delle preferenze (figura 3.21) contiene la casella “Invert” che, se selezionata, consente di invertire lo stato di un elemento. Nel nostro esempio, selezionando la casella Invert avremmo impostato una condizione basata su una connessione wifi non attiva.
Le sequenze di figure riportate di seguito (figure 3.22-3.29) mostrando in che modo Tasker consente di impostare l’azione corrispondente ad una notifica da visualizzare:
Figure 3.22-3.25: procedura per la selezione della categoria azione “Alert” che contiene l’elemento “Notifica” con Tasker.
Abbiamo visto in che modo sia possibile creare la stessa regola (“Quando una connessione wi-fi è attiva, mostrami una notifica”) utilizzando le versioni delle app su cui è stato eseguito il test utente.
42
Figure 3.26-3.29: procedura per l’impostazione della notifica “Connected to Wifi” e visualizzazione del profilo “Wifi Connected” creato con Tasker.
Nel corso del tempo Atooma, Locale e Tasker hanno subito aggiornamenti di vario tipo correggendo alcune loro caratteristiche. Nel capitolo 6 si analizza l’evoluzione apportata dalle modifiche cui sono state sottoposte, alcune delle quali in linea con i risultati ottenuti dallo studio di usabilità esposto nel capitolo successivo.
43
CAPITOLO 4
TEST DI USABILITÀ
Le applicazioni mobili dipendenti dal contesto sono nate in risposta alla crescente necessità di adattamento, offrendo all’utente la possibilità di personalizzare il comportamento del proprio dispositivo in relazione al verificarsi di determinate circostanze.
Il test ha riguardato l’analisi dell’usabilità delle applicazioni Android Atooma, Locale e Tasker mostrate nel capitolo 3.
Le tre app analizzate permettono di specificare degli eventi al verificarsi dei quali lo smartphone avvia l’esecuzione automatica di determinate azioni (ad esempio: “Se ricevo una chiamata, dalle ore 8 alle 10 del lunedì, rispondi a quel numero con il messaggio “sono in riunione”.) Utilizzando una di queste applicazioni l’utente può quindi creare regole di automazione personalizzate sulla base delle proprie necessità quotidiane, selezionando semplicemente gli eventi e le azioni di cui sono composte. Le tre applicazioni sono perciò per natura sensibili a eventi e cambiamenti di stato che riguardano il dispositivo e che avvengono al suo interno. Grazie all’integrazione sempre più estesa di varie tipologie di sensori esse sono in grado di monitorare anche trasformazioni che si verificano nell’ambiente esterno (temperatura, umidità, campi elettromagnetici ecc.). Inoltre alcune di queste applicazioni dipendenti dal contesto consentono l’accesso agli account di vari servizi web (Facebook, Twitter, Instagram ecc.), caratteristica che permette di esprimere condizioni e azioni relative a situazioni che accadono al loro interno (come ad esempio la regola “quando pubblico una foto su Instagram, salvala su Dropbox”).
Il test si è prefisso l’obbiettivo di esaminare la corrispondenza tra le metafore usate dalle tre interfacce e il sistema mentale dell’utilizzatore. L’analisi si è svolta in 3 fasi distinte:
44
la valutazione della loro dell’usabilità tramite test utente;
la definizione dello schema interno del successivo mockup tramite card sorting.
Di seguito è descritta più nel dettaglio la metodologia di esecuzione di ognuna delle tre fasi di analisi.
4.1 Espressività
Per poter eseguire una differenziazione più profonda tra Atooma, Locale e Tasker è stato in primo luogo effettuato un calcolo della loro espressività. Le versioni delle app sottoposte al calcolo sono rispettivamente la 1.2.6; la 5.0 e la 4.2, esposte nel capitolo 3.
Nel nostro contesto il termine espressività si riferisce sostanzialmente al numero di funzionalità posseduto da un’app. Tale valore definisce il grado di adattabilità di ognuna rispetto alle altre in termini di possibilità espressive, ovvero di ricchezza di funzioni esprimibili dall’utente.
Abbiamo deciso di misurare questo dato per scoprire al termine del test utente, se esistesse o meno una qualche relazione tra il numero di funzionalità di un’app e la sua usabilità.
La natura delle applicazioni considerate consente di distinguere il dominio più generale dell’espressività in due sottoinsiemi distinti: l’espressività degli eventi e quella delle azioni. L’espressività totale di un’applicazione sarà perciò data dalla formula:
ExpTot = ExpEventi + ExpAzioni
dove ExpEventi e ExpAzioni rappresentano rispettivamente l’espressività totale degli eventi e delle azioni, calcolate sommando le diverse funzionalità riferite a quel particolare sottoinsieme.
Poiché tra le altre cose le app analizzate differiscono per l’organizzazione interna degli elementi, la loro etichettatura e la sintassi di
45
definizione delle funzioni, prima di procedere al calcolo dell’espressività è stato necessario sviluppare una categorizzazione univoca che fosse in grado di equiparare funzionalità identiche nelle tre applicazioni, anche se espresse differentemente o collocate diversamente. Utilizzando lo stesso criterio di categorizzazione per gli elementi di eventi e azioni si è ottenuta una classificazione per rendere comparabili le tre applicazioni (diagrammi 4.1 e 4.2).
Diagrammi 4.1 e 4.2: gerarchie create per equiparare gli elementi di tipo evento e azione delle tre applicazioni in esame.
Si sono quindi esplorate le applicazioni alla ricerca di elementi e funzionalità che rientrassero nelle categorie definite dalle gerarchie sopra riportate. Un esempio è visibile nella tabella 4.3 che riporta un estratto del conteggio degli eventi. Per stabilire il numero e la natura delle funzionalità presenti o mancanti, sono state riportate sulla stessa riga le funzioni comuni alle tre app, sebbene identificate da un linguaggio diverso o collocate in maniera differente.
