Human Computer Interaction

Presentazione sul tema: "Human Computer Interaction"— Transcript della presentazione:

1 Human Computer Interaction
Fabio Vitali

2 Fabio Vitali Come, scusi?

3 A seguire: Perché HCI (2) 13/33
Autorità La direttiva europea 90/270/EEC richiede che si adottino delle precauzioni nel progettare, scegliere, commissionare o realizzare software. In particolare il software deve essere: Adatto al compito Facile da usare e, dove appropriato, adattabile alle esperienze e conoscenze dell’utente In grado di fornire feedback sulle sue funzionalità In grado di visualizzare le informazioni in un formato e ad una velocità adatta all’utente Conforme ai principi dell’ergonomia nel software

4 Perché HCI (2) Business Mercato
A seguire: Perché HCI (3) 14/33 Perché HCI (2) Business Siamo in grado di usare le capacità dei dipendenti in maniera più proficua Il costo umano è di gran lunga superiore al costo di hardware e software Gli errori sono costosi in termini di perdita di tempo, di soldi, di vite umane, di morale. Mercato Le persone si aspettano che i computer siano facili da usare, sono meno tolleranti verso errori di progettazione, sono estremamente eterogenee per quel che riguarda conoscenze, esperienza, aspettative.

5 Perché HCI (3) Individui La sfida progettuale
A seguire: Storia del nome (1) 15/33 Perché HCI (3) Individui Il computer è sempre più visto come un elettrodomestico, e ci aspettiamo lo stesso grado di affidabilità, facilità, utilità. La sfida progettuale Gli essere umani sono complessi, i sistemi sono complessi, l’interfaccia tra i due è complessa. Il punto di vista sociale I computer sono sempre più una parte critica della nostra società, e verranno usati per aspetti socialmente rilevanti: educazione dei bambini, trattamento dei dati personali, applicazioni critiche (controllo aereo, impianti industriali e d’energia, office automation)

6 Storia del nome (1) Human performance Ergonomics Human factors
A seguire: Storia del nome (2) 16/33 Storia del nome (1) Human performance Inizio secolo. Applicazione diretta del taylorismo: l’uomo - l’operaio - è una macchina, ed è necessario massimizzarne le prestazioni. Ergonomics II guerra mondiale, GB. Studia l’interazione tra uomo e macchina e cerca di creare macchine (ad esempio armi) che utilizzino al meglio le caratteristiche fisiche degli esseri umani. Qui nasce la legge di Murphy. Human factors Termine americano degli anni ‘60 (ergonomics è europeo) per indicare la stessa cosa. In più entrano in gioco fattori cognitivi.

7 Storia del nome (2) Man-machine interaction Human-computer interaction
A seguire: Storia del nome (3) 17/33 Storia del nome (2) Man-machine interaction Negli anni ‘70 l’ergonomia si divide: studi sulle applicazioni del design nella vita quotidiana (es. sedie) rimangono col nome di ergonomics, mentre studi sull’usabilità degli oggetti per il lavoro (macchine, computer, ecc.) prendono il nome di interazione uomo-macchina Human-computer interaction Negli anni ‘80 la consapevolezza della grande parte che i computer avevano nel campo del man-machine interaction (oltre a considerazioni di correttezza politica) portano ad identificare un campo specifico. Il termine interazione persona-elaboratore è stato proposto anche in Italia. User interface Una visione più ristretta, relativa soltanto agli aspetti delle applicazioni con cui l’utente si trova in contatto. Da qui il termine “user friendliness”

8 Storia del nome (3) Web design Web usability
A seguire: Termini dell’HCI 18/33 Storia del nome (3) Web design In particolare, la nascita del World Wide Web, la sua subitanea popolarità e la quantità di brutti siti che ciò ci ha portato ha creato una nuova disciplina specificamente orientata alla progettazione di buoni siti Web. Questa disciplina richiede competenze grafiche, tecniche, di progettazione dell’informazione e della comunicazione. Web usability Alcuni guru indiscussi (Siegel, Veen, ma soprattutto Jakob Nielsen) hanno proposto teorie dell’usabilità che molto hanno influenzato la progettazione recente dei siti Web.

9 Termini dell’HCI Utente Elaboratore Interazione
A seguire: Una mappa dell’HCI (1) 19/33 Termini dell’HCI Utente Un individuo, un gruppo di persone che lavorano insieme, un gruppo di utenti che lavorano insieme in un’organizzazione. Elaboratore Ogni tecnologia dell’informazione, dal piccolo PDA al computer da scrivania, ad un sistema su larga scala, ad un sistema embedded, e che includa anche parti non computerizzate (ad es. altri esseri umani). Interazione Ogni comunicazione tra utente e computer, diretta o indiretta. Se è diretta si dice che c’è un dialogo, con feedback e controllo del dialogo. Se è indiretta si assume l’esistenza di un processo in background o batch. In ogni caso esiste un fine dell’interazione.

10 Linee-guida e case studies
A seguire: Una mappa dell’HCI (2) 20/33 Una mappa dell’HCI (1) Elaborazione Aspetti sociali Ambiente di lavoro Linguaggio Grafica Ergonomia Dialogo I/O Linee-guida e case studies Valutazione Tecniche e tool

11 Una mappa dell’HCI (2) La progettazione L’ambiente sociale
A seguire: Tensioni 21/33 Una mappa dell’HCI (2) Gli esseri umani Elaborazione dell’informazione Linguaggio, comunicazione Ergonomia, caratteristiche fisiche degli esseri umani I computer Device di I/O Tecniche di dialogo Generi del dialogo Computer graphics La progettazione Approcci alla progettazione Tecniche e tool di programmazione Linee guida e case studies Tecniche di valutazione L’ambiente sociale Organizzazione sociale Computer e ambiente di lavoro

12 Tensioni Di interesse per l’HCI Utilità Efficienza Complessità
A seguire: Arte, mestiere o scienza? 22/33 Tensioni Di interesse per l’HCI Utilità Servire a qualcosa Efficienza Richiedere il minimo di risorse per raggiungere lo scopo Complessità Essere di ostacolo alla comprensione per motivi intrinseci (cioè inerenti al concetto in sé). Usabilità Essere facile da imparare e da usare. Efficacia Richiedere il minimo di risorse aggiuntive (ad esempio, negli utenti) per raggiungere lo scopo. Complicazione Essere di ostacolo alla comprensione per motivi estrinseci (cioè dipendenti da cause esterne).

13 Arte, mestiere o scienza?
A seguire: Testing, metodi o trucchi? (1) 23/33 Arte, mestiere o scienza? Non esiste una teoria unificante dell’HCI. Forse non può esistere. Comunque tutte le teorie si basano sullo studio dei task. C’è un parallelo con l’architettura: La scienza fornisce le tecniche numeriche per evitare che l’edificio crolli Il mestiere ottimizza la struttura, le tecniche costruttive, il soddisfacimento dei bisogni pratici L’arte aggiunge grazia, ispirazione, genio. C’è nel campo dell’HCI la tensione a descrivere, regolare, racchiudere. Questo eliminerà l’arte? La velocità di innovazione nell’informatica garantisce che qualunque tecnica invecchierà rapidamente. Senza lo spazio per la creatività, HCI è destinato a burocraticizzarsi.

