Valutare il ruolo della visualizzazione nella ... · la sua storia e il suo sviluppo come strumento adottato nei processi business. Nel secondo capitolo si analizza lo stato dell’arte

Valutare il ruolo della visualizzazione nella rappresentazione dei dati

Business Dashboard per l’ospitalità

Politecnico di MilanoFacoltà del Design

Corso di Laurea MagistraleDesign della Comunicazione

Laureando Gianluca RossiRelatore Paolo Ciuccarelli

A/A 2015/2016

I

Indice dei contenuti

Introduzione 3

1. Dall’ Armaturenbrett alla Business Dashboard 9

2. Verso una definizione tassonomica 29

1.1 La ricerca del senso come innovazione 11

2.1 Forme e funzioni 31

1.3 Dalle classi alle masse 19

2.3 User Inteface Dashboard 42

1.2 Cos’è una Business Dashboard? 15

2.2 Overview, drill down, detail 36

1.4 Architettura di una Dashboard 24

2.4 User Experience Dashboard 49 Tassonomia

II

3. Valutare una visualizzazione di dati 593.1 Introduzione al Performance testing 633.2 Introduzione alla Valutazione Euristica 69

4. Progettare una valutazione 994.1 Una dashboard per l’ospitalità 101

Descrizione Funzionale 102

Utenti 113Obbiettivi 119Contesto 121

3.3 Astrazione, Iconicità e ChurtJunk 75

4.3 Attività di valutazione 125

4.2 Verso una proposta metodologica 111

3.4 Oltre il tempo e l’errore 813.5 Oltre le metodologie 85

Process scenarios 87Valuation scenarios 92

III

4.4 Descrizione Progetto 1274.5 Protocollo di valutazione 133

IV

5. Risultati ottenuti 1445.1 Visual test report 149

Ringraziamenti Bibliografia 1655. Conclusioni 161

V

Introduzione

Questa tesi ha come scopo la creazione, lo sviluppo e la verifica di una metodologia di valutazione delle visualizzazioni di dati nel contesto operativo delle business dashboard. La domanda di ricerca da cui si sviluppa l’elaborato è formalizzata nella seguente frase:

COME SI VALUTA L’ EFFICACIA DELLE VISUALIZZAZIONI DI DATI NELLE BUSINESS DASHBOARD?

La risposta a tale quesito è il frutto di un percorso di ricerca teorica e sul campo che ha prodotto una prima proposta metodologica di valutazione. Il testo si articola esplicando nel primo capitolo la ricerca di una prima definizione della business dashboard, mediante la sua storia e il suo sviluppo come strumento adottato nei processi business. Nel secondo capitolo si analizza lo stato dell’arte delle business dashboard, ovvero viene descritta una proposta tassonomica utile per catalogare questo software al fine di una sua decostruzione nelle sue logiche di funzionamento e di interazione.Il terzo capitolo è dedicato all’introduzione del concetto di valutazione ed in particolare si concentra nella descrizione delle tecniche di valutazione maggiormente utilizzate nella valutazione di usabilità, nelle interfacce utente, negli artefatti digitali e nelle visualizzazioni di dati.Il quarto capitolo è dedicato alla descrizione del case study sviluppato dal laboratorio di ricerca Density Design del Politecnico di Milano e di come si siano articolate le fasi di valutazione e le scelte adottate.

Introduzione

3

Il quinto capitolo è dedicato alla analisi dei risultati progettuali ed alla loro comunicazione mediante dei visual report.

4

““

Protagora, in Platone, Teeteto, 152 a.C.

L’uomo è la misura di tutte le cosedi quelle che sono in quanto sono e

di quelle che non sono in quanto non sono

Milestone Sviluppo Business Dashboard

1950

1960

1930 1954

1970

Tableau de Bord Peter DruckeManagement by objectives

William H. InmonData WareHouse

General ElectricPerformance Management System

Robert AnthonyControl system based framework

1987

1992

2010

1980 2006

2000

1990

William H. InmonData WareHouse

Executive Information System Stephen FewBusiness Dashboard

Olap

Howard DresnerBusiness Intelligence

Robert AnthonyControl system based framework

Texas InstrumentsDecision Support System

Robert S. Kaplan - David NortonBalanced scorecard

Predictive Analitycs

Da circa un decennio il ruolo dei dati è entrato a far parte dei processi decisionali aziendali. Possiamo affermare che il progressivo interesse verso quella che viene definita come l’era dei “Big Data”1 abbia comportato nelle aziende pubbliche e private una crescente presa di coscienza del ruolo che tali dati possono avere nei processi di decision making. Lo sviluppo tecnologico ha permesso la creazioni di dataset in continuo aggiornamento che ha comportato a sua volta la creazione di enormi giacimenti di dati disponibili ad essere utilizzati: il dato è diventato con il tempo un nuovo materiale grezzo su cui è possibile lavorare per trasformarlo in informazione utile, leggibile, condivisibile ovvero un’informazione che rientri appieno nei processi di valore aziendali. Il termine “dashboard” in lingua inglese significa “cruscotto” ed è proprio dal cruscotto automobilistico sembra derivi per estensione la metafora del termine oggi applicato ai management cockpits.La parola “cruscotto” utilizzata nell’ambito automotive è derivata a sua volta per affissazione dallo stesso termine che definisce la paratia anteriore presente nelle carrozze trainate dai cavalli, installata per proteggere il cocchiere dal fango ed a cui si appendeva la crusca ed il mangime per gli equini. Dalla carrozza alle automobili e così via, ai primi aerei, i significati del lemma cruscotto definiscono sempre un elemento funzionale utile a “governare”, a prendere decisioni e che possa essere fruito facilmente e velocemente dall’uomo, inserito in un sistema complesso fatto di differenti organi in movimento. La metafora visiva dei cruscotti delle auto è da sempre

1. Dall’Armaturenbrett alla Business Dashboard

9

1 Jonathan Shaw, Why “Big Data” Is a Big Deal, 2016, www.harvardmagazine.com Accessed 10 May 2016;

10

termine di paragone, nella progettazione delle componenti grafiche dei cruscotti di monitoraggio dati, poiché il fruitore di tale tecnologia proprio come il conducente di un’autovettura si trova a monitorare costantemente le performance del mezzo in cui si trova: attraverso la lettura degli indicatori. Si potrebbe affermare che i valori costitutivi dei primi “quadri comando” sono stati e sono ancora oggi archetìpi nella progettazione dei software monitoraggio dati: i decisor maker ai vertici dei dipartimenti aziendali “conducono” le business units anche grazie alla consultazione delle performances visualizzate nelle dashboard. La progettazione visiva di questi prodotti, soprattutto nelle sue fasi iniziali, ha risentito della metafora automobilistica o meglio del cruscotto dell’automobile: tachimetri, contagiri, indicatori di vario genere sono stati tra gli elementi grafici maggiormente utilizzati per descrivere le performances. L’aumento della complessità informativa con il passaggio dalle componenti analogiche a quelle digitali, l’ibridazione tra le stesse mediante lo sviluppo hardware e software coaduviate da un pensiero di stampo positivista definito oggi come “internet of things”2 trainante nell’innovazione commerciale, ha portato un aumento della complessità informativa da dover essere gestita, ponendo in dubbio la reale utilità nella pratica, della metafora del cruscotto3.Per tali considerazioni, si potrebbe affermare che nell’immediato futuro della progettazione visiva degli strumenti di performance management, si dovrà tener conto non solo della facilità d’uso, ma anche della sempre crescente facoltà di giustapporre differenti dataset in cui gli

2 K.Ashton, That ‘Internet of Things’ Thing, 2009, www.rfidjournal.com Accessed 10 May 2016;3 Michele Mauri, Oltre la metafora del cruscotto - un modello per l’esplorazione visuale dei dati ba-sato sui flussi, 2009

In questo paragrafo si definisce una linea guida generica il cui compito è delineare lo sviluppo avuto negli ultimi vent’ anni dei software dedicati alla visualizzazione dei dati, cosiddetti della business intellicence. In particolar modo ci si focalizza su quei software in cui la visualizzazione di dati è una delle caratteristiche maggiormente sviluppate: dalla na-scita dei primi sistemi di data warehousing agli ultimi pro-dotti commerciali utilizzati nelle aziende di tipologia web based. Come descritto nel capitolo precedente i qua-dri comando, cruscotti automobilistici di vario genere, sono stati archetìpi nell’ausilio decisionale per un fruitore umano. Per fruitori si intendono in particolare quei decision makers che fin dai primi albori della B.I. sono stati utenti con carat-teristiche di managerialità, capitani d’azienda o ai vertici di catene produttive, con un particolare bisogno di prendere decisioni strategiche al fine di aumentare il valore del loro business. Fin dalla prima metà del 1970 negli Stati Uniti, vengono commercializzati i primi dischi magnetici per la memorizzazione dei dati, insieme nascono i primi software di gestione dei neonati database: definiti ancora oggi come database management system, acronimo “DBMS”4. Questi software vennero adottati per consentire l’accesso ai dati memorizzati e in qualche modo sfruttarli, essi possono essere letti come i precursori di quello che sarebbe stato definito qualche anno più tardi come “DSS” acronimo di Decision Support System5.Il DSS è un concetto che definisce una strategia, in cui un dato sistema software supporta le decisioni per una migliore comprensione e gestione delle risorse da parte di managers. In esso si possono riconoscere quattro valori

1.1 La ricerca del senso come fattore di innovazione

4 William H. Inmon, Building theData Warehouse, 20025 D. J. Power, A Brief History of Decision Support Systems, 2003, www. dssresources.comAccessed 09 May 2016

11

6 William H. Inmon, Datawarehousing & Datamining, 20027 W. B. Creps, D. E. O’Leary, Executive Information Systems, 1994, pag. 1.8 acr. Graphical User Interface

costituenti come la facilità d’uso rispetto ad un particolare tipo di utenza, un supporto interattivo di analisi, un sistema che fornisca supporto al processo decisionale e un sistema efficace nell’utilizzo di modelli nell’analisi dei dati. Come si è notato, i quattro valori sopra descritti rientrano appieno in quel campo dedicato ai modelli di business digitale relativo ad utenti con ruoli manageriali chiamato “Management Level System”6. L’importanza e la diffusione delle strategie DSS portarono agli inizi del 1980 i primi software di gestione dati basati sulla visualizzazione dei dati: SW disponibili per i di-riginenti “Executive” tali software vennero nominati con l’a-cronimo “EIS” appunto Executive Information System. Si riporta una prima definizione degli EIS:

“An executive information system (EIS) provides key information, gathered from both internal and external sources, to senior executives and managers. It accomplishes the multiple purposes of supporting decision making, communicating information, and providing awareness.”7

Nella citazione qui riportata vi si possono leggere quegli elementi che sono ancora attuali negli strumenti EIS, come lo sviluppo di una “GUI”8 fortemente orientata alla visualizzazione delle informazioni, comunicativamente facile da capire e che fornisca consapevolezza in chi la utilizza. L’innovazione di tali prodotti è da ricercare in quella che è stata la loro architettura, ancora oggi largamente utilizzata riconoscibile nei quattro componenti fondamenta-li: Hardware, Software, Interfaccia untente, Telecomunica-zioni.

12

Proprio nelle prime interfacce utente nasce l’idea della business dashboard così come si riconosce oggi:

“Executive information systems must be graphic-oriented and able to deliver a variety of graphicaldisplays. An EIS user will not only want to see the numbers, but also how the numbers look in a bar graph,pie chart, or line plot. This enhances the executives’ ability to spot trends and discrepancies andcommunicate their findings to colleagues, subordinates or external audiences”9

La principale differenza tra le due tipologie di infrastrutture tecnologiche, dalla parte dell’utente è da ricercarsi negli aspetti legati all’interazione della GUI: se entrambe offrono dei software che tendono ad un approccio interattivo-esplorativo sui dati, si deve riconoscere che solo nei sistemi EIS viene sviluppata un’interfaccia orientata alla visualizzazione del dato, in cui il tipo di output corrisponde ad ottenere informazioni grafiche al fine di valutare criticità o fattori di successo.Nel mondo accademico, si fa risalire alla fine della decade del 1980 il fallimento degli EIS, o meglio dire, un suo temporaneo abbandono verso uno sviluppo costante nel mercato MLS. Principalmente a causa degli alti costi di aggiornamento dati, tali software non riuscivano a portare abbastanza vantaggi nel loro impiego per giustificare un così importante investimento economico. Solo con l’ultima decade del secolo scorso, grazie anche ad un abbassamento dei costi degli hardware ed alla messa in pratica e sviluppo

9 W. Viehiand, Decision Support for Executives:Executive Information Systems, 1990, pag. 2

13

10 Si fa risalire la nascita del concetto del DW alla fine degli anni 1980, con l’invenzione da parte di ingegneri dell’ IBM del “business data warehouse”11 Sistema logico già teorizzato negli anni 1970 in cui i dati sono organizzati attorno ad una o più tabelle, la Fact Table raccoglie eventi omogenei caratterizzati da dimensioni e da attributi dipendenti12 Un’evoluzione dei DB relazionali fuorono i nuovi sistemi di stoccaggio dati come l’OLAP acronimo di On-line analytical Processing, essi furono adottati principalmente nell’estrazione dati ai fini di profilazione utente13 Thomas and Cook, 2005, www.infovis-wiki.net, Accessed 10 May 2016

del concetto del Data warehousing acronimo DW10 ovvero la creazione di una logica di storage dati, basata sulle fact tables11, che pone le basi per un nuovo e rinnovato interesse per i sistemi di decision making. Nasce in quegli anni anche il concetto di Data Mining cioè un insieme di analisi matematiche applicate a grandi insiemi di dati in ambito informatico utili a prendere decisioni strategiche. Semplificando il Data warehouse e il Data Mining genericamente rappresentano la nascita della Business Intelligence12. Alla fine di una ulteriore analisi nel campo di indagine della business intelligence, si sceglierà nei prossimi capitoli di indagare quel settore legato agli strumeti cosiddetti “visual analytics” rappresentanti di un insieme di strumenti tra cui la business dashboard.

“Visual analytics is the science of analytical reasoning facilitated by interactive visual interfaces” 13

Come si è descritto, seppur in modo volutamente semplificativo, la storia delle business dashboard è strettamente legata a sviluppi tecnologici, ma ancor prima concettuali, applicati al mondo dell’informatica e del business: le logiche di business si sono sempre riflesse negli strumenti informatici. Un’ altra carattarestica fondamentale, è da ritrovarsi in quel bisogno di cercare senso, dalla lettura del dato.Questo bisogno da parte dei decision makers ha condotto in ogni passaggio evolutivo della B.I. un ulteriore sviluppo

14

Questo capitolo vuole avere la funzione di descrivere mediante una comunicazione esemplificativa il prodotto dashboard proponendo una originale definizione di quello che oggi corrisponde al concetto di tale strumento: la descrizione delle sue componenti, dei suoi fruitori e del mercato di riferimento in cui questo artefatto viene utilizzato.Nel paragrafo precedente si è descritta in linea generale la storia dello sviluppo degli strumenti che hanno portato la nascita della dashboard. Nel turbinio di definizioni e di ruoli, è possibile che i confini tra uno strumento ed un altro non siano così chiari, ma anzi essendo strumenti dell’oggi utilizzati quotidianamente le definizioni spesso sono frutto di una pratica quotidiana del progettista che utilizza lemmi e terminologie al solo fine, seppur nobile, di farsi capire con i suoi interlocutori, siano essi colleghi o per l’aggiunta clienti.Per suddetto motivo si riportano in seguito una serie di definizioni e citazioni di ambito accademio, esempi di questa variazione di significati, oscillanti a seconda del settore di pertinenza. Stephen Few è tutt’oggi, uno dei maggiori studiosi del settore dell’Information and Communication Technology legato al mondo Business Dashboard. Egli vanta un’esperienza trentennale nel settore consulenziale ed i suoi testi rappresentano dei supporti validi nella ricerca di linee guida per la progettazione dei cockpits. Nel 2006 pubblica il libro “Information Dashboard Design” uno testo cardine nella progettazione delle interfacce nel mondo business. Da questo testo si riporta nella pagina a fianco una prima e fondamentale definizione:

1.2 Cos’è una Business Dashboard

15

“A dashboard is a visual display of the most important information needed to achieve one or more objectives; consolidated and arranged on a single screen so the information can be monitored at a glance”14

Questa citazione, prosegue nella metafora del cruscotto automobilistico: si potrebbe leggere di come l’autore definisca per dashboard di uno strumento in grado di visualizzare in una sola schermata informazioni più importanti, finalizzate ad uno o più obbiettivi. Tali condizioni sono condivisibili e presenti anche nei cruscotti automobilistici.Ci si trova di fronte ad una prima definzione nella quale si enuncia dell’importanza di visualizzare le informazioni più rilevanti rispondenti ad uno o più obbiettivi; Nel secondo periodo, la definizione è surclassata: allo stato attuale una dashboard di controllo dati è uno strumento che si è evoluto nell’ultima decade grazie a tecnologie web based e non proprietarie quindi in molti casi progettato in più dispositivi per l’accesso informativo, per questo motivo potremmo definire lo strumento come “responsive”15. Proseguendo nella ricerca di una definizione completa e condivisibile del cockpits, di seguito si riporta un’altra citazione, dell’autore Waine Eckerson anch’egli accademico e consulente ITC con esperienza pluridecennale. L’autore propone una descrizione della BD che enfatizza la natura articolata dell’artefatto, accentuandone la complessità e gli aspetti implicati all’ambito business.

14 S. Few, Information Dashboard Design - The effective visual communication of data, 2006, pag. 2515 Il termine viene ripreso dall’accezione “responsive” ripreso dalla programmazione web. Il designresponsivo nasce come risposta alla necessità di rendere gli artefatti webased facilmente accessibili con ogni tipo dispositivo e risoluzione video,

16

“Dashboards and scorecards are multilayered performance ma-nagement systems, built on a business intelligence and data in-tegration infrastructure, that enable organizations to measure, monitor, and manage business activity using both financial and non-financial measures” 16

Parafrasando la frase sopra riportata, anche per il teorizzato-re il fulcro dei cruscotti è dare ausilio ai decision makers nei processi decisionali. Proporremo un primo assunto o funzio-ne basilare della dashboard riconosciuta dagli EIS:

Una business dashboard è un software interattivo progettato per rendere agevoli dei processi decisionali

L’assunto è volutamente incompleto, in quanto risponde alla sola enunciazione della funzione principale, escludendo il “come” e “a chi” lo strumento permette la presa di de-cisioni. La frase sopra scritta potrebbe essere applicata ad altri prodotti presenti nel campo della business intelligence ma potrebbe avere riscontro pur nei software commerciali. Serve dunque un ulteriore dettaglio di analisi, per intendere quali sono gli elementi che contraddistinguono la BD.Una delle sue principali caratteristiche è da trovarsi nell’in-terfaccia utente, una GUI sviluppata tenendo conto di vi-sualizzazioni di dataset e di una loro navigazione. Le data visualizations sono parte fondamentale dell’aspetto di ri-conoscibilità17 del prodotto dashboard, in quanto essa si fa portatrice degli archetìpi visivi generati dai suoi precursori come i software denominati “Balance Scorecard” acronimo “BSC”18. I Balance Scorecard furono dei sw ideati nella metà

16 Wayne W. Eckerson Deploying Dashboards and Scorecards, 2006, pag. 6 17 M.Maiocchi, M.Pillan, Design e Comunicazione ,

17

degli anni 1990 in cui oltre a proseguire le visualizzazione dei dati come negli EIS, essi proponevano delle visualizzazioni maggiormente dettagliate anagrafiche di dati di particolare interesse, definiti come “Indicatori di Performance” dall’inglese “Key performance indicators” acronimo “KPY”.L’importanza di tali software, nella progettazione delle attuali dashboards, è da ricercare nella pratica della visualizzazione dei KPY mediante metafore visuali avanzate ed interattive19.Un altro fattore oggi ripreso nella progettazione che deriva dalle BSC è la determinazione del KPY mediante studi da parte del progettista direttamente sul fruitore del prodotto. A questo punto si propone una nuova e più completa definizione della dashboard:

Una business dashboard è un software interattivo in cui determinati dataset venogono visualizzati per rendere agevoli dei processi decisionali

Seppur non ancora definitiva, questa definizione vorrebbe tracciare dei confini all’interno dei prodotti digitali B.I., dividendo tra i SW dedicati alla visualizzazione ed esplorazione dei KPY e gli altri SW che non hanno queste caratteristiche.Nel prossimo capitolo, si propone una definizione delle BD, cercando di definire per chi è pensata ed in linea generale come definire gli obbiettivi dell’utenza del tool.

Vengono riportati alcuni esempi di interfaccie utente di sw BSC e metafore visive utilizzate nella visualizzazione dei dati.

TtgtmediaScorecard, www.datamanagement.com

Hierarchical Clustering Explorer 3.0, www.cs.umd.edu

18

1.3 Dalle classi alle masse

Nella ricerca di una definizione condivisa e attuale della business dashboard, in questo paragrafo si descrive l’argomentazione rivolta a rispondere ad una identificazione generica dell’utenza del tool.Nella metà degli anni 1930, in Francia si teorizza uno strumento di reportistica chiamato “Tableau de Bord”, esso doveva rispondere a neccessità di controllo di cicli produttivi, incentrandondosi maggiormente verso visualizzazioni relative alla produzione aziendale:

“Dès la fin du 19ème siècle, les dirigeants collectent l’information au travers d’un « rapport hebdomadaire » ou d’un « journal de marche ». Pour l’essentiel, cette information se présente sous une forme narrative. A partir des années 1920-1930, le tableau de bord, sans qu’il soit nommé d’ailleurs, apparaît de notre point de vue contemporain, comme le dispositif qui est espéré par les dirigeants. Ils clament alors leur besoin d’informations, de « statistiques » de ventes ou de production”19

Il bisogno di informazione di cui si parla nella citazione, è un bisogno ancora attuale che accomuna i dirigenti francesi di ottanta anni fa con gli attuali decision makers aziendali. Oggi la dashboard è adottata nelle più disparate aree merceologiche ad uso di molteplici figure interne: questo a causa di una migliore diversificazione della progettazione dei KPY in base al tipo di utente per cui è designato il tool.Si potrebbe affermare che il cruscotto così come gli altri strumenti di reportistica, dalla loro nascita, furono progettati per essere fruiti da persone con capacità gestionali, a causa di un diverso tasso di alfabettizzazione

19 Anne Pezet Les French tableau de bord, 2006, pag. 8

19

20 S. Few, Information Dashboard Design - The effective visual communication of data, 2006, pag. 34

e di organizzazione aziendale mentre a confronto, oggi gli strumenti di reportistica vengono adottati a tutti i livelli gerarchici interni alle aziende.Si riprende dal Few20, una prima proposta descrittiva di utenza rispetto al dominio dei tool utilizzati. Questa categorizzazione che per sua natura parziale, viene riportata ai soli fini di ricerca di categorie presunte d’utenza.L’autore diversifica i settori di utilizzo dei cockpits in base ad una generale organizzazione aziendale, identificando nove aree di competenza principali a cui corrispondono figure professionali derivate, sottoposte a queste categorie:

- Vendite- Marketing- Finanza- Supporto tecnico- Centri smistamento- Produzione- Risorse Umane- Information Technology- Web Services

