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.

Quando si parla di usabilità ci si dimentica spesso che un grosso corpus di ricerche proviene dallo studio dell'usabilità di interfacce software. Gli stessi principi euristici di Nielsen e anche quelli di Tognazzini, visti nel precedente articolo, sono basati su ricerche in quel settore. La trasposizione dei medesimi principi sul web è avvenuta naturalmente, in maniera quasi implicita.
Eppure, vi sono delle differenze fra il web design e il design delle interfacce di software. Questo significa che i principi non sono più validi sul nuovo dominio? No, significa che qualcuno dovrebbe preoccuparsi della loro validazione, come minimo. O di raccogliere dati specifici e confrontarli con i precedenti.

In attesa che questo avvenga, non possiamo certo ignorare principi che hanno dimostrato spesso una forte validità. Ma dobbiamo certamente essere cauti nel considerarli definitivi.
Per capire meglio il problema, tuttavia, è utile una panoramica che identifichi le differenze principali fra i due ambiti.

La bibliografia in rete non sembra poi essere molta, sorprendentemente. Si sono scritti fiumi di righe sull'usabilità, ma ben pochi articoli sulle differenze o sulle somiglianze fra i software e il web. Fra questi pochi, l'immarcescibile Nielsen dice la sua in un articolo del '97.

Questione di controllo.

Secondo Nielsen, la differenza principale fra i due tipi di interfacce risiede nella differenza di controllo. Mentre i GUI designer (designer di Graphic User Interfaces) hanno il totale controllo sull'aspetto finale dell'interfaccia, sul web questo non è possibile a causa di svariati motivi.
Primo fra tutti, la differente dotazione hardware e software dei diversi utenti (oltre naturalmente ai ben evidenti limiti dell'HTML nella visualizzazione). Il problema è ben noto ai web designer, ed è stato segnalato con puntualità anche da Sofia Postai nel suo "Siti che funzionano". La Postai conclude, per una volta, allo stesso modo di Nielsen: il web designer deve accettare questa variabilità e farsela amica, rinunciando al controllo di ogni singolo pixel in virtù di una progettazione flessibile che tenga conto delle differenze di visualizzazione fra piattaforme diverse.
Giustamente Nielsen nota che la diversità della resa nei diversi dispositivi deve essere considerato non un baco (cioè un errore), ma una caratteristica dell'ambiente web.

Il differente grado di controllo riguarda non solo la visualizzazione, ma anche ciò che all'utente viene reso possibile. Mentre nei software il progettista decide quali azioni rendere in ogni momento disponibili (ad esempio, disattivando alcune voci di menu, con il caratteristico colore grigio), il web è invece liberamente esplorabile in ogni momento. Non siamo nemmeno sicuri che l'utente entri nel sito passando dall'home page o da qualunque altra entry-page ci preoccupiamo di rendere disponibile.
Più in generale, mentre il software viene percepito come un ambiente chiuso, nel quale c'è tempo per imparare specifiche funzionalità, che possono in certa misura essere anche diverse dal prodotto concorrente, Nielsen sostiene che il web viene percepito come un tutto, e diventa un genere a sé, nel quale non è conveniente per nessun sito differenziarsi troppo dalle convenzioni tacite che si vanno stabilendo.
Spingendosi oltre, il guru danese ventila proprio la definizione formale delle convenzioni cui attenersi per rendere l'esperienza sul web più simile fra i siti e quindi più facile per l'utente. Opinione che giustamente gli vale la pessima fama di 'omologatore' e che per nostra fortuna non è mai stata veramente realizzata.
Del resto chi potrebbe mai obbligare un web designer indipendente a seguire le convenzioni sul proprio sito sperimentale? Questi siti non omologati continuerebbero comunque a circolare e a formare la diversità delle esperienze dell'utente, ampliandone le conoscenze e fungendo spesso anche da punto di paragone per gli altri siti, che finirebbero in alcuni casi per sembrare ancora più piatti (cosa che le aziende temono come la peste, anche se forse sono altri gli aspetti di cui dovrebbero preoccuparsi).

Il contenuto e l'esperienza dell'utente.

Vi è però un altro tipo di differenza che Nielsen nota fra i siti web e i prodotti software, che a mio parere è ancora più significativa, perché ha molte implicazioni non propriamente ovvie.
Ovvero: mentre i software hanno a che fare soprattutto con funzionalità, il web, piaccia o no, è un mezzo basato essenzialmente sul contenuto.

Testuale, grafico o multimediale, il vero fulcro dei siti non sono le funzionalità, in sè abbastanza primitive, ma l'interazione fra strumenti di navigazione e aree della pagina destinate interamente ai contenuti, sia informativi che meramente emotivi, d'atmosfera (come la maggior parte della grafica).

Questo pone ai designer problemi nuovi e del tutto assenti nei software. Per di più i contenuti spesso sono prodotti da fornitori esterni indipendentemente dai graphic designer e dagli interaction designer. Viceversa, nel campo software, dati e logica di business sono interni alla struttura produttiva, la quale si occupa anche della progettazione e può avere proficui scambi fra i reparti che spesso sono invece complicati nelle web agency, dove diversi aspetti del progetto sono affidati a staff differenti.

Succede così che chi deve produrre il contenuto non lo faccia in un formato che tenga conto di una task analisys o elaborato attraverso una progettazione centrata sull'utente. Anzi, il più delle volte è il designer a dover adeguare l'interfaccia a un contenuto già preconfezionato, ignorando magari il modo in cui un utente preferirebbe fruirne.
In un interessante editoriale comparso su www.uidesign.net viene fatto l'esempio delle previsioni del tempo e degli orari aerei, che vengono forniti in maniera del tutto generica, completa di dati aggregati in maniera poco intuitiva o codici incomprensibili. Magari un utente ha invece bisogno di sapere se l'aereo è normalmente in orario, se il maltempo provocherà ritardi, o come si arriva all'hotel a partire dall'aeroporto, tutte informazioni che forse sono disponibili, ma attraverso percorsi diversi da quelli che sarebbero necessari (e che verrebbero spontanei) all'utente (N.d.r.: l'esempio è stato adattato).