14 Testing, metodi o trucchi? (1)
A seguire: Testing, metodi o trucchi? (2) 24/33 Testing, metodi o trucchi? (1) L’HCI è recente e popolare. I suoi dettami non sono ancora codificati. Esistono decine di trattati e teorie variamente sovrapposte, contrapposte o alternative. Teorie di dieci anni fa sono oggi già completamente screditate. Probabilmente teorie di moda oggi saranno screditate tra cinque anni. Molte regole d'oro del passato sono ormai entrate nella consapevolezza collettiva, e sono di difficile rimozione, anche se ormai non più attuali. Ad esempio, il ruolo delle metafore o delle icone nella progettazioni di interfacce. La cosa è ancora più evidente nel Web. La disponibilità di nuove tecnologie, gli studi di usabilità, gli stili di progettazione incalzano a pochi anni o mesi di distanza l'uno dall'altro, e libri di progettazione di tre-quattro anni fa sono già inesorabilmente datati. Come capire se un dettame è destinato a durare nel tempo o dovuto a mode o situazioni contingenti?

15 Testing, metodi o trucchi? (2)
A seguire: Testing, metodi o trucchi? (3) 25/33 Testing, metodi o trucchi? (2) Il progresso scientifico è solidamente basato sul test: uno scienziato propone un'ipotesi e va tosto a verificarne la correttezza. Il paradigma scientifico è lo schema all'interno del quale vengono fatte ipotesi e che permette di valutare in partenza -cioè prima del test - quali ipotesi abbiano una speranza di successo e quali no. Il solo meccanismo di testing, dunque, non dà nessuna garanzia di arrivare a produrre conclusioni ragionevoli e utili. In particolare, non fornisce un metodo. Il metodo, invece, è fondamentale nella invenzione: fornisce concetti, schemi e trucchi indispensabili per ottenere in tempi ragionevoli un risultato utile. Le linee-guida costituiscono una formalizzazione e cristallizzazione di un metodo di progettazione. Esprime in esteso quei concetti, schemi e trucchi che costituiscono il metodo.

16 Testing, metodi o trucchi? (3)
A seguire: I bias del vostro docente 26/33 Testing, metodi o trucchi? (3) Assiomi Regole "eterne", che non dipendono dalle mode, dallo sviluppo tecnologico, e che presumibilmente saranno vere ancora a lungo nel futuro. Ad esempio: "Minimizzare il carico cognitivo richiesto dall'interfaccia aumenta il potenziale cognitivo a disposizione per il task" Paradigmi Schemi globali che forniscono una vera e propria filosofia di progettazione. Vengono rivoluzionati da grandi cambiamenti tecnologici o sociali (invenzioni importanti, cambi generazionali, etc.) Ad esempio: Metafore negli anni '80, Internet negli anni '90, mobilità negli anni '00. Regole Singoli, specifici dettami, più o meno dettagliati, che portano il paradigma a effettiva realizzabilità. Ad esempio: usa un font senza grazie per i titoli; fornisci sempre un link alla home page.

17 I bias del vostro docente
A seguire: 4 regole d’oro 27/33 I bias del vostro docente Mi piacciono i contributi di individui geniali… Controversi Per lo più inutili o senza sbocco Paradigmatici Peggiorano le cose prima di migliorarle Miglioramenti di ordini di grandezza Non prevedibili, non ricercabili … ma bisogna anche tener conto dei contributi della comunità di scienziati. Non controversi Sempre utili Di dettaglio o tassonomici Migliorano comunque, ma poco alla volta Prevedibili e ricercabili

18 4 regole d’oro Pensare agli utenti Provare sul campo
A seguire: La siringa automatica (1) 28/33 4 regole d’oro Pensare agli utenti Il 90% degli sforzi di un esperto in HCI è ricordare al progettista del sistema che ci sarà un utente ad usare il sistema. Provare sul campo Un sistema che in laboratorio è facile e piacevole da usare può non esserlo nella situazione reale: le autoradio o i telecomandi vanno usati senza essere guardati, le radiosveglie da persone addormentate. Coinvolgere gli utenti Gli utenti (soprattutto per i task specializzati) hanno conoscenze importanti e non formalizzate. Una interfaccia di prova (mock-up) compie il miracolo che mille studi su carta non riescono a fare. Iterare (e iterare e iterare e iterare e iterare e iterare e iterare e iterare e iterare e iterare) Nessuna interfaccia riesce giusta al primo tentativo. Piccoli prototipi a basso costo e sacrificabili sono cruciali. Esistono molte tecnologie che permettono di creare finte interfacce a basso costo.

19 La siringa automatica (1)
A seguire: La siringa automatica (2) 29/33 La siringa automatica (1) Si dovette progettare l'interfaccia di una siringa automatica: l'infermiera digita la quantità di liquido da iniettare, e attiva la siringa. I progettisti immediatamente pensano alle tastiere di computer e telefoniche, e progettano questo: 99999 7 8 9 4 5 6 1 2 3

20 La siringa automatica (2)
A seguire: Una meta-teoria dell’HCI 30/33 La siringa automatica (2) Quello a cui i progettisti non pensano, e gli utenti sì, è l'applicazione dell'interfaccia nel mondo reale. Ad esempio, qual è l’effetto se si preme per errore un tasto in più nell’inserire il valore numerico 1372? 13672 7 8 9 4 5 6 1 2 3 + - 4 7 2 1 Tastierino progettato senza coinvolgere gli utenti Tastierino progettato con il coinvolgimento degli utenti

21 Modelli di interazione
Fabio Vitali Modelli di interazione L’interfaccia è il luogo dove avviene l’interazione tra due sistemi complessi e disomogenei, e l’interfaccia realizza la traduzione del dialogo tra un sistema e l’altro. Nel nostro caso, esseri umani e computer sono sistemi particolarmente complessi, e quindi maggiore sarà la possibilità di errori nella realizzazione di questa traduzione. L’uso di modelli di interazione ci permette di evidenziare eventuali problemi di traduzione molto presto, e di confrontare tra loro le soluzioni.

22 Il modello di Norman Scopi Oggetti della realtà Noi Mondo
Fabio Vitali Il modello di Norman Scopi Intenzione di agire Sequenza di azioni Esecuzione della sequenza Valutazione delle interpretazioni Interpretazione della percezione Percezione dello stato del mondo Oggetti della realtà Noi Mondo