Da questa prima categorizzazione si evince la parcellizzazione delle funzionalità differente per ogni tipologia di decision maker, ognuno di essi ha la facoltà di analizzare categorie di dimensioni che fa parte del proprio know how aziendale.La progettazione delle misure condivisibili al tipo di lavoro che il fruitore deve affrontare durante il suo ciclo produttivo giornaliero, sono da considerarsi come fattori

20

esclusivi che concorrono alla definizione di una particolare tipo di utenza: Il designer implicito o esplicito deve saper tradurre queste tipicità o forme di conoscenza dell’utenza in altrettanti sistemi informativi in linea con i needs trovati: questo tipo di processo rientra nell’approccio User Centerd Design.21 Vi sono in una prima analisi, un certo numero di aree di competenza riconoscibili all’utente che devono essere formalizzate prima della costruzione del progetto, in quella che viene descritta come la fase metaprogettuale.Oltre al contesto di riferimento, al fine di una buona progettazione, si deve tener conto di tutte quelle analisi che concorrono alla definizione delle “PERSONA”Il termine “Persona” identifica un insieme di documenti il cui scopo è descrivere degli archetìpi di utente coinvolte in un prodotto o servizio. Il progettista è parte integrante del processo di definizione: obbiettivi, motivazioni, background culturale, similitudini demografiche sono caratteristiche che concorrono alla definizione degli obbiettivi comunicativi di un prodotto.22 Le “analisi delle persona” teorizzate negli anni 1980 - 1990, nacquero dai cosiddetti “Profili Utente” utilizzati nei reparti di marketing e del design, con il compito di immaginare meglio le relazioni tra i bisogni identificati e i prodotti.Il termine “Persona” venne coniato per la prima volta nel 1983 da Alan Cooper durante lo sviluppo di software proprietari, poi coadiuvati in Microsoft.Rispetto ai profili utente le persona differiscono per un approccio di tipo etnografico basato su analisi raccolte “sul campo” piuttosto che attraverso ricerche di mercato.

21 Donald A. Norman, The Design of Everyday Things, 198822 Si riportano le metodologie maggiormente utilizzate:- Scenari;- Schizzi e Modelli;-Storyboard;- Analisi dei Compiti;- Flussi dei compiti;- Casi d’Uso;-Moodboards;- Wireframe;- Journey maps23 Dan Saffer, Designn dell’interazione.Creare applicazioni intelligenti e dispositivi ingegnosi con l’interaction design, 2007

21

24 Wayne W. Eckerson The Future of Business Intelligence, 2016, pag. 7

La raccolta dei requisiti per la definizione delle persona ha il compito di descrivere archetìpi ascrivibili a tre tipologie di bisogni:

- Obbiettivi Esperienziali: descrivono i bisogni dell’utenza durante l’uso del prodotto;

- Obbiettivi di vita: descrivono le aspirazioni lavorative dell’utente;

- Obbiettivi Finali: descrivono ciò che gli utenti hanno bisogno per soddisfare i propri tasks lavorativi.

Al fine dell’implementazione di questi tre tipi di obbiettivi, il designer definisce inoltre schemi di comportamento, scenari e requisiti.La pratica di questa metodologia si ritiene possa essere fondamentale nel riconoscimento dell’utente tipo della business dashboard, a tal proposito si veda il capitolo dedicato in questo testo per avere maggiori dettagli riguardo l’applicazione metodologica. In definitiva la metodologia di rifermento è utile al progettista per avere ulteriori informazioni con logiche bottom up poichè l’utente analizzato conosce già i workflow lavorativi e le informazioni che vorrebbe avere o utilizzare dall’interazione: egli deve essere visto come un esperto del flusso di lavoro dove la BD deve essere strumento di complemento alle attività di business giornaliere.Eckerson divide gli utilizzatori degli strumenti B.I. in due categorie: Casual Users e Power Users.24

22

23

Per Casual User, l’autore identifica gli utenti che vogliono utilizzare strumenti di reportistica e dashboard. Gli utenti occasionali vogliono report e cruscotti interattivi su misura per i loro ruoli applicativi che consentano di assolvere la loro ricerca di informazioni. L’utente “Power” che si avvale di una strategia di più strumenti al fine di analizzare, combinare ed interrogare le visualizzazioni. Esistono due tipi principali di approcci ad un cruscotto di monitoraggio che identificano un tipo di utilizzatore canonico, ma l’utente deve essere riconosciuto in base alla funzione ed ai workflow lavorativi che sono utili al compimento dei task lavorativi.Nella ricer-ca di una definzione attuale della business dashboard, si è visto come essa debba tener conto di descrivere non solo lo strumento tecnologico, le sue funzionalità, ma anche gli ob-biettivi che un determinato utente ricerca durante l’utlizzo dello stesso applicativo. Lo strumento di reportistica digitale è ad oggi uno strumento versatile, adottato nei più dispara-ti campi aziendali e come si è visto è l’ultimo passaggio di uno sviluppo che nasce da più di cento anni. Si propone una nuova versione della definizione di dashboard alla luce degli sviluppi legati al fruitore descritti in questo capitolo:

Una business dashboard è un software interattivo in cui determinati dataset venogono visualizzati per rendere agevoli dei processi decisionali a specifici utenti

Nel prossimo e conclusivo capitolo, si definiscono gli sviluppi che tale software può apportare nel supporto decisionale così come una descrizione generale della sua architettura.

1.4 Architettura di una Dashboard

Questo capitolo cerca di definire lo strumento dal punto di vista architetturale. Con il termine “Architettura Software” si definiscono tutte quelle componenti hardware e software di un prodotto o servizio e come le due interagiscono tra loro.Come descritto, la BD è il risultato di uno sviluppo incrementale di innovazioni tecnologiche che si sono sovrapposte e riorganizzate con il tempo e con l’evolversi delle metodologie e politiche aziendali. Nella BD convergono elementi già utilizzati negli altri strumenti DSS come il DataWarehause e che in linea generale rispecchiano gli strumenti di reportistica nel campo B.I.. La differenza sostanziale rispetto agli strumenti di decision making precedenti, la BD potrebbe essere ricondotta all’integrazione con tecnologie web based.Una forma di composizione architetturale esemplificativa della dashboard è riscontrabile nella Architettura Multi-Tier.25

Genericamente tale tipo di architettura presuppone che si stia sviluppando un software web based in cui vi sia una gestione online dei dati o della comunicazione di parte della struttura gestita via internet. La struttura logica tipica di un software multi livello potrebbe essere riconosciuta nei canonici tre livelli di comunicazione basati su connessioni web. Denominata “Three-tier” si riconoscono tre livelli di sviluppo:

- Livello presentazione: riconosciuto nelle applicazione RIA che vengono eseguite lato Client, in cui deve essere presente un broswer web in cui si eseguono una serie di tencologie front end definite appunto come Rich Internet Applications.

25 Wayne W. Eckerson Performance Dashboards: Measuring, Monitoring, and Managing Your Business, 2006, pag. 55

24

26 Wayne W. Eckerson The Future of Business Intelligence, 2016, pag. 7

- Livello applicazione: chiamato anche business logic funge da middle layer o livello medio che mette in comunicazione mediante applicativi di server il front-end e il back-end.

- Livello dati: definito come back-end è il livello del database in cui i dati sono depositati in maniera persistente su un DBMS dove le informazioni vengono raccolte e organizzate in modo che possano essere facilmente accessibili, gestibili e aggiornabili.

In questa organizzazione a tre livelli, possono essere adottati innumerevoli linguaggi di sviluppo divisibile per ciascun strato e scelti in base a logiche di business aziendale. Dagli ultimi anni del secolo scorso ad oggi, la logica dei tre livelli è rimasta largamente adottata nello sviluppo degli strumenti d’anlisi, mentre i software adottati per ciascun livello sono cambiati: si pensi al solo livello di presentazione i cui framworks adottati sono cambiati vertendo da applicazione B.I. Desktop ad applicazioni B.I. Platform: ad esempio nella fine degli anni 1990 si addottarono come framework Windows e Unix, alla fine degli anni 2000 Silverlight, Flash, ActiveX, attualmente con l’avvento del nuovo standard del markup language identificato con l’HTML5 si utilizzano librerie Javscript come ad esempio Angular js., Ajax, js. Query etc.26

Concludendo si potrebbe affermare che l’architettura così come i software adottati nella costruzione di una BD dipendono dagli obbiettivi per cui questa deve essere sviluppata: la definizione delle sue componenti sono relative

25

alle logiche di business così come alle competenze appartenute agli utenti ed in ultima analisi alle infrastrutture tecnologiche che fanno parte della competence aziendale. La tendenza di sviluppare applicazioni web based ha comportato uno sviluppo del numero di devices su cui l’informazione è stata “spalmata”, per questo motivo non si parla più di una singola dashboard sviluppata per un ambiente proprietario, ma di una piattaforma analitica responsive, progettata per più devices, dallo smartphone, al tablet, al descktop e che pertando possa adattarsi a diversi ambienti come differenti browser o sistemi operativi.L’architettura di una moderna business dashboard deve essere duttile ai cambiamenti al fine di essere fruita nei molteplici varianti strutturali.Viene proposta in seguito la versione definitiva di definizione di una business dashboard:

Una business dashboard è una web application in cui determinati dataset venogono visualizzati al fine di accrescere la creazione dei processi decisionali a specifici utenti

Nel prossimo capitolo ci si addentrerà maggiormente nella descrizione e nell’analisi degli aspetti attinenti al sopracitato livello di presentazione ed in particolare della User Interface legata alla rappresentazione visiva dei dati.

26

Verso una definizione tassonomica

2. Verso una definizione tassonomica

In questo capitolo si propone una metodologia di analisi della User Interface 27 di un software Business Dashboard: decostruendone gli apparati legati alla visualizzazione dei dati ed in generale dell’ impianto grafico.La descrizione degli aspetti compositivi della GUI comporta la creazione di una categorizzazione visuale che ha il compito di creare una tassonomia applicabile ai casi studio di questo particolare tipo di software.L’obbiettivo implicito è avere una tassonomia attuabile che permetta una visione più chiara dello stato dell’arte del design di un dato prodotto, risultato dalla decostruzione dei suoi elementi grafici: trovarne le funzionalità e gli aspetti che possono essere maggiormente predisposti a determinati compiti informativi.L’apparato informativo di un software adibito alla visualizzazione di dati nasce da quelle che si definiscono tre tipologie di natura informativa: natura computazionale, natura rappresentativa, natura scrittoria.28

La presenza simultanea di queste tre nature permette il trattamento grafico e manipolatorio dell’informazione, più nel dettaglio:per natura computazionale in quanto le dashboard sono sistemi computazionali;per natura scrittoria in quanto le dashboard adottano sistemi di interfaccia caratterizzati da una forte dimensione grafico-simbolica attraverso cui si manipolano le informazioni;per natura rappresentativa in quanto le dashboard sono caratterizzate da una dimensione grafico-espressiva che attraverso apparati grafici permette una manipolazione diretta degli stessi.

27 La nascita dell’ interfaccia grafica viene fatta risalire canonicamente nel 1973 presso Palo Alto Research Center Incorporated, con la creazione del concetto “what you see is what you get”. Si riporta una immagine pubblicitaria di uno dei primi modelli di pc che l’azienda ha prodotto lo Xerox Star 8010 nella cui interfaccia, curiosamente

28 Massimo Botta, Design dell’informazione - Tassonomie per la progettazione di sistemi grafici auto-nomatici, 2006

29

30

Tavola rappresentazione tre nature informative

Manipolazione e trattamento graficoInformazione

Sistemidi scrittura

Sistemicomputazionali

Sistemidi rappresentazione

Natura Computazionale

Natura Scrittoria

Natura Rappresentativa

2.1 Forme e funzioni

In questo paragrafo si descrive una prima categorizzazione del software applicata alle funzionalità per cui è stata progettata una BD: in ambito accademico si sono ricercati i punti in comune tra le teorie di categorizzazione dello strumento, proponendo una prima griglia concettuale entro cui dividere le applicazioni.Tra le fonti che si citano più spesso vi sono autori come Wayne Ekerson e Stephen Few, essi proposero una serie di definizioni nei loro scritti al fine di riconoscere categorie funzionali dei cockpits. Si riporta in seguito una prima proposta di suddivisione del software per funzione.Sia Few che Eckerson dividono le business dashboard principalmente in tre ruoli in base alle attività di business che supportano all’interno dei processi decisionali. Per Eckersono gli strumenti di B.I. sono riconducibili alle categorie Stategica, Operativa, Tattica, dove solo la funzione Strategica è riconducibile alla dashboard. Few categorizza lo stumento nelle tre tipologie: Strategica, Analitica, Operativa.29 Questo tipo di suddivisione è riportata come riferimento teorico poichè in termini operativi le tre tipologie lavorano in sinergia e sono l’una in funzione dell’altra, creando un ecosistema di DSS fruibili in una strategia comune.Few descrive come Dashboard Strategica come: “Dashboards of this type focus on high‐level measures of performance, including forecasts to lightthe path into the future. Although these measures can benefit from contextual information to clarify themeaning, such as comparisons to targets and brief histories, along

29 Stephen Few, Information Dashboard Design, 2006, pag 30.

Qui sotto viene riportato un esempio di UI per una BD strategica. Si noti la composizione della griglia in cui sono rappresentati i dati mediante Percentage graph e i Bullet graph

31

30 Stephen Few, Information Dashboard Design, 2006, pag 32.

31 W.Eckerson, 2016, www.eckerson.com, Accessed 10 May 2016

with simple evaluators of performance(for example, good and bad)...”30

Parafrasando la frase dell’autore statunitense la dashboard è per sua natura strategica. Si tratta di un software appositamente progettato per essere di supporto alle attività decisionali e per porre l’accento sugli obbiettivi principali dell’azienda mediante delle visualizzazioni che pongono l’accento sull’opposizione positivo e negativo. Essa è quindi descritta mediante visualizzazioni temporali come andamenti. Il suo livello di interazione è focalizzato alla comprensione dei fenomeni offrendo uno sviluppo in quelle che sono le previsioni del business di riferimento. L’obbiettivo di questi cruscotti è fornire una visione strategica che possa trasformarsi in decisioni a lungo termine e non immediate, per tale motivo le anagrafiche uti-lizzate non corrispondono a dataset aggiornati in tempo rea-le, ma sono riferibili a periodi di tempo rilevanti con valorizzazione dei campi giornaliero, settimanale, mensile.La BD strategica è rivolta a figure professionali con mansioni manageriali di pianificazione, planning per questo motivo l’interazione con i dati è limitata essenzialmente ad un monitorgaggio visivo o alla scelta di variabili tempora-li che si traducono in trasformazioni delle visualizzazioni di dati. Un altro elemento di differenziazione rispetto alle altre due tipologie è riconoscibile nei modelli statistici detti predittivi31: attività in cui la creazione di modelli statisitici è utile alla creazione di nuovi dati aziendali per fare previsioni e creare risposte automatizzate utilizzando i dati passati.

32

Per Dashboard Analitica si identificano quei software progettati per assolvere compiti di analisi approfondita dei fenomeni: l’utente deve aver la possibilità, mediante i dispositivi di accesso, di poter indagare e analizzare nel modo più completo, particolari dati ed estrapolarne delle informazioni utili. Dashboard analitiche richiedono un approccio diverso della progettazione rispetto a quelle strategiche: in questo tipo di software le informazioni devono essere contestualizzate rispetto a degli scenari, questo per facilitare l’analisi di grandi dataset complessi presenti nei DB aziendali. La complessità delle anagrafiche dati è un elemento caratterizzante di questo tipo di BD: la cosiddetta User Experience è molto importante poichè spesso l’analista si trova a dover esaminare dati complessi e deve investire molto tempo nell’analisi. Tra i cruscotti strategici ed i cruscotti analitici la discriminante è riconducibile al tempo che l’utente dedica all’interazione nella ricerca di senso.Si pensi all’utilizzo durante il processo di interazione della metafora “DRILL DOWN ”32: per un analista non è sufficiente vedere la decrescita delle vendite, ma necessita di analizzare le caratterisiche che hanno portato tale valore ad essere negativo.

“Analytical dashboards should support interactions with the data, such as drilling down into the underlying details, to enable the exploration needed to make sense of itthat is, not just to see what is going on but to examine the causes”

Questa tipologia BD è pensata per un’utenza dalle forti

32 Nel campo dell’ Information Te-chnology il termine ha un significato di un ulteriore passaggio informativo, nella dashboard assume un significato simile che corrisponde al passaggio da informazioni sintetiche ad informazioni dettagliate al fine della messa fuoco di particolari informazioni

33

33 L’aggiornamento del DB con valorizzazione dei campi in tempo reale o nelle tempistiche di aggiornemnto inferiori ai 15 minuti. Con tale termine si riconoscono software la cui base dati sia appunto in RTD: Real-time analytics, Real-time data integration, Real-time intelligence

capacità analitiche: analisti principalmente con competence ampia sui flussi di lavoro da analizzare e che possano interagire attivamente con l’organizzazione aziendale al fine di condividere i risultati delle analisi e trovare una strategia atta a definire nuovi sviluppi sul business.

Per dashboard Operativa si identificano qui software progettati per offrire all’utente informazioni in tempo reale di un particolare ciclo produttivo. Per questo motivo tali software sono creati per utilizzare i dati in real time 33.La velocità di comprensione di un ciclo produttivo, legata alla velocità e alla precisione della risposta dell’utente sono i fattori fondamentali per un buon design di questo software.L’interfaccia utente come nella dashboard strategica deve essere progettata con l’obbiettivo di essere fruibile nel modo più semplice. Possono essere portati come esempio quelle BD sviluppate per segnalazioni di allarmi negli impianti di trasmissione Location Based Services, in cui in base a certi tipi di anomalia vengono segnalati in real time al personale tecnico. Gli elementi grafici relativi alle segnalazioni di allarmi o anomalie sono gli elementi fondamentali che contraddistinguono questa tipologia di software rispetto alle altre due precedentemente descritte:

“...operational dashboards must have the means to grab your attention immediately if an operation falls outside the acceptable threshold of performance...”

Questa tipologia BD è pensata per un’utenza inserita in un ciclo produttivo che abbia bisogno di informazioni in real

34

time: essa deve essere un supporto costante e fruibile facilmente in modo da permettere il monitoraggio delle operazioni mantenendo un’alta attenzione sugli eventi che sono in costante evoluzione ed eventualemente sulle tipologie di allarmi che si possono evincere.Queste tre tipologie descritte, offrono un panorama ampio nel mondo B.I. ma come tutte le definizioni tendono a dividere o a descrivere differenze. In realtà i confini tra una tipologia e l’altra non sono così marcate, molto spesso una Dashboard Strategica può avere più funzionalità di una analitica ed è difficile stabilire l’appartenenza ad una o l’altra tipolologia solamente in base qualche variabile come l’interazione sul dato, sul tempo o sugli allarmi.A titolo di maggior chiarezza sulle attività riconducibili al mondo dei cruscotti di monitoraggio dati, vengono descritte in seguito le principali teorie legate alla funzionalità del prodotto.

35

Questo paragrafo ha il compito di descrivere in linea generale le funzioni riconosciute nello strumento di business dashboard al fine della creazione di una tassonomia funzionale che possa essere utile a categorizzare ulteriormente le funzionalità legate a questo strumento.Si pone l’enfasi su quella che è riconosciuta come il basic interaction tasks nei cruscotti di monitoraggio. In essi si possono verificare la presenza della famosa regola o “mantra” teorizzato da Shneiderman più di vent’anni fa:

“Overview first, zoom and filter, then details-on-demand”34

In questa frase l’autore statunitense riporta un flusso interattivo che ancora oggi è comune nei diversi campi dell’interazione con gli artefatti digitali. Nel caso dei cockpits esso potrebbe essere letto come una condizione fondamentale nella ricerca delle informazioni ed in generale con l’interazione visiva delle visualizzazioni.Da una vista generale “Overview” l’utente mediante una selezione con i dispositivi d’interfaccia “Zoom and Filter” ottiene delle informazioni ricercate “Details on demand”. Nella sua semplicità questa frase rappresenta il termine entro cui un progettista visuale deve confrontarsi durante lo sviluppo dell’interazione per le BD. Questa interazione con le visualizzazioni è riscontrabile in quelle due principali funzioni descritte da Eckerson, che un cruscotto deve supportare:

- Monitoraggio dati: monitorare lo stato del business in un colpo d’occhio;

2.2 Overview, drill down, detail

34 Ben Shneiderman, Designing the User Interface: Strategies for Effective Human-Computer Interaction, 1987

36

- Analisi dati: analizzare le eccezzioni e trovarene le cause;

Le funzionalità di base sono trasversali durante l’eperienza utente ed è riscontrabile in tutte tre le tipologie di BD che si sono descritte in precedenza.Proseguendo nella ricerca di una definizione condivisia delle funzionalità legate all’ interazione grafica dello strumento, si riprende il lavoro di Jeffrey Heer e di Ben Shneiderman, riportando l’analisi che essi rendono noti in una pubblicazione dedicata.35

Come già scritto in questo testo la caratteristica delle dashboard è cercare di aiutare l’utente nella presa di decisioni. Questo aiuto passa attraverso l’interazione delle visualizzazioni mediante una serie di dispositivi grafici e tecnologici che potremmo definire come “Configurazioni d’uso”.36

Queste configurazioni sinoetiche altro non sono che una serie di interfacce grafiche che possono essere manipolate a seconda di determinati obbiettivi. Le visualizzazioni di dati presenti in queste interfacce grafi-che devono essere manipolate mediante interazioni e come suggerito dai due autori statunitensi tali tipologie di interazione diretta sono ascrivibili in tre insiemi: Data e View Specification, View Manipulation, Process e Provenance.Per Data e View Specification, gli autori identificano come specifiche visuali quelle attività che corrispondono all’analisi visuale che descrivono le caratteristiche della visualizzazione dei dati e alla loro manipolazione. L’analisi visuale è un processo iterativo di esplorazione che richiede

35 Jeffrey Heer, Ben Shneiderman, A taxonomy of tools that support the fluent and flexible use of visualizations., 201236 Massimo Botta, definisce una configurazione d’uso come:“Una configurazione d’uso è, in altri termini, la stretta relazione fra le caratteristiche formali di un insieme informativo e i suoi dispositivi grafico funzionali” citazione da Design dell’informazione - Tassonomie per la progettazione di sistemi grafici auto-nomatici, 2006,pag.123

37

più interazioni e diversi punti di ingresso e di uscita nel processo di interazione. Nella dashboard di controllo è quindi possibile progettare tutta quella serie di dispositivi che permettono all’utente di ripercorrere la storia delle sue interazioni, così come esportare i risultati della propria esplorazione per presentare e condividere i fenomeni analizzati.Le attività di questa tipologia devono consentire agli analisti di visualizzare in modo selettivo i dati, per filtrarli e concentrarsi su elementi rilevanti al fine di ordinare le informazioni per esporre i modelli. Si riporta una breve descrizione delle attività che fanno parte di questa tipologia: Visualize, Filter, Sort, Derive;

