Il protagonista – Tom Cruise – cammina in un centro commerciale dove, grazie ad un sistema di scansione della retina, viene identificato da cartelloni pubblicitari “intelligenti” che gli propongono pubblicità personalizzate, chiamandolo anche per nome. Fantascienza? Non proprio…

Annunci proposti da Gmail mentre leggevo una newsletter sullo sviluppo Javascript. Personalizzati in base al contenuto della mail e al mio profilo.

Su Gmail riceviamo continuamente piccoli annunci pubblicitari: se facciamo attenzione, noteremo che quasi sempre questi annunci non sono casuali, ma sono attinenti al contenuto della mail che stiamo leggendo. Google – con la piattaforma AdWords – propone inserzioni personalizzate in base al contenuto che stiamo leggendo (riceviamo una mail di un nostro amico che ci propone un viaggio a Madrid? Ecco che arriva la pubblicità per un hotel in città a prezzo scontato!) e anche in base al nostro profilo che l’azienda di Mountain View traccia continuamente.

Cosa c’é di diverso dalla scena del film? Gli scanner della retina non sono ancora stati installati nei centri commerciali, ma la tecnologia oggi a disposizione é tuttavia più che sufficiente perché uno scenario del genere non sia solo plausibile, ma anche realizzabile. Ed é quello che sta accadendo sul web già adesso, dove non serve nessuna scansione dell’occhio per identificarci. I futurologi che Spielberg aveva consultato per la realizzazione del film sapevano bene a cosa andavamo incontro: la personalizzazione delle informazioni. Sul web possiamo andare oltre e parlare di personalizzazione della user experience.

Tentare di adattare l’esperienza dell’utente non è nulla di particolarmente innovativo (i sistemi adattativi esistono dall’inizio degli anni ’90), ma le tecnologie a disposizione oggi e, soprattutto, i dati che ci riguardano reperibili in rete non sono mai stati cosi ricchi ed accessibili.

Un esempio banale? Ogni volta che accediamo ad Amazon con il nostro account, il sistema di raccomandazione del sito ci propone dei prodotti che “pensa” ci possano interessare. Come fa? Provate a pensare al sistema di raccomandazione come ad un negoziante di fiducia che conosce le nostre abitudini d’acquisto, cosa  abbiamo già comprato, i nostri interessi, la nostra propensione a spendere, ecc. Tutte queste cose – vi chiederete –  come le può sapere?

Il flusso incessante di informazioni che ci riguardano sul web (ció che diciamo di noi sui social network, i nostri acquisti online, le  ricerche fatte su Google, i checkin su Foursquare, ecc) va a comporre un puzzle che rappresenta la nostra personalità online. Il compito dei sistemi adattativi é ricomporre questo puzzle partendo dai singoli pezzi che hanno a disposizione, privacy permettendo. Per sintetizzare:

Per web personalizzato o adattativo intendiamo la capacità di siti o applicazioni di adattare  la User Experience (contenuti, interfaccia, grafica, navigazione, ecc)  in base a fattori come il profilo utente, il contesto, le interazioni sociali, il device utilizzato, ecc.

Come avviene questo processo? E soprattutto, a partire da quali informazioni? Il punto di partenza è solitamente il profilo utente: vedremo tuttavia, senza entrare in dettagli tecnici, che ci sono altri fattori da tenere in considerazione.

1. Profilo utente

La maggior parte dei sistemi adattativi usa questo tipo di dati per proporre contenuti personalizzati. Informazioni semplici come fascia demografica, sesso, occupazione e interessi personali, ma anche più complesse e dettagliate, come un film che ci è piaciuto particolarmente o un luogo che abbiamo visitato e ci ha colpiti. Da dove provengono questi dati? Il metodo più semplice consiste nel proporre questionari da compilare all’utente. Tuttavia, nessuno ha voglia di compilare lunghi e noiosi questionari. I designer si sono quindi ingegnati per trovare soluzioni creative alternative per ottenere le stesse informazioni, in modo più diretto e coinvolgente.

Tripadvisor chiede ai propri iscritti di compilare una mappa con i luoghi visitati, preferiti e quelli che ci piacerebbe visitare. Ci invoglia a compilarla mostrando quella dei nostri amici (estratti da Facebook). Un metodo alternativo ad una scomoda form per ottenere informazioni preziose da utilizzare per la personalizzazione

La maggior parte delle volte, invece, questi dati vengono dedotti in modo “implicito“. Clicchiamo “mi piace” o “+1” su una pagina? Stiamo insegnando al sistema (sia esso Google, Facebook o quant’altro) qualcosa sui nostri interessi personali.

Nemmeno i risultati dei motori di ricerca sono esenti dalla personalizzazione. Google traccia il nostro profilo (sia che siamo loggati o meno) e usa fino a  57 indicatori diversi (ricerche precedenti, device, luogo, +1, ecc) per personalizzare il ranking dei risultati. Google non è più uguale per tutti.

Molti siti ci consentono di registrarci connettendo i nostri account sui social network (Facebook, Twitter e, molto presto, Google+). Quando scegliamo questa modalità, non stiamo solo evitando una noiosa form di registrazione, ma stiamo anche fornendo al sito – la maggior parte delle volte – accesso ai nostri dati personali, che verranno estratti dal nostro profilo e usati per personalizzare la User Experience. Abbiamo indicato i nostri film preferiti nei nostri interessi di Facebook? Bene, un sito come Netflix (servizio per la visione di film in streaming che attualmente possiede uno dei migliori sistemi di raccomandazione esistenti) usa anche questi dati per proporci i film di nostro gradimento.

Netflix propone delle raccomandazioni in base ai film che abbiamo visto in precedenza, ai voti che gli abbiamo assegnato e al nostro rating dei generi. Usa anche i nostri dati estratti da Facebook (es. interessi, film visti, pagine), se forniamo l'accesso all'account

La personalizzazione sulla base delle nostre informazioni personali è probabilmente la più potente: le pubblicità più mirate ed efficaci sono quelle che si trovano su Facebook. Sembrano quasi sempre adatte a noi e quello che ci interessa. Gli algoritmi che le selezionano “leggono” i ricchi dati che ci riguardano in possesso del social network e ci riconoscono, proprio come i tabelloni pubblicitari di Minority Report.

2. Contesto d’uso

La pagina "Luoghi" di Foursquare ci propone i luoghi e gli specials più interessanti vicini alla nostra posizione

“Contesto” è una nozione dai contorni abbastanza sfumati: nel nostro caso, per semplificare un po’ le cose, possiamo considerarlo come il luogo e il periodo temporale in cui stiamo utilizzando un’applicazione. Cosa significa quindi personalizzare la nostra esperienza in base al contesto? Facciamo alcuni semplici esempi.

Foursquare ci propone luoghi interessanti e Specials (offerte speciali), calibrandoli sulla nostra posizione fisica. Nulla di particolarmente complicato, che è stato però reso possibile da un’innovazione tecnologica: il sensore GPS installato negli smartphone. Aziende come Groupon, hanno puntato tutto fin da subito sulla pubblicazione di offerte e sconti personalizzati per le varie città, in modo da fornire  al proprio utente solo le informazioni che erano veramente rilevanti per il suo contesto.

Applicazioni più sofisticate potrebbero invece pensare di fornire contenuti adattati alla fascia oraria. Immaginiamo un feed reader “intelligente”, che raccomanda contenuti differenti quando di mattina ci troviamo a lavoro (articoli legati alla nostra professione) oppure la sera o nel week-end a casa (articoli riguardanti i nostri hobby, eventi, programmi TV) proprio per fornirceli nel momento in cui è più probabile che verranno apprezzati.

3. Device

Negli ultimi anni, abbiamo assistito ad un aumento vertiginoso dei dispositivi connessi in rete: una crescita destinata a diventare ancora più veloce nel prossimo decennio. Il PC viene via via rimpiazzato da una marea di nuovi device: smartphone, cellulari, tablet, Internet-TV, ecc sono mezzi sempre più utilizzati per accedere a Internet. In più, le interfacce multi-touch hanno rivoluzionato il nostro modo di interagire con il mondo digitale, rendendolo più diretto e fisico.

E’ ormai quindi un requisito essenziale, per il progetto di un’applicazione, la capacità di adattarsi al dispositivo attraverso la quale verrà usata, alle costrizioni che introduce, alle opportunità che offre, ai differenti form factor. Non si tratta solo di applicare principi come responsive web design o pattern per la progettazione multi-touch, ma anche di capire come e perché verrà usata l’applicazione con un certo device. Ricordandoci quindi anche dell’utente che la sta utilizzando.

