Skip to topic | Skip to bottom
Home

Tesi
Tesi.UsabilitaEVideoGiochir1.17 - 13 Mar 2005 - 17:45 - MirkoVenturitopic end

Start of topic | Skip to actions

I videogiochi e le interfacce

Come i videogiochi hanno influenzato lo sviluppo delle interfacce

Per sapere dove sto lavorando adesso cercare "<<<QUI>>>"

Indice

Introduzione

I videogiochi sono stati un fenomeno molto importante e significativo avvenuto negli ultimi decenni, sia come fenomeno in sé, sia come generatore di idee e di influenze verso altri settori più o meno contigui.

La tesi che si vuole qui esplorare riguarda l'influenza che i videogiochi hanno avuto, e stanno avendo, sullo sviluppo delle interfacce in genere, di programmi professionali o sistemi operativi.

Il punto di partenza dei lavori e delle ricerche prese in esame è il riconoscimento di un fatto, all'apparenza scontato ma caratterizzato da conseguenze meno evidenti: il successo dei videogiochi deriva dal successo che questi prodotti hanno saputo trovare nel regalare divertimento agli utenti, in altri termini, l'individuazione del componente-chiave di quello che ormai è assurto a fenomeno sociale ancorché ludico o tecnologico. Il sillogismo derivato dal riconoscimento di questo fattore centrale è "divertimento dell'utente -> successo dell'applicazione" o, in termini più formali, condizione sufficiente (ma non necessaria) perché un'applicazione abbia successo è che l'utente viva un'esperienza divertente. Vedremo come questo sillogismo non è che un'approssimazione di un collegamento che sì esiste, ma in termini molto più complessi, variegati e strutturati, tra il diverti-mento e/o il coinvolgimento dell'utente, e il gradimento (reale o apparente) dell'utente nei confronti dell'applicazione.

Come il precedente periodo suggerisce, il concetto di "divertimento", per quanto ficcante e d'effetto, non inquadra né precisamente né integralmente il complesso sistema che modella l'esperienza interattiva di un utente. Nel corso di questo lavoro si cercherà di approfondire questo argomento, in quanto premessa-chiave per lo sviluppo delle successive argomentazioni.

Dall'altra parte, verranno presi in esame più nel dettaglio i videogiochi, curiosi 'animali' che hanno creato grande scompiglio non solo nel mondo dell'intrattenimento ma anche in quello più consolidato dell'informatica cosiddetta 'professionale', e che hanno avuto e stanno avendo un successo sempre più mondiale. Si cercherà di dar conto delle analisi che sono state effettuate soprattutto nell'ambito della ricerca accademica, analisi che partono da approcci differenti, che offrono spunti di riflessione, e che portano a considerazioni non sempre assonanti e allineate nelle loro conclusioni.

Cos'è il divertimento? Perché i videogiochi sono divertenti? Quali sono le caratteristiche che li rendono tali? Queste sono alcune delle domande alle quali si cerca di rispondere nella prima parte di questo lavoro. (da completare)

[…]

Qual è l'influsso che i videogiochi hanno avuto e stanno avendo sui loro (lontani ma non troppo) parenti più "seri"? E più importante e al di là di questo, si possono individuare delle linee-guida di progetto affinché anche applicazioni "normali" possano trarre beneficio da tali caratteristiche? La seconda parte affronta questi aspetti. (da completare)

[...]

Videogiochi ---> Divertimento ---> Flusso

[...]

Importanza dell'aspetto didattico/dell'apprendimento: anche se non si trattano nello specifico i programmi dedicati all'apprendimento, la questione dell'apprendimento in sé è molto importante perché riguarda la fase in cui l'interfaccia è più sotto esame. L'apprendimento perciò costituisce la fase in cui i suggerimenti tratti dai videogiochi possono essere molto, se non addirittura più, efficaci.