- Visualize: quale dato deve essere visualizzato e come deve essere utilizzato. I software che dispongono di questa specifica sono progettati per predisporre all’utente una serie di widget e dispositivi che si rivolgono ad un fruitore esperto: egli deve avere delle competenze sia sui dati che sul software poichè deve saper scegliere i dataset da visualizzare e saper utilizzare l’interfaccia utente per definire la visualizzazione;

- Filter: il filtro è comune nelle interazioni con le UI basate sulla visualizzazione dati in quanto raramente viene visualizzato l’intero dataset ma il fruitore seleziona la tipologia dei dati. Inoltre durante il processo di interazione i widget predisposti a filtrare le informazioni servono al proseguo dell’azione;

- Sort: ordinamento è un’altra operazione fondamentale nelle

38

37 Le gesture sono riconoscibili nelle basic interaction tasks

data visualizations. Questo tipo di interazione prevede che vi siano degli appositi widget adibiti all’organizzazione dei dati. Il tipo di output nella visualizzazione è quindi condizionato dalle scelte che il fruitore compie. L’organizzazione di solito si riferisce ad unità di analisi temporali;

- Derive: questo tipo di processo prevede che nel dataset, possano essere inseriti dei dataset di provenienza differente. In questo modo è possibile da parte dell’utente confrontare dati di provienenza differente per una migliore comprensione del fenomeno. Ad esempio, dati di vendita di viaggi confrontati a dati esterni, come le condizioni meteo.

I tasks relativi alla View Manipulation, corrispondono al processo di esplorazione visuale dell’interfaccia grafica. Una volta che l’utente ha impostato una visualizzazione di dati deve essere in grado di manipolarla per indagare ulteriori ipotesi o evidenziare caratteristiche. Si propongono in seguito le tipologie di manipolazioni necessarie all’esplorazione:Select, Navigate, Coordinate, Organize.

- Select: la selezione è l’interazione fondamentale riconosciuta nelle UI. Essa in particolare nella interactive data visualization corrisponde a tutte quelle gesture che facilitano la navigazione con l’interfaccia.37

- Navigate: il mantra per questa tipologia di interazione sa-rebbe “Cerca, visualizza contesto espandi a seconda della richiesta”. Questa tipologia sarebbe più rappresentativa per

39

38 L’organizzazione delle viste di un piano deriva dall’organizzazione spaziale già teorizzata dal matematico francese Gaspard Monge nelle sue Proiezioni Ortogonali

l’esplorazione degli schemi ordinali come le mappe. La navigazione quindi sottende una ricerca delle informazioni su un piano in cui poter esplorare la visualizzazione.- Coordinate/Organize: la coordinazione e l’organizzazione corrispondono alla facoltà di modificare l’organizzazione spaziale delle viste presenti su schermo. Nella UI uno stesso dataset può essere visualizzato con metafore visive differenti a seconda del tipo di informazione voluta nella stessa schermata. Questa tipologia di vista multipla permette all’utente di avere maggiori dettagli dello stesso fenomeno che è descritto. 38

I tasks relativi alla Process e Provenance corrispondono alla facoltà dell’utente di condividere ed esportare i risultati della sua analisi. L’analisi visuale non si limita alla visualizzazione dei dati e alla loro manipolazione. L’analisi visuale è un processo iterativo di esplorazione che richiede più interazioni e diversi punti di ingresso e di uscita nel processo di interazione. Nella dashboard di controllo è quindi possibile progettare tutta quella serie di dispositivi che permettono all’utente di ripercorrere la storia delle sue interazioni, così come esportare i risultati della propria esplorazione per presentazioni e condividere i fenomeni analizzati. In questa tipologia si riconoscono i seguenti tasks: Record, Annotate, Extract.

- Record: al fine di supportare i processi decisionali iterativi il software deve poter registrare le azioni e le scelte che l’utente ha compiuto durante il processo di analisi ed esplorazione.

40

Per questo motivo la History Line può essere un buon esempio di registrazione delle azioni dell’utenza.

- Annotate: i tool B.I. non solo permettono l’esplorazione delle visualizzazioni, ma possono permettere al fruitore di annotare commenti testuali o evidenziare particolari variazioni. Questo tipo di processo rientra in una visione plurale della fruizione del software in cui vi sono differenti utenti che si scambiano informazioni riguardo particolari punti di interesse.

- Extract: l’estrazione è un processo di condivisione delle informazioni e comunicazione dei risultati delle esplorazioni. L’esplorazione è di solito un’azione individuale, mentre la comunicazione dei risultati della stessa sono rivolti a più persone. I tool di estrazione sono quindi quei dispositivi che permettono l’estrazione e l’esportazione di particolari punti di interesse. La condivisione è infine l’ultimo processo di comunicazione. Essa permette all’utente di condividere le informazioni ad altri utenti mediante dispositivi progettati.

In questo paragrafo si sono proposte una serie di funzioni che si considerano trasversali a tutte le tipologie di dashboards. Sono funzioni legate all’esplorazione ed all’analisi delle informazioni e di come queste possono essere sfruttate nella creazione di senso. Si sono descritte quelle caratteristiche che possono essere riconosciute al fine di una tassonomia funzionale: per i designer, la tassonomia

41

2.3 User Inteface Dashboard

Se nel paragrafo precedente si sono descritte le funzionalità al fine tassonomico, in questo paragrafo vengono definite le caratteristiche grafiche per la progettazione di una dashboard controllo dati. Sono aspetti legati a funzionalità presenti in determinate scelte compositive legate al trattamento grafico delle informazioni, in questo caso dei dati. Una dashboard è un software che comunica mediante il suo livello rappresentativo sottoforma di visualizzazione di dati e livelli di interazione: il dato da pura informazione testuale o numerica viene trasformato e aggregato ad altri dati anche di tipologia differente al fine di creare un dataset che comunichi a seconda di un obbiettivo comunicativo. Le Anagrafiche dati non sono altro che una serie di relazioni logiche espresse sottoforma tabellare (Data Table) che consentono di definire un fenomeno. Il modo in cui un utente ottiene informazioni varia in funzione del tipo di restituzione grafica con cui le anagrafiche dati vengono tradotte in visualizzazioni. Ogni soluzione della User Interface stabilisce un rapporto tra l’informazione trattata e e le tecniche e i modi con cui vi si interagisce producendo quelle che vengono riconosciute come tipologie della rappresentazione schematica.39

Riprendendo le definizioni dei “Tasks” di Ben Shneiderman identifichiamo sette principali tasks o compiti in cui sono divise le interfacce grafiche relative alla visualizzazione dei

39 Ben Shneiderman, Designing the User Interface: Strategies for Effective Human-Computer Interaction, 1987

42

dati. La loro divisione dipende da come i dataset sono visualizzati e come l’utente si trova ad interagire con tali informazioni. L’organizzazione dei dati in schemi è un argomento toccato anche da Botta40, nel suo caso egli comprende la tassonomia dei compiti esposta dall’autore statunitense, ma la categorizza in tre variabili principali che si descrivono in seguito: Schemi Quantitativi, Schemi Strutturali, Schemi Ordinali. Si ricorda che tale suddivisione è utile ai fini teorici nella creazione di una tassonomia visiva che possa aiutare il progettista visivo nel definire una categorizzazione propositiva a ricerca o riconoscimento compositivo di prodotti.

Per Schemi Quantitativi nel contesto delle business dashboards si identificano quel tipo di rappresentazioni in cui i dati sono solitamente di origine quantitativa e organizzati secondo uno spazio geometrico. Il fine del diagramma nelle BD è dar forma ad un fenomeno informativo. Ai fini di un riferimento teorico si vedano le definizioni che studiosi come Moles, Bertin, Anceschi descrivono come diagrammi 41.

Per Schemi Strutturali nel contesto delle business dashboards si identificano quel tipo di rappresentazioni in cui l’informazione è organizzata visivamente secondo relazioni fra le parti o vi è generalmente un’ organizzazione tipologica dell’informazione.Il fine dello schema strutturale nelle BD è rappresentare complessivamente un fenomeno informativo. Si riconoscono in tale tipologia le visualizzazioni asseribili al grafo ed alla mappa.

40 Massimo Botta, Design dell’informazione - Tassonomie per la progettazione di sistemi auto- nomatici, 2007, pag. 135

41 Per un approfondimento teorico si veda la definizione degli ultimi tre livelli di schematizzazione di Moles del 1972 (10°, 11°,12°).

Inoltre si tenga presente alla definizione di “Diagrammes” di Jacques Bertin nella sua accezione di “Schema de Base”:

“Dans les diagrammes et les réseaux, la libre disposition des dimensions du plan conduit à distinguer les semis, les impositions rectilignes, circulaires, orthogonales, polaires ou les élévations et à définir des Types de construction que l’on peut caractériser par des Schemàs de

43

42 Il Taxòn è considerato come un’ unità tassonomica che differisce per determinate cataratterisiche morfologiche da altre unità. 43 Ben Shneiderman, Designing the User Interface: Strategies for Effective Human-Computer Interaction, 1987, pag. 339

Per Schemi Ordinali nel contesto delle business dashboards si identificano quel tipo di rappresentazioni in cui l’informazione è organizzata secondo variabili di origine categoriale e temporale. Il fine dello schema ordinale nei cruscotti di monitoraggio dati, è raccontare l’evoluzione storica, categoriale e spaziale di un dato fenomeno.

Le tre tipologie in linea teorica dato il loro alto grado di astrazione potrebbero coprire tutti gli esempi di visualizzazione di dati nelle BD. Visto però l’alta genericità delle definizioni proposte, in seguito si riportano in modo più dettagliato delle ulteriori categorizzazioni tipologiche utili a definire una migliore determinazione delle visualizzazioni così come una prima proposta di taxòn tassonomici.42

Si riprendono alcune categorie proposte da Ben Shneiderman e si cerca di attualizzarle al prodotto B.I.. Scrive l’autore statunitense riguardo i riferimenti tassonomici lui proposti nel 1987:

“This taxonomy is useful only if it facilitates discussion and leads to useful discoveries”43

Secondo il ricercatore questi taxòn sono riportati per facilitare un riconoscimento di pattern visivi e compositivi nell’interfaccia dello strumento ai fini della ricerca. Pur riconoscendo le categorie descritte nel testo 1-dimensional, 2-dimensional, 3-dimensional, Temporal, Tree, Network, si propone qui in seguito una loro attualizzazione al contesto BD.

44

Il taxòn 1-dimensional si riferisce alla singola dimensione che nell’accezione originale doveva descrivere quegli elementi grafici con delle caratteristiche visive maggiormente incentrate su di una rappresentazione tabellare o scrittoria del dato e dalla compresenza di una sua rappresentazione visiva grafica. Si propone una attualizzazione al contesto bu-siness dashboard, dove si intendono appartenenti a questa categoria gli elementi UI rappresentati come visione tabellare o testuale, come rifermento si considerino le datatable o rappresentazioni verbo testuali dei dati. Questo taxòn rientra nella categoria degli Schemi Quantitativi.

Il taxòn 2-dimensional si riferisce a visualizzazioni di dati geograficamente costituite, come geolocalizzaioni e le mappe, in cui vengono visualizzati dei dati georeferenziati. Si pensi alle rappresentazioni di dati urbani con dataset riferibili a sistemi LBS. Anche nella definizione originale il 2D doveva descrivere quegli elementi grafici con delle caratteristiche visive basate sulla rappresentazione di mappe geografiche e floorplans44. Questo taxòn rientra nella categoria degli Schemi Strutturali.

Il taxòn 3-dimensional si riferisce a visualizzazioni di dati geograficamente costituite in un ambiente tridimensionale.Attualmente la visualizzazione di dati rappresentate tridimensionalmente è poco utilizzata in strumenti B.I. Si possono trovare esempi interessanti in cruscotti di monitoraggio di tipologia operativa. Come riferimento si pensi alle interfacce utente presenti nei navigatori dei

44 E’ possibile riconosce un’ulteriore passaggio tassonomico con il riconoscimento di altre due categorie: Base Map, Cartogram. Per Base Map si intendono quelle visualizzazioni in cui i dati sono riferiti geograficamente e sono basati su mappa geografica; Per Cartogram si identificano quelle visualizzazioni in cui le informazioni geograficamente riferite vengono stravolte secondo i principi dell’anamorfosi. Vengono riportati due esempi a titolo illustrativo.

Base Map www.plot.ly.com

Cartogramwww.anguagesindanger.eu

45

45 Per impianto inclusivo si definiscono metodi di visualizzazione in cui i dati sono rappresentati in rapporto gerarchico tra loro come le TreeMaps sperimentate già da Shneiderman nel 1991, qui riportato un esempio di questo grafico.

cruscotti auto o ad alcune dashboard di comunicazione dei dati urbani. Questo taxòn rientra nella categoria degli Schemi Strutturali.

Il taxòn Temporal si riferisce a visualizzazioni di dati rappre-sentati secondo delle variabili temporali. Queste rappresentazioni sono riconducibili alla tipologia degli Schemi Ordinali in cui l’informazione è organizzata in modo sequenziale come ad esempio le timeline.Esistono applicativi che mettono le rappresentazioni temporali come core della propria comunicazione. Si pensi agli applicativi in ambito medico in cui si rappresentano dati legati alla salute di un paziente in relazione al suo decorso temporale.

Il taxòn Tree si riferisce a visualizzazioni di dati che corrispondono a gerarchie visuali come le Treemaps.In generale le visualizzazioni definite ad “impianto inclusivo”45 appartengono a questa tipologia. Questo taxòn rientra nella categoria degli Schemi Strutturali.

Il taxòn Network si riferisce a visualizzazioni di dati che corrispondono ai sistemi rappresentativi dei Grafi.Sono rappresentazioni che pongono l’enfasi sugli aspetti gerarchici e relazionali, definendo cluster e insiemi di appartenenza. Questa tipologia di grafico è asseribile alla categoria degli Schemi Strutturali.

Nella proposta di una tassonomia che possa rappresentare al

46

meglio le variabili degli elementi grafici presenti nell’interfaccia di una business dashboard si descrivono gli elementi che rappresentano delle variabili visive.

Variabili visive

Jacques Bertin nel 1967 affermava che le Variabili Retiniche rappresentano differenti modi di trattamento e caratterizzazione dell’informazione nel piano della rappresentazione. Egli definiva queste variabili nel contesto cartografico e più precisamente in quei tratti che compongono un simbolo cartografico. Il concetto di variabile viene ivi ripreso per descrivere quei fattori di cambiamento che si verificano durante l’esperienza esplorativa del dato. Ai fini tassonomici si sono scelte quattro delle sei variabili: Dimensione, Forma, Valore, Colore.

Per dimensione si intende quella variabile con cui l’elemento grafico di un’interfaccia cambia di dimensioni come l’altezza, la lunghezza;per Forma si intende il cambiamento di forma di un elemento, ad esempio da un quadrato ad un cerchio;per Valore si identificano le variabili legate al cambiamento della tonalità e della luminosità del colore e agli aspetti di Saturazione cromatica;per Colore si identificano le variabili legate al cambiamento del colore che caratterizza un elemento grafico.

47

Gli elementi grafici nel contensto delle interactive datavisua-lizations subiscono trasformazioni per la loro natura digitale:ad ogni aggiornemento del dataset è possibile che vi siano cambiamenti negli elementi e che questi siano caratterizzati dalle quattro variabili sopra descritte. Si pensi alle dashboard di controllo, in cui gli elementi vengono rappresentatati, ad esempio, mediante formattazione SVG acronimo del termine inglese Scalable Vector Graphics.Queste visualizzazioni di dati sono rappresentate mediante una libreria in programmazione javascript dal nome D3.js. Il fine è quello di creare uno stretto legame tra spazio e dati, ovvero tra DOM e il modello di dati, facilitando tutti i processi di aggiornamento e transizione grazie al pattern di selezione enter-update-exit fornito da D3.js.46 Grazie a questa funzionalità gli attributi che interagiscono con i fogli stile CSS ed i dati in back end, condizionano le variabili visuali di un elemento rappresentato avendo la possibilità di modificarne appunto la forma, la dimensione, Valore, Colore.

Data-Driven Documents, si tratta di una libreria in linguaggio Javascript, realizzata nel 2011. Permette ad un browser di gestire in modo più controllato le datavisualiztions da parte di un browserwww. d3js.org

46

48

In questo ultimo paragrafo si descrivono in linea teorica le tipologie di interazione che un utente può applicare durante il suo processo di esperienza con le visualizzazioni di dati presenti in una business dashboard.L’eperienza interattiva dell’esplorazione del dato è un processo che deve essere progettato al fine di creare prodotti che possono comunicare effettivamente. Il proposito di questo paragrafo è descrivere quelle caratterisitche interattive che un utente può utilizzare nella ricerca di senso durante l’esplorazione visuale.Il concetto di User Experience acronimo UX è stato coniato dal ricercatore statunitense Donal Norman nella metà degli anni 1990, con la volontà di descrivere le emozioni che un utente evince durante l’utilizzo di un prodotto.47 La progettazione dell’esperienza di dashboard passa anche dalla progettazione di un’interazione con gli apparati grafici attraverso quei dispositivi di accesso che permettono l’interazione con l’interaccia chiamati anche widget.Le tecniche di esplorazione nel contesto delle BD interattive come abbiamo già scritto, permettono un avvicinamento da una vista generale ad un dettaglio informativo ricercato mediante delle interazioni con le visualizzazioni che si definiscono “Manipolazioni”.Riprendendo la definizione proposta da Anceschi nel 1992per manipolazioni, si intendono quella serie di attività grafiche che agiscono sull’oggetto referente, al fine di essere trasformato in un oggetto visivo. Nel caso specifico delle BD, si intende per oggetto referente, un fenomeno informativo espresso in dati e per oggetto visivo la sua trasfor-mazione in visualizzazione grafica.

47 La definizione di User Experience è stata con il tempo più volte formalizzata fino a raggiungere una descrizione standardizzata. Secondo l’International Organization for Standardization la UX è definita come norma ISO 9241-210:2010: “person’s perceptions and responses resulting from the use and/or anticipated use of a product, system or service”

2.4 User Experience Dashboard

49

A loro volta le manipolazioni possono essere divise in due categorie: manipolazioni ostensive che corrispondono a quelle attività dirette alla modifica diretta degli attributi grafici di una visualizzazione e manipolazioni attuative che agiscono ad un livello più profondo sulle anagrafiche dati al fine di modificare la rappresentazione.

Le manipolazioni ostensive sono quel tipo di modifiche che l’utente può effetturare e che agiscono direttamente sulle visualizzazioni di dati.Si possono riconoscere sei gradi di intervento che agiscono sulla visualizzazione, traslando le definizioni di Anceschi che egli applica nei suoi esempi legati alle illustrazioni, si applicano i gradi di manipolazione alle business dashboard:1° Vista vantaggiosa, 2° Messa in posa della visualizzazione, 3° Agire sulla visualizzazione guardandola dall’interno, 4° Trasparenza di parti della visualizzazione, 5° Esploso della visualizzazione, 6° Spaccato della visualizzazione.

Per il taxòn 1° Vista vantaggiosa, si identifica la scelta da parte dell’utente della metafora visiva con cui il dato deve essere visualizzato da cui partire per l’esplorazione. Si pensi a quegli stumenti che permettono l’importazione di dataset esterni, XML o CSV ad esempio, che una volta importati permettono al fruitore della BD di scegliere come questi dataset possono essere visualizzati mediante la selezione di finestre pop up di esempio.

50

Per il taxòn 2° Messa in posa della visualizzazione, si identificano quelle attività in cui l’utente definisce delle variabili visive che caratterizzano la visualizzazione mediante i dispositivi di navigazione. Si pensi ai cosidetti multiple-selector presenti nella UI che pos-sono definire variabili differenti che modificano la visualizzazione. Un esempio potrebbero essere dei widget che permettono una selezione temporale.

Per il taxòn 3° Agire sulla visualizzazione guardandola dall’interno, si identifica la scelta da parte dell’utente della trasmutazione di dati da un sistema visivo ad un sistema ad esempio tabellare. Ad esempio si pensi a interfacce che permettono una doppia vista del fenomeno: se in una è possibile vedere la visualizzazione grafica, nell’altra è possibile vederne la relazione tabellare dei dati.

Per il taxòn 4° Trasparenza di parti della visualizzazione, si identifica la scelta da parte dell’utente di esplorare solo alcune sezioni di una visualizzazione. Ad esempio si pensi alla selezione direttamente interagendo sull’infografica, di una sua parte per poterne leggere le informazioni. Modifiche visive di questa tipologia, possono essere considerate come i contrasti attributivi che agiscono direttamente sulla visualizzazione mettendone in evidenza delle parti ed escludendone delle altre attraverso trasparenze e colori.

Per il taxòn 5° Esploso della visualizzazione, si identifica la scelta da parte dell’utente di esplorare solo alcune sezioni di una visualizzazione ma a differenza del 4° vengono

51

decontestualizzate alcune sezioni del grafico per poter proseguire delle ulteriori analisi. Ad esempio si pensi ad una selezione di tipologia drill-down diretta a visualizzare le informazioni in una nuova finestra mantenendo i rapporti gerarchici della visualizzazione.

Per il taxòn 6° Spaccato della visualizzazione, si identifica la scelta da parte dell’utente di agire sull’infografica destrutturandone la forma, non solo ponendo in evidenza alcune sue parti ma interagendo con queste al fine di destrutturarla e ponendola in una nuova finestra d’analisi.

A fianco di queste sei categorie, si possono riconoscere altredue tipologie di manipolazioni definite come Attuative.Le manipolazioni attuative come specificato da Botta48, agiscono ad un livello più profondo. Nel nostro caso possiamo riconoscerne la natura computazionale in quanto sono manipolazioni che avvengono direttamente sul Database di rifermento. Idealmente si identificano due principali tipologie di modifica che corrispondono all’architettura stessa del Data base di rifermento: Attuativa di 1°livello e Attuativa di 2°livello.

Per il taxòn Attuativa di 1°livello si identifica la scelta da parte dell’utente di agire direttamente nel DataTable sulle relazioni del DB modificandone la mappatura. Si pensi a quegli applicativi che permettono l’utilizzo di interfacce Dataflow e Pivot table.

48 Massimo Botta, Design dell’informazione - Tassonomie per la progettazione di sistemi auto- nomatici, 2007, pag. 165

52

Per il taxòn Attuativa di 2°livello si identifica la scelta da parte dell’utente di modificare le anagrafiche dati riguardanti le singole viualizzazioni direttamente dall’interfaccia utente della dashboard mediante appositi widget. Si pensi ad esempio alle opzioni come i radio button o slider in cui è possibile cambiare le variabili visive della visualizzazione.

Proseguendo nella descrizione tassonomica degli elementi interattivi che concorrono nell’esplorazione delle interfacce relative alle business dahsboard si conclude con le categorie dedicate alle interazioni. In particolare si descrivono le gesture utente che si compiono sull’oggetto della figurazione. Si riconoscono cinque fondamentali azioni con cui l’utente può interagire con l’interfaccia: Fly through, Fly over, Zooming, Panning, Drill-Down.

La tecnica del Fly Through letterlamente passare attraverso, si riferisce a quelle interazioni in cui il punto di vista viene posto in mezzo al campo visivo, si pensi agli spazi tridimensionali come interfacce di dashboard operative. La tecnica del Fly Over letterlamente passare sopra, si riferisce a quelle interazioni in cui il punto di vista viene posto sopra al campo visivo, simile alla vista cosiddetta a volo d’uccello. Tale tecnica è utilizzata soprattutto nelle interfacce di dashboard che adottano schemi strutturali come le base map.

