Le interfacce delle applicazioni web | Usabile.it

Usabile.it

usabilità, accessibilità e interaction-design per il web

Home » Articoli » Le interfacce delle applicazioni web

14/02/2007

Le interfacce delle applicazioni web

[di Maurizio Boscarol]

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.01. 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 browser2.

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 funzioni3.

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”).

Esempio di assenza della funzione di reply in cima alla mail in gmail
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.

Esempio di mail in gmail con la funzione di reply anche in cima a destra nella mail
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.

Non sfuggirà a chi si occupa di gestione di progetti che questo approccio eternamente in divenire ha dei punti in comune con il noto “modello Toyota”, dove gli operai stessi vengono incoraggiati a migliorare continuamente il processo di produzione: questo ha l’effetto di motivare gli operai e di raffinare sempre di più non solo i prodotti, ma ciò che determina i prodotti: i processi.

Una mentalità realmente evolutiva, che lo User Centred Design da sempre incoraggia, scontrandosi però troppo spesso con le rigidità di un modello di processo produttivo di derivazione fordista, troppo rigido e ingessato in cicli chiusi, resistente a modifiche e miglioramenti.

Non sfuggirà altresì ad alcuni che questo modello distributivo, che ha bisogno di applicazioni non possedute dal cliente, ma ospitate dal produttore, che dunque è libero di aggiornarle continuamente senza preoccuparsi della distribuzione, ha molto in comune con quello che già alcuni anni fa Jeremy Rifkin chiamava “economia dell’accesso”: ovvero la diffusione di beni come fossero servizi, non più posseduti dal cliente, ma “affittati”. In qualche modo, Google sta proprio implementando le anticipazioni di Rifkin, senza un affitto esplicito, ma con un modello di business basato sugli introiti pubblicitari (integrato dalla vendita di servizi a valore aggiunto alle aziende).

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 puntamento5).

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.

1 Qualcun altro invece ritiene che il WEB 2.0 riguardi soprattutto un modello partecipativo dove gli utenti sono essi stessi autori dei contenuti, e concorrono alla creazione dei siti in un’idea di social networking che in realtà ricorda molto il concetto di intercreatività originariamente pensato da Tim Berners Lee per il web. Non entriamo nel merito della definizione, alquanto dubbia, di WEB 2.0. Ci basta sottolineare che tutte queste tendenze non sono affatto nuove. Sono soltanto più numerose e concrete di qualche anno fa (e hanno cambiato tipo di tecnologia lato client, come vedremo). Ma Il web ha sempre avuto una natura duale, come ben sottolineato da Jesse James Garrett (in questo pdf in versione italiana, 24KB): in parte strumento informativo, in parte applicazione. ^

2 Supportate nativamente non significa “standard”. L’oggetto XmlhttpRequest usato in AJAX non è un costrutto standard, ma oggigiorno viene supportato da tutti i browser moderni. ^

3 Sono noti, all’opposto, i problemi delle interfacce che cambiano in maniera invisibile all’utente, che non trova più gli oggetti nella posizione in cui si trovavano all’utilizzo (o alla versione) precedente. Su questo argomento si vedano le considerazioni di Bruce Tognazzini sui Personalized menus in Windows. ^

4 Disponibile in traduzione italiana su html.it. Vedere anche la presentazione di Jeremie Keith. ^

5 Il nuovo prodotto Apple, il chiacchierato iPhone, che attira l’attenzione soprattutto per l’interfaccia touch-screen, in realtà introduce, fra le altre, un’interessante interfaccia a doppio puntamento. Cioè il cursore non è più uno, ma possono essere due contemporaneamente (vedere la demo del sotto-menu “photo”)! Questo apre ovviamente nuove possibilità di “gesti”, azioni significative. Cioè introduce un salto di paradigma, che verrà probabilmente sviluppato in futuro (e che si è già visto, fra l’altro in film come “Minority Report”. di Spielberg, dove Tom Cruise agiva su un’interfaccia immateriale con entrambe le braccia, ingrandendo e rimpicciolendo oggetti con movimenti simili a quelli disponibili sull’iPhone), ma è possibile soltanto con l’uso di parti del corpo che siamo abituati a controllare, non con utensili (mouse, penne) che dobbiamo coordinare. Due dita o le due braccia sono facili da coordinare, due mouse richiederebbero ore di allenamento… ^

Tag:

Iscriviti alla newsletter di usabile.it:

Circa una mail al mese con gli aggiornamenti più significativi.

Articoli correlati:

torna su Torna su

Privacy Policy