Rilevanza dei limiti di tecnologia: solo apparente, nel 1973 viene sviluppato Alto (vedi http://www.sis.pitt.edu/~mbsclass/hall_of_fame/xerox.htm), prototipo a fini di ricerca; segue il sistema Star che esce nell'81 (iniziato nel 1975); visita di Steve Jobs ai laboratori di Palo Alto nel 1979. Precursore di Macintosh, Windows e X Window.

Mancanza di un collettore che raccoglie e organizza il lavoro di ricerca fatto (e magari anche da fare).

Definizioni

[Dra99] Gioco.

[MHBR02] Piacere (da Epicureo).

Divertimento.

[Hol93] Definizione di Man-Machine Interaction e di Human-Computer Interaction.

Applicazione professionale.

Videogioco.

Parole tradotte

enjoyable -> piacevole

Breve storia dei videogiochi

[Lev02] Le origini dei videogiochi.

[Lev02] La nascita del videogioco commerciale.

L'esplosione dei videogiochi.

Stato attuale.

[JuWag97] Tipologie di videogioco.

Capitolo 1 – Il divertimento

Perché i videogiochi sono divertenti

Premessa

Motivare l'approccio cronologico e per autore [da completare].

Malone, l'antesignano

Premessa

Quali sono le caratteristiche di base che rendono un videogioco divertente? L'ipotesi di Malone è che tali caratteristiche, una volta individuate, possano essere applicate – mutatis mutandis – più in generale ai programmi educativi.

Seppure costituiscano un campione rappresentativo per l'epoca in cui sono stati scritti gli articoli di Malone di seguito citati, i videogiochi esaminati (ad esempio "Breakout") appaiono sicuramente datati all'utente degli anni duemila. Ciononostante, l'identificazione delle caratteristiche di cui sopra rimane interessante sia per la modalità seguita sia per i risultati ottenuti, sebbene questi ultimi debbano talvolta essere riletti in chiave attuale.

Un'altra considerazione di merito riguarda la composizione dei campioni di indagine, che vede bambini e ragazzi tra l'asilo e le scuole medie (Malone si riferisce all'ottavo grado del sistema scolastico statunitense), e ragazzi delle scuole superiori; una composizione così connotata deriva senza dubbio dall'obiettivo specifico delle indagini svolte, ovvero l'esame dei videogiochi per l'identificazione di linee-guida da adottare nello sviluppo di programmi educativi. Questo è un fattore da tenere ben presente, perché limita perlomeno in potenza la validità e l'applicabilità dei criteri individuati ai programmi professionali oggetto di questo lavoro, programmi che hanno il maggior numero di utenti nella fascia adulta. Nonostante questo limite, però, si vedrà come l'analisi dei fattori componenti il divertimento elaborata da Malone sia tuttora ben valida, e quanti spunti offra.

Caratteristiche che rendono divertente un videogioco

In [Mal80], l'autore analizza le caratteristiche essenziali che rendono divertente un videogioco e che, più in generale, stanno alla base di tutte le situazioni intrinsecamente piacevoli. L'obiettivo è quello di applicare i principi identificati per la progettazione di videogiochi dedicati all'apprendimento, secondo la massima che afferma che se lo studente si diverte allora impara di più e più facilmente.

Tali caratteristiche vengono suddivise in tre categorie fondamentali:

  • sfida,
  • fantasia,
  • curiosità.
Malone dedica una trattazione separata ad ognuna di queste categorie, elencandone e descrivendo le caratteristiche fondamentali.

Sfida
Un videogioco deve fornire un obiettivo il cui raggiungimento sia incerto. Da questa considerazione si traggono importanti conseguenze.

Obiettivo
L'obiettivo è in effetti l'essenza del gioco. Le implicazioni che vengono dedotte sono:
  • tanto più è evidente tanto migliore è l'obiettivo (ad esempio, in "Breakout" bisogna abbattere tutti i mattoni che compongono un muro);
  • un ambiente complesso privo di obiettivi intrinseci dovrebbe essere strutturato in maniera tale da consentire agli utenti di definire obiettivi propri in autonomia (l'esempio proposto è il linguaggio di programmazione per bambini "Logo");
  • gli obiettivi migliori sono spesso pratici o di fantasia, piuttosto che semplicemente funzionali all'utilizzazione di una capacità (ad esempio la risoluzione di problemi aritmetici);
  • l'utente deve riuscire a capire se si sta avvicinando al raggiungimento dell'obiettivo.

Incertezza
Un giocatore normalmente si annoia se è certo del risultato, sia che vinca, sia che perda; i modi per rimediare sono quattro:
  • livello di difficoltà variabile (implicitamente determinato dal gioco, scelto esplicitamente dall'utente, determinato dalla scelta dell'avversario); in effetti, l'appropriatezza del livello di difficoltà è una delle ragioni fondamentali per cui una competizione, o un gioco, diventa motivante;
  • obiettivi a diversi livelli, così da dare all'utente una sorta di diversivo all'interno dell'obiettivo principale (ad esempio, in Pacman il diversivo è costituito dalle pillole energetiche che rendono temporaneamente vulnerabili i nemici, che così si possono "mangiare" per aumentare il proprio punteggio); a questo proposito è necessario il mantenimento del punteggio, e la velocità di reazione sia rilevante ai fini dell'obiettivo;
  • informazioni occultate, per provocare curiosità e rendere il gioco più intrigante;
  • casualità, tra le altre cose la base di una tipologia di indubbio successo qual è quella dei giochi d'azzardo.

Autostima
Le sfide sono attraenti perché tirano in ballo l'autostima: il successo in un videogioco, e più in generale in una qualsiasi attività che comprenda una sfida, fa sentire meglio se stessi, finanche nei casi in cui l'abilità del giocatore è fortemente subordinata alla casualità come nei giochi d'azzardo. Il rovescio della medaglia è il sentimento negativo che segue un fallimento. Da questo si può dedurre che i giochi dovrebbero avere un livello di difficoltà variabile cosi da adattarsi al meglio alle capacità del giocatore. Un'altra implicazione è che il feedback all'utente non dovrebbe essere troppo "severo" in caso di esito negativo della sessione di gioco, per non deprimere o frustrare il giocatore stesso.

Fantasia
Le fantasie rendono molto spesso i videogiochi [e non solo, N.d.A.] più attraenti. Per dare una definizione di "sistema che usa la fantasia", diciamo che si intende un sistema che richiami immagini mentali e sensazioni relative a cose o situazioni al momento non presenti realmente. Il grado di "impossibilità" di tali rappresentazioni può variare dal totalmente possibile (e.g. un simulatore di volo) al totalmente impossibile (e.g. Pacman).

La fantasia trova certamente parte del suo successo con i videogiocatori nell'andare incontro ai loro bisogni emozionali, nell'aiutare a soddisfarli. Il pubblico è vasto e vario, ed inoltre è molto difficile individuare quali sono le fantasie che colpiscono il gusto delle persone. Il progettista di videogiochi deve sì cercare di individuare i temi, le fantasie più coinvolgenti, ma deve anche cercare di proporne una varietà, sia per allargare l'insieme degli utenti potenziali sia per proporre al singolo videogiocatore più possibilità tra cui poter scegliere.

Fantasie intrinseche e fantasie estrinseche
Un modo relativamente semplice di aumentare il divertimento nell'apprendimento è di aggiungere alla base esistente un gioco in cui il partecipante deve avanzare fino al raggiungimento di un obiettivo di fantasia, o di evitare un finale catastrofico (sempre di fantasia) a seconda che le risposte siano giuste o sbagliate. Un esempio è il gioco dell'impiccato, in cui bisogna indovinare una parola predeterminata procedendo per tentativi una lettera alla volta; ad ogni errore, si aggiunge un elemento al disegno fino a completare l' "impiccato", la fine del gioco con la sconfitta del giocatore che cercava di indovinare e la vittoria dell'altro che ha scelto la parola. In questo esempio si può notare come sia la fantasia a dipendere dall'uso dell'abilità, ma non il viceversa: l'autore chiama intrinseche le fantasie di questo genere. La maggior parte delle fantasie estrinseche dipende quindi sia dalla correttezza e/o efficacia della risposta, sia da fattori di altro genere quale ad esempio la velocità della risposta.

Per le fantasie intrinseche, invece, si ha che l'abilità e la fantasia dipendono vicendevolmente l'una dall'altra. Tipicamente, questo si traduce nel porre i problemi in termini degli elementi della fantasia scelta. Ad esempio, un videogioco di avventura in cui un vasto sistema di caverne viene esplorato dal giocatore tramite input testuale può essere considerato come una fantasia intrinseca per l'abilità nella lettura (delle descrizioni delle caverne fornite fal videogioco) e nella scrittura (dei comandi).

Malone suggerisce come le fantasie intrinseche siano più interessanti ed efficaci di quelle estrinseche. Un primo vantaggio delle prime sulle seconde è che spesso indicano come una certa abilità possa essere utilizzata per raggiungere un certo obiettivo appartenente anche al mondo reale (ad esempio il simulatore di volo). Ancora più importante, quando la fantasia di un gioco è intimamente correlata con il materiale costituente la base del gioco stesso, allora diventa possibile da parte del giocatore inferire in autonomie delle analogie tra il mondo di fantasia (a lui/lei noto) e la materia alla base ancora sconosciuta.

Aspetti emotivi della fantasia
Le fantasie in un videogioco derivano quasi certamente la loro attrattività dall'aiuto che forniscono nel soddisfare le necessità emotive del giocatore. È praticamente impossibile arrivare a conoscerle e a capire come un videogioco potrebbe aiutare a soddisfarle. D'altra parte, i videogiochi che si appoggiano su fantasie di guerra, distruzione o competizione sembrano avere decisamente più successo di quelli basati su fantasie emotive. La visione freudiana di sesso e aggressività come le due principali fonti di stimolo farebbe ipotizzare che ai videogiochi basati su fantasie aggressive si aggiungano quelli basati su fantasie sessuali.

A questo proposito, con il senno di poi e a distanza di più di vent'anni, credo che si possa affermare senza tema di smentita quanto Malone avesse ragione nel prevedere una tale deriva: non bastassero i videogiochi e le avventure, si pensi all'esplosione di siti di carattere pornografico, un fenomeno che richiama un curioso parallelo tra l'espansione della base di utenza di Internet e dello standard VHS per le videocassette, standard affermatosi soprattutto grazie alla diffusione di film pornografici.

Per tornare al merito, una ovvia conseguenza dell'importanza degli aspetti emotivi è che utenti differenti apprezzeranno fantasie differenti: tanto più i progettisti sapranno spaziare tra le varie tipologie di fantasie, tanti più utenti potranno venirne coinvolti. Va detto che sono diversi e complessi i fattori che determinano queste differenze di "gusto" (al di là del gusto personale in sé): il genere (o la tendenza) sessuale, la cultura di provenienza sono solo alcuni esempi di questi fattori.

Curiosità
La curiosità è il motore fondamentale dell'apprendimento, a prescindere da obiettivi da raggiungere o fantasie da soddisfare. I videogiochi possono stimolare la curiosità dell'utente tramite un ambiente né troppo complicato né troppo semplice secondo la conoscenza corrente del giocatore, che sia nuovo e sorprendente senza essere incomprensibile. Più in generale, un tale ambiente dovrebbe essere conosciuto dall'utente abbastanza da permettere di avere delle aspettative su cosa succederà, ma dovrebbe anche fare in modo che queste aspettative non siano sempre soddisfatte.

Curiosità sensoriale
La curiosità sensoriale coinvolge la capacità di attrarre l'attenzione da parte dei cambiamenti percebili visivamente, uditivamente, o attraverso altre stimolazioni sensoriali derivanti dall'ambiente. Un'ipotesi suggestiva spiega come la televisione attragga artificialmente l'attenzione proponendo cambiamenti "contraffatti", dei cosiddetti eventi tecnici come cambi di angolo di ripresa, zoomate o simili; l'artificio risiede nel fatto che l'attenzione viene attratta a prescindere dal contenuto della trasmissione: si va dai 2-3 eventi tecnici al minuto delle trasmissioni delle emittenti pubbliche ai 20-30 degli spot pubblicitari [negli Stati Uniti, nel 1978, N.d.A.].

Analogamente, i videogiochi possono sfruttare lo stesso fenomeno producendo stimoli uditivi e visivi tramite effetti sonori e grafici. Vi sono diversi modi di utilizzare questi meccanismi.

  • Come decorazione. Quando grafica e sonoro vengono usati a prescindere dal corso del gioco e dalle azioni dell'utente, essi possono essere usati come decorativi. Tale tipo di effetti risulta essere efficace per l'interesse iniziale, diventando però rapidamente noioso o addirittura fastidioso (e quindi controproducente).
  • Per aumentare l'efficacia della resa della fantasia. In questo caso, gli effetti grafici e sonori sono interessanti non solo di per se stessi ma anche per le fantasie che evocano tramite associazione di idee, amplificando la resa dell'ambiente del videogioco.
  • Come ricompensa. A seguito di particolari traguardi raggiunti, o in corrispondenza di eventi particolari - positivi o negativi -, un effetto grafico e/o sonoro può aumentare la resa e l'efficacia dei videogioco, alimentando il gusto della sfida e blandendolo.
  • Come metafora di rappresentazione. Banalmente, l'evocatività della fantasia di un videogioco (ad esempio una delle caverne del videogioco di esplorazione descritto sopra) può essere efficacemente incrementata utilizzando grafica e sonoro, in aggiunta o in alternativa alle descrizioni testuali.

Curiosità cognitiva
La curiosità cognitiva può essere descritta come il desiderio di migliorare le proprie strutture cognitive. In particolare, l'autore afferma che noi tutti tendiamo a dare alle nostre strutture cognitive tre delle caratteristiche di ogni ben definita teoria scientifica: completezza, coerenza e sinteticità. Secondo questa teoria, il modo migliore per stimolare la curiosità dell'utente (o dello studente) è di far sembrare la sua attuale conoscenza incompleta, contraddittoria o ridondante. Questo meccanismo è sfruttato per esempio nei romanzi 'gialli', inducendo il lettore ad arrivare fino in fondo per "completare" la propria conoscenza scoprendo finalmente l'identità del colpevole.

Feedback pregnante
Una maniera di rendere gli ambienti dei videogiochi intrigantemente complessi è di renderli responsivi. In particolare:
  • per suscitare la curiosità, il feedback dovrebbe essere una sorpresa per l'utente; la sorpresa si può ottenere tramite pura casualità o, più profondamente, tramite risvolti o comportamenti apparentemente inspiegabili dell'ambiente, spiegabili però dalle regole che modellano l'ambiente, che l'utente può utilizzare per far sì che tali comportamenti "inaspettati" vengano ridotti alla normalità [questa situazione è sicuramente familiare per chi ha giocato SimCity, N.d.A.];
  • per avere valore educativo, il feedback deve essere costruttivo, ovvero non solo far traballare la struttura cognitiva dell'utente, ma anche fornendo indizi e suggerimenti per aumentarne completezza, coerenza e sinteticità.

Verifiche sul campo

In [Mal81], l'autore mette alla prova i principi da lui stesso enunciati in [Mal80] attraverso una indagine effettuata su un campione di studenti. Malone, prima di tutto, sceglie un insieme di videogiochi di genere e tipologia sufficientemente vari per costituire una buona fotografia dell'universo videoludico corrente. Ai videogiochi analizzati viene attribuito un voto relativamente a ciascuna delle caratteristiche considerate rilevanti, risultato del già citato precedente lavoro [Mal80]:
  1. chiarezza dell'obiettivo
  2. calcolo del punteggio
  3. presenza di effetti sonori
  4. casualità degli eventi
  5. rilevanza della velocità di risposta
  6. presenza di effetti grafici/visuali
  7. competizione
  8. livello di difficoltà variabile (crescente)
  9. cooperazione
  10. fantasia/fantasiosità
  11. tipologia di gioco

Come già in [Mal80], vengono elencate le tre caratteristiche che secondo Malone rendono un'applicazione (didattica) interessante, ovvero sfida, fantasia e curiosità.

I videogiochi in esame vengono fatti passare al vaglio degli utenti-campione: a ciascun videogioco viene attribuito un voto di gradimento da parte di ciascun utente e - sempre per ciascun videogioco - si ricava il voto medio. I risultati di gradimento vengono infine correlati con i dati dell'analisi sopradescritta, ottenendo così una classifica che ai primi posti trova le caratteristiche che più si accompagnano al gradimento di un videogioco (vedere l'elenco precedente, che è ordinato per fattore di correlazione decrescente). Un ulteriore dato che l'indagine fornisce è la differenza tra i generi sessuali a riguardo sia dei diversi giudizi di gradimento espressi, sia per la diverso peso attribuito ad alcuni delle caratteristiche oggetto della valutazione. Il risultato in questo caso sta più nella conferma della bontà del metodo utilizzato che nell'effettiva valenza del dato rilevato, in sé già abbastanza intuitivo e anticipabile.

Dai videogiochi alle interfacce

In [Mal82], Malone estende il suo approccio, limitato in [Mal81] alle applicazioni educative, alle applicazioni intese più in generale. Le domande alle quali cerca di rispondere sono sempre quelle già proposte nei due precedenti lavori: perché i videogiochi attraggono così tanto l'attenzione e l'interesse dell'utente? Come si può trasferire questa capacità di attrazione alle interfacce utente delle applicazioni professionali per renderle più interessanti e piacevoli all'uso? Il punto di partenza sono le indagini effettuate nell'ambito di lavori precedenti (tra cui [Mal81]) sul perché i videogiochi piacciano. Le componenti importanti che vengono rilevate sono 2:
  • un obiettivo da raggiungere;
  • la presenza di stimoli alla fantasia (che siano però ben selezionati: una scelta errata in questo caso porta ad un'inversione della valenza, ovvero questi stimoli - sbagliati - alla fantasia diventano una caratteristica negativa).

Le implicazioni dedotte da questa ricerca vengono inquadrate nell'ambito di una struttura il più generale possibile tale che possa costituire una linea-guida per l'analisi e il progetto delle interfacce utente, per renderle piacevoli da tulizzare. Va detto che, più che insieme di requisiti, esso si debba intendere come un insieme di suggerimenti, data l'intrinseca approssimazione dell'ambito di analisi (ovvero il gradimento degli utenti). Inoltre, questi suggerimenti possono essere buoni per alcune tipologie di utente e meno buoni per altre tipologie, buoni per certi contesti di utilizzo ma non per altri.

La dicotomia 'giocattolo' - 'strumento'
Un altro punto da rimarcare è la distinzione tra le due tipologie di sistema dei videogiochi e delle applicazioni professionali, ovvero tra 'sistema-giocattolo' e 'sistema-strumento' (da qui in poi 'giocattolo' e 'strumento'): i primi trovano intrinsecamente il loro senso d'essere, sono fini a se stessi in quanto non soddisfano alcuna esigenza esterna (se non il divertimento dell'utente); i secondi, invece, hanno la loro motivazione principale nell'essere un mezzo per il raggiungimento da parte dell'utente di un obiettivo esterno alle applicazioni stesse.

La dicotomia non è in realtà così ben delineata: le due tipologie, infatti, pur essendo ben differenti l'una dall'altra, hanno svariati punti di contatto. Buoni giocattoli e buoni strumenti possono essere simili per le modalità con cui utilizzano o possono utilizzare le componenti della fantasia e della curiosità, ma sono in opposizione relativamente alla modalità di utilizzo della componente di sfida. Le motivazioni che spingono all'uso di uno strumento o di un giocattolo sono quasi contrapposte: uno strumento viene utilizzato tipicamente per raggiungere obiettivi esterni allo strumento stesso, mentre un giocattolo viene utilizzato solo per il piacere di farlo. Nei casi in cui l'obiettivo esterno che spinge all'utilizzo dello strumento non sia particolarmente motivante, le caratteristiche ludiche che l'autore indica possono rendersi particolarmente utili per far diventare piacevole anche questa attività.

Viene quindi descritta una struttura generica per analizzare il gradimento di un'applicazione in genere - giocattolo o strumento che sia - basandosi sui tre elementi fondamentali più volte citati: sfida, fantasia, curiosità. Lo scopo principale di questa struttura è di fornire una lista di euristiche per la costruzione di interfacce piacevoli da utilizzare: tali euristiche vanno considerate come suggerimenti piuttosto che come requisiti.

Sfida
Affinché un'attività sia stimolante ed impegnativa, è necessaria la presenza di un obiettivo il cui raggiungimento sia incerto; questo si applica soprattutto ai 'giocattoli'. Dall'altra parte, un buon 'strumento' è concepito per aiutare a raggiungere gli obiettivi già presenti nelle attività che li vedono coinvolti.

L' incertezza del risultato è un altro ingrediente importante per sentirsi sfidati nello svolgimento di un'attività. Si potrebbe affermare di primo acchito che questo riguarda esclusivamente i 'giocattoli': se un videogioco dà la certezza della conclusione - positiva o negativa che sia - automaticamente fa cadere l'interesse da parte dell'utente. Al contrario, premettendo una differente definizione del concetto di risultato per 'giocattoli' e 'strumenti', si può vedere che un certo grado di incertezza (o di variabilità, in altre parole) può aiutare a catturare l'attenzione dell'utente e a rendere più stimolante l'utilizzo dell'applicazione - sia essa 'giocattolo' o 'strumento'.

Un indicatore di prestazione (il punteggio nei videogiochi, per esempio) è pure di aiuto: l'utente ha un riscontro di come si sta comportando relativamente al raggiungimento dell'obiettivo e quindi ne viene positivamente stimolato.

Altro importante fattore per mantenere alto l'impegno dell'utente è la variabilità del livello di difficoltà. Di nuovo, questo sembrerebbe un requisito più da 'giocattolo' che da 'strumento': per esempio, nuovamente in Breakout, all'avanzare nei livelli di gioco corrisponde un aumento della velocità della pallina. Nolan Bushnell (il fondatore di Atari Inc.) diceva che "un buon gioco deve essere facile da imparare ma difficile nel fare arrivare a buoni risultati" ("easy to learn, difficult to master" nel testo) [Bus96]. D'altra parte, uno strumento deve essere facile sia da imparare che da padroneggiare: l'obiettivo - esterno al programma - da raggiungere è già incerto per definizione (ad esempio, la scrittura di una lettera tramite un elaboratore di testi, o di un programma tramite un ambiente di sviluppo), e quindi lo strumento deve essere il più "invisibile" possibile. Questa distinzione aiuta a capire perché alcuni utenti trovano estremamente gratificanti e stimolanti programmi molto complessi e difficili da usare: il motivo sta nel fatto che questi utenti trattano i programmi che usano più come giocattoli che come strumenti, la difficoltà accresce la sfida e quindi il piacere di utilizzarli.

Nonostante la differenza sopra descritta, comunque, può essere utile adottare livelli di difficoltà variabili anche in uno strumento, per ottenere una maggiore facilità di apprendimento e insieme uno stimolo all'utilizzo: adattare l'interfaccia al livello di esperienza e alla capacità dell'utente, rendendolo facile da imparare e semplice nell'uso per i principianti, potente e flessibile per gli esperti. L'interfaccia, in altre parole, dovrebbe essere in qualche modo adattiva, mostrandosi in maniera diversa a seconda del livello di esperienza e capacità dell'utente del momento, e variando anche la messaggistica di errore: quella che per un utente avanzato è un'azione lecita, per un utente inesperto si potrebbe considerare come un errore di utilizzo, per esempio nel caso in cui questa azione implichi la conoscenza di concetti sconosciuti, o perlomeno non ancora conosciuti.

La molteplicità degli obiettivi è senz'altro una caratteristica che per i videogiochi contribuisce ad aumentare l'attrattiva: per utilizzare sempre l'esempio del Breakout, l'utente potrebbe essere sfidato non solo nel superamento del livello sic et simpliciter, ma anche nell'abbattimento di tutti i mattoni di una certa fila (ottenendo magari un bonus se si abbattono tutti i mattoni della prima fila senza aver abbattuto ancora nessun mattone nella seconda), oppure nel superamento del livello entro un limite prefissato di tempo (ancora ottenendo un bonus all'eventuale raggiungimento di questo sotto obiettivo). Più in generale, il punteggio e la velocità di risposta sono due tra le chiavi possibili per introdurre obiettivi multipli nei videogiochi. In un certo senso, secondo Malone si potrebbero introdurre meccanismi di questo genere anche in applicazioni di tipo 'strumento' [con un'analogia forse un po' forzata, N.d.A.]: per esempio, un elaboratore di testi utilizzato da una segretaria potrebbe fornire alcune misure - punteggi - relativamente al testo inserito, come la velocità di battuta o il numero di correzioni effettuate (se questi 'punteggi' fossero però a disposizione del capoufficio, l'effetto ottenuto sarebbe molto probabilmente l'opposto). Un altro modo è consentire di modificare il comportamento del programma tramite macro definibili dall'utente, cosicché ad esempio azioni ripetitive possano essere automatizzate, rendendo il lavoro più efficiente, meno alienante e quindi più piacevole.

Fantasia - Emozioni e metafore
La fantasia è probabilmente la caratteristica dei videogiochi che si può più direttamente ed efficacemente utilizzare per le interfacce degli altri programmi.

[MS Agents, cane della ricerca di Explorer - da completare]

Un uso possibile della fantasia nella progettazione di sistemi tradizionali è di dare un aspetto, una personalità differente alle varie parti che compongono il sistema, per caratterizzarle nei confronti degli utenti: ciascuna parte del sistema potrebbe avere una propria tipologia di rappresentazione che aiuti l'utente meno esperto a identificare tale parte e ad inquadrarla correttamente nel contesto di utilizzo; di più, ad ogni utente potrebbe essere offerta una varietà di rappresentazioni più o meno, o diversamente, "fantasiose" tra cui scegliere, così da soddisfare sia l'esperto che il novizio. [Temi di Windows - da completare]

Oltre che per l'appeal emotivo che può offrire, la fantasia è efficace anche in termini di metafora utilizzata: utilizzando modalità rappresentative già familiari all'utente, il processo di apprendimento all'uso del programma risulta facilitato. Secondo l'autore, questo è il motivo principale del successo ottenuto da VisiCalc, il primo programma di calcolo ad utilizzare la metafora del foglio elettronico, adesso così popolare da essere praticamente scontata. Un altro esempio forse ancor più rilevante in questo senso è l'interfaccia utente della workstation Xerox Star, che introduce il concetto della 'scrivania virtuale' simulata sullo schermo: le icone rappresentano oggetti familiari come il cestino, la cartellina, lo schedario, ed operando su di esse l'utente manovra gli oggetti reali sottostanti.

Curiosità
Un'altra componente sensibile della fantasia che i videogiochi evocano è la curiosità. Gli ambienti operativi possono stimolare la curiosità dell'utente se riescono ad essere né troppo semplici (da risultare irrispettosi delle capacità dell'utente) né troppo complessi (da evidenziare le lacune dell'utente), se riescono ad essere innovativi e sorprendenti senza risultare incomprensibili. In particolare, la curiosità sensoriale è un canale molto importante che i videogiochi utilizzano per attrarre il giocatore: gli effetti audio e video possono servire ad abbellire l'interfaccia utente, ad aumentarne l'effetto metaforico, e - ultima ma non meno importante - come sistema di rappresentazione di eventi del sistema (ad esempio: suoni per identificare la conclusione con successo di una certa operazione e per segnalare un errore; grafica al posto di numeri per rappresentare lo stadio di avanzamento di un certo processo). Casualità e umorismo possono ulteriormente contribuire ad aggiungere complessità ad un ambiente operativo: un esempio è il programma 'Fortune', che estrae una frase a caso da un insieme preassegnato; la frase proposta introduce un elemento inaspettato che genera attesa nell'utente e che aumenta perciò la gradevolezza del sistema. Com'è ovvio, questa componente di casualità deve essere usata a proposito: se la risposta casuale risulta essere a sproposito, o magari con umorismo fuori luogo, l'affidabilità dell'ambiente operativo risulta indebolita, e l'effetto ottenuto diventa la frustrazione. La curiosità può essere inoltre utilizzata per provocare l'attenzione dell'utente: le persone creano le proprie strutture cognitive cercando di renderle complete, coerenti e sintetiche. Il progettista può avvantaggiarsene, ad esempio, presentando nuove funzionalità del sistema solamente quando l'utente mostra di averne bisogno (facendo leva sull'incompletezza della sua conoscenza), oppure mostrando che una certa operazione si può svolgere in meno passi (in questo caso è la sintesi che risulta colpita).

Carroll e Thomas - La centralità del divertimento

Dopo che Malone - per primo - punta il riflettore sul divertimento, concentrandosi su cosa rende un'applicazione divertente e sull'importanza rivestita dal (video)gioco in questo ambito, in [CarTho88] Carroll e Thomas puntano il riflettore sul divertimento in sé: cosa vuol dire in realtà 'divertente'? La risposta a questa domanda non è banale e richiede, come intuibile, considerazioni di carattere psicologico (in particolare di psicologia cognitiva).

Il punto di partenza si trova in un precedente lavoro dei due autori, [CarTho82], che riguarda i meccanismi psicologici che vengono innescati dall'interazione con un programma, e in particolare sulle metafore che l'utente (consciamente o inconsciamente) sviluppa e utilizza per poterlo capire e utilizzare. Una descrizione più dettagliata delle basi psicologiche di questo discorso si trova nel capitolo seguente, mentre nel terzo capitolo sono descritte le implicazioni che gli autori deducono relativamente all'apprendimento e alla progettazione di interfacce. Pur non essendo strettamente inerenti a videogiochi e interfacce, rimangono pertinenti perché ritengo il concetto di metafora basilare per la spiegazione del videogioco e del "divertimento da videogioco".

Divertente, non semplice

In [CarTho88], Carroll e Thomas sostengono che la comunità dei ricercatori sulle interfacce uomo macchina ("HCI community") ha solamente una parziale comprensione della modalità secondo la quale analizzare l'usabilità di un programma. Divertente, facile da usare, facile da imparare, produttivo sono termini spesso confusi o erroneamente scambiati: questa confusione è interessante perché spinge a capire perché mai si tende a fare confusione su concetti apparentemente ben distinti; è anche stimolante perché mostra come sia necessario distinguere meglio tra facile e divertente.

Cos’è il divertimento per Carroll e Thomas? Essi sostengono che il divertimento può essere complicato, come ad esempio imparare a colpire delle "curve" nel baseball, o come per una barzelletta, che per essere divertente non deve essere ovvia; un gioco deve contenere una qualche componente di sfida ("challenging" nel testo) per essere interessante. In altre parole, una cosa è divertente quando è abbastanza complicata pur rimanendo trattabile, in pratica né troppo facile né troppo difficile.

Un tema di discussione è l'affermazione che l'elemento-chiave della qualità del software sia nella semplicità: quello che gli autori sostengono è che invece la chiave sia rendere le cose più divertenti e non semplicemente più facili. Uno degli esempi proposti è il sistema "Lisa" (1983), primo esempio di sistema operativo commerciale con interfaccia cosiddetta 'visuale'. Esso venne presentato e diffusamente ritenuto come una svolta nel campo della facilità d'uso e di apprendimento. Una studio condotto all'epoca, al contrario, rivelò che quel sistema molto probabilmente non era più facile di altri sistemi più convenzionali dello stesso periodo: i problemi di apprendimento erano sì di diversa natura, ma c'erano eccome. Ad ogni modo, il sistema Lisa ha costituito una pietra miliare nell'evoluzione delle interfacce, sia per il riconoscimento ottenuto (al di là dell'effettività dei risultati), sia per l'impatto sulle interfacce dei sistemi a venire. "Facilità d'uso" significa semplicità: le cose semplici si imparano velocemente - in pochi passi e con pochi errori -, e si riesce a spiegarle con poche parole. L'ipotesi formulata da Carroll e Thomas per spiegare questo successo è la presenza rilevante della componente divertimento rispetto a quella della facilità d'uso.

Si può senz'altro affermare che c'è una mutua compenetrazione tra i due concetti di cui sopra, sia nell'uso che nell'apprendimento. Il divertimento può implicare difficoltà (ad esempio, imparare a fare canestro da 3 punti). D'altra parte, un apprendimento facile e veloce potrebbe essere ugualmente gradevole (per non dire divertente), nel senso che un'esperienza priva di problemi e di intoppi (ad esempio l'aver imparato in maniera semplice e veloce ad utilizzare con profitto un certo programma) potrebbe essere ricordata con soddisfazione e collegata ad una sensazione di divertimento, per quanto di divertimento in senso letterale non si tratti.

Quanto è importante il divertimento?
Le difficoltà che si incontrano nel tentativo di separare il divertimento dalla facilità d'uso sono incrementate dal meccanismo psicologico della cosiddetta "coerenza cognitiva" ("cognitive consistency"), ovvero la tendenza delle persone alla razionalizzazione delle loro nozioni in una struttura semplice ed altamente coerente; questa teoria, elaborata da L. Festinger nel suo articolo del 1957 "A Theory of Cognitive Dissonance", era già stata introdotta dagli autori in [CarTho82], (e ripresa, perlomeno implicitamente, anche da Malone in [Mal80]). La tendenza alla coerenza cognitiva incoraggia le persone a catalogare arbitrariamente e soggettivamente le loro impressioni e sensazioni in categorie monolitiche. Perciò, a prescindere dal discettare sul fatto che un sistema sia considerato divertente perché facile da usare, oppure facile da usare perché divertente, c'è una tendenza delle persone a generalizzare rispetto ai dettagli, per arrivare a classificare molto più semplicemente il sistema come "buono" - a significare insieme divertente, facile da usare, e forse altro ancora.

La conclusione a cui si può giungere a seguito della confusione dei due concetti può portare a dire che il fattore essenziale per il software è che sia il più semplice possibile: ma, come si è osservato in precedenza, il divertimento richiede che le cose non siano le più semplici possibile. In effetti, le questioni in gioco sembrano essere molto più sottili.

Incertezza e rischio, fantasia e curiosità
Un'altra questione da considerare, sempre secondo Carroll e Thomas, è quella insita nell'incertezza e nel rischio intrinseci nei (video)giochi: parte della motivazione per cui i giochi catturano l'attenzione e motivano l'utente-giocatore all'utilizzo è il fatto che, nell'ambito del gioco, l'utente non ha paura di sbagliare, anzi, i "rischi" sono ammessi, incoraggiati e necessari, e che l'incertezza costituisce un fattore attrattivo anziché repulsivo [vedere nell'altro articolo per il gusto dell'esplorazione e della scoperta - da concludere]. D'altra parte, l'introduzione di una componente di incertezza e/o di rischio in programmi che non siano giochi - quali ad esempio un elaboratore di testi o un foglio di calcolo - non costituisce necessariamente un vantaggio.

La fantasia costituisce senz'altro un fattore di interesse per le applicazioni professionali (gli "strumenti"): l'introduzione di forme di rappresentazione alternative relativamente ad un certo compito da svolgere potrebbe catalizzare maggiormente l'attenzione dell'utente altrimenti a rischio. Il requisito secondo Carroll e Thomas è l'equivalenza logica della rappresentazione: l'utente può svolgere gli stessi compiti di controllo anche se le informazioni vengono proposte in forma diversa ancorché equivalente, e li può svolgere meglio se questa forma alternativa offre elementi di interesse in più.

Dalla fantasia alla curiosità il passo è breve: stimolare la curiosità dell'utente aiuta a catturarne l'attenzione, a far sì che si ponga autonomamente domande sull'utilizzo del sistema e che sempre autonomamente tenda a far progredire la sua conoscenza del sistema stesso.

Studiare il divertimento
Uno dei motivi principali per cui il concetto di divertimento è così sfuggente è che è difficilmente misurabile: se la facilità d'uso si può misurare in termini di tempo di esecuzione di un'azione, di tempo di apprendimento, rassegna e conteggio di errori commessi, come si misura il divertimento? Un altro motivo risiede nella latitanza della ricerca scientifica [al momento della scrittura dell'articolo, N.d.A.], cosa che può essere spiegata - tra il serio e il faceto - chiedendosi quale informatico penserebbe di essere preso sul serio dedicando la sua carriera allo studio del divertimento, con l'eccezione del lavoro - empirico - di Malone dedicato ai programmi educativi: quanto tale lavoro sia rilevante per le applicazioni professionali è tutto da dimostrare.

Per tutte queste ragioni, secondo Carroll e Thomas è necessario iniziare a studiare in maniera sistematica il divertimento e la motivazione che spingono all'uso di un programma, è necessario che nel mondo accademico nasca e venga coltivata una nuova sensibilità riguardo il divertimento e le sue correlazioni con il campo dell'usabilità.

Neal - Prosecuzione del lavoro di Malone e di Carroll e Thomas

Prendendo spunto dal lavoro di Malone, in [Nea90] Neal propone uno studio empirico sull'utilizzazione dei videogiochi, concentrandosi sulle caratteristiche che li rendono attraenti. Il punto di partenza è che le decisioni che guidano la progettazione di un sistema vengono solitamente prese sulla base di motivazioni soggettive e in maniera asistematica senza tener conto delle esigenze del futuro utente del sistema stesso.

Lo studio, di tipo empirico come quello di Malone, presenta delle innovazioni: innanzitutto utilizza come base di analisi un insieme di quattro videogiochi contemporanei all'articolo, rapprensentativi per tipologia e per qualità di implementazione dell'interfaccia, aggiornando così lo studio di Malone che aveva a disposizione un campionario molto meno ampio rispetto al 1990; oltre a questo, introduce nell'analisi la possibilità di giocare un videogioco da parte di più utenti.

Dall'analisi delle caratteristiche identificate che rendono così efficaci i videogiochi analizzati, vengono quindi prodotte delle indicazioni per la progettazione di sistemi in genere: questo aspetto viene trattato nel terzo capitolo.

La caratterizzazione dei videogiochi presi in considerazione

Anche il videogioco più semplice si presenta complesso quando se ne studiano le caratteristiche peculiari e le abilità richieste per poterlo giocare. La caratterizzazione elaborata dall'autrice è basata proprio su questi aspetti, ed è così composta:
  • Obiettivi: già Malone aveva identificato la necessità di un obiettivo chiaro per il successo di un videogioco. Il fattore di novità è il riconoscimento del fatto che gli utenti spesso arrivano a definire degli obiettivi "personali" all'interno del videogioco, quali ad esempio il raggiungimento di una certa abilità nella coordinazione occhio-mano, o l'elaborazione di una strategia di gioco più efficace. La comprensione di questi obiettivi personali può essere utile per l'identificazione di eventuali discrepanze tra le intenzioni dell'utente e le azioni effettivamente intraprese, nonché per l'elaborazione di un efficace feeback che sia rispondente agli obiettivi effettivi dell'utente in ogni momento.
  • Competizione: il ruolo del videogioco può essere attivo, nel caso in cui esso fornisca in qualche modo l'elemento di competizione (ad esempio, un avversario generato dal videogioco), o passivo, nel caso fornisca semplicemente la risposta ai comandi impartiti (oltre che, ovviamente, dare vita all'ambiente del videogioco). Si può definire anche un livello intermedio, o semi-attivo, nel caso in cui un videogioco introduca degli elementi "di propria sponte" senza però esplcitamente competere. L'effetto sugli utenti di questo ruolo attivo o semi-attivo del videogioco si è rivelato essere di indurre paranoia, ovvero di far pensare che vi fosse un intento deliberato contro di loro da parte del videogioco, in questo senso antropomorfizzato, escludendo la casualità degli eventi. L'antropomorfizzazione è stata riscontrata soprattutto con videogiochi attivi o semi-attivi.
  • Aiuto all'utente: è fondamentale sia nelle prime fasi, per fornire all'utente le nozioni di come giocare e come vincere, sia in quelle successive, per rispondere a domande più puntuali o rivolte all'incremento della propria capacità di giocare efficacemente. Una componente particolarmente apprezzata per chiarezza ed efficacia si è rivelata essere la presenza di schermate d'esempio; fornire informazioni aggiuntive dipendenti dal contesto di gioco corrente, e il suggerimento della prossima mossa/azione più conveniente da fare, sono pure state riconosciute utili dai giocatori.
  • Livelli di difficoltà: se i videogiochi mettono a disposizione in maniera esplicita dei livelli di difficoltà tra cui scegliere (sia da parte del giocatore che, in automatico, da parte del videogioco stesso), le applicazioni professionali [da controllare la definizione] nella maggior parte dei casi o non offrono alcuna scelta o limitano questa scelta al "minimo sindacale" della selezione dell'ampiezza del set di comandi.
  • Controllo: molti videogiochi richiedono un controllo intensivo da parte dell'utente. Il controllo è spesso semplificato in videogiochi in cui mouse, tastiera, joystick o altri dispositivi di input sono usati per selezionare piuttosto che per muovere o manipolare oggetti ed elementi del videogioco stesso. Il controllo costituisce tipicamente uno degli aspetti più critici nei videogiochi in tempo reale, in cui la velocità di reazione è fondamentale. Nel controllo risiede uno dei maggiori fattori di attrazione dei videogiochi, laddove il livello di controllo percepito dall'utente è più sentito del livello di controllo effettivamente raggiunto [aggiungere riferimenti alla parte successiva sull'efficacia percepita e reale]. Il senso di controllo deriva dalla capacità da parte delle azioni dell'utente di influire sull'andamento del gioco; tale senso di controllo si può rendere attraverso la responsività (ad ogni azione o inazione del giocatore far corrispondere una reazione prevedibile) e la proposta di scelte esplicite da effettuare, anche se l'eccesso di opzioni può provocare l'effetto contrario, ovvero frustrazione invece di soddisfazione.
  • Strategia: le strategie adottate per giocare un videogioco consistono nella determinazione della miglior mossa successiva, e spesso si basano sulle informazioni acquisite nel corso della sessione di gioco e anche sull'esperienza del giocatore in quel videogioco. Quest'ultimo caso è quello che contraddistingue i videogiochi in cui la casualità ha un ruolo importante o predominante: l'esperienza viene usata per cercare di prevedere la prossima mossa del videogioco, e più in generale per la definizione di una strategia di gioco. Va evidenziato come l'aver identificato la strategia ottimale di gioco, e con ciò la sensazione di non avere più prospettive di miglioramento, fa perdere ogni interesse in un gioco o in un videogioco: il gioco del tris, per esempio, è divertente finché la strategia ottima, essendo a portata, non viene scoperta; in un gioco come gli scacchi, invece, dove la strategia ottima esiste solo in teoria data la limitatezza dei giocatori, non finisce mai di offrire spunti di miglioramento (non considerando ottima la capacità di elaborazione strategica a disposizione degli ultimi super-computer che sono arrivati addirittura a battere i migliori giocatori umani).
  • Scoperta e comprensione delle informazioni: insieme alla capacità di controllo, la comprensione delle regole di funzionamento del videogioco è necessaria per avere successo, nonostante il fatto che spesso il giocatore disponga di informazioni frammtentate o incomplete. La scoperta e l'elaborazione di queste informazioni è fondamentale ed è parte integrante dell'attività di gioco. I videogiochi e anche altre forme di software consentono l'apprendimento incrementale, in cui l'apprendimento delle regole e degli elementi è necessario per utilizzare l'applicazione in modo efficace. Questo può avvenire tramite l'elaborazione e l'uso di analogie o metafore (v.) unitamente alla conoscenza già acquisita, e anche attraverso l'esplorazione, il cui motore è la curiosità, definita come il desiderio di migliorare le proprie strutture cognitive (v. Malone); il sistema di aiuto facilita questo processo, sebbene non sia sempre usato - per scelta, o per indisponibilità o inadeguatezza. La capacità di predire gli eventi di gioco, di rivelare gli elementi nascosti e di valutarne correttamente l'importanza aumentano l'aspettativa [da controllare] di successo da parte del giocatore.
  • Feedback: il feedback serve a dare ai giocatori una misura del loro avanzamento e del loro successo nel gioco. Il punteggio è il tipico esempio di feedback usato dai videogiochi. Quantità e varietà dei feedback forniti contribuiscono a rendere i videogiochi divertenti e di successo, e costituiscono una delle maggiori differenze rispetto agli altri tipi di sofware.

Aycock - Il punto di vista degli sviluppatori di videogiochi

In [Ayc92], Aycock prende in esame alcuni videogiochi e ne intervista gli autori/programmatori chiedendo loro quali siano le caratteristiche che rendono un videogioco di successo.

Il primo elemento che emerge è il divertimento: un videogioco deve essere in primis divertente per attrarre e richiamare l'utente. L'asserzione è senza dubbio banale, ma non per questo meno vera; al di là di considerazioni tecniche, progettuali o implementative, ad un videogioco non deve mancare quel "nucleo di divertimento", quel quid, magari impalpabile, ma importantissimo, che porta l'utente a giocare e giocare e giocare ancora.

La semplicità, secondo l'intervistato di turno, è fondamentale affinché un videogioco funzioni: tanto più è immediato e alla portata dell'utente, tanto più l'utente avrà la possibilità di divertirsi, questo è in sintesi il principio esposto. 'Semplice da usare' non vuol dire 'semplice' tout court, un'interfaccia ed un metafora semplici possono benissimo enucleare un'ambiente di gioco dalle caratteristiche anche molto complesse. L'esempio riportato è 'Lemmings': un gruppo di roditori tende inesorabilmente ad avanzare, e il giocatore può attribuire speciali "poteri" o capacità a queste creature per far loro superare ostacoli o passaggi difficili. L'autore rimarca il fatto che, da un gruppo iniziale di 20 caratteristiche tra cui l'utente poteva scegliere, alla fine ne ha fatte rimanere solo 8, un parco di possibilità apparentemente limitato ma che in realtà offre una grandissima varietà di opzioni al giocatore.

La storia è un altro importante fattore che determina il gradimento di un videogioco: non è solo questione di vincere, è rilevante anche il percorso attraverso il quale si arriva alla vittoria. La vicenda narrata, l'approfondimento psicologico dei personaggi, l'identificazione nel protagonista, sono tutti elementi di successo, alla stessa stregua di film e romanzi. È senz'altro vero che queste considerazioni fanno pensare subito alle avventure, per le quali la storia è il nucleo fondante e fondamentale del successo o dell'insuccesso; è vero altresì che un buon background narrativo e di caratterizzazione dei personaggi e degli ambienti giova sicuramente anche al videogioco di azione pura.

L'aspetto tecnologico è un ulteriore fattore di successo: introdurre effetti speciali sfruttando al massimo le potenzialità del mezzo a disposizione, arricchire di particolari lo scenario, rendere le scene con il maggior realismo possibile possono dare all'utente il coinvolgimento massimo, l'illusione di "essere veramente lì".

<<<QUI>>>


Capitolo 2 – Psicologia e videogiochi

Carroll e Thomas - L'importanza della metafora adottata

Già nel 1890, William James rilevava come le persone tendano ad imparare facendo uso delle proprie conoscenze già acquisite: almeno inizialmente, i nuovi concetti vengono espressi in termini dei vecchi concetti già noti e ben compresi. In [CarTho82], gli autori si concentrano sul ruolo giocato dall'apprendimento per metafore quando una persona vuole impadronirsi di una certa applicazione. I differenti livelli di competenza giocano un ruolo fondamentali: se un utente esperto utilizza la conoscenza di sistemi già noti per impararne uno nuovo, utilizzando quindi una metafora molto diretta, un utente meno esperto o non esperto per nulla tenderà ad utilizzare metafore tratte da conoscenze meno direttamente connesse (ad esempio, iniziare ad utilizzare un elaboratore di testi potrebbe far richiamare ciò che si sa sull'uso delle macchine da scrivere). La naturale conseguenza è i progettisti di applicazioni dovrebbero tenere conto di queste considerazioni, e cioè anticipare e incoraggiare tali "costruzioni metaforiche" per incrementare la facilità di apprendimento e di utilizzo, e per guidarne in maniera attiva il processo di formazione così da minimizzare il rischio della scelta di una metafora inefficace o - peggio - controproducente.

Il superamento del modello di apprendimento "paired-associates" ("coppie-associate")

Immaginiamo di voler descrivere il processo di apprendimento di un certo linguaggio di comandi. Una possibile descrizione è la seguente:
  • per prima cosa, bisogna saper riconoscere le sequenze di lettere come significanti di comandi e non come stringhe di caratteri senza senso;
  • bisogna inoltre conoscere la definizione del comando e che cosa fa, ovvero il suo significato;
  • infine, bisogna essere in grado di richiamare il nome del comando quando si pensa alla funzione che svolge, e di richiamare la funzione quando si legge il nome del comando.
Questo costituisce l'approccio della teoria tradizionale sull'apprendimento in psicologia: coppie di elementi arrivano all'attenzione; si sviluppano immagini mentali degli elementi; gli elementi vengono messi in interrelazione.

Il principio della struttura

Il limite insito in questa visione di "coppie-associate" si trova nel fatto che solitamente le persone non imparano coppie isolate, e che questi accoppiati-associati vengono messi in relazioni gli uni con gli altri. Per esempio, consideriamo un editor di testi che fornisce degli shortcut per determinati comandi, e che uno di questi shortcut sia la lettera 'U' per 'up'; consideriamo adesso in maniera separata un'altra abbreviazione, 'D' per 'delete': la combinazione delle due può però generare confusione, in quanto per la maggior parte delle persone l'associazione 'U'-'up' implicherebbe l'associazione 'D'-'down'. Gli accoppiamenti devono essere organizzati e razionalizzati in una super-struttura, per formare un insieme coerente.

Da questa considerazione gli autori traggono il "principio della struttura": le persone imparano strutture, non coppie-associate isolate; l'interfaccia di un'applicazione dovrebbe essere dotata di una struttura coerente.

Il principio della metafora

Si può quindi dire che l'apprendimento di una qualasiasi coppia-associata ha influenza sull'apprendimento di ogni altra coppia-associata. Relativamente alla reciprocità tra richiamo e uso di coppie-associate, si possono trovare delle analogie anche nel comportamento umano: una teoria che descrive questa relazione è il cosiddetto modello EPAM elaborato dai due studiosi Simon e Feigenbaum. Questa teoria può essere sintetizzata come segue: - una certa porzione della schiera di stimoli presentati al soggetto viene percepita e codifica in uno o più simboli; - una struttura cognitiva viene creata o estesa mettendo in relazione il nuovo simboli con quelli già facenti parte della struttura stessa; - quando il materiale appreso viene richiamato, si attiva una intera struttura cognitiva.

Al fine di valutare l'effettiva rilevanza della sovrastruttura alle coppie-associazioni costituita dalle strutture cognitive, gli autori effettuano un'indagine su un campione di utenti non-programmatori con oggetto un semplice linguaggio di comandi per muovere un robot, al fine di rilevare lo stile e l'efficacia delle soluzioni adottate per risolvere diversi problemi inerenti al controllo del robot stesso. Questa indagine rivela che al variare della struttura complessiva del linguaggio di comandi, identiche coppie-associazioni tra comando e funzione producevano nei diversi soggetti prestazioni molto diverse sia nell'apprendimento che nella risoluzione dei problemi.

Questa ed altre esperienze svolte portano Carroll e Thomas ad afffermare il "principio della metafora": le persone sviluppano nuove strutture cognitive tramite l'utilizzo di metafore a strutture cognitive già acquisite.


Capitolo 3 - Imparare dai videogiochi

Malone - Una lista di suggerimenti

La seguente lista riassume quelle caratteristiche rilevanti dei videogiochi che possono essere utilizzate anche per le applicazioni professionali:
  1. Sfida
    1. Obiettivo. L'attività ha un obiettivo chiaro? Viene fornito un feedback sullo stato di avanzamento rispetto all'obiettivo da raggiungere?
    2. Incertezza del risultato. Il risultato è incerto?
      1. L'attività ha un livello di difficoltà variabile? Per esempio, l'interfaccia dispone di diversi strati di complessità?
      2. L'attività ha obiettivi a diversi livelli? Per esempio, l'interfaccia include un meccanismo di punteggio-feedback?
  2. Fantasia
    1. L'interfaccia incoropora fantasie coinvolgenti dal punto di vista emotivo?
    2. L'interfaccia incorpora metafore con sistemi - fisici e non - già a conoscenza dell'utente?
  3. Curiosità
    1. L'attività fornisce il livello ottimale di complessità di informazione?
      1. Utilizza effetti audio e video: - come decorazione, - per esaltare la fantasia, - come metafora di rappresentazione?
      2. Utilizza la casualità aggiungendo varietà senza rendere l'applicazione inaffidabile?
      3. Utilizza l'umorismo in maniera appropriata?
    2. L'interfaccia fa leva sulla pulsione dell'utente per strutture cognitive ben formate? Fornisce nuove informazioni quando la conoscenza dell'utente si rivela - incompleta, - incoerente, o - ridondante?

Sebbene non tutte queste caratteristiche siano utilizzabili a priori, molte interfacce utente trarrebbero sicuramente giovamento dall'inclusione sistematica di caratteristiche quali: - diversi strati di complessità, - metafore produttive e coinvolgenti, - effetti grafici e sonori utili.

Carroll e Thomas - Come scegliere la metafora da utilizzare

Le metafore richiamate da una persona quando cerca di imparare, o quando viene insegnato, ad utilizzare un'applicazione sono determinanti per il successo o l'insuccesso in questo obiettivo di apprendimento. A questo proposito, [CarTho82] contiene alcune raccomandazioni, da prendere non come precetti ma, più elasticamente, come linee-guida, le quali, oltre che per insegnare ad usare un programma e per scriverne un manuale d'uso, rimangono valide anche per progettarlo.

Adattando per l'occasione un celebre proverbio, si può dire in questo caso che "l'abito fa il monaco".

Raccomandazioni per l'utente novizio

Le persone che non dispongono di uno specifico addestramento molto probabilmente non prescinderanno mai dalla rappresentazione metaforica iniziale del sistema: l'efficacia della metafora da loro richiamata al primo contatto con la nuova applicazione può avere implicazioni a lungo termine e influenzare sia il risultato finale del processo di apprendimento che il successivo effettivo utilizzo dell'applicazione stessa, in particolare in quesi casi in cui l'utilizzazione dell'applicazione sia opzionale.

Raccomandazione 1: utilizzare le metafore appropriate

Per essere efficace, la metafora deve appoggiarsi su una relazione adatta all'oggetto della metafora stessa; questa relazione deve essere congruente, deve esistere cioè un isomorfismo - almeno parziale - tra la metafora e il suo oggetto.

L'esempio riportato dagli autori è quello della metafora tra un programma di elaborazione testi e un macchina per scrivere, esempio questo tanto calzante quanto datato: entrambi gli strumenti si utilizzano tramite una tastiera e, oltre alla ovvia comunanza dei tasti alfanumerici e della punteggiatura, la metafora viene rispettata anche per i tasti di maiuscolo temporaneo ("shift") e di maiuscolo fisso ("caps lock"). Ci sono però, com'è ovvio, delle incongruenze: ad esempio, per posizionare il punto di scrittura con la macchina per scrivere si utilizzano la barra spaziatrice e e il tasto di ritorno a capo, direttamente la manopola del rullo per andare indietro; utilizzare lo stesso approccio con un elaboratore di testi porterebbe a risultati non certo ottimali; un altro esempio di incongruenza, forse ancora più pregnante, è quello della necessità di salvare il lavoro in corso di realizzazione, concetto questo totalmente estraneo alle macchine per scrivere. I messaggi di errore sono un'altra fonte di problemi: se i messaggi di errore del programma utilizzano parole delle quali un utente novizio non può neanche intuire il significato (come potrebbe essere ad esempio "I/O error"), si rischia di mandare in frantumi anche la migliore metafora.

[se si riesce, trovare un esempio non antidiluviano: le cartelle/folder dei desktop, magari?]

Lemma: tra più metafore, scegliere la più appropriata, ovvero quella che copre il maggior numero di aspetti del sistema

Raccomandazione 2: la metafora deve essere adatta all'attitudine emotiva presunta dell'utente

Va rimarcata l'importanza della "congruenza emotiva", cioè della necessità per una metafora di essere, oltre che più isomorfa possibile al suo oggetto, anche di essere "emotivamente" appropriata. Sarebbe sbagliato, ad esempio, realizzare un'interfaccia dal tono giocoso per un programma utilizzato da consulenti finanziari, categoria che (non da sola) oltre che di capacità, serietà ed affidabilità, necessita anche di dimostrare tali caratteristiche.

Raccomandazione 3: la metafora deve essere trasparente

Un'altra proprietà che deve caratterizzare la metafora è di essere trasparente all'utente, in altri termini deve essere abbastanza "naturale" da non richiedere passi logici forzati.

Raccomandazione 4: la metafora deve essere semanticamente disgiunta dal proprio oggetto

Se il dominio semantico di appartenenza della metafora è troppo "vicino" a quello del suo oggetto, il rischio che si corre è quello di fare confusione tra i due domini, mescolandone proprietà e peculiarità, arrivando infine ad assunzioni sbagliate.

Raccomandazione 5: quando è necessario usare più metafore, esse devono essere tutte abbastanza vicine tra loro

Per esempio, nell'interfaccia grafica di un sistema operativo, un sistema di cartelle come metafora per il file system, unito al cestino come metafora per la gestione delle cancellazioni (ripristinabili, proprio come con un cestino vero!), è senz'altro in accordo.

Raccomandazioni per l'utente esperto

Le raccomandazioni impartite finora sono soprattutto adatte alla fase di apprendimento di un sistema, fase questa più rilevante per gli utenti novizi (anche e soprattutto dal punto di vista temporale). A questo punto la questione è come consentire all'utente oramai esperto - se non d'altri, del sistema corrente - di proseguire nel suo percorso. Una possibilità è quella di rimuovere progressivamente la "protezione" costituita dalla metafora. L'altra possibilità è sostituire la metafora di partenza con altre metafore via via più complesse e adatte alla maggiore comprensione dell'utente.

Raccomandazione 6: presentando una metafora, rimarcarne sempre sia i limiti che l'eventuale natura temporanea

Nella maggior parte dei casi, una metafora inizialmente utile diventa ad un certo punto limitante per l'evoluzione dell'utente: quelle semplificazioni che in principio rendevano il sistema approcciabile diventano un freno. Quando una metafora comincia a fallire, è opportuno sostituirla con una nuova più letterale, avvicinandosi così ulteriormente all'oggetto. Un suggerimento a questo proposito è di evidenziare la natura temporanea di una metafora, sottolineando le disomogeneità con l'oggetto, all'inizio del suo utilizzo: per l'utente sarà quindi più facile sia accorgersi di essere limitato da essa, sia di familiarizzare più efficacemente con quella subentrante.

Raccomandazione 7: adottare metafore accattivanti in caso di lavori monotoni, utilizzando anche diversi formati o stili ma senza cambiare il paradigma [verificare la pertinenza del termine]

Un fattore che influisce considerevolmente, specie negli utenti inesperti, sull'efficacia e sulle prestazioni in fase di apprendimento, sono le motivazioni [riferimenti agli altri articoli che ne parlano: Malone- come 'sfida' - non citato in bibliografia!, Nea90, ISW94, RSN98, Dra99, la sezione "Il divertimento come motivazione"]. Le motivazioni possono essere di tipo estrinseco (ad esempio, lavorare per sostentarsi) o intrinseco (ad esempio, scrivere poesie per passione); ci sono anche casi in cui le due tipologie convivono: ad esempio, un lavoratore a cui viene concesso un aumento, oltre a mantenere la motivazione intrinseca, guadagnerà molto probabilmente anche in motivazione intrinseca, vedendosi riconosciute le sue aspettative e capacità. Una considerazione a questo proposito è che la motivazione di tipo intrinseco è, perlomeno nella maggior parte dei casi, più stimolante, e regge comunque meglio sulla lunga distanza; allo stesso tempo, però, è molto più difficile da indurre.

L'esempio proposto è relativo ad un programma di sorveglianza di un processo industriale, sorveglianza che potrebbe essere attuata adottando metafore di rappresentazione del sotto-sistema da controllare più interessanti e stimolanti, quali l'esposizione di un "processo virtuale" come la guida di un aereo, che fornisce la rappresentazione dei dati rilevati. L'utente "pilota" l'aereo, ovvero controlla i parametri del processo in questione, e l'aereo risponde secondo le reazioni del processo sotto controllo. [vedi anche ChaD01?, Doom come interfaccia per 'ps'].

Ci sono due aspetti centrali in questa proposta di utilizzare metafore basate sul (video)gioco nell'ambito di lavori monotoni:

  • la dinamicità;
  • il coinvolgimento.

I videogiochi sono intrinsecamente dinamici e coinvolgenti, tanto dinamici e coinvolgenti quanto un'interfaccia "normale" non potrà mai essere. Ulteriormente, il modello del videogioco si presta perfettamente ad agevoli cambiamenti di scenario (ovvero di formato o stile).

Una proposta su questa linea che gli autori citano è quella di Fields e Negroponte, che nel loro lavoro del 1977 "Using New Clues to Find Data" ipotizzano l'utilizzo di un'interfaccia tipo simulatore di volo per "navigare" nello spazio di informazioni di una base di dati.

Sarebbe interessante esplorare il panorama corrente per analizzare le applicazioni che lo compongono e verificare se denotano una progettazione che tiene conto di queste considerazioni.

Neal - Imparare dai videogiochi

In [Nea90], attraverso uno studio empirico di un insieme-campione di videogiochi, Neal ne identifica una serie di caratteristiche e tecniche la cui adozione potrebbe migliorare il progetto delle applicazioni professionali.

Progettazione dei comandi

In genere, inconsistenza e irreversibilità dei comandi provocano dei problemi di interazione, sia nel caso dei videogiochi - caratterizzati di solito da un insieme relativamente piccolo di comandi - , ma anche e soprattutto nel caso dei sistemi professionali. La consistenza dell'insieme dei comandi è importante perché consente all'utente di fare previsioni sull'effetto di una certa operazione avendo noto l'effetto di un'operazione simile. La reversibilità è importante dal momento che la possibilità di annullare gli effetti di un'operazione effettuata può agevolare ed incentivare notevolmente l'esplorazione del sistema.

Feedback del risultato

Uno dei modi attraverso i quali i videogiochi riescono ad essere più efficaci rispetto alle applicazioni professionali è costituito dai sistemi di feeback (in genere, il punteggio) che propongono all'utente per indicare il livello del successo dell'utente nella sessione di gioco corrente. Anche se l'utente di un sistema professionale può arrivare a sviluppare autonomamente misure dell'avanzamento o del successo nel compito correntemente svolto, il sistema non sempre offre supporto a tale tendenza, con il risultato che l'utente non ha mai una sensazione precisa del punto al quale è arrivato, o di quanto distante si trovi dal raggiungimento dell'obiettivo. Un sistema di punteggio traslato al mondo delle applicazioni professionali potrebbe essere ipotizzato relativamente ad un sistema di sviluppo: l'utente-programmatore ha l'obiettivo di scrivere del codice che sia corretto, efficiente, e anche scritto nella maniera migliore e più chiara possibile, senza errori sintattici e possibilmente senza warning; in questo contesto, un possibile sistema di punteggio potrebbe essere costruito a partire da un collegamento tra il progetto del programma in corso di preparazione ed il codice sorgente del programma stesso, collegamento che consentirebbe di "calcolare" quanta parte del progetto è stata implementata; a seconda del linguaggio utilizzato, poi, si potrebbero trovare altri tipi di misura, quali ad esempio l'incidenza dell'utilizzo dell'ereditarietà multipla (considerata non una buona pratica) in un ambiente ad oggetti, o l'utilizzo di variabili statiche; in particolare il Test First Design (o anche Test Driven Development), una metodologia di lavoro appartenente alla famiglia dell'Agile Development, che si va affermando in questi ultimi anni, si presta a questo genere di misurazione.

Sistema di help e responsività del programma

Il ruolo dell'help e dei messaggi che il programma fornisce all'utente è quello di supportarlo nel raggiungimento dell'obiettivo prefisso, e di prevenire errori derivanti dall'uso sbagliato o improprio del sistema stesso. Il sistema di help deve essere facilmente accessibile, per non costituire un ulteriore motivo di frustrazione per l'utente che sta muovendo i primi passi, sia per il richiamo in sé, sia per la localizzazione dell'informazione ricercata; a tale proposito, i sistemi cosiddetti contestuali sono di notevole aiuto perché evitano all'utente l'onere di trovare il "punto giusto", proponendo direttamente la pagina relativa al contesto attuale del programma; importante è anche la strutturazione del sistema di help: una struttura logica e prevedibile semplifica enormemente l'utente alla ricerca dell'informazione che lo può sbloccare.

I messaggi che il programma propone all'utente a seguito delle sue azioni sono altrettanto importanti: specialmente per gli utenti inesperti, o particolarmente ansiosi, l'assenza di "risposta" da parte del programma a seguito di un'azione dell'utente - corretta o meno che sia - può generare dubbio e nervosismo, dal momento che viene a mancare l'approvazione (o la disapprovazione) esplicita dell'azione stessa, con la conseguente insicurezza relativamente all'esito. La risposta non deve essere necessariamente espressa in forma testuale: l'utilizzo di un particolare effetto audio nell'ambito di un codice sonoro noto può essere altrettanto se non più efficace.

Livello di difficoltà progressivo

Una delle principali modalità attraverso le quali i videogiochi stimolano la sfida nell'utente è l'esistenza dei livelli di difficoltà. Questo principio, che per i videogiochi si è dimostrato vincente, è stato per nulla, o solo in maniera rudimentale, adottato anche per le applicazioni professionali. La definizione di sottolivelli di comandi costituisce un esempio di progressione del livello di difficoltà per i programmi professionali, progressione che può alimentare nell'utente, come detto sopra, la componente della sfida; questo esempio è molto spesso messo in pratica molto grossolanamente tramite l'introduzione di due diverse modalità, quella "novizio" e quella "esperto", le quali, sebbene d'aiuto, costitituiscono solo una realizzazione parziale del principio. Tenendo traccia del grado di efficacia dell'utilizzo dei comandi appartenti al livello corrente, il sistema potrebbe proporre all'utente un "avanzamento" nel livello di difficoltà, ovvero un'estensione - mirata - dell'insieme di comandi.

Al contrario dei videogiochi, per i quali l'aver raggiunto il massimo della prestazione corrisponde di solito a noia e disamoramento, l'applicazione professionale che viene utilizzata al massimo dell'efficienza e delle possibilità porta l'utente ad affezionarsi sempre di più. Paradossalmente, questo si può rivelare un difetto: difficilmente la tendenza dell'utente sarà quella di abbandonare la vecchia e ben nota applicazione per utilizzare quella nuova, anche se quest'ultima si dovesse rivelare molto più efficace; per i videogiochi, invece, il fenomeno è esattamente speculare.

<<<QUI>>>


Bibliografia

[Ayc92] Aycock H. E., "Principles of Good Game Design", Compute, 14(1), 1992, 94-98.
[Bar01] Bartneck C., "How Convincing is Mr. Data's Smile: Affective Expressions of Machines", User Modeling and User-Adapted Interaction, 11(4), Kluver Academic Publishers, 2001, 279-295. Anche in http://www.bartneck.de/work/bartneck_umuai.pdf
[Bar03] Bartneck C., "Interacting with an Embodied Emotional Character", Proc. 2003 Interna-tional Conference on Designing Pleasurable Products and Interfaces, New York, ACM, 2003, 55-60.
[Bat03] Battarbee K., "Co Experience: the Social User Experience", in: Proc. CHI 2003, New York, ACM, 2003, 730-731.
[Bat03a] Battarbee K., "Defining Co Experience", in: Proc. 2003 International Conference on De-signing Pleasurable Products and Interfaces, New York, ACM, 2003, 109-113.
[Bay93] Bailey G., "Iterative Methodology and Designer Training in Human Computer Interface Design", in: Proc. SIGCHI Conference on Human Factors in Computing Systems, New York, ACM, 1993, 198-205.
[BroBel04] Brown B., Bell M., "Late Breaking Result Papers: Social Interaction in 'There' ", Ex-tended Abstracts of the 2004 Conference on Human Factors and Computing Systems, New York, ACM, 2004, 1465-1468. Anche in: http://people.cs.uct.ac.za/~dnunez/reading/papers/p1465-brown.pdf
[BryHig00] Bryce J., Higgins D., "Optimal Experience: a Framework for Understanding the Phe-nomenology of Computer Use", in: Smalley N., Brake M., Saunders D., "International Simulation and Gaming Yearbook", 2000, 197-205.
[Bur96] Burcham S. E., "The Video Game [R]evolution", ACM Crossroads Student Magazine, 3(2), 1996, http://www.acm.org/crossroads/xrds3-2/vgmusnew.html.
[Bus96] Bushnell N., "Relationships between Fun and the Computer Business", Communications of the ACM, 39(8), 1996, 31-37.
[CarTho82] Carroll J. M., Thomas J. C., "Metaphor and the cognitive representation of computer systems", IEEE Transactions on Man, Systems, and Cybernetics, SMC-12 (2), 1982, 107-116.
[CarTho88] Carroll J. M., Thomas J. C., "Fun", SIGCHI Bulletin, 19(3), 1988, 21-24.
[CCO97] Cherny L., Clanton C., Ostrom E., "Entertainment is a Human Factor: a CHI 97 Workshop on Game Design and HCI", SIGCHI Bulletin, 29(4), New York, ACM, 1997, 50-54. +++ Citazione di Carroll & Thomas, di Malone.
[ChaD01] Chao D., "Doom as an Interface for Process Management", in: Proc. SIGCGI Conference on Human Factors in Computing Systems, New York, ACM, 2001, 152 157.
[ChuBly99] Churchill E. F., Bly S., "Virtual Environments at Work: Ongoing Use of MUDs in the Workplace", Proc. International Joint Conference on Work Activities Coordination and Collabora-tion, New York, ACM, 1999, 99-108.
[CKK99] Choi D., Kim H., Kim J., "Toward the Construction of Fun Computer Games: Differ-ences in the Views of Developers and Players", Personal Technologies, 3(3), 1999, 92 104.
[Cla98] Clanton C., "An Interpreted Demonstration of Computer Game Design", in: CHI 98 Con-ference Summary on Human Factors in Computing Systems, New York, ACM, 1998, 12.
[CWMJ00] Cahill B., Ward R., Marsden P., Johnson C., "Fun, Work, and Affective Computing: Can Psychophysiology Measure Fun?", in: Proc. Computers and Fun - 3, University of York, 2000. Pubblicato in: Interfaces, 46, 2001, 11, http://www.bcs hci.org.uk/interfaces/interfaces46.pdf.
[DCJC02] De Angeli A., Cameron D., Johnson G. I., Coventry L., "Is Verbal Humour Possible for Chatterbots?", in: Proc. Computers and Fun - 4, University of York, 2001. Pubblicato in: Interfa-ces, 50, 2002, 20, http://www.bcs-hci.org.uk/interfaces/interfaces50.pdf.
[DFSW04] Dourish P., Finlay J., Sengers P., Wright P., in: Proc. Reflective HCI: Towards a Criti-cal Technical Practice - A Workshop at CHI 2004, 2004, http://www.cs.cornell.edu/people/sengers/ReflectiveHCI/ReflectiveHCIProceedings.pdf.
[Die03] Diederiks E. M. A., "Buddies in a Box - Animated Characters in Consumer Electronics", in: Proc. 8th International Conference on Intelligent User Interfaces, New York, ACM, 2003, 34-38.
[DowLon89] Dowell J., Long J., "Towards a Conception for an Engineering Discipline of Human Factors", Ergonomics, 32(11), 1989, 1513-1535.
[DowLon98] Dowell J., Long J., "Conception of the Cognitive Engineering Design Problem", Ergonomics, 41(2), 1998, 126-139.
[DPBG03] Dyck J., Pinelle D., Brown B., Gutwin C., "Learning from Games: HCI Design Innova-tions in Entertainment Software", in: Proc. Graphics Interface 2003, Halifax, 2003, http://hci.usask.ca/publications/2002/games/games.pdf, 8 febbraio 2003.
[Dra99] Draper S. W., "Analysing Fun as a Candidate Software Requirement", Personal Technolo-gies, 3(1), 1999, 117-122, http://www.psy.gla.ac.uk/~steve/fun.html, 8 febbraio 2003.
[ESA04] Entertainment Software Association, "Essential Facts about the Computer and Video Game Industry - 2004", http://www.theesa.com/IDSABooklet.pdf, 17 ottobre 2004.
[Fal03] Fallman D., "Design-oriented human-computer interaction", in: Proc. ACM Conference on Human Factors in Computing Systems, New York, ACM, 2003, 225-232.
[Fen00] Fencott C., "The Perceptual Opportunities of an Ordinary Day", 2000, http://www-scm.tees.ac.uk/users/p.c.fencott/research/gamasutra/GamaPO.htm.
[FogNas97] Fogg B. J., Nass C., "Silicon Sycophants: the Effects of Computers that Flatter", Inter-national Journal of Human-Computer Studies, 46(5), 1997, 551-561.
[For04] Forlizzi J., "Experience, Emotion and Design", 2004, http://www.designandemotion.org/de64.php.
[Gar01] Gardner P., "Games with a Day Job: Putting the Power of Games to Work", 2001, http://www.gamasutra.com/features/20010601/gardner_01.htm, 8 febbraio 2003.
[Gri00] Grice R., "I'd Rather Play Computer Games than Do Real Work. Wouldn't you?", Make It Easy 2000 Conference, IBM, 2001, http://www 3.ibm.com/ibm/easy/eou_ext.nsf/Publish/1217/$File/Grice.pdf, 8 febbraio 2003.
[GriStr00] Grice R., Strianese L., "Navigating the New Media: Learning and Building Strategies with Computer Games", Proc. IEEE Professional Communication Society International Professio-nal Communication Conference and Proc. 18th Annual ACM International Conference on Computer Documentation: Technology & Teamwork, IEEE, 2000, 535-540.
[HarRai96] Harrison, A. W., Rainer R. K, "A General Measure of User Computing Satisfaction", Computers in Human Behavior, 12(1), 1996, 79-92.
[Has00] Hassenzahl M., "Truly Enjoyable Software is neither 'Tool' nor 'Toy' ", in: Angewandte Sozialpsychologie in Organizationen, La Clusaz, 2000.
[HBB01] Hassenzahl M., Beu A., Burmester M., "Engineering Joy", IEEE Software, 18(1), 2001, 70-76. [HBS99] Hassenzahl M., Burmester M., Sandweg N., "Perceived Novelty of Functions - a Source of Hedonic Quality", in: Proc. Computers and Fun - 2, University of York, 1999. Pubblicato in: In-terfaces, 42, 2000, 11-12, http://www.bcs-hci.org.uk/interfaces/interfaces42.pdf.
[Hol93] Hollnagel E., "The Design of Reliable HCI: The Hunt for Hidden Assumptions", Proc. HCI'93 Conference, People and Computers VIII, Cambridge, Cambridge University Press, 1993, 3 15.
[Hol99] Hollnagel E., "Keep Cool: The Value of Affective Computer Interfaces in a Rational World", Proc. HCI International (the 8th International Conference on Human-Computer Interac-tion) on Human-Computer Interaction: Ergonomics and User Interfaces-Volume 1, Lawrence Erl-baum Associates Inc., 1999, 676-680.
[HPBL00] Hassenzahl M., Platz A., Burmester M., Lehner K., "Hedonic and Ergonomic Quality Aspects Determine a Software's Appeal", Proc. SIGCHI Conference on Human Factors in Comput-ing Systems, New York, ACM, 2000, 201-208.
[HPS98] Höök K., Persson P., Sjölinder M., "From Task-Based to Fun-Based Design: Evaluation of Navigational Tools", in: Proc. Computers and Fun, University of York, 1998. Pubblicato in: Inter-faces, 40, 1999, 8-9, http://www.bcs-hci.org.uk/interfaces/interfaces40.pdf.
[HWEML03] Heeter C., Winn B., Egidio R., Mishra P., Lownds N., "Focusing on User-to-Product Relationships: Girls as Space Game Designers: Extreme Baseline Research", Proc. 2003 conference on Designing for user experiences, 2003. Anche su http://www.aiga.org/resources/content/9/7/8/documents/heeter.pdf
[HCMME03] Heeter C., Chu K., Maniar A., Mishra P., Egidio R. "Comparing 14 Forms of Fun (and Learning and Gender Issues) in Commercial Versus Educational Space Exploration Digital Games", in: International Conference on Digital Games Research Conference, Netherlands, 2003. Anche in http://commtechlab.msu.edu/publications/files/forms_of_fun.pdf.
[IDS02] Interactive Digital Software Association, "Essential Facts about the Computer and Video Game Industry - 2002", http://www.theesa.com/IDSABooklet.pdf, 17 ottobre 2004.
[ISW94] Igbaria M., Schiffman S. J., Wieckowski T. J., "The respective roles of perceived useful-ness and perceived fun in the acceptance of microcomputer technology", in: Behaviour & Informa-tion Technology, 13(6), 1994, 349-361.
[JohC98] Johnson C., "Using Cognitive Models to Transfer the Strengths of Computer Games into Human Computer Interfaces", in: Proc. Computers and Fun, University of York, 1998. Pubblicato in: Interfaces, 40, 1999, 5-6, http://www.bcs-hci.org.uk/interfaces/interfaces40.pdf. Anche in http://www.dcs.gla.ac.uk/~johnson/papers/ics/fun_and_games.html
[JohC99] Johnson C., "Taking Fun Seriously: Using Cognitive Models to Reason about Interaction with Computer Games", in: Personal Technologies, 3(1), 1999, 105-116, http://www.dcs.gla.ac.uk/~johnson/papers/um99/games.htm.
[JohJ98] Johnson J., "Simplifying the Controls of an Interactive Movie Game", in: Proc. SIGCHI Conference on Human Factors in Computing Systems Table of Contents, New York, ACM, 1998, 65 72.
[JuWag97] Ju E., Wagner C., "Personal computer adventure games: their structure, principles, and applicability for training", ACM SIGMIS Database, 28(2), 1997, 78-92.
[KGH85] NO! Krueger M., Gionfriddo T., Hinrichsen K., "VIDEOPLACE - An Artificial Reality", in: Proc. 1985 Conference on Human Factors in Computing Systems, New York, ACM, 1985, 35 40.
[KurKas95] Kurosu M., Kashimura K., "Apparent Usability vs. Inherent Usability", Conference Companion on Human Factors in Computing Systems, New York, ACM, 1995, 292-293.
[LinWhi04] Lindgaard G., Whitfield T. W. A., "Integrating aesthetics within an evolutionary and psychological framework", Theoretical Issues in Ergonomics Science, 5(1), Taylor & Francis, 2004, 73-90.
[Mal80] Malone T. W., "What Makes Things Fun to Learn? Heuristics for Designing Instructional Computer Games", in: Proc. 3rd ACM SIGSMALL Symposium and the First SIGPC Symposium on Small Systems, New York, ACM, 1980, 162-169.
[Mal81] Malone T. W., "What Makes Computer Games Fun?", Byte, December, 1981, 258-277.
[Mal82] Malone T. W., "Heuristics for Designing Enjoyable User Interfaces: Lessons from Com-puter Games", in: Proc. 1982 Conference on Human Factors in Computing Systems, New York, ACM, 1998, 63-68.
[MHBR02] Monk A. F., Hassenzahl M., Blythe M., Reed D., "Funology: Designing Enjoyment", in: CHI 2002 Extended Abstracts on Human Factors in Computer Systems, New York, ACM, 2002, 924-925.
[Mon02] Monk A. F., "Fun, Communication and Dependability: Extending the Concept of Usabil-ity", in: Proc. HCI 2002, London, 2002, 3-14, http://www users.york.ac.uk/~am1/MonkHCI02.PDF, 8 febbraio 2003.
[Mic2000] Microsoft , "Microsoft Agents", 2000, http://www.microsoft.com/msagent.
[Mul04] Muller M., "HCI as Translation Work: How Translation Studies Can Inform HCI Research and Practice", in: Proc. Reflective HCI: Towards a Critical Technical Practice - A Workshop at CHI 2004, 2004, http://www.cs.cornell.edu/people/sengers/ReflectiveHCI/ReflectiveHCIProceedings.pdf.
[Nea90] Neal L., "Implications of Computer Games for Systems Design", Interact 90, 1990, 93 99. [PetFra98] Petrie H., Francis J., "Playfulness, Persistence and Computer Use: a Study of Individual Differences", in: Proc. Computers and Fun, University of York, 1998. Pubblicato in: Interfaces, 40, 1999, 6, http://www.bcs-hci.org.uk/interfaces/interfaces40.pdf.
[PGST94] Pausch R., Gold R., Skelly T., Thiel D., "What HCI Designers Can Learn from Video Game Designers", in: Conference Companion on Human factors in Computing Systems, New York, ACM, 1994, 177-178.
[Por95] Porter D. B., "Computer Games - Paradigms of Opportunity", Behavior Research Methods Instruments & Computers, 27 (2), 1995, 229-234.
[RSN98] Rieber L. P., Smith L., Noah D. "The Value of Serious Play", Educational Technology, 38(6), 1998, 29-37, http://it.coe.uga.edu/~lrieber/valueofplay.html, 8 febbraio 2003.
[Saw02] Sawyer B., "Enhancing Simulations, Models and Their Impact Using Interactive Game Design and Development Practices and Technology", 2002, http://wwics.si.edu/subsites/game/Serious2.pdf, 8 febbraio 2003.
[SFLNR94] Skelly T. C., Fries K., Linnett B., Nass C., Reeves B., "Seductive Interfaces: Satisfying a Mass Audience", in: Conference Companion on Human factors in Computing Systems, New York, ACM, 1994, 359-360. [Spa04] Sparisci D., "Il Navigatore Satellitare Diventa un Videogioco", Repubblica.it, 10 luglio 2004, http://www.repubblica.it/2004/g/motori/luglio04/navsatgioco/navsatgioco.html.
[Spr98] Springel S., "Introducing the "Virtual Theatre" Immersive Drama Project", in: Proc. Computers and Fun, University of York, 1998. Pubblicato in: Interfaces, 40, 1999, 6-7, http://www.bcs-hci.org.uk/interfaces/interfaces40.pdf.
[Tho99] Thomas R. C., "Riding the Wave of the Reckless Explorer", in: Proc. Computers and Fun - 2, University of York, 1999. Pubblicato in: Interfaces, 42, 2000, 13-14, http://www.bcs-hci.org.uk/interfaces/interfaces42.pdf.
[Tog93] Tognazzini B., "Principles, Techniques, and Ethics of Stage Magic and Their Application to Human Interface Design", in: Proc. INTERCHI, 1993, ACM, New York, 355-362.
[Tra97] Tractinsky N., "Aesthetics and Apparent Usability: Empirically Assessing Cultural and Methodological Issues", in: Proc. SIGCHI Conference on Human Factors in Computing Systems, New York, ACM, 1997, 115-122.
[WBL98] Wright P., Belt S., Lickorish A., "Animation, the fun factor and memory", in: Proc. Computers and Fun, University of York, 1998. Pubblicato in: Interfaces, 40, 1999, 7-8, http://www.bcs hci.org.uk/interfaces/interfaces40.pdf.
[Web88] Webster J., "Making Computer Tasks at Work More Playful: Implications for Systems Analysts and Designers", in: Proc. ACM SIGCPR Conference on Management of Information Sys-tems Personnel, 1988, 78-87.
[WMM00] Wright P., McCarthy? J., Marsh T.,"From Usability to User Experience", in: Proc. Com-puters and Fun - 3, University of York, 2000. Pubblicato in: Interfaces, 46, 2001, 4-5, http://www.bcs-hci.org.uk/interfaces/interfaces42.pdf.


Parte di struttura ancora da sistemare

      1. [Ayc92] cosa rende divertente un videogioco – l’opinione di alcuni autori e progettisti.
      2. [JuWag97] Analisi di diverse avventure, anche tramite interviste a campioni di giocatori.
      3. [JuWag97] Cosa rende le avventure piacevoli (storia, ricchezza di particolari, plot, velocità narrativa, gioco di ruolo) e stimolanti (compiti da portare a termine, livello di comkplessità, difficoltà).
      4. [JuWag97] Valore educativo delle avventure. La gente apprezza l'interfaccia e la storia, e si sente sfidata dall'avventura stessa. Adatto all'apprendimento di nozioni, meno adatto all'apprendimento della pianificazione e alla "conoscenza negativa" (riferimento a Malone). L’interfaccia povera (grafica, sonoro, input), obiettivi troppo semplici e svolgimento lento rendono il programma poco attraente.
      5. [CKK99] What makes a computer game fun? Different views from programmers and players. – Analysis of game design factors; - rating of the relative importance of the design factors: developers vs. players.
      6. [CKK99] Result: no factor is important and resolutive by itself. - It depends on the type of game (e.g. adventure-role playing, strategic); - not specific rules: not “why games are fun”, but “why people think game are fun”; - many limits in the survey.
      7. [Fen00] Perceptual Opportunities, ovvero l’analisi dei videogiochi secondo 3 differenti tipi di significato che gli oggetti possono avere: sicurezze (significato denotativo – sedia come l’oggetto su cui sedersi), sorprese (siginificato connotativo – sedia utilizzata mettendola su un tavolo e salendoci sopra per raggiungere un oggetto in alto), shock (errori percettivi che inducono a rompere le illusioni create dai 2 tipi precedenti). Le sorprese si dividono a loro volta in: attrattori, connettori, ricompense. I PO costituiscono una ulteriore chiave di lettura per capire cosa rende divertente un videogioco e per provare a trasferire tali caratteristiche ad altri videogiochi (generi di) [o addirittura ad altri tipi di applicazione]
    1. Misurare il divertimento
      1. [WMM00] Giocosità (divertimento) nel computer non è un valore assoluto
      2. [PetFra98] Playful attitude to the computers is very beneficial (about “computerphobia”)
      3. [PetFra98] Persistence is another relevant aspect: because it is often required more than one attempt to obtain what is wanted from a computer, you need to persist and try again (explore?) until you make it done
      4. [PetFra98] Computer playfulness scale is correlated to: - computer attitudes; - computer anxiety rate; - computer self-efficacy; - adjective self list (need to seek the novelty of the experience); - participant’s sex.
      5. [CWMJ01] Indicatori fisiologici per la misura del divertimento.
      6. [HarRai96] Definizione di una misura per la ‘user computing satisfaction’.
      7. [WBL98] “Animation, the fun factor and memory” Misurare il divertimento
    2. Apparenza o sostanza
      1. [KurKas95] Apparenza Vs. Sostanza: l’abito fa il monaco, ovvero l’usabilità apparente (percepita dall’utilizzatore) dipende più dall’aspetto estetico dell’interfaccia che non dalla effettiva usabilità della stessa.
      2. [HBS99] Importanza delle qualità edoniche.
      3. [Tra97] Relazione tra l’estetica e l’usabilità apparente non correlata alla realtà culturale.
      4. [HPBL00] Sempre sulle qualità edonica e ergonomica, soggettivamente ed indipendentemente percepite. Differenza tra valori attesi e sperimentati. Più importante la qualità edonica? Utilità e divertimento contano ugualmente nel gradimento di un’interfaccia da parte dell’utente. Citazione da Fun di Carroll e Thomas: non confondere “Easy to use” e “Fun to use”. Facilità d’uso implica semplicità, abbastanza incompatibile con il divertimento nell’uso.
      5. [FogNas97] Il computer che adula: effetti positivi sul gradimento dell’utente. Lezione che i videogiochi hanno imparato e impartito: gratificare l’utente, riconoscendo le cose buone che ha fatto o semplicemente senza motivo; attrarre l’utente funziona.
      6. [SFLNR94] Interfacce seduttive, come attrarre anche l’utente passivo.
      7. [ISW94] Perceived usefulness and perceived fun.
      8. [DCJC02] Programmi che simulano un umano per conversare con l’utente. Perché si parla con un programma invece che con una persona?
      9. [Bar01] Efficacia delle espressioni umane interpretate dal computer.
      10. [Bar03] Interazione con un personaggio “emotivo” (riferimento all’agente graffetta Microsoft). Gli animali sono dei buoni soggetti perché l’utente non si aspetta che parlino o che comprendano il linguaggio parlato (a parte semplici comandi vocali – ideale per il livello attuale delle interfacce vocali), e tende a “perdonare” eventuali errori.
      11. [HPS98] Non-serious (nor polite) computer agent
      12. [Die03] Utilità dei personaggi animati per l’interazione utente. Aumento del gradimento di sistemi di interazione per l’elettronica di consumo (es. “consiglieri per programmi” integrati in un televisore) tramite l’utilizzo di personaggi animati.
      13. [Hol99] Interfacce emotive possono essere utili nel miglioramento dell’efficacia di interazione [i videogiochi non sono forse per loro stessa natura ‘emotivi’?]
    3. Il divertimento come motivazione
      1. [PGST94]
      2. [Mal81] fantasia intrinseca ed estrinseca
      3. [RSN98] Propongono la distinzione tra lavoro (intrinseco) e svago (estrinseco) (‘work vs. leisure’ nel testo). Questa dicotomia è però meno efficace e applicabile rispetto a intrinseco/estrinseco: un’attività come ‘andare dal dentista’ verrebbe classificata come svago dal momento che non si viene pagati per farlo (anzi!), e di converso a molta gente piace il proprio lavoro e non lo fa solo perché ne trae sostentamento; lavoro e svago contengono una implicita contrapposizione, che risulta fuorviante.
      4. [RSN98] Apprendimento e motivazione – l’uno è funzione dell’altra
      5. [RSN98] Perché le persone dedicano a certi compiti enormi risorse di tempo, di attenzione, di emozione? Il gioco è l’esempio perfetto che riunisce queste caratteristiche
      6. [RSN98] Il gioco è un metodo adatto per quei casi in cui sono richiesti pensiero ad alto livello e profondo coinvolgimento personale. Le tendenze dello sviluppo dei computer manifestano notevoli possibilità di supporto da parte della tecnologia interattiva
    4. ‘Serious play’
      1. [RSN98] “Serious play”: special kind of intense learning experience in which both adults and children voluntarily devote enormous amount of time, energy and commitment and at the same time derive great enjoyment from the experience
      2. [RSN98] Even if adults tend not to like the definition of “play”, it suites perfectly adult’s activities in certain situations
      3. [RSN98] Serious play is based on a complex set of conditions
      4. [RSN98] Definition of ‘play’: voluntary activity involving active (often physical) engagement that is pleasurable for its own sake and includes a make-believe quality
      5. [RSN98] 3 levels of playing (at least): 1) participation 2) problem solving 3) catalytic action
      6. [RSN98] 4 themes around which play’s literature is organized: play as progress, play as fantasy, play as self, play as power
      7. [RSN98] Commonsense says that play is the opposite of work. The other point of view is the “pleasurability-purposefulness” model from Blanchard
      8. [RSN98] Maximum pleasurability means being in a state of “flow”
      9. [RSN98] Videogames are not mind-numbing: (youngsters, children) players are perfectly aware of rules and relationships among objects and characters, they have mastered complex virtual worlds, at the point that they would be able to pass the toughest test
      10. [RSN98] Motivation in education: 1) motivation to initially participate in a task; 2) subsequently to persist in the task
      11. [RSN98] Motivation: – intrinsic reasons; – extrinsic reasons (; – compliance). See Malone: intrinsic motivation based on the attributes of challenge, curiosity, fantasy and control
      12. [RSN98] No dichotomy between extrinsic and intrinsic motivations: to love our job, to enjoy studying for a test. Self-determination makes to coexist extrinsic motivations and personal choice (intrinsic motivations)
      13. [RSN98] Games are a way of telling stories (see edutainment games – COLORS, Drive)
      14. [RSN98] Difference between boys and girls (in the way they differently enjoy videogames)
      15. [Dra99] Distinzione tra motivazione intrinseca (l’attività ha senso in sé, ad esempio ‘mangiare’) ed estrinseca (l’attività ha senso per le conseguenze che produce, ad esempio ‘lavorare per guadagnare uno stipendio’). Le due cose non sono necessariamente contrapposte (ad esempio, si può fare un lavoro per trarne sostentamento ma anche perché piace farlo), possono essere presenti sia singolarmente che insieme. Perfeziona [RSN98].
      16. [Dra99] Una cosa è divertente da fare se non viene fatta solamente per raggiungere uno scopo, ma piuttosto se viene fatta per l’attività in sé. Si gioca per il solo piacere di farlo: giocare è divertente anche se alla fine si perde; giocare sarebbe noioso se si sapesse dall’inizio che la vittoria è sicura.
      17. [Dra99] Il divertimento, comunque, non è l’unica forma di motivazione intrinseca. In un videogioco la grafica, il sonoro e la musica sono divertenti anche se ‘non si giocano’ in se; allo stesso modo, una certa informazione (ad esempio, la risposta in un quiz , o la ‘prossima puntata’ in una serie televisiva) può essere divertente pur essendo certamente non giocabile.
      18. [Dra99] “learning by exploration” Vs. “problem-based learning”.
      19. [ISW94] Elementi importanti: ansietà nell’uso del computer, utilità percepita (motivazione estrinseca), divertimento percepito (motivazione intrinseca), soddisfazione. L’utilità percepita influenza maggiormente l’accettazione da parte dell’utente, mentre il divertimento percepito influenza di più la soddisfazione rispetto all’utilità percepita. Suoni, colori e personaggi animati aiutano nel far accettare il sistema e ad invogliare l’utente ad usarlo. [problema molto minore ora di quanto non fosse 15 anni fa, NdA?]. Lavorare sul divertimento per sdrammatizzare e diminuire l’ansia. Importanza della comprensione delle attese dell’utente. Validità dell’utilizzo di metodologie derivate dai videogiochi.
    5. Gioco o strumento
      1. [RSN98] “Serious play”; work vs. leisure; Apprendimento e motivazione – l’uno è funzione dell’altra; ... e molto altro.
      2. [Has00] Un software professionale può trarre grande giovamento dall’utilizzo di metafore ludiche. Non c’è la dicotomia strumento-giocattolo (tool-toy).
      3. [Gri00] Progetto di software professionale che utilizzi l’esperienza dei videogiochi. Ripetizione delle esperienze di Malone.
      4. [Bus96] Videogiochi come incubatori di tecnologia “seria”. I videogiochi hanno inventato il concetto di interfaccia-utente. Introduzione storica, e possibilità future.
      5. [CCO97] Citazione di Carroll e Thomas. Velocità di apprendimento in ambienti a ricambio frequente per personale sotto-acculturato ma che videogioca.
      6. [Gar01] Scacchi come metafora di gioco per insegnare le tecniche della guerra. Marketing games, videogiochi pubblicitari-promozionali, come un cavallo di Troia.
    6. Ricerche e sondaggi su utenti finali
      1. [Por95] Analisi statistica sistematica per spiegare come i giocatori riescono ad eccellere nei videogiochi. Utilizzo di approcci diversi: oggettivo (osservazione passiva – si mettono in relazione misurazioni dell’input e i risultati conseguiti a seconda dei diversi obiettivi posti,), soggettivo (interviste/questionari), empirico (partecipazione attiva del ricercatore introducendo variazioni sistematiche nelle condizioni dell’esperimento).
      2. [IDS02] e [ESA04] Sondaggio sulla percezione dei videogiochi (perchè giochi, ecc.). Si ritrova Malone. Chi gioca (sesso, età). Chi compra (sesso, età). Quale tipo vende di più.
      3. [HWMEL03] Differenze nell’approccio al progetto e all’apprendimento dei videogiochi tra ragazzi e ragazze, giovani e adulti
    7. Il divertimento è sempre un requisito?
      1. [DowLon89] Importanza dei fattori umani nel progetto delle interfacce. [I videogiochi possono rientrare]
      2. [Dra99] Il divertimento non può essere un requisito per tutti i programmi. Se la funzione principale del programma è -il soddisfacimento dell’utente, oppure -l’apprendimento, e la facilità di apprendimento dell’utilizzo del programma (‘learnability’) è un obiettivo secondario importante.
      3. [Dra99] Videogiochi. Punto di partenza: i 2 articoli di Dowell e Long [DowLon89] e [DowLon98]. Essi affermano che i benefici di una buona interazione si trovano nell’ambito del lavoro – esterno al programma –, mentre relativamente all’utente si parla solo di costi (di interazione). In altre parole, scopo e benefici di un’interfaccia devono essere esterni al programma, in un certo qual modo oggettivi, contrariamente ad un’analisi incentrata sull’utente che rivolge l’attenzione alla risposta dell’utente e al suo gradimento. La loro analisi non comprende i videogiochi, e più in generale non comprende quelle attività i cui obiettivi sono ‘stati mentali – dell’utente’ piuttosto che ‘stati esterni – della realtà’.
      4. [Dra99] Il divertimento non è proprietà di un’attività, ma piuttosto della relazione tra l’attività e gli obiettivi individuali del momento: la maggior parte delle cose che si considerano divertenti da fare durante la giornata perdono tutta la loro attrattiva durante la notte (ad esempio, una telefonata di un amico durante il giorno è piacevole, la stessa telefonata nel bel mezzo della notte non lo è affatto). Perciò, affinché il gioco risulti piacevole, deve richiedere una capacità di risposta da parte dell’utente che sia compatibile con il suo attuale livello di ‘attenzione’ (‘arousal’ nel testo).%BRIn pratica, si può affermare che si dovrebbero progettare giochi diversi per i diversi momenti dell’utente: di sicuro i videogiochi ad alto contenuto competitivo e che richiedono grande attenzione e concentrazione da parte dell’utente sono una parte del discorso; d’altra parte, la programmazione televisiva attuale dimostra un bisogno notevole di svago ‘passivo’, nullo in termini di sfida, e che richieda poco o nulla in termini di attenzione attiva. Ci sono anche altri esempi (forse più positivi) di attività a bassa richiesta di attenzione, come una passeggiata per riflettere su un problema che si sta affrontando. (O per rimanere strettamente in ambito videoludico, ‘Tetris’, gioco che si fa per rilassarsi più che per vincere). La distinzione non sta nei diversi tipi di utente, ma piuttosto nei diversi momenti nei quali l’utente può vivere un’esperienza interattiva, quanto è attivo e quanto è pronto alla sfida.
      5. [Dra99] “learning by exploration” Vs. “problem-based learning”. LbE: means determined in advance, effect is learned. PBL: result determined, means to be discovered.
      6. [Dra99] Play: to discover the outcome of the process, or the consequences of the game rules. Play is learning, while learning is not necessarily play, but it should be: once learning was only tedious repetition and exercise, it should be always playing-oriented. Same as in SW engineering: once waterfall (analysis, design, developing, test, release), now discover by exploration (prototyping, or even XP).
      7. [Dra99] Problem-based learning: medical schools, cooking schools, motivating not because of u flow, but for the strong link between learning and their “real world”. To make learning enjoyable does not necessarily mean that fun has to be added, because it gives the message that work needs it. Fun is not the root matter for learning support software (see [Rie96] for an opposite point of view). Intrinsic/deep motivation for adults is a strong component: no need for fun/play (can be no joy), satisfaction is in “going to the target”.
      8. [Dra99] Difference between youngsters and adults: no goal Vs. goal.
      9. [Dra99] Play is at most one of the components, fun is not the only – nor the best – way.
      10. [Dra99] OSs requires constant learning (they continuously change), so fun could be of use (e.g. animations, sounds). But could be also resented if taking time/attention during a work goal.
    8. L’usabilità deriva dal divertimento?
      1. [MHBR02] ‘Usabilità’ à non necessariamente un fattore positivo: è proprio vero che divertimento, piacere e soddisfazione implicano usabilità?
      2. [MHBR02] Scarsi effetti dopo Malone e Carroll & Thomas
      3. [MHBR02] Assenza di ricerche specifiche sia di psicologia cognitiva che di psicologia emotiva relativamente al divertimento (siamo proprio sicuri?, verificare). Di contro, molta attenzione ad argomenti ‘negativi’ quale ad esempio lo stress dell’ansia da computer (o tecnofobia). Eccezione: [ISW94]
      4. [MHBR02] È proprio vero che divertimento, piacere e soddisfazione implicano usabilità?
      5. [MHBR02] Soddisfazione à fattore altamente soggettivo
      6. [MHBR02] Storicamente gli studi si sono dedicati soprattutto alle interfacce dei programmi professionali, adesso i computer stanno entrando/sono entrati anche nelle case e nelle scuole. Questo ha portato ad un risveglio delle ricerche sul divertimento.
      7. [MHBR02] Né strumenti utili ma ottusi, né giocattoli fantasiosi ma inutili: porsi come obiettivo la soddisfazione di requisiti edonistici/edonici (cioè non strettamente utili) e la loro integrazione con i requisiti più orientati all’obiettivo. (sempre dicotomia giocattolo <-> strumento, vedi [Mal82])
  1. Capitolo 2 – Psicologia e videogiochi
    1. I concetti di ‘flusso’ e di ‘esperienza ottimale’
      1. [BryHig00] La comprensione dell’uso intrinsecamente motivato e piacevole/soddisfacente/enjoyable del computer è un mezzo importante per incorporare divertimento e piacevolezza nei sw educativo e per l’utlizzazione dei videogiochi e simulazioni come mezzi per l’apprendimento.
      2. [BryHig00] Definizione di 'flusso' secondo Csikszentmihalyi. Caratteristiche che contraddistinguono lo stato di flusso.
    2. Flusso conscio e inconscio
      1. [Dra99] Il concetto di flusso-i (‘u-flow’ nel testo) e di flusso-c (‘c-flow’).
        Flusso-i: flusso continuo ma inconscio di azioni da parte di un individuo (ad esempio, guidare seguendo un percorso ben noto; passeggiare pensando ad altro).
        Flusso-c: flusso continuo di azioni che, al contrario di quanto accade nel flusso i, vengono gestite attivamente e occupano la consapevolezza dell’individuo (ad esempio, guidare abbastanza velocemente per una strada sconosciuta; leggere un libro essendone completamente assorbiti). Ogni passo è seguito senza problemi dal successivo: la persona non pensa a nient’altro, non ha preoccupazione riguardo alla scelta della successiva cosa da fare, né di aver dimenticato altre cose importanti da fare. Il flusso-c corrisponde inoltre ad un equilibrio ottimale tra la noia e l’ansia.
      2. [Dra99] Videogiochi. Il termine ‘flusso’ viene introdotto da Mihaly e Isabella Selega Csikszentmihalyi nel lavoro “Optimal Experience: Psychological Studies of Flow in Consciousness” del 1988, ripreso poi dal solo Mihaly nel 1990 in “Flow: The Psychology of Optimal Experience”, lavori questi non inquadrabili nel settore dello studio delle interfacce uomo-macchina. La teoria formulata è quella dell’ “esperienza ottimale”, si basa su interviste e questionari coinvolgendo gruppi-campione composti anche da pittori e scultori, e cerca di descrivere cosa succede in quei periodi molto produttivi di totale coinvolgimento, per riferirsi ai quali si utilizza il termine ‘flusso’.
      3. [Dra99] Un altro autore, Jones, in “Creating Engagement …”, per caratterizzare l’esperienza di flusso elenca le seguenti proprietà: task that we can complete; ability to concentrate on task; task has clear goals; task provides immediate feedback; deep but effortless involvement (losing awareness of worry and frustration about everyday activity); exercising a sense of control over our actions; concern for self disappears durino flow, but sense of self is stronger after flow activity; sense of duration of time is altered.
      4. [Dra99] Csikszentmihalyi’s analysis misses the component of the ‘engagement’, in addition to c flow and u flow. These components are difficult to measure.
    3. I modelli cognitivi
      1. [JohC98] e [JohC99] Utilizzazione dei modelli cognitivi, strumenti derivati dalla psicologia affettiva, per analizzare (più) in profondità i meccanismi di interazione utilizzati dai videogiochi. Approccio innovativo ma che produce risultati difficili da applicare a causa dell’inadeguatezza/imprecisione dei paradigmi di progettazione attuali. Unsuitable for the analysis of the activity of a group (think something new?).
      2. [DowLon98] Sulla trasformazione del progetto di HCI da arte a tecnica.
      3. [HBB01] Ingegnerizzazione dell’usabilità. Vedi cognitive engineering. Utilizzare la soddisfazione dell’utente nel progetto del software. Ridefinire l’usabilità. Qualità edoniche.
    4. [DFSW04] ‘Reflective HCI’ e ‘critical technical practices’. Reflective HCI, ovvero un nuovo approccio basato sulle scienze sociali, studi culturali, teoria critica e fenomenologia. Riferimento a Philip Agre, “critical technical practices”. Nel workshop si esplorano le “CTP” nell’HCI come modo di integrare l’esplorazione delle assunzioni fondamentali sottostanti le attuali pratiche con lo sviluppo di nuove forme di progetto dell’interazione.
    5. [Fal03] Design-oriented HCI. Tipologie di progettazione e loro relazione con l’HCI. Differenza tra design-oriented research e research-oriented design. 3 direzioni di progetto: conservativa, romantica, pragmatica.
    6. [CWMJ00] psicofisiologia.
    7. Magia e interfacce
      1. [Tog93] Principi della magia applicabili al progetto di interfacce: consistenza; unità, semplicità, utilizzo di metafore del mondo reale, user testing.
      2. [Tog93] Varie definizioni di interfaccia utente: incarnazione del modello di progetto del progettista, virtualità, mito dell’esteriore, illusione-utente.
      3. [Tog93] Principi della magia applicabili alle interfacce: carattere, regolarità, concisione.
    8. [Hol93] L' “utente perfetto”.
    9. [Spr98] Anonyminity, or the ‘Karaoke effect’
    10. ‘Human factors’
      1. [DowLon89] Definizione di una disciplina: enunciazione del problema generale; pratiche di soluzione del problema; conoscenza a supporto delle pratiche. Categorizzazioni derivanti dal contesto di applicazione.
      2. [DowLon89] Difetti delle pratiche HF che inducono alla ricerca di forme alternative: sono poco o nulla integrate nelle pratiche di sviluppo dei sistemi (gli sviluppatori effettuano le scelte sull’interazione invece degli esperti HF, che sono limitati alla valutazione finale del sistema); sono di dubbia utilità (l’efficacia non è affatto garantita); sono inefficienti (l’esperienza fatta da altri viene persa e va quindi ri appresa di continuo); non ci sono segni di miglioramento relativamente ai 3 problemi sopracitati.
      3. [DowLon89] Non è corretta l’assunzione che l’indeterminismo del comportamento umano escluda a priori una formalizzazione delle conoscenze HF. Bisogna dimostrare se il comportamento umano si può considerare deterministico per gli scopi della progettazione di interfacce (di programmi di computer): solo da questo si potrà determinare la possibilità di rendere formale la conoscenza della disciplina HF.
      4. [DowLon89] Test attitudinali – diretti e indiretti – per selezionare gli utenti (magari è l’utente che è “sbagliato”, non l’interfaccia). Formazione per compensare le deficienze rilevate. Manuale a supporto della formazione dell’utente. L’interfaccia implementa una certa specifica dell’utente.
        Al momento [della stesura di questo articolo, NdA?] la progettazione di interfacce è un’arte, non una scienza applicata.


  1. Capitolo 3
    1. Usabilità e divertimento
      1. [Mon02] Extend usability concept from traditional definition (ease of learning, low level ease-of-use, task fit) with: - enjoyment; - effective communication; - dependability. Examples: “Virtual Pub” application, “Mavis’ home” domotics suite.
      2. [Mal81] Caratteristiche per una buona applicazione (didattica): sfida, fantasia, curiosità.
      3. [Mal81] “increasingly complex microworlds”, i.e. interfacce adattive che si propongono in maniera differente a seconda dello skill dell’utente, e diventano più complesse e potenti via via che l’utente diventa più esperto; tentativo in questa direzione sono i menu adattivi di WinXP?, l’interfaccia stessa di WinXP? che si può scegliere essere semplice (con più figure, con meno cose da configurare) o complessa; personalizzabilità del SO.
      4. [WMM01] Da ‘interazione’ a ‘esperienza’, un nuovo concetto di usabilità.
    2. Usabilità e facilità di apprendimento
    3. [Bay93] Identikit del perfetto progettista. Non si sa quali effettivamente siano le caratteristiche-chiave di una buona interfaccia utente, né quali siano le competenze-chiave di un buon progettista (progettisti Vs. programmatori: vincono i progettisti). Reference to XP in the last paragraph (‘rapid application development techniques’).
    4. ‘Design-oriented HCI’
    5. Dai videogiochi alle applicazioni professionali – come e perché
      1. [Web88] motivazioni per portare il gioco al lavoro; Designing computer systems to make tasks at work more playful may result in real advantages to users and organizations. Focus on playfulness at work (playfulness for adults, not for children). Define characteristics of playful activities (Malone, Csikszentmihalyi) à outline their relationship to work.
      2. [Web88] Parallel between play and learn-by-exploration in computer activity (user loses awareness when concentrate on computer – as in play). Computer activity can be also distracting.
      3. [Web88] Users try to make their work more playful (even/especially when repetitive).
      4. [Web88] Analysis from Malone, Carroll, Csikszentmihalyi. Suggestions from Malone, Carroll et al. to design playful behaviors in computer systems (to cause more positive affect at work, heightened concentration, less awareness of time).
      5. [Mul04] Visione di HCI come lavoro di traduzione da progettisti ad utenti.
      6. [CarTho82] Videogiochi più facili da imparare; più facile ricordare come si usano.
      7. [GriStr00] Applicare la lezione appresa dai videogiochi sui software professionali. Norman: caratteristiche di un ambiente ad elevato apprendimento. Esperimento su 2 diversi simulatori di flipper per verificare l’effetto di vari fattori (es. suoni, musica, ecc.). Nell’articolo mancano i risultati.
    6. Cosa fare, cosa evitare – lezioni dai videogiochi
      1. [JohJ98] Identifica i difetti dell’interfaccia: si possono estendere anche ai programmi “normali”. Adeguamento dell’interfaccia al contesto.
      2. [Has00] La dicotomia tra strumento e giocattolo non va considerata nella progettazione di sistemi software (vedi [Mal82])
      3. [Tho99] Si parla dei diversi stili di esplorazione, e della progettazione orientata ad assecondare i diversi stili.
      4. [KurKas95] Verifica sul campo (test di usabilità) prima della commercializzazione
      5. [KurKas95] Importanza della risposta sonora del programma all’input dell’utente.
      6. [WBL99] Graphics (and sound?) linked to text can (not necessarily) increase the enjoyment of reading (depending on the context of application). Graphics with verbal text enhances the enjoyment but reduces memory of the text (graphics gives more fun, but it’s less effective).
      7. [For04] Esperienza ed emozione come elemento di progetto delle interfacce.
      8. [PGST94] Imparare dai videogame per l’HCI: un po’ di idee.
      9. [DBPG03] I videogame sono l’applicazione di maggior successo nella storia del software nonostante non abbiano mai seguito i dettami dell’usabilità. 4 idee/approcci alternativi di progetto che funzionano per i videogiochi (tratti da esperienze nel mondo reale) da applicare anche alle applicazioni professionali.
      10. [DPBG03] Learning from games. Utilizzare le caratteristiche dei videogiochi per migliorare i programmi normali
      11. [DPBG03] raggruppamento facilitato degli utenti (effortless community – per i giochi online). I videogiochi sfruttano la naturale tendenza all’associazione dei videogiocatori, offrendo sistemi per reperire in rete avversari contro cui giocare, o gruppi di gioco a cui unirsi. Molti programmi normali (es. Photoshop, centinaia di migliaia di post nei newsgroup) possiedono questo amplissimo bacino potenziale ma non lo sfruttano. Gli elementi chiave sono: connessione semplice alla comunità, possibilità di identificare e formare gruppi all’interno della comunità (gilde, luoghi di ritrovo, canali di conversazione, lista degli amici, squadre esplicite, identità visibili/avatar). Possibili problemi: distrazione, problemi di privacy e di sicurezza.
      12. [DPBG03] imparare guardando (learning by watching – alcuni programmi consentono di guardare le partite di altri giocatori; così facendo si impara prima). Es. esplicitare anche i comandi impartiti da teastiera. Problemi: privacy, visibilità.
      13. [DPBG03] ampia personalizzabilità dell’interfaccia. malleabilità (nel layout di interfaccia, nella mappatura delle funzioni sui controlli), estensibilità (es. macro), portabilità delle personalizzazioni.
      14. [DPBG03] interazione fluida – strategie di comunicazione che richiedano meno attenzione e meno sforzo da parte dell’utente: messaggistica tranquilla (audio, messaggi transienti, animazioni), elementi dell’interfaccia responsivi, adattamento dell’aspetto al contesto.
      15. [JuWag97] Gli adventure come metafora per il progetto di applicazioni dedicate all’apprendimento.
      16. [Cla98] Cosa sanno i progettisti di videogame che i progettisti HCI tradizionali non sanno. Dall’analisi di alcuni videogiochi, scelti in differenti categorie, si evincono alcuni ‘must’ (cose da fare e cose da evitare) per progettare un buon videogioco.
      17. [CarTho82] viene proposto un altro utilizzo della componente fantastica-emotiva, ovvero quello di “incorniciare” processi di routine in rappresentazioni più evocative e coinvolgenti, nell’intento di ridurre la noia derivante dalla routine
      18. [BruBel04] Efficace utilizzare le chat in ambienti multiutente
    7. Videogiochi applicati
      1. [Cha01] Doom come interfaccia per un tool di controllo dei processi. Altre metafore: di desktop, di ‘ps’ (process status). Metafore di interfaccia superate: chi ha mai lavorato con degli archivi organizzati a cartelle-folder? (copyright sul cestino)
      2. [RSN98] SimCity? used to teach economics (one unit of the course). Teacher has to adapt to the learner in order to reach the “serious play” condition
      3. [ChuBly99] Impiego dei MUD nell’ambiente di lavoro come collante per il lavoro di gruppo distribuito (anche remoto).
      4. [Spa04] Navigatore satellitare che diventa un videogioco.
      5. [HPS98] Instead of a (normal) serious agent, A&F are not serious and polite, and are distant from 1) the computer culture, and 2) its male dominance
      6. [...] Looking glass, nuova interfaccia tridimensionale di Sun.
  2. Conclusioni
    1. Ricapitolazione
    2. Prosecuzione del lavoro
      1. Analisi di applicazioni correnti.
        [Mie considerazioni] Microsoft Windows 95/98/XP: interfaccia videogiocosa, configurabile; menu adattivi di Office.
        [Mie considerazioni] Dai videogiochi: livelli di difficoltà crescente, interfacce adattive, più semplici per gli inesperti, più efficaci per gli esperti. Interfacce ed interazione dipendente dal contesto. Es. se si sta usando il Find di Word, allora potrebbe essere meglio utilizzare i tasti cursore per e.g. cercare il prossimo/precedente match invece che spostare il cursore; oppure se si sta eseguendo la correzione ortografica; oppure se si sta risistemando l’impaginazione; etc. 1 Applicazione delle analisi descritte sui videogiochi dei giorni nostri; intervistare gli autori di oggi 1 Caratteristiche che rendono di successo un videogioco attuale: realismo della simulazione, grafica/effetti 3D, meno risalto alla storia e all'inventiva, più esteriorità. Multi-utenza, ubiquità, Internet.
      2. Nuovi media: navigatori, televisori, telefoni, elettrodomestici, PDA; non c’è più semplicemente "il computer".
      3. Nuove interfacce di input/output; comprensione del linguaggio naturale cambierà il paradigma di comunicazione. 1 Interdisciplinarietà: lavorare insieme con psicologi per elaborare nuovi test da effettuarsi con gli utenti. 1 Grafo della bibliografia, archi distinti per riferimenti espliciti ed impliciti (es. Mal80-82 ---> CarTho82?)