53

La tecnica dello Zooming si riferisce a quelle interazioni in cui l’utente può ingrandire una determinata aerea della visualizzazione per aumentarne il dettaglio informativoLa tecnica del Panning si riferisce a quelle interazioni in cui l’utente può esplorare il contenuto informativo spostando lateralemnte il piano della rappresentazione.

La tecnica del Drill-Down si riferisce a quelle interazioni in cui l’utente può esplorare il contenuto informativo interagendo con esso cliccando punti di interesse e aumentandone il dettaglio informativo. Questa tecnica è la maggiormente adottata nelle business dashboard, poichè maggiormente congeniale nell’esplorazione e ottenimento delle informazioni ai fini di analisi complesse.

Nella seguente pagina viene riportata una mappa visiva dei riferimenti tassonomici che in questo capitolo sono stati descritti.

54

Dashboard

RoleStrategicAnalyticalOperational

ArtifactCustomVideoInteractiveWeb App

Data handling

Update

HourlyReal TimeDailyWeeklyMonthly

Data Domain

FinanceMarketingSalesManofacturingH.R.

Dataset QuantitativeNon Quantitative

Interactivity

Data Interaction

PanningZoomingFly overFly throughDrill-Down

Process ProvenanceShareExtractAnnotateRecord

View ManipulationOrganizeNavigateSelect

ImportDeriveSortVisualizeFilter

Visual data

Actuation

Oxtension

Data Task

1 level2 level

1 grade2 grade3 grade4 grade5 grade6 grade

TreeTemporalMultidimensional3D World2D Map1D LinearNetwork

Stephen Few

Giovanni Anceschi

Ben Shneiderman

Originality

Massimo Botta

Massimo Botta

Originality

Stephen Few

Tavola di riferimenti tassonomici

Dashboard

RoleStrategicAnalyticalOperational

ArtifactCustomVideoInteractiveWeb App

Data handling

Update

HourlyReal TimeDailyWeeklyMonthly

Data Domain

FinanceMarketingSalesManofacturingH.R.

Dataset QuantitativeNon Quantitative

Interactivity

Data Interaction

PanningZoomingFly overFly throughDrill-Down

Process ProvenanceShareExtractAnnotateRecord

View ManipulationOrganizeNavigateSelect

ImportDeriveSortVisualizeFilter

Visual data

Actuation

Oxtension

Data Task

1 level2 level

1 grade2 grade3 grade4 grade5 grade6 grade

TreeTemporalMultidimensional3D World2D Map1D LinearNetwork

Stephen Few

Giovanni Anceschi

Ben Shneiderman

Originality

Massimo Botta

Massimo Botta

Originality

Stephen Few

““

ISO 9241-210:2010

Human-centred design is an approach to interactive systems development that aims to

make systems usable and useful by focusing on the users, their needs and requirements, and by applying human factor-

sergonomics, and usability knowledge and techniques.

3. Valutare una visualizzazione di dati

Nei precedenti capitoli si sono descritte le caratteristiche che concorrono alla definizione di un software business dashboard, fino a una proposta di descrizione delle tipologie categoriche che lo compongono. Ora che il prodotto è stato analizzato ed in linea generica si è evinto il suo funzionamento, l’obbiettivo di questo capitolo è capire come valutarne l’efficacia.Si è riportato il termine efficacia volutamente in quanto si ricollega ad un valore intrinseco di un prodotto digitale, a tal punto che è presente in una definizione di standard qua-litativo. L’International Organization for Standardization riporta al punto 2.3 della seguente ISO 9241-210:201049 che per efficacia si intenda:

“resources expended in relation to the accuracy and completeness with which users achieve goals”

Parafrasando la definizione si capisce che le risorse spese in relazione alla correttezza e alla completezza con il quale gli utenti raggiungo determinati obbiettivi, sià già di per sé un interessante punto di partenza per definire come valutare un prodotto.Il termine efficienza compare inoltre nella stessa normativa nella definizione di usabilità:

“extent to which a system, product or service can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use”

Riportando il concetto di usabilità si sono definiti così i

49 Questa normativa è una versione riveduta di una precedente del 1999 riconosciuta ISO 13407: 1999.Lo scopo del nuovo standard è riassunto in questi tre assunti:

- chiarire il ruolo di iterazioni nell’intero processo di progettazione (non solo di valutazione);

- evidenziare che l’UCD può essere utilizzato in tutto il ciclo di vita di un sistema informatico;

- definire le attività di progettazione;

- chiarire i principi dello human centered design.

www.iso.org/obp/ui/#iso:std:i-so:9241:-210:ed-1:v1:en

59

50 Si veda la normativa ISO/IEC 25010:2011

www.iso.org/obp/ui/#iso:std:i-so-iec:25010:ed-1:v1:en

limiti entro il quale impostare la ricerca di un metodo di valutazione.Si noti come nella definizione stessa, l’usabilità sia considerata un’entità misurabile. Essa viene misurata in uno specifico contesto come ad esempio un sistema, un prodotto, un servizio da determinati utenti al fine di raggiungre specifici obbiettivi. Leggendo la frase si riconoscono gli elementi fondamentali di una valutazione di usabilità di un prodotto: il contesto, l’utente, l’obbiettivo.

Per Utente si identificano le persone fisiche a cui è destinato il prodotto o servizio;

per Contesto si identificano gli scenari di utilizzo specifici di un prodotto;

per Obbiettivo si identificano le finalità per cui il prodotto deve essere utilizzato dall’utente.

Queste tre variabili di misura dell’usabilità sono considerate fondamenti dell’approccio User Centerd Design acronimo UCD: metodologia utilizzata nella progettazione di artefatti comunicativi come risposta ai bisogni degli utenti. Al fine di definire una prima proposta teorica si pongono queste tre caratterisitiche come fondamentali nella progettazione di un metodo valutativo, che possa essere parte integrante del processo di sviluppo dell’artefatto. Si noti inoltre che efficienza ed efficacia rientrino nei valori che conocorrono a definire la qualità di un software 50.

60

51 Si veda la normativa ISO/IEC 25010:2011

www.iso.org/obp/ui/#iso:std:i-so-iec:25010:ed-1:v1:en

Per definire un software di “qualità” si deve innanzitutto capire il punto di vista da cui misurare la qualità stessa del prodotto. Molto spesso per “qualità” nel campo informatico si identificano certificazioni di competence da parte di team di sviluppo oppure della qualità dell’applicazione di particolari metodologie manageriali. Riprendendo il modello qualitativo espresso nella normativa dedicata ISO/IEC 912651, si legga l’enunciazione di una serie di parametri “Esterni” ed “Interni” rispetto a cui si può misurare la qualità. Per paramenti Esterni si identificano quella serie di attributi che un utente percepisce durante l’utilizzo del SW: funzionalità, affidabilità, robustezza, efficienza, usabilità, ecocompatibilità. Per paramenti Interni si identificano quella serie di attributi che uno sviluppatore percepisce durante l’utilizzo del prodotto: verificabilità, manutenibilità, riparabilità, evolvibilità, riusabilità, portabilità, leggibilità, modularità. Restringendo il campo della ricerca, si può capire come per valutare un software di visualizzazione dati si possa identificare una metodologia partendo dai parameti “Esterni” riconducibili a Funzionalità, Efficienza ed Usabilità. Il motivo per cui si sono definiti tali attributi è per via della loro riconducibilità agli aspetti legati all’interazione tra l’utente con la User Interface. Se per gli utlimi due si sono già descritte le caratteristiche nel paragrafo precedente, il parametro della Funzionalità viene esposto come la soddisfazione dei requisiti e bisogni dell’utente mediante la creazione di funzionalità rispetto ai

61

52 Si veda la normativa IEEE 29148-2011

www.standards.ieee.org/findstds/standard/29148-2011.html

requisiti espressi:

“A set of attributes that bear on the existence of a set of functions and their specified properties. The functions are those that satisfy stated or implied need” I requisiti dall’inglese “Requirements” rappresentano una parte fondamentale di una progettazione di un software: essi corrispondono a delle definizioni di obbiettivi che il progetto deve adempiere. Parafrasando la definizione riportata dalla IEEE52, i requisiti possono specificare le funzionalità di un artefatto avendo il compito di descrivere, ad esempio le interfacce, le prestazioni del sistema, le anagrafiche dati, i vincoli di progettazione, le interazioni con i widgets.Si riconosce nella “Analisi dei requisiti” quella attività che precede la descrizione delle specifiche stesse. Un’attività che comporta la condivisione degli obbiettivi del software mediante la descrizione delle singole funzionalità in una o più interazioni tra analisti e il cliente, ad esempio riunioni, briefing, incontri con gli utenti finali. L’analisi dei requisiti in ultimo, copre tutta la portata del progetto: essa è un’analisi completa e approfondita, che prende in considerazione i punti di vista e le esigenze di tutti i soggetti coinvolti nel progetto.L’analisi dei requisiti rappresenta il documento principale di discussione delle finalità che si condivide con il committente del progetto.Si può affermare, che con la definizione del requisito come una specifica funzionalità a cui la dashboard deve adempiere, si sono toccati i punti fondamentali per introdurre il concetto di valutazione nel prossimo paragrafo.

62

Ai fini della ricerca, in questo paragrafo si descrivono in linea generale quelle attività volte a validare un prodotto software. La voltontà di affrontare un’illustrazione delle caratteristiche che definiscono un metodo di valutazione SW è comportata da finalità di progettazione di una metrica applicabile al contesto delle visualizzazioni di dati.Esistono molteplici metodi di validazione di un applicativo digitale, che possono essere divisi per il campo di applicazione: metodi di valutazione dei parametri esterni e di parametri interni.Le valutazioni dei parametri esterni dipendono dal livello di presentazione, riguardante l’interazione dell’utente con l’interfaccia grafica e le funzionalità esplicite del software. Ad esempio si pensi agli User Acceptance Testing acronimo “UAT”;

Le valutazioni dei parametri interni riguradano il livello della applicazione ed il livello dei dati, dove si riconoscono valutazioni atte a gestire i flussi dati tra i databases o come questi vengono trasformati nei passaggi tra sistemi. Ad esempio si pensi ai System Integration Testing acronimo “SIT”.

Tutti i metodi di validazione formale53 attribuibili ai diversi livelli di un applicativo, riconoscono nella valutazione dei requirements descritti nelle analisi, il superamento o meno della valutazione stessa e di conseguenza ad un rilascio del prodotto. Le attività finalizzate a determinare se un dato pro-

3.1 Introduzione al Performance testing

53 Il concetto di validazione formale si riferisce ad attività svolte a garantire che un prodotto indirizzi i requisiti originali quando viene utilizzato nell’ambiente per cui è destinato. La validazione consegue alle attività di testing.

63

dotto software soddisfa i requirements per cui è stato progettato sono chiamate “Performance Testing”. Queste hanno il compito di testare la funzionalità, la correttezza e la completezza di ogni singola specifica. Inoltre esse non hanno solo il compito di rilevare errori generici nel SW, ma verificare che esso soddisfi le specifiche prestazionali richieste in fase di esplicitazione dei requisiti.Ai fini della ricerca, si analizzano le caratterisitiche riconosciute nei metodi di validazione del livello di presentazione, ponendo l’accento sugli aspetti legati all’usabilità ed a quelle metodologie legate ai test UAT definite come test funzionali.L’approccio Performance Testing è formalizzato nella normativa IEEE 829-1983, in cui si identificano tre fasi di organizzazione: Test planning, Test specification, Test Reporting.

Il Test Planning corrisponde a quella serie di documenti che specificano gli obbiettivi del test, approcci al testing, le risorse previste, le tempistiche e le risorse umane. Esso identifica le features da testare e i tasks associati da svolgere.

Il Test Specification rappresenta la progettazione delle “Test Suite” divisa nelle:Specifiche di progettazione dei test in cui si individuano le componenti e le caratterisitiche del software da testare identificando i criteri di completamento e fallimento;Specifiche delle documentazioni dei testcase in cui si descrivono i dati di utilizzo nei singoli casi di test raggruppati in testbook o scenari di test;Specifiche per le procedure del test in cui si identificano i

54 Il test case è l’unità molecolare che fa parte di uno scenario di test relativo alla sezione da validare chiamato anche Testbook. Ogni test case è definito mediante una dicotomia divisa tra la descrizione del compito che l’utente deve compiere o task e il risultato atteso da quell’interazione.

64

compiti per completare ogni singolo caso di test;Test execution in cui si identifica la vera esecuzione dei singoli test case 54 da cui si riportano in un report i risultati dei dati attraverso variabili come defects, timing, o non soddisfamento del requisito.il Test Reporting corrisponde ad una serie di documenti o report con il ruolo di comunicare i risultati delle sessioni di test.

Il performance testing può essere utlizzato nel testare funzionalità legate a degli specifici compiti progettati a cui deve adempiere il software, mediante interazione attraverso i dispositivi di interfaccia.Si può dedurre che questa metodologia di test sia legata alla valutazione finalizzata a misurare l’efficacia, l’efficienza e l’usabilità dell’interfaccia utente e delle caratteristiche di fruizione in essa sviluppate.Pertanto si ritiene che in una creazione di un metodo utile alla valutazione delle visualizzazioni in ambito business intelligence questo approccio possa fornire strumenti congeniali alla definizione dell’utenza, del contesto e degli obbiettivi.L’analisi funzionale attraverso le specifiche dei requisiti, formalizza le tre caratteristiche fondamentali di misura di un software, dove:

l’ Utenza: viene definita nella fase di Test Plan, durante la descrizione dei profili di tester o di utente archetipico su cui si sono sviluppate le finalità del software;

65

55 Il difetto o defect nella valutazione rappresenta un probelma di sviluppo interpretativo del requirement. L’errore o bug rappresenta un malfunzionamento sistemico del software non della specifica.

66

il Contesto: viene definito nella fase di Test Specification, attraverso la descrizione delle tecnologie e degli scenari in cui il software deve essere validato;

l’obbiettivo: viene definito nel Test Specification e più precisamente nella fase delle “Specifiche per le procedure del test” dove si identificano i singoli compiti.

A conclusione del performance testing si crea un report che è un documento in cui vengono riportati i risultati della sessione di test, dichiarando solitamente dati di tipo quantitativo.Esempi di dati di tipo quantitativo possono essere il numero dei testcase passati e non passati, il tempo che l’utente ha impiegato per completare il task ed il numero di difetti e errori 55 riscontrati.Posson esistere anche dati di natura qualitativa come le descrizioni dei defects riscontrati.Nel prossimo paragrafo si descrivono dei test basati su metodologie qualitative utili al fine di definire una metodologia di applicazione nelle visualizzazioni di dati.

L’ usabilità come si è visto, è un requistio fondamentale nella progettazione di ogni software. Essa sottende a caratteristiche che possono essere ricondotte a specifiche funzionali: la soddisfazione di certi obbiettivi d’interazione portati a termine da specifici utenti in determinati contesti possono essere letti come requisiti e quindi essere oggetto di valutazione.

IMPLEMENTATION

ANALYSIS

DESIGN

EVA

LUATION

Product Backlog

Sprint

Sprint 2

Review

Specifiche Funzionali

Performance Test - Agile Scrum Testing un esempio

IMPLEMENTATION

ANALYSIS

DESIGN

EVA

LUATION

Sprint

Sprint 2

Testing

Rilascio

Performance Test - Agile Scrum Testing un esempio

Se nel capitolo 3.1 si è descritto un esempio di metodologia di valutazione con output quantitativo, questo capitolo vuole essere un’introduzione alle metodologie di valutazione basa-te su un approccio qualitativo.Nell’ambito della valutazione software si introduce il concetto di euristico. Con il termine “euristica” il vocabolario della lingua italiana Treccani definisce:

“Aspetto del metodo scientifico che comprende un insieme di strategie, tecniche e procedimenti inventivi per ricercare un argomento, un concetto o una teoria adeguati a risolvere un problema dato”

Nel 1994 Jackob Nielsen pubblica un articolo in cui definisce dieci linee guida per la buona progettazione di un’interfaccia utente: “Ten Usability Heuristics”56 : Visibility of system status, Match between system and the real world Consistency and standards, User control and freedom. Error prevention, Recognition rather than recall, Flexibility and efficiency of usem, Aesthetic and minimalist design, , Help users recognize, diagnose, and recover from errors, Help and documentation. Le linee guida così come la parola “euristico” vengono poi riprese in una altra definizione di Nielesen l’”Heuristic evaluation” dove un esperto di usabilità attraverso un approccio qualitativo, definisce i punti critici e le caratteristiche migliori e o peggiori di un prodotto57. In definitiva il termine rappresenta per Nielsen un insieme di processi non rigorosi, inventivi, intuitivi che assolvono il compito di valutare una UI.

3.2 Introduzione alla Valutazione Euristica

56 Jakob Nielsen, 10 Usability Heuristics for User Interface Design, 1994, www.nngroup.com/articles/ten-usability-heuristicsAccessed 10 May 2016;

57 Jakob Nielsen, 10 Usability Heuristics for User Interface Design, 1994, www.nngroup.com/articles/ten-u

69

58 Jakob Nielsen, Usability Inspection Methods, 1994

59 Jakob Nielsen, Usability 101: Introduction to Usability 2012, www.nngroup.com/articles/usabili-ty-101-introduction-to-usabilityAccessed 10 May 2016;

60 Jakob Nielsen, Usability Inspection Methods, 1994.Si riportano i nomi con cui queste tecniche vengono definite:

- Heuristic Evaluation;- Cognitive Walkthroughs- Formal Usability Inspections- Pluralistic Walkthroughs-Feature inspection- Consistency inspection- Standards inspection

Riprendendo lo stesso autore, si nota come sempre nello stesso anno, pubblicò un articolo in cui descrisse le sette tipologie di approcci inseriti nel metodo valutativo denominato Usabilty Inspection. 58 Di questa tipologia l’autore riportò come allora si dimostrasse la più efficacie anche in rapporto ai costi di gestione di utenti che non fossero esperti. Infatti la caratteristica fondamentale della Usability Inspection sta proprio nell’utente o tester che deve affrontare la valutazione dell’usabiltà di un software: egli è un esperto di usabilità oppure è un esperto nei flussi di business per i quali l’applicazione è stata sviluppata. Nielsen nel 2012 in un altro articolo riguardante il metodo da utilizzare per valutare un’interfaccia, riporta che uno dei metodi migliori sia il cossidetto “Usability Testing” che lo definisce così:

“There are many methods for studying usability, but the most basic and useful is user testing”59

L’Usability Test è concettualmente in contrasto rispetto all’ Usability Inspection, in quanto in questo test gli utenti non sono esperti di usabilità come designer o sviluppatori, ma una parte rappresentativa e disomogenea dei fruitori finali per cui è stato pensato il prodotto. L’autore danese in ultima analisi non definisce la supremazia di uno dei due metodi, ma suggerisce di utilizzarli entrambe poichè insieme si avrebbe una mgliore idea dei problemi di usabilità. Esistono differenti metodi di valutare un’interfaccia anche trasversali alle due tipologie sopra descritte, di seguito vengono riportate le più importanti 60.

70

Ai fini della ricerca si prende in considerazione quello che potrebbe essere condiserato il principale tra le sette tecniche di valutazione inspettiva proposte da Nielsen: l’Heuristic Evaluation. L’Heuristic Evaluation acronimo HE si descrive come una tecnica in cui un Utente Esperto di usabilità valuta una certa interfaccia al fine di trovarne dei problemi di usabilità in relazione alle dieci variabili euristiche. Una sessione di valutazione da parte di un esperto ha una durata limitata poichè tale utente non ha bisogno di training per affrontare l’interazione e conoscere le funzionalità dell’applicativo.La valutazione si compone di due fasi principali: una prima in cui l’utente interagisce con le funzionalità principali del software ed una seconda in cui si concentra su delle caratteristiche particolari che possono essere valutate separatamente. A tal proposito si pensi alla valutazione di una UI business dashboard in cui l’utente in un primo momento esplora le funzionalità esplicite ed in un secondo momento della valutazione si concentri sulle interazioni dedicate ad ogni singola visualizzazione.I tipi di risultati sono differenti ma seguono le dieci variabili euristiche. Ad esempio un risultato relativo alla prima linea guida euristica “Visibility of system status” ovvero la visione di informazioni riguardo lo stato dell’applicativo, potrebbe essere una serie di outputs in cui si valuta quali informazioni una dashboard comunica all’utente riguardo la sua esplorazione con il dato: una “history line” dell’interazione.In conclusione i tipi di outputs che si ottengono dalle tecniche di Usability Inspection sono in maggior parte di tipo qualitativo: commenti, idee, punti di vista, suggerimenti a

71

modifiche descritti direttamente da esperti di usabilità e che in qualche modo aiutano il progettista ad avere in tempistiche strette e spunti per procedere allo sviluppo del prodotto.Si ritiene questo approccio sia fondamentale ai fine della ricerca di un metodo da applicare alle visualizzazioni di dati in quanto la definizione di un utente che abbia caratteristiche tecniche, aiuta e controbilancia la tecnica del perfomance testing descritta qualche pagina addietro.Si conosce ora la possibilità di avere dei punti di vista differenti per avere una migliore comprensione dei punti di forza o di debolezza di un’interfaccia utente: si ritiene che avere a disposizione differenti utenti e differenti approcci alla valutazione può aiutare a descrivere meglio un fenomeno problematico ed ottenere informazioni diversificate per definire meglio una caratteristica funzionale.

72

Usability Inspection Methods

Usability Inspection Methods

Heuristic evaluation

Heuristic estimation

Cognitive walkthrough

Standards inspection Formal usability inspection

Feature inspection

Consistency inspection

Pluralistic walkthrough

Usability Experts

DesignerDevelopers

End Users

In questo paragrafo si vuole introdurre un aspetto, oggetto di controversia nella progettazione di infografiche, che viene riassunto in una domanda diretta:

“Quando una data-visualization si può definire efficace?”

Valutare l’efficacia di una visualizzazione di dati è un argomento ancora dibattuto tra gli esperti del settore. Si possono dividere due tipologie di pensiero: coloro che pensano che l’infografica debba essere decorazione contrapposti a coloro che pensano che essa debba essere funzionale senza essere decorativa.Si introdocuno a questo punto i due maggiori esponenti di questo pensiero Edward Tufte e Nigel Holmes.Prendendo come esempio la cosiddetta “ChurtJunk” da una definizione di Edward Tufte ovvero le visualizzazioni di dati in cui la decorazione (la “superficie” grafica che non porta informazioni basilari sul dataset) supera il rapporto 1.0 del “Data Ink Ratio,”61 possiamo dividere le visualizzazioni in due categorie: una più corretta e funzionale corrispondente alla Data Ink Ratio ed un’altra scorretta e poco funzionale alla comunicazione esatta del dato corrispondente alla Churtjunk.Il punto di vista di tale visione è ovviamente dettato dall’accettazione dei principi “tuftiani”.

3.3 Astrazione, Iconicità e ChurtJunk

61 Edwarde Tufte, The Visual Display of Quantitative Information, pag. 93

75

Data Ink Ratio

Total Ink use to print the graphic

Data Ink