In generale, la presenza di contenuto implica l'azione di altre regole: i contenuti sono fra le caratteristiche di un sito che consentono la formazione dell'esperienza complessiva da parte degli utenti. Esperienza intesa come qualità dell'interazione, come abitudine, conoscenza pregressa.
I contenuti sono ciò che rende il sito attraente, utile, di tendenza, noioso, buffo, misterioso, affascinante. In poche parole, sono una componente forte della soddisfazione d'uso. Ma, come abbiamo visto, anche i contenuti necessitano di particolari modi di fruizione, di navigazione, per poter soddisfare l'utente, quello specifico utente, diverso magari da altri.

Se i contenuti sono una delle caratteristiche che vanno a formare la soddisfazione d'uso, sono allora necessariamente campo di interesse dell'usabilità. E tuttavia non vi sono ricerche precedenti sulla fruizione di contenuti nel campo software, perché i software sono ambienti di lavoro (discorso parzialmente diverso per i cd-rom, che però sono un mezzo privo dei vincoli che attualmente caratterizza internet).

L'usabilità pare muoversi allora in mezzo ad una sorprendente ricchezza di nozioni e regole per quanto riguarda funzionalità e navigazione (e si tratta, ricordiamolo, di norme ancora in larga parte disattese…), grazie anche alle ricerche sulle GUI e -ma solo in parte- sullo stesso web. Ma è ancora agli albori per quanto riguarda la presentazione e la fruizione dei contenuti, ovvero una delle parti predominanti di un sito web.
Le norme sulla scrittura dei testi, di cui abbiamo già parlato, sono un esempio di come pensare un testo per il web. Ma vi sono molte possibilità inesplorate e non sperimentate per offrire servizi, utilità, contenuti che possono non essere semplicemente articoli o testi di presentazione.