Bibliografia ancora da controllare e formattare

Workshops: Reflective HCI: towards a critical technical practice, Paul Dourish, Janet Finlay, Phoebe Sengers, Peter Wright, April 2004, Extended abstracts of the 2004 conference on Human factors and computing systems, http://portal.acm.org/ft_gateway.cfm?id=986203&type=pdf&coll=Portal&dl=ACM&CFID=36037636&CFTOKEN=41320309

Critical technical practice: http://polaris.gseis.ucla.edu/pagre/che-intro.html

Why are videogames engaging? Determining what we mean by 'fun' with a Grounded The-ory approach. J. Salisbury and B. Fields. Proceedings, twelfth European Conference on Co-gnitive Ergonomics (ECCE 12), 2004.

Fabricatore, C., Nussbaum, M., & Rosas, R. (2002). Playability in Action Videogames: A Qualitative Design Model. Human-Computer Interaction, 17, 311-368. http://www.leaonline.com/doi/pdf/10.1207/S15327051HCI1704_1;jsessionid=jUH_hTzvqxSf

Poole, S. (2000). Trigger Happy: the inner life of videogames. Fourth Estate.

http://www.cs.mdx.ac.uk/research/PhDArea/j_salisbury/publications.html

http://www.microsoft.com/playtest/publications.htm

