Questa è la traduzione dell'articolo Understanding Progressive Enhancement di Aaron Gustafson pubblicato originariamente su A List Apart il 7 Ottobre 2008. La traduzione viene qui presentata con il consenso dell'editore e dell'autore.
Sin dal 1994 la comunità degli sviluppatori web si occupa e discute di graceful degradation. È un'idea che viene dal mondo dell'ingegneria e che può essere così sintetizzata: fornire ai browser più recenti e migliori l'esperienza di un pasto completo dall'antipasto al dessert, lasciare qualche briciola ai poveretti che magari sono così sfortunati da usare ancora Netscape 4. Ha funzionato, certo. Ma è una visione che non corrispondeva a quella promossa da Tim Berners Lee a favore di un web universalmente accessibile.
Circa dieci anni dopo, alcuni ragazzi intelligenti hanno iniziato a mettere in discussione l'idea di graceful degradation e hanno evidenziato quanti limiti avesse sotto diversi aspetti. Occupandosi di disponibilità dei contenuti, accessibilità generale e capacità dei dispositivi mobili, hanno escogitato un nuovo approccio allo sviluppo web, un metodo che aveva il suo focus sul contenuto e che faceva molto più che semplicemente fornire un supporto minimale ai dispositivi più datati.
Alla SXSW del 2003 Steve Cahampeon e Nick Finck mostrarono una presentazione intitolata Inclusive Web Design For the Future. In quell'occasione rilasciarono anche una sorta di guida a questo nuovo metodo di approcciare lo sviluppo web. Steve Champeon trovò anche un nome: progressive enhancement.
Una sottile differenza
Nel caso vi stesse chiedendo in che cosa il progressive enhancement è diverso dalla graceful degradation, ecco cosa ho da dirvi: è una questione di prospettiva. Entrambi gli approcci tengono in considerazione come un sito possa funzionare bene su una varietà di dispositivi. Il punto fondamentale riguarda il dove essi concentrano il proprio focus e come ciò ha effetti sul flusso di lavoro.
La prospettiva della graceful degradation
La graceful degradation è focalizzata sulla realizzazione di un sito per i browser più capaci e avanzati. Il test nei browser più datati o meno capaci avviene in genere nell'ultimo quarto del ciclo di sviluppo ed è spesso un'operazione limitata alle versioni precedenti l'ultima dei principali browser (IE, Mozilla, etc).
Secondo questo paradigma, i browser più vecchi offrono un'esperienza più povera ma comunque accettabile. Possono essere apportate piccole modifiche di correzione per aggiustare la situazione su un browser particolare. Dal momento che non rappresentano il focus principale, viene prestata poca attenzione alla correzione degli errori che vadano al di là di quelli più macroscopici.
La prospettiva del progressive enhancement
Il progressive enhancement si concentra sul contenuto. Notate la differenza: non ho proprio menzionato i browser.
Il contenuto è la ragione prima per cui creiamo un sito web. Alcuni siti lo distribuiscono, altri ancora lo aggregano, altri ancora lo richiedono agli utenti, altri lo manipolano e alcuni fanno tutte queste cose: tutti i siti però richiedono la presenza di contenuti. Ecco perché il progressive enhancement rappresenta un paradigma più appropriato. È per questo che Yahoo! lo ha adottato e usato per creare la strategia del Graded Browser Support.
Come funziona?
Entrare nel punto di vista del progressive enhancement è piuttosto semplice: pensate dal contenuto all'esterno. Il contenuto forma la base solida intorno a cui costruite i vostri stili e le vostre interazioni. Se vi piacciono certe caramelle, pensate al progressive enhancement come ad un Peanut M&M:
Iniziate con la nocciola del contenuto, marcato con codice (X)HTML semantico e ricco. Ricoprite questo contenuto con uno strato di buon CSS. Infine, aggiungete JavaScript come se fosse una bellissima copertura in caramello per rendere il tutto più buono (ed evitare che vi si sciolga nelle mani).
Se avete familiarità con il mantra del movimento dei web standard (separazione, separazione, separazione), tutto ciò ha un senso. Lo sviluppo basato sugli standard web è stato spesso paragonato ad una sfogliatina fatta di tanti strati sovrapposti. Io preferisco l'analogia con i Peanut M&M perché in essi i livelli superiori avvolgono completamente la parte centrale, così come stili e script avvolgono i nostri contenuti.
Se vi soffermerete ancora un po' sulla mia analogia con il cibo (spero di non farvi venire fame), vi spiegherò perché questo approccio è migliore e come i vari livelli interagiscono nel contesto di questo paradigma.
La nocciola
Ad alcune persone piacciono le nocciole. Alcuni preferiscono di fatto le nocciole ai Peanut M&M. Allo stesso modo, alcuni (pensate per esempio agli spider dei motori di ricerca) vogliono solo e soltanto il contenuto.
Poi ci sono persone che non possono mangiare gli strati che si trovano sopra la nocciola (pensate per esempio ai diabetici). Come questi ultimi, le persone che usano dispositivi mobili o browser datati potrebbero non essere in grado di visualizzare al meglio i vostri splendidi stili o interagire con la vostra fantastica interfaccia basata su Ajax.
Assicurandovi che il vostro markup veicoli il più alto livello possibile di dettaglio sui contenuti sarete in grado di offrire un'esperienza di base a questi utenti.
Lo strato di cioccolato
Successivamente, potrete delicatamente immergere il contenuto in un caldo e dolce bagno di CSS. Ma prima di arrivare alla copertura di caramello ci sono alcune considerazioni da fare.
Ci sono persone che amano le nocciole ricoperte di cioccolato. Queste persone sono come un livello medio di utenti che possono contare su un qualche livello di supporto dei CSS, ma non su complesse interazioni Javascript. Magari lavorano per una società dove gli addetti alla sicurezza del reparto IT hanno una specie di fobia per gli script. Per queste persone Javascript potrebbe essere del tutto disattivato.
Queste persone devono essere comunque tenute in considerazione. Ci sono molti metodi basati sul progressive enhancement che consentono di applicare stili al vostro contenuto: sarà l'argomento del secondo articolo di questa serie.
La copertura di caramello
Infine, potete aggiungere al mix un po' di Javascript. Con le potenzialità che offre in termini di interazione, come per la sua abilità di manipolare gli strati del contenuto e della presentazione, Javascript è davvero l'ingrediente che può trasformare un sito in un'esperienza.
Non sono sicuro di come lo strato di caramello esterno sia aggiunto ad un M&M, ma aggiungere interattività e funzionalità basate su Javascript al vostro sito è semplice e magnifico quando pensate in termini di progressive enhancement. E, allo stesso modo in cui i Peanut M&M sono disponibili in vari colori, l'esperienza basata su Javascript può variare in base alla capacità del browser o del dispositivo che tenta di usarlo.
Come forse sapete, questo approccio di sviluppo prende il nome di Javascript non intrusivo. Parlerò di queste tecniche nel terzo articolo della serie.
Mettere tutto insieme
Sviluppare con il progressive enhancement è attualmente molto semplice una volta che si siano compresi i concetti di base e si inizi a mettere tutto in pratica. Forse è ancora più semplice che fare una caramella. Nei prossimi articoli della serie tenterò di migliorare le vostre abilità relativamente a CSS e Javascript, mostrandovi come tutto quanto detto qui si trasforma in codice.
