Undolog.com

Permettere agli utenti di interagire con una pagina Web ha prodotto negli ultimi anni un notevole aumento nell’uso di script lato client: codice Javascript in grado di rispondere e manipolare in tempo reale tutta una serie di informazioni. Il Web2.0 è la massima espressione di questa capacità di interazione, dove l’utente finale - il navigatore -partecipa attivamente alla costruzione e all’evoluzione del sito Web, interagendo con esso e contribuendo personalmente. Si parla quindi di User-Generated Content (o UGC - contenuto generato dagli utenti) che vede il “navigatore” sicuramente meno passivo!

Per realizzare questa interazione, per permettere quindi all’utente finale di aggiungere il suo contributo, sono state sviluppate una serie di tecniche che hanno modificato l’aspetto e il comportamento delle pagine Web (statiche sino ad oggi, mentre adesso simili alle tradizionali applicazioni dei Desktop) negli ultimi anni. Modificare il contenuto di una pagina, inviare dei file, dare il proprio voto ad un video o a un documento, registrarsi o modificare i propri dati, sono solo alcune delle operazioni richeste in tanti servizi (2.0 beta) presenti sul Web.

La crescente richiesta di strumenti Client (Prototype, Dojo Toolkit, jQuery, Ajax ASP.NET, …) e Server (Ruby on Rails, librerie PHP, JSP e ASP, …) per la costruzioni di Web 2.0, ha portato alla nascita di tantissimi tool di sviluppo, librerie o semplicemente filosofie di un nuovo sviluppo sul Web;

Queste tecniche e questi strumenti sono stati usati in quasi tutte le combinazioni possibili, grazie alla loro caratteristica modulare e alla capacità di risolvere a volte alcuni compiti particolari. C’è chi ha scelto, quindi, soluzioni interamente in Adobe Flash, chi ha usato soluzioni ibride (Adobe Flash + Javascript), chi, partendo da librerie generiche come Prototype, ha realizzato i suoi Framework specifici. La maggioranza di questi strumenti, inoltre, è open source (o comunque gratuita) e questo ha contribuito sicuramente ad una enorme diffusione in tempi brevissimi.

Il prezzo che si è pagato, tuttavia, per ottenere questa nuova interazione, è stato una netta perdita di accessibilità (e spesso usabilità) del Web. Paradossalmente l’incremento delle funzionalità di interazione ha ristretto il numero degli utilizzatori che, per ragioni diverse, non possono accedere a queste nuove tecnologie! Si è avuto, quindi, un’incremento del Digital Divide, spesso dovuto esclusivamente all’abuso di alcune tecniche di sviluppo o semplicemente alla non considerazione di alcuni target finali.

Quando si sviluppa una sito Web, o più semplicemente una pagina Web, non bisogna dimenticare mai l’utente finale, il quale può visitare il nostro sito con dispositivi (browser o user agent) diversi da quelli che ci aspettiamo ma, soprattutto, con caratteristiche e impostazioni diverse da quelle che abbiamo dato per scontato (risoluzione dello schermo, numero di colori, Javascript disabilitato, mancanza di Applet, Plugin o ActiveX, ecc…). Ne deriva che oltre alla semplice compatibilità (funzionale e visiva) tra i diversi browser bisogna porre attenzione alle caratteristiche che questi dispongono. L’argomento, evidentemente, è complesso ed articolato.

È giusto obbligare un utente ad avere Javascript disponibile ed abilitato per navigare il nostro sito Web?

Secondo me ci sono due possibili risposte a questa domanda; la prima potrebbe essere no, non è giusto, soprattutto se quello che vogliamo realizzare può essere strutturato in modo tale da permettere sia una accesso evoluto sia un accesso base. Tuttavia, e questa è la seconda risposta, ci sono evidentemente casi limite dove l’obbligo di disporre di una particolare tecnologia prescinde le capacità - e la buona volontà - dell’analista programmatore!

Inoltre - questione controversa - chi siamo noi (sviluppatori) per decidere e obbligare chi debba avere cosa?

Se il progetto che vogliamo realizzare è tale da poter essere usato da qualsiasi user agent, con le dovute precauzioni, i tempi di sviluppo crescono e la complessità del codice (HTML, Javascript e Scripting Server) aumenta. È una scelta produttiva, personale, a dettare le regole di avvio. Tuttavia la messa in compatibilità non è un’operazione che dev’essere pianificata sin dall’inizio, si può infatti affrontare il problema in un secondo momento, quando il nostro sito Web (o il nostro servizio) è già online.

Normalmente si utilizzano due tecniche, o due approcci, per costruire un Web davvero accessibile:

• Graceful Degradation
• Progressive Enhancement

Graceful Degradation