Juul, J. (2003). The game, the player, the world: Looking for a heart of gameness. Level Up: Proce-edings of the Digital Games Research Conference. http://www.jesperjuul.dk/text/gameplayerworld/

Pagulayan, R. J., Steury, K. R., Fulton, B., & Romero, R. L (2003). Designing for fun: User-testing case studies. In M. Blythe, K. Overbeeke, A. Monk, and P. Wright, (Eds.), Funology: From Usability to Enjoyment (pp. 137-150). Kluwer Academic Publishers.

Fulton, B., & Medlock, M. (2003). Beyond Focus Groups: Getting More Useful Feedback from Consumers. Game Developer's Conference 2003 Proceedings, San Jose CA, March 2003.

Fulton, B (2002). Beyond Psychological Theory: Getting Data that Improve Games. Game Developer's Conference 2002 Proceedings, San Jose CA, March 2002. Reprinted on the front page of Gamasutra.com on 3.21.02, viewable at http://www.gamasutra.com/gdc2002/features/fulton/fulton_01.htm

Videogiochi ed usabilità: perché e come fare di più, C. Fabricatore. http://idearium.org/d/node/view/183 Multisensorialità: il pericolo dell'overload percettivo, http://idearium.org/d/node/view/243?PHPSESSID=b5f2092ee087ce25503bceda44a08eef http://www.gamasutra.com/features/20010427/hopson_01.htm, Behavioral Game Design http://www2.sfu.ca/media-lab/onlinegaming/report.htm