Ma se cambiassimo prospettiva e mettessimo le emozioni ed il racconto come obbiettivo comunicativo quindi un approccio più simile a quello descritto da Nigel Holmes, potremmo verificare che anche tali visualizzazioni più emotive sono maggiormente funzionali alla memoria ed al ricordo. A tal proposito si faccia riferimento alla ricerca pubblicata nel paper “Useful Junk? The Effects of Visual Embellishment on Comprehension and Memorability of Chart”62. In tale ricerca condotta dal dipartimento di Computer Science dell’ università canadese di Saskatchewan vengono mostrati differenti visualizzazioni ad un gruppo di studenti, queste visualizzazioni sono dei due tipi descritti sopra, uno tuftiano in cui i dati vengono rappresentati in modo pulito e rigoroso e uno nigeliano in cui i dati vengono visualizzati mediante illustrazioni e raffigurazioni.

62 Saskatchewan Univeristy Useful Junk? The Effects of Visual Embellishment on Comprehension and Memorability of Chart, 2011

77

1978 1979 1980 1981 1982

$60,000

$50,000

$40,000

$30,000

$20,000

$10,000

Il risultato della ricerca riporta che gli studenti si ricordano maggiormente le visualizzazioni nigeliane, ovvero si denota una maggiore permanenza nella memoria del fruitore attraverso la lettura di visualizzazioni maggiormente decorative, in cui lo storytelling del dato acquista una più ampia personalità mediante un approccio grafico maggiormente figurativo .Tale controversia affonda le sue radici in diverse teorizzazioni esposte da critici dell’arte e teorici del design: dai primi scritti di Paul Klee63, alle teorizzazioni di Tomas Maldonado64, a Rudolph Arnheim65 ai più vicini in ordine temporale, Giovanni Anceschi66. Questi autori, nei loro scritti, pongono al lettore considerazioni di carattere formale sulla natura degli aspetti visuali intendendo questi

63 Paul Klee, Teoria della forma e della figurazione, 197664 Tomas Maldonado, Reale e virtuale, 199265 Rudolph Arnheim, Arte e percezione visiva, 197466 Giovanni Anceschi, L’oggetto della raffigurazione, 1992

78

come espressioni per lo più artistiche. Ora uno degli aspetti fondamentali è la cosiddetta opposizione astratto – figurativo: ogni opera visuale si pone tra questi due opposti, ha cioè una tendenza a essere catalogata come maggiormente astratta o maggiormente figurativa. Questa opposizione è riscontrabile nella scala iconica presentata da Abrham Moles così come in Manfredo Massironi, dove al massimo dell’astrazione corrisponde un livello di segni (semi) minimi con il referente, mentre al massimo dell’iconicità i senemi più condivisi con l’oggetto referente. Riprendendo gli ultimi sette livelli della scala iconica di Moles, possiamo notare come l’ultimo livello da egli teorizzato ovvero “l’astrazione perfetta” (che corrisponde al diagramma di Massironi e Bertin) possa corrispondere ai principi tuftiani delle visualizzazioni create secondo il Data Ink Ratio. E’ doveroso però rendere conto che la totale convenzione della lettura per una corretta comunicazione di tali visualizzazioni dipenda in realtà dalla creazione di un contesto in cui l’immagine viene inserita. Il contesto di rifermento che è uno dei principi per una corretta valutazione basata sull’UCD. Inoltre la stessa teorizzazione di Moles, in cui per tale livello di iconicità mancano i semi con il referente, si crede che non è del tutto una visione corretta. Le visualizzazoni di dati in quanto sistemi grafici che dipendono totalmente dal referente, rientrano più nel concetto di ipotetigrafia di Massironi che nella massima astrazione di Moles. L’ iconicità dipende dal contesto dell’immagine in cui viene inserita: al massimo grado di astrazione corrisponde una minore iconicità e quindi un maggior

79

grado di convenzione con il contesto, mentre al maggior grado di iconicità corrisponderà un minor rapporto con il contesto di riferimento. E’ chiaro quindi come le visualizzazioni di Holmes, siano indipendenti dal contesto in cui queste vengono inserite. Il pregio delle visualizzazioni nigeliane è così l’indipendenza comunicativa, ogni visualizzazione è contestuale a se stessa. Per spiegare meglio la dipendenza dal contesto bisognerebbe ricordare che nelle visualizzazioni nigeliane il cosiddetto “peritesto” ( paratesto + epitesto) è particolarmente presente come peso nell’intero campo visivo non solo come sfruttamento del campo, ma come epitesto cioè vincolante nell’informazione del testo vero e proprio.Secondo questo assunto la teoria emotiva o nigeliana vedrebbe il “contorno” come preponderante rispetto al cuore dell’informazione:

PARATESTO (PERITESTO + EPITESTO) > TESTO

E’ quindi auspicabile ai fini teorici un superamento delle teorie gestaliane in quanto seppur utili, si pongono come troppo strutturate di fronte alle visualizzazioni di dati business.I dati rappresentati sotto forma visiva nelle business dashboard rientrano in metafore visive fortemente convenzionalizzate e per questo inserite in un contesto operativo in cui il valore dell’efficacia non debba valutarsi secondo concetti gestaliani, ma applicando metodologie più

80

Nei precedenti paragrafi di questo capitolo si è introdotto il concetto di valutazione software applicato con metodologie differenti, da approcci strutturati ad approcci meno formali basati su osservazioni. Differenti metodologie che trovano i loro comuni obbiettivi nel valutare l’usabilità di un’interfaccia grafica prendendo in considerazione gli aspetti relativi alla funzionalità, all’efficienza, all’efficacia di una GUI.Si sono definiti i tre aspetti contestuali che devono essere presi in considerazione durante una valutazione che sottendono una visione User Centerd Design: l’utente, il contesto, gli obbiettivi.In ultimo si è introdotto il concetto di efficacia di una visua-lizzazione dati.Ben Shneiderman e Catherine Plaisant nel 2006 pubblicano un articolo67 in cui descrivono un nuovo paradigma valutativo dedicato alle datavisualizations. Per i due autori statunitensi le visualizzazioni di dati sono parte di un processo creativo che crea negli utenti la creazione di ipotesi:

“Information visualization is usually part of some creative activity that requires users to make hypotheses, look for patterns and exceptions, and then refine their hypothesis”

Si potrebbe affermare che non si tratta di un processo in cui bisogna portare a termine un determinato compito ed è per tale motivo che la valutazione delle visualizzazioni debba comportare una tecnica differente dagli Usability Test o dagli Usabilty Inspection che risultano forse troppo limitanti.L’idea generale è la creazione di una tipologia di test che sappia adattarsi a saper valutare non solo il tempo o gli errori

3.4 Oltre il tempo e l’errore

67 Ben Shneiderman, Catherine Plaisant, Strategies for Evaluating Information Visualization Tools:Multi-dimensional In-depth Long-term Case Studies, 2006

81

68 Purvi Saraiya, Chris North, Karen Duca, An Evaluation of Microarray Visualization Tools for Biological Insight.69 Catherine Plaisant, Promoting Insight Based Evaluation of Visualizations: From Contest to Benchmark Repository, 200470 www.hcil2.cs.umd.edu/trs/2004-30/2004-30.htm

per ogni task case, ma che possa essere di supporto ad altri tipi di valutazioni con altre variabili. Si veda ad esempio le ricerche affrontate da tre ricercatori della Virginia Polytechnic Institute and State University: avendo il compito di valutare quale software adottare tra cinque disponibili essi hanno definito una metrica basata sul riconoscimento degli Insight. L’Insight o ipotesi è categorizzabile per contenuto e misurabile per la quantità leagata a determinate funzionalità:

“A primary purpose of visualization is to generate insight .A measure of an effective visualization is its ability to generateunpredictable new insights that might not be the result of apreplanned benchmark task” 68

L’approccio basato su metriche Insights-based fu una tematica analizzata nei tre anni di conferenze InfoVis 2003 -2006 69

dove si affrontavano dei contest legati a diversi temi in cui si sarebbe valutato l’approccio ad una valutazione basata sullo sviluppo di insights. Tale argomento è ancora caldo e discusso come uno tra i topic nell’incontro annuale IEEE VAST:

“Evaluation methods, visual ethical analysis such as privacy, security, and regulatory compliance, interoperability, and technology practice and experience”70

Il nuovo paradigma dell’approccio MILCS si basa sull’applicazione di un metodo “Etnografico”, in cui il

82

valutatore attraverso osservazioni sul campo, osserva i comportamenti che l’utente compie durante l’interazione con il software in esame.Analizzando in dettaglio le caratteristiche principali di questa metodologia possono essere riconosciute in quattro fasi che si riportano in seguito.La prima fase detta di “Preparation” corrisponde a documentarsi sull’organizzazione o cliente in cui si dovrà operare.La seconda fase che è detta “Field Study” in cui il progettista stabilisce un rapporto con il cliente, recandosi presso di esso dove raccoglie dati quantitativi e qualitativi.La terza fase detta di “Analysis” in cui il designer analizza i dati raccolti in forma numerica o testuale e li interpreta.La quarta fase è detta “Reporting” in cui si prepara una relazione o report per comunicare i risultati.Bisogna ricordare al lettore che nel ruolo del valutatore, quest’ultimo è un progettista e non un antropologo, per cui vi sono delle peculiari differenze:un designer a differenza di un antropologo, si concentra a porre domande e osservare sui propositi dell’interfaccia utente e non si immerge nella cultura e nel mondo del cliente. Un’altra caratteristica divergente è il tempo a disposizione: il designer rimane sul campo per poco tempo, si pensi ad ore piuttosto che giorni, l’antropologo rimane sul campo per giorni o mesi.L’utente presunto in questa metodologia è un utente esperto del dominio della valutazione. Egli conduce il progettista nei workflow di business esponendo il proprio punto di vista durante l’interazione con il tool.

83

In conclusione si è voluto introdurre il sistema MILCS come esempio di una metodologia di valutazione che potrebbe essere considerata ad alto livello: l’approccio etnografico consente al progettista di definire delle linee guida da avere con l’utente, dove le singole tecniche canoniche dell’usability inspection o del test possono essere utilizzate in modalità varie: ad esempio potrebbero essere utilizzate il Cognitive Walkthrough e il Performance Testing insieme. La convertibilità delle tecniche potrebbe essere vista come il grande vantaggio della metodologia, in quanto la progettazione attenta e attiva, basata su questo particolare approccio osservativo sembra ad una prima analisi un buon riferimento per la valutazione delle visualizzazioni dati in ambito business.

84

3.5 Oltre le metodologie

Nel 2014 cinque ricercatori provenienti da università francesi, tedesche, statunitensi, canadesi e da Google, pubblicano i risultati di una loro ricerca nell’articolo “Empirical Studies in Information Visualization: Seven Scenario” 71. Il proposito di questa ricerca è riuscire a proporre un metodo di valutazione delle information visualizations incentrato su determinati scenari:

“instead of focusing on evaluation methods, we provide an in-depth discussion of evaluation scenarios, categorized into those for understanding data analysis processes and those which evaluate visualizations themselves”

Gli scenari descritti sono da leggersi come degli insiemi di tecniche che sottendono a delle metodologie come quelle esposte nel capitolo 3 di questo scritto.Presumibilmente, gli scenari sono una risposta coerente con la complessità che un progettista deve valutare. La scelta di uno o più scenari deve essere subordinata agli specifici obbiettivi:

“...Our goal is to provide an overview of different types of evaluation scenarios and to help practitioners in setting the right evaluation goals, picking the right questions to ask, and to consider a variety of methodological alternatives to evaluation for the chosen goals and questions”

Sembra chiaro come le tecniche di valutazione siano subordinate agli “Evaluation Goals” o obbiettivi delineati in differenti ambiti di un software: dagli aspetti di ricerca delle

71 Heidi Lam, Enrico Bertini, Petra Isenberg, Catherine Plaisant, Sheelagh Carpendale, Empirical Studies in Information Visualization: Seven Scenarios, 2014

85

72 D.Stone, C.Jarrett, M.Woodroffe, S.Minocha, User Interface Design and Evaluation, 2005

informazioni, agli aspetti dell’interazione, agli aspetti di visualizzazione.Si crede che questo approccio Scenario-Based possa essere efficacemente adottato per delineare una prima proposta di tecniche da applicare durante le analisi valutative.Qui in seguito vengono riportati gli scenari di riferimento concernenti gli ambiti di applicazione; essi sono divisi in due principali aree di ricerca:

process: gli scenari che riguardano i processi di business, in cui vengono valutati gli aspetti relativi ai workflow aziendali;

visualization: gli scenari che riguardano gli aspetti delle singole visualizzazioni e di come queste vengono capite ed esplorate.

Questi scenari sono da considerarsi come esempi nella creazione di un protocollo di valutazione che tenga conto della definizione, degli obiettivi e delle metodologie. Una volta definiti gli approcci e descritte le metodologie che si vogliono applicare con relativi riferimenti e casi studio si passa alle attività di pianificazione, creazione, compilazione del cosiddetto protocollo di valutazione acronimo EP 72.Segue nelle prossime pagine una breve descrizione per ogni scenario.

86

Gli scenari di Process sono volti a valutare il processo di interazione con l’interfaccia e le visualizzazioni, avendo un’idea della user experience dell’utente. In questo insieme si possono riconoscere quattro scenari: Understanding Environments and Work Practices, Evaluating Visual Data Analysis and Reasoning, Evaluating Communication through Visualization, Evaluating Collaborative Data Analysis. In seguito vengono descrititi in linea generale.

UWP - Understanding Environments and Work Practices

Dal titolo si può capire come il progettista da tale scenario dovrebbe essere in grado di ottenere informazioni riguardanti l’ambiente e dei flussi di lavoro dell’utente. Tale metodologia è utile per capire gli obbiettivi di progetto nelle prime fasi come nel riconoscimento dei requisiti attraverso un approccio che si possa definire etnografico. L’obbiettivo di questa tipologia di tecniche rientra nel più ampio contesto per capire le principali funzionalità di un software basato sulle visualizzazioni dati. Nel caso in cui il prodotto sià già stato rilasciato, questo approccio può essere utile per definire le carenze del software sviluppato ai fini degli obbiettivi iniziali: il confronto tra le specifiche iniziali e la correttezza dei flussi di lavoro durante l’interazione.

Ai fini teorici e di categorizzazione, ad ogni scenario sono dipendenti delle domande generali a cui lo stesso dovrebbe essere uno strumento di risposta. Ad esempio per l’UWP,

Process scenarios

87

i quesiti sottesi sono riconducibili ai seguenti obbiettivi:

Riconoscere il contesto di utilizzo del software;Riconoscere le attività quotidiane in cui lo strumento dovrebbe essere integrato;Riconoscere le tipologie di analisi per cui lo strumento dovrebbe essere utilizzato;Riconoscere quali altri tipi di software sono utilizzati dagli utenti nel proprio ambiente di lavoro;Riconoscere criticità che il software potrebbe creare nei flussi di lavoro ad esempio con l’utilizzo di altri software.

Le tecniche utilizzate per riconoscere l’ambiente di lavoro sono tecniche di tipo qualitativo basate su approccio etnografico: ad esempio “Osservazioni sul Campo”, “Interviste”, “Registrazioni”, “Materiale Scritto”. Esempi di questo tipo di approccio possono essere riconosciuti nei test effettuati nel 2004 dalla University of California proponendo una serie di compiti da portar a termine su differenti tool a titolo comparativo per capire quale tool fosse condiserato più comprensibile agli obbiettivi lavorativi 73.

VDAR – Evaluating Visual Data Analysis and Reasoning

Tale metodologia è utile per capire se uno strumento di visualizzazione già sviluppato e utilizzato, come sia capace di portare al ragionamento l’utente durante l’esplorazioni dei

73 Alfred Kobsa, User Experiments with Tree Visualization Systems, 2004.

Treemap 3.21 software, vrs 2004

SequoiaView, vrs 2004

88

dati visuali.L’obbiettivo di tali insieme di approcci è definire quanto e come il software utilizzato permette l’analisi dei dati e il conseguente ragionamento attraverso l’esplorazione delle visualizzazioni. I risultati sono metriche quantificabili, come ad esempio il numero degli “insight” che una determinata visualizzazione ha prodotto il ragionamento degli utenti in fase di analisi, o opinioni personali riguardo la qualità dell’esperienza di analisi. Per tale motivo la valutazione è complessiva all’intero strumento e non alla singola visualizzazione. A tal proposito VDAR sarebbe maggiormente utile a definire problematiche di user experience dell’intero strumento nell’ottica di una nuova versione o aggiornamento.Le domande di ricerca di questo approccio si possono identificare nelle seguenti:

Riconoscimento dei processi di selezione, filtraggio e lettura dei dati all’interno di un ciclo interattivo;Riconoscimento dei processi di analisi del fenomeno; Riconoscimento dei processi di generazione delle ipotesi;Riconoscimento dei processi che l’utente compie dopo aver analizzato i dati;

Le valutazioni con l’approccio VDAR sono tipicamente studi sul campo per lo più in forma di casi studio. Essi sono metodi che mirano a studiare l’utilizzo del software nell’ambiente di lavoro con compiti realistici ed utenti esperti, esistono tuttavia approcci studiati e valutati in ambiente di laboratorio.

89

Si possono riconoscere le tecniche più utilizzate in questo tipo di scenario nelle seguenti: “Raccolta osservazioni” ed “interviste”.Esempi di questo tipo di approccio possono essere riconosciuti nei test effettuati nel 2000 dal HCI Laboratory, Naval Research Laboratory, proponendo una serie di compiti da portar a termine su un’unica dashboard operativa di ambito meteorologico: COAMPS-OS® DASHBOARD 74.

CTV – Communication through Visualization

Lo scenario CTV ha il compito di valutare come una deteminata visulizzazione può sostenere una certa comunicazione. La comunicazione è qui intesa come fattore informativo che permette all’utente, mediante l’interazione con la UI di apprendere, capire e presentare meglio fenomeni complessi attraverso visualizzazioni di dati.Gli studi CTV sono spesso intesi per quantificare delle metriche qualitative di apprendimento delle informazioni relative allo strumento utilizzato dagli utenti.Le domande di ricerca di questo approccio si possono identificare nelle seguenti: Riconoscimento del processo di apprendimento delle informazioni visive rispetto ad un altro tool o artefatto non digitale;Riconoscimento di output e reportistica come supporto alla comunicazione e dati verso esterni;Si possono riconoscere le tecniche più utilizzate in questo tipo di scenario nelle seguenti: “Raccolta osservazioni” ed “interviste”.

74 Gragory Trafton, Turning pictures into numbers: extracting and generating information from complex visualizations, 2000.

Coamps-Os Dashboard

90

CDA – Evaluating Collaborative Data Analysis

Le valutazioni nel CDA studiano quando uno strumento permette l’analisi collaborativa nei processi decisionali. Questa tipologia di analisi collaborativa è differente rispetto a quella mono-utente per il fatto che gli utenti condividono le esperienze di analisi dei dati avendo un obiettivo comune.All’interno di tale approccio si valuta se il gruppo ha portato a termine un compito e in quale modo.La difficoltà consiste nel ricavare implicazioni progettuali concrete dalla comprensione euristica del lavoro di gruppo: aumentando il numero di utenti aumentano il numero di variabili che il ricercatore deve prevedere in considerazione per la valutazione.Le domande di ricerca di tale metodologia sono le seguenti:

Riconoscimento della collaborazione degli utenti attraverso lo sturmento;Riconoscimento delle tecniche di comunicazione tra gli utenti attraverso il tool;Riconoscimento del processo di analisi utilizzato dagli utenti in gruppo;Riconoscimento di esigenze comuni a tutti gli utenti.

Si possono riconoscere le tecniche più utilizzate in questo tipo di scenario nelle seguenti: “Raccolta osservazioni” ed “Pluralistic walkthrough” 75.

75 Carl Gutwin, Saul Greenberg, The Mechanics of Collaboration: Developing Low Cost Usability Evaluation Methods for Shared Workspaces, 2004

91

Gli scenari di Visaulization hanno l’obbiettivo di valutare il processo di interazione delle visualizzazioni, cercando di capire caratteristiche positive e negative nella singola visualizzazione. In questo insieme si possono riconoscere tre scenari: Evaluating User Performance, Evaluating User Experience, Evaluating, Visualization Algorithms. In seguito vengono descritti in linea generale.

UP – Evaluating User Performance

Le prestazioni degli utenti sono misurate in variabili quantitative come il tempo e il tasso di errore. Le metriche più comunemente usate sono quindi Timing ed Accuracy (errors). I risultati sono generalmente valori numerici analizzati utilizzando medie statistiche. Le domande di ricerca a cui risponde tale approccio sono le seguenti:

Riconoscimento dei limiti temporali nel completamento di tasks definendo il Best Cases e il Worst Cases; Riconoscimento del numero degli errori nel completamento di tasks definendo il Best Cases e il Worst Cases;

Si possono riconoscere le tecniche più utilizzate in questo tipo di scenario nelle seguenti: “Performance Testing” ed in generale le tecniche di “Usability testing” 76.

76 Catherine Plaisant, The Challenge of Information Visualization Evaluation, 2004

Visualization scenarios

92

UE – Evaluating User Experience

Questi tipi di metodologie riguardando lo studio degli utenti attraverso osservazioni di interazioni con le visualizzazioni per un breve o un lungo periodo di tempo. Le valutazioni sono delle metriche soggettive composte dalle reazioni dei singoli utenti di tipo qualitativo. I dati raccolti dai ricercatori possono essere riferibili ad ogni fase della progettazione della visualizzazione dagli schizzi progettuali al prototipo fino al primo rilascio del software.Le domande di ricerca di tale metodologia sono le seguenti:

Riconoscimento delle caratterisitiche della visualizzazione migliori e peggiori;Riconoscimento dei processi di interazioni funzionali ai processi di business;Riconoscimento di limiti comunicativi delle visualizzazioni nella comunicazione a terzi.

Si possono riconoscere le tecniche più utilizzate in questo tipo di scenario nelle seguenti: “Cognitive walkthrough”, “Heuristic evaluation” ed “Usability Testing”.Si veda come esempio le attività di test portate avanti da Shneiderman, nella valutazione mediante la tecnica dell’ Usability Testing del tool Similan basato sulla visualizzazione di temporal categorical records77.

77 Krist Wongsuphasawat , Ben Shneiderman, Finding Comparable Temporal Categorical Records:

Similan UI

93

VA – Visualization Algorithms

Con questo scenario sono definite delle tecniche che hanno il compito di ottimizzare la visualizzazioni dei dati.Le valutazioni di algoritmi di visualizzazione mirano a esplorare i limiti e il comportamento dell’algoritmo in base alla dimensione dei dati, la complessità dei dati, casi particolari.Prestazioni è indicato in termini di efficienza computazionale, la qualità di visualizzazione viene calcolata attraverso la definizione di una serie di parametri, si veda ad esempio il caso degli “Stress Test”.Le domande in questo scenario di solito riguardano l’efficacia o l’efficienza computazionale con la quale il dato è rappresentato. Domande di ricerca tipiche in questo campo sono:

Riconoscimento di limiti prestazionali della metafora visiva rispetto a casi limite.

