L’importanza del miglioramento progressivo

Con l’avvento dei nuovi dispositivi disponibili sul mercato ci si è trovati di fronte ad un problema di non poca importanza per i designer ma non solo (anche i grafici e gli sviluppatori ne sono coinvolti): il problema di adattare il contenuto di una pagina web a tutti i dispositivi disponibili. Il che non è così semplice se pensiamo a quanti dispositivi sono oggi in circolazione, dalle marche sconosciute alle più famose, ognuno con la propria risoluzione e le proprie modalità di interazione.

Era già una tortura quando si aveva a che fare con quei quattro o cinque browser sui tre principali sistemi operativi tenendo conto delle risoluzioni di schermo standard del momento. Il layout liquido ci è venuto in aiuto risolvendo la maggior parte dei problemi, ma rimangono a volte alcune discrepanze non risolvibili o risolvibili solo con l’aiuto di JavaScript.

Ecco che siamo arrivati dunque alla fatidica domanda: il sito si deve vedere nello stesso modo su tutti i dispositivi? Se una volta forse la risposta era un tassativo “sì e non si discute” oggi è “no”. Perché dovrebbe essere tassativo, per un sito, avere la stessa visualizzazione per ogni tecnologia? Cambiano le modalità di interazione quindi cambia anche la struttura della pagina. Dopotutto un sito deve assolvere ad una principale funzione: rendere fruibili dei contenuti nel modo più chiaro e scorrevole possibile.

Questo pone l’accento su uno dei fondamentali principi del web design: “Content is king”, e su due tecniche, quella più indicata per raggiungere questo scopo che è il miglioramento progressivo (o progressive enhancement) e la sua controparte, la graceful degradation.

Realizzare una pagina in modo responsivo è un impiego di tempo dal quale però non si può più prescindere ormai. Avere un sito responsive non è più un plus ma un must. Ma è tanto più dispendioso, a mio avviso ma non solo, farlo con la tecnica della graceful degradation piuttosto che con il miglioramento progressivo. Il termine  graceful degradation indica che si parte da un contenuto ricco andando man mano a privarlo di parti per poterlo adattare ad una specifica risoluzione. Questo procedimento inverso rischia di far perdere il focus sui contenuti realmente importanti della pagina e adattare qualcosa, che a grandi risoluzioni occupava il suo bello spazio, ad uno, a volte, anche molto più piccolo, compromette tutto l’equilibrio e l’armonia della pagina.

Qual è dunque l’approccio giusto da utilizzare?

Deciso il contenuto della pagina, si impostano, sulla base di questo e non delle risoluzioni dei dispositivi, i vari breakpoint affinché le informazioni siano facilmente consultabili. Questo fa sì che non accadrà mai che a risoluzioni a volte trascurate come quelle che stanno a metà tra quella mobile e quella del tablet, o tra quella del tablet e quella desktop, siano poco curate e la struttura della pagina visibilmente rotta. Ci si svincola dai dispositivi e ci si concentra invece sul contenuto permettendo così di dover gestire solo pochi breakpoint, tagliati su misura sul sito stesso.

Stephen Hay nel suo libro Responsive Design workflow spiega come raggiungere questo obiettivo anche se può sembrare un procedimento lungo e non sempre attuabile, ma quello che conta è il concetto. Si parte da una pagina senza stili in cui si inserisce il contenuto nell’esatto ordine in cui si vuole che venga letto quindi creando un contenuto basato sulla priorità delle informazioni che non solo è utile per l’utente che deve usufruire di tali contenuti ma anche per i motori di ricerca, quindi per la SEO, le cui linee guida dicono di mettere più in alto i contenuti importanti ed inoltre anche per l’accessibilità, poichè gli screen reader, limitandosi a leggere il testo consecutivamente, arrivano così subito al nocciolo del discorso.

Questa pagina senza stili, nel quale quindi si avrà un flusso di contenuti verticale, diviso in blocchi a seconda di paragrafi, tipi di contenuto (come menu, barre laterali), etc.., è la base su cui partire a disegnare la grafica del sito iniziando dalla risoluzione più piccola, quindi potenzialmente quella mobile. Lavorando perciò con una pagina html statica e con i contenuti reali è immediatamente chiaro quanto sia leggibile un testo ad una data risoluzione e quanto ad un altra perché è sufficiente allargare la finestra del browser per scoprirlo (cosa che invece su Photoshop è molto più difficile da riprodurre in così breve tempo). Per cui se si parte, com’è convenzione, con una solo colonna su mobile per il testo (ma potrebbe valere anche per le immagini), per scoprire qual è il prossimo breakpoint, sarà sufficiente allargare gradualmente la finestra finchè non ci si rende conto che si può disporre ora testo o immagine su due colonne, oppure trasformare il menu da icone a testo, oppure da dropdown a menu in linea e così proseguendo verso risoluzioni maggiori dove magari il contenuto principale viene suddiviso in tre colonne e un potenziale slider di immagini passa da 2 a 4.

Così facendo è possibile identificare dei reali breakpoint su cui basare le grafiche che sono indipendenti dai dispositivi ma studiati ad hoc per il progetto in essere.

Non è poi così oneroso da realizzare, al di là delle tecniche che illustra Hay nel suo libro, che sono comunque interessanti da provare almeno una volta. L’unica nota, se vogliamo, dolente è che per farlo bisogna disporre dei contenuti e si sa che non sempre durante la realizzazione del progetto si hanno già tutti. Ma questo è in realtà il nocciolo della questione: si può creare la grafica di qualcosa supponendo di avere contenuti che poi nella realtà non si avranno e si dovrà così o ridisegnare alcune parti (quindi doppio lavoro) o riempirle con del testo segnaposto inventato (quindi poco ottimizzato) che il più delle volte risulta essere ridondante proprio perché non era necessario? O non è forse meglio disegnare fin da subito la grafica per un contenuto già deciso e approvato, quindi già ottimizzato sia come reale contenuto che come SEO?

Io propendo per la seconda perché a rigor di logica è anche la più sensata.

Una cosa che questo approccio evidenzia e che è un aspetto fondamentale, anche se non sempre scontato, è che il grafico che disegna per il web deve conoscere il web, ovvero aver dimestichezza con l’HTML, averci quanto meno lavorato qualche volta e sapere cosa accade ad una pagina quando visionata su desktop o sul dispositivi mobili e touch ma soprattutto sapere cosa è possibile fare e cosa no. Perché purtroppo ci sono limitazioni sul web che la grafica per stampa non incontra, per contro ci sono interazioni sul web che la grafica per stampa non potrai mai riprodurre (tranne i giornali di Harry Potter).

Si pensa che disegnare con la tecnica mobile first sia dispendioso ma non farlo lo è altrettanto. Perché sono pochi quelli che disegnano considerando tutte le casistiche, direi nessuno. Il più delle volte si viene forniti di una grafica per il desktop e di una per il mobile tralasciando completamente tutte le risoluzioni intermedie a svantaggio del tablet che spesso si trova in un limbo a metà tra mobile e desktop per il quale il front end developer si deve inventare una soluzione che non distrugga quanto già fatto per il desktop e il mobile.

Risulta così evidente che la smania di certi grafici per il pixel perfect venga meno ad un certo punto proprio perché sul web non si hanno misure fisse ma fluide (per esempio vengono spesso usati gli EM a vantaggio dei PX), cangianti in ogni momento per via delle numerose condizioni che si possono creare.

Ma questa è un’altra storia e si dovrà raccontare un’altra volta.