Proviamo a confrontare la versione desktop e quella mobile di Foursquare: le azioni a disposizione dell’utente sono completamente diverse.

• Nella versione mobile l’accento è posto sulla ricerca di luoghi (venues), in cui fare checkin, leggere e dare consigli (tips), ecc. Altre funzioni, come amici, statistiche, ecc sono solo secondarie o del tutto assenti.
• La versione desktop è molto diversa e – data la sua natura statica – la ricerca di luoghi non è nemmeno disponibile e si enfatizza la gestione della cerchia sociale (friends) e delle statistiche (badge, stats, history).

I progettisti hanno quindi capito e messo al centro della progettazione i bisogni fondamentali degli utenti dei differenti device.

Il sito di Foursquare come appare per computer standard. L'enfasi è posta sugli aspetti sociali dell'applicazione, sulle statistiche e la gestione degli amici

In Foursquare mobile (qui vediamo l'app iOS) la funzione preminente è "checkin" (assente in versione desktop). Abbiamo anche altre funzioni relative ai luoghi ("esplora", "to-do list"). La gestione degli amici e le statistiche sono invece meno evidenti.

4. Relazioni sociali

Basandosi sui dati riguardanti la nostra “rete sociale”, alcuni sistemi possono personalizzarsi in modo molto sofisticato. Il criterio più semplicistico può essere riassunto cosí:  ”quello che piace ai nostri amici è probabile che piaccia anche a noi”. Per questo le informazioni di rete sono così importanti: capire quali interazioni abbiamo e con chi, cosa piace alle persone nella nostra cerchia, quali attività svolgiamo con essi, ecc.

Un esempio di sito che usa le informazioni sociali è TripAdvisor. Una volta che decidiamo di connettere il nostro account con Facebook ci verrà chiesto l’accesso, oltre ai soliti dati personali, anche ai dati riguardanti la nostra rete sociale. Dopo questa procedura, l’homepage del sito cambia radicalmente: ci vengono proposte le attività recenti dei nostri amici (recensioni, luoghi visitati, ecc.) e le  mete più popolari nella nostra cerchia sociale. L’assunzione di base è sempre la stessa: è probabile che ciò che è popolare nella nostra rete sociale possa piacere anche a noi.

Dopo aver collegato l'account Facebook, l'home page di Tripadvisor ci mostra suggerimenti basati sulla nostra rete sociale. Mete più popolari nelle nostre cerchie, recensioni dei nostri amici e la mappa dei luoghi visitati.

L’innovazione più grande in questo ambito la sta forse introducendo Google nel suo motore di ricerca. Il recente ingresso di massa di Big G nel campo social, con il lancio del bottone +1 e di Google+ introduce questa nuova dimensione anche negli algoritmi che gestiscono posizionamenti e determinano investimenti milionari. Il motore di ricerca impara a conoscerci, a conoscere i nostri amici, dando priorità ai risultati che sono particolarmente popolari nella nostra cerchia sociale.

Conclusione

Molte delle tecnologie che rendono possibile il web personalizzato esistono sul mercato da parecchi anni. Tuttavia, ultimamente, diversi fattori hanno spinto molte aziende ad investire  in questo campo, con gli algoritmi di raccomandazione personale, le applicazioni context-aware e quelle multi-piattaforma. La grande quantità di informazioni personali che circolano oggi su Internet (fenomeno dovuto soprattutto all’adozione di massa dei Social Network), la crescente ubiquità dell’accesso alla rete, che avviene ormai con ogni dispositivo e da ogni luogo, e infine, l’enorme quantità di contenuto che circola oggi in rete e rischia di sommergere gli utenti, se non opportunamente “filtrato”.

Queste tecnologie possono migliorare realmente l”esperienza d’uso di un’applicazione, che non sarà quindi mai la stessa per due utenti diversi.

My dream search engine of the future guides me throughout the day. It knows my next meeting is downtown, but the streets are closed, so I should take the subway. It reminds me that my wife’s birthday is in two weeks, tells me she wants an iPad and suggests I talk to my friend, Matt, who has done research on its Wi-Fi capabilities. Then it sends me directions to the closest store. It could even suggest a romantic restaurant nearby, search our schedules, and book a candlelit table for two.

Amit Singhal – “The Science fiction behind search”

L’articolo sopracitato – pubblicato sul magazine online Think Quarterly –   illustra la visione di Google per quanto riguarda il web personalizzato (riferimenti riportati a fine articolo).

Non mancano – ovviamente – anche i potenziali lati negativi. Vogliamo veramente avere a che fare solo con contenuti pensati per noi? Vogliamo vivere in un mondo in cui ascoltiamo solo le voci con cui siamo d’accordo? In cui un oscuro algoritmo decide cosa fa per noi e cosa no? Un pericolo che viene descritto in “The Filter Bubble”, libro in cui la personalizzazione (dei contenuti) viene descritta come una “bolla” che intrappola la nostra vita online. Per avere un breve riassunto rimando alla sezione “Altre risorse”.

In ogni caso ci troviamo di fronte ad un futuro guidato dai dati personali. Un futuro in cui la gestione della privacy sarà sempre più importante e vitale. In cui dovremo districarci in mezzo ad una mare di informazioni e in cui avremo, inevitabilmente, bisogno di un aiuto. Un futuro in cui la nostra vita digitale si mescolerà sempre di più più più più più reale, che lo vogliamo o meno.

Altre risorse

• The science fiction behind search, Amit Singhal, “Think Quarterly”
• Quello che Internet ci nasconde, Eli Pariser per “Internazionale“
• Building a Recommendation engine, Foursquare style, “Foursquare Engineering blog”

Tuttavia, a volte il linguaggio CSS può sembrare un po’ limitato e, se non si presta abbastanza attenzione, è facile ritrovarsi con fogli di stile inzuppati di codice incomprensibile e poco gestibile. Questo problema, oltre che con un’accurata progettazione del codice, può essere affrontato con lo strumento che andrò a presentare in questo articolo: LESS.

Che cos’è?

LESS, al contrario di come può suggerire il nome, è un’estensione del codice CSS, che introduce alcune funzionalità che possono semplificare notevolmente la vita dello sviluppatore web. Il codice proprietario LESS può essere mixato a piacere con CSS standard all’interno di un foglio di stile. L’unica differenza è che il file prende l’estensione .less e deve poi essere compilato in puro CSS prima di essere utilizzato (vedremo dopo come, è molto semplice!)

Cosa introduce LESS in più rispetto ai CSS? Principalmente quattro cose: le Variabili, i Mixins, le Regole annidate e le Operazioni. Vediamo di cosa si tratta in dettaglio.

1. Variabili

Grazie alle variabili, possiamo definire in un’unica riga di codice dei valori che vengono poi usati in diversi punti del foglio di stile. Le variabili sono sempre precedute dal carattere @. Vediamo un esempio:

@brandcolor: #F39923;
....
h1, h2, #header{
      color: @brandcolor;
}
#footer{
      background: @brandcolor;
}

Qual’è l’utilità delle variabili? Permettono di mantenere il codice più pulito e facile da modificare. Supponiamo che il colore del brand aziendale venga modificato da un giorno all’altro. Cosa dovremmo fare con CSS standard? Andare a cercare il valore in ogni punto in cui è stato usato e modificarlo. Con LESS sarà sufficiente modificare la dichiarazione @brandcolor e il gioco è fatto.

2. Mixins

I mixins (contrazione di “mixing in“) sono un’estensione del concetto di variabile. Mentre con le variabili possiamo memorizzare un singolo valore CSS (un colore, una dimensione, un bordo, ecc.), grazie ai mixins possiamo dichiarare una classe CSS che contiene più proprietà e poi riutilizzarla a piacimento all’intero del foglio di stile. Vediamo come:

.light-textshadow{
       -webkit-text-shadow:0 1px 2px #888;
       -moz-text-shadow:0 1px 2px #888;
       -o-text-shadow:0 1px 2px #888;
       text-shadow:0 1px 2px #888;
}
...
h1{
      .light-textshadow;
      color: red;
}
#footer h3{
      .light-textshadow;
      color: #333;
}

