blog: C’è vita nell’experience design

In occasione di scelte o eventi di una certa importanza, è normale fare il punto della situazione: che sia la notte di San Silvestro, piuttosto che il proprio compleanno o il cambiare lavoro, si cerca di capire dove si è arrivati, dove si sta andando, e se ha senso ciò che si è fatto.

Quando un annetto fa i binari della vita mi condussero in Svizzera, ero curioso e un po’ impaurito; fondamentalmente non avevo la minima idea di cosa avrei trovato in un ufficio come Sketchin.

Ora che sono in procinto di salire sul treno del rientro, so cosa ho trovato in Sketchin, ed è qualcosa dal valore inestimabile: ho trovato persone grandi, in grado di regalare emozioni enormi.

Dal punto di vista umano Sketchin mi ha dato moltissimo, e non avrò ricordo più caro di quello stupore che si prova quando ci si accorge di quanto splendide siano le sorprese che la vita ci riserva.

Il treno sta per partire, e guardando le stelle penso che sarebbe bello scoprire che andando sempre dritto tornerei esattamente qui, ad ammirare questa fantastica luna.

Alberto

Dei molti interventi seguiti al romecamp, vorrei dedicare qualche parola a quello di Antonio Lieto, dedicato al web semantico, intitolato “Intelligent Search e motori di ricerca inferenziali”.

Se attualmente i motori di ricerca (o meglio, il motore di ricerca) utilizzano quasi esclusivamente aspetti lessicali per analizzare i contenuti delle pagine web, è da anni che si attende il momento in cui sarà possibile effettuare ricerche in linguaggio naturale.

Secondo gli esperti il presupposto per passare alla semantica è costituito dalla organizzazione del sapere in ontologie che consentano alle macchine di catalogarlo.

La creazione e gestione delle ontologie ha però alcuni problemi, che hanno limitato di molto il loro utilizzo:

• Vanno create a mano
• Esistono ontologie diverse per il medesimo argomento
• Non risolvono il problema delle ambiguità

Quello che di fatto è successo, è che se da un lato gli esperti spingevano verso la creazione di sempre più sofisticate ontologie, il web ha trovato la sua strada, catalogando il sapere mediante l’uso dei tag.

Quale delle due soluzioni sia la migliore, sarà il tempo a dircelo, ma non mi stupirei più di tanto se stesse proprio a metà strada tra lo schieramento dell’ontologia e quello dalla folksonomia.

Di seguito riporto il link per rivedere l’intervento e il dibattito che ne è seguito.

http://romecamp.ilcannocchiale.tv/video/5905

E’ difficile immaginare Aristotele mentre cerca difetti nel software.

Eppure i suoi lontani sillogismi sono alla base di quella branca della logica che si occupa di verificare la correttezza del software, dove per correttezza non si intende il banale test finalizzato alla ricerca di difetti, ma la sicurezza assoluta che una applicazione funzioni come previsto.

Tradizionalmente, la correttezza formale del software è un requisito che viene considerato solo in ambiti molto specifici (militare, aero-spaziale, sistemi di controllo e sicurezza realtime), dove il prezzo di un singolo difetto può essere molto alto.

La storia dei bug è ricca di aneddoti, e sono in molti a ricordarsi del disastroso lancio dell’Ariane 5, in cui in 37 secondi bruciarono più di 370 milioni di dollari.

Quello che succede di solito, è che il costo di una verifica formale, è così alto che si preferiscono usare tecniche di debugging basate su test. Questo non perchè le università non diano ai propri studenti basi di logica del prim’ordine, teoria dei tipi e utilizzo di dimostratori automatici, ma perchè il processo di traduzione delle istruzioni software in linguaggio logico è una operazione che richiede competenze e tempi che non rientrano nel budget a disposizione.

Esiste però un progetto finanziato dall’unione europea, che si pone come obiettivo quello di portare la correttezza formale del software nel mondo del mobile (cellulare e PDA), creando un sistema che consenta agli sviluppatori di accedere a parti di codice certificate come corrette.

Il fatto che esistano progetti di questo tipo non implica automaticamente che in futuro potremo utilizzare in mobilità applicazioni esenti da bug (molto dipende da quanti sviluppatori vi aderiranno), ma ci fa comprendere come l’attenzione verso il mondo mobile, negli ultimi mesi, sia sempre più elevata, e coinvolga settori, come quello della ricerca, che spesso sono accusati di andare per conto proprio, senza seguire le necessità del mercato.