Questa tecnica, utilizzata anche in ambiti diversi dal web design, parte dal presupposto di concentrarsi da subito nella realizzazione di un sito Web estremamente evoluto, facendo uso di tecniche e tecnologie all’avanguardia, senza preoccuparsi affatto di problemi di compatibilità e accessibilità. L’usabilità, invece, è - ovviamente - il primo ingrediente per definizione. Successivamente si procederà ad inserire tutte le caratteristiche per supportare browser e utenti che si trovano - di fatto - ai margini.

Si farà quindi uso di tabelle per formattare il nostro layout, senza esasperare l’uso di CSS e float, in modo da rispettare l’impaginazione del sito anche su browser di vecchia generazione. Dove compare Javascript si sfrutterà il Tag NOSCRIPT per fornire un’alternativa accessibile. Usare i Tag ALTTITLE dove richesto, ecc…

Graceful Degradation ha però dei limiti. Non prendere seriamente in considerazione i vari tipi di user agent (o utenti finali) sin dall’inizio, può avere brutte (a volte bruttissime) ripercussioni nei momenti successivi. Non sempre, infatti, è possibile aggiungere quegli artefizi e strumenti in grado di fornire un reale contenuto alternativo ai diversi utenti. L’esperienza dell’analista web developer/designer, in questo caso, gioca un ruolo fondamentale. Tuttavia un sito Web evolve nel tempo, si migliora, aggiunge funzionalità che potrebbero non essere risolvibili in altri modi, se non costringendo all’uso di una particolare tecnologia: la visione di un video (in Flash, in QuickTime o altro) è difficile - se non impossibile - da realizzare in HTML standard!

Progressive Enhancement

Questo approccio è probabilmente quello che personalmentre preferisco. Esso è l’esatto opposto del Graceful Degradation. Per chi ama l’uso dei fogli di stile è una tecnica già nota: si parte dalla struttura base, il semplice markup, e man mano si aggiungono tutte le caratteristiche evolute. Nell’ambito del layout, quindi dei CSS, è l’approccio usato per l’image replacement ovvero la sostituzione tramite style-sheet di un testo con un immagine (ci sono poi tecniche che sfruttano anche Flash o addirittura Ajax).

Di notevole interesse, in questo tipo di approccio, è la diffusione del cosiddetto Unobtrusive JavaScript: ovvero Javascript non intrusivo. Questa tecnica permette di migliorare la funzionalità di un sito Web sfruttando la capacità di manipolazione del DOM di Javascript. Inserendo in modo opportuno gli script Javascript nella pagina si può fare in modo da renderli trasparenti ai i browser che non supportano Javascript (o hanno disabilitato Javascript) ma funzionanti per gli altri.

Le caratteristiche di un Unobtrusive JavaScript sono:

• Migliora o modifica - NON implementa - caratteristiche già presenti
• Trasparente in caso di user agent che non supportano o che disabilitano Javascript

Il punto 1 è fondamentale per l’accessibilità, nello stesso modo dell’image replacement usato nei CSS. Un esempio è Snap che migliora la visibilità di un link. Snap è un classico esempio di Unobtrusive JavaScript: se Javascript è disabilitato il link è ancora presente e funzionante, tuttavia se Javascript è abilitato viene aggiunta la funzionalità di anteprima. Inoltre se non è possibile accedere a Javascript nessun messaggio viene mostrato: punto 2 - non intrusivo.

Altro esempio di Unobtrusive JavaScript ben realizzato è Lightbox JS che migliora gli slideshow delle immagini. Partendo da una serie di link (Tag <A>) con l’attributo rel propriamente impostato è in grado di visualizzare le immagini linkate in modo davvero accattivante!

Questa tecnica risulta estremamente versatile e permette un vero approccio Progressive Enhancement - e, senza esagerare, un vero approccio web2.0.

In questo scenario l’uso della libreria Prototype garantisce un facile accesso al DOM HTML permettendo di sovrascrivere e aggiungere funzionalità agli elementi di una pagina rendendoli più versatili.

Entrambe le tecniche, quindi, permettono di realizzare alla fine dei siti Web davvero accessibili. Di contro richiedono un’attenzione e un lavoro aggiuntivo che, alla fine, viene ripagato da una maggior quantità di visitatori! Io personalmente adotto la tecnica del Progressive Enhancement, per una questione puramente soggettiva e di abitudine. Scegliere tra le due tecniche può essere indifferente; l’esperienza, insieme al tipo di progetto che si deve sviluppare, giocono sicuramente un ruolo fondamentale.

Visto che un esempio vale più di mille parole, mi ripropongo quanto prima di mosrtare alcuni semplici estratti di codice davvero illuminati.

Post correlati

• Tutti i cloni di Lightbox in una matrice dinamica (7)
• Light Library: da Slimbox a Shadowbox, gallerie in Javascript (12)
• Light gallery: Lightview 2.0.0_rc1 (1)
• Web2.0: Gran Paradiso-Firefox 3.0 e Apollo (2)
• Web2.0: Adobe ci prova con Apollo? (2)