23 Il modello di interazione (1)
Fabio Vitali Il modello di interazione (1) Un sistema interattivo permette ad un utente di raggiungere un goal, ovvero uno scopo all’interno di un dominio applicativo, ovvero un’area di competenza e conoscenza in qualche attività. I task sono operazioni per manipolare i concetti del dominio, e il goal è il risultato desiderato di queste manipolazioni. Attraverso Input ed Output si ottiene il dialogo che realizza l’interazione. Ogni membro dell’interazione utilizza un proprio linguaggio, e compito del progettista è trovare una traduzione adeguata tra i linguaggi. Il sistema ha un proprio linguaggio detto core, di computazioni che è in grado di eseguire. L’utente ha un linguaggio di task in cui è in grado di esprimere i suoi goal. A loro volta, input ed output hanno un proprio linguaggio con cui sono in grado di mappare gli uni negli altri.

24 Il modello di interazione (2)
Fabio Vitali Il modello di interazione (2) Il modello di interazione qui presentato divide in quattro fasi la valutazione dell’interazione, e sempre come valutazione di correttezza, completezza e facilità di traduzione da un linguaggio ad un altro. L’enfasi nella valutazione è data in particolare alla capacità di tradurre i task umani in compiti al sistema, piuttosto che a metriche interne al sistema stesso. Questo è un modo complicato per dire che “il programma migliore dipende da quello che ci si vuole fare.” S U O I core task output input esecuzione presentazione osservazione articolazione

25 Il contesto organizzativo e sociale
Fabio Vitali Il contesto organizzativo e sociale L’interazione non avviene nel vuoto. C’è un contesto sociale ed organizzativo che va valutato. Differenze tra committente e utente Procedure non informatiche che influenzano l'uso del sistema Atteggiamento psicologico degli utenti del sistema Aspettative incoerenti dei committenti L'esempio delle casseforti Esistono poi fattori che influenzano notevolmente l’interazione con i sistemi complessi Competitività tra pari Desiderio di impressionare il superiore, Paura di sbagliare in pubblico, ecc., … ne riparliamo a breve

26 Fabio Vitali Un esempio Per ragioni di sicurezza, in una banca inglese la password per sbloccare le casseforti di filiale era divisa in due semichiavi assegnate a due manager diversi. Poiché era ritenuto disdicevole che i manager digitassero di persona su una tastiera, era pratica comune che la semichiave venisse affidata ad una segretaria. Contemporaneamente, una politica di austerity applicata dalla banca dimezzò il numero di segretarie, obbligando più manager a condividere la stessa segretaria. Ci furono dunque svariati casi di segretarie in possesso di entrambe le semichiavi! La discrepanza non venne rilevata che vari anni dopo.

27 Usability engineering (1)
Fabio Vitali Usability engineering (1) La prima generazione di utenti di computer erano i programmatori stessi. Essi avevano esperienza sostanziale e motivazioni forti nell’approccio al computer. Per questo potevano accettare (ed anzi approvare) interfacce complesse e potenti. La popolazione utente attualmente è composta in minima parte di esperti di computer, ma anzi di persone dotate di diversissime competenze: anni 80 impiegati e professionisti, anni 90 utenti casuali e per “diporto”. Questi utenti non usano il computer per obbligo o per dedizione alla tecnologia, ma perché trovano in esso un supporto al lavoro o all’hobby. Il loro uso è discrezionale, e può essere interrotto e sostituito in qualunque momento.

28 Usability engineering (2)
Fabio Vitali Usability engineering (2) La progettazione dei sistemi deve dunque essere basata fondamentalmente sull’osservazione attenta degli utenti, dei loro task, delle loro preferenze. I progettisti cerchino il rapporto diretto con gli utenti in tutte le fasi del design, dalla progettazione all’implementazione a tutto il ciclo di vita del software. I metodi di progettazione iterativa permettono test precoci dei prototipi, feedback tempestivo, raffinamenti incrementali. L’ingegneria dell’usabilità (usability engineering) è una disciplina con pratiche formalizzate e standard riconosciuti, per ottimizzare l’usabilità di un sistema.

29 Usability engineering (3)
Fabio Vitali Usability engineering (3)

30 I cinque parametri dell’usabilità
Fabio Vitali I cinque parametri dell’usabilità Apprendibilità: la facilità di apprendimento per gli utenti novizi. Efficienza: prestazioni continuative da parte di utenti esperti Memorizzabilità: facilità nell’uso intermittente del sistema da parte di utenti casuali. Errori:frequenza di errori catastrofici e/o minori. Soddisfazione soggettiva: piacevolezza all’uso del sistema

31 Curve di apprendimento
Fabio Vitali Curve di apprendimento Un sistema può : Focalizzarsi sulla facilità di apprendimento, compiacendo gli utenti novizi. Focalizzarsi sulla efficienza di uso, compiacendo gli utenti esperti Permettere sia un modo novizio che un modo “esperto” (ad esempio con menù più ricchi e un linguaggio di script) In questo caso naviga sopra ad entrambe le curve dell’apprendimento

32 System e User-centered design
Fabio Vitali System e User-centered design System-centered design Progettazione basata su aspetti di convenienza per il progettista. Cosa è facile progettare su questa piattaforma? Cosa è facile creare con gli strumenti disponibili? Cosa trovo interessante ed appagante progettare? User-centered design Progettazione basata su caratteristiche dell’utente a cui il sistema è destinato Cosa sa fare l’utente? Di cosa ha bisogno l’utente? In che contesto opera l’utente?

33 Sette facili principî di user-centered design
Fabio Vitali Sette facili principî di user-centered design 1 Sfrutta sia la conoscenza nel mondo che la conoscenza nella testa 2 Semplifica la struttura dei task 3 Rendi visibili le cose 4 Sfrutta correttamente il mapping 5 Sfrutta la potenza dei vincoli 6 Progetta considerando gli errori 7 Quando il resto non basta, standardizza

34 Fabio Vitali L’ergonomia Lo studio delle caratteristiche fisiche dell’interazione e dei controlli che la permettono. Lo scopo primario è l’incremento di efficienza degli esseri umani. Ci occupiamo brevemente di: Organizzazione di controlli e display L’ambiente fisico dell’interazione Aspetti connessi con la salute L’uso dei colori

35 Organizzazione di controlli e display
Fabio Vitali Organizzazione di controlli e display La disposizione fisica dei controlli e dei display è importante. In applicazioni critiche è fondamentale, ma anche nelle applicazioni su PC di tutti i giorni: tasti vicini possono avere significati molto diversi e potenzialmente in contrasto. Il raggruppamento dei comandi è importante. Possiamo avere: Raggruppamenti funzionali: i comandi funzionalmente collegati sono messi vicini Raggruppamenti sequenziali: i comandi sono organizzati per riflettere l’ordine con cui vengono attivati (soprattutto in situazioni dove le sequenze sono obbligate: aviazione) Raggruppamenti per frequenza: i comandi usati più frequentemente sono raggruppati insieme.

36 L’ambiente fisico dell’interazione
Fabio Vitali L’ambiente fisico dell’interazione Anche le condizioni ambientali sono importanti: i controlli sono messi ad altezza comoda? I display sono posti in modo da non riflettere la luce delle finestre o dell’illuminazione? Un utente in sedia a rotelle riuscirà a raggiungere tutti i controlli? Un utente molto alto o molto grasso non sarà reso impacciato dai comandi troppo vicini? Riusciranno tutti gli utenti a vedere comodamente tutti i display?