Da qualche anno la potenza di calcolo disponibile sui personal computer ha permesso di portare sul web giochi ed applicazioni computazionalmente pesanti, senza che questo comprometta la normale fruizione di contenuti.

La grafica 3D e la fisica sono due degli ambiti che richiedono più potenza di calcolo, e l’uscita dal flash player 10, prima versione in grado di sfruttare la GPU per elaborare dati, ci fa comprendere come nei prossimi mesi sia lecito aspettarsi una diffussione su larga scala di applicazioni che includano grafica 3D, calcoli fisici, ed effetti applicati in tempo reale.

Dopo il post relativo a Gravitwit, ho ricevuto alcune e-mail che mi chiedevano spiegazioni sul motore fisico dell’applicazione; scrivo questo post per elencare gli indirizzi di alcuni dei motori fisici 2D esistenti per Flash/Flex (insomma, per ActionScript 3), sperando di fare cosa gradita a chiunque sia interessato all’argomento.

BOX2D - http://box2dflash.sourceforge.net/

Porting in AS3 di un motore fisico originariamente scritto in C/C++. Sul sito sono presenti alcuni esempi, le API, e un forum di supporto. Licenza zlib/libpng.

MOTOR - http://lab.polygonal.de/motor_physics/

Interessante evoluzione di Box2D da parte dei ragazzi di Polygonal. Licenza BSD.

APE - http://www.cove.org/ape/

Motore fisico creato da Alec Cove; purtroppo lo sviluppo è fermo da tempo.

FISIXENGINE - http://www.fisixengine.com/

Motore fisico 2D, licenza commerciale

Non c’è spettacolo più emozionante che vedere un infante alla scoperta della fisicità del mondo che lo circonda: la prima volta che il bambino tocca qualcosa e si accorge che questa, quasi per magia, reagisce alla sua azione, apprende una nozione fondamentale per la sua esistenza.

Ammetto di non potermi proprio definire un utilizzatore compulsivo di twitter, ma recentemente ho assistito a situazioni limite (twitter come unico strumento di comunicazione) che mi hanno fatto rivalutare l’utilità del servizio.

Sia ben chiaro: non ho iniziato a twittare.

Ma ho iniziato a seguire le twittate di altre persone.

Accorgendomi che twitter, via web, è tremendamente statico, fermo, immobile!

Così, spinto da puro spirito ludico, ho cercato di immaginare come rendere le cose un po’ più movimentate: se solo fosse possibile toccare le twittate, lanciarle nel cielo, e osservare con sorpresa ciò che accade, quel bambino che anni fa si meravigliava della fisicità delle cose, oggi probabilmente sorriderebbe.

GraviTwit.com/sketchine (prima le signore)

GraviTwit.com/sketchin

GraviTwit utilizza le API di twitter, quelle di Flickr, ed è programmato in Actionscript 3 / Php 5. E’ stato creato e messo online dopo una decina di ore di intenso sviluppo: i bug ci sono, ma fanno parte dello spirito giocoso del progetto.

Ieri, al CTIA Wireless IT & Entertainment di San Francisco, NeuroSky ha presentato un prototipo in grado di usare le onde cerebrali per controllare alcune applicazioni per cellulare.

Al di là della curiosità verso applicazioni che si interfacciano più o meno direttamente al cervello scavalcando il corpo, la presentazione di questo sistema è stata il trampolino di lancio per riflettere su come potrebbero evolversi le interfaccie utente di un ipotetico futuro.

Se già oggi è possibile acquistare in licenza l’apparato di NeuroSky, che - semplificando - non fa altro che processare dati inviati da alcuni sensori, un domani tale sistema potrebbe essere adeguatamente completato con ciò che più gli manca: il feedback.

Abituati come siamo alle attuali interfacce grafiche, immaginare un sistema controllato mentalmente, che generi “sensazioni” (o cosa?) come feedback, è un bell’esercizio: in uno scenario futuribile in cui i computer inviano e ricevono segnali dal cervello, quale ruolo potrebbero ricoprire le interfacce?

Sebbene in Sketchin mi occupi prevalentemente di sviluppare prototipi, mi hanno sempre affascinato le ricerche sui sensi e sulla percezione.