Per le tipologie attuali di videogioco:


Appunti

  • Pag. 57: <1961, "Mouse in the maze" sul TX-0 all'MIT
  • Pag. 58: 1962, Steve "Slug" Russell programma "Spacewar" sul PDP-1 all'MIT
  • Pag. 140: >1962, Donald Woods programma "Adventure" sul PDP-10 a Stanford (ispirato da una avventura trovata su un computer Xerox per ricerca, programmata da tale Will Crowther)
  • Pag. 144: 1970, John Conway programma "Life" (articolo di Martin Gardner su Scientific Ameri-can dell'ottobre 1970) sul PDP-6 (?); Bill Gosper lo trova a Stanford su un PDP-6 con terminale "340" e lo elabora
  • Pag. 243: 1976, Steve Dompier programma "Target" su un Sol; il primo videogioco ad andare in televisione (il programma "Tomorrow" di Tom Snyder)

Differenza tra approccio empirico (es. Malone, Neal) e sistematico (?cercare riferimenti?)


-- FabioVitali - 20 Dec 2004 -- MirkoVenturi - 13 Mar 2005
to top

I Attachment sort Action Size Date Who Comment
Bibliografia.rtf manage 98.8 K 20 Dec 2004 - 19:01 MirkoVenturi Bibliografia - versione corrente.

You are here: Tesi > ArgomentiDiTesi > UsabilitaEVideoGiochi

to top

Copyright © 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Fabio's Wiki? Send feedback