37 Altri aspetti ergonomici
Fabio Vitali Altri aspetti ergonomici Aspetti connessi con la salute Lavorare con i computer non è intrinsecamente pericoloso, ma a lungo andare possono sorgere dei problemi: Sforzi fisici, temperatura, luce, rumore possono avere alla lunga effetti nocivi sul nostro corpo. In particolare esistono malattie alle mani e agli occhi caratteristiche dell’uso dei computer. Uso dei colori Non solo le nostre percezioni sono limitate (per esempio nel numero di colori singoli identificabili), ma esistono molte variazioni individuali. Moltissime persone hanno difficoltà a distinguere colori agli estremi della gamma (ad es., blu e nero), e molte hanno altri tipi di deficienze (ad es., daltonismo). E’ opportuno dunque non usare MAI i colori come unica differenziazione e MAI in contrasto con le aspettative culturali locali. Un trucco per verificare la leggibilità dei propri design per persone con problemi di colori è visualizzarli su uno schermo a toni di grigio.

38 Fabio Vitali Il design del dialogo L’interazione può essere vista come un dialogo tra utente e computer. La scelta dello stile di interazione ha profondi effetti sulla natura del dialogo e, di conseguenza, sull’efficacia dell’interazione. Sono stati identificati 6 stili di interazione primari: Command entry Menu e navigazione Domanda/risposta Form-fill e spreadsheet Linguaggio naturale Manipolazione diretta

39 Attira ed è adatto ai power users.
Fabio Vitali Command entry Consiste nel comandare direttamente il computer tramite comandi basati su parole intere, abbreviazioni, caratteri o tasti funzione. E’ stata la prima forma di interazione con il computer, ed è ancora molto diffusa. Spesso è l’unico modo di comandare un sistema (es. Unix shell), a volte è complementare ad un sistema basato su menu. PREGI Flessibile e potente Favorisce l’iniziativa dell’utente Favorisce la creazione di script e macro DIFETTI Apprendimento lungo Difficile memorizzazione Guidato dalla sintassi Scarsa tolleranza agli errori Attira ed è adatto ai power users.

40 Adatto per compiti semplici e strutturati.
Fabio Vitali Menu e navigazione Le opzioni a disposizione dell’utente sono di volta in volta mostrate a schermo, occupandone gran parte. Poiché le opzioni spesso non stanno tutte sullo schermo, richiede l’adozione di meccanismi di organizzazione che nascondono set di opzioni (menu gerarchici). Un corretto matching con le attività dell’utente ppuò aiutare. Ogni altra organizzazione porta a confusioni e difficoltà di apprendimento. PREGI Apprendimento breve Poche azioni richieste (es. tasti) Struttura i task dell’utente Facile gestione degli errori DIFETTI Poco adatto a sistemi complessi Occupa schermo Struttura i task dell’utente Rallenta i power users Adatto per compiti semplici e strutturati.

41 Adatto per compiti semplicissimi.
Fabio Vitali Domanda/risposta All’utente viene posta una serie di domande (perlopiù con risposte sì/no, codici, selezione da liste, ecc.) ed è condotto passo passo attraverso il task. Il sistema è in controllo dell’interazione, e a volte non permette all’utente di variare rispetto alla sequenza dei comandi. Adatto per compiti dalla struttura ben nota e lineare (es. bancomat) PREGI Apprendimento inesistente Facile gestione degli errori Poche azioni richieste DIFETTI Adatto a sistemi molto semplici Controlla l’iniziativa dell’utente Biforcazioni di task, anche molto semplici, sono irreversibili. Adatto per compiti semplicissimi.

42 Form-fill e spreadsheet
Fabio Vitali Form-fill e spreadsheet Per l’inserimento e la ricerca di dati, è utile organizzare lo schermo come se fosse un modulo cartaceo (form). Ogni dato da inserire ha una sua posizione sullo schermo (campo), e il passaggio da un campo all’altro avviene attraverso sistemi noti. L’uso e la correzione di errori è facile, tuttavia l’applicabilità è limitata Gli spreadsheet generalizzano questo tipo di interfaccia. PREGI Apprendimento modesto e di tecniche generali Semplifica l’inserimento dati Buona gestione degli errori Facile da realizzare DIFETTI Poco adatta per ogni compito oltre all’inserimento dati Occupa schermo Limita i task dell’utente Adatto per inserimento dati.

43 Adatto per compiti specifici.
Fabio Vitali Linguaggio naturale La comprensione del linguaggio naturale è molto desiderabile, ma è molto difficile per via dell’ambiguità intrinseca nel linguaggio. Essa può avvenire via voce o tramite una tastiera, ma non va confusa con il riconoscimento del parlato. Un sistema generale è attualmente al di fuori della nostra portata, ma esistono sistemi su domini limitati. Diventa tuttavia difficile tirare una linea tra questi sistemi e sistemi a command entry PREGI Non c’è apprendimento E’ naturale e immediato DIFETTI Non esistono di tipo generale Possono richiedere molte azioni Richiedono spesso dialogo di chiarificazione Non sono predicibili. Adatto per compiti specifici.

44 Manipolazione diretta (1)
Fabio Vitali Manipolazione diretta (1) I sistemi a manipolazione diretta permettono l’interazione immediata, fisica con gli oggetti dell’interfaccia. Essa richiede un’intelligente rappresentazione visuale dei concetti del dominio di interazione, e la possibilità di identificare oggetti ed azioni da compiervi. L’uso della tastiera e scelta di comandi sono sostituiti (o integrati) da attività motorie con l’ausilio di meccanismi di puntamento. PREGI Presenta visivamente i task Facile da apprendere e ricordare Permette l’esplorazione Facile gestione degli errori Dà soddisfazione soggettiva DIFETTI Difficile da programmare Richiede display grafici e sistemi di puntamento. Richiede una rappresentazione visuale adatta (metafore???) Adatto per compiti semplici e strutturati.

45 Manipolazione diretta (2)
Fabio Vitali Manipolazione diretta (2) I sistemi a manipolazione diretta hanno le seguenti caratteristiche: Visibilità degli oggetti di interesse Azioni rapide, reversibili, incrementali Manipolazione motoria degli oggetti di interesse. Tra i sistemi a manipolazione diretta ricordiamo: Interfacce WIMP (Window, Icon, Menu, Pointers): MacOS, Windows, X-Windows Interfacce point-and-click: WWW browsers Interfacce tridimensionali: VRML, ecc.