Gli studi sull’interazione uomo-macchina hanno migliorato l’interfaccia degli oggetti e delle macchine che usiamo. Quando però si affida alle macchine il compito di simulare l’apparenza dell’essere umano, e si mostra ad un uomo il risultato, in una frazione di secondo l’uomo saprà discernere se si trova davanti ad un suo simile o ad una macchina.

Non sto parlando del test di Turing, nè della stanza cinese: sto parlando della capacità di percepire la natura “vivo” o “non vivo” di ciò che ci sta vicino, alla base del senso di disorientamento e meraviglia che si prova quando si è di fronte ad una statua vivente.

La percezione del vivo/non vivo è massima nel caso di automi fisici, ma vale anche per automi digitali.

La teoria dell’uncanny valley tenta di spiegare quel che accade: man mano che la verosimiglianza dell’essere che osserviamo cresce, il senso di familiarità aumenta. C’è però un brusco calo del senso di familarità in prossimità della massima verosimiglianza, che crea nell’osservatore quel senso di repulsione alla base dello scarso successo di alcune pellicole cinematografiche realizzate in grafica 3D.

La strada da intraprendere quando si sceglie di rappresentare un essere animato è quindi divisa in due: o si punta all’iperrealismo (percorso scelto degli studios cinematografici e da alcuni videogames), tentando di superare l’uncanny valley, oppure si sceglie di abbandonare il realismo per restare al sicuro al di quà della valle (wii).

Gli esempi di rappresentazioni con chiari problemi derivanti dalla mancata considerazione del fenomeno dell’uncanny valley sono molti, e Youtube può essere un’ottimo punto di partenza.

Spesso capita di dover rappresentare informazioni in forma grafica, per riuscire ad evidenziare correlazioni che in formato testuale o tabellare risulterebbero illegibili.

Parlando di information visualization e web, utilizzare Adobe Flash è quasi un obbligo, tuttavia ci tengo a non commettere la leggerezza di considerare Flash come l’unico strumento per fare infovis.

Per semplificare la vita a coloro che prima o poi si troveranno di fronte al problema di dover visualizzare informazioni in forma grafica, ho deciso di dedicare questo post ad un veloce elenco delle librerie dedicate allo sviluppo di grafici in flash.

XML/SWF Charts 4.7
Libreria che offre 20 tipologie di grafici, che usano come fonte di dati file xml. Demo gallery. Prezzo: free.

Open Flash Chart
16 tipologie di grafici, che usano come fonte di dati file di testo. Prezzo: free.

AmCharts
Diverse tipologie di grafici; dati prelevati in file di testo / xml. Prezzo: a partire da 85 €

Yahoo! UI Library: Charts
Libreria sperimentale di Yahoo. Diverse tipologie di grafici. Buona documentazione. Prezzo: free.

PHP/SWF Charts
Libreria che genera grafici swf via php. Interessanti alcune visualizzazioni 3D, migliorabile l’interazione. Demo Gallery. Prezzo: free.

Come per tutte le librerie, la bontà dei singoli componenti stà sia nella facilità con cui è possibile usarli la prima volta, sia nella possibilità di customizzarli per le proprie esigenze. Le librerie che ho citato non coprono l’intero spettro delle rappresentazioni esistenti e spesso dimostrano il proprio limite nelle possibilità di interazione, tuttavia possono rappresentare un buon punto di partenza.

Ieri Google ha lanciato Lively, un sistema di chat room 3D accessibile a chiunque possieda un account Google. L’unione delle parole avatar, chat e 3D fa pensare automaticamente ad una cosa: se Big G si mette contro Linden Lab, sarà la fine di Second Life.

Essendo una persona curiosa, ho subito provato ad usare Lively, rimanendo sorpreso da alcuni suoi aspetti e deluso da altri.

Lively nasce come plug-in per il browser: si scarica in un poco tempo ed è pronto per l’uso. E’ semplice da usare: in due minuti è possibile creare il proprio avatar, la propria stanza, ed inserirla nel proprio sito con la stessa facilità con cui si embedda un video di Youtube. E’ quasi lecito dimenticarsi che si sta usando un plug-in: il legame con il web (questa è la novità di Lively) è così stretto che sembra di usare una normale webapp.

Tanta semplicità ha come contro alcuni limiti in termini di funzionamento: lively (attualmente) non è scriptabile e non ha una moneta. Il plug-in è inoltre disponibile solo per utenti windows (niente mac nè linux).