Alcuni spunti utili (scarsamente tenuti in considerazione) possono venire da tutto un filone di studi sulla presentazione simultanea di informazioni verbali e non verbali (visive e auditive) nell'ambito della comprensione dei testi e delle difficoltà di apprendimento.
Alcuni esperimenti per esempio dimostrano che la presentazione di materiale iconico (figure, animazioni, diagrammi) assieme a testi scritti influenza la comprensione, e può in specifici casi addirittura ostacolarla, perché richiede l'integrazione di informazioni provenienti da fonti diverse (Schnotz et al. 1993). Molte ricerche sono in corso, e non possono che avere un forte impatto su quella che domani sarà la nuova usabilità del web.

L'esperto di usabilità web si va così sempre più configurando per il futuro come un integratore di conoscenze. In parte si tratta di conoscenze riguardanti il design di interfacce, l'analisi dei compiti, lo studio dell'utente. Ma in parte l'esperto deve avere competenze di comunicatore, essere capace di occuparsi a tutto tondo di media e di contenuti, con l'obiettivo di fondere conoscenze provenienti da campi di studio diversi e apparentemente poco affini, ma che concorrono in maniera determinante a formare l'esperienza dell'utente sul web.

Il WAP, il protocollo per l’internet sui telefonini, è al centro di una
piccola diatriba. Il solito Nielsen stavolta l’ha fatta grossa. Con una
ricerca condotta assieme a Marc Ramsay per il suo Norman-Nielsen
Group tenta di mettere una lapide sul protocollo, dimostrando che
gli utenti non lo gradiscono e che l’usabilità è a zero.

La ricerca è un plico di 90 pagine scaricabili
via internet sul sito NNgroup dietro il pagamento della modica cifra di
18$. Nell’alertbox del suo sito personale Nielsen offre una sintesi
della ricerca, che riassumiamo per sommi capi:

20 utenti londinesi sono stati forniti di telefonino WAP, la metà Ericsson
e la metà Nokia (la cosa non è irrilevante, come vedremo in seguito…).
Per una settimana hanno potuto utilizzarlo gratuitamente, usufruendo così
dei servizi WAP, che normalmente sono a pagamento con una tariffa basata
sul tempo di connessione. Al termine della settimana, il 72% dei soggetti
dichiarava di non voler aver più nulla a che fare con il WAP, che risultava
difficile da usare e frustrante. Nielsen in particolare conclude che:

• Le applicazioni e i servizi WAP sono troppo lenti: uno o due minuti
  sono troppi per una risposta; un tempo accettabile dev’essere entro
  i 30 secondi.
• La navigazione utilizza termini incomprensibili
• Manca del tutto un’analisi dei compiti (task-analysis), cioè lo studio
  dei procedimenti che gli utenti farebbero per svolgere un compito. Ad
  esempio, i programmi televisivi sono divisi per rete televisiva e non
  per orario: così se un utente vuole cercare i programmi delle 8 deve
  fare l’identica ricerca tante volte quante sono le reti televisive,
  con grande dispendio di tempo e di denaro.

I servizi WAP non dovrebbero essere trasposizioni sul telefonino degli
stessi servizi per il Web. Andrebbero abolite la grafica, le schermate
di presentazione e andrebbero riprogettati contenuti e servizi per adattarli
ai piccolissimi display dei telefonini.

Conclusione: inutile sviluppare per il WAP, meglio dedicarsi direttamente
ai telefonini di terza generazione.

A riprova della poca qualità del WAP, Nielsen cita il protocollo alternativo
i-mode, utilizzato in Giappone, dove vanta 10 milioni di utenti,
che funzionerebbe meglio.

Ciò che Nielsen non dice è che in Giappone vi sono anche circa 5 milioni
di utenti WAP, che ne utilizzano ogni giorno i servizi con soddisfazione.
Altra cosa che Nielsen non prende in considerazione è l’uso del WAP in
Giappone, America e Corea, dove viene regolarmente utilizzato da moltissimi
utenti. Com’è possibile che solo in Europa il WAP stenti ad affermarsi?
E come la mettiamo veramente con l’usabilità?

