Il progetto di una interfaccia prevede una serie di libere scelte sia se viene realizzato con modalità euristiche che con una metodologia rigida (matematica, computazionale), vi sarà coesione solo se c'è uno scheletro strutturale che tiene tutti i pezzi insieme.
Delaying: modalità impegnativa ma, spesso, consente di ottenere una buona soluzione. È una strategia general-purpose, la programmazione è un mezzo per rinviare all'hardware la realizzazione di compiti particolari.
Le interfacce utente programmabili (customizable) spingono ad una implementazione dilazionata.
Ancora sul delaying
Le persone con poca esperienza cercano di fare ed ottenere cose esatte sin dall'inizio, le persone più esperte sanno che questo non è possibile e ritardano la soluzione ai problemi che sorgono (questo anche se ne conoscono la soluzione o il modo per celare l'errore); infatti, il posticipare, porta ad accorgimenti nuovi e utili.
Una personalità giudicante cerca di eseguire immediatamente le funzioni da implementare; una personalità percepiente tende a dilazionarli nel tempo.
Gli ostacoli vengono affrontati immediatamente per cercare di ridurre la complessità ed il numero dei problemi da risolvere (questo modo di operare è tipico dei programmatori intransigenti). Una settorizzazione delle funzioni da implementare promuove il ruolo dell'utente;, il quale può giocare un ruolo importante sin dall'inizio del progetto.
Generalmente i progettisti e gli utenti non sanno quello che vogliono... gli diverrà più specifico e mirato non appena il progetto prenderà forma riguardo: cosa e come progettare le specifiche richieste.
Il sistema può lavorare correttamente ma non nella maniera aspettata... risolvere questo problema può sembrare facile ma, in generale, non lo è (è facile per le persone ma non per le macchine).
La maggior parte delle interfacce utente sono programmate in linguaggio imperativo, fare un cambiamento ed aggiungere nuove istruzioni, alla lunga, rende il programma difficile da capire; inoltre vengono generati coi cambiamenti side-effects e quelli devono essere a loro volta risolti e così via...
Conseguenze
Per evitare questo è stata introdotta la programmazione strutturale (s.p.). L'idea dietro alla s.p. è proteggere il software esistente da cambiamenti non desiderati introducendo ridondanza nel programma (es: in Pascal tutte variabili devono essere dichiarate). Inoltre la s.p. preserva contro cambi intenzionali in diverse parti del programma evitando che il programma divenga illeggibile...
"Una caratteristica che è omessa può essere aggiunta sempre più tardi, quando il suo progetto e le sue implicazioni sono capite bene. Una caratteristica che è stata inclusa precedentemente e che è stata capita perfettamente non potrà essere mai più rimossa."
Tony Hoare
Commenti sulla realizzazione iterativa
Quando un sistema non è chiaro vi è la necessità da parte degli utenti di commenti. Utenti e designer ripetono il progetto: gli utenti sono consultati, i progettisti accettano suggerimenti, ecc. Se questi cicli sono compiuti propriamente il progetto tende a migliorerare.
La progettazione iterativa può essere senza fantasia; alcune caratteristiche possono essere perfezionate ma non completamente
Il progetto, si sviluppa in modalità bottom-up. Inoltre il progetto può risultare essere uniforme.
La progettazione iterativa può essere frequentemente usata, questo in quanto risulta essere più conveniente e più veloce lasciare che siano gli utenti a correggere gli errori del software e suggerire innovazioni.
La progettazione iterativa può ignorare l'impatto locale: è più affidabile se il numero di utenti è alto; inoltre, ciascuna iterazione può usare utenti con diverse personalità per varianti del sistema.
Considerazioni finali
La progettazione iterativa può essere lenta, i concorrenti e l'evoluzione tecnologia possono impedire il progetto del prodotto finale.
Interessi commerciali possono essere a sostegno della progettazione iterativa: il prodotto finale non deve essere descritto al vasto pubblico.
La progettazione iterativa viene svolta in grande scala: le iterazioni utente/progettista possono durare per molto tempo, vi è una ricerca di compatibilità con le versioni precedenti, gli utenti vogliono che sia la stessa compagnia a fare le nuove modifiche/richieste ed infine può accadere che si dia vita alla formazione di nuove compagnie informatiche.
La progettazione iterativa è un processo con fine a se stesso o è un mezzo per giungere alla meta ? (l'ultima risposta è esatta).
Commenti
Quale è il miglior modo per progettare un interfaccia utente? Dipende dal progettista (se è identificabile con il livello 1o della scala di sofistificazione intellettiva allora utilizzare linee guida può essere la soluzione migliore); come vede il progettista gli utenti che svolgono il loro lavoro? X or Y? È richiesta una sopra o sotto-determinazione? Il progettista dovrebbe migliorare il suo stile personale? Due considerazioni potrebbero essere prese fortemente in considerazione: utilizzare una progettazione iterativa e cercare di raggiungere una personalità pari al 5o livello della scala di Jung.Non c'è alcuna risposta esatta per il progetto di una valida interfaccia utente, ma un buon approccio sarebbe quello scientifico: ciascuna iterazione è un esperimento.
Cosa è una buona progettazione
La progettazione è una scienza sintetica che tenta di capire i mondi sintetici in cui vivono gli utenti:
1 Il progetto dovrebbe avere un compito specifico ed il compito dovrebbe essere affermato chiaramente.
2 Il progetto dovrebbe mostrarsi palesemente: in genere, è impossibile sapere ciò che si compra prima di rompere il sigillo.
3 La progettazione dovrebbe essere iterativa: un prototipo come punto iniziale per un ciclo di una nuova interfaccia.
4 Il progetto dovrebbe avere più controlli che valutazione.
C'è una teoria per il progetto di intefacce? Se la risposta fosse affermativa, tale teoria dovrebbe provvede a: chiarimenti, predizioni, cose da mostrare...
Il problema è: come fa un uomo a comunicare con una macchina ?
Le teorie possono essere astratte e lontane dalla realtà, bisogna pertanto fare continue indagini ed osservazioni per migliorare/aumentare i concetti base delle nostre teorie.Se, tramite delle analisi, aggiungiamo informazioni la teoria verrà detta monotona, mentre se aggiungendo osservazioni non otteniamo una maggiore informazione allora la proprietà sopracitata non è assicurata.
Vogliamo che i sistemi conversazionali siano monotoni così che ad un aumento di nuove caratteristiche vi sia anche un aumento della conoscenza del sistema, dell'abilità per usarlo e così via...
Si riconoscono due tipi di idee: idea scientifica e idea di sperimentazione/uso.
Le idee scientifiche vengono esaminate mediante esperimenti.
Nella vita reale, il progetto di interfacce prevede che il test di analisi venga ritardato nel tempo.
Di principi ce ne sono molti e alcuni anche molto utili, alcuni vengono riconosciuti come fondamentali per la stesura di una valida interfaccia utente.
Oggi le linee guida disponibili sono molte... l'uso di principi e teso a:
aiutare i progettisti durante la fase primordiale della progettazione.
evitare errori.
usare tecniche usate precedentemente con esiti positivi.
I progettisti non amano ricorere alle clinee guida perchè possono essere banali e/o difficili da adottare. Talvolta i designer possono cambiare l'intero sistema di lavoro.
Linee guida (guidelines)
Le linee guida sono realizzate per una maggiore consapevolezza dei problemi identificati per i quali non c'è alcuna risposta generale.
Una linea guida standard è generalmente del tipo "present feedback info"- (in alcuni casi l'interfaccia presenta dei messaggi espliciti (offensivi!!!): messaggio di errore dopo aver immesso una password non valida in uno sportello bancario elettronico.
Input ed output dovrebbero essere compresibili e compatibili come nel caso in cui si debba inserire una data:
97/06/10
Con questa scrittura si possono intendere due date (il 10 di giugno o il 6 di ottobre). In questo caso il sistema dovrebbe rispondere mostrando la "sua" interpretazione così che l'utente possa controllare e vedere se la data immessa sia quella corretta.
Il tempo che si impiega a muovere la mano (spostando un mouse) per raggiungere un icona sullo schermo dipende logaritmicamente dalla distanza tra puntatore del mouse ed icona (non è una relazione lineare).
Questa legge può aiutare il progettista a decidere sulle misure che devono avere gli oggetti presenti sullo schermo: quelli più distanti dovranno avere dimensioni maggiori.
Le linee guida possono essere viste come suggerimenti da aggiungere ad una analisi degli atteggiamenti e abilità degli utenti (il progettista dovrebbe conoscere l'utente e lasciare che quest'ultimo risolva da solo problemi semplici).
Un sistema conversazionale senza comandi non è 'facile usare'.
Aggiungere un comando ad un sistema 'difficile da usare' non rende il sistema 'facile da usare' (aggiungere un comando di aiuto può renderlo facile da capire ma non da usare).
Non vi è relazione tra facilità d'uso e numero dei comandi-'facile da usare' è un concetto vago che, incidentalmente, non aiuta a realizzare un sistema con tale proprietà.
Di solito i problemi sorgono in condiziona estreme, l'idea è quella di sorprendere l'utente il meno possibile, particolarmente quando entra in nuove modalità/eccezioni/condizioni critiche.
Cosa si intende per stupore minimo? I criteri sono soggettivi.
Uniformità in altro verso: non tutti i comandi possono prevedere l'utilizzo di un UNDO.
Nuovo orientamento
Alcune persone possono stabilire sia l'uso che le regole di chi lavora, il progetto di una interfaccia ha un modello della persona che può variare o essere ripresa.
Buoni sistemi conversazionali sono nati da idee (guidati da considerazioni formali) e in parte dalla crescita delle richieste... di solito però, un sistema può presentare inconvenevoli nel caso in cui interagiscano nuovi utenti.
Rutherford affermò che una scienziato non sa quello che fa a meno che non lo possa spiegare semplicemente.
Le linee guida dovrebbero essere accessibili sia al progettista che all'utente.
Per il progettista: aiutarlo a ragionare sul suo lavoro e sulle scelte che deve implementare per la creazione del sistema.
Per l'utente: aiutarlo a crearsi un modello del sistema.
Si impara da esperienza o da regole? (da entrambe !)
Si cerca di utilizzare gueps per spiegare all'utente come funzioni il sistema, utilizzando nozioni chiare e basilari.
Passo tipico
Un progettista è colui che implementa un progetto: ha idee su come progettare il programma; formalizza queste idee (in notazione matematica, in una notazione del linguaggio di specifica,...); lo realizza e lo sottopone al giudizio dell'utente e documentors.
Commenti
Il compito dei documenters comincerà quando la realizzazione del progetto sarà finita. Il loro compito sarà quello di capire realmente se il sistema sia in grado di compiere un buon lavoro. Una cattiva opera di documentazione porta a pessimi manuali e accresce le incertezze degli utenti.
In questo schema i fattori umani non sono menzionati e non sono inclusi nel passo del specifica formale.
Se questo approccio può essere definito l'ingegneria del software, allora è necessario completarla con l'ingegneria psicologica: questa è l'idea del guep. In breve: si utilizzano principi che mi consentano una discussione formale e colloquiale delle funzioni che coinvolgono il nostro progetto.
Il modello GUEP nella pratica
La parte sinistra produce programmi-grezzi contemporaneamente la parte destra produce programmi-utenti.
Il problema importante in questo diagramma è quello che i programmi sono progettati non solo per il computer ma anche- in misura uguale- per l'utente (la documentazione potrebbe essere vista come un programma che debba essere interpretato dall'utente).
Conseguenze sul modello GUEP
Vi saranno difetti/contraddizioni sia nel programma che nelle classi di utenza prescelte che nei manuali (a causa di descrizioni inesatte).
Un sistema conversazionale può essere migliorato da accorgimenti fatti a posteriori mediante un accurato studio della documentazione (talvolta è necessario scrivere di nuovo il programma o cambiarlo del tutto !!).
Un altro genere di difetti sono quelli legati all'interfaccia: errori che si verificano dopo un azione non corretta dell'utente e/o presenza di side-effects.
I difetti strutturali sono quelli in cui è permesso compiere X e poi Y oppure XY ma non YX- spesso il programmatore 'risolve' questi problemi aggiungendo nuovi comandi (a scapito di una maggiore complessità computazionale).
GUEP in azione
Riassumere chiarisce. Una descrizione succinta, completa e veritiera, anche se impossibile da farsi, rende il sistema più semplice.
L'utente ha la proprietà del programma se si è fatto un modello ed è in grado di spiegarlo.
Il progettista deve assicurare che l'utente si costruisca ed usi un modello proprio del sistema.
Il guep dovrebbe aiutare a fare quello detto precedentemente (creare il modello dell'utente) e spesso questo accade.
Il modello dell'utente viene raramente discusso : è una asserzione esplicita.
Un modello dell'utente è tanto semplice quanto possibile.
Il modello dell'utente cambia nel momento in cui l'esperienza dell'utente aumenta.
Il modello dell'utente si adatta ai bisogni psicologici. Il guep è indipendente da questi bisogni ma aderisce completamente al progetto.
Indipendenza dei domini
I principi dovrebbero essere indipendenti dalle richieste. (WYSIWYG è un tale principio).
GUEP:Considerazioni
I gueps sono principi difficili da individuare.
Dei buoni gueps sono restrittivi e spesso mutuamente incompatibili.
I gueps sono basati su ipotesi progettuali e non è detto che siano sempre validi.
Un guep può essere utilizzato per un ammontare limitato di informazioni (non interessando tutto il progetto dell'interfaccia).
I sistemi complessi sono essenzialmente imprevedibili (come i sistemi conversazionali).
Fare sistemi prevedibili potrebbe essere una buona idea.
Altri problemi legati ai GUEPS
Le interfacce utente dovrebbero essere costanti riguardo ad una classe di gueps.
Se le interfacce fossero incoerenti, l'utente potrebbe attribuire poteri magici e illimitati.
All'inizio tutti i sistemi sono costanti, anche se non lo sembrano!
I sistemi prevedibili possono essere considerati costanti.
Due tipi di GUEPS
Possono restringere o possono liberare l'utente (restrizione: tipica nei modelli di sicurezza: solo un utente abilitato può accedere a specifiche informazioni; liberazione: tipico dei box-information: informazione libera a tutti gli utenti).
Il progettista e l'utente non possono andare d'accordo su cosa deve essere ristretto/liberato.
Un significato del termine matematico che si compie un'operazione data: non forza l'utente fuori dal sistema in cui l'operazione è stata compiuta. In una biblioteca.
Chiusura semplice: (riguardo alle citazioni) vi è un libro che cita tutti i libri presenti nella biblioteca.
Chiusura riflessiva: ciascuno libro cita se stesso (al meno nella pagina del titolo!).
Chiusura simmetrica: se il libro A cita il libro B allora B cita il libro A (caratteristica valida per la ricerca degli utenti).
Chiusura transitiva: se il libro A cita il libro B e il libro B cita il libro C allora il libro C cita il libro A.
La chiusura in atto
Un sistema conversazionale che perfeziona una biblioteca elettronica può migliorare mediante la relazione di chiusura.
Il progettista può richiedere che il suo sistema sia chiuso rispetto ad una proprietà richiesta/data affinché ottenga una definizione chiara per computer ed utente favorendo l'usabilità dell'interfaccia utente.
Per chiusura in sistemi conversazionali si intende una corrispondenza per compiere un'azione simile da due meccanismi diversi.
Chiusura nei linguaggi di programmazione
Il Principio di Corrispondenza in un linguaggio programmativo è un principio che si avvale della proprietà della chiusura per le variabili: la definizione e meccanismi legati alla variabile devono corrispondere completamente.
In Pascal è possibile sostituire l'espressione con una funzione che dia lo stesso valore (fare l'operazione inversa non è sempre possibile!!). In questo ultimo caso non vi sarà chiusura simmetrica.
Il Principio di Astrazione afferma che una unità significativa può essere sostituita da un'astrazione e viceversa (tipico dei linguaggi che utilizzino funzioni e procedure).
Tipicamente l'utente non è in grado di dire in quale stato si trova o come ha raggiunto lo stato corrente (l'informazione è ignota).
Nessuno va d'accordo su cosa sia un modo: canale dell'informazione nel campo psicologico; le classi nella Logica.
I sistemi modali possono essere usati velocemente: ambiguità e complessità sono i prezzi da pagare.
Pochi Modi o unimodalità?
Un sistema unimodale non può essere utilizzato! Infatti si dovrebbe permettere almeno una differente commutazione che a sua volta può essere vista come un modo condizionale.
L'unimodalità è una qualità: infatti i sistemi con pochi modi sono quelli più adeguati (l'utente non percepisce i vari modi e lavora senza difficoltà).
L'unimodalità è un sistema di pubblico-accesso: i terminali per ottenere informazioni su una città presentano sempre una unamodalità.
Principio di ragione non-sufficiente
Pólya 1948
Quello che non si vede non esiste. I ritardi possono essere considerati significativi se sono casuali, generano un modello molto complesso del sistema nella testa dell'utente.
Se non c'è alcuna ragione sufficiente per dubitare che le cose siano diverse (quando risolvono le stesse istanze di problemi) allora è possibile trattarle come se fossero tutte una stessa cosa: se 2 finestre mostrano la stessa cosa allora ne basterebbe una.
I sistemi non dovrebbero lavorare con una multi modalità a meno che vi siano ragioni sufficienti o vi sia una informazione esplicita su quale modo è presentato all'utente nel momento in cui interagisce.
Quale è un buon modo?
Non è sempre facile dire quale sia un buon modo. Si dovrebbe avere una completa informazione sui modi esistenti.
Un buon uso di un modo è quello di trattare l'interpretazione del comando "giù" in un word processor nel caso in cui si sia raggiunto la fine del documento
Se si hanno molti modi, l'utente può perdere l'orientamento... si può trovare in difficoltà a ricordare in quale modalità si trova. Legge di Hick (Hick, 1952) affermò che il tempo della decisione dell'utente è logaritmica col numero di scelte a lui note. A volte l'utente non conosce il significato esatto di ciascuna scelta a lui disponibile.
Maniere spaziali, temporali
Perchè vi sono diverse modalità? Perchè disponiamo di soli 70 tasti sulla tastiera, un schermo piccolo ed una stretta bandwidth per i mezzi di I/O (dita/tasti) con un grande bandwidth per l'O/P mezzo (occhi/schermo).
Vi è una trasmissione lenta quando si hanno pochi tasti, veloce nel caso in cui ve ne siano molti (a scapito di un maggiore spazio). Se si sceglie come variabile fondamentale il tempo si parlerà di degradazione aggraziata mentre per lo spazio si parlerà di degradazione improvvisa.
I modi dell'utente possono essere diversi da quelli implementati.
Il significato del bottone del mouse dipende sul luogo in cui punta il mouse: modo spaziale invece di modo temporale.
Modi ingombranti
È difficile far comprendere all'utente in quale modalità si trova.
I modi temporali appaiono quando premendo un tasto sul mouse questo atto assume un significato che dipende dalla scelta selezionata dal menu (transitorio spaziale), se nessuno bottone è pigiato il sistema scende a una modalità di base dando sicurezza all'utente.
Illustrare modi
Un BACKSPACE può essere fuorviante: Cosa accade ai caratteri esistenti? ecc.
Consideriamo una calcolatrice con quattro funzioni:
Vengono visualizzati i risultati diversi in tempi diversi senza possibilità di rivedere quello che è stato fatto precedentemente.
Le informazioni significative non sono state mostrate e l'utente è costretto a memorizzare ciò che ha fatto.