Ma come sono i primi minuti d’uso di Lively?

La mia personale impressione, in termini di abbattimento delle barriere d’ingresso, è stata positiva: big G ha fatto un ottimo lavoro.

Quello che mi è mancato, tralasciando i tecnicismi, è la continuità del territorio. In Second Life le isole formavano arcipelaghi, e gli arcipelaghi un mondo esplorabile in lungo e in largo: volando tra un’isola e l’altra al crepuscolo era talvolta possibile entrare in una dimensione quasi poetica.

Lively invece è costituito da stanze chiuse, che cercano di fingere in modo ancora troppo grezzo di non avere limiti.

Si badi bene: il motivo di questa mancanza non è da imputare a Lively, che non ha alcun territorio (forse è il web il suo territorio), ma alla mia attesa di trovarmi di fronte a qualcosa di simile a Second Life.

Ho un paio di spunti di riflessione da sottoporvi:

• Che influenza prevedete che avrà la non continuità del territorio nello sviluppo di reti sociali in Lively? Il mondo reale ci costringe in ambienti fortamente limitati: vuoi vedere che il problema di Second Life era la dimensione poetica? ;-)
• Riuscirà un servizio come Lively a prendere il posto di Second Life, pur essendo diverso da Second Life?

Che ci si accorga delle cose quando queste vengono meno, è cosa nota. Quando però uno strumento, che per sua natura dovrebbe essere trasparente all’utente, subisce cambiamenti che lo rendono inusabile, il senso di mancanza è spesso accompagnato - quando non sopraffatto - da pura frustazione.

Qualche mese fa, dopo un weekend trascorso con amici, sono rientrato a casa trovando di fronte ai miei occhi una sorpresa: il vecchio citofono non c’era più.

Al suo posto si ergeva un mastodontico ed ipertecnologico esemplare dotato di display lcd, tastierino numerico e videocamera. WOW!

Premetto che abito in un condominio i cui sedici appartamenti sono organizzati su due scale: per entrare in un appartamento bisogna quindi aprire prima il portone del condominio e successivamente quello della propria scala.

Non sono contrario al progresso, e pensando a quante applicazioni si posson realizzare con una videocamera, avevo accolto con notevole interesse la novità.

Almeno fino a quando non ci ho dovuto avere a che fare.

Con il vecchio citofono, per raggiungere casa bisognava seguire quattro immediati passi:

1. Cercare tra 16 cognomi quello dell’inquilino a cui citofonare
2. Premere il pulsante più vicino al cognone fino a percepire un click (1 pulsante per funzione, mi sovvengon gli esempi del buon vecchio Norman)
3. Aprire la porta del condominio
4. Aprire la porta della scala

Con il nuovo citofono, raggiungere casa diventa una sfida, e i passi da seguire son parecchi:

1. Leggere le istruzioni (scritte sia sull’lcd che su un foglietto di carta: melius abundare…)
2. Cercare tra 16 cognomi quello dell’inquilino a cui citofonare
3. Leggere il codice numerico di 4 cifre (da quando servon 4 cifre per rappresentare 16 numeri?) corrispondenti al nome dell’inquilino
4. Digitare il codice numerico su tastierino controllando sul display la corretta digitazione (nota: i pulsanti non hanno alcun feedback di fine corsa)
5. Premere il pulsante raffigurante la campanella
6. Aprire la porta del condominio
7. Cercare tra 8 cognomi quello dell’inquilino a cui citofonare
8. Leggere il codice numerico di 4 cifre corrispondenti al nome dell’inquilino (4 cifre per 8 possibilità: di male in peggio)
9. Digitare il codice numerico sul tastierino
10. Premere il pulsante raffigurante la campanella
11. Attendere prego (chi è in casa non si aspetta che ricitofoniate)
12. Premere nuovamente il pulsante raffigurante la campanella
13. Aprire la porta della scala

Di regola sono una persona calma e pacata, ma questo nuovo “citofono” mi ha messo a dura prova, riuscendo a rendere odioso un momento dolce e delicato come dovrebbe essere quello del rientro nella propria abitazione.

La prima volta che l’ho usato senza sapere come funzionava, sono arrivato al punto 9 con la voglia di premere il pulsante con la campanella fino a sfondarlo (magari così un feedback ci sarebbe stato). La seconda volta.. non c’è ancora stata: ho abbandonato l’uso del citofono.