Le tecniche asserribili a questa tipologia di scenario possono essere gli “Usability Test” in cui sono previsti dei test case in cui l’utente deve portare ai limiti la visualizzazione: mediante manipolazioni attuative, in cui si cambia la base dati è possibile vedere se la metafora sia ancora funzionale.

94

Progettare una valutazione

?!

““

...to choose the right variables to evaluate to pick the right tasks, users or data sets to test

and to pick appropriate evaluation methods....

H.Lam et all, 2006

Questo capitolo è dedicato alla descrizione del progetto di valutazione svolto durante l’attività di ricerca tesi.Come si è visto la scelta di un metodo di valutazione dipende da diversi fattori riconducibili ai tre cardini dell’approccio UCD: l’utente, il contesto, l’obbiettivo. Inoltre vi sono altri fattori di scelta che non devono essere considerati secondari, ma letti in una visione più operativa e inserita nel contesto delle logiche di business del cliente: ad esempio si pensi a dei limiti di natura economica dedicati allo sviluppo del progetto, alle tempistiche che concorrono alla valutazione delle releases e alle risorse umane da poter impiegare. Questi limiti progettuali presenti in un approccio customer oriented, non devono essere letti in un’ottica costrittiva, ma piuttosto pensati per essere perno al fine di una progettazione più consona alle esigenze del cliente, riferibile ad un approccio button up.Si ritiene che questi fattori implichino la costruzione di un metodo di progettazione della valutazione che possa essere duttile: progettare una metodologia applicabile implica delle scelte da parte del progettista che ha una visione ampia delle tecniche disponibili e dei tipi di risultati che si possono ottenere, riuscendo a definire un metodo customizzato.Valutare un software con cui gli utenti interagiscono attivamente prendendo decisioni attraverso delle visualizzazioni di dati interattive, comporta che il progettista abbia ben presente le variabili sopra descritte al fine di scegliere le tecniche più congeniali alla buona progettazione di un ciclo di test.Il software servito come case study nella costruzione di un protocollo di valutazione, rientra nelle caratterisitiche che lo

4. Progettare una valutazione

99

possono definire come una business dashboard.Sphaera, è il nome che si è adottato per il software ed è stato sviluppato nel corso del 2015 da Density Design Lab., laboratorio di ricerca della Facoltà di Design della Comunicazione del Politecnico di Milano, per conto del cliente SI Hotels S.c.p.A. facente parte del marchio commer-ciale Besteam S.c.p.A..Sphaera fa parte di un sistema di strumenti B.I. che SI Hotels mette a disposizione ai soci, per aiutarne la gestione degli alberghi nelle scelte strategiche e commerciali ad esempio nelle politiche di pricing delle camere. Direttamente dalla pagina dedicata del sito di SI Hotels si può leggere questa frase che caratterizza la Vision degli strumenti progettati ambito B.I.:

“Sphaera è un sistema di gestione del business alberghiero che integra i software di PMS (Property Management System), Business Intelligence, CRM (Customer Relationship Management) e di analisi della customer journey per dare ordine alla molteplicità dei dati ed effettuare analisi e valutazioni sull’andamento della struttura alberghiera” 78

Al rilascio della prima versione dello strumento si sono definite in modo condiviso con il cliente delle attività di valutazione dello strumento, avvenute nei mesi di Aprile e Maggio 2016.Questo capitolo ha il compito di descrivere tali attività di testing portate come esempio di valutazione sperimentale nell’ambito delle visualizzazioni di dati.

78 www.sihotels.it/soluzioni-ho-tels/soluzioni-si-performance/Accessed June 2016

100

4.1 Una dashboard per l’ospitalità

La dashboard Sphaera fa parte di un sistema di strumenti di business intelligence sviluppati da SI Hotels S.c.p.A. per consentire a figure professionali come revenue manager, gestori alberghi, consulenti attività customer pricing e marketing di analizzare i dati del prorpio hotel attraverso una serie di funzionalità che permettono una migliore e attenta gestione delle proprie politiche di business.Il progetto Sphaera è composto da due differenti tipologie di software dashboard, una dashboard di tipologia strategica e una dashboard di tipologia analitica. Questi software sono pensati per lo stesso target di rifermento, ma con funzinalità differenti: la BD strategica è progettata per dare una rapida visione, chiara e quotidiana dei KPY, mentre la BD analitica prevede che l’utente possa esplorare i KPY analizzando i dati attraverso una interazione delle visualizzazioni, dettagliata e customizzabile a secondo delle necessità dell’utente stesso. L’ immagine qui sotto, riporta un esempio di UI ripresa dal software “Qlik® Sense Desktop” adottato per sviluppare la B.I. Analitica.

101

79 S. Few, Information Dashboard Design - The effective visual communication of data, 2006, pag. 3280 Si veda la tabella Codici SICTabella di identificazione settori merceologici - cod. 7000

La B.I. Cognitiva è da considerarsi strategica in quanto le diciotto sottosezioni divise per le quattro principali rappresentano un numero di KPY non modificabile dall’utente: le anagrafiche dati sono state scelte al fine di rendere più diretta una visione delle più importanti variabili attività commerciali. I dati sono utilizzati al fine di enfatizzare misure prestazionali mediante valutazioni di perfomance come il positivo ed il negativo. Questa composizione rientra nella descrizione di Strategic dashboard teorizzata da Few79.

Descrizione FunzionaleCome si è già esplicato il prodotto B.I. Sphaera Cognitiva è una dashboard strategica, software progettato per operare nel settore merceologico italiano dei Servizi Vari - Alberghi 80.L’artefatto è stato progettato come software customizzato per il cliente cioè sviluppato in modo innovativo nella sua architettura Multi-tier con Back-end tier, Middle-tier, Front -end tier sviluppati in modo innovativo. Il tool si può definire multipiattaforma grazie alla sua tecnologia web based che gli garantisce di essere utilizzato su differenti browsers. Per quanto riguarda le tipologie di anagrafiche dati utilizzate, esse possono essere sia quantitative che qualitative.Alla fine di definire i taxa relativi alla tipologia Data Domain presente nella proposta tassonomica si può notare come questi siano assimilabili a differenti domini di competenza come il settore Sales, Finance, Marketing. Analizzando la User Interface si nota come sia suddivisa in quattro sezioni principali, in cui l’utente una volta registrato, può selezionare la sezione voluta con l’interazione

102

presente nel vertical menu navigation, posizionato sulla sinistra dello schermo.

Le sezioni sono denominate “Sintesi”, “Oggi”, “Storico”, “Previsionale”.Una volta che l’utente si sia registrato, abbia cioè inserito le credenziali di accesso mediante form web all’http di log dedicato, accede alla dashboard mediante la prima scherma-ta detta di “Sintesi”.La sezione di Sintesi è composta da tre sottosezioni presenti nella stessa schermata corrispondenti al “Fatturato Giornaliero” ,“Storico” e “Previsionale”. Si riconoscono i seguenti elementi su schermo: elementi ver-bo-numerici come le percentuali e i valori economici, datavisualizations riconducibili alla tipologia Area Graph - Quantitative Smooth 81. L’utente è abilitato ad interagire con le Area Graphs, selezionando i line point al fine di ottenere ulteriori informazioni dalla lettura del tooltip.Un altro elemento grafico presente nella schermata è l’icona

81 Robert L. Harris, Information Graphics: A Comprehensive Illustrated Reference, 1999

103

avente la funzionalità di segnalare le previsioni meteo.In questa sezione l’utente ha a disposizione degli strumenti utili ai fini di avere un quadro quotidiano del fatturato giornaliero in relazione a specifiche variabili temporali.La sezione “Oggi” è composta da due visualizzazioni interattive, riconducibili all’Arch Diagram e allo Scatter Plot oriented.

La sottosezione visualizzata mediante l’Arc Diagram è dedicata alla visualizzazione del numero e della tipologia di prenotazioni delle camere della struttura. Gli estremi dell’arco rappresentano le date di rifermento per una prenotazionesingola, il colore la tipologia di prenotazione mentre l’altezza tra il punto medio della corda e il punto medio della saetta corrisponde al valore economico.Nello screenshot in seguito viene riportata l’immagine della sottosezione successiva all’Arc Diagram, con grafico di tipologia asseribile allo ScatterPlot.

104

In questa sotto sezione definita di “Dettaglio” l’utente è in grado di ottere maggiori informazioni riguardo il numero delle prenotazioni divise per giorno e la durata di soggiorno. Questi due tipi di visualizzazioni possono essere inserite ai fini tassonomici nel taxòn Schemi Ordinali. Proseguendo nella breve descrizione funzionale, si descrive la sezione “Storico”.

105

Come si può notare, nello screenshot dell’applicativo riportato sopra, l’utente è abilitato a cambiare il periodo di riferimento dei dati, mediante la selezione dal menù a tendina presente nella frase d’introduzione alla sezione.La selezione delle voci temporali corrisponde ad una manipolazione ostensiva di secondo livello, in quanto una volta selezionate cambiano le variabili temporali modficando l’aspetto del fenomeno visualizzato.La folder è costituita da due sottosezioni: “Andamento del fatturato” e “Distribuzione del fatturato per categoria”.La sezione “Andamento del fatturato” è caratterizzata da una visualizzazione line graph adibita a confrontare gli andamenti del fatturato tra due periodi di tempo similari.La seconda sezione “Distribuzione del fatturato per categoria” è a sua volta divisa in cinque sotto sezioni denominate “Fatturato Totale”, “Classe di Servizio”, “Tipo di Garanzia”, “Paese di Provenienza”, “Tipologia di Tariffa”. Le cinque sottosezioni sono descritte visivamente mediante l’utilizzo di grafico Bubble Charts in cui le dimensioni di ogni singolo cerchio corrispondono a dei valori quantitativi definiti dal tipo di categoria a cui appartegono.

106

Si noti come i colori siano utilizzati al fine di definire uno stato negativo o positivo cognitivamente facile da capire.I colori così come il suo valore tonale, la dimensione del grafico e la forma come nell’area graph, sono da considerarsi delle variabili visive che concorrono anch’esse a definire un taxa proprio. Ogni visualizzazione ha un set di proprietà di variabili con cui il grafico cambia a seconda della variabile, si pensi alla Dynamic Properties di D3.js che ha la funzione di recuperare i dati precedenti ad un evento consentendo di ricalcolare le proprietà senza rebinding82.L’ultima sezione della B.I. Sphaera Cognitive riguarda l’analisi previsionale del fatturato, divisa in tre sezioni principali: “Confronto previsioni periodo passato e periodo corrente”, “Distribuzione del fatturato per categoria”, “Il tuo Pricing”. Nella prima sezione viene visualizzato il confronto del fatturato previsionale in termini economici diviso per categoria di prenotazione. La metafora visiva utilizzata è rappresentata da due area graph allineati verticalmente ed è possibile avere maggiori informazioni attraverso un tooltip a comparsa.

82 www.stackoverflow.com/que-stions/18205034/d3-adding-da-ta-attribute-conditionally

107

La seconda sezione “Distribuzione del fatturato per categoria” riprende le caratteristiche funzionali dello “Storico”.Nella terza sezione “Il tuo Pricing” si identificano i prezzi delle camere a notte applicati nell’hotel in confronto con il prezzo medio dei competitor ed altre tipologie di dati qualitativi come il tempo meteorologico previsto e gli eventi previsti vicino alla struttura.Con quest’ultima visualizzazione si pone l’utente in condizione di essere in possesso di uno strumento che riassuma e faciliti la fruizione di informazioni che altrimenti sarebbero sparse in altre innumerevoli fonti. Il concetto qui espresso è riferibile alle teorie di “Data Quality” intendendo in linea generale il concetto dell’affidabilità e normalizzazione di dati provenienti da fonti esterne.

108

Sotto l’aspetto di interazione con i dati e le visualizzazioni, il software vista la sua natura strategica offre una esperienza utente che ricalca una fruizione maggiormente incentrata sulla facilità di comprensione dei fenomeni visualizzati. Per tale motivo la gestione da parte dell’utente dei dati è limitata alla selezione di filtri di carattere temporale e categoriale: il taxòn filter descritto in questo testo può essere letto come un buon esempio di manipolazione che l’utente può effettuare durante l’esplorazione dell’interfaccia.Grazie ad una descrizione funzionale dell’applicativo è pos-sibile capire quali possano essere le caratteristiche che rientrino in un piano di valutazione: una descrizione delle funzionalità e delle caratteristiche interattive, potrebbe essere una base di partenza per inquadrare quegli aspetti più prioritari oggetto di valutazione. Si pensi ad una progettazione di innovativi grafici: in questo caso il compito di una valutazione sarebbe valutare l’efficacia, l’efficienza e l’usabilità di questa innovazione.

109

In conclusione una descrizione funzionale deve essere considerata parte fondamentale per qualsiasi tipo di valutazione: da una parte per visione prioritaria delle funzionalità e gli elementi da valutare, dall’altra al fine di creare una documentazione che possa essere condivisa con il cliente al fine di aumentare la visibilità e lo scambio di feedback per una corretta progettazione della valutazione.Nel prossimo paragrafo si descrive quale tipo di piano di valutazione si è creato e quali sono stati gli obbiettivi, i bisogni dell’utente e la metodologia.

110

4.2 Verso una proposta metodologica

In questo paragrafo si dscrivono in linea teorica le fasi del progetto di valutazione della dahboard B.I. Sphaera Cognitiva supportate da motivazioni ed esempi.La prima domanda che si è posta è stata come affrontare una valutazione di una dashboard di controllo dati. Avendo presente in linea generale le metodologie adibite alla valutazione dei campi relativi ai software e alle visualizzazioni, l’attenzione si è spostata su questi grandi insiemi di tecniche che in questo scritto si sono citate.La scelta di una o dell’altra tecnica non è stata frutto di determinanti quali l’esperienza passata con l’applicazione di tali metodologie, ma piuttosto dettata da scelte volutamente consapevoli nella ricerca di un approccio User Centered che se utilizzato con consapevolezza avrebbe offerto dei buoni spunti nella scelta di un protocollo di valutazione. Un obbiettivo del progetto è riconoscibile in quello che sarebbe stata la creazione di un protocollo che potesse assumere i valori di verificabilità e ricreabilità nei contesti di valutazione delle visualizzazioni di dati.Questa implicazione ha comportato una certa predisposizione a conoscere gli aspetti di progettazione che potessero essere più consoni con le metodologie utilizzate in ambito business: nella miriade di logiche che possono essere usate, vi è stata la ricerca di metodologie che in qualche modo potessero rappresentare dei “ponti disciplinari” tra tecniche più formalizzate dell’ambito software development e quelle considerate con approcci maggiormente qualitativi proprie della disciplina del Design.

111

Dopo aver analizzato il prodotto, il passaggio successivo è stata la ricerca di informazioni utili e già condivise con SI Hotel riguardo la documentazione funzionale al fine di una definizione dei focus che avrebbero dovuto riguardare le attività di testing. Per volontà del cliente questo approccio formale, basato sulla creazione di analisi delle specifiche funzionali e tecniche non è stato formalizzato. Il cliente ha volutamente saltato questi passaggio in quanto conscio di applicare una metodologia di sviluppo veramente AGILE, legata ad un continuo scambio di feedback che potessero essere basilari per una buona riuscita del prodotto. Questo ha comportato la non formalizzazione dei requisiti e di conseguenza una maggiore difficoltà nella ricerca di test features da inserire nel processo di valutazione.La ricerca e verifica dei requisiti funzionali sono stati gli obbiettivi iniziali della valutazione al fine di focalizzare ulteriori scopi. Per una prima definizione degli obbiettivi si sono svolte delle prime attività di ricerca degli archetìpi utente mediante interazioni con cliente Best Western Italia S.c.p.a. .Il processo di definizione degli utenti è stato un risultato conseguito da attività di interazione con gli stakeholder del progetto: da una prima proposta utente interna al Laboratorio di ricerca Density Design alla condivisione di questa e suo riallineamento avvenuta durante il primo incontro in SI Hotels S.c.p.a. con il Direttore Amministrativo e il Responsabile IT.Si descrivono in seguito i risultati dello studio condotto per la definizione degli utenti con la descrizione delle Personas.

83 D.Stone, C.Jarrett, M. Woodroffe,S.Minocha, User Interface Design and Evaluation, 2005

112

Utenti

Lo User Centerd Design, si propone di porre l’utente del prodotto al centro degli studi per la prototipazione dell’artefatto. Nelle metodologie di progettazione tale approccio è considerato come etnografico: infatti l’utente è studiato nel suo contesto di lavoro, nelle sue abitudini, cercando di trovare delle caratteristiche che possano essere utili a definirne i bisogni che il prodotto deve soddisfare. Si sono identificati tre utenti reali che corrispondono alle esigenze di profilazione al prodotto B.I. Sphaera cognitiva.Gli utenti sono stati riconosciuti in base ai profili Persona presi in esame durante la condivisione degli obbiettivi nel primo incontro in Best Western Italia S.c.p.a.: figure manageriali che rispondessero a delle caratteristiche come la proattività e una ottima capacità di comunicazione, ma soprattutto in base a delle caratteristiche background di conoscenza di flussi di business e dimestichezza a lavorare su piattaforme B.I..Si tratta di fruitori con alte competenze tecniche e manageriali, queste caratteristiche confermano che software come le business dashboard sono progettati per profili di questo genere.Gli utenti considerati rappresentano le tre tipologie in cui dividere i fruitori degli applicativi B.I. Sphaera: Basic User, Advance User, Expert User. Si delinea in questo modo una strategia di valutazione di tipologia Usability Test di cui l’idea iniziale è far testare la B.I. Sphaera Cognitiva senza che gli utenti l’abbiano mai utilizzata, in modo che non esista un determinato vantaggio durante la prima interazione.

76 I profili Persona sono descrizioni di caratteristiche archetipiche di utenti di un prodotto reale. Si veda a tal proposito il lavoro ancora attuale Henry Dreyfuss descritto da Alvin R. Tilley, The Measure of Man and Woman: Human Factors in Design, 1993

113

Utente Basic

Nome e Cognome: Giovanni BrambillaEtà: 50Professione: Resident Manager Struttura: Hotel Best Western in Milano

Descrizione MansionePer utente Basic si intende quella tipologia di utilizzatore del software che conosce i flussi di lavoro e i key performance indicators, ma non ha maturato delle competence specifiche nell’utilizzo di strumenti di business intelligence. Il signor Brambilla è considerato un utente basic. Egli lavora nella mansione di resident manager da circa trent’anni in un ruolo manageriale che è subordinato solo al Direttore dell’albergo: il resident manager è il responsabile dei dipendenti della struttura, della comunicazione con i fornitori e svolge attività di ausilio al direttore generale dell’hotel. Tra i compiti lavorativi che si contemplano al resident manager vi è la pianificazione delle strategie di business, la definzione e l’aggiornamento di tutte le politche di pricing e marketing che possano offrire competivitità dell’hotel in nuovi mercati.

Obbiettivi valutazione strumentoIl sig. Brambilla non ha particolari esperienze nell utilizzo di strumenti di gestioni dati. Egli utilizza devices come smarthphone, personal computer, dove utilizza strumenti come Microsoft Word ed Microsoft Excel in compiti di mansione e di offerta del revenue. L’obbiettivo di testare

114

l’applicativo insieme ad un utente Basic si incentra nella ricerca della comprensione e nella lettura di un software basato su visualizzazioni di dati, che non fa parte delle skills culturali dell’utente.Inoltre è interessante notare come un confronto tra i due applicativi B.I. Sphaera possa dare importanti informazioni su strategie di formazione ponderate in base al tipo di risposta che l’utente vuole ottenere.

115

Utente Advance

Nome e Cognome: Maurizio ScolaEtà: 40Professione: General ManagerStruttura: Best Western in Chieti

Descrizione MansioneMaurizio lavora da dieci anni in mansioni manageriali legati al settore alberghiero, attualmente è il General Manager dell’ albergo abruzzese. La sue attività come amministratore riguardano lagestione del personale, la definizione quotidiana di strategie di pricing e controllo revenue giornaliero.

Obbiettivi valutazione strumentoIl Sig. Maurizio utilizza tutti i giorni appena arrivato in ufficio il software B.I. Sphaera Analitica ai fini di controllo e gestione dei contenuti relativi al fatturato. Utilizza inoltre il PMS dell’albergo che dedica ad analisi nella seconda parte della giornata. Egli è un utente Advance perchè unisce le sue competenze manageriali agli strumenti B.I. in possesso, per gestire al meglio il rapporto con la clientela. L’utente Advance è sicuramente utile poichè ha una visione particolare dei software B.I. molto legata a caratterisitiche della struttura, confrontare i suoi flussi di lavoro con logiche innovative sperimentate nella B.I. Sphaera Cognitiva può mettere in luce vantaggi e svantaggi dei contenuti operativi in essa inseriti.

116

Utente Expert

Nome e Cognome: Flavio PiccoloEtà: 36Professione: Revenue Manager at Hotelsolutions srlStruttura: Best Western Hotel Canon d’Oro

Descrizione MansioneFlavio lavora da dieci anni in una società leader nello Strategic Revenue Management applicato alla distribuzione internet.La sua mansione come consulente presso l’hotel Best Western Canon d’Oro è quella del Revenue Manager. In detteglio si occupa di definire strategie di pricing mediante la definizione del segmentazione del mercato della struttura, analizzando i principali mercati e creando piani strategici finalizzati alla massimizzazione della redditività di vendita camere.

Obbiettivi valutazione strumentoIl Sig. Flavio è un consultant avente il compito di gestire i revenue di oltre trenta strutture alberghiere. Egli utilizza strumenti di B.I. come la versione analitica di Sphaera di cui si può considerare un utente con profonda conoscenza del software. Egli ha competenze in software commerciali web based come Agency360 della software house Travelclick, Amadeus della omonima società di consulenza e Bellboypms della società di hotel management system Bellboy a PMS interni alle strutture. Egli è un utente esperto perchè non solo ha competenze nella gestione e managerialità del

84 Esempi interfaccia dashboard: Agency360° di Travelclick, Amadeus basata su ClickSense,Bellboypms.Queste dashboard web based sono strumenti utilizzati per finalità di revenue management

www.amadeus.com www.travelclick.comwww.bellboypms.comAccessed in June 2016

Software Agency360°

Software Amadeus

Software Bellboypms

117

pricing e revenue ma ha anche competenze maturate in esperienza decennale nell’utilizzo di software di Property management system. L’utente Expert è sicuramente utile a confrontare ed analizzare Sphaera ad altri software affini per definirne migliorie.

118

Obbiettivi

Nella ricerca di una strategia condivisa con Best Western Italia si prosegue nella descrizione degli obbiettivi della valutazione.Come si è descritto nel paragrafo precedente attraverso l’analisi delle Persona si è evinto che gli strumenti di B.I. utilizzati dagli utenti sono usati nella ricerca di informazioni quotidiane come l’andamento del revenue, in relazione alle politiche di pricing messe in atto precedentemente.Va da sè che la definizione delle politiche di pricing così come l’esplorazione del revenue si sono attestati come i bisogni informativi principali su cui gli utenti hanno dimostrato interesse. La strategia che è apparsa con maggior vigore è stata la proposta di un piano di valutazione che in qualche modovalutasse la soddisfazione di questo bisogno informativo messo in atto con uno strumento come la B.I. Sphaera Cognitiva.Non solo, ma che la soddisfazione di questi bisogni venisse messa in relazione agli strumenti di B.I. già in utilizzo presso le strutture.Il primo obbiettivo condiviso della valutazione, si è identificato come la necessità di una valutazione di tipo comparativo:mettere cioè a confronto gli strumenti B.I. Sphaera Cognitiva e Analitica rispetto alla soddisfazione di obbiettivi comuni; inoltre verificare come le due dashboard possano essere utilizzate in sincronia al fine di una esplorazione dei fenomeni che possa identificarsi come efficace, efficiente e

