Scarica Programmazione di interfacce Unipi e più Appunti in PDF di Programmazione e Tecnologie Web solo su Docsity!
PROGRAMMAZIONE DI INTERFACCE
LEZIONE 1 – 14/09 – Introduzione, design, interaction design
UNA NUOVA ERA – Perché è importante l’interazione uomo - macchina Negli ultimi anni il ruolo degli informatici è decisamente cambiato. Per anni l'informatico è stato chiuso in uno sgabuzzino ad interagire in solitudine con una tastiera, bevendo bibite gassate mentre qualcuno gli diceva che cosa serviva (o almeno era convinto di sapere cosa servisse) all'azienda per crescere. Questo corso è una trattazione adattata per informatici delle teorie di human computer (HCI) e human machine interaction (HMI) = interazione uomo-computer e interazione uomo-macchina (anche mondo della robotica). L'obiettivo è quindi gestire il processo di sviluppo delle interfacce e dei prodotti interattivi. Questo corso ambisce a spostare l'informatico dal suo tipico ruolo di sviluppatore elevandolo a progettista non solo del “codice” ma dell'intero prodotto. È ispirato alla teoria dell'interazione sviluppata dal Prof. Donald Norman. Nel corso verranno trattati anche aspetti relativi all'Internet delle cose e alle interazioni con robot e altri sistemi “smart”. Il prodotto È il risultato di un processo di design, qualsiasi cosa che una persona usa. Google è un prodotto, usato a servizio gratuito (monetizza attraverso altri sistemi). Nel corso parlerò spesso di prodotto, business, acquisto e altri termini legati al mondo della vendita, dell'economia e del mercato. Questo perché l'informatico deve sviluppare una consapevolezza fondamentale per il suo lavoro: un prodotto che nessuno compra è un prodotto inutile. Non importa quanto geniale sia il codice che avete scritto o rivoluzionario il sistema che avete implementato, se non vi curerete di far sì che questo artefatto venga apprezzato e quindi utilizzato dalle persone, la vostra creazione, geniale o stupida che sia, morirà dentro il vostro computer. Design La rivoluzione tecnologica degli ultimi anni ha portato a parlare molto di User Experience Design, User Interface Design, Interaction Design etc. Cosa si intende con il termine Design? Non è grafica , ma progettazione. Da Treccani: design - > «disegno, progetto», nella produzione industriale, progettazione (detta più precisamente industrial design ) che mira a conciliare i requisiti tecnici, funzionali ed economici degli oggetti prodotti in serie, così che la forma che ne risulta è la sintesi di tale attività progettuale; quando la forma dell’oggetto viene elaborata indipendentemente dalla progettazione vera e propria, si parla più propriamente di styling design. In Italiano tendiamo quindi ad usare il termine design per riferirci sia al processo di progettazione che al risultato stesso di questo processo:
- Processo: “E' stato avviato il design dell'interfaccia grafica”.
- Risultato del processo: “Ecco il design dell'interfaccia grafica pronto per essere implementato”. Per design si intende quindi sia il processo di progettazione e pianificazione che l'output stesso di questo processo. Può un informatico diventare designer? È importante notare che nel mondo del design, ed in particolare nel design industriale, si approccia alla risoluzione dei problemi e alla progettazione con una forma mentis molto diversa rispetto a quella “computazionale” tipica del mondo informatico. Nel 2006 Jeannette Wing, direttrice del Dipartimento di informatica della Carnegie Mellon University, formulò la seguente definizione di Pensiero Computazionale: il pensiero computazionale è un processo di formulazione di problemi e di soluzioni in una forma che sia eseguibile da un agente che processi informazioni. Il Computational Thinking non consiste semplicemente nel saper programmare, ma nel pensare a diversi livelli di astrazione, per “spacchettare” un problema in una serie di astrazioni con sempre maggior dettagli, fin quando il problema sarà risolvibile con un algoritmo. Il pensiero computazionale è quindi un processo mentale che consente di risolvere problemi di varia natura seguendo metodi e strumenti specifici, pianificando una strategia; abitua al rigore e rende possibili gli atti creativi.
Come tutte le scienze, ha i suoi fondamenti formali nel linguaggio matematico e ha a che fare con oggetti del mondo reale. Il pensiero computazionale è infatti basato sulla suddivisione di un problema in sotto-problemi così da poter giungere ad una formalizzazione del problema sotto forma di algoritmo (serie di passi). Nel mondo del design invece, la progettazione è tipicamente affrontata in maniera globale. L'obiettivo principale del design di prodotto non è necessariamente quello di trovare una soluzione al problema specifico ma è piuttosto quello di comprendere il problema nel suo insieme. Nel mondo del design il primo passo è sempre quello di capire perché il problema esiste e solo dopo aver appurato che l'origine di un problema non può essere eliminata o mitigata ci si adopera per cercare di risolverlo nello specifico. Viceversa, l'informatico medio non appena si trova davanti ad un problema, apre il proprio editor di testo e inizia a scrivere un algoritmo per cercare di risolverlo senza neanche chiedersi se il problema che si sta affrontando esiste veramente. Cioè: George Berkeley, un filosofo irlandese del '700 sosteneva che gli oggetti esistono solo in quanto percepiti. Dunque, se un albero cade in una foresta e nessuno lo sente, non fa rumore. Se un problema non è percepito da un utente allora quel problema non esiste. Nel design dell'interazione l'obiettivo primo è quindi quello di avere un utente soddisfatto non un software teoricamente perfetto o super-ricco di funzionalità. Questo può portare a situazioni che dal punto di vista informatico sono percepite come assurde. Nel design di prodotto ci si trova infatti spesso costretti a modificare i requirement e le specifiche di prodotto per andare in contro alle esigenze degli utenti, sacrificando funzionalità tecniche e qualità dell'implementazione software. Trovare il corretto bilanciamento fra esperienza utente, funzionalità e qualità tecnica è la parte più complessa dell'intero processo di sviluppo prodotto. Questo processo antropocentrico di adattamento del software alle esigenze dell'utente piuttosto che al virtuosismo tecnico è spesso vissuto dalla maggior parte degli informatici come un'assurda violenza. Per questo motivo è molto importante che gli informatici studino i principi del design, perché il mondo del design antropocentrico è per i tecnici tipicamente molto complicato da metabolizzare in quanto distante dal pensiero computazionale. È importante evidenziare che design dell'interazione e pensiero computazionale non sono mutualmente esclusivi, anzi! È nell'unione dei due e nell'integrazione dei due processi di studio e progettazione che nascono prodotti di successo e software di qualità. INTERACTION DESIGN Il mondo della progettazione è diventato talmente ampio e variegato che il termine design da solo ormai non ha quasi più significato. Esistono varie sotto discipline del design e con queste numerose professioni, metodi di lavoro, scuole di pensiero e altrettante immancabili faide e lotte fra fazioni. Un informatico può fare a meno di conoscere al completo il mondo del design ma non può esimersi da possedere i rudimenti base del “design dell'interazione”. Interaction design, o progettazione dell'interazione, è l'attività di progettazione dell'interazione che avviene tra esseri umani e oggetti in generale. L'obiettivo principale dell'interaction design è quello di rendere macchine, servizi e sistemi usabili dagli utenti per cui sono stati pensati e realizzati e non solamente dai propri creatori. All'interno di un processo di interaction design, si investigano l'uso che verrà fatto dell'artefatto e il target a cui esso si rivolge. Questo significa che le questioni legate agli utenti guidano il processo più di quanto non facciano le questioni tecniche. Gli sviluppatori devono mettere al centro del processo di sviluppo i bisogni degli utenti, arrivando a realizzare un prodotto più appropriato e maggiormente usabile. Le forze trainanti lo sviluppo di un prodotto dovrebbero essere quindi gli utenti reali e i loro bisogni e non solo le tecnologie.
LEZIONE 2 – 15/09 – Design del prodotto, designer, UX e UI design
L'obiettivo principale del HMI e HCI design è quindi rendere possibile e facilitare al massimo, per un essere umano, l'uso e l'interazione con sistemi del mondo IT (Information Technology) quali, calcolatori, dispositivi mobili, servizi web etc.
Il UXD è il processo volto ad aumentare la soddisfazione e la fedeltà del cliente migliorando l'usabilità e il piacere fornito nell'interazione tra il cliente e il prodotto. La UXD comprende la tradizionale progettazione dell'interazione uomo-macchina e la estende integrandola con tutti gli aspetti di business, marketing e sviluppo prodotto necessari per garantire il successo del prodotto e/o servizio. Lo UX Designer ha quindi l'obiettivo di far vivere all'utente del suo prodotto la miglior esperienza possibile, evitando che l'oggetto induca nell'utente sensazioni di frustrazione e delusione. Spesso si tende a dire che si “progetta l'esperienza utente”. In realtà è impossibile progettare l'esperienza utente perché ogni utente è diverso dall'altro ed è quindi illusorio pensare che chiunque durante l'utilizzo del prodotto si comporti alla stessa maniera e in particolare si comporti esattamente come il progettista ha ipotizzato. Si dice meglio “progettare per l’esperienza utente”. Lo studio e la progettazione dell'esperienza utente partono sempre dalla analisi e comprensione delle esigenze dell'utente e non dalle specifiche funzionali di prodotto. Tutti i prodotti che sono usati da qualcuno hanno una user-experience: giornali, bottiglie di ketchup, maglioni, ecc… User Interface Designer (UI design) Lo UI designer non costruisce quindi l'interfaccia utente, nei team numerosi questa figura è spesso un progettista grafico e non un informatico. L'obiettivo dello UI designer è quello di progettare l'aspetto estetico e la struttura dell'interfaccia così che questa durante l'utilizzo induca l'utente nel seguire l'esperienza che è stata per lui progettata. Dice ad esempio che il menù è in alto, che il tasto new è sulla destra. Lo UI designer produce in output quindi un wireframe, una bozza grafica dell'interfaccia e una serie di linee guida che poi verranno seguite dagli sviluppatori (UI developer o Front-end developer) per implementare la reale interfaccia del prodotto o servizio. Entrambi gli output vanno al front-end. Lo UID ha bisogno di pensare in termini di forme, superfici, sfumature, consistenza, aspetto visivo del progetto in base alla UX fornita. Il processo di Product Design include quindi varie figure e discipline. In grandi team questi step sono eseguiti tipicamente da diverse persone, ma spesso nella media e piccola impresa o startup questo percorso deve poter essere seguito in autonomia da una o al massimo due figure. L'interfaccia vera e propria viene implementata quindi solo alla fine del percorso di progettazione da figure con profilo tecnico informatico (Front End Developer o UI Developer). Queste figure devono essere in grado di comprendere le richieste provenienti dagli step di progettazione precedenti e devono possedere le basi dell'Interaction Design e delle relative sotto discipline. Lo UI dovrebbe avere la capacità di trasformare la configurazione UI e UX data in HTML, CSS, Javascript, altri linguaggi. Il vero compito del front-end engineer è quello di dare l'ultimo risultato con tutti i flussi di connessione rappresentati nell’UI design da un UI designer. → Figma per i wireframe navigabili. Il Design dell'interazione ha come focus il modo in cui le persone interagiscono con la tecnologia, lo scopo è migliorare la loro comprensione di ciò che si può fare, ciò che succede e ciò che è appena successo, basandosi su principi psicologici, tecnici ed estetici. Dallo studio della UX si crea quindi uno schema di interazione che poi viene passato allo UI Designer che ha il compito di progettare l'interfaccia utente al fine di abilitare l'esperienza progettata.
LEZIONE 3 – 21/09 – Design antropocentrico (Human Centered Design)
HUMAN CENTERED DESIGN (HCD)
I progettisti devono produrre cose che soddisfino i bisogni della gente, in termini di funzioni, facilità d’uso e gratificazione emotiva. In altre parole, il design (di prodotto) deve essere pensato come un’esperienza totale (per l'utente). Le persone sono sempre più frustrate dalla complessità degli oggetti quotidiani. Dalla complessità sempre maggiore del cruscotto dell'auto, dalla lavatrice piena di incomprensibili funzioni e pulsanti, dalla crescente automazione della casa, e dalla continua proliferazione di funzioni che i progettisti aggiungono con orgoglio ad ogni nuova versione dei loro prodotti. La vita della maggior parte degli utenti è ormai diventata una battaglia quotidiana per la sopravvivenza alla invadente e iper-funzionale tecnologia. Questo problema origina direttamente dalla modalità con la quale vengono oggigiorno progettati gli oggetti quotidiani ed in particolare quelli tecnologici. Le macchine (computer) hanno una modalità di funzionamento logica, dovuta all'algoritmo che il progettista ha sviluppato come anima della macchina. Noi umani invece siamo tutt'altro che logici e razionali, siamo intuitivi, flessibili, versatili e curiosi. È chiaro quindi che nell'interazione uomo-macchina si va a creare una relazione fra specie diverse che hanno modalità di pensiero e di funzionamento opposte. Gli ingegneri e gli informatici, orgogliosi dei loro progressi tecnologici, hanno preteso da sempre che gli umani si adattassero alle loro macchine. Le macchine sono viste dai progettisti come un elemento di orgoglio che rappresenta il progresso e chi non è in grado di capirle è retrogrado, vecchio e a volte anche un po' stupido. Questo approccio tecno-centrico dei progettisti ha in realtà leso lo sviluppo stesso della tecnologia dal momento che ne ha rallentato la sua diffusione e accettazione. La maggior parte degli utenti oggi è frustrata dall'utilizzo di incomprensibili oggetti tecnologici di cui non capisce il principio di funzionamento e dove tipicamente si limita ad utilizzare il 10% delle funzionalità disponibili. Le macchine hanno delle loro regole di funzionamento che sono spesso note solo ai progettisti. Quando non si seguono queste regole le cose non vanno come previsto e l'utente si sente stupido ed incapace. La macchina è perfetta, non può sbagliare, quindi se le cose sono andate male è sicuramente colpa dell'umano. È vero! ma non è l'umano utente ad aver sbagliato, la colpa è del progettista! Nel design antropocentrico si inverte il paradigma di progettazione mettendo l'utente al centro del processo. Le funzionalità del prodotto vengono dopo. Prima ci sono i bisogni dell'utente! Questo approccio favorisce un corretto comportamento dell’uomo, la sua soddisfazione. Questo processo, apparentemente ovvio e banale, risulta in realtà estremamente difficile da applicare per gli informatici. I tecnici infatti amano le funzioni e le funzionalità, amano le peculiarità tecniche dei sistemi e sono spesso spinti a sviluppare nuove soluzioni non tanto per risolvere il problema ma piuttosto per la soddisfazione personale di aver implementato qualcosa che prima non esisteva. La blockchain, creata per diletto da degli appassionati di crittografia, ha dato vita alla prima criptomoneta della storia. Dopo il boom di Bitcoin e delle altre cripto-monete è scoppiata la bolla blockchain dove tutti nel mondo IT hanno iniziato a dichiarare che grazie alla blockchain si sarebbe potuto innovare in maniera radicale tantissimi
- Specificare i Requirements: identificare i business requirement e gli obiettivi utente che devono essere raggiunti grazie all'utilizzo del software; si inizia ad implementare qualcosa che poi verrà testato: dai risultati dei test vengono messi in discussione i requirements precedenti, che vengono eventualmente modificati.
- Progettare la soluzione: questa fase può essere a sua volta spacchettata in sotto fasi iterative. Si passa tipicamente da delle bozze a dei prototipi e poi alla soluzione;
- Testare e valutare: è fondamentale testare e quindi valutare il sistema così da poter iniziare il ciclo sulla base dei risultati dei test e quindi procedere ad uno sviluppo e miglioramento incrementale. Per ora, al fine di inquadrare meglio la filosofia HCD nel contesto dello sviluppo software vi basti pensare che le versioni alfa e beta dei nostri software possono diventare potenti strumenti di analisi degli utenti. Le versioni di test non servono quindi solamente a fare debugging del codice e delle funzioni, ma servono anche e soprattutto a capire che cosa fanno e come si comportano gli utenti durante l'utilizzo del nostro software. Nello sviluppo software diventa quindi indispensabile abilitare dei sistemi di tracking dell'utente finalizzati alla produzione di statistiche di utilizzo (capire quale funzione è considerata utile e quale inutile). PROGETTARE L’INTERAZIONE Esistono solo due tipi di design, riuscito e fallito; buono e cattivo (D. Norman). Il problema è che il buon design non è universale. Un progetto, prodotto o sistema apprezzato da tutti non esiste perché l'esperienza di interazione è soggettiva e quindi dipende più dalla persona che non dell'artefatto e di conseguenza è statisticamente impossibile progettare qualcosa che sia apprezzato da chiunque. DISCOVARIBILITY È la capacità di un sistema di veicolare e comunicare i propri possibili usi all'utente. Un sistema che a prima vista fa capire all'utente a cosa serve e che cosa ci si può fare ha una buona Discoverability Per avere una buona discoverability si usa tipicamente la visibilità. Non è detto però che una volta capito cosa si può fare si riesca a farlo. ES: il telecomando ha una buona visibilità, sappiamo cosa ci possiamo fare ma non ancora come (non sappiamo cosa faccia il pulsante f1 ). → Nel secondo caso si è aumentata la visibilità, e anche la discoverability. Il prodotto deve raccontarsi da solo, non dipende da noi
UNDERSTANDING
È invece la capacità del prodotto di farsi usare correttamente dall’utente. Se la discoverability è la misura di quanto bene si capisca cosa si può fare con il prodotto, la understending invece è la proprietà associata a quanto bene un prodotto dice come si usano le funzioni disponibili. Per capire come si usa un prodotto non basta infatti aver identificato quali sono i controlli, è necessario dare con facilità risposta alle seguenti domande:
- Come si usa il prodotto?
- Che funzione ha ciascun controllo?
- Come si combinano i controlli? Design of Useful things Questi due aspetti sono importanti per evitare la frustrazione dell’utente - > aiutano a ridurre il numero degli errori che l’utente può commettere, a istruire l’utente e recuperarlo dall’errore. Infatti: quando le cose vanno bene, si dimenticano subito, quando vanno male non si dimenticano mai! Se fatti bene, i prodotti sono brillanti e piacevoli. Se fatti male, sono inutilizzabili, causano frustrazione e irritazione. Le macchine sono limitate: sono rigide, richiedono sempre una procedura esatta, non hanno esperienza, non possono fare le cose in maniera “mediocre”: l’uomo è diverso ma si adatta e quando sbaglia la colpa è sua - > la prospettiva è da ribaltare. L’informatico crede che la spiegazione logica sia sufficiente per far comprendere all’utente l’uso di un qualcosa, basta leggerlo sul manuale - > il problema con i progetti della maggior parte degli ingegneri è che sono troppo logici. Dobbiamo accettare il comportamento umano così com'è, non come vorremmo che fosse. Esempio: incidente nucleare a Three Mile Island, a causa di un blocco di un sistema di raffreddamento, la temperatura sale, si attiva un circuito alternativo ma la temperatura continua ad aumentare, pur seguendo le linee guida del protocollo il nocciolo è scoppiato - > l’operatore non ha conoscenza e lucidità per mettere in discussione il pannello, l’errore è stato del progettista del quadro di controllo. La vita è fatta di esperienze, anche lavorare con un software è per l’utente un’esperienza.
LEZIONE 5 – 28/09 – Affordances, Signifiers, Mapping
Quando interagiamo con un prodotto, dobbiamo capire cosa fa, come funziona e quali operazioni sono possibili. Per mediare la Discoverability si sfruttano 6 principi fondamentali che guidano l’interazione Uomo – macchina:
- Affordances : relazione tra le capacità e le proprietà di un oggetto fisico – e le proprietà di una persona. Un oggetto non “afforda” sempre per le stesse cose, le affordance non sono oggettive: dipende dal contesto, dalla persona che lo utilizza - > ES: il bottone “invita ad essere premuto da chi ha le mani, una scala “afforda” per essere salita da una persona normo-dotata, una sedia invita a sedersi (ma non a un bambino). Le affordances sono legate all’utente che abbiamo scelto come riferimento, sono opportunità d’azione. Ci sono anche gli anti-affordance, deterrenti, prevenzione di un’interazione: la strada contrasta l’andare veloce. Le affordances devono essere percepibili, le affordances percepite ma non progettate portano l’utente ad usare in una maniera non progettata e non prevista l’oggetto (esempio del vetro non attraversabile). Per dare visibilità a una affordance e stabilire la corretta interazione uomo – oggetto si usano i significanti o si riduce lo spazio di utilizzo dell’utente, perciò ad es Google home permette pochissime funzioni di tocco. NB: le affordances non sono proprietà, ma relazioni. Nel primo caso non è chiaro l’associazione tra pulsante e fornello, nel secondo caso i pulsanti riproducono il mapping dei fornelli - > l’understanding aumenta.
Bisognerebbe raggruppare i significanti per affinità in base ai significati che veicolano, vicinanza di funzionalità o di contesto di utilizzo. Esempio: word, icone vicine di bold, italic, ecc.. + vicinanza di allineamento del testo. Il mapping ci aiuta anche a evitare gli errori - > elementi rischiosi da utilizzare lontani dagli altri. Esempio: macchina in Europa si scorre da sx verso dx, macchina in Giappone dall’alto al basso. → l’errore sta che la campanella è al posto dello zero + ordine 6 F 7 perché al piano 6 o 7 c’è sia la porta del piano che quella del fitness. → questa interfaccia è più facile da navigare e da vedere perché viene utilizzata tante volte. LINK UTILI: https://www.youtube.com/watch?v=UtulTXJLGOI&ab_channel=LeahGreis
LEZIONE 6 – 29/09 – Feedback, Conceptual Model, Mental Model, System Image
- Feedback: è la comunicazione del risultato di un’azione, una risposta che l’interfaccia dà all’utente. Esempio dell’ascensore per un palazzo di 100 piani che non ci dice cosa sta accadendo. L’utente deve sapere cosa la macchina sta facendo: se perde fiducia non la userà più. Il feedback deve essere immediato ed esaustivo. Se impiega troppo tempo l’utente non lo riterrà legato all’azione. Un esempio utile di feedback immediato è quello tattile, come sulla tastiera del telefono. Deve essere informativo, semplice e conciso, anche troppi feedback sono controproducenti, portano l’utente a perdere la concentrazione su cosa sta facendo + a ignorarli. Deve mantenere l’ambiente calmo. Esempio: tre bip della lavastoviglie, nessuno attende i tre bip, dunque si tratta di un eccesso di feedback. Feedback e notifiche non sono la stessa cosa, ma anche le notifiche hanno gli stessi problemi dei feedback - > per le troppe notifiche solitamente l’utente le disabilita o mette il telefono in modalità silenziosa - > come far arrivare una notifica davvero importante? Molti utilizzano i messaggi, che ormai sono utilizzati molto poco.
- Conceptual Model: è uno degli argomenti più importanti. I punti precedenti sono legati alla psicologia umana, quest’ultimo non è un vero e proprio principio ma è parte integrante del processo di ideazione del prodotto o interfaccia ed è la spiegazione semplificata di come funziona il nostro prodotto, come il designer vorrebbe che l’utente lo percepisca. Non completa ma utile. Esempio: file e cartelle sul PC, per spiegare l’organizzazione all’interno del disco è stato utilizzato il modello di organizzazione dei contabili in cartelle, ecc… Il concetto di file e cartelle è una pura astrazione finalizzata a raccontare in maniera semplificata come funziona il sistema. L’obiettivo è creare un modello concettuale il più semplice possibile, per farlo arrivare a più persone possibili: la soglia di semplificazione è difficile da trovare, semplificando troppo l’utente non capirà esattamente la funzione del prodotto.
Esempio del Cloud: i file sembrano essere sul dispositivo ma invece sono nel cloud. Se non c’è connessione il servizio del cloud è interrotto e il risultato può essere confusionario perché i file continuano ad essere mostrati all’utente ma egli non può aprirli - > la semplificazione è utile fin quando le ipotesi che la supportano sono vere. L’utente non vuole studiare, vuole apprendere senza saperlo. Mental Model: è il modello mentale che l’utente si fa del prodotto (ciò che ne ha capito), diverso dal modello concettuale perché dipendente dalla base culturale dell’utente. Più c’è distanza tra CM e MM più ci potranno essere errori e viceversa. Una stessa persona può anche avere più MM dello stesso prodotto, perché non lo ha capito bene e procede per tentativi e ipotesi su come funzioni. Bisogna immaginare le possibili interpretazioni dell’utente. Il CM non è nel manuale, è solo nella nostra mente: per trasferirlo bisogna sfruttare le affordances, i signifiers, ecc… è importante che sia il device stesso a trasmetterlo, non che l’utente lo apprenda da terzi. La maggior parte dei MM viene comunque costruito con l’esperienza: è più efficiente raggruppare i comandi, creare dei significanti chiari, usare dimensioni e forme diverse per i bottoni, ecc.. perché tutto ciò è percepito in maniera innata. Esempio di buon CM: le forbici. Possono essere narrate in modo semplice grazie alle sue affordances, fori in cui inserire le dita, parte metallica che taglia e che nessuno afferra. I CM possiamo portarli nel software facendo leva su quello che le persone conoscono: esempio di Skype che riprende la tastiera di chiamata del telefono. Ci sono le lettere anche se non serve, per richiamare appunto il telefono e far capire che non si tratta di una chiamata Skype ma di una chiamata telefonica a pagamento. System Image: le persone tendono a creare un MM di qualsiasi cosa, attraverso l’esperienza o la formazione e la ricezione di istruzioni. Come fanno gli uomini a formarsi un modello concettuale adeguato dei dispositivi che utilizzano? Non potendo parlare con il progettista, essi si basano su tutta l'informazione accessibile: l'aspetto dell'apparecchio, cosa hanno imparato dall'uso di oggetti simili in passato, cosa comunicano le pubblicità, i venditori, i pieghevoli illustrativi, il sito web e il libretto di istruzioni. L'insieme di tutta questa informazione è l'immagine di sistema. L’immagine che l’utente si fa del sistema gli permette di produrre il MM. Non c’è quindi comunicazione diretta tra designer e utente, è il prodotto che si narra da solo. Attenzione a non veicolare SI incoerenti o inappropriati: questo porterà l’utente a non poter utilizzare il prodotto. Un prodotto complesso da utilizzare sarà anche l’immagine che l’utente avrà dell’azienda. I MM vengono fuori anche tra team e team, non solo quando il prodotto arriva all’utente finale. Esempio: termostato impostato a 20, temperatura segnalata a 17°, è da alzare? No anche se può essere istintivo perché solitamente per aumentare un’intensità si muove una manopola (gas, rubinetto acqua), qui invece il termostato è già acceso e anche aumentando la temperatura la caldaia non andrà più veloce. Il MM creato della caldaia è errato.
CONSTRAINTS CHE FORZANO IL COMPORTAMENTO DESIDERATO
Sono dei casi estremi di vincoli forti: sono obbligatori e servono ad evitare comportamenti inappropriati dell’utente. Le azioni sono vincolate in modo che un passaggio mancato impedisca di procedere al successivo. Sono vincoli fisici. In base alla forzatura avremo tre categorie di questi vincoli (detti forcing functions , funzioni obbliganti):
- Interlocks, forza le operazioni nella giusta sequenza prima di avviare l'azione richiesta (premere un controllo con il piede e due con le mani per evitare di schiacciare le mani nella pressa, frullatore che non funziona senza coperchio, verifica della mail). Sono usati soprattutto come sistemi di sicurezza nei macchinari industriali ma anche nel mondo software come per esempio nel caso dei sistemi Captcha.
- Lock-ins, blocca l’utente nello stato corrente fin quando non prende una decisione o fa un’azione (richiedere di salvare prima di uscire). Blocca nell’andare allo stato successivo, evita che si interrompa una funzione prematuramente. NB: qui non si va nello stato successivo, nell’interlock invece sì.
- lockout, trattiene qualcuno in uno spazio o previene un’azione pericolosa fin quando viene svolta l’azione desiderata, previene che qualcuno entri in uno spazio pericoloso. Bloccare un utenza perché ha immesso troppe volte credenziali sbagliate è un esempio di lock-out. Per superare il blocco bisogna attendere o seguire delle specifiche procedure. ACTIVITY CENTERED CONTROLS L’activity centered design è un’estensione del paradigma HCD: comandi centrati sull’attività dell’utente. Le features ACD danno enfasi alle attività che un user farà con una tecnologica datagli. Sono un altro modo di utilizzare i vincoli, un modo di interagire con il dispositivo in base a quello che l’utente vuole fare. In Google sono le routine. ES: bottone che non abilita una feature (accendi luce, spegni, accendi monitor), ma un’attività che l’utente vorrebbe fare (modalità lezione, modalità compito). Il problema è che ogni utente è diverso e vuole fare attività diverse. È estremamente difficile fare la progettazione ACC perché mappare le attività sugli utenti è estremamente complesso. Un’attività generalista che vada bene per tutti non esiste. È utile quando si creano funzioni in ambiti specializzati, come l’auto-fit su PS. Sono difficili da usare come utenti generalisti, ma molto utili come utenti esperti in software specifici. Gli ACC sono eccellenti nella teoria, ma difficili da realizzare bene nella pratica. Se sono fatti male creano difficoltà. Gli ACC si basano sull’attività dell’utente e non del software: devono essere User activity centered, se invece sono device-centered l’utente dovrebbe conoscere il modello tecnico dietro il sistema. L’utente deve rimanere tale e non deve essere influenzato. Esempio del telecomando Harmony di Logitech: consente di controllare vari dispositivi attraverso un modello di interazione basato sugli activity centered controls. Non si seleziona più il dispositivo che si vuol controllare ma l'attività che si vuol fare: Play Game, Watch TV, etc..
LEZIONE 8 – 06/10 – Golfi, 7 step e 7 principi
COME FANNO LE COSE LE PERSONE?
Se le cose vanno male come farlo capire all’utente? Bisogna analizzare la psicologia dell’individuo e un semplice modello di come le persone scelgano e valutino le loro azioni. È una similitudine per dire che il percorso lineare è quello che si auspica l’utente faccia anche se poi non sarà così. Ogni azione è quindi composta da due parti: l’esecuzione e la valutazione dell’azione. Il golfo della valutazione è stretto quando il dispositivo fornisce le info sul proprio stato, in una forma facile da cogliere. Il golfo dell’esecuzione si migliora con signifiers, constraints, mapping, modello concettuale adeguato; quello di valutazione con modello concettuale adeguato e feedback. È importante studiare i golfi e immaginare l’utente intento ad interagire con il sistema e percepirne il feedback perché quando egli sbaglia si incolpa dell’errore e prova frustrazione. Oppure, se non riesce a percepire un modello concettuale corretto pensa che il sistema sia troppo complicato e smette di utilizzarlo. In realtà, le difficoltà risiedono nella progettazione delle cose, non nelle persone che cercano di usarle. Sia l'esecuzione che la valutazione richiedono comprensione di come funziona l'oggetto e quali risultati produce + possono influenzare il nostro stato emotivo. 7 Stadi dell’azione Per prima cosa specifichiamo il nostro obiettivo, il goal, il risultato che vogliamo (esempio di invio dei dati di una form) quindi passiamo alle 3 fasi di esecuzione + 3 fasi di valutazione = 7 stati dell’azione (3 per ogni golfo): Non è detto che vengano eseguiti tutti i punti, l’utente esperto ad esempio sceglie obiettivi di più alto livello. Inoltre, non è detto che tutti gli utenti abbiano, a parità di preparazione, lo stesso loop, perché può magari interpretare in maniera leggermente diversa un certo feedback. Quando le persone usano qualcosa, ci sono due fasi:
- Una legata all’esecuzione, quando cercano di capire come operare.
- Una legata alla valutazione, quando cercano di capire cosa è successo. È la teoria dei due golfi. Il compito del progettista è quello di aiutare gli utenti a superare i due golfi e renderli il meno profondi possibili. Si dice golfo perché: il modo più semplice per interagire con un sistema è avere un ponte.
- Definisco il goal
- Pianifico l’azione da eseguire
- Trasformo l’azione in una sequenza di passi per compierla
- Eseguo la sequenza
- Percepisco il nuovo stato, un feedback
- Lo interpreto (l’interpretazione può dipendere dal background culturale)
- Confronto con lo stato iniziale, per capire se ho raggiunto il goal + stabilire nuovo
La maggior parte delle operazioni del cervello sono sub consce. Solo il livello più esterno è conscio. La modalità conscia utilizza la parte più giovane della corteccia, consuma molto glucosio. La modalità sub conscia lavora a basso livello energetico, ma senza possibilità di manovra. L'attenzione cosciente è necessaria per apprendere la maggior parte delle cose, ma dopo l'apprendimento iniziale, la pratica e lo studio continui, a volte per migliaia di ore nel corso di un periodo di anni, produce ciò che gli psicologi chiamano "apprendimento eccessivo", fatto automaticamente, con poca o nessuna consapevolezza. La modalità di pensiero sub conscia funziona come l’intelligenza artificiale = modalità pattern matching, trovando la migliore corrispondenza possibile tra esperienza passata e attuale. È uno dei nostri punti di forza. Come ci ricordiamo le nostre esperienze se spesso lavoriamo in modalità sub conscia? Con la memoria esperienziale, ricordo di un esperienza fatta. Bisogna sapere come i nostri utenti funzionano per capire come poterci lavorare: nella modalità cosciente l’utente è esagerato, ha una modalità di ragionamento alto e va quindi guidato, nella modalità subconscia non abbiamo spazio di manovra. Ci sono due tipi di memoria: dichiarativa (usata a scuola) e procedurale (esempio del legarsi le scarpe, non si riesce a spiegarlo senza una scarpa perché lo conosciamo solo in termini procedurali e non in termini teorici e dichiarativi). NB: memoria procedurale molto vicina al subconscio. Il nostro sistema nervoso non è limitato al funzionamento neurale, ciò che avviene nel nostro cervello, ma è influenzato anche da omoni, neurostimolatori, ecc…: le emozioni modificano il rilascio di questi elementi, che vanno a influenzare il procedere del nostro cervello, rendendolo più propenso al conscio o al sub conscio. ES: situazione di pericolo, produzione di adrenalina per uscire dalla modalità sub conscia e agire. Gli stati emozionali positivi favoriscono il pensiero creativo e la mente cosciente; percepiamo uno sforzo minore. L’utente frustrato invece lavora istintivamente, fa fatica ad apprendere anche cose semplici: questo è l’utente su cui lavorare. Il modo con cui il nostro cervello fa processing è divisibile in tre livelli procedurali, i quali contribuiscono tutti insieme a determinare lo stato emotivo e cognitivo dell'utente:
- Livello viscerale, gestito dal livello più basso del cervello, emette giudizi sull’ambiente: cosa è buono, cattivo e pericoloso. Permette di rispondere velocemente e in maniera sub conscia, senza consapevolezza. Qui devono lavorare bene i designer del front-end: la sensibilità estetica, l’apparenza, l’attrazione o repulsione guida il livello viscerale. Questo sistema non ha apprendimento.
- Livello comportamentale: skill già apprese (sapere come si lanciano i programmi, pulsanti login vs signup) in circostanze più o meno simili a quelle attuali. Sia questo livello che quello precedente fanno parte del sub conscio. Stabilisce in che modo si compie una certa azione e in che modo si interpreta un certo feedback. Il feedback gestisce le aspettative, le conferma o meno, determinando soddisfazione o frustrazione.
- Livello riflessivo: livello conscio, in cui avviene la riflessione sull’aver raggiunto o meno il goal + il processo decisionale. È questo livello che “scrive in memoria”: ricordiamo di aver riflettuto su un’azione, anche se poi svolta in maniera automatica. È anche il livello più emotivo per soddisfazione e frustrazione. Per educare l’utente e far sì che apprenda bisogna tenerlo sul livello riflessivo: qui è conscio e le emozioni che egli produce sono le più durature. La riflessione spesso avviene dopo che le azioni sono avvenute. Il subconscio controlla e utilizza comportamenti già acquisiti, quello conscio è lento e guidato, non automatico, usa il raziocinio ed è richiesto per apprendere o per uscire da situazioni inattese, quando cioè il pattern matching non funziona. Qui è dove meditiamo lentamente sulle decisioni, pensiamo alle alternative, confrontiamo scelte diverse.
LEZIONE 10 – 13/10 – Errore umano, slips e mistakes, prevenire gli errori
Tra il 75% e 95% degli incidenti industriali avvengono per errori umani, ma ciò non significa che le persone siano incompetenti, il problema è di design (errori di progettazione). Tipicamente noi chiediamo agli utilizzatori dei nostri prodotti la capacità di avere l’attenzione molto alta per tanto tempo. Il nostro cervello fa però di tutto per lavorare in maniera sub conscia. La maggior parte degli errori è dovuta all’interruzione, la quale distrugge il flusso di ragionamento, si rompe il golfo. L’attitudine umana verso la gestione dell’errore: individuare un colpevole, ma del sintomo e non della causa. La ricerca dell’origine del problema è complessa, ma è possibile sfruttare delle tecniche come la Root Cause Analysis
indagare l’incidente finché non si scopre la causa. Due difetti: la maggior parte degli incidenti non ha una sola causa. Solitamente l'analisi delle cause profonde si ferma non appena trovato un errore umano. “Swiss cheese model of accidents”: i problemi accadono perché esiste un’unica condizione per cui tutte le cause si manifestino in un certo ordine tale da portare ad un errore. Per risalire all’origine si utilizza la Tecnica dei 5 perché (Toyoda): non ci si può fermare al primo perché, ma ci si chiede almeno 5 perché consecutivi. Con questa tecnica non ci si ferma all’effetto finale, ma si arriva all’origine delle cause. Inoltre, oggettiva l’analisi. Quando le persone sbagliano, bisogna cambiare il sistema in modo da evitare l'errore e, se non è possibile eliminarlo del tutto, almeno fare in modo di ridurne gli effetti. Se il sistema lascia sbagliare gli utenti è mal progettato, se il sistema induce all'errore, allora è progettato malissimo. Perché le persone sbagliano? Perché il design si concentra sulle esigenze del sistema e delle macchine, non su quelle degli utenti. Si definisce errore umano ogni deviazione dal comportamento appropriato. Esiste un modo per classificare gli errori: slips (lapsus), mistakes (errori cognitivi). Gli slips avvengono quando una persona vuole fare un’azione, l’ha già pianificata, ma finisce per farne un’altra. Due sottocategorie: slips di azione (pianificazione corretta ma azione sbagliata), slips di memoria (dimenticare e saltare una delle azioni pianificate). ES1: mattina, mettere in frigo la tazza di latte invece che il cartone. ES2: dopo aver cucinato dimentichiamo di spegnere il gas. Gli errori cognitivi (mistakes) avvengono quando viene prefissato un goal errato o è sbagliata la pianificazione. Con questi errori, l’azione matcha con la pianificazione, ma è quest’ultima ad essere errata. Tre sottocategorie: 1. Negli errori cognitivi di regola l’utente ha conoscenza di come funziona il sistema, ma pianifica seguendo una regola operativa errata. Forse la conoscenza non era completa. ES: termostato, sappiamo per cosa serve ma
Per minimizzare gli slips non si può pensare di tenere sempre l’utente in modalità cosciente, gli slips vanno gestiti dopo che sono accaduti: possiamo evitare l’errore ma non la singola causa, non possiamo eliminare gli slips. Gli errori non si possono eliminare, ma solo prevenire e ridurre, ad esempio riducendo il numero di interruzioni e realizzando percorsi corti e lineari, e dando feedback corretti. Usare feedback vocali può essere utile ma in pochi contesti l’interazione vocale è appropriata e apprezzata. Altre tecniche sono quelle di ridurre il più possibile i controlli nella pagina: ogni volta si dà poca informazione. Ti guido step by step nel prendere le decisioni, dandoti la possibilità di tornare indietro. Gli slips avvengono soprattutto quando siamo in modalità sub conscia. Ogni volta che chiediamo l’attenzione, si crea un’interruzione, quindi non è una buona idea volere che l’utente sia sempre attento. La modalità subconscia è veloce, efficiente e solitamente accurata. Il modo migliore per minimizzare gli slips è dare dei feedback percettibili sulla natura dell’azione compiuta, e poi feedback sul nuovo stato del sistema, assieme ad un meccanismo che permetta di tornare indietro in caso di errore. Un altro modo è quello di creare routine dove nella serie di azioni, ogni azione è il più diverso possibile dalle precedenti e successive. Non sempre è possibile: un esempio è l’inserimento di più dati in una form. Il modello a fette di formaggio suggerisce, per ridurre gli errori:
- Aggiungere più fette, cioè più controlli
- Ridurre il numero di buchi (possibile falla), o rendere quelli esistenti più piccoli (separando i comandi, utilizzando i sensibility check).
- Allertare l’utente quando ci si sta pericolosamente avvicinando ad una situazione in cui “troppi buchi del formaggio” sono allineati. Esempio: più bonifici, al terzo il nostro conto va a soli 100 euro - > messaggio per avvertire l’utente, anche se non si tratta di un errore e si sono passati i sensibility check. Tutte queste soluzioni hanno delle implicazioni: più fette di formaggio implicano più linee di difesa (più checks e step di controllo) e il software diventa più pesante e noioso; ridurre il numero di buchi dove possono comparire errori porta a scelte di design che richiedono diverso tempo. Altri elementi principali che supportano la riduzione degli errori:
- Dare all’utente più elementi possibili per crearsi il set di conoscenze necessarie per comprendere il sistema.
- Sfruttare il potere dei constraints naturali e artificiali: fisici, logici, semantici e culturali.
- Creare un ponte tra i due golfi, quello dell’esecuzione e quello della valutazione, rendendo visibili aspetti sia per l’esecuzione (rendere visibili le opzioni) che per la valutazione (i risultati delle azioni, i feedback). https://uxdesign.cc/how-to-prevent-your-users-from-making-mistakes-d641c6260b Esempio: eliminazione, messaggio di warning “inserisci il nome del dispositivo che vuoi eliminare”, “fai 3*2” - > content switch ma voluto. INTERFACCE UTENTE Un'interfaccia è qualcosa che sta fra due facce. È il punto di contatto fra due sistemi che tentano di comunicare. Le interfacce possono far comunicare due macchine fra loro oppure l’uomo con la macchina. Lo strumento è ciò che fa qualcosa, l’interfaccia è ciò che serve per guidarlo nell'esecuzione dell'azione. Quando parliamo di Interfaccia Utente (User Interface o UI) intendiamo lo spazio di un sistema dove avviene l'interazione fra uomo-macchina. Tipicamente, si parla di UI in ambito informatico e tecnologico e quindi le interfacce utente sono comunemente identificate come sistemi atti a mettere in comunicazione l'uomo - computer, sistemi informatici e oggetti intelligenti. Amazon Apple è la UI di Alexa, Google Home è la UI di Google Assistent. Le interfacce sono uno strumento di mapping tra il dominio, lo spazio dell’informazione del computer e le capacità cognitive e sensoriali degli umani. È dove avviene la traduzione. È il momento in cui si esce dal mondo digitale e si entra nell’analogico.
L'obiettivo primario dell'interazione fra uomo e macchina è quello di consentire all'utente di controllare e far funzionare la macchina in modo efficace. L'interfaccia deve quindi essere progettata per semplificare l'interazione fra l'uomo e la macchina rendendo così l'esperienza d'uso piacevole e prolifica. L'interazione fra uomo e macchina deve sempre essere facile, efficiente e divertente così da massimizzare la User Experience del prodotto. Abilita inoltre la comunicazione fra due realtà aventi principi e modalità di "funzionamento" diametralmente opposte.
LEZIONE 12 – 20/10 – Interfacce e Human Interface Device (protocollo)
Un'interfaccia ben progettata consente all'utente di controllare l'apparato richiedendo uno sforzo fisico e cognitivo minimo. La buona interfaccia massimizza inoltre la quantità di informazioni utili trasferite all'utente durante l'interazione evitando un sovraccarico informativo che provocherebbe nell'utente confusione e quindi frustrazione. Come si definiscono le interfacce utenti? HMI (Human Machine Interface) dedicate all’inserimento o esternalizzazione di stimoli dalla macchina verso l’uomo. Un device che implementa una HMI è detto HID (Human Interface device). È la periferica attraverso cui l’utente interagisce con il sistema, l’elemento di contatto fisico. Ad esempio il mouse è un HID, combinato con il cursore e le finestre implementa una HMI. HDI + software che lo gestisce = HMI Le interfacce utente sono tipicamente organizzate sulla base dei sensi che utilizzano per stabilire l'interazione fra umano e macchina. Gli umani possiedono cinque sensi (Tatto, Vista, Udito, Olfatto e Gusto). Questo porta ad identificare cinque categorie di interfacce possibili, più una sesta che è legata al cosiddetto senso dell'orientamento (balance in inglese), che però non è considerato un senso vero e proprio nella fisiologia umana. Possiamo quindi organizzare le interfacce in 6 categorie:
- Tactile UI
- Visual UI
- Auditory UI
- Olfactory UI
- Gustatory UI
- Equilibrial UI (overbouard) La maggior parte delle interfacce utente utilizza però più di un senso umano per stabilire il collegamento. Le interfacce che usano più di un senso sono dette CUI o Composite User Interface. Le più comuni e note CUI sono chiaramente le famose GUI o Graphical User Interface, le quali sono composte da interfacce grafiche (visual) e tattili (tactile): monitor + mouse. Se ad una GUI andiamo ad aggiungere anche il suono otteniamo una MUI o Multimedia User Interface. Estendere le interfacce con più canali (sensi) non è sempre una buona idea: esempio dei video su Facebook che partono in muto, perché il suono può essere fastidioso se si pensa che il social vuole essere fruibile in qualsiasi momento e in qualsiasi luogo. Le interfacce vanno adattate al contesto di utilizzo: ad esempio gli assistenti vocali fuori casa funzionano male. Ci sono tre categorie di CUI: standard (con dispositivi HID standard come tastiera e mouse), Virtual (ferma l’interazione con la realtà esterna per creare una realtà virtuale) e Aumentata (Augmented) (non ferma l’interazione con la realtà esterna ma ne crea una aumentata, espandendola). Le CUI possono essere anche classificate tramite il numero di sensi che utilizzano. Per questo motivo, la progettazione di un'interfaccia è per definizione un'attività interdisciplinare che va oltre la programmazione grafica e abbraccia la psicologia, le neuroscienze, il design e la fisica.
