Applicazioni online, browser dedicati, in arrivo anche un telefono per l’azienda di Mountain View. Ma qual è la strada per lo sviluppo futuro di Google? Il keynote pronunciato da Adam Bosworth, vice president per l’engineering di Google, un anno fa davanti al pubblico del politecnico assume particolare interesse se rivisto alla luce delle informazioni attuali.
Tra i pionieri dell’Xml e creatore del database Microsoft Access, Bosworth ha rilanciato la strada dello sviluppo Web verso la creazione di applicazioni intelligenti e distribuite. I segreti di una progettazione software di successo, secondo Bosworth, sono da ricercare nel mondo dell’architettura: “elementi artistici e ingegneristici sono combinati in un mix perfetto, dove pratica ed estetica convivono e si completano a vicenda”. Lo sviluppo software dovrebbe basarsi sugli stessi principi: occorre riconoscere quello che suscita emozioni di gioia o disgusto insieme alla risoluzione dei problemi pratici e degli obiettivi. Il software non deve essere semplicemente “ben progettato” oppure soltanto “bello da vedere” ma entrambi gli elementi, in equilibrio. Ma come si può conciliare i due aspetti? Arte e ingegneria? Quello di cui la gente ha bisogno e quello che è possibile effettivamente?
Memoria a breve termine
Fino a pochi anni fa il software veniva costruito secondo un ciclo di sviluppo piuttosto lungo: il team di sviluppo lavorava per diversi mesi fino al rilascio della nuova versione del software. Così facendo, il tempo che intercorre tra due versioni diverse è particolarmente lungo (mesi o addirittura anni), con la conseguente perdita della memoria a breve termine, delle “prime impressioni” sul software, della reazione immediata all’interfaccia utente. Dopo mesi di utilizzo costante di un software, interviene la memoria a lungo termine: le connessioni neurali cambiano e ci abituiamo all’utilizzo di uno strumento anche se questo non è ottimale. Le nuove versioni dello stesso software non sfrutteranno appieno i feedback della memoria a breve termine semplicemente perché questi sono troppo lontani dal ciclo di sviluppo. Ma cosa accadrebbe se invece avessimo cicli di sviluppo molto più brevi, con modifiche all’interfaccia quasi immediate scaturite direttamente dall’interazione con l’utente? Se l’esperienza utente potesse entrare nel ciclo di sviluppo e i progettisti software potessero attingere direttamente a questa esperienza, il software si evolverebbe molto più velocemente.
Dare agli utilizzatori gli strumenti per migliorare a proprio uso e consumo l’interfaccia del software, e dare agli sviluppatori i feedback su questa attività, consentirebbe di raccolgiere molto velocemente informazioni sulla memoria a breve termine e sull’efficacia dell’applicazione, con il rilascio di nuove versioni molto ravvicinate (anche dieci in un anno) a differenza di quanto avviene per lo sviluppo tradizionale.
Tempi di latenza
Un aspetto molto importante, sul web, è il tempo di latenza. Il ritardo di un’applicazione online ha effetti direttamente sull’apprendimento: il tempo tra lo stimolo e la risposta, infatti, è proprio quello che ci permette di imparare. Applicazioni con tempi di risposta troppo lunghi verrebbero subito abbandonate, motivo per cui in Google sono stati posti obiettivi molto chiari per mantenere i tempi di latenza tra i 300 e i 3000ms (millesecondi, ndr). Una pagina che richiede troppe chiamate a un database è una pagina mal progettata. Un sito di successo deve essere anche in grado di crescere e assorbire milioni di nuovi utenti in pochi giorni, come è accaduto per esempio a Facebook.
È vero che oggi la banda larga ha risolto molti problemi di velocità, ma è anche vero che la maggior parte delle pagine Web ormai danno per scontata la banda larga e sono estremamente pesanti da visitare per chi possiede ancora una connessione lenta.
Navigare sul Web con il telefono è un’esperienza terribile. I tempi di risposta troppo elevati e il design delle pagine non progettate per essere visualizzate su uno schermo così piccolo sono i due problemi principali. Se consideriamo però quanto siano utilizzati i telefoni cellulari in Italia (molto più del computer) si comprende quanto sia importante accedere a questa base utenti. Se consideriamo inoltre che i telefonini di oggi hanno una capacità di elaborazione e una memoria molto più elevata dei Pc di alcuni anni fa, la pessima esperienza utente appare ancora meno giustificabile. Occorrono pagine semplici, pochissimi elementi, che si scarichino in poco tempo.
Usabilità e funzionalità
È meglio un’interfaccia utente semplice e pulita come Google o ricca di comandi e menu come Microsoft Access? La risposta è: dipende. Dipende ancora una volta dalla memoria umana. Se l’applicazione è di uso quotidiano e continuo, il suo funzionamento si imprime nella memoria a lungo termine. Il funzionamento diventa semplice perché ci ricordiamo la posizione di menu e comandi, perché sappiamo come attivare pulsanti e finestre. Tuttavia, se l’utilizzo è più sporadico, per esempio una volta alla settimana o ancora meno, l’interazione non riuscirà ad attivare la memoria a lungo termine ma solo quella a breve termine. Ogni volta che useremo l’applicazione incontreremo gli stessi problemi della prima volta: capirne il funzionamento e trovare le funzioni all’interno dell’interfaccia. In questo caso, più l’interfaccia è semplice e meglio è.
Quando Amazon ha cambiato la propria interfaccia ed è diventata più complicata, il pubblico ha cominciato ad andare su Google a cercare il libro a cui era interessata, per poi tornare su Amazon per acquistarlo.
Interfaccia, prestazioni, apprendimento
Le tre direzioni principali che sta prendendo lo sviluppo futuro di Google sono: mantenere una interfaccia utente semplice; preoccuparsi sempre della velocità e delle prestazioni; costruire sistemi che imparano dagli utenti.
La fisica è cambiata; oggi possiamo avere comunicazione real time sul web (chat, video) grazie alla banda larga e alla potenza di elaborazione. Ma c’è una cattiva notizia: improvvisamente saremo sommersi da un flusso gigantesco di informazioni, molto più grande di quelle che saremo in grado di gestire manualmente. Non tutti siamo bravi nel multitasking: quando cerchiamo di maneggiare tonnellate di informazioni e di stimoli simultanei potremmo trovarci in difficoltà. Troppe interazioni simultanee sono problematiche. Abbiamo bisogno di applicazioni che scelgano per noi. Abbiamo bisogno di filtri. Non solo una scelta automatica (algoritmica) ma creata dalla rete sociale: si possono sfruttare gli strumenti di social networking per filtrare selettivamente l’attenzione e decidere che cosa vale la pena seguire. Se la propria rete sociale reputa un’informazione interessante, allora molto probabilmente sarà interessante anche per noi, e viceversa. Ogni web application deve interagire con la rete sociale e diventare brava a selezionare quello che merita attenzione e quello che invece può essere filtrato.
Google Gears è la piattaforma di sviluppo su cui costruire questa innovazione. Funziona come plugin per il browser e mette a disposizione due database locali (local store): uno per le immagini e uno per i dati. Le informazioni vengono messe in coda e sincronizzate nel momento in cui la connessione è disponibile: in questo modo si riduce la latenza. La connessione avviene in background e intanto l’utente può fare altre operazioni: non deve aspettare. Pensiamo per esempio all’invio di informazioni di un modulo: questa comunicazione può avvenire in background mentre eseguiamo altre operazioni, nonsiamo costretti ad aspettare sempre la risposta del server. Meno interazioni utente-web e più interazioni con la macchina locale per avere una migliore efficienza dell’applicazione.
All’interno di questa piattaforma occorre poi costruire applicazioni che imparano dall’utilizzo e si modificano. A chi si chiede se questo non possa essere frustrante per l’utente, che abituato a una interfaccia di un certo tipo se la trova poi modificata in base al suo utilizzo (come in Office 2003), la risposta sta ancora nella memoria a breve e lungo termine. Nel caso di applicazioni di utilizzo quotidiano, il rischio esiste. In questo caso l’uso dell’applicazione assomiglia a un videogame: quasi i comandi sono inconsapevoli quando ci abituiamo alla posizione. Se invece l’uso è poco frequente questi cambiamenti sono positivi. Inoltre si può misurare l’efficacia sul comportamento dell’utente (più o meno tempo per accedere alla funzione).
Dobbiamo trovare il modo di costruire software in grado di modificarsi. In Gmail per molto tempo non esisteva un pulsante per cancellare le mail. Erroneamente, in Google, si riteneva che gli utenti non avessero bisogno di cancellare nulla una volta che gli si fosse fornito spazio sufficiente (2 Giga) per memorizzare tutte le informazioni. Sbagliato: le persone hanno molte buone ragioni per cancellare la mail. Il percorso per cancellare le email in realtà esisteva, ma era molto complicato. Un sistema in grado di imparare avrebbe dovuto accorgersi che molti utenti andavano a cercare questo comando nascosto e, dopo poco tempo, avrebbe dovuto mostrare un nuovo pulsante: Cancella.
Nei prossimi dieci anni assisteremo a grandi cambiamenti finalizzati a riflettere sulla comunicazione real time, le social network e l’attenzione selettiva. Scoprire come costruire un’applicazione che capisce cosa vogliono gli utenti e si adatta, cambia la sua forma, è l’obiettivo per il futuro.
