3.2 Scelte di programmazione
3.2.3 Definizione dei concetti e design
Una volta deciso cosa realizzare è stato valutato se costruire l’interfaccia grafica da zero, utilizzando librerie generiche per il drag-and-drop o per la costruzione di diagrammi, oppure se usare una libreria che permetta l’uso di blocchi per strutturare linguaggi. E’ stato deciso di usare la libreria Blockly perché presentava funzionalità utili per il progetto. Queste sono un 38 sistema di drag-and-drop e collegamento dei blocchi, possibilità di generazione di codice personalizzato a partire dall’area di lavoro, possibilità di modificare i blocchi e crearne di nuovi, possibilità di ricompilare la libreria per definire comportamenti specifici. E’ stata usata per svariati progetti relativi al mondo TAP e IoT come Smart Block, Domoticz, PICAXE, oltre ad essere la libreria alla base degli ambienti di programmazione Scratch e App Inventor.
La progettazione è continuata con la scelta dei concetti da veicolare attraverso le rappresentazioni grafiche. E’ stato deciso di usare lo spazio della pagina in due dimensioni, per usare lo sviluppo sia in verticale che in orizzontale per veicolare informazioni.
Il flusso logico principale dell’applicazione è dall’alto in basso. Ciò è collegato alla sequenzialità, sia nel all’attivazione dei trigger che nello svolgimento delle azioni. I trigger e le azioni vengono impilati uno sull’altro, collegati da eventuali operatori. Lo spazio in orizzontale viene usato per la descrizione di un trigger. Viene inoltre utilizzato per rappresentare una ramificazione del flusso. E’ possibile definire azioni parallele, che iniziano nello stesso momento. Graficamente il flusso normale di esecuzione si divide in due (o più) rami, resi con colonne di blocchi di tipo azione affiancati.
L’idea di utilizzare il flusso della pagina è già stata usata insieme alla metafora del puzzle in [7]. In [16] viene evidenziato come questo flusso sia da considerare anche nella definizione
38 "Blockly | Google Developers." https://developers.google.com/blockly. Ultimo accesso: 1
del singolo blocco, basandosi sul tipo di lingua (right to left oppure left to right) di riferimento degli utilizzatori.
Successivamente è stato definito il concetto di inclusione o raggruppamento. Serve a evidenziare il rapporto tra elementi concettualmente separati ma che fanno parte di una struttura più grande. Esempi di questo concetto sono gli stessi trigger e azioni, entrambi facenti parte di una regola, oppure trigger diversi raggruppati logicamente tramite un blocco che ha la funzione di parentesi. Questo concetto è stato rappresentato tramite un blocco contenitore che delimita al proprio interno i concetti da raggruppare.
Un altro concetto incluso è stato quello di modificatore, qualcosa di accessorio che si applica ad altri trigger o azioni per cambiarne il senso o renderlo più specifico, come la negazione oppure la specifica di una data per la negazione. E’ stato deciso, data la natura opzionale di questi concetti, di renderli visibili tramite un’azione dell’utente, ad esempio il selezionare una checkbox, e dopo aggiungere la possibilità di inserire i blocchi rappresentanti concetti accessori.
Successivamente è stato definito come rendere graficamente i blocchi relativi a trigger e azioni. Sono mostrati gli elementi temporali: la distinzione tra eventi e condizioni per i trigger, e tra immediato, continuativo e sostenuto per le azioni. Per i trigger è stato scelto di mostrare, alla creazione, una finestra modale con le due possibili scelte, insieme ad un’icona rappresentativa con associata una descrizione. Questo perché dalle esperienze precedenti è stato visto che gli utenti tendono a soprassedere sulla scelta tra evento e condizioni, scegliendo l’uno o l’altro senza porre troppa attenzione. In questo modo si è cercato di far pensare alla scelta che stava vendendo fatta, che porta anche all’inserimento nel blocco trigger di un altro blocco che ne rappresenta il tipo scelto. Esso viene agganciato tramite un collegamento di tipo puzzle e con una icona distintiva se si tratta di evento o condizione, utilizzando la raffigurazione grafica definita in [12].
Immagine 1: blocchi trigger di tipo evento e condizione.
Passando il puntatore sul blocco evento o condizione apparirà una tooltip descrittiva, contenenti informazioni simili a quelle date poco prima: in uno studio recente [4] l’uso di informazioni ripetute è stato confermato come utile a facilitare gli utenti nell’analisi dei problemi relativi a questo tipo di applicazioni. Passare il mouse sopra il blocco trigger ne mostrerà invece una breve descrizione.
Immagine 2: blocco di tipo azione.
Per le azioni è stata scelta una rappresentazione simile a quella dei trigger, ma senza rendere evidente come in questi ultimi la differenziazione temporale tra i tipi di azioni possibile (tipo immediato, continuativo o sostenuto, mostrate invece in una tooltip al soffermarsi del mouse su un blocco azione). Questo perché questa distinzione non è di per sé importante per l’utente finale, ma lo diventa in particolari condizioni.
Una volta definiti i concetti da veicolare e la struttura dei blocchi si è passati al design di questi ultimi. Per questo è stato usato il Blockly Developer Tool , uno strumento online 39 realizzato in Blockly che permette di definire dei blocchi personalizzati, e di convertirli in
39 "Blockly Developer Tools - Blockly Demo."
https://blockly-demo.appspot.com/static/demos/blockfactory/index.html. Ultimo accesso: 4 nov. 2019.
formato JSON o JavaScript per poterli usare nei progetti. Anche se non permette di definire comportamenti avanzati dei blocchi, questo tool si è dimostrato adatto in questa fase.
E’ stato considerato che alcuni problemi, come repeating-trigger e revert-state, sono collegati ad alcune combinazioni riguardo la temporalità di trigger e azioni. Il ripristino del device allo stato precedente ha senso solo in caso di azioni sostenute, mentre la ripetizione di un’azione può avvenire nel caso di azioni immediata o continuative. Inoltre, se la parte di trigger presenta almeno un evento, l’azione non è più soggetta ad essere ripetuta, e non c’è più l’incertezza sul ripristino o meno dello stato iniziale al termine della condizione.
Si è deciso di inserire nei blocchi azione una indicazione riguardante il ripristino dello stato precedente del device nel caso di trigger di tipo condizione e azioni sostenute. Questa situazione porti molti utenti a pensare che al diventare falso della condizione, l’azione sostenuta sarà ripristinata allo stato iniziale [23]. Per mostrare questa caratteristica si è scelta una rappresentazione iconica (due frecce in direzioni opposte) associata ad una descrizione del comportamento in una tooltip.
Immagine 3: blocco azione di tipo revert.
Visto che il comportamento repeating-trigger è stato individuato come non problematico [3], e visto che l’engine sottostante l’interfaccia si prende già carico di gestire questa situazione effettuando l’azione solo una volta, è stato deciso di non gestire la possibilità di ripetizioni. Inoltre non risulta particolarmente utile permettere che un’azione venga effettuata di continuo in un intervallo di tempo.
Per non aggiungere ulteriore carico cognitivo (visto che comunque si tratta per l’utente di usare un nuovo linguaggio) e limitare la possibile frustrazione [16], è stato limitato il numero di blocchi rappresentanti concetti e di possibili combinazioni tra loro, rimuovendo la possibilità di usare blocchi di tipo temporale da aggiungere ai blocchi di tipo negazione per specificare quando qualcosa non deve essere valido.
I blocchi rappresentanti trigger, azioni e i collegamenti logici tra loro si impilano l’uno sull’altro, mentre i blocchi “subordinati” (blocchi trigger rispetto al blocco regola o al blocco raggruppamento, blocchi evento e condizione rispetto al blocco trigger) si trovano contenuti nel blocchi “maggiori” dal punto di vista concettuale.
Immagine 4: esempio di comportamento complesso espresso tramite raggruppamento.
E’ stata posta attenzione alla coerenza interna all’interfaccia, come suggerito in [16]. Ciò è stato fatto tramite la ripetizione di pattern di forme, uso di colori significativo (divisione del blocco regola in due aree di diversa tinta associata ai colori di trigger e azioni, operatori di trigger e azioni con tinta simile ai blocchi di partenza ma meno satura), uso del solito ordine per gli input all’interno dei blocchi e usando una terminologia il più possibile simile per le descrizioni.
Immagine 5: esempio di regola completa.
3.2.4 Requisiti
All’inizio della fase di progettazione i requisiti dell’applicazione non erano ben definiti. I punti fermi riguardavano l’orientamento verso persone non esperte, il poter eventualmente cambiare contesto, l’uso di un linguaggio visivo per esplorare la possibilità di creare regole più espressive. Nel corso delle discussioni durante la fase di design i requisiti sono diventati più chiari. E’ emerso come, all’aumentare dell’espressività, sarebbe stato necessario aggiungere degli ulteriori strumenti di supporto per l’utente. I requisiti infine identificati sono stati i seguenti.
● Rendere l’ambiente flessibile, non legando strettamente l’interfaccia ad un caso di uso e permettendo di caricare da file esterno i contesti di trigger e azioni;
● Rendere possibile esprimere in modo efficace regole più complesse rispetto a quelle composte da un trigger e una azione;
● Utilizzare le due dimensioni della pagina ed ulteriori elementi grafici per veicolare concetti appropriati ad un sistema trigger-action;
● Mitigare gli errori principali dovuti ad una diversa mappatura mentale degli utenti rispetto alle effettive caratteristiche del sistema tramite design dei blocchi, segnali visivi e descrizioni testuali;
● Venire ulteriormente incontro alle possibili difficoltà degli utenti tramite un modo per suggerire i trigger e le azioni che possono essere di interesse nel corso della creazione della regola.