Cerchiamo di sciogliere alcuni dei nodi di questa faccenda, con l’aiuto
di una vera autorità in materia, Luca Passani di Openwave,
società che riunisce Phone.com e Software.com. Perché lui? Perché
Luca ha scritto già un
articolo su Punto-informatico contestando la ricerca di Nielsen, e
perché la Phone.com ha una certa importanza nell’argomento. Luca Passani
è inoltre l’autore del capitolo sull’usabilità WAP del libro
"Professional WAP" di Wrox Press, presto tradotto anche
in Italiano.

Andiamo dunque verso le applicazioni trasparenti della tecnologia, insomma,
quelle wearable (vestibili), che qualcuno pronostica saranno il vero punto
di arrivo di tutta questa rivoluzione. Ma come ne escono Nielsen e il
WAP da tutta questa chiacchierata?

Non benissimo, il primo. E’ vero che le applicazioni WAP in Europa sono
poco usabili. Ma non è vero che la soluzione sia quella di abbandonarle
per investire sulla prossima generazione, semplicemente perché la prossima
generazione… sarà ancora il WAP!

Il guaio di questa ricerca è che non tiene conto della realtà, non
studia l’usabilità in paesi nei quali il WAP è molto più sviluppato e
funziona, finendo per dare di questa tecnologia una visione molto parziale.
Porta ad esempio una tecnologia (l’i-mode) che trae i suoi vantaggi dall’essere
proprietaria e quindi confinata al Giappone.

I veri sconfitti di tutta questa storia sono però ancora una volta
gli sviluppatori che non fanno tesoro delle linee guida sull’usabilità
WAP già definite da Passani nel libro citato. Una volta che queste
saranno entrate con decisione nel processo di sviluppo – e non occorre
dire che questo cambiamento di rotta nel processo di progettazione va
effettuato quanto prima – e una volta superati i problemi di interoperabilità,
con la messa a punto di standard rispettati da tutti i gestori, allora
il WAP potrà svilupparsi efficacemente anche qui da noi, a differenza
di quanto pronosticato, forse troppo superficialmente, dal guru dell’usabilità.

Per motivi legati all’usabilità e all’accessibilità è consigliabile limitare
l’uso dei moduli multimediali in Flash ai soli casi in cui essi possano
costituire un reale valore aggiunto per il sito.
I casi in cui questo si verifica sono due:

1. quando il sito si rivolge ad utenti fortemente motivati all’innovazione
   senza basarsi su una struttura informativa o di servizio complessa.
2. quando la natura dell’informazione o dell’esperienza da trasmettere
   è principalmente visiva.

Anche in questi casi, comunque, Flash deve essere proposto come alternativa
ad una visione più accessibile delle informazioni in HTML.

Perché tanta cautela? Perché aggiungere regole ad un mondo che ne ha
già troppe? Per diverse ragioni: innanzitutto perché Flash è una tecnologia
che richiede l’installazione di un plug-in sul browser affinché i
file siano correttamente visualizzati. Ciò taglia automaticamente fuori
una certa percentuale di utenti. E poi perché molto spesso i file hanno
dimensioni e tempi di caricamento ragguardevoli, la stragrande maggioranza
delle volte molto più alti dell’HTML. Vari studi di usabilità dimostrano
che gli utenti non gradiscono lunghe attese davanti al monitor del
computer, perché si annoiano e si distraggono, scegliendo altri siti.
Per lunghe attese intendiamo superiori ai 20-30 secondi.

La Macromedia, casa produttrice di Flash, ha reso il plug-in disponibile
e scaricabile
gratuitamente, e, grazie ad un’attenta campagna marketing, è
riuscita ad ottenere che moltissimi utenti siano in grado visualizzare
il suo formato. Ciononostante non è riuscita a risolvere gravi problemi
di usabilità e accessibilità di base.
Fra i principi alla base dell’accessibilità dei siti ci sono:

1. Rendere i contenuti disponibili a tutte le categorie di utenti (quindi
   anche a categorie svantaggiate, come ciechi e sordi).
2. Laddove non fosse possibile il punto 1, almeno fornire strade di
   fruizione alternative.

Flash viola entrambi questi principi, assieme ad altri standard
importanti:

1. Flash non può essere visto da una percentuale importante di utenti,
   come già detto. Oltre a quelli sprovvisti del plug-in, vanno menzionati
   gli utenti con svantaggi visivi o uditivi.
2. Con alcune configurazioni, addirittura, l’uso di Flash può mandare
   in blocco il sistema.
3. Il tasto back del browser, uno dei click più gettonati, viene
   reso inutile.
4. Chi non ha il plug-in non può nemmeno avere idea di cosa si
   mostri nel filmato, sebbene la Macromedia abbia implementato l’uso del
   tag ALT, già usato in HTML per una breve descrizione delle immagini
   statiche. Ma possono poche parole descrivere adeguatamente l’esperienza
   multimediale di un filmato Flash?
5. La navigazione nei filmati Flash è raramente conforme agli standard
   e comprensibile per gli utenti, che devono così impiegare la
   prima parte del loro tempo di fruizione per capire “come funziona”.

La Macromedia cerca ora di correre ai ripari dichiarando un miglioramento
degli standard di accessibilità di Flash. Queste dichiarazioni sono
state purtroppo smentite dai fatti e da un ottimo
articolo di Joe Clark, che dimostra chiaramente come l’accessibilità
dei progettisti di Flash non sia la stessa del W3C, il consorzio che regola
gli standard sul web (ne parleremo in un prossimo articolo).

Guerra aperta a Flash, allora? No, più semplicemente la reazione
ad un fraintendimento, forse alimentato dalla stessa Macromedia,
su questo prodotto. Nato come gadget per arricchire l’esperienza sensoriale
sul web, Flash ha acquistato crescente popolarità fra gli sviluppatori
e i web designer perché consentiva di dar libero sfogo alla propria vena
creativa, aspetto sul quale l’HTML è notoriamente castrante. Dietro
questa differenza fra Flash e HTML sta però il vero motivo del contendere.
Alcuni sviluppatori si sono fatti prendere la mano dal giochino sperando
forse in cuor loro di liberarsi alla svelta dell’HTML, e si sono dimenticati
di quale fosse lo scopo primario di un sito: fornire informazioni e
servizi utili all’utente. Può Flash svolgere questo compito? A volte,
forse. Nella maggioranza dei casi, no. I file prodotti da Flash hanno
infatti numerosi altri problemi di gestione:

1. Non rispettano gli standard per la gestione dei link dell’HTML
2. Non si interfacciano facilmente con le funzioni di ricerca
3. Sono complicati da aggiornare e localizzare, a differenza dell’HTML.
4. Un testo in Flash non può essere selezionato e copiato, nè può essere
   modificata la visualizzazione del carattere nel caso un utente abbia
   problemi di vista.

[NOTA: Quest’ultima affermazione vale solo fino al plug-in della versione
3, ovvero quello che usavo all’epoca della scrittura dell’articolo]

Fornite informazioni visive.

A differenza di HTML, Flash non è un linguaggio di mark-up, cioè
di descrizione di documenti, ma un linguaggio visivo.
Questo spiega da una parte la sua popolarità, dall’altra le critiche per
ogni suo uso improprio.

E’ adatto a rappresentare informazioni visive e a offrire esperienze
originali e creative, ancorché anomale, di interazione con l’utente. Dovrebbe
essere usato per questo: per offrire esperienze alternative, per
animare piccoli moduli di una pagina, per cartoni animati
d’intrattenimento o per informazioni di natura intrinsecamente visiva.

Facciamo un esempio. Pensiamo alle possibilità che offrirebbe Flash
per una spiegazione didattica basata sui diagrammi di flusso (informazione
di tipo visivo): potremmo far vedere il diagramma che si forma, visualizzare
una spiegazione cliccando su una parte che interessa, ruotare, ingrandire
o rimpicciolire il diagramma per metterlo in relazione con un flusso di
lavoro più complesso… Sarebbe un’ottima alternativa visiva a
una spiegazione passo-passo in HTML o a un’immagine statica.
Fra gli altri, www.monkey.com
fornisce alternative di questo tipo, arricchendo la versione Flash del
sito con feature visive (e sonore) che migliorano la fruizione dell’informazione
quando questa è di natura visiva.