46 Manipolazione diretta (3)
Fabio Vitali Manipolazione diretta (3) Al cuore della manipolazione diretta c’è il problema di collegare in maniera diretta azioni e comandi dell’utente agli oggetti dell’interfaccia. Questa maniera si dice directness. Distinguiamo due tipi di directness: Directness semantica: c’è un rapporto diretto tra quello che l’utente vuole fare (task) e quello che il sistema permette (function)? O sono necessari dei workaround? C’è un ovvio discorso di affordance. Directness articolatoria: C’è un rapporto diretto tra la funzione ed il comando che la attiva? I comandi sono pensati in modo da permettere un associazione intuitiva con il loro effetto? C’è un ovvio discorso di mapping.

47 Per una storia delle interfacce

48 Primi protagonisti Fabio Vitali
Doug Engelbart, con Augment (anni ‘60), dimostrò che il computer poteva essere uno strumento di produttività personale. Seymour Papert, con il LOGO (anni ‘60), dimostrò che i computer potevano essere usati da non professionisti, addirittura da bambini. Alan Kay, con FLEX (anni ‘60), e con Xerox Star (anni ‘70), dimostrò che la grafica poteva essere usata per le interfacce Bill Atkinsons, realizzando il Macintosh Toolbox (primi anni ‘80), dimostrò che la grafica poteva essere realizzata in maniera efficiente con macchine “povere”.

49 Teorie dell’apprendimento
Fabio Vitali Teorie dell’apprendimento Alan Kay fu il primo ad ipotizzare l’uso sistematico della grafica. I primi studi risultarono però in sistemi sostanzialmente inutilizzabili. Il LOGO gli fece capire che i meccanismi di apprendimento erano la chiave per organizzare l’interfaccia globale. Si concentrò su due pensatori in particolare: Jean Piaget (cognitivista svizzero, ) Jerome Bruner (“Verso una teoria dell’istruzione”, 1966)

50 La teoria piagetiana Fabio Vitali
I bambini non sono in grado di fare ragionamenti simbolici tradizionali fino all’età di 11 o 12 anni, ma sono invece molto abili in altri tipi di ragionamenti, anche avanzati, che coinvolgono nozioni di topologia, geometria differenziale, etc. I bambini, crescendo dalla nascita alla maturità (adolescenza), passano attraverso stadi intellettuali diversi e successivi. Si possono ottenere cose molto complesse sfruttando la natura dei vari stadi, e causare problemi, frustrazioni ed ansie ignorandole. Esempio dei due bicchieri d’acqua: i bambini sotto i dieci anni, anche vedendo versare dell’acqua da un bicchiere alto e magro ad un bicchiere basso e grosso, continueranno a pensare che nel bicchiere grosso ci sta più liquido.

51 I tre stadi piagetiani Fabio Vitali
Lo stadio cinestetico è quello in cui il bambino impara a muoversi, a toccare, a spostare gli oggetti, ad afferrarli e a valutarne le caratteristiche strutturali e di robustezza Lo stadio visuale è quello in cui il bambino osserva l’aspetto esteriore degli oggetti, lo valuta, lo confronta, ne apprezza le caratteristiche visive più importanti (forma, colore, simmetria, etc.) Lo stadio simbolico è quello in cui il bambino valuta il significato, l’uso degli oggetti, si fa modelli mentali del mondo esterno e delle relazioni, e fa analisi simboliche non più sugli oggetti, ma su concetti astratti

52 L’elaborazione di Bruner (1)
Fabio Vitali L’elaborazione di Bruner (1) Gli stadi piagetiani in realtà sono modalità sovrapposte e mai cancellate. I passaggi della crescita generano mentalità diverse, autonome ed indipendenti: ragionano in modo diverso, hanno abilità diverse, sono in contrasto le une con le altre L’elaborazione dell’esperimento dei bicchieri d’acqua: se nascondo il bicchiere grosso, gli stessi bambini che vedendo insistono che ci sta più liquido capiranno che ci sta la stessa quantità. Scoprendo il bicchiere si ri-convincono del contrario. E’ inoltre dimostrato che le mentalità bruneriane siano estremamente “modali”, e dopo aver preso il controllo lo lasciano con difficoltà: dopo aver risolto cinque problemi simbolici di fila, coloro che sono sottoposti a test vengono generalmente bloccati per ore a risolvere simbolicamente un problema che era banale risolvere visivamente.

53 L’elaborazione di Bruner (2)
Fabio Vitali L’elaborazione di Bruner (2) Sebbene Bruner identifichi varie modalità e mentalità, le più rilevanti rimangono le mentalità create dai tre stadi piagetiani: realizzativa, iconica e simbolica. Mentalità realizzativa: sapere dove ci si trova, in quale posizione, muoversi in un ambiente, manipolare oggetti Mentalità iconica: riconoscere, confrontare, configurare, concretizzare Mentalità simbolica: astrarre, concatenare catene di passi logici, dedurre Le persone apprendono applicazioni della mentalità realizzativa con una parte del cervello sviluppata precedentemente alla parte che si occupa di applicazioni iconiche, e ancora prima di ragionamenti simbolici.

54 Lo Xerox Star (1979) Doing with Images makes Symbols
Fabio Vitali Lo Xerox Star (1979) Doing with Images makes Symbols Doing - mouse - mentalità realizzativa - oggetti realizzati come oggetti manipolabili fisicamente Images - icone, finestre - mentalità iconica - oggetti che si differenziano e rassomigliano visivamente, confrontabili, comparabili. Symbols - SmallTalk - mentalità simbolica - oggetti che si prestano ad astrazioni, ragionamenti, modifiche e personalizzazioni.

55 Caratteristiche dello Xerox Star
Fabio Vitali Caratteristiche dello Xerox Star Finestre sovrapposte permettono il confronto, facilitano la complessità fornendo contesti autonomi Modelessness Si passa da una modalità all’altra senza atti di terminazioni speciali, semplicemente facendo click sulla finestra giusta Object-Oriented l’oggetto fornisce informazioni sul tipo di azioni che è in grado di fare. Nasce la sintassi “selezione-comando” Text editing come sbarazzarsi di modalità “insert” e modalità “replace”? Introducendo il concetto di selezione.

56 Le metafore Suggerisce comandi, proprietà, azioni, interazioni
Fabio Vitali Le metafore Es: lo schermo come carta su cui scrivere, disegnare, cancellare Suggerisce comandi, proprietà, azioni, interazioni Ma non suggerisce la magicità dell’azione: vogliamo che la carta su computer sia altrettanto difficile da modificare e cancellare che la carta vera? E’ la magia - magia comprensibile - che conta, non l’adeguamento ad una realtà esterna Meglio “illusione dell’utente” che “metafora” Es. il desktop come metafora deve sparire: le vere scrivanie si riempiono di carta, non si auto-ordinano, non danno aiuti quando si tratta di cercare qualcosa.

57 Design dell'usabilità

58 Il design dello schermo
Fabio Vitali Il design dello schermo Lo schermo (grafico o a caratteri, b/n o a colori, ecc.) è il meccanismo principe di output dell’informatica corrente. A seconda di quali caratteristiche abbiamo a disposizione, abbiamo diverse funzionalità di interfaccia che possono essere attivate. Esistono tuttavia delle regole generali da rispettare: Come presentare e inserire informazione Come fornire indizi sulle attività possibili Estetica ed utilità Localizzazione ed internazionalizzazione

