Negli ultimi anni sul web si stanno diffondendo applicazioni fruibili via browser composte da pagine HTML sulle quali sono disponibili funzioni tipiche di applicazioni desktop: fogli di calcolo, ambienti di scrittura, gestione di progetti, di foto, ecc. Alcuni esempi sono i servizi di Google (Gmail, Doc & Spreadsheet, Calendar, Analytics e altri), Flickr, e altri.

Qualcuno identifica questa tendenza a proporre applicazioni web-based con una nuova ondata del web, il cosiddetto WEB 2.0¹. Le nuove applicazioni web-based non sono più basate su tecnologie proprietarie e plugin, ma su DHTML o su AJAX, un insieme di tecnologie che è supportato nativamente dai browser².

L’analisi delle interfacce di queste applicazioni e della loro logica di produzione è interessante per l’usabilità e la progettazione centrata sull’utente. Alcuni aspetti rilevanti sono i seguenti:

1. La progettazione continua con logica evolutiva
2. L’introduzione di paradigmi di interazione ibridi

Vediamoli nel dettaglio.

Progettazione continua

Le applicazioni di cui stiamo parlando sono per lo più applicazioni ospitate dal server di chi le offre. Non vengono scaricate sul computer dell’utente, installate, come le tradizionali applicazioni desktop (mail, office, calendar) di cui si propongono come alternativa. Il fatto di non dover essere scaricate e installate ha reso possibile un lavoro continuativo di evoluzione di queste applicazioni attraverso l’analisi dei problemi, le richieste degli utenti, i test di usabilità. L’evoluzione di queste interfacce è continua, ma avviene per gradi: cioè senza rivoluzionare l’ambiente.

Talvolta questo ha anche un effetto negativo: quello di non rendere consapevoli gli utenti che nuove funzionalità sono state introdotte. Ma ha pure il pregio della stabilità: chi non è consapevole della nuova funzionalità, può continuare ad usare l’interfaccia come il giorno precedente, scoprendo poi magari casualmente (o grazie a tooltip disseminati qua e là discretamente nell’interfaccia) le nuove funzioni³.

Un esempio di questa natura “evolutiva” morbida di queste applicazioni, lo fornisce proprio Gmail, il servizio di posta elettronica di Google. Fino a qualche mese fa (ma si può vedere la stessa situazione nella versione in italiano, più indietro rispetto a quella inglese), mentre si leggeva un messaggio mail, si poteva fare un reply solo cliccando su alcuni widget in fondo al messaggio stesso (segnatamente, o cliccando dentro un textarea in fondo al messaggio – uso a sua volta insolito, ma semanticamente corretto, di un widget tradizionale – o cliccando su un link blu con la scritta “reply”).

Fig. 1 – Nella prima versione, per fare reply bisognava scorrere fino in fondo al messaggio, per cliccare su un link (1) o nella textarea (2). Ma se la mail è lunga e vogliamo fare reply prima? Siamo costretti a scorrere comunque fino in fondo.

La nuova soluzione ha introdotto una sorta di tasto esplicito per il reply nella parte alta del messaggio.

Fig. 2 – Con l’introduzione del tastino in alto (che attiva anche una tendina con diverse altre opzioni), non è più necessario scorrere la pagina per fare un reply. Si notano anche altre leggere modifiche dell’interfaccia, come l’introduzione di alcune icone e il cambiamento del tono di blu per i link e le icone corrispondenti. Inoltre la sottolineatura della lettera R allude alla scorciatoia da tastiera: difficile da notare e capire, ma una funzionalità in più per utenti evoluti.

La sua introduzione è non invasiva, non modifica il layout, è integrata nella grafica per effetto di gradienti molto leggeri, e offre anche una tendina con nuove funzioni. Questa introduzione è tutt’altro che rivoluzionaria (se vogliamo è piuttosto ovvia) ma migliora di molto l’efficienza del prodotto. L’approccio di un po’ tutte le applicazioni della famiglia Google potremmo definirlo quello dell’innovazione che non si vede, o dell’innovazione discreta. Vengono introdotte gradualmente solo le piccole modifiche che si rendono necessarie.