119

usabile. Il secondo obbiettivo condiviso che si è evinto è la valutazione delle singole visualizzazioni come generatrici di processi cognitivi. Le metafore visive progettate in modo innovativo nella costruzione formale e nelle funzionalità informative, ha determinato la volontà di creare una proposta di metrica che potesse misurare l’usabilità di queste visualizzazione mediante una proposta di metodologie di tipo qualitativo.Il terzo obbiettivo della valutazione è da ricercarsi nella formalizzaione di requisiti funzionali relativi alla dashboard Cognitiva, al fine di creazione di documentazione che potesse servire per un nuovo sviluppo di ulteriori funzionalità.Il quarto obbiettivo è identificabile nella valutazione dell’ usabilità della dashboard cognitiva, dove gli utenti sono condotti a portare a termine delle azioni interagendo con l’interfaccia utente.Il quinto obbiettvo è da ricercarsi nella segnalazione dei difetti o bug dell’applicazione.I cinque obbiettivi principali sono stati identificati e condivisi con SI Hotel durante gli incontri avvenuti nel mese di marzo 2016 con il Responsabile IT che ha fornito un’ulteriore spiegazione delle funzionalità della B.I. Sphaera Analitica al fine di ricercare i punti di interazione con la dashboard Cognitiva.

120

Contesto

Per contesto si identifica la descrizione delle tecniche e gli scenari proposti nella progettazione di un piano di valutazione. Dopo aver definito i bisogni degli utenti e gli obbiettivi della valutazione si descrivono le metodologie proposte per la creazione di un protocollo.Si riprende la formulazione degli scenari esposti nel paragrafo 3.5 di questo scritto, in particolare la scelta delle domande di valutazione sottese ad ognuno di questi, nella scelta delle tecniche validative.In particolare l’attenzione si focalizzano sugli scenari di Process e Visualization collegati alle relative domande cui mirano a dare risposta:

- UWP Riconoscimento del contesto di utilizzo del software; Riconoscimento delle attività quotidiane in cui lo strumento dovrebbe essere integrato; Riconoscere le tipologie di analisi per cui lo strumento dovrebbe essere utilizzato; Riconoscere quali altri tipi di software sono utilizzati dagli utenti nel proprio ambiente di lavoro; Riconoscere criticità che il software potrebbe creare nei flussi di lavoro ad esempio con l’utilizzo di altri software.

- VDAR Riconoscimento dei processi di analisi del fenomeno; Riconoscimento dei processi di generazione delle ipotesi;

121

Riconoscere le tipologie di analisi per cui lo strumento dovrebbeessere utilizzato;

- UP Riconoscimento dei limiti temporali nel completamento di tasks; Riconoscimento del numero degli errori nel completamento dei

tasks;

- UE Riconoscimento delle principali caratterisitiche della visualizzazione in vantaggi e svantaggi; Riconoscimento dei processi di interazione funzionali ai processi di business;

A questi scenari si riconoscono associazioni a specifiche tecniche di valutazione, che si reputano comunque trasversali, ma che probabilmente concorrono ad una maggiormente efficienza di risposta a certi obbiettivi. Si veda la descrizione delle associazioni create per scenario:

Understanding Environments and Work Practices - a questo scenario si sono associati le tecniche di Usability Test e del Cognitive Walktrough;

Evaluating Visual Data Analysis and Reasoning - a questo scenario si sono associati le tecniche di Heuristic Evaluation e del Think-aloud protocol;

122

Evaluating User Performance - a questo scenario si è associata la tecnica del Performance Testing negli aspetti riguardanti la registrazione delle tempistiche di completamento tasks;

Evaluating User Experience - a questo scenario si è associata le tecnica del Think aloud protocol, per gli aspetti di esplorazione delle informazioni.

A fronte di una applicazione ponderata di queste tecniche differenti a seconda del profilo di Persona a cui sottoporre gli scenari, si è definita una metrica basata sul riconoscimento del numero e della qualità delle ipotesi collegate all’esplorazione dell’interfaccia: una tecnica basata sul riconoscimento degli Insights sviluppati dal tester durante l’interazione visiva definita come Insight-Based Valuation.La metrica è progettata per misurare variabili quantitative e qualitative. Nella variabili quantitative si veda il riconoscimento del numero degli Insight prodotti dall’utenza in relazione al tempo impiegato per portare a termine determinati compiti. Tale tipo di metrica potrebbe essere interessante per definire delle relazioni interpretative di tipo Regressivo o Correlativo:si pensi all’attività di test di tipo Think-aloud protocol inseribile nello scenario VDAR. L’utente durante l’esplorazione di una particolare visualizzazione innovativa come nel caso del grafico dedicato nella sezione “Il tuo Pricing” della B.I. Sphaera Cognitiva, produce un certo numero di intuizioni impiegando una determinata quantità di tempo relativo all’interazione con i widget e variabili dedicate. Questo tipo di esplorazione potrebbe produrre una

85 La relazione di tipo Regressione si verifica quando è ipotizzabile un rapporto di “causa-effetto” tra le variabili;la relazione di tipo Correlazione si verifica quando non è ipotizzabile un rapporto di causa-effetto tra le variabili, ma queste dipendono, almeno in parte, da cause comuni.

123

caratteristica relazione tra la quantità di variabili informative visualizzate in relazione a quanto tempo l’utente dedica all’esplorazione e quanti Insight produce.

124

125

4.3 Attività di valutazione

In questo paragrafo si descrivono le sessioni di valutazione durante le quali sono stati applicati gli scenari sopracitati.Le attività si sono condivise durante gli incontri con il responsabile tecnico di SI Hotels S.c.p.A. avvenuti alla fine di marzo 2016 ed inizio aprile 2016. La scelta delle tre tipologie di utenza è sembrata da subito coerente con gli obbiettivi di progetto, così come l’approccio etnografico e gli scenari di rifermiento.Durante il Kick Off avvenuto il giorno 22 Aprile 2016 si è pianificato il Test and evaluation master plan condiviso con il cliente, identificando le tempistiche anche in relazione alle trasferte.Le attività di test sono state progettate per essere completate in una mezza giornata lavorativa di 4 ore preventivando uno slack del 50% su ogni ora. Adottando un approccio etnografico, cioè attività fatte sul campo, ovvero nel posto di lavoro del utente si sono preventivate delle trasferte da effettuarsi negli hotel di riferimento in cui lavorano i managers. Gli incontri sono avvenuti durante il mese di Aprile e Maggio 2016 e si sono svolti in loco, nelle strutture alberghiere affiliate Best Western Italia S.c.p.a. Le strutture prese in esame sono site in Milano presso il BW Hotel Felice Casati, Chieti pressoo il BW Hotel Parco Paglia e Conegliano Veneto (TV) presso il BW Hotel Canon d’Oro.In particolare per la struttura di Conegliano non si è effettuata la trasferta in quanto è stato possibile incontrare il revenue manager presso la società Hotelsolutions srl sita in Milano.

126

Nella pagina seguente è possibile leggere lo sviluppo temporale della valutazione con dettaglio sugli scenari applicati.22 Aprile 2016Kick Off - Valutazione B.I. SphaeraPresso sede Best Western Italia S.c.p.A via Livraghi, 1/b - MilanoPartecipanti: Responsabile IT, Valutatore, Utente Basic, Utente Advance, Utente Expert via Web binar.Incontro di introduzione alle attività di valutazione, condivisione degli obbiettivi di progetto e coferma date di trasferta.

27 Aprile 2016Valutazione B.I. SphaeraPresso Best Western Hotel Felice CasatiVia Felice Casati, 18 - MilanoPartecipanti: Responsabile IT, Valutatore, Utente BasicScenari: UP, UE

12 Maggio 2016Valutazione B.I. SphaeraPresso sede HotelSolutions S.r.l.Via dell’ Annunciata, 23/1 - Milano Partecipanti: Responsabile IT, Valutatore, Utente ExpertScenari: UWP, VDAR, UP, UE

27 Aprile 2016Valutazione B.I. SphaeraPresso Best Western Hotel Parco Paglia

4.4 Descrizione Metodologia

La strategia di valutazione Sphaera, condivisa con SI Hotels S.c.p.A. si riassume come:

Approccio etnografico applicato mediante Usability Testing in cui si inseriscono delle componenti di Usability Inspection utilizzando delle metriche di valutazione Insight-Based.

Questa metodologia trova una struttura di base nell’approccio Usability Testing, in quanto la valutazione dell’interfaccia utente di Sphaera Cognitiva è divisa per compiti che definiscono un interazione tipica, per ogni sottosezione chiamata workflow. Ogni workflow rappresenta una particolare flusso di azioni scomponibili in singoli test case. Questa struttura di valutazione delle funzionalità divise per azioni è sembrata l’unica utilizzabile per ottenere risultati validi: se uno degli obbiettivi è il confronto tra le due B.I., l’usability Testing è sembrato l’approccio con cui si potessero ottenere dei risultati quantitativi: si pensi al tempo come ariabile mettendone in evidenza l’eventuale risparmio di tempo rispetto ad un uguale ottenimento di informazioni.Lo svantaggio di questa tecnica è da ricercarsi proprio nel suo utilizzo di valutazione per i due strumenti Spahera: I testbook sono differenti nella definizione dei singoli test case, in quanto non dispongono delle stesse funzionalità. In definitiva è stato possibile un confronto solamente dopo aver “allineato” i test per workflow specifici e miranti ad ottenere lo stesso tipo di informazioni.

127

L’allineamento dei testbook delle due dashboard è stato sviluppato durante una sessione appositamente definita con il Responsabile IT presso Best Western S.c.p.A.. Usability TestingPrendendo in esame la progettazione di un Deliverable di progetto di un Usability Test, come il TestBook si veda la descrizione di questo attraverso i singoli test case condivisi con il cliente. Per una descrizione dettagliata di ogni singolo test case di veda la tavola esplicativa dedicata.Il TestBook è stato creato scomponendo l’interazione del software in task funzionali detti TestCase. Ad ogni caso di test sottendono un certo numero di informazioni che lo descrivono che si possono riconoscere in: numero identificativo del testcase, descrizione del Test Case, risultato aspettato, status del testcase. Il Testbook della B.I. Sphaera Cognitva è composto da 18 testcase in cui si identi-ficano 61 singoli tasks. Il Testbook della B.I. Sphaera Analiti-ca è composto da 10 testcase in cui si identificano 30 singoli tasks. Vi sono dei casi di test che non è stato possibile allineare come il Testcase “Workflow Generici - workflow di riassunto” che si è eliminato durante la fase di analisi dei ri-sultati ottenuti come fattore di confronto. La tavola seguente “Relazione Test Cases B.I. Sphaera Cognitiva - Sphaera Analitica” visualizza il numero totale di task relazionando le singole testcase per funzionalità simili. Ad esempio il testcase della B.I. Cognitiva legato alla comprensione dell’informazione legata al posizionamento di vendita della classe di camere, presente nello “Storico” è in relazione al testcase della B.I. Analitica avente la stessa funzionalità ma presente nella sezione “Consuntivo e Fatturato ADR”.

128

Proiezioni 14

Oggi 11

Sintesi 7

Relazione Test Cases B.I. Sphaera Cognitiva - Sphaera AnaliticaRelazione tra singoli tasks relativi alle sezioni UI per numero di Test Case

Storico 17

Tot. n. tasks 49

B.I. Sphaera Cognitiva

129

4 Previsionale Fatturato On the Book

2 Fatturato On the Book

23 Tot. n. tasks

B.I. Sphaera Analitica

17 Consuntivo Fatturrato ADR

130

Think Aloud Protocol vs. Heuristic Evaluation

Le tecniche utilizzate durante le sessioni di valutazioni asseribili alla Usability Inspection sono state utilizzate poichè gli utenti sono da considerarsi sia esperti del settore di competenza della dashboard come l’utente Advance e l’utente Basic, sia utenti esperti che hanno maturato anni di esperienza nell’analisi del dato tramite cruscotti digitali come l’utente Expert. .Per questo motivo l’Heuristic Evaluation di cui si è descritta la funzionalità nel paragrafo 3.2 si è utilizzato al fine di ottenere una valutazione da utenti esperti di usabilità in un’accezione più ampia cioè in base alla loro esperienza con altri prodotti della stessa fascia di mercato. Essi possono valutare l’interfaccia utente attraverso la loro esperienza passata, segnalando quelle caratteristiche formali delle visualizzazioni che non soddisfano appieno bisogni informativi o di quei difetti o problemi di usabilità della visualizzazione e spunti idee per migliorale.Per gli utenti Basic e Advance è previsto un test di tipo Thin k aloud. Questa tecnica permette all’utente di rendere pubblici i suoi pensieri legati all’esplorazione dell’interfaccia. A differenza dell’utente Expert i due Utenti Basic e Advance hanno una esperienza limitata di utilizzo di software come le BD, va da sè che durante la prima esplorazione del software essi possano attraverso il loro ragionamento avere intuizioni importanti per il miglioramento della UI.

131

Insight - Based Evaluation

La metrica Insight Based Evaluation può essere adibita anche a raccogliere outputs di tipo qualitativo che dipendono dai contenuti degli Insight.Un Insight può avere innumerevoli significati, è il valutatore che ne definisce il contenuto e l’appartenenza ad insiemi. Si possono altresi proporre dei campi di appartenenza generici nel riconoscimento degli insight:

- Osservazioni generiche: osservazioni dirette divisibili in carattere negativo o positivo riguardanti la metafora visiva utilizzata;- Considerazioni formali: osservazioni dirette volte a descrivere le proprietà formali della rappresentazione;- Ipotesi: osservazioni dirette volte a descrivere il proseguimento dell’esplorazione del fenomeno;

Queste tre famiglie generiche di insight si possono applicare alla costruzione di un uleriore misura del grado di efficienza della dashboard in quanto se uno degli obbiettivi di una datavisualization nel contesto B.I. è creare senso nel dato, l’insight oppurtamente trattato può funzionare a definire l’efficacia di una business dashboard.

132

133

Questo paragrafo descrive il tipo di organizzazione che si è data durante le attività di valutazione.Come si è già descrtito nel paragrafo 4.3 di questo capitolo le attività di test hanno comportato la definizione di ruoli ai fini del test che i partecipanti hanno ricoperto. Gli utenti sono stati definiti come Tester, il responsabile IT come Facilitarore, il ricercatore di questa tesi come Osservatore/valutatore. Si noti il seguente schema di flusso, rappresentante il workflow di somministrazione del task.

Osservatore/valutatore: ha il compito di gestire l’attività di test definendo l’inzio e la fine di ogni sessione. Egli legge i task pone domande all’utente e registra le considerazioni annotandole;

Facilitatore: ha il compito di aiutare l’utente nei compiti richiesti;

Tester: ha il compito di effettuare il test e rispondere alle domande poste dall osservatore/valutatore.

Se l’interazione viene completata e assolve i risultati aspettati, l’osservatore pone lo status del test in passato definito “OK” segnando il tempo impiegato e gli Insight prodotti durante l’attività. Nel caso in cui il tester non riesca ad interagire con la dashboard, ad esempio non trovando i contenuti descritti nel task, l’osservatore pone lo status del test in non passato “ISSUE” segnando il tempo impiegato.

4.5 Protocollo di valutazione

134

Lettura task

User Interaction

Task Execution

StatusOK

StatusISSUE

Timing Description

Timing Description

Insight Description

Test ExecutionDiagramma di flusso dedicato alla descrizione dell’esecuzione di un singolo task

Attività Osservatore Attività Tester

Sintesi; 2 - Storico - Confronto fatturato singole settimane

135

Test Book - Sphaera CognitivaDescrizione per Sezione dei Task Description e Expected Results

I.D.

Sintesi: 1 - Lettura Fatturato

1.0

2.0

3.0

2.1

3.1

2.2

3.2

Task Description

Lettura Fatturato numerico

Confronto del fatturato nelle singole settimane

Confronto del fatturato nelle singole settimane

Interazione touch point Area Graph

Interazione touch point Area Graph

Lettura del tooltip

Lettura del tooltip

Riconoscimento e lettura del valore numerico corrispondente al Fatturato

L’utente ricerca informazioni aggiuntive me-diante interazione con Area Graph

L’utente ricerca informazioni aggiuntive me-diante interazione con Area Graph

L’ utente cerca informazioni sulla variazione per-centuale del fatturato settimanale posizionando il cursore direttamente sui punti di variazione dell’Area Graph

L’ utente cerca informazioni sulla variazione per-centuale del fatturato settimanale posizionando il cursore direttamente sui punti di variazione dell’Area Graph

L’utente legge le informazioni presenti nel tooltip di riferimento

L’utente legge le informazioni presenti nel tooltip di riferimento

Expected Results

Sintesi; 3 - Proiezioni - Confronto fatturato singole settimane

136


4.0

4.1

5.0

6.0

4.2

5.1

6.1

4.3

5.2

Accedere alla sezione “Oggi”

Lettura contenuto informativo “Oggi hai X prenotazioni in corso, di cui X di tipologia cancellabile e X di tipologia non cancella-bile. Inoltre X sono state cancellate

Riconoscimento del numero di “Prenotazioni non cancellabili”

Nella sezione “OGGI” esplorare il “Detta-glio” della tipologie di prenotazione

Selezionare il pulsante “Più Informazioni”

Riconoscimento del numero di “cancellabili”

Selezione del pulsante “Guarda in detta-glio”

Uscire dal tooltip informativo selezionan-do la scritta precedentemente selezionata

Riconoscimento del numero di “cancellate”

L’utente selezionerà riconoscendone l’icona cliccan-doci sopra una sola volta mediante il mouse

L’utente sarà invitato mediante “affordance” del peso visivo ad interagire con esse

Riconoscimento valore economico e data prenota-zione ed effettivo soggiorno

L’utente selezionerà il pulsante “Guarda in detta-glio”

Comparirà un messaggio di spiegazione dell’Arc Diagram

Riconoscimento valore economico e data prenota-zione ed effettivo soggiorno

Il pulsante “Guarda in dettaglio” inverte i colori, la sezione di dettaglio si estenderà mediante movimen-to verticale, diminuendo l’Arc Diagram nel testa pa-gina

Il tooltip scomparirà

Riconoscimento valore economico e data prenotazio-ne ed effettivo giorno della disdetta

Oggi; 5 - Esplorazione ARC DIAGRAM

Oggi; 6 - DETTAGLIO

Oggi; 4 - Esplorazione informazioni sezione

I.D. Task Description Expected Results

137

I.D.



7.1

8.1

7.2

8.2

7.3

7.4

Task Description

Dal folder “Oggi” accedere alla sezione “Storico”

Cambiare i dati temporali per il confronto selezionando il menù a tendina che com-pare nella scritta “Rispetto a un annofa, come è cambiata la situazione?”

Selezionare il periodo di peggior fatturato per le 2 line di confronto definendo la data del picco e la quantità in €

Selezionare il periodo di maggior fatturato per le 2 line di confronto definendo la data del picco e la quantità in €”

Selezionare la voce “ 2 mesi”

Selezionare la voce “ Un mese”

Si aprirà la sezione “Storico” impostata con data di confronto ad “Un anno”

Si aprirà la sezione “Storico” impostata con data di confronto ad “Un anno”

Si aprirà un menù a tendina contenente i seguenti campi “Un anno, 2 mesi, 1 mese”

L’utente dovrà definire a voce la quantità di denaro e la data del picco negativo per ambedue le date

Il grafico “Andamento” si modificherà in base al dif-ferente confronto temporale

Expected Results

Storico; 7 - Modifica selezione voci confronto temporale

Storico; 8 - Lettura grafico “Andamento” fatturato

6.2

6.3

Ricerca informazioni “Distribuzione delle prenotazioni per durata di soggiorno.”

Dettaglio Tooltip

L’utente interagisce con il grafico “Scatter Plot Oriented” alla ricerca di informazioni riguardan-ti la distribuzione temporale delle prenotazioni

L’utente legge il contenuto informativo nei tool-tip dei “baloon” spiegando il proprio workflow decisionale


138


9.0

9.1

10

11

9.2

10.1

11.1

Espandere la sottosezione “Classe di Ser-vizio”

Espandere la sottosezione “Tipo di garan-zia”

Interazione touch point Bubble Chart

Definire per la tipologia X la %di variazio-ne rispetto all’anno precedente e la diffe-renza espressa in €


La sottosezione si espande visualizzando una Bub-ble Chart del fatturato totale diviso per prenotazioni “Cancellate” e prenotazioni “Non Cancellate” visua-lizzate per le 3 categorie

La sottosezione si espande visualizzando una Bub-ble Chart del fatturato totale diviso per prenotazioni “Cancellate” e prenotazioni “Non Cancellate” visua-lizzate per le 2 categorie Flex, No Flex

si visualizzerà un tooltip informativo contenendte i se-guenti dati: “Totale - % di variazione - Variazione in € tra il periodo presente e passato

Comparirà un tootip in cui saranno presenti i riferi-menti


Oggi; 10 - Esplorazione della sottosezione Classe di servizio

Oggi; 11 - Esplorazione della sottosezione Tipo di Garanzia

Oggi; 9 - Esplorazione della sottosezione Distribuzione del fatturato totale


Dal grafico “Andamento” accedere alla sot-tosezione di dettaglio “Distribuzione del fatturato per categoria”

Espandere la sottosezione “Fatturato tota-le”

Saranno presenti 5 sottosezioni espandibili. “Fattu-rato totale”, “Classe di servizio”, “Tipo di garanzia”, “Paese di provenienza”, “Tipologia di tariffa”

La sottosezione si espande lasciando lo spazio cen-trale della pagina alla visualizzazione mediante Bub-ble Chart del fatturato totale diviso per prenotazioni “Cancellate” e prenotazioni “Non cancellate”

139


12

13

14

12.1

13.1

14.1

14.2

14.3

Espandere la sottosezione “Paese di Prove-nienza”

Espandere la sottosezione “Tipo di garan-zia”

Dal folder “Storico” accedere alla sezione “Proiezioni”



Cambiare i dati temporali per il confronto selezionando il menù a tendina che com-pare nella scritta “Rispetto a un annofa, come è cambiata la situazione?”

Selezionare la voce “ 2 mesi”

Selezionare la voce “ 1 mese”

La sottosezione si espande visualizzando una Bub-ble Chart del fatturato totale diviso per prenotazioni “Cancellate” e prenotazioni “Non Cancellate” visua-lizzate per le categorie

La sottosezione si espande visualizzando una Bub-ble Chart del fatturato totale diviso per prenotazioni “Cancellate” e prenotazioni “Non Cancellate” visua-lizzate per le 4 categorie Commercial, Discount, Par-tnership, Bar

Si aprirà la sezione “Proiezioni” impostata con data di confronto ad “Un anno”r



Si aprirà un menù a tendina contenente i seguenti campi “Un anno,2 mesi, 1 mese”