59 Presentare ed inserire informazioni
Fabio Vitali Presentare ed inserire informazioni Cosa bisogna mostrare? Testo, numeri, immagini, schemi, mappe, tavole, record, ecc. Con che device? Per quale scopo? A come presentare le informazioni dedicheremo una lezione intera, ma qui vale la pena ricordare: Fornire molte rappresentazioni diverse delle stesse informazioni permette di non sbagliare mai! Allineamenti e raggruppamenti sono importanti per dare indizi d’uso, appartenenza e rilevanza ai vari elementi dell’interfaccia L’uso dei colori va limitato al massimo, per sobrietà e generalità. Seguire euristiche e regole d’oro come quelle di Nielsen e Molich o Ben Shneiderman

60 Le 9 euristiche di Nielsen e Molich (1)
Fabio Vitali Le 9 euristiche di Nielsen e Molich (1) 1 Simple and natural dialog Simple means no irrelevant or rarely used information. Natural means an order that matches the task. 2 Speak the user's language Use words and concepts from the user's world. Don't use system-specific engineering terms. 3 Minimize user memory load Don't make the user remember things from one action to the next. Leave information on the screen until it's not needed. 4 Be consistent Users should be able to learn an action sequence in one part of the system and apply it again to get similar results in other places. 5 Provide feedback Let users know what effect their actions have on the system.

61 Le 9 euristiche di Nielsen e Molich (2)
Fabio Vitali Le 9 euristiche di Nielsen e Molich (2) 6 Provide clearly marked exits If users get into part of the system that doesn't interest them, they should always be able to get out quickly without damaging anything. 7 Provide shortcuts Shortcuts can help experienced users avoid lengthy dialogs and informational messages that they don't need. 8 Good error messages Good error messages let the user know what the problem is and how to correct it. 9 Prevent errors Whenever you write an error message you should also ask, can this error be avoided?

62 Fabio Vitali Le 8 regole d’oro del dialogo (1) Ben Shneiderman Designing the user interface 1 Cercare la coerenza interna: sintattica e semantica esterna: con le altre applicazioni e con il mondo reale 2 Fornire feedback informativo proporzionale all’importanza ed al ruolo dell’azione 3 Disegnare dialoghi che portino ad una chiusura I gruppi di azioni debbono avere un inizio, un centro ed una fine Fornire un grado di soddisfazione da raggiungimento dello scopo Permettere l’abbandono di strategie contingenti 4 Fornire una strategia di gestione dell’errore semplice

63 Le 8 regole d’oro del dialogo (2)
Fabio Vitali Le 8 regole d’oro del dialogo (2) 5 Fornire reversibilità alle azioni 6 Permettere agli utenti esperti delle scorciatoie 7 Garantire all’utente il senso del controllo evitare mancanze di causalità (es. arbitrarietà nella sequenza dei comandi) Rendere l’utente “iniziatore” piuttosto che “risponditore” 8 Ridurre il carico della short-term memory Mantenere un display semplice, informativo, comprensibile

64 Fabio Vitali Fornire indizi Un’aspetto importante nell’interazione è la continua ricerca da parte degli esseri umani di esplorare, provare nuove strade, fare esperimenti. Inoltre la caratteristica naturale degli umani di razionalizzare e fornire spiegazioni (anche antropomorfizzando le reazioni automatiche di un sistema) vanno considerate. Alcuni elementi dell’interfaccia sono passivi, altri permettono inserimenti, altri lo richiedono. Affordance e mapping sono la base per le nostre esplorazioni, e standard e linee guida (di piattaforma o aziendali) aiutano a fornire affordance e mapping noti. Ad esempio, cliccare su un icona è naturale per utenti in misura della loro esperienza di computer, non delle loro esperienze di vita reale.

65 Altri aspetti Estetica ed utilità
Fabio Vitali Altri aspetti Estetica ed utilità Un bella interfaccia non è necessariamente una buona interfaccia. A volte bellezza ed utilità possono essere in contrasto. Tuttavia le regole di bel layout possono fornire preziosi indizi di usabilità. Localizzazione ed internazionalizzazione Localizzare o internazionalizzare del software non si limita a tradurre le voci dei menu o dei manuali. Ad esempio, allineamento e layout si basano su sistemi di scrittura da sinistra a destra, dall’alto al basso. Ad esempio, molte icone o l’uso culturale di colori può essere molto diverso da cultura a cultura.

66 About Face (Alan Cooper 1995)
Fabio Vitali About Face (Alan Cooper 1995) Il Macintosh ha delle linee guida dal I programmatori le rispettano, perché sanno che applicazioni che le seguono hanno successo, e le ammirano, perché forniscono risposte chiare e comprensibili ed allo stesso tempo profonde. Microsoft ha pubblicato libri analoghi per Windows per ottenere lo stesso effetto di costrizione e entusiasmo, senza riuscirci. About Face ha avuto, nella comunità di programmatori per Microsoft, lo stesso effetto delle linee guida Apple per i programmatori Macintosh. Noi non ci occupiamo delle parti più direttamente orientate a Windows, ma delle parti più generali e meno specifiche.

67 Goal-oriented design (1)
Fabio Vitali Goal-oriented design (1) Il software solitamente non è progettato, ma emerge come casualmente dal team di sviluppo come uno zombie da una tomba Quando è progettato, è progettato sul punto di vista del programmatore, o del settore marketing, o al massimo dal punto di vista dell’utente. Mai dal punto di vista dei goal dell’utente. Anche nel caso migliore, gli utenti non sono consci dei loro goal. Software che semplicemente permettano loro di completare task non sono soddisfacenti. Il compito del progettista è di guardare oltre il task verso i goal degli utenti.

68 Goal-oriented design (2)
Fabio Vitali Goal-oriented design (2) Questi non sono veri goal dell’utente: Evadere efficientemente una pratica Formattare velocemente un’intero libro Verificare la correttezza di un ipotesi commerciale Questi sono veri goal dell’utente: Non sembrare stupido Non fare grossi errori Portare a termine una quantità ragionevole di lavoro Divertirsi (o almeno non annoiarsi troppo) Anche se si riferiscono al lavoro, i goal sono sempre personali, mai lavorativi. Un software pensato per i goal lavorativi fallirà, un software pensato per i goal personali riuscirà e riuscirà anche a soddisfare i goal lavorativi.

69 Fabio Vitali Tre paradigmi Esistono tre criteri di fondo per progettare un’interazione Il paradigma tecnologico: come nello stile architettonico dei Metabolisti (anni 60), lo scheletro interno della macchina è espresso in evidenza, quasi orgogliosamente: conoscere il programma equivale a conoscerne il funzionamento interno. Il paradigma metaforico: Si prende una rappresentazione del mondo reale con qualche attinenza all’ambito dell’applicazione, e si imita il modello reale con il modello del computer, attuando una metafora. La metafora globale forza ogni sua sottoparte ad adattarsi per non rovinare il feeling, ed impedisce all’interfaccia di evolversi verso strade non realistiche. Il paradigma idiomatico: l’interfaccia usa un vocabolario di base di comandi, anche arbitrario, ma identificabile e ricordabile, che costituisce un livello “automatico” su cui viene formata l’esperienza d’uso del sistema.