Questo modello progettuale è noto anche come perpetual beta: le applicazioni rimangono perennemente in versione provvisoria. L’approccio ha dei detrattori. La scelta di non sbilanciarsi con versioni definitive dei prodotti in qualche modo risparmia alle applicazioni stesse alcune critiche che non mancherebbero se venissero presentate con il consueto marketing aggressivo da “soluzione finale ai problemi dell’utente”. Quindi qualcuno vede la “perpetual beta” come un’ipocrita espediente per ridurre le critiche.

Al di là delle considerazioni di marketing, questo è invece davvero l’approccio corretto per lo sviluppo di interfacce e applicazioni innovative, perché prevede una costante manutenzione e un miglioramento graduale dell’interfaccia, in base ai risultati che test o prove sul campo fanno emergere.
Spesso invece nei cicli di progettazione tradizionale quando si propone un approccio di revisione iterativa basato su test o altri strumenti di analisi dell’interfaccia si incontra un muro di scetticismo, legato al fatto che le attività di test vengono ancora percepite come dei costi e dei rallentamenti rispetto all’obiettivo di “time-to-market”. In realtà è l’approccio progettuale tradizionale ad essere obsoleto, sul web. E a produrre, in definitiva, scelte più rigide, dunque peggiori.

In sostanza: sul web non è più pensabile sviluppare un’applicazione in versione 1.0 e poi correggerla nella versione 2.0 su segnalazione degli utenti, molti mesi dopo. E’ necessario che quella dell’applicazione sia una specie di cantiere permanente, aperto a revisioni quotidiane, leggere, pur garantendo la piena funzionalità. E’ il ciclo di progetto che deve essere ripensato e ritarato: le applicazioni web-based di Google ci offrono uno dei possibili approcci: una cura e una manutenzione continua, che riduce il tempo della prima release, e consente di apportare continue piccole migliorìe al prodotto. Costanti, leggere, poco invasive, e impossibili con una progettazione rigida di tipo tradizionale.

In questo modo cambia anche il tipo di curva di apprendimento degli utenti, che diventa molto più morbida proprio per la gradualità degli interventi.

L’introduzione di paradigmi di interazione ibridi

I paradigmi di interazione possono essere riassunti come i gesti e i modi di agire a disposizione dell’utente per ottenere effetti significativi in un’interfaccia.

Uno dei problemi storici delle applicazioni web è la scarsità di possibilità che offre l’html a livello di “serbatoio” di azioni possibili:

• Sul web si può solo cliccare su specifici oggetti (su link e su pulsanti o caselle), digitare testi, scorrere con barre di scorrimento.
• Sul desktop sono possibili queste azioni assieme a molte altre. Ad esempio, vi è il doppio click per lanciare un’applicazione. Il click e lo scorrimento , il posizionamento e il rilascio per lanciare funzioni da un menu. Il click a distanza di tempo su un etichetta di file per cambiarle nome; il drag & drop, e così via.

Il fatto che le azioni significative e il modo dell’interfaccia di reagirvi siano fondamentalmente diverse su web e sulla scrivania porta inizialmente ad alcuni problemi da parte degli utenti, che devono dimenticare vecchi automatismi e acquisirne di nuovi, problemi in parte testimoniati dal fenomeno del doppio click sui link che si vede durante molti test di usabilità. Il problema maggiore sta però nella necessità di convivere con modelli mentali diversi per applicazioni che svolgono funzioni simili, ma in due ambienti diversi come web e desktop.

Queste differenze hanno anche generato una rincorsa ad avvicinare i due mondi, proprio per evitare questi problemi e i limiti che sarebbero potuti nascere in prospettiva se i due mondi fossero rimasti fondamentalmente separati. In fondo per il desktop e il web si usa la stessa macchina, il computer: dunque passare rapidamente da un paradigma all’altro può creare disorientamento e generare errori a causa di automatismi non appropriati al contesto e di modelli mentali non consolidati.

