Scelta del contesto e del linguaggio visivo

E’ stato inizialmente deciso che questo editor di regole doveva essere flessibile per poter supportare eventuali cambi di contesto, ma orientato verso l’uso da parte di persone non esperte nell’ambito dell’assistenza agli anziani. Essi possono dover imparare ad usare questi programmi per supportare il proprio lavoro. La fase di apprendimento deve essere rapida ed efficace, per dare la confidenza necessaria all’uso. Per questo la creazione di una regola semplice deve essere lineare, con l’eventualità di poter creare regole più avanzate quando un utente raggiunge un buon livello di padronanza del sistema.

C’è inoltre la possibilità che lo stesso utilizzatore finale del sistema trigger-action (e non dell’editor di regole, quindi l’eventuale persona anziana) voglia poter provare a cimentarsi nella modifica o nella creazione di una regola.

Un altro punto a favore, dal punto di vista pratico, è stato il poter usare per questo progetto un contesto precedente già usato in ambiente sperimentale. Il contesto è suddiviso in tre dimensioni generali (utente, ambienti, tecnologia), suddivise a loro volta in una gerarchia di categorie “middle-level” e di attributi. Ad esempio, la dimensione utente include la categoria dati personali che ha come attributi età, genere e educazione, mentre la dimensione ambienti contiene la categoria cucina che ha come attributi tutti i sensori presenti in cucina. Sono presenti sotto-categorie, come nella categoria meteo-orari sono incluse le categorie data e orario, previsioni di oggi e previsioni per domani. Anche le azioni sono strutturate gerarchicamente in modo simile.

Visto che il contesto è relativo al progetto PETAL, incentrato sull’uso di sistemi di illuminazione per migliorare la qualità della vita delle persone anziane, la maggior parte delle azioni riguardano la gestione dell’illuminazione. E’ possibile gestire l’accensione, il cambiamento di colore per un periodo, o l’esecuzione di scene programmate (sequenze di illuminazione con durata e modalità specifiche: attivante, rilassante, bioritmica). E’ anche possibile inviare promemoria e messaggi di allarme, eventualmente ripetuti e su diversi canali (SMS, mail, notifica sul tablet). Una rappresentazione schematica del contesto è presente nella [Appendice D].

Con esso è stato usato un insieme di regole create dagli utenti durante il test di quel contesto. E’ stato così possibile avere un’idea di quali regole sarebbero state interessanti per gli utenti. L’insieme di regole è stato utilizzato come base di partenza da cui estrarre suggerimenti.

Per la rappresentazione delle regole è stato scelto un linguaggio visivo basato su blocchi per diverse ragioni. E’ possibile riassumere e contenere all’interno di un blocco informazioni collegate, come la definizione di un trigger con tutte le sue caratteristiche. Ciò permette di mettere in risalto l’aspetto compositivo della creazione di una regola. In un blocco è possibile inserire una sezione in linguaggio naturale, eventualmente affiancata da un’icona per rafforzare il significato espresso da quel blocco, e usare notazioni secondarie come i colori.

I linguaggi visuali basati su blocchi sono già stati usati per rappresentare la creazione di regole di personalizzazione, ad esempio in [4, 2]. Anche applicazioni relative al mondo IoT al di fuori della ricerca usano questa metafora, ad esempio domoticz , HABmin per31 openHAB , BlocklyDuino , PICAXE . In [24] l’uso di un linguaggio di questo tipo è stato32 33 34 definito dagli utenti come più facili e soddisfacenti per modellare task di robotica rispetto ad altri tipi di interfaccia. In SQL Blockly è stato invece usato per definire query SQL. 35

L’uso della programmazione visuale basata su blocchi associata alla metafora del puzzle è stata usata in [4]. In questo studio si è rivelata facile da capire e usare, permettendo a utenti non esperti di programmazione di comporre regole trigger-action senza problemi [4]. Nello stesso studio è emerso come feedback e spiegazioni siano utili per permettere agli utenti di capire i problemi che possono incorrere nella creazione di una regola, come le inconsistenze.

Questo ci fa capire l’importanza di affiancare questa metodologia con un sistema di supporto e guida, in particolare se vogliamo permettere più libertà espressiva nella creazione delle regole. Infatti è possibile vedere una interfaccia a blocchi come una via di mezzo, dal punto di vista dei possibili costrutti realizzabili, tra una guidata stile wizard e una di tipo flow.

I blocchi hanno una affordance caratteristica che invita alla “tinkerability”, un processo di apprendimento prevalentemente bottom-up. Ciò si riferisce al non avere un obiettivo preciso in partenza, da raggiungere tramite accurata pianificazione, ma il definirlo tramite sperimentazioni (come provando diversi pattern con i blocchi LEGO). In alternativa l’obiettivo può essere definito, ma può non esservi un piano preciso sul come raggiungerlo: ciò viene fatto tramite adattamenti e rinegoziazioni del piano a seconda delle interazioni che stanno avvenendo con i materiali e con le persone . Ciò evidenzia l’utilità di supportare 36 l’utente durante questo percorso.

31 _{"Blockly - Domoticz." 3 ago. 2019, ​https://www.domoticz.com/wiki/Blockly​. Ultimo accesso:}

1 nov. 2019.

32 _{"Graphical Rule Designer · openhab/org.openhab.ui ... - GitHub."}

https://github.com/openhab/org.openhab.ui.habmin/wiki/Graphical-Rule-Designer_​. Ultimo accesso: 1 nov. 2019.

33 _{"BlocklyDuino." ​https://blocklyduino.github.io/BlocklyDuino/blockly/apps/blocklyduino/​.}

Ultimo accesso: 1 nov. 2019.

34 _{"Blockly for PICAXE - Software - PICAXE."}

http://www.picaxe.com/Software/PICAXE/Blockly-for-PICAXE/_​. Ultimo accesso: 1 nov. 2019.

35_{​"SPE-Systemhaus/blockly-sql-app: SQL Blockly ... - GitHub."}

https://github.com/SPE-Systemhaus/blockly-sql-app_​. Ultimo accesso: 1 nov. 2019. 36 _{"5863P DESIGN MAKE PLAY-V/lb_Standard B 6x9."}

https://web.media.mit.edu/~mres/papers/designing-for-tinkerability.pdf_​. Ultimo accesso: 1 nov. 2019.