Facciamo così … Non dico neanche niente. Non commento quanto io sia in ritardo nello svolgere i compiti di questo MOOC. Basta guardare il mio resoconto della scorsa settimana per capire il mio imbarazzo. O anche quello della settimana prima. O di quella prima ancora.
Diciamo che sto facendo del mio meglio e che a quanto pare il mio meglio non è sufficiente a tenere il passo con i ritmi di questo corso online. Ancora una volta, sottolineo come la mancanza di compagni con cui affrontare l’avventura faccia calare drasticamente la motivazione. Nonostante questo, so che dovrei comunque sforzarmi di essere più disciplinata e regolare. E chi lo sapeva che settembre mi avrebbe colpito in faccia con un calcio rotante? Adesso capisco perché i Green Day cantano “Wake me up when September ENDS”.
Nonostante le mie manchevoli manchevolezze, voglio mantenere la sana abitudine di riportare in questo blog quanto contenuto nella sezione Design/Play/Story/Code che è presente in ogni modulo del MOOC.
Questa sezione è preceduta dalla registrazione audio della conferenza virtuale che Lance Weiler tiene ogni domenica pomeriggio per fare il punto della situazione. Con orgoglio posso dire che (almeno questa) l’ho ascoltata approfittando di un lungo viaggio in treno.
Come promesso, ora passiamo alla sezione successiva.
Jorgen van der Sloot e la T di Testare
Dopo averci annunciato che il corso avrebbe seguito il processo suggerito dall’acronimo E.D.I.T. e dopo averci parlato della E di Empatia (prima settimana), della D di Definire (seconda settimana), della I di Ideare (terza settimana), è il momento di spiegare l’ultima lettera: la T che sta per Testare.
E’ il momento di creare un prototipo e di provare a farlo usare a delle persone volenterose che, alla fine dell’esperienza, ci diranno com’è andata: ci daranno un feedback. Grazie a questo, potremo migliorare sempre più il nostro progetto.
Il prototipo è stato costruito in base a una serie di predizioni che noi abbiamo fatto quando abbiamo immaginato come sarebbe stato usato. Per capire se il nostro design è corretto, l’unico modo è testare il nostro prodotto sottoponendolo all’utilizzo di persone esterne. Questo è il momento in cui si scopre se davvero le persone capiscono come utilizzarlo e ne sono soddisfatte, e quindi è questo il momento in cui si scopre se il nostro lavoro di ideazione è ben fatto.
Nick Fortugno e il processo di creazione di un prototipo (prototyping)
Dopo avere dato una rapida definizione di “prototyping” (presa da Wikipedia e la cosa un po’ mi sconcerta), Fortugno passa a discutere il primo passo del processo: se voglio testare qualcosa, significa che ho qualcosa da testare, ma calcolando che in questa fase la nostra idea è in costante evoluzione, come faccio a decidere che quello che ho prodotto è pronto a essere trasformato in prototipo e testato?
Per rispondere a questa domanda il nostro si ispira al lavoro di Chris Hecker che risponde al problema di cui sopra dicendo: “Un prototipo è una risposta a una domanda” (“A prototype is an answer to a question”) di cui non conosciamo la risposta e per cui dobbiamo “fabbricarne” una.
Fortugno continua fornendo alcuni esempi di domande che portano a un prototipo (ad esempio, “Come posso rendere rispondere al telefono un’esperienza spaventosa?”) e puntualizzando che queste domande non devono avere una risposta chiara. Proprio lì sta il bello: nelle possibilità che aprono. Il brutto è che possono risultare in una sensazione di stordimento, come stessimo giocando a freccette bendati.
Purtroppo questo è quanto accade quando non si conosce la risposta a una domanda: si tira a indovinare. Dobbiamo familiarizzare con questa sensazione se vogliamo fare dei progressi.
Allo stesso tempo, possiamo (anzi, dobbiamo) cercare di limitare la confusione il più possibile. Ecco alcune strategie per la fase di Indovinamento* (guessing):
*chiaramente questa parola non esiste, ma non mi veniva in mente una traduzione migliore in italiano
- Rispondere a una domanda alla volta. Se si testano varie domande tutte insieme, poi si perde cognizione di cosa ha funzionato e cosa no.
- Per il test è preferibile produrre la cosa più veloce e meno costosa possibile. Stiamo investigando una domanda specifica e dobbiamo trovare il modo più semplice per ottenere la nostra risposta. In questa fase non ci interessa che il prodotto sia bello, artistico, eccetera eccetera. Ci interessa solo la risposta alla nostra domanda.
- Non pensarci troppo – Quasi sicuramente il primo tentativo andrà male! E questa è una cosa positiva. Se il prototipo è un fallimento, questo ci fornisce informazioni su cosa NON è, di conseguenza su come renderlo migliore. Bisogna fallire molte volte nel minor tempo possibile.
Fatto questo, passiamo alla fase di revisione dei prototipi (reviewing prototypes) le cui fasi prevedono di:
- Analizzare i risultati, con brutale onestà.
- Chiedersi: Abbiamo ottenuto la risposta che volevamo? Sì? No? Se sì, abbiamo altre domande? Se no, come posso rispondere in modo diverso? Come possiamo riformulare la domanda e la risposta?
- Creare un nuovo prototipo, seguendo gli stessi passi di prima ma concentrandosi sul nuovo problema.
- Ripetere tutte le volte che serve, fino a che tutte le domande hanno trovato risposta.
Questo è come funziona il processo di prototyping per prodotti interattivi:
Si definisce un obbiettivo di tipo formale (aesthetic goal) e poi si inizia a costruire (build), testare (test) e valutare (evaluate) e di nuovo costruire, testare, valutare e di nuovo … Fino a che non si ottiene qualcosa che fa pensare “Sì! Questa cosa funzionerà! L’ho testata abbastanza e mi dà i risultati che volevo”. A questo punto, si passa allo sviluppo (development) completo del prodotto.
Questo è il processo che ci porta dall’idea alla concretizzazione fisica dell’idea. Bisogna ricordare, però, che nulla di questo funziona se quell’idea non viene finalizzata seguendo dei principi precisi (analizzati abbondantemente nelle scorse settimane) che permettono di renderla compatta e coerente.
Lance Weiler parla di come il processo di prototyping si interseca alla narrazione interattiva
Lance Weiler si dice affascinato da quello che chiama 21st century rewrite, ovvero riscrittura del 21esimo secolo: la commistione di narrativa e codice di programmazione che apre la possibilità di creare storie che si adattano al fruitore, e lavorano con l’estetica, con le emozioni, per trovare nuovi modi di raccontare.
Lui e gli altri organizzatori di Sherlock & IoT sapevano che all’interno del Lincoln Center sono distribuiti vari beacons e volevano utilizzarli per l’esperimento. Il loro primo tentativo di oggetto narrativo e interattivo era stato un telefono a rotella, che rappresentava Scotland Yard. Questo telefono è stato collegato ai beacons e poteva comunicare con loro. Inoltre, grazie al Raspberry Pi al suo interno, poteva connettersi con la Cloud e disponeva di un software di riconoscimento e interpretazione vocale.
Nei mesi successivi, Weiler e compagni hanno continuato a lavorare su questo oggetto, aggiungendovi il software Watson creato da IBM. Questo ha permesso non solo di incrociare e utilizzare dati relativi a tutte le storie di Sherlock Holmes, ma anche di registrare e elaborare le interazioni dei giocatori con l’oggetto per renderlo sempre più “intelligente”.
L’idea è di rendere il telefono una sorta di filo d’Arianna che guida il giocatore nell’esperienza. Il telefono viene affidato al giocatore da un attore, che finge di essere un investigatore che è stanco di collaborare con Scotland Yard e che non ne condivide i metodi. L’attore consegna un pacco nelle mani del giocatore e se ne va. Nel pacco il giocatore trova il telefono.
Il giocatore viene messo di fronte alla scena del crimine e capisce di doverla risolvere. Quando avrà creato una storia plausibile, alzerà la cornetta e telefonerà a Scotland Yard. Dall’altra parte ci sarà Watson (il programma IBM, non l’ometto baffuto) che analizzerà la storia e la confronterà con tutte le storie su Sherlock Holmes. Fatto questo, produrrà un documento scritto in cui dirà al giocatore a quale storia di Conan Doyle assomiglia di più quella che ha prodotto.
(Non capisco bene lo scopo di tutto ciò. Mi sembra che non aggiunga niente alla narrazione. Forse ho capito male? :/ )
Weiler spiega che questo confronto dovrebbe ricordare al giocatore il mondo letterario che fa da cornice al progetto e alimentare la sua immaginazione.
(Non mi ha convinto. Rimango dell’idea che il problema potrebbe essere mio e della mia mancata comprensione visto che sono seduta di fronte al computer da dieci ore.)
Un altro esempio di prototipo fisico interessante è la macchina obliteratrice creata durante l’evento di Torino (organizzato da Sabrina Giacardi e Valentina Maffucci che ho conosciuto a Venezia qualche settimana fa).
Una delle cose importanti per Weiler e gli altri creatori del progetto Sherlock, era che i partecipanti si sentissero incoraggiati a fare fork, ovvero a creare versioni alternative dei prototipi o del progetto stesso, adattandole alle proprie necessità o inclinazioni. Questo è successo.
Weiler fa l’esempio di tre forkings: Solve LA, un programma in una scuola superiore che mischia ragionamento deduttivo e narrazione con i processi di ragionamento specifici del design, il tutto per incoraggiare l’innovazione sociale nella città di Los Angeles; Sherlock Youth Workshop, un laboratorio che insegna competenze digitali a studenti fra i 12 e i 18 anni in Belgio; Sherlock Escape Room, un progetto in cui studenti delle elementari e delle medie progettano e creano una escape room che verrà poi aperta al pubblico.
Oltre a questi, Weiler menziona anche un progetto per i sordi e uno per l’agricoltura che si sta sviluppando in California, in cui la storia di come il cibo viene prodotto viene esplorata attraverso indagini di tipo giallistico e narrata usando vari strumenti fra cui la Realtà Aumentata.
Tornando al progetto Sherlock Holmes and the Internet of Things, Weiler sottolinea ancora una volta come uno degli obbiettivi principali sia quello di creare uno spazio collaborativo in cui esplorare modi nuovi di raccontare storie (“explore what stories can be”). Siamo abituati a una gerarchia in cui le storie ci arrivano dall’alto: dalla letteratura, dal cinema, dall’industria dell’intrattenimento in generale. La cultura orale è (quasi totalmente) scomparsa e le storie che la costituivano sono finite in un grande calderone in cui non si riconosce più un rapporto di appartenenza. Spesso c’è chi se ne è appropriato e, invece di incoraggiare la creatività, la punisce, come nel caso della fan fiction osteggiata dalle grandi case di produzione.
In questa cornice, l’idea di poter prendere un prodotto letterario come Sherlock Holmes e farne il materiale di scambio di una piattaforma collaborativa è emozionante.
Rivedere la nostra nozione di narrazione offre nuove possibilità di ricerca e può offrire nuove risposte alle nostre domande su come utilizzare le storie per rendere la nostra società migliore.
Segue, come sempre, una playlist bonus, questa volta contenente vari esempi di esperienze immersive in cui storia e gioco si intersecano. Poi, per la sezione su Sherlock Holmes viene proposto un video in cui viene spiegata l’influenza del personaggio nella cultura popolare. A seguire, una sezione nuova dedicata agli “oggetti incantati” in cui si parla degli oggetti realmente esistenti all’epoca che il personaggio Sherlock avrebbe usato nelle sue indagini e di come l’Internet of Things creerà la magia nelle nostre vite.
Infine, il solito tasto dolente: la sfida. Durante la seconda settimana avrei dovuto fare la Appreciative Enquiry (discutere con un’altra persona un momento “incantato” della mia vita e cosa lo rendeva tale) e trarne dei design principles. Se avessi fatto questo, ora potrei registrarmi sulla piattaforma Doable, che loro hanno ribattezzato Scotland Yard, e iniziare il brainstorming con gli altri. La cosa funziona così: ogni partecipante carica la propria idea e gli altri utenti sono invitati a commentare cinque idee altrui con tre domande ciascuna, sempre partendo con la frase “Yes, and …” (come spiegato da van der Sloot la scorsa settimana). Questo compito era da completare entro il 19 settembre per trarne qualcosa di davvero utile. Potrei anche farlo adesso, ma gli altri partecipanti nel frattempo sono andati avanti.
Mi sa che devo rassegnarmi all’idea che sperimenterò questo MOOC più come osservatrice esterna che come vera e propria partecipante. E vabbè. E’ andata così. C’è comunque tanto da imparare …