70 Il paradigma idiomatico (1)
Fabio Vitali Il paradigma idiomatico (1) La mente umana è superba ad analizzare e organizzare informazioni visuali (basti pensare a trarre un senso dalla miriade di informazioni visive che recepiamo ogni momento dai nostri occhi). Anche la lettura di testi avviene attraverso questa superba capacità di individuare e riconoscere forme e trovare pattern in input apparentemente difformi. Il riconoscimento di pattern visivi è di gran lunga superiore (in tempi, sforzo mentale, ecc.) al riconoscimento verbale o pittografico. Per riconoscere il segnale stradale dell'autostrada, cerchiamo un cartello verde. Non è un simbolo metaforico, neanche representazionale. E' idiomatico: se ne impara l'uso in un contesto, e da allora in poi rappresenta il contesto in cui viene usato.

71 Il paradigma idiomatico (2)
Fabio Vitali Il paradigma idiomatico (2) Analogamente, le interfacce grafiche hanno avuto successo non perché grafiche o perché adottavano la metafora della scrivania, ma perché avevano identificato un idioma. Nelle interfacce a command line l'utente può inserire un numero virtualmente infinito di comandi, di cui solo una parte ristrettissima viene effettivamente compresa dall'elaboratore. Viceversa le interfacce grafiche restringono le possibilità di dialogo alle sole dotate di significato: sparisce il concetto di errore di sintassi. Ciò avviene adottando un idioma composto di combinazioni di tre azioni fondamentali: movimento, click e drag del mouse.

72 Il paradigma idiomatico (3)
Fabio Vitali Il paradigma idiomatico (3) Il paradigma idiomatico si basa dunque sulla creazione di un vocabolario specifico, peculiare e ristretto. Nelle interfacce grafiche ho a disposizione solo comandi significativi come composizione naturale di idiomi di base a formare un vocabolario canonico. Tutti i sistemi facili da imparare prevedono un vocabolario canonico al di fuori del quale NON È POSSIBILE GENERARE ESPRESSIONI LINGUISTICHE. I vocabolari canonici derivano da un'applicazione a piramide di elementi fondamentali (le primitive), che permettono costrutti più complessi (i composti), che si specificano nella applicazione in icostrutti dotati di significato, gli idiomi.

73 Il paradigma idiomatico (4)
Fabio Vitali Il paradigma idiomatico (4) Objects Text Idiomi Draw, create, Delete, change shape Edit, format, sort, scroll Composti Double click, Area select Modified keypress Edit fields, move among fields, highlight words, lines, Primitive Click, drag, move, keypress Keypress, move cursor

74 Flusso ed orchestrazione (1)
Fabio Vitali Flusso ed orchestrazione (1) Nelle barche a vela, c’è un momento magico in cui la velocità è sufficiente a sollevare la barca sopra la sua stessa scia, toccando appena il pelo dell’acqua, così da riuscire a toccare velocità elevatissime. Avviene in maniera improvvisa ed è (dicono) una sensazione esilarante. Tuttavia è anche un momento fragilissimo, poiché basta una manovra goffa per tornare giù nell’acqua e fermarsi come contro un muro. Gli esseri umani hanno similmente uno stato psicologico chiamato “flusso”, che si attiva improvvisamente quando ci concentriamo su un task. Il “flusso” è definito come un “coinvolgimento profondo e quasi meditativo” sul task da realizzare, e induce spesso una “gentile sensazione di euforia”, ed una sostanziale perdita di senso del tempo. In stato di flusso, le persone sono molto produttive, specialmente per attività creative o progettuali.

75 Flusso ed orchestrazione (2)
Fabio Vitali Flusso ed orchestrazione (2) Come per le barche a vela, anche per gli esseri umani il flusso è uno stato magico e fragilissimo. E’ necessario evitare che la goffaggine dell’interazione possa interromperlo. Una volta fuori dal flusso, è difficile e lento riportarcisi. Per evitare di uscire dal flusso, queste sono tecniche utili: Seguire i modelli mentali uno strumento che organizza le proprie procedure intorno ai modelli mentali dell’utente non disturba. Dirigere, non discutere un volante non discute: limita a due direzioni la scelta dell’utente, ma non inizia una conversazione con l’utente per la scelta ottimale della prossima direzione

76 Flusso ed orchestrazione (3)
Fabio Vitali Flusso ed orchestrazione (3) Tenere gli strumenti a portata di mano molti programmi sono troppo complessi per permettere in maniera facile di accedere a tutti i comandi. In questo caso le modalità sono indispensabili. Le toolbar permettono all’utente di avvicinare a sé gli attrezzi che gli sono necessari, e cambiare di modalità in maniera veloce e facile. Fornire feedback non modale Il modo più semplice di fornire all’utente un valore di feedback è mostrare una finestra modale, che richiede che l’utente esplicitamente la licenzi. Informazioni non modali sono un modo molto migliore, anche se questo può popolare l’interfaccia di numeri e valori ovunque. Per ottenere un’interazione migliore, l’orchestrazione delle varie parti dell’interfaccia in un unico coerente ed efficace è il meccanismo fondamentale. L’obiettivo finale è l’invisibilità dell’interfaccia.

77 Possibilità contro probabilità (1)
Fabio Vitali Possibilità contro probabilità (1) Se una proposizione è vera volte e falsa 1 volta, per un matematico la proposizione è falsa. Se, di fronte ad una scelta, utenti scelgono la prima risposta, ed 1 sceglie la seconda, l’informatico riterrà comunque importante fare la domanda. Per un informatico o un matematico, possibilità e probabilità si confondono: per esempio, se sono sei ore che sto lavorando su un documento di testo, il programma di dà la possibilità di salvare il documento su disco oppure di buttarlo via. La cameriera non mi propone di versare la birra sulla camicia ogni volta che mi serve. Perché il software mi propone di NON salvare il mio file? Perché il programmatore ha confuso possibilità con probabilità. Comandi e funzioni usati centinaia di volte al giorno stanno fianco a fianco con comandi e opzioni che useremo una volta nella nostra vita. Ha senso?