Ottimizzare!

Anche nei casi riusciti, comunque, un file Flash dovrebbe essere sempre
presentato come una scelta, e non come l’unica alternativa possibile.
Non solo: dovrebbe anche essere sempre ottimizzato: adeguare il
peso del file alla qualità dell’animazione, scegliendo i settaggi e le
tecniche di animazione più leggere per raggiungere lo stesso scopo. Una
tecnica elementare in alcuni casi può essere quella di scegliere il
frame rate (numero di fotogrammi per secondo) più basso possibile
in relazione alla fluidità necessaria all’animazione.

Sono suggerimenti dei quali non sembrano aver tenuto conto gli autori
di un filmato di presentazione
per un corso di formazione che mi è capitato di incontrare di recente
in rete.
Cercando le informazioni su questo corso sul sito dell’ente di formazione
che lo organizza, ci si trova a dover scaricare un filmato in Flash! Nessuna
alternativa html è presentata! Cosa tanto più sorprendente se si pensa
che le informazioni di base su un corso di formazione possono tranquillamente
essere presentate in forma scritta, anzi: di solito lo sono.

La cosa più perversa e insieme ironica di questo filmato è che il tempo
di scaricamento è insolitamente lungo se consideriamo che il modulo non
presenta quasi animazioni! Solo un leggero tremolio di scritte e di
link verbali! Circa tre minuti di attesa per un filmato Flash di
poche pagine composto soltanto da informazioni verbali scritte e
senza alternative in html…
Inutile dire che ho terminato la mia visita senza finir di vedere
il modulo e senza ottenere alcuna informazione utile sul corso.

Perché usare Flash per presentare un semplice corso di formazione,
(informazione di natura verbale)? Non riesco a trovare una sola
risposta valida a questa domanda. Tanto più che buona parte dell’audience
potenziale di queste informazioni potrebbe essere composta da laureandi,
i quali si collegano spesso dall’università, dove l’installazione
di plug-in non è permessa…

Piuttoto che per i siti informativi, dunque, l’uso di Flash sulla rete
si presenta come un’attrattiva soprattutto per alcuni siti d’immagine,
per i quali non vi sono requisiti particolari di usabilità, in quanto
si rivolgono ad utenti motivati all’innovazione e disposti magari
a perdere del tempo in cambio di un’esperienza di fruizione estetica.
Meglio ancora se questi siti non devono interfacciarsi con grosse basi
di dati né essere aggiornati frequentemente.
In questi casi probabilmente i benefici (esclusivamente in termini d’immagine)
possono essere superiori ai costi, a patto di rispettare i criteri di
ottimizzazione e di coerenza con la natura visiva dell’informazione: in
nessun caso è preferibile un testo informativo in Flash piuttosto
che in HTML!

Chiarezza con il cliente

Ma in generale come decidere circa l’uso o l’abuso di Flash? Tenendo
conto di tutti i fattori fin qui visti, innanzitutto. E facendo in secondo
luogo affidamento sulla professionalità e sull’onestà intellettuale
degli sviluppatori.
Sono loro che dovrebbero informare i propri clienti anche degli svantaggi,
e non solo dei vantaggi, di questo formato di animazione, evitando di
lasciarsi andare a racconti o a dimostrazioni off-line magnificanti.
Le dimostrazioni off-line hanno il difetto di non tener conto del tempo
di scaricamento, com’è ovvio. Non basta dire “be’, naturalmente ci metterà
un po’ più di così a caricarsi…” per avere la coscienza a posto. Fatele
vedere in remoto, con una normale connessione telefonica… e forse
il cliente inizierà a cambiare parere!

Le domande da porre e da porsi sono piuttosto: Flash è davvero un
valore aggiunto? Si attaglia al profilo del sito e dell’azienda? Ostacola
una categoria importante di utenti?
Non possiamo scaricare la decisione sul cliente, se non gli forniamo le
corrette informazioni per decidere. Si tratta di una prassi addirittura
banale di deontologia professionale che pare purtroppo non solo molto
lontana dall’essere praticata, ma anche dall’essere vista come una reale
necessità.