Nuove interfacce
Il web 2.o stà diffondendo applicazioni fruibili via browser composte da pagine HTML sulle quali sono disponibili funzioni tipiche di applicazioni desktop. L’analisi delle interfacce di queste applicazioni e della loro logica di produzione è interessante per l’usabilità e la progettazione centrata sull’utente.
Si tratta di fogli di calcolo, di scrittura, gestione di progetti, di foto, come ad esempio Gmail, Doc & Spreadsheet, Calendar, Flickr, e altri. 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. Questa nuova caratteristica risulta essere interessante, per quanto riguarda l'analisi delle interfacce, per due aspetti:
Si tratta di fogli di calcolo, di scrittura, gestione di progetti, di foto, come ad esempio Gmail, Doc & Spreadsheet, Calendar, Flickr, e altri. 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. Questa nuova caratteristica risulta essere interessante, per quanto riguarda l'analisi delle interfacce, per due aspetti:
- La progettazione continua con logica evolutiva
- L’introduzione di paradigmi di interazione ibridi
La progettazione continua
Le applicazioni web-based sono ospitate dal server di chi le offre. Non vengono scaricate sul computer dell’utente. Questo 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. Vengono introdotte gradualmente piccole modifiche che si rendono necessarie.
Un esempio di questa natura “evolutiva” morbida di queste applicazioni, lo fornisce Gmail.
- 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.
- 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.
Questo modello progettuale è noto anche come perpetual beta: le applicazioni rimangono perennemente in versione provvisoria. In sostanza: sul web è necessario che quella dell’applicazione sia una specie di cantiere permanente, aperto a revisioni quotidiane, leggere, pur garantendo la piena funzionalità.
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 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 invece 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.
Queste differenze portarono a due principali problemi da parte degli utenti:
- Devono dimenticare vecchi automatismi e acquisirne di nuovi (per esempio il doppio click sui link che si vede durante molti test di usabilità).
- Devono di convivere con modelli mentali diversi per applicazioni che svolgono funzioni simili, ma in due ambienti diversi come web e desktop.
Tali problemi hanno generato una rincorsa ad avvicinare i due mondi:
- Sul web, fin dall’inizio si è tentato 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.
- 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).
Hanno avuto un buon riscontro in ambiti specialistici, ma hanno creato problemi a utenti comuni.
Le interfacce di queste nuove applicazioni 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 di manipolazioni dirette
- applicazioni consentono il dragging di intere porzioni di pagina in modo da ricomporre il layout (excite mix, pageflakes, ecc). - applicazioni che introducono scorciatoie da tastiera, implementandole con l’uso di una detezione javascript (gmail e le applicazioni della stessa famiglia). - applicazioni che consentono il riordinamento degli item attraverso il drag & drop (bloglines, ad esempio). Con tecnologie DHTML e AJAX si introduce 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).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, e fra web e strumenti diversi e ubiqui, probabilmente, domani.