78 Possibilità contro probabilità (2)
Fabio Vitali Possibilità contro probabilità (2) La soluzione non è impedire la scelta, ma far richiedere esplicitamente la scelta improbabile. Invece di fornire il comando “Salva”, fornire “Abbandona i cambiamenti”, da attivare nel raro caso in cui voglio buttare via il lavoro. In generale, i programmi si debbono porre nel modo di minimizzare il dialogo non necessario, al fine di non ostacolare lo stato di flusso dell’utente. La regola proposta è: “dirigi, segui o stai fuori dai piedi”. L’utente preferisce un risultato immediato da modificare, piuttosto che una complessa dialog box prima di vedere qualcosa. Ad esempio, un comando di creazione tabelle dovrebbe prima creare una tabella, e poi permettere all’utente di manipolarla e cambiarla a suo gradimento. Il programma deve chiedere scusa, non permesso. Caratterizzare il feedback è importante. Un’azione che va a buon fine, la normalità, non vanno riportate con un dialogo modale: il feedback non modale serve proprio a questo.

79 Postura e stato Fabio Vitali
Come le persone, anche i programmi hanno un atteggiamento, che influenza il modo in cui funzionano e sono percepiti dagli utenti. Questo atteggiamento è anche un modo di porsi all’utente, una postura. Postura sovrana: alcuni programmi si pongono come padroni dell’interazione, il programma principale usato dall’utente per lungo tempo. Word processor, spreadsheet, ecc. sono di questo tipo. Postura transiente: esistono programmi che fanno saltuariamente un compito importante, come dirigere uno scanner per importare un grafico. Non essendo un’applicazione sovrana, deve esibire un comportamento diverso. Deve essere più avara di spazio, ma può essere più brillante ed estroversa. Postura demonica: applicazioni che normalmente non richiedono l’intervento dell’utente: driver di stampa, programmi di fax, ecc. Postura parassitica: silenziosi testimoni di un processo in corso: l’orologio, lo stato di download di un file, ecc.

80 Fabio Vitali Overhead Per compiere un task, dobbiamo sempre eseguire un certo numero di azioni non direttamente connesse con il task. Questo è l’overhead. Esistono quindi azioni guadagno (che ci portano più vicini al completamento del task) ed azioni tassa (che non contribuiscono direttamente al completamento del task). Un azione è tassa se serve al computer, e non a me: salvataggio di file, recupero, spostamento e riordinamento di finestre, operazioni di backup, installazione di programmi, configurazione di driver, ... Eliminare le azioni tassa rende l’utente più efficace. Un’importante classe di azioni tassa sono le meta-domande: chiedere di poter chiedere. Ad esempio, sullo schermo è mostrata un’informazione che io posso cambiare. Debbo però attivare un comando per poter cambiarlo, invece di cambiarla direttamente: sto chiedendo di poter chiedere l’aggiornamento di un valore! Permettere l’input in ogni situazione in cui ci sia output.

81 Fabio Vitali Idiozia Mi compare questo messaggio quando il disegno è orientato in maniera diversa dal formato di stampa. Perché il programma mi avverte di questa situazione? Perché debbono esistere due orientazioni diverse? Perché non le sistema da solo? Cosa significano i pulsanti Annulla ed Ok? Perché almeno non ci sono pulsanti tipo “Converti il disegno in Landscape” e “Converti il formato di stampa in Portrait”?

82 Fabio Vitali Memoria Un trucco semplice per migliorare overhead e idiozia è fornire di memoria il programma: apprendendo dal comportamento dell’utente la volta precedente, il programma potrebbe evitare domande sciocche e ripetute. Le domande non sono scelte: la dialog box pone l’utente in una situazione di inferiorità, dovendo avere una risposta pronta per tutte le domande che gli vengono poste Viceversa, una toolbar offre scelte, lasciando l’utente in situazione di superiorità e controllo. Se vale la pena chiederlo, vale la pena ricordarlo.

83 Fabio Vitali Messaggi di errore (1) I messaggi di errore debbono essere rari. Adesso vengono usati come le aspirine, mentre dovrebbero essere usati come la chirurgia. E’ necessario vaccinare i programmi in modo che non si possano presentare le condizioni di errore. Errori come inserimento di caratteri spuri in un formato fisso (es. una data), o fuori ordine, ecc., sono sintomi dell’inabilità del programma di gestire l’interazione, non dell’umano di capire qualcosa. Non sono errori dell’utente, ma limiti del software.

84 Messaggi di errore (2) Fabio Vitali
Gli utenti percepiscono i messaggi di errore come accuse nei loro confronti. Un messaggio come quello sopra verrà percepito come questo sotto.

85 Fabio Vitali Messaggi di errore (3) Inoltre, il messaggio di errore non serve. Tutto quello che riesce a fare è di impedire di inserire una lettera in un campo che vuole numeri, ma non mi impedisce di inserire il numero sbagliato. Questo è molto più difficile da realizzare. A volte il messaggio d’errore è inevitabile. In questo caso, il messaggio deve essere: Gentile: prendersi le colpe e ammettere i propri limiti Illuminante: fornire informazioni lucide e complete su quello che è successo D’aiuto: fornire una via d’uscita ed assicurarsi che l’utente possa riprendere la procedura normale il più facilmente possibile.

86 Fabio Vitali Messaggi di errore (4)

87 Fabio Vitali Classi di utenti I software vengono solitamente pensati per utenti esperti, oppure per utenti completamente ignari e principianti. L’utente medio non arriverà mai allo stato di utente esperto, e tante facilitazioni gli saranno sempre negate. Tuttavia, tutti gli utenti lasciano presto lo stato di totalmente ignaro. E presto trovano irritante l’atteggiamento paternalistico delle interfacce per principianti. La maggior parte degli utenti rimangono in uno stato perpetuamente intermedio, con abilità e fluidità che vanno e vengono a seconda della frequenza con cui usano il programma. Lo scopo del progettista dunque è: Trasformare al più presto il principiante in un intermedio Non ostacolare quegli intermedi che vogliono diventare esperti Tenere gli intermedi perpetui felici e produttivi per sempre

88 J.L. Borges + A. Bioy Casares Sboccia un'arte
Fabio Vitali … grosso modo abbiamo tratteggiato fin qui lo svolgimento morfologico degli [edifici] inabitabili, dense e rinfrescanti raffiche d'arte che non piegano il capo al menomo utilitarismo: nessuno vi entra, nessuno vi si stende, nessuno vi si siede sulle calcagna; nessuno s'insinua nelle concavità, nessuno saluta con la mano dall'impraticabile balcone, nessuno agita il fazzoletto, nessuno vi si getta sotto. Là tout n'est qu'ordre et beauté. J.L. Borges + A. Bioy Casares Sboccia un'arte Cronache di Bustos Domecq, 1967

89 Fabio Vitali Riferimenti A. Dix, J. Finlay, G. Abowd, R. Beale, Human Computer Interaction, Prentice Hall, Cap. 3 B. Shneidermann, Designing the User Interface, 3rd Edition, Addison Wesley, Cap. 2 T. Hewett, R. Baecker ed altri. ACM SIGCHI Curricula for Human-Computer Interaction, Report of the ACM SIGCHI Curriculum Development Group, ACM, 1992 Alan Cooper, About Face - The Essentials of User Interface Design, IDG Books, 1995 Theodore H. Nelson, The future information - Ideas, Connections and the Gods of Electronic Literature,