Sul web, fin dall’inizio si tentò di imporre l’uso di applicazioni basate su plugin proprio perché queste applicazioni consentivano un paradigma d’azione più ricco, modellato su quello del desktop. Ma anche i sistemi operativi cambiarono, implementando strumenti e modi d’azione che hanno una chiara derivazione dal web. La più evidente è l’introduzione di una funzione di search di documenti (disponibile in mac OSX e annunciata in Vista) come interfaccia privilegiata (rispetto al file system precedente).

Sul web le applicazioni basate su plugin hanno avuto un buon riscontro in ambiti specialistici, ma sono noti i problemi che creano a utenti comuni. Nessuna tecnologia è finora riuscita ad imporsi come la soluzione tecnologica per eccellenza e a raggiungere l’ubiquità dell’html, e questo è naturalmente un problema per lo sviluppo di applicazioni complesse.

Le interfacce di queste nuove applicazioni ora ci riprovano, usando javascript anziché un plugin. Anch’esse introducono modalità di interazione normalmente estranee al web. Il vantaggio è che ora questo viene fatto in modo più trasparente, non invasivo, basandosi su un look & feel degli oggetti sostanzialmente simile a quello dell’html, anche perché… è html!

Le funzionalità introdotte sono invece molte.

1. Alcune applicazioni consentono il dragging di intere porzioni di pagina in modo da ricomporre il layout (excite mix, pageflakes, ecc).
2. Altre introducono scorciatoie da tastiera, tradizionalmente assenti sul web, implementandole non attraverso il problematico accesskey, ma con l’uso di una detezione javascript (gmail e le applicazioni della stessa famiglia).
3. Altri ancora consentono il riordinamento degli item attraverso il drag & drop (bloglines, ad esempio).

La cosa che accomuna queste applicazioni è l’introduzione di paradigmi non presenti in html, ma innestati sopra l’html, come un livello di comportamento separato che viene “attaccato” agli oggetti html. Non sempre il loro uso è intuitivo, ma il vantaggio è che quasi sempre l’applicazione è utilizzabile comunque. Niente deve per forza essere imparato. Niente deve essere scaricato.

Certo, applicazioni basate sulla manipolazione diretta che non prevedano alternative, pongono problemi di accessibilità (il caso dell’ordinamento delle sottoscrizioni in Bloglines, per esempio). E tuttavia vi è per la prima volta la sensazione che si stia imboccando una strada proficua, dopo la separazione fra contenuto e presentazione da una parte: con tecnologie DHTML e AJAX si introduce infatti un nuovo livello di separazione] fra presentazione e comportamento degli oggetti, che ha a che fare specificatamente con i paradigmi di interazione resi disponibili da javascript.

Verso un modello integrato di interazione

Supportare modelli d’azione più ampi di quelli disponibili sul web è probabilmente necessario per rendere le interfacce più efficienti e soddisfacenti. Farlo in maniera non invasiva e non esclusiva, attraverso librerie javascript che vengono richiamate attraverso classi (o in generale attributi) associati agli oggetti html apre la strada per la progettazione di modalità d’azione alternative a seconda del programma utente usato e delle preferenze/capacità dell’utente (con tastiera o con dispositivi di puntamento⁵).

Siamo tutt’altro che giunti a maturazione di questo processo, che anzi è nelle sue fasi iniziali. Molti problemi di usabilità possono derivare da applicazioni progettate in questo modo. Ma le novità delineate fin qui nelle applicazioni web sembrano davvero indicare un modo nuovo e concreto, non invasivo, basato su html, ma arricchito di possibilità, di progettare l’interazione del futuro e una possibile integrazione fra web e desktop oggi, e fra web e strumenti diversi e ubiqui, probabilmente, domani.