Semplice no? Abbiamo applicato l’ombra agli elementi h1 e h3 senza alcuna ridondanza nel codice. I mixins sono particolarmente utili quando dobbiamo usare le nuove proprietà CSS3, che vanno scritte sempre con 4 prefissi diversi.
Meglio ancora, i mixins si possono comportare come vere e proprie funzioni, ricevendo in input dei parametri. Vediamo un esempio in cui il colore dell’ombra è personalizzabile nei vari selettori:

.light-textshadow(@shadowcolor: #888){
       -webkit-text-shadow:0 1px 2px @shadowcolor;
       -moz-text-shadow:0 1px 2px @shadowcolor;
       -o-text-shadow:0 1px 2px @shadowcolor;
       text-shadow:0 1px 2px @shadowcolor;
}
...
h1{
      .light-textshadow(#d00);
      color: red;
}
#footer h3{
      .light-textshadow;
      color: #333;
}

Nel caso dell’elemento h1, il colore dell’ombra è impostato a #d00, mentre nel secondo elemento non viene passato alcun valore al mixin, che usa il valore di default (#888) presente nella dichiarazione.

3. Regole annidate

Nei CSS per specificare regole per elementi annidati, dobbiamo spesso usare una serie di selettori che possono diventare abbastanza lunghi e ripetitivi. Ecco un tipico esempio:

#main-menu{ background:#444; }
#main-menu ul{ list-style-type:none; }
#main-menu ul li{ float:left; padding: 0.3em; }
#main-menu ul li a{ color: #44f; }

Usando le regole annidate, possiamo scrivere i selettori all’interno di altri, mostrando in modo più chiaro qual’è la struttura gerarchica degli elementi:

#main-menu{
   background: #444;
   ul{
      list-style-type:none;
      li{
         float: left;
         padding: 0.3em;
         a{
            color: #44f;
         }
      }
   }
}

4. Operazioni

In LESS possiamo eseguire semplici operazioni matematiche su tutti gli attributi di tipo numerico, cioè dimensioni, colori, variabili LESS, ecc. Questo è molto utile quando vogliamo usare valori proporzionali tra di loro, come un colore leggermente più chiaro (o scuro) di un colore base, o la dimensione di un bordo aumentata o diminuita proporzionalmente. Vediamo un esempio:

@basecolor: #c00;
@baseborder: 1px;
...
#header{
   background: @basecolor - #111;  //slightly darker color
   border:solid @baseborder white;
}
h3{
   color: @basecolor + #111;  //slightly lighter color
}
#image-box{
   border:solid @baseborder*2 @basecolor-#111;
}

Come usarlo?

Ovviamente non stiamo usando nessuna magia: il browser non è infatti in grado di interpretare i fogli di stile con estensione .less. E’ necessario convertirli in file standard .css e per questo scopo esistono numerosi metodi. Vediamo i principali:

• Ruby gem: la soluzione proposta sul sito ufficiale di LESS è scritta in Ruby, un linguaggio molto popolare nel mondo web. Sul sito sono presenti le istruzioni per installare il software e compilare i fogli di stile da LESS a CSS.
  Ad esmpio, su Mac OSX da linea di comando, per installare la “gemma” Ruby:

  $ sudo gem install less

  Poi per compilare un file da LESS a CSS. Se usiamo l’opzione –watch, il compilatore controllerà le modifiche al file LESS e lo ricompilerà automaticamente ad ogni salvataggio:

  $ lessc style.less
  $ lessc style.less --watch

• App OSX: disponibile solo per Mac OS X, una comodissima app da installare. Sostanzialmente permette di fare le stesse cose della Ruby gem, senza però chiederci di usare la linea di comando
• Javascript: una libreria Javascript che compila il file LESS on-the-fly all’interno della pagina HTML. Il file .less viene incluso direttamente nel codice come un normale foglio di stile (attenzione però ad usare rel=”stylesheet/less”). Una funzione Javascript si preoccupa quindi di trasformarlo in CSS al momento del caricamento. Questa soluzione, seppur poco indicata per siti in produzione (Javascript è relativamente lento e potrebbe essere disattivato nel browser), è invece ottima nelle fasi di sviluppo e testing, perchè non richiede la ricompilazione continua del codice.

  <link rel="stylesheet/less" href="main.less" type="text/css" />
  <script src="http://lesscss.googlecode.com/files/less-1.0.30.min.js"></script>

• Compilatori in PHP e .NET

Conclusioni

In questo articolo abbiamo visto le principali funzionalità introdotte dal linguaggio LESS per arricchire le già numerose funzionalità offerte dai fogli di stile CSS. LESS non è l’unica soluzione di questo tipo disponibile in rete, ma è probabilmente la più semplice, perché utilizza la stessa sintassi CSS: basta infatti rinominare il foglio di stile da .css a .less e avremo un foglio di stile valido.

SASS è un’altra soluzione molto popolare e ha recentemente introdotto modifiche sostanziali al linguaggio (da .sass a .scss) per allinearsi a quanto fa LESS, ovvero essere compatibile al 100% con la sintassi CSS. In precedenza SASS usava infatti una sintassi diversa, che andava ad eliminare completamente le parentesi graffe dal linguaggio.

A prescindere dalla soluzione scelta, questi tool rendono la vita dei web designer più semplice, permettendoci di scrivere codice più pulito, facile da modificare e da mantenere organizzato. Ovviamente, sono una soluzione molto conveniente solo in caso di fogli di stile di complessità medio-alta, mentre in caso di CSS molto semplici il gioco potrebbe non valere la candela.

Le possibilità aperte da un’interazione più “naturale” e semplice (NUI, Natural User Interfaces) sono innumerevoli e vanno sfruttate appieno dalle interfacce di nuova generazione (Web e non), così come è necessario tenere conto delle limitazioni che impongono al progettista. Basta pensare ad esempio a quanto è poco preciso il “tocco” delle dita su uno schermo rispetto al puntatore del mouse.

Questo articolo cercherà di proporre una serie di tecniche e linee guida necessarie per rendere la nostra interfaccia il più usabile, semplice e piacevole possibile per un uso touch, Le riassumo brevemente qui di seguito:

1. Usare interazioni naturali
2. Dimensioni adeguate degli elementi interattivi
3. Attenzione alla posizione delle mani
4. Dimenticatevi dell’hover!
5. Ottimizzare l’input testuale

1. Usare interazioni “naturali”

Uno dei grandi meriti di questa nuova generazione di interfacce sta nella capacità di rendere l’interazione il più “naturale” possibile, eliminando la mediazione di dispositivi di input non necessari (il mouse). Come? Con una serie di gestures (gesti) più o meno codificate, che permettono di manipolare gli elementi in modo semplice e immediato. L’intuitività delle interfacce multi-touch è evidente in questo video, in cui un bambino usa senza problemi un iPhone.

Quando progettiamo un’applicazione è utile quindi usare elementi interattivi che assecondino la naturalezza dell’interfaccia touch. Vediamone alcuni esempi.

No Scrollbar

Una delle cose più fastidiose delle interfacce classiche point-and-click è utilizzare le scrollbar per scorrere contenuti che sono troppo grandi per la finestra utilizzata. Quando si è trattato di disegnare il nuovo iOS, Apple ha ben pensato di eliminare questo scomodo elemento e di sostituirlo con qualcosa di più naturale: lo scorrimento del dito sullo schermo che permette di scorrere il contenuto in modo del tutto naturale. Poi, per rendere il tutto ancora più simile al mondo reale, i designer Apple hanno introdotto l’inerzia nel movimento (per intendersi se rilasciamo il dito, lo scroll non si interrompe, ma prosegue fermandosi in modo graduale, come accadrebbe nella realtà).