Oggi; 13 - Esplorazione della sottosezione Tipologia di tariffa

Proiezioni; 14 - Esplorazione della sezione Proiezioni

Oggi; 12 - Esplorazione della sottosezione Paese di provenienza


140




15.0

16.0

17.0

15.1

16.1

15.2

16.2

15.3

Posizionandosi nel grafico Area Graph se-lezionare il massimo importo in € per una prenotazione di tipologia “Non Cancellabi-le” riferita ad due giorni dalla data corrente

Ricercare nel tooltip la differenze tra perio-do anno passato e attuale

Comparirà un tootip in cui saranno presenti i riferi-menti espressi in € per le 3 tipologie di prenotazioni “Cancellabili” “Cancellate”, “Non Cancellate”

Proiezioni; 15 - Esplorazione Grafico Area Graph

Proiezioni; 16 - Esplorazione Fatturato per categoria

Proiezioni; 17 - Esplorazione sottosezione Il tuo pricing


Posizionandosi nel grafico Area Graph se-lezionare il massimo importo in € per una prenotazione di tipologia “Cancellabile” ri-ferita ad 1 giorno dalla data corrente

Dal grafico “Area Graph” accedere alla sot-tosezione di dettaglio “Distribuzione del fatturato per categoria”

Cambiare i dettagli X della frase “Il grafico mostra il prezzo a notte che applichi per una camera X con un contratto X compa-rato con la media della città” selezioando dai menù a tendina rispettivamente la voce “Standard” e “Cancellabile”

Ricercare nel tooltip la differenze tra perio-do anno passato e attuale

Comparirà un tootip in cui saranno presenti i riferi-menti espressi in € per le 3 tipologie di prenotazioni “Cancellabili” “Cancellate”, “Non cancellate”

Lettura Tooltip

Lettura Tooltip

Saranno presenti 5 sottosezioni espandibili. “Fattu-rato totale”, “Classe di servizio”, “Tipo di garanzia”, “Paese di provenienza”, “Tipologia di tariffa”

Il grafico sottostante cambierà le sue dimensioni

Interazione touch point Bubble Chart si visualizzerà un tooltip informativo contenendte i se-guenti dati: “Totale - % di variazione - Variazione in € tra il periodo presente e passato

Espandere la sottosezione “Fatturato tota-le”

La sottosezione si espande lasciando lo spazio cen-trale della pagina alla visualizzazione mediante Bub-ble Chart del fatturato totale diviso per prenotazioni “Cancellate” e prenotazioni “Non cancellate”

I.D.


18.0

18.1

18.2

18.4

18.6

18.3

18.5

18.7

Task Description

Quante sono state cancellate ad 1 mese dalla loro prenotazione?

Visualizza le prenotazioni della giornata odierna comparandole con lo stesso gior-no dell’anno scorso

Quale è stata la prenotazione cancellata dal costo più alto?

In quale giorno è stato toccato il più alto valore economico per una prenotazione cancellabile?

Definire la variabile temporale nelle proie-zioni (scelta 1 mese, 2 mesi, 12 mesi)

Considerazioni utente





Expected Results

Worlflow generici; 18 - Testcase di riassunto

17.1

17.2

Definire per il primo giorno del mese pros-simo alla data odierna: la proiezione del proprio pricing e quello medio dei compe-titor espresso in € e il tempo previsto

Definire per il primo giorno della secon-da settimana del mese prossimo alla data odierna: la proiezione del proprio pricing e quello medio dei competitor espresso in €






Quale tipologia di prenotazioni per un importo pari o maggiore di 100 euro sono state disdette ad 1 settimana dalla loro con-segna?

Rispetto allo stesso giorno del anno scorso il fatturato in data odierna come si pone?

In quale giorno è stato toccato il più alto valore economico prenotazione non can-cellabile?

141

142


18.8

18.9

18.10

18.11

Confronto annuale delle quantità econo-miche delle prenotazioni (per le 3 tipolo-gie)

Ricerca della nazionalità con più alta can-cellazione prenotazioni nel prossimo mese e quale evento sarà previsto

Ricerca della nazionalità con la minore conferma prenotazioni nel prossimo mese

Definizione delle prime 5 nazionalità con la più alta cancellazione prenotazioni per i prossimi 2 mesi





Risultati Ottenuti

5. Risultati ottenuti

Dopo la raccolta dei dati segue la fase di analisi.La fase di analisi si caratterizza da differenti approcci il cui obbiettivo è trovare senso nel materiale raccolto:darne forma al fine di comunicarne i risultati.I dati raccolti durante le sessioni sono di natura differente, si possono riconoscere in testuali e in audiovisivi, rispettivamente nei testbooks e video interviste86.Si veda la ripartizione in termini quantitativi del materiale raccolto per sessione di test nel grafico seguente:

6 TestBook

51 Video 32 Registrazioni

Questi output, sono definiti come deliverable dell’analisi e rappresentano il materiale grezzo, o giacimenti di dati.Il ruolo del progettista corrisponde nel dare senso, forma al materiale al fine di rendere il processo di analisi allineato agli obbiettivi della ricerca.Nella pagina fianco si veda la visualizzazione di tipo Tree map in cui si possono notare le gerarchie definite mediante le dimensioni temporali del materiale audio- video. Ogni rettangolo rappresenta la quantità di tempo espresso in mi-nuti di un singolo file audiovisivo, i colori ne identificano la relazione alla B.I. valutata. Il tempo totale totale espresso è un complessivo sia dell Heuristc Evaluation che del Usability Testing, quindi non cor-risponde all’effettivo completamento dei singoli Task.

86 Le registrazioni sono avvenute mediante questa strumentazione:

- Registratore Audio: Sony ICD-PX333;

- Fotocamera Reflex Digitale:Ca-non EOS 50D

145

Sessione Valutazione BW Hotel Felice Casati - durata audio-video in ore 01:45:00

Previsionale Fatturato On the Book

Previsionale Fatturato On the Book

Previsionale On the book

Previsionale Fatt.

ConsutivoFatt.

Consuntivo Fatturato ADR

Consuntivo Fatturato ADR

Storico

Storico

Storico

Previsionale

Previsionale

Previsionale

Sintesi

Sintesi

Fatturato On the Book

Fatturato On the Book

Oggi

Oggi

Oggi

Sessione valutazione SI Hotel s.r.l . - durata audio-video in ore 04:33:00

Sessione valutazione BW Hotel Parco Paglia - durata audio-video in ore 02:50:00

146

Le otto ore di materile raccolto sono state ridotte considere-volmente mediante l’analisi del contenuto. I file ottenuti in versione Raw sono stati processati mediante tool commerciale Adobe Premier Pro Cs6, mediante tecniche di montaggio video.La suddivisione e la categorizzazione mediante esclusione di parti non propedeutiche alla produzione di senso è stata oggetto di analisi. Il materiale è stato alterato ai soli fini di essere fruito vista le dimensioni dei file Raw .In termini di contenuti le registrazioni sono state alterate solo nelle parti non incentrate al test: pause ad esempio.Il resto del contenuto è stato analizzato al fine di valutare e verificare i risultati già segnati sui Testbooks di riferimento:ad esempio verificare le tempistiche di completamento di un task e verificare la correttezza delle citazioni degli utenti riportate.Mediante osservazione e analisi dei file audiovisivi è stato possibile dividere le sessioni in categorie dedicate alle singole sezioni delle B.I. valutate: il primo insieme di attività di ana-lisi affrontate si può ridurre a un processo di selezione:

- Decostruzione dei file; - Esclusione delle parti non idonee all’analisi;- Costruzione dei file in base al contenuto;- Analisi mediante lettura del contenuto;- Verifica del contenuto mediante confronto Testbook

Una volta che è stato verificata la correttezza del contenuto è stato possibile definirne un senso dettato dagli obbiettivi proposti inizialmente.

147

Gli obbiettivi di validazione dell’efficienza, dell’efficacia e dell’usabilità della business dashboard sono stati tradotti mediante variabili quantitative e qualitative che si ricordano come:

- Completamento dei task;- Tempo di completamento dei task;- Numero Insight;- Tipologia degli Insight;

Da queste variabili è stato possibile formulare delle ipotesi vi-sive che rispondessero alla definizione dei fenomeni per una lettura che rispondesse ad un ulteriori analisi visiva.La comunicazione delle variabili è stata un attività propria del progettista e trattandosi di dati, essa deve rispondere ai requisiti di efficacia ed efficienza proprio come la domanda di ricerca iniziale di questo scritto:

COME SI VALUTA L’ EFFICACIA DELLE VISUALIZZAZIONI DI DATI

NELLE BUSINESS DASHBOARD?

Si potrebbe contestualizzare la domanda di ricerca alla comunicazione di dati di valutazione ma anticipando le conclusioni di questa tesi, si può affermare che lacomunicazione dipenda dal obbiettivo comunicativo, dal contesto di riferimento in questa è posta e dal lettore che ne deve fruire.

148

Si è descritto come l’efficacia di una comunicazione dipenda dalle tre variabili UCD e come da queste si possano identifi-care innumerevoli strategie e forme comunicative.La comunicazione di dati, nella forma interattiva e visuale riprende il concetto dello User Centerd Design riproponendolo come scelta metodologica fondante della sua progettazione. Inoltre è doveroso ricordare che l’efficacia di una valutazione di infografiche dipenda dalla scelta coordinata e consapevole di differenti punti di vista che possano descrivere un fenomeno in forme differenti.Le proiezioni ortogonali sono in ultima analisi una buona metafora della progettazione di una comunicazione visualebasata sui dati: nelle dashboard il piano verticale potrebbe essere rappresentato da una determinata variabile del KPY mentre il piano laterale da un altra e così via.Si ricordi l’aspetto duale che ha caratterizzato la valutazione descritta in questa tesi: la presenza di due B.I. che avessero due modi di comunicare i dati differenti seppur descrivendo lo stesso fenomeno informativo. L’efficacia e l’efficienza è riconducibile alla sintesi cognitiva creata nella mente del fruitore nella comprensione dei differenti sistemi informativi e la facoltà di fruire da più punti di vista decreta una migliore o minore comprensione di un fenomeno.I dati di valutazione vengono a tal proposito descritti in forme visuali differenti: riprendendo la metafora della dash-board strategica e della dashboard analitica viene propostauna comunicazione visuale che descriva un stessodato in modo differente e che enfatizzi caratteristichedifferenti di uno stesso fenomeno.Nelle pagine seguenti vengono riportate delle tavole di

5.1 Visual test report

149

esempio in cui si descrivono due principali grammatichevisive create per visualizzare i dati.Queste due tavole sono da considerarsi al fine della conclusione del ciclo di test, dei report in cui si comunicanoi risultati della valutazione.

150

Tempo completamento task per utente

Task Task

n. Insight

Si riconoscono tre tipologie di utenti. Per ogni tipo vengono riportati i risultati del singolo testcase divisi tra Testbook di Sphaera Cognitiva e Analitica; Si riconoscono sei tipologie di Insight sottocategorie delle tre principali: Osservazioni generiche, Ipotesi Considerazioni formali89;

Suddivisone dei Testbook B.I. Sphaera Cognitiva B.I. Sphaera Analitica;

Rappresentazione simbolica delle anomalie. Il numero corrisponde ad un indice della descrizione del defect presente nel Testbook.

1!

Master Test Report

L’esempio riportato nella pagina a fianco rappresenta deglielementi visivi che caratterizzano questo Report.Al fine di comunicare in un modello di MTP visivamente costituito che possa rappresentare anche dei focus sulle anomalie riscontrate mediante la loro descrizione o il rimando a note specifiche presenti nel Testbook di riferimento. A fianco viene riportato un esempio di legenda e divisualizzazione descrittiva adottata per comuni-care i risultati della sezione Sintesi 1.

88 L’ Anomaly Report è un reportspecifico in cui vengono descrittetutte le anomali riscontrate durante le attività di analisi89 Si veda la suddivision seguente:

Ipotesi: New Feautures, C.R;

Considerazioni Formali: Anomalies;

Oss. Generiche: Touchpoints;

151

Utente Basic

Utente Expert

00:05s 00:10s 00:20sGAP analysis

B.I. Cognitiva - AnaliticaTask non effettuato (status “to do”)

Utente Advance Task non completato (status “issue”)

Task completato (status “ok”) New Features Touchpoint with SW

Legenda

Change Request Anomalies

Touchpoint with B.I.

00:00s

1 !

Tempo medio utenti completamento task

TaskTask Task

n. Insight

L’esempio riportato nella pagina a fianco descrive ilTestcases della sezione Sintesi. Come si può notare i dati re-lativi al singolo Testcase Sintesi1 sono gli stessi proposti nel grafico nella pacina precedente. Il punto di vista in questa visualizzazione enfatizza la descrizione della valutazione at-traverso una visione unitaria dell’esplorazione degli utenti. Le variabili utilizzate riguardano il numero degli Insights, la loro tipologia divisa per i singoli Testcases.

153

Sintesi 1 Sintesi 2 Sintesi 3 Sintesi 4

Utente Advance

Utente Expert

Legenda

Utente Basic

Osservazioni generiche

Considerazioni FormaliIpotesi

00:10s

!

TestCases

Sintesi 1

Sintesi 2

Sintesi 3

Oggi 4

Oggi 5

Oggi 6

Storico 7

Storico 8

Storico 9

Storico 10

Storico 11

Storico 12

Storico 13

Proiezioni 14

Proiezioni 15

Proiezioni 16

Proiezioni 17

00:05s 00:10s 00:20s 00:40s 00:60s 02:00 02:3200:00s u = 1 insights

Sections Users GAP analysis

1

1

0

2 2 1

1

0

1 1 0

0 0

0 0

0

1

2

2

0

0 0

0

0

2

2 1 3

2 2 2 0

0

0

3

1

1 3

1 3

2

1

2

1 0

0

0 0

1

1

1 3

0

0 0

0 2

0

0

0 0

1

0

0 0

0 0

1

1

4

0

0 0

0 1

2

0

0

0

0

0

0

0

0

2

2

1

1 1

1

1

1 1

1

1 1 1

2

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

2

2 2

2

2 2

1

1

1

3

3

3

3

2

2

!!

!

!

!

!!

!!

!!

!!!

!!

!

! !! !

!!!

!!

tale tool ad inizio giornata per capire le mie performance e solo in un secondo momento utilizzerei la B.I. Analitica per uno studio più approfondito in caso di sottoperformance...” Advance User

”...Sintesi, avere un colpo d'occhio sul delta rispetto all anno scorso...” Expert User

lavoro...” Basic User

”...Analizzo un dato se c'è un trend o un anomalia...” Expert User

di vedere quotidianamente...” Advance User

”...Cognitiva senza l'analitica è limitante se non si è

giornaliera... ma l'analitica serve ad approfondire un Advance User

Matrix InsightsGli istogrammi visualizzano dati quantitativi e qualitativi user centerd, servendo daconfronto tra le due B.I..

!

TestCases

Sintesi 1

Sintesi 2

Sintesi 3

Oggi 4

Oggi 5

Oggi 6

Storico 7

Storico 8

Storico 9

Storico 10

Storico 11

Storico 12

Storico 13

Proiezioni 14

Proiezioni 15

Proiezioni 16

Proiezioni 17

00:05s 00:10s 00:20s 00:40s 00:60s 02:00 02:3200:00s u = 1 insights

Sections Users GAP analysis

1

1

0

2 2 1

1

0

1 1 0

0 0

0 0

0

1

2

2

0

0 0

0

0

2

2 1 3

2 2 2 0

0

0

3

1

1 3

1 3

2

1

2

1 0

0

0 0

1

1

1 3

0

0 0

0 2

0

0

0 0

1

0

0 0

0 0

1

1

4

0

0 0

0 1

2

0

0

0

0

0

0

0

0

2

2

1

1 1

1

1

1 1

1

1 1 1

2

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

2

2 2

2

2 2

1

1

1

3

3

3

3

2

2

!!

!

!

!

!!

!!

!!

!!!

!!

!

! !! !

!!!

!!

tale tool ad inizio giornata per capire le mie performance e solo in un secondo momento utilizzerei la B.I. Analitica per uno studio più approfondito in caso di sottoperformance...” Advance User

”...Sintesi, avere un colpo d'occhio sul delta rispetto all anno scorso...” Expert User

lavoro...” Basic User

”...Analizzo un dato se c'è un trend o un anomalia...” Expert User

di vedere quotidianamente...” Advance User

”...Cognitiva senza l'analitica è limitante se non si è

giornaliera... ma l'analitica serve ad approfondire un Advance User

Sintesi 2

Sintesi 1 Sintesi 3

Oggi4

Oggi5

Oggi6

Storico 7

Storico 8

Storico 9

Storico 10

Storico 11

Storico 12

Storico 13

Proiezioni14

Proiezioni 15

Proiezioni16

Proiezioni 17

Users InsightsI SandKey Diagram visualizzano il numero degli insights generati da tre utenti di Sphaera Cognitiva. Essi sono generati da due variabili: il numero Insight totale e il tempo medio di completamento per i tre utenti

Sintesi 2

Sintesi 1 Sintesi 3

Oggi4

Oggi5

Oggi6

Storico 7

Storico 8

Storico 9

Storico 10

Storico 11

Storico 12

Storico 13

Proiezioni14

Proiezioni 15

Proiezioni16

Proiezioni 17

Conclusioni

6. Conclusioni

Esistono numerosi modi di definire quando una visualizzazione di dati sia considerata efficacie: metodologie, tecniche, rappresentazioni creano un sistema variegato di punti di vista che descrivono un proprio concetto di efficacia in base a caratteristiche proprie.Per definire l’efficacia di una visualizzazione di dati, il designer deve saper riconoscere gli utenti, saper tradurrei loro bisogni in obbiettivi di valutazione e sapere in qualetipo di contesto la valutazione deve essere effettuata.In base a queste tre variabili il progettista può trovare una strategia coordinata di tecniche e metodologie che sono stabilite in un ordine definito. Il concetto di efficacia sem-bra più inserito nel contesto di scelta strategica definibile dal contesto User Centerd Design, che dalle singole tecniche di valutazione.Il percorso di questa ricerca è il frutto di esperienze che nonsi sono limitate all ambito accademico ma vi è stata la possibilità di poter applicare questa progettazione in uncontesto lavorativo reale: in questo modo è stato possibileconstatare l’efficacia delle tecniche di valutazione sul campo.Grazie a questa possibilità, si è cercato di applicare una strategia comune tra tecniche formali ed informali in modo da ridefinire attività di test utilizzate in ambito di sviluppo software in uno contesto legato alla visualizzazione di dati. Uno degli scopi di tale ricerca è riuscire a formalizzareun metodo di valutazione a forte componente etnografica che possa essere utilizzato nei più disparati settori dellaprogettazione degli sturmenti di Business Intelligence.Questa ricerca ha confermato che il concetto di valutazione è fondamentale nella progettazione e rientra nelle attività che

161

definiscono un progetto:nell’ambito business la valutazione deve essere uno degli scopi durante la progettazioe che devono essere condivisi con il cliente già nelle prime fasi di interazione e di defini-zione del prodotto.Nel contesto delle Business Dashboard l’efficacia delle visua-lizzazioni si definisce con gli aspetti di usabilità e di efficien-za del software: per questo motivo una valutazione solo di carattere qualitativo non può essere esauriente per validare il prodotto. Solamente mediante un approccio multi dimensionale, è che tenga conto della valutazione delle diverse nature del prodotto è possibile definire l’efficienza di questo.In conclusione, alla domanda di ricerca inziale si risponde che l’efficacia delle visualizzazioni di dati nel contesto del-le Business Dashboard si valuta mediante la progettazione di una singola strategia di valutazione basata su approccio UCD che riesca a creare metriche adibite a raccogliere dati sia qualitativi che quantitativi e che trovi nella multidiscipli-narità il suo valore caratterizzante.

162

Biblografia

Biblografia

Michele Mauri, Oltre la metafora del cruscotto - un modello per l’esplorazione visuale dei dati basato sui flussi, 2009

William H. Inmon, Building the Data Warehouse, 2002

D. J. Power, A Brief History of Decision Support Systems, 2003

William H. Inmon, Datawarehousing & Datamining, 2002

M.Maiocchi, M.Pillan, Design e Comunicazione, 2009

Anne Pezet Les French tableau de bord, 2006

S. Few, Information Dashboard Design - The effective visual communication of data, 2006

Donald A. Norman, The Design of Everyday Things, 1988

Wayne W. Eckerson The Future of Business Intelligence, 2016

Wayne W. Eckerson Performance Dashboards: Measuring, Monitoring, and Managing Your Business, 2006

165

Massimo Botta, Design dell’informazione - Tassonomie per la progettazione di sistemi grafici auto-nomatici, 2006

Stephen Few, Information Dashboard Design, 2006

Ben Shneiderman, Designing the User Interface: Strategies for Effective Human-Computer Interaction, 1987

Jeffrey Heer, Ben Shneiderman, A taxonomy of tools that support the fluent and flexible use of visualizations., 2012

Jakob Nielsen, 10 Usability Heuristics for User Interface Design, 1994

Edwarde Tufte, The Visual Display of Quantitative Information, 1983

Saskatchewan Univeristy Useful Junk? The Effects of Visual Embellishment on Comprehension and Memorability of Chart, 2011

166

Heidi Lam, Enrico Bertini, Petra Isenberg, Catherine Plaisant, Sheelagh Carpendale, Empirical Studies in Information Visualization: Seven Scenarios, 2014

D.Stone, C.Jarrett, M.Woodroffe, S.Minocha, User Interface Design and Evaluation, 2005

Paul Klee, Teoria della forma e della figurazione, 1976

Rudolph Arnheim, Arte e percezione visiva, 1974

Tomas Maldonado, Reale e virtuale, 1992

Giovanni Anceschi, L’oggetto della raffigurazione, 1992

Purvi Saraiya, Chris North, Karen Duca, An Evaluation of Microarray Visualization Tools for Biological Insight, 2005

Catherine Plaisant, Promoting Insight Based Evaluation of Visualizations: From Contest to Benchmark Repository, 2004

Ben Shneiderman, Catherine Plaisant, Strategies for Evaluating Information Visualization Tools: Multi-dimensional In-depth Long-term Case Studies, 2006

Alfred Kobsa, User Experiments with Tree Visualization Systems, 2004

Gragory Trafton, Turning pictures into numbers: extracting and generating information from complex visualizations, 2000

167

Robert L. Harris, Information Graphics: A Comprehensive Illustrated Reference, 1999

Carl Gutwin, Saul Greenberg, The Mechanics of Collaboration: Developing Low Cost Usability Evaluation Methods for Shared Workspaces, 2004

D.Stone, C.Jarrett, M. Woodroffe,S.Minocha, User Interface Design and Evaluation, 2005

Alvin R. Tilley, The Measure of Man and Woman: Human Factors in Design, 1993

168

Ringraziamenti

Ringrazio il Gentile Professor Paolo Ciuccarelli per l’aiuto e la disponibilità ricevuti.

Ringrazio Michele Mauri per il supporto e i preziosi consigli.

Ringrazio la mia famiglia per questi anni in cui ha dovuto sopportarmi...

Ringrazio Francesca per il suo contributo.

Ringrazio Luisa per avermi spronato a concludere il percorso.

Un pensiero particolare a miei nonni che ci sono sempre stati