Slides dalle lezioni del corso di Interazione Uomo Macchina per il corso di laurea in Informatica - Università di Milano Bicocca - Prof.R.Polillo - lezione del 19 marzo 2014.
1. Corso di Interazione Uomo Macchina
AA 2013-2014
Roberto Polillo
Corso di laurea in Informatica
Università di Milano Bicocca
Dipartimento di Informatica, Sistemistica e Comunicazione
INGEGNERIA E
CREATIVITÀ
1
R.Polillo - Marzo 2014
Edizione
2013-14
2. Queste slides…
… si basano sul libro “Facile da usare”, dell’autore, dove si trovano
tutte le necessarie spiegazioni. Vedi www.rpolillo.it
Queste slide sono disponibili con licenza Creative Commons
(attribuzione, non commerciale, condividi allo stesso modo) a
chiunque desiderasse utilizzarle, per esempio a scopo didattico,
senza necessità di preventiva autorizzazione:
http://creativecommons.org/licenses/by-nc-sa/3.0/it/deed.it
La licenza non si estende alle immagini fotografiche e alle screen
shots, i cui diritti restano in capo ai rispettivi proprietari, che sono
stati indicati, ove possibile, nelle didascalie del libro. L’autore si
scusa per eventuali omissioni, e resta a disposizione per
correggerle.
R.Polillo -
Marzo 20142
3. Scopo di questa lezione
3
Presentare alcune tecniche che possono
stimolare la creatività nel design di nuovi
manufatti.
R.Polillo - Marzo 2014
21. Questo bottone permette di cambiare la
scala: l’oggetto imitato viene “potenziato”
con funzioni non realizzabili nel modello reale
R.Polillo - Marzo 2014
21
22. IBM Smart Phone
1. Comporre il numero
2. Cliccare la cornetta (sic!)22
R.Polillo - Marzo 2014
23. Da: IBM, Aptiva Communication Center
R.Polillo - Marzo 2014
23
24. Ibridazione
“Incrociare piante o animali di specie diverse
in modo da ottenere ibridi”
R.Polillo - Marzo 2014
24
Esempio:
lavagna + proiettore ⇒ lavagna luminosa
25. calendario + orologio
+ tab + bottoni
player musicale +
menu e form
Windows-like
Ibridazione: esempi
R.Polillo - Marzo 2014
25
36. Metafora
dal greco metaphora, trasporto, mutazione
Consiste, in sostanza, nel “mescolare” fra loro campi
semantici differenti, trasferendo proprietà e concetti
propri di un campo semantico ad un altro
R.Polillo - Marzo 2014
36
donatore
ricevente
37. Metafora: esempi
sei un fulmine
l’ondeggiare delle spighe
il ruggire dei motori
la gamba del tavolo
al timone dello stato
R.Polillo - Marzo 2014
37
38. Metafora: esempio
È vero, il mondo è tutto un palcoscenico
sul quale tutti noi, uomini e donne
siam solo attori, con le nostre uscite
e con le nostre entrate; ove ciascuno,
per il tempo che gli è stato assegnato,
recita molte parti,
e gli atti sono le sue sette età
….
W. Shakespeare, As you like it
R.Polillo - Marzo 2014
38
39. Word 95
La icona crea la metafora,
e suggerisce immediatamente
la funzione del menu
39
R.Polillo - Marzo 2014
40. La metafora della scrivania (Macintosh, 1984)
R.Polillo - Marzo 2014
40
41. Metafora: vantaggi
Suggerisce idee al designer, perché
trasferisce un intero “campo semantico”
da un contesto all’altro, suggerendo
soluzioni inattese
R.Polillo - Marzo 2014
41
44. Metafora: svantaggi
Può confondere l’utente, perché le inevitabili
incongruenze fra i due campi semantici possono
generare confusione e sfiducia
NB La metafora non è una similitudine!
R.Polillo - Marzo 2014
44
57. Una variante: Mutazione
57
“Fenomeno per cui in una specie si origina un
individuo che presenta alcuni caratteri diversi
dai suoi ascendenti, e li trasmette alla
discendenza”
R.Polillo - Marzo 2014
58. Esempio: design generativo
58
Progettare un manufatto e affidare al computer il
compito di generarne possibili “mutazioni
genetiche”
“metadesign” o “design di specie”:
definire le caratteristiche essenziali di un
manufatto e affidare al computer il compito di
generarne possibili “incarnazioni”
R.Polillo - Marzo 2014
64. Design patterns: che cosa sono
Un design pattern è una soluzione generale a un
problema di progettazione che si ripropone in molte
situazioni, anche diverse
Non una soluzione “finita”, ma piuttosto un modello, un
template da adattare alla specifica situazione
Il concetto è nato in architettura
alla fine degli anni ’70
(Christopher Alexander),
e applicato all’ingegneria del
software dalla fine degli anni ‘80
R.Polillo - Marzo 2014
66
66. Design pattern in architettura
R.Polillo - Marzo 2014
68
“Colloca la scala principale in una
posizione chiave, centrale e
visibile. Tratta l’intera scala come
una stanza (o, se all’esterno,
come un cortile). Disponila in
modo che la scala e la stanza
siano una cosa sola, con la scala
che scende attorno a una o due
pareti della stanza. Allarga il
fondo della scala con finestre
aperte o balaustre, e con ampi
gradini, in modo che le persone
che scendono lungo la scala
diventino parte dell’azione della
stanza mentre sono ancora sulla
scala, e che le persone in basso
usino naturalmente i gradini per
sedersi”.
Da C.Alexander, A Pattern Language
67. I pattern di interazione uomo macchina: esempio
Design pattern per le funzioni di ricerca in un sito web
(van Welie)
Advanced search Search Tips
Autocomplete Site Index
FAQ Site Map
Help Wizard Footer Sitemap
Search Box Tag Cloud
Search Area Topic Pages
Search Results
R.Polillo - Marzo 2014
69
68. Pattern language per l’interazione
70
I formalismi di descrizione sono diversi, ma
normalmente ogni pattern è descritto in una
scheda che fornisce
Il problema di cui si tratta
Il pattern che lo risolve
Le motivazioni
L’ambito/limitazioni di applicazione
Esempi di uso
R.Polillo - Marzo 2014
69. • Problem
• Solution
• Use when
• How
• Why
• More examples
• Implementation
• Literature
Schede descrittive: esempi
R.Polillo - Marzo 2014
71
Van Welie
• Problem summary
• Example
• Usage
• Solution
• Rationale
• [Discussion]
• [Sources]
• More examples
Toxboe
70. Design pattern: vantaggi
Raccolgono lo stato della pratica
Suggeriscono soluzioni ai progettisti
Formazione di un linguaggio comune
Diffondono gli “standard di fatto”
Evitano di “reinventare la ruota”
R.Polillo - Marzo 2014
72
72. “Per inventare, serve una buona
immaginazione e un mucchio di cianfrusaglie”
Thomas Alva Edison
R.Polillo - Marzo 2014
74
Editor's Notes
IBM SMART PHONE
Welcome to the future; one without distracting windows and menu bars. The RealPhone is an experiment in user interface design for a new, real-world user interface style...
Put a telephone-type keypad on any application, and the user will pretty rapidly guess that it's a telephone application. Sure, having an image of a telephone handset helps, but it's not necessary. Make the handset a necessary control for the application, and you'll have a lot of users that are unaware that it's a control. Controls should look like controls, and they should appear manipulatable. If you can use a telephone, you can use this software. Here's where the metaphor starts to break down. No matter how similar your program appears to look like a phone, it will always operate differently. When using a real phone, you pick up the phone, verify the dial tone, then dial your number. With RealPhone you dial your number, then point to the handset and click on it to start the call. Furthermore, to speed dial a number on a real phone, you pick up the handset, then press the speed dial number. On RealPhone however, you simply click on the speed dial number, which is likely to lead to a lot of inadvertent phone calls. Inadvertent mouse clicks don't happen when using real-world phones, but they occur frequently in computer-based applications. Novice users can use it immediately... Not likely. The application does not provide an area to type the number to be dialed. It displays numbers as they are typed, but because there is no control to receive the focus, there is no indication that you can type at all. Furthermore, while the interface provides command buttons for Redial and Flash, it does not provide a command button to initiate the call once the number has been entered. The user has to click on the handset, which is so non-intuitive that few users would ever consider trying it. In order to compensate for the non-intuitiveness of the interface, RealPhone relies on extremely lengthy tooltips to provide instructions. Many of the tips are so long they cannot be read in the display time for the tooltips (less than 3 seconds).
http://www.iarchitect.com/mshame.htm
The Address Book function in IBM's Aptiva Communication Center illustrates the joy the developers must have felt when they discovered the use of tabbed dialogs: The developers seem to have beside themselves with the new ability to place tab controls whereever they wanted. Tabs are placed along the top and along both sides; undoubtedly, if they were not constrained by the size of a 640x480 screen, they would have found a reason to put tabs along the bottom as well.
Of all the various sets of tabs, only those tabs along the right side of the display are appropriate in this dialog. These allow the user to quickly "move" to an appropriate page in the address book. While not easily discernible, there are two tabs along the left-hand side of the dialog; these allow the user to toggle the display between the Address Book view, and a Speed Dial view. The "tabs" along the top are particularly deserving of attention. Of the nine "tabs", only two, Add and Change, can be argued to cause a different tab to be displayed. "Change" causes the currently selected record to be displayed in the "notebook" area of the display, and "Add" causes a blank record to be displayed in the area. The other seven "tabs" are actually command buttons, each either causing a secondary dialog to be displayed, or initiate an immediate action.
This is the kind of design that gives tabbed dialogs a bad reputation.