Le gestures usate per attivare lo zoom. Da "Touch Gesture Reference Guide" (link in fondo all'articolo)

Zoom

In quasi tutti i dispositivi touch di ultima generazione, i controlli di zoom sono stati ormai sostituti da una gesture standard (avvicinamento/allontanamento delle dita), che rappresenta un’ottima metafora che riduce il gap concettuale tra effetto desiderato (ingradimento/rimpicciolimento dello schermo) e l’azione necessaria, restringendo quello che Norman chiama il ”golfo dell’esecuzione“.

Drag-n-drop

Pensate a questa situazione: abbiamo un insieme di prodotti da scegliere ed aggiungere ad una lista inizialmente vuota. Cosa faremmo nella realtà? Prenderemmo fisicamente i prodotti e li sposteremmo nella nostra lista (che nella realtà può essere il cestino di un negozio). Perché non trasportare l’idea anche nelle interfacce virtuali? I controlli di tipo drag-n-drop, sono ottimi esempi di interazioni naturali, ovvero simili al mondo reale in cui viviamo. Guardate la differenza tra l’esempio a sinistra, in cui i singoli elementi sono aggiunti alla lista con il bottone “aggiungi” e quello a destra, che sfrutta la naturalezza del drag-n-drop.

Due metodi di interazione a confronto: classico point-and-click VS drag-n-drop

2. Dimensioni adeguate degli elementi interattivi

Una delle prime cose che si nota utilizzando un’interfaccia touch (e una delle critiche più frequenti che le sono state mosse) riguarda la scarsa precisione del “dispositivo” di input, il dito, rispetto a quanto eravamo abituati a fare con il mouse. Questo è solo parzialmente vero: infatti ciò è anche dovuto al fatto che le interfacce erano (e sono ancora!) progettate per i cursori dei mouse, che hanno una precisione di 1-2 pixel. Con le dita non è così.

Le dimensioni dei touch-target devono essere sufficientemente grandi per permettere un’interazione agevole. Esattamente, quanto grandi?

Uno studio del MIT, intitolato Human Fingertips to Investigate the Mechanics of Tactile Sense (PDF) ha scoperto una grandezza media per un polpastrello di 8-10 mm. Da qui emerge la dimensione minima consigliata per ogni elemento interattivo. La dimensione in pixel corrispondente dipende dalla risoluzione dello schermo che stiamo considerando: lo schermo dell’iPhone 3GS impone, ad esempio, una dimensione minima di circa 30×44 pixel. Il design dovrebbe seguire la semplice equazione “+ importante = + grande” in modo da facilitare la vita dell’utente.

Gli elementi interattivi vanno poi anche adeguatamente spaziati: target troppo vicini possono far aumentare la probabilità di errore, facendo premere all’utente involontariamente un elemento piuttosto che un altro. Una spaziatura di 1-2 mm è lo standard. Tutte queste considerazioni sono relative in qualche modo alla legge di Fitt, che descrive con una formula matematica la relazione tra il tempo necessario per raggiungere un bersaglio, la sua dimensione e la sua distanza dal punto di partenza.

Nell’articolo LukeW | Touch Target Sizes, troverete una panoramica esaustiva sulle dimensioni minime suggerite dei principali produttori mondiali di smartphone.

3. Attenzione alla posizione delle mani

Una delle principali differenze tra interfacce GUI e NUI (quelle touch per intenderci) sta nel fatto che in quest’ultime il dispositivo di input corrisponde al dispositivo di output (lo schermo in entrambi i casi). Questo, come abbiamo visto, rende il tutto più semplice, ma può anche creare problemi: le mani possono infatti coprire elementi importanti dell’interfaccia, proprio quando ci servono!

Uno slider con le etichette posizionate sotto di esso: la mano copre informazioni essenziali

L’interfaccia va quindi progettata tenendo a mente queste restrizioni: posizioniamo informazioni in modo che non possano venire coperte dalle mani quando sono necessarie. Evitiamo quindi di posizionare le etichette sotto gli elementi di interazione. L’esempio di prima viene modificato semplicemente in questo modo.

Ora le etichette sono sopra lo slider: le mani non coprono più le informazioni

4. Dimenticatevi dell’hover!

Il progettista di un’interfaccia per dispositivi touch  deve assolutamente evitare l’uso dell”evento di hover, che attiva comportamenti al passaggio del mouse sopra determinati elementi. Uno dei suoi usi più comuni è l’evidenziazione di elementi interattivi quando il puntatore si posiziona su di essi: ad esempio link che assumono l’aspetto di link solo quando la freccina del mouse è sopra di essi.  Nei device multi-touch l’evento di hover non esiste e non deve essere considerato nel design dell’interfaccia. Un corollario molto importante di questa osservazione è il seguente:

Rendere immediatamente evidente cosa è interattivo nell’interfaccia e cosa no.

Deve essere chiaro cosa può essere toccato, manipolato, trascinato, ecc. e cosa no, senza affidarsi al passaggio del mouse sopra di esso. Ancora più importante, non utilizzare la tecnica (presente ad esempio nel recente redesign di Twitter) che visualizza controlli relativi ad un elemento solo al passaggio del mouse su di esso.

5. Ottimizzare l’input testuale

Non c’è buon design che tenga: l’input da tastiera su interfacce touch resta il vero problema di questi device. Non a caso, parallelamente al lancio dell’iPad, Apple ha proposto anche una mini docking station per il suo nuovo gioiellino, corredata di una classica tastiera QWERTY per utilizzarlo comodamente quando si è a casa. Cosa deduciamo quindi?

Ora e minuti della sveglia per iPhone sono impostati con due comodi controlli select

Le richieste di input scritto all’utente dovrebbero essere ridotte al minimo sulle interfacce touch. Ci sono ovviamente alcuni casi in cui non possono essere eliminate (es. dobbiamo inserire nome e cognome), ma ci sono altri in cui possono essere semplificate o anche sostituite con qualcos’altro. Vediamo alcune tecniche.

Autocompletamento

I meccanismi di auto-completamento dei campi di testo sono essenziali per ridurre l’input di testo richiesto all’utente, che può quindi digitare poche lettere e ricevere suggerimenti sulle parole più comuni, cliccando poi su di esse per completare l’inserimento

Controlli Select e Slider

Se le opzioni di inserimento possibili sono limitate (< 50-100) è molto più veloce usare un controllo di tipo Select piuttosto che richiedere l’input manuale da tastiera. In caso di input numerici si può anche utilizzare un controllo di tipo Slider.

Input vocale

Le tecnologie in questo campo sono ancora un po’ acerbe: a volte sono poco precise o non riconoscono parole difficili. Tuttavia ci sono alcune interessanti tentativi in questa direzione, che mira a sostituire lo scomodo input da tastiera con una modalità d’interazione più immediata e consona ad un device touch, che è anche solitamente estremamente mobile. Uno degli esempi migliori si trova nell’app di Google per iPhone e Android, che permette di fare ricerche sul web usando come input la propria stessa voce.

L'app per iPhone di Google permette di effettuare ricerche sul web usando la voce come input: una modalità molto adatta per il tipico contesto mobile in cui viene usato il device

Usare i nuovi tipi di <input> HTML5

Il recente update del linguaggio di markup web ha introdotto molti nuovi type da assegnare ai campi testuali <input> delle form. Oltre al solito text ora possiamo usare anche email, date, number, search, url solo per citarne alcuni. Oltre ad aumentare notevolmente la semantica del markup, l’uso di questi tipi invece del generico type=text permette ai dispositivi più avanzati di “aiutare” l’utente quando si tratta di inserire l’input testuale.

Non usare:
<input name="yourwebsite" type="text" />
ma:
<input name="yourwebsite" type="url" />

Guardate come cambia la tastiera sull’iPhone quando si usa la seconda notazione. Il dispositivo riconosce il codice e presenta immediatamente all’utente alcuni caratteri utili per scrivere una url (i simboli “.” , “/” e “.com”) e che sarebbero altrimenti stati più lunghi e difficili da raggiungere e da usare. Ottimizzazioni analoghe si possono avere usando i tipi email, number e tel.

La tastiera sull'iPhone presenta caratteri speciali se si usano i nuovi tipi per le form HTML5

Conclusioni

Quella appena finita non vuole assolutamente essere una lista esaustiva di “best practices” da seguire per la progettazione di interfacce multi-touch. Tuttavia negli ultimi anni, mi sono reso conto che il materiale presente in rete sull’argomento è, a parte rari casi, molto frammentato. Ho voluto riassumere qui quelle che ritengo le linee guida più utili per progettare applicazioni e siti web “pensati” per le interfacce che, presto o tardi, soppianteranno largamente le nostre care (ma ormai piuttosto anzianotte) GUI. Come dice Dan Saffer, uno dei guru in materia di interfacce gesturali:

we’re in the midst of an interaction design revolution

paragonabile al passaggio dalle interfacce da linea di comando a quelle basate su finestre, puntatori e icone, usate ancora oggi.

Se l’importanza delle NUI non bastasse a convincervi a tenere in considerazione queste regole pensate anche a questo: l’applicazione di queste tecniche, oltre che ad ottimizzare la User eXperience dell’utente che utilizza la vostra applicazione con un device “touch”, renderà l’interfaccia più usabile e semplice anche per gli utenti che vi accedono utilizzando  i classici dispositivi di input, cioè mouse e tastiera. Target più grandi sono più facili da cliccare anche per chi è dotato di mouse, usare interazioni più naturali permette di avere interfacce più intuitive a prescindere dal dispositivo di input, non affidarsi unicamente all’hover rende più evidenti gli elementi interattivi della pagina, ridurre l’input testuale velocizza le operazioni anche su un normale computer.

Altre risorse:

• Dan Saffer, “Tap is the new Click”: in questa presentazione, che è stata fonte di grande ispirazione per la stesure di questo articolo,  Dan Saffer ci guida alla scoperta delle interfacce “gesturali” (non solo touch quindi), illustrandoci il loro funzionamento, alcune best practices per il loro design e prototipizzazione. Assolutamente FONDAMENTALE.
• Touch gesture reference guide: una raccolta esaustiva di tutte le gesture più comuni usate nelle interfacce touch-based, by Luke Wroblewski
• iPhone User Interface guidelines: dai maestri del design di Cupertino, le linee guida per la progettazione di interfacce per applicazioni e siti web ottimizzati per il melafonino.
• Android User interface guidelines: le best practices suggerite ai designer che lavorano sul popolarissimo sistema operativo sviluppato da Google
• UI Design and Interaction Guide for Windows Phone 7: anche Microsoft, dopo il recente lancio del suo nuovo OS per smartphone (molto interessante), propone delle linee guida per il design delle interfacce utente

You wake up and check your email on your bedside iPad — that’s one app. During breakfast you browse Facebook, Twitter, and The New York Times — three more apps. On the way to the office, you listen to a podcast on your smartphone. Another app. At work, you scroll through RSS feeds in a reader and have Skype and IM conversations. More apps. At the end of the day, you come home, make dinner while listening to Pandora, play some games on Xbox Live, and watch a movie on Netflix’s streaming service.
You’ve spent the day on the Internet — but not on the Web. And you are not alone.
Chirs Anderson, “The Web is dead”, Wired US, 09/10 issue

La tesi di Anderson afferma sostanzialmente che la gente si muove (e si muoverà sempre di più) in un universo prevalentemente fatto di applicazioni, perché esse forniscono più features, sicurezza, affidabilità, velocità, insomma … funzionano meglio! Questo anche a costo di doverle pagare e di entrare in un mondo meno “libero” (AppStore, Android Market, ecc.), al contrario di quello che accade abitualmente sui siti web.

Il titolo dell’articolo non deve essere ovviamente preso alla lettera, ma fornisce ottimi spunti per discutere sul futuro del web (che non penso affatto sia il cimitero). Si sta veramente spostando verso un paradigma “application-oriented”? Io penso di sì. Penso però anche che questo universo non sarà costituito solo da una miriade di applicazioni native, incompatibili tra di loro e utilizzabili solo su determinati device. Le tecnologie web standard ci permettono di creare applicazioni interattive e COMPATIBILI già oggi. Le nuove tecnologie che vengono introdotte in questo periodo ci permetteranno di spingerci oltre. Vediamo come.

Web applications: siti web intelligenti?

La prima rivoluzione: il Web 2.0

Quando alcuni anni fa la parola Web 2.0 è diventata di moda, nel mondo Internet era in corso un grande cambiamento: alcuni siti web iniziavano a incorporare funzionalità interattive tipiche delle applicazioni desktop. L’uso di AJAX, di librerie Javascript e di tecniche avanzate CSS permetteva di creare vere e proprie Web applications (intese qui come applicazioni sviluppate con tecnologie web standard, HTML/CSS/Javascript), in grado di fornire interattività, effetti grafici avanzati e sopratutto evitare il refresh completo della pagina ad ogni azione dell’utente, risparmiandoci lente interazioni con il server ad ogni click. Il lato “client” del World Wide Web cominciava a diventare meno “stupido”: un po’ di logica applicativa si spostava dal server al browser dell’utente. Alcuni esempi di queste web applications (che hanno lanciato anche l’idea di Cloud Computing) sono Gmail, Google Docs, Photoshop.com, Picasa, solo per citare i più famosi.

Un documento aperto in Google Docs

La seconda rivoluzione: HTML5

Ora siamo alle soglie di una nuova rivoluzione: le applicazioni web 2.0 sono pronte a fare un salto in avanti e diventare (quasi) del tutto simili alle applicazioni native, sia desktop che mobile. Questo principalmente grazie alle novità introdotti da HTML5, la nuova versione del linguaggio di markup web e alla lungimiranza dei principali player del settore, che stanno già investendo in questa direzione. Ci concentreremo ora su tre features introdotte da HTML5 (in realtà le novità sono molte di più), che ritengo particolarmente importanti per questa transizione verso un mondo “application-oriented”:

1. Accesso all’hardware del device
2. Esecuzione offline
3. Local storage

1. Accesso all’hardware del device

Uno dei principali vantaggi delle applicazioni “native” è la loro stretta integrazione con il sistema operativo, e quindi con le funzionalità hardware dei dispositivi in cui sono installate. Ad esempio, possono sfruttare le informazioni dei giroscopi degli smartphone di ultima generazione, accedere ai dispositivi di I/O (fotocamera, memoria fisica, ecc.), accedere alle liste dei contatti o usufruire delle funzioni di accelerazione hardware della scheda grafica.

Una delle caratteristiche più interessanti introdotte da HTML5 è la Geolocation API, che permette di accedere in modo molto semplice, tramite Javascript, alle informazioni sulla posizione del dispositivo dell’utente. Il modo in cui queste informazioni sono acquisite dipende dal device: GPS, triangolazione, RFID, WiFi, ecc. . E’ quindi un primo passo per fornire alle applicazioni web un accesso ai sensori dei device in cui sono installati e sfruttarli adeguatamente. Il suo uso è veramente semplice.

Esempio:

if(navigator.geolocation){
   navigator.geolocation.getCurrentPosition(
      function(position){
         // 'position' contiene le coordinate del dispositivo
         alert( 'Your position is: Latitude: ' + position.coords.latitude
                   + ' Longitude: ' + position.coords.longitude);
      },
      function(msg){
         alert( 'Impossibile rilevare la posizione. '+msg );
      });
}else{
   alert("Geolocalizzazione non supportata. Aggiorna il tuo browser!");
}

Un’altra caratteristica importante, introdotta dalla nuova versione di Internet Explorer 9 (udite udite!) è il supporto per l’accelerazione grafica alle applicazioni eseguite nel browser. Questo per far fronte alle crescenti  potenza di calcolo richiesta dagli effetti grafici implementabili nelle moderne applicazioni web (tag canvas, animazioni Javascript e CSS3, ecc.).

2. Esecuzione offline

La possibilità di eseguire un’applicazione senza disporre di una connessione Internet è fondamentale per garantire una più ampia adozione delle applicazioni web. Google Docs è eccezionale: ma se non siamo connessi ad Internet non possiamo usarlo!

HTML5 per ovviare al problema introduce la funzionalità di cache manifest, molto semplice ma altrettanto potente. Supponiamo di avere una piccola applicazione costituita da due pagine HTML, “index.html” e “about.html”, un file CSS, “style.css” e un file Javascript “navigation.js”. Tutto quello che dobbiamo fare per garantire un accesso offline è aggiungere un file “.manifest” che elenca tutti i file da scaricare necessari per eseguire l’applicazione e linkarlo dalla nostra pagina web. Vediamo concretamente come.

All’interno del file myapp.manifest elenchiamo i file che compongono la nostra applicazione:

CACHE MANIFEST
index.html
about.html
style.css
navigation.js

Nella pagina HTML facciamo riferimento al file .manifest in questo modo:

<!DOCTYPE HTML>
<html manifest="manifest.cache">

Dopo un primo accesso all’applicazione via Internet, che possiamo vedere come una sorta di “installazione“, il nostro browser caricherà dalla cache locale i file contenuti nel manifesto (sincronizzandoli periodicamente con quelli online) e ci permetterà di eseguire l’applicazione anche senza connessione web. Consultate questo articolo per ulteriori informazioni sull’uso dell’offline caching (“Let’s take it offline – Dive Into HTML5″, english).

3. Local Storage

Le applicazioni native permettono di memorizzare in locale i dati utili per l’esecuzione, come ad esempio preferenze, dati di accesso o sullo stato di esecuzione, file contententi lavori salvati, ecc. Questo nel web non è quasi mai stato possibile: l’unico strumento conosciuto erano i cookie. Essi permettono di memorizzare sulla macchina dell’utente brevi file di testo contenenti dati necessari all’applicazione (ad esempio un ID di sessione per l’utente). Questo metodo è molto limitato: diversi vendor hanno infatti prodotto plug-in per i browser che supportassero una memorizzazione locale dei dati più efficace e complessa: Gears di Google, che permette di creare in locale veri e propri database, ne è un esempio. Il team di Google lo ha utilizzato per creare la versione offline di Gmail, che permette di scaricare la posta in locale, leggerla anche senza connessione e memorizzare la posta in attesa di essere inviata, proprio come un comune client di posta. Ora questa possibilità verrà offerta nativamente tramite Javascript dalle Web Storage API di HTML5, attraverso tre elementi: sessionStorage, localStorage e Web SQL Database.

1. sessionStorage

Molto simile al comportamento dei cookie. Permette di memorizzare variabili in formato chiave/valore usando i metodi sessionStorage.getItem(key) e sessionStorage.setItem(key,value). Queste variabili “vivono” nella tab del browser, quindi scompariranno una volta che la tab viene chiusa.

Esempio:

sessionStorage.setItem( 'nome' , 'Matteo' );
alert( " Il tuo nome è "+ sessionStorage.getItem( 'nome' ) );

2. localStorage

Il funzionamento è del tutto simile a sessionStorage. La differenza consiste nel fatto che localStorage persiste anche al di fuori della singola sessione in cui viene creata e vi si può accedere tramite Javascript anche dopo che la finestra del browser è stata chiusa (magari dopo giorni). Questa API presenta gli stessi metodi di sessionStorage, ovvero setItem e getItem. Molto utile per memorizzare le preferenze dell’utente.

3. Web SQL database

Session e localStorage sono ottimi metodi per memorizzare dati semplici. Ma cosa succede se ci serve  qualcosa di più complesso? Entra in gioco qui l’API più potente messa a disposizione dalla specifica HTML5, ovvero i database locali. Grazie ad essi è possibile creare dei veri e propri database all’interno del browser dell’utente. Potremmo usarla, ad esempio, in una web app di posta elettronica per memorizzare periodicamente tutte le e-mail ricevute dal nostro utente in una tabella, per permettergli di visualizzarle senza doversi connettere al server di posta. Quella che vi mostrerò molto brevemente è quella che è chiamata Web SQL Database API (“Specifica W3C”, english). Esiste anche un’altra versione in corso di sviluppo che supporta funzionalità simili, detta Indexed Database API (“Specifica W3C”, english), di cui non parlerò. L’API supporta tutte le comuni operazioni SQL, come INSERT, DELETE, UPDATE e CREATE, così come le transazioni e la gestione degli errori.

Esempio. Leggiamo dal DB locale ‘MailDB’ i dati della tabella ‘posta_in_entrata’ e li visualizziamo nella pagina web

//Apertura Database
var db = openDatabase( "MailDB" , "1.0" );
//Esecuzione query SQL racchiusa da una transazione
db.transaction(
 function( tx ){
   tx.executeSql( "SELECT * FROM posta_in_entrata" , [],
     function( tx, result ){
       // Funzione eseguita se l'istruzione SQL va a buon fine
      for( var i=0;i<result.rows.length;i++){
          $('#mails').append('<li><strong>'+results.rows.item(i).mailFrom +
                           '</strong>' + results.rows.item(i).mailText + '</li>' );
     },
     function( tx , error ){
       //Gestione errori
       alert("Errore nella lettura delle e-mail.");
   });
});

Per concludere

Dopo questa carrellata di alcune delle novità introdotte da HTML5 cerchiamo di dare una visione d’insieme di questa vera e propria rivoluzione. Rispetto alle applicazioni Web 2.0 di cui abbiamo parlato all’inizio, HTML5 ci permette di rendere il browser ancora più intelligente e indipendente: ci permette di spostare ancora più logica applicativa sul lato “client”, limitando quindi allo stretto necessario le interazioni richieste con il server. Queste applicazioni si collegheranno solo saltuariamente al server centrale, per sincronizzare i dati locali o per richieste particolari non eseguibili offline (es. l’acquisto di un prodotto nell’ e-store). Ad esempio, il client di posta realizzato come Web App potrebbe scaricare periodicamente (in background) le mail nuove dal server centrale e collegarsi ad esso per inviare i messaggi composti dall’utente in locale, magari mentre era scollegato dalla rete.

La struttura tipica di una Web Application: Html, Css e Javascript sono su lato client e interagiscono saltuariamente con il server remoto

Ovviamente tutto questo non è ancora del tutto attuale: il supporto nei vari browser a queste tecnologie è sorprendentemente buono (sopratutto in ambito mobile), ma non ancora completo. Trovate in questo sito una serie di tabelle che illustrano la compatibilità delle tecnologie HTML5 (“When can I use” , english) con i browser più diffusi.

La strada sembra comunque segnata: alcuni dei maggiori player del settore Internet stanno sviluppando progetti per il supporto estensivo delle Web Apps con un paradigma simile all’AppStore reso famoso da Apple: applicazioni concentrate in uno o pochi luoghi di acquisto, facili da trovare, alcune gratuite, alcune a pagamento, corredate da reviews e installabili a piacere sul proprio device. Vediamo i 3 più interessanti:

• Chrome Web store: ancora in fase di sviluppo (lancio previsto per fine 2010). [Update: Chrome web store è ora aperto al pubblico]  Si tratta del market per Web applications proposto da Google ed integrato con il browser Chrome. Grazie ad estensioni proprietarie del browser, queste applicazioni (sviluppate con tecnologie HTML5) potranno essere installate e accedute in modo molto simile alle applicazioni native del nostro dispositivo.
  

  Google Chrome apps launcher

• Mozilla Open Web App Ecosystem: proposto da Mozilla nell’ottobre 2010. E’ un framework che supporta la pubblicazione “libera” di Web Apps sviluppate con tecnologie web standard e installabili sul proprio computer grazie ad un “descrittore” scritto in linguaggio JSON. Lo sviluppatore è poi libero di distribuirla indipendentemente (es. sul proprio sito) oppure attraverso i vari Web store che verranno aperti, contenenti diverse applicazioni, con prezzi, voti, commenti, ecc. ecc. Il framework supporta anche applicazioni a pagamento. Qui si trova una serie di demo interessanti sviluppate da Mozilla.
  

  Una demo dell'App Store proposto da Mozilla

• Apple Web apps store: probabilmente non molti lo sanno, ma Apple fornisce anche un AppStore per applicazioni mobile sviluppate con tecnologie Web. L’ “installazione” avviene semplicemente usando la funzione “Aggiungi a schermata Home” quando ci si trova sulla pagina web dell’applicazione. L’ottimo supporto ad HTML5 di Safari Mobile permette di sviluppare applicazioni molto interessanti usando tecnologie web.

Altre risorse

• Dive into HTML5: eccezionale risorsa per capire e imparare ad usare al meglio le novità principali introdotte da HTML5
• The Web is Dead: l’articolo integrale uscito il 17 agosto 2010 su Wired US che parla della “morte” del web come noi lo conosciamo. Scritto da Chris Anderson e Michael Wolff
• HTML5 complete draft: gigantesco elenco di tutte le features in corso di sviluppo rigurdanti HTML5. Qui troverete veramente tutto: dalle API che vi ho illustrato ai nuovi tag semantici, dai nuovi campi per le form alle specifiche per il drag-n-drop nativo e la gestione degli upload dei file. E molto altro ancora.

Durante questo lavoro e nell’attività di documentazione su Internet ho imparato molte cose interessanti riguardo al design di web application fortemente interattive. Vorrei condividere qui una serie di “best practices” che ho ricavato e che sarebbe utile applicare quando ci si trova a dover progettare un processo più o meno complesso, che richiede l’input dell’utente. Spiegherò poi, con degli esempi, ognuna di queste raccomandazioni.

1. Indicare sempre l’obiettivo del processo
2. Indicare sempre lo stato di avanzamento
3. Dare feedback adeguati all’utente
4. Usare “smart defaults” quando possibile
5. Dare suggerimenti sopratutto quando sono richiesti dati in formati standard

1. Obiettivo del processo

Se il processo in cui l’utente è coinvolto è abbastanza complesso e composto da diversi passi è utile indicare chiaramente in ogni pagina qual è l’obiettivo finale del workflow. Questo aiuta a fare chiarezza sullo scopo che la form permette di raggiungere e funziona anche da utile promemoria per chi, nel corso del processo, si fosse dimenticato il motivo che lo aveva spinto ad iniziare. Sembra strano, ma può succedere più spesso di quanto si creda!

Come

Un titolo ben visibile che riporta il nome del processo è sufficiente per questo scopo. L’ideale è posizionarlo in alto, in ogni caso il più vicino possibile all’indicatore di progresso (vedi punto 2).

Il processo di creazione di un canale su LiveStream. Lo scopo del processo è chiaramente indicato dal titolo di inizio pagina "Launch a channel"

2. Stato di avanzamento

Quando l’utente deve passare attraverso diverse pagine per completare il processo, è necessario dare continuamente una chiara indicazione dello stato in cui si trova, dei passi completati e di quelli ancora da fare. Questo aiuta un utente non esperto nella procedura, a capire i passi necessari per completarla, dando anche una generica indicazione del tempo totale che viene richiesto.

Come

Non è necessario che i passi siano indicati con assoluta precisione: è anche sufficiente un’indicazione generica delle fasi da completare. Infatti, in base ai risultati intermedi, il numero di passi può cambiare (ad esempio, se è richiesta una registrazione e l’utente non è già registrato). Guardate ad esempio l’indicatore di progresso usato su amazon.com e riportato nella prossima figura. E’ comunque utile limitare il numero di pagine diverse che l’utente dovrà visitare (non più di 10).
Infine, l’indicatore deve riportare visivamente in modo molto chiaro quali sono i passi già completati, il passo corrente e quelli ancora da fare.

I passi indicati nel processo di checkout su amazon.com

3. Feedback adeguati

Ora che le applicazioni basate su AJAX sono così popolari la nozione di feedback per le azioni dell’utente dovrebbe essere abbastanza familiare per i Web designer. Ad ogni bottone premuto deve seguire un feedback visuale evidente che dia l’impressione all’utente che il sistema sta rispondendo alle sue azioni. Allo stesso modo gli errori fatti nelle form devono essere indicati il prima possibile.

Come

Se si implementa la form con tecnologie dinamiche AJAX (o simili) prevedere sempre degli indicatori di caricamento, progresso e/o conferma per ogni azione possibile dell’utente. Ad esempio, usare una barra di caricamento per indicare lo stato di upload di un file, oppure, alla pressione di un pulsante, mostrare un simbolo animato che indica l’attività del sistema, come viene fatto da anni nelle interfacce dei sistemi operativi.

Per quanto riguarda i messaggi di errore, il consiglio è di mostrarli sempre appena possibile all’utente. La tendenza attuale è di controllare e indicare dinamicamente la validità di un campo di una form non appena l’utente toglie il focus da esso (non prima! Sarebbe molto fastidioso). Ad esempio, dopo l’inserimento di un indirizzo e-mail, il sistema controlla e valida il formato in tempo reale, indicando l’errore o la correttezza dell’inserimento.

Un esempio di feedback inadeguato lo troviamo sul sito di Poste Italiane, che riportiamo nelle immagini successive. Nella form di login (immagine a sinistra) l’utente può inserire username e password. In caso di errore la pagina che ci viene restituita è quella che troviamo a destra. Nessuna indicazione! Non sappiamo neanche se qualcosa è andato realmente storto. Potremmo aver sbagliato username, password oppure potrebbe essere il sistema ad avere qualche problema (dopotutto non ci sta dicendo nulla!). Non lo sapremo mai. Pessimo design per una semplicissima form.

Un feedback praticamente inesistente dopo un login errato sul sito di Poste Italiane

4. Smart defaults

Sul sito di Alitalia, invece di lasciare i campi Data partenza/Data ritorno vuoti, il sistema li compila automaticamente con due date plausibili per una persona che deve prenotare un aereo (una settimana dopo)

Quando l’utente deve scegliere tra molte opzioni, ma è possibile dedurre le più probabili che verranno scelte, inserire la più probabile come valore di default del campo della form. Questo permette di velocizzare operazioni comuni, dando comunque la possibilità all’utente di modificare questi valori standard. Inoltre è utile per indicare la formattazione dei dati da inserire, nel caso in cui l’utente non sia familiare con la procedura. Sarebbe invece una tecnica da evitare quando i campi devono essere compilati con estrema attenzione dall’utente.

Come

I valori di default possono essere di due tipi: “non personalizzati” ovvero un valore di default comune per tutti gli utenti del sito (vedi esempio di Alitalia) e “personalizzati“, ovvero un valore di default dato in base alle caratteristiche dell’utente (storia d’uso dell’applicazione, provenienza geografica, lingua, ecc.). In entrambi i casi va lasciata ovviamente la possibilità di modificare questi valori.

5. Suggerimenti per dati standard

Quando il sistema richiede formati strutturati per alcuni campi della form (es. date, ore, nomi di aeroporti, ecc.) oppure i valori dovrebbero essere preferibilmente selezionati da un insieme di termini già esistenti, è utile dare all’utente “suggerimenti” e strumenti adatti per inserire correttamente i dati. Questo riduce sensibilmente la probabilità di errore e la frustrazione dell’utente, che può compilare la form preoccupandosi meno del modo in cui scrive i dati.

Come

L’esempio più comune sono i widget per l’inserimento delle date/ore. In casi estremi, è possibile utilizzare dei semplici controlli drop-down o checkbox, per inserire i dati scegliendoli da un elenco di valori ammessi. Quest’ultimo metodo è tuttavia molto inefficiente: basti pensare a quanto sia noioso inserire una data di nascita selezionando prima il giorno, poi il mese e l’anno da tre menù drop-down  diversi.
Quando invece i valori ammessi sono molti, è utile usare dei metodi di suggerimento, simili a quanto fanno i motori di ricerca quando inseriamo un termine più o meno comune. Vediamo in questo caso la differente User eXperience dell’utente su due siti che offrono due servizi simili, ovvero ricerca/prenotazione di voli aerei.

Il primo (expedia.com) non fornisce suggerimenti all’utente quando inserisce i dati delle città di partenza ed arrivo. Il risultato è che ci viene spesso richiesto in una pagina aggiuntiva di specificare l’aeroporto e la città specifica che che volevamo inserire. Un passo aggiuntivo molto fastidioso e che rallenta il processo di acquisto.

La cattiva User experience di expedia.com

Il secondo sito (alitalia.com) fornisce invece degli utili suggerimenti man mano che l’utente digita il nome della città che vuole raggiungere. In questo modo le probabilità di errore si riducono drasticamente, evitando quindi passi aggiuntivi e messaggi di errore inutili.

Gli utili suggerimenti del sito di Alitalia migliorano l'User experience complessiva

Conclusioni

Siamo sinceri, compilare form non piace a nessuno. Tuttavia i designer di interfacce web hanno a disposizione numerosi strumenti  per migliorare la User eXperience durante questo procedimento e renderla il meno “dolorosa” possibile. In questo articolo ho illustrato 5 tecniche utili migliorare l’usabilità dei form e, più in generale, dei processi guidati composti da più pagine. Ispirati e affiancati da altri principi di usabilità, questi suggerimenti possono aiutare i webdesigner alle prese con form di registrazione, procedure di pagamento, pagine di ricerca e quant’altro.

Altre risorse

Queste 5 tecniche non sono ovviamente tutto. Vi segnalo qui alcune risorse molto utili da consultare, che riguardano il design di form e di applicazioni altamente interattive. Io stesso mi documento spesso su questi siti e parte dei concetti spiegati qui deriva da studi del materiale che propongono:

• Web form design: un video (in inglese, circa 75 min) registrato al MIX 09 in cui Luke Wroblewsky (esperto di usabilità e Interaction design di fama mondiale) spiega gli errori più comuni relativi al design di form interattivi, riportando esempi dal mondo reale e fornendo utili “best practices” da seguire
• UI-patterns:  una collezione di pattern ricorrenti nel design di web application interattive. Un’utilissima risorsa che permette di risolvere problemi di design con soluzioni “chiavi in mano” già sviluppate. Ricchissimo di esempi tratti da applicazioni web reali
• Welie.com: sito simile al precedente. Una buona collezione di pattern comuni, ben spiegati e corredati da schemi esplicativi molto chiari

Che dire…. Felicissimo a dir poco, rilassato e, per un po’, in vacanza !

Pubblico qui la presentazione della mia tesi di laurea.

Il video che pubblico qui è qualcosa che ognuno di noi dovrebbe vedere, uno dei migliori discorsi che abbia mai ascoltato. Steve Jobs, CEO di Apple, e una delle personalità più influenti degli ultimi 20 anni, parla a Stanford nel 2005, nel giorno delle lauree . Un condensato della sua filosofia, di questo “you’ve got to find what you love” che ho fatto un po’ mio.

Non voglio fare un discorso fuori dalla realtà. Raggiungere i proprio sogni è difficile, a volte impossibile. La vita ci mette spesso in situazioni che ci obbligano ad accantonare le nostre aspirazioni. Ma è quando non è così che bisognerebbe avere il coraggio di provare, anche se ci sembra difficile, anche se qualcuno ti dirà che è “da pazzi fare una cosa del genere“. Le persone che hanno dovuto soffrire per raggiungere i propri obiettivi sono quelle che poi provano più soddisfazione, amano quello che fanno, ci credono e quindi lo fanno meglio. “Accontentarsi” a volte è necessario, ma non dovrebbe diventare la nostra filosofia di vita.

Dedico questo video a tutti quelli che hanno avuto il coraggio di provarci, lo stanno facendo o ci hanno rinunciato. Magari li farà cambiare idea.

Da questo punto di vista, il nostro fido computer può essere visto come un potente mezzo per ottenere contenuti multimediali “on demand”, ovvero quando ne abbiamo la necessità. La televisione, al contrario, è basata su un modello diverso di fruizione, in cui il broadcaster ci fornisce i contenuti agli orari e con le modalità che lui decide. Un modello destinato a essere superato da quello, molto più potente, permesso da Internet.

Le forme affermate di mezzi di comunicazione devono cambiare in risposta all’emergere di un nuovo mezzo, altrimenti la loro unica alternativa è sparire.

Così scriveva Roger Fidler nel suo famoso libro del 1997 in cui coniava il termine “mediamorfosi” (metamorfosi dei media). La televisione non sarà certo un’eccezione a questa regola.

Nell’ottobre 2010 siamo vicini al lancio ufficiale di Google TV, la nuova piattaforma interattiva sviluppata in collaborazione da Google, Sony e Logitech che promette di portare l’esperienza del web all’interno dei normali televisori di casa. “E sai che novità!” direte voi. Le Internet TV sono già presenti sul mercato da tempo e poco tempo fa la stessa Apple ha lanciato un servizio simile con AppleTV™, un set-top box per avere contenuti on-demand direttamente sul televisore.

Tuttavia Google TV si propone di alzare l’asticella e di rivoluzionare il modo in cui gestiamo il nostro tempo libero. Le Internet TV oggi presenti sul mercato non offrono ancora un’esperienza veramente integrata TV/Web: trattano i due servizi come due cose separate, non comprendendo quindi che sono destinati a fondersi in un “calderone” mediatico comune.  La stessa Apple TV è basata, in modo simile a quanto fatto con iPhone, su una piattaforma più “chiusa”, nel tipico stile dell’azienda californiana. Per di più non è integrata con la tv, ma va acquistata appositamente: sarebbe invece più semplice far penetrare questa innovazione presentandola direttamente all’interno dei televisori che usiamo tutti i giorni. Google TV cerca di fare questo, portando l’esperienza del web all’interno della TV, muovendosi però verso una più completa integrazione delle due piattaforme. Come gli stessi sviluppatori dicono:

Non solo le TV sono il centro delle nostre stanze, ma sono anche usate da 5 miliardi di persone. E’ molto di più del numero di persone che usano un computer o un cellulare. Sapendo come il web ha radicalmente cambiato questi device, abbiamo immaginato cosa avrebbe potuto fare per lo schermo più “ubiquo” del mondo, la televisione

Cosa offre:

Cosa si propongono di fare la nuova piattaforma? In pratica di rendere la televisione più simile ad un computer, senza dimenticare la facilità d’uso che l’hanno resa utilizzabile da qualunque fascia di età. Ecco alcune delle funzionalità di punta che verranno proposte:

Ricerca integrata

Trattandosi di Google, la ricerca non può che svolgere un ruolo fondamentale nella piattaforma. Una barra di ricerca comune permette di effettuare ricerche nel web, ma anche all’interno dei contenuti multimediali della propria libreria e nei canali televisivi che riceviamo con la televisione. Scriviamo “Lost” e otterremo pagine web sulla famosissima serie americana, foto, video e i canali tv che la trasmettono.

La barra che permette una ricerca integrata nei contenuti web, video e tra i canali TV

Alcune delle applicazioni che verranno fornite con la piattaforma, compatibili con Android Market

Applicazioni

Seguendo le orme tracciate da Apple (con AppStore) e la stessa Google (con Android Market) Google TV sarà una piattaforma aperta per applicazioni di tutti i tipi sviluppate da terzi. Le applicazioni già sviluppate per cellulari Android saranno adattabili per le televisioni dotate di piattaforma Google TV. Alcune applicazioni già disponibili: NBA, Pandora, NetFlix, CNBC, CNN, Amazon.

Browser integrato

Grazie al browser Chrome e a Adobe Flash Player sarà possibile navigare nel web in modo totalmente integrato con l’esperienza televisiva

Browsing/TV contemporanei

Con una funzione di sdoppiamento dello schermo, sarà possibile navigare sul web mentre in una finestra la trasmissione TV continua indisturbata. Questo permette scenari d’uso molto interessanti: ad esempio, dopo aver visto una pubblicità in televisione potremmo navigare sul sito dell’azienda e acquistare immediatamente il prodotto, oppure controllare i tweet in tempo reale riguardo ad una partita di calcio, proprio mentre la stiamo guardando.

Grazie alla funzione dual view è possibile navigare sul web (la pagina in grande) mentre si guarda la televisione (la partita di NBA in sovra-impressione in basso a destra)

La televisione avrà una home page che permette di accedere velocemente a tutti i contenuti disponibili

Home screen browser-like

Google TV ha una home page personalizzabile che è un mesh-up di fonti di informazione diverse tra loro, come i contenuti preferiti, le applicazioni, i canali tv, i podcast, il web, ecc

Servizi di video on-demand

La piattaforma sarà integrata con alcuni servizi di video on-demand  che permettono di scaricare puntate di trasmissioni, film e eventi sportivi e vederli quando e come desideriamo. Attualmente sono supportati Netflix e Amazon Video On Demand.

Il telefono come telecomando

Installando un programma apposito, il cellulare (Android o iPhone) può essere comodamente usato per controllare la TV. Una funzione del tutto simile all’app Remote disponibile per iPhone. La smart TV Sony con Google TV integrata presenta un telecomando dotato di tastiera QWERTY.

Google TV sarà inizialmente disponibile su un nuovo modello di Internet TV Sony oppure tramite il set-top box Logitech Revue da collegare alla nostra televisione attuale.

In sostanza, che c’è di nuovo?

In sostanza, dove sta la novità di Google TV?

A mio avviso, sta nella capacità (tutta da verificare, è vero) di questa piattaforma di “introdursi” nelle nostre vite di tutti i giorni, rendendo più interattiva l’esperienza del guardare la TV. Il televisore è il dispositivo di fruizione mediatica più largamente usato nel mondo: più del PC, più del cellulare. Se più televisori saranno equipaggiati nativamente con questa piattaforma (o con qualcosa di simile, viva la concorrenza!) sarà possibile introdurre con più facilità e in modo “indolore” la più grande innovazione tecnologica degli ultimi 30 anni, Internet, anche nella vita di tutti i giorni di persone che un computer non l’hanno mai acceso. So che è un target un po’ utopistico, ma l’obiettivo dichiarato è quello di rendere le televisioni più simili ai computer. Tuttavia è fondamentale per il suo successo, che la piattaforma Google TV risulti intuitiva, facile da usare e permetta di fare con facilità ciò che si faceva prima con la televisione, come sintonizzarsi su un canale e guardare la trasmissione preferita. Non dovrà mettere a soqquadro le nostre abitudini, ma affiancarsi ad esse e modificarle gradualmente.

Google si pone l’obiettivo di fare per la TV quello che Apple ha fatto per i cellulari con l’iPhone, ovvero cambiarli radicalmente, rendendoli da una parte più potenti e versatili, ma anche incredibilmente più facili e intuitivi da usare. E possiamo tranquillamente dire che il mondo televisivo avrebbe proprio bisogno di una rivoluzione simile.