Responsive Web Design

Il controllo che i designer possono esercitare nella stampa, e che spesso desiderano anche nel web, è semplicemente una funzione dei limiti della pagina stampata. Dovremmo accettare l’idea che il web non ha gli stessi limiti e pertanto progettare avendo in mente la sua flessibilità. Ma prima di tutto, dobbiamo accettare il flusso ed il riflusso delle cose.

L’articolo prosegue sotto
John Allsopp, “A Dao of Web Design

L’architetto inglese Christopher Wren una volta fece una battuta affermando che il suo settore “mira all’Eternità” e c’è qualcosa di affascinante in questa formula: a differenza del web, di cui spesso si ha l’impressione che aspiri alla prossima settimana, l’architettura è una disciplina molto ben definita dalla sua stabilità. Le fondamenta di una costruzione ne definiscono il suo ingombro, che definisce la sua struttura portante, che dà forma alla facciata. Ogni fase del processo architetturale è più immutabile e più costante rispetto alla precedente. Le decisioni creative danno quasi letteralmente forma ad uno spazio fisico, definendo il modo in cui le persone si muovono attraverso i suoi confini per decenni o addirittura secoli.

Lavorare sul web, comunque, è una questione totalmente differente. Il nostro lavoro è definito dalla sua transitorietà, spesso modificato o sostituito nel giro di un anno o due. Larghezze delle finestre inconsistenti, differenti risoluzioni dei monitor, preferenze degli utenti ed i font installati dai nostri utenti sono solo alcune delle cose intangibili che negoziamo quando pubblichiamo il nostro lavoro: nel corso degli anni, siamo diventati incredibilmente esperti nel fare ciò.

Tuttavia il panorama sta cambiando, forse più velocemente di quanto preferiremmo. Si stima che la navigazione internet mediante dispositivi mobili sopravanzerà quella attraverso dispositivi desktop in un periodo che va dai tre ai cinque anni. Due delle tre console di gioco che dominano il mercato sono dotate di browser web (e uno di questi è di tutto rispetto). Dobbiamo progettare per i mouse e le tastiere, per i tastierini T9, per i controller di gioco handheld, per le interfacce touch. Per farla breve, ci troviamo di fronte ad un numero maggiore di device, di modi di input e di browser di quelli a cui siamo stati abituati finora.

Negli anni recenti, ho avuto sempre più spesso a che fare con aziende che richiedevano “un sito per iPhone” come parte del loro progetto. È una frase interessante: in apparenza, ovviamente, parla della qualità di WebKit come browser per dispositivi mobili, così come di un business case che ci fa andare oltre il desktop. Ma come designer, penso che spesso tali richieste esplicite ci diano conforto, perché ci permettono di dividere in scomparti i problemi che ci si parano davanti. Possiamo confinare l’esperienza mobile su sottodomini separati, spazi distinti e separati dal “sito non-iPhone”. Ma cosa verrà dopo? Un sito iPad? Un sito per N90? Possiamo davvero continuare a impegnarci a supportare qualunque nuovo user agent con la sua esperienza su misura? Ad un certo punto, questo comincia a sembrare un gioco privo di senso. Ma come possiamo noi ed i nostri progetti adattarci a questa situazione?

Fondamenta Flessibili#section1

Consideriamo un progetto di esempio. Ho creato una semplice pagina per un magazine ipotetico; è un layout semplice a due colonne costruito su una griglia fluida [fluid grid, ndr], con qualche immagine flessibile qua e là. Essendo io un sostenitore da molto tempo dei layout non fissi, ho creduto per molto tempo che fossero “a prova di futuro” semplicemente perché erano agnostici rispetto al layout. E, in una certa misura, questo è vero: i design flessibili non fanno assunzioni riguardo alla larghezza della finestra del browser e si adattano tranquillamente ai device che hanno le modalità di visualizzazione orizzontale e verticale.

Le immagini giganti sono giganti. Il nostro layout, per quanto flessibile, non risponde bene ai cambi di risoluzione o alle variazioni di grandezza del viewport.

Tuttavia, nessun design, flessibile o fluido che sia, si scala in maniera invisibile oltre il contesto per cui era stato originariamente progettato. Il progetto d’esempio si scala perfettamente a seconda del ridimensionamento della finestra del browser, ma a basse risoluzioni appaiono subito dei punti di rottura. Quando lo si visualizza in viewport più piccole di 800×600, l’illustrazione dietro al logo viene presto tagliata, il testo di navigazione può andare a capo in modo sconveniente e le immagini lungo il bordo inferiore divengono troppo appiccicate per apparire leggibili. E non è solo il lato inferiore dello spettro della risoluzione ad essere interessato: quando si guarda questo design su un grande monitor, le immagini diventano presto ingombranti per le loro dimensioni, riempendo il contesto circostante.

In breve, il nostro design flessibile funziona abbastanza bene nel contesto centrato sul desktop per cui è stato progettato, ma non è ottimizzato per estendersi molto oltre questo.

Diventare reattivi#section2

Recentemente, una disciplina emergente chiamata “architettura reattiva” ha cominciato a chiedersi come gli spazi fisici possano reagire alla presenza delle persone che li attraversano. Attraverso una combinazione di robotica incorporata e materiali di trazione, gli architetti stanno sperimentando con installazioni artistiche e pareti in muratura che si piegano, flettono ed espandono all’avvicinarsi della gente ad esse. I sensori di movimento possono essere accoppiati con i sistemi di controllo del clima per regolare la temperatura di una stanza e l’illuminazione dell’ambiente a seconda di quanta gente vi sia al suo interno. Ci sono aziende che hanno già prodotto una “tecnologia per vetri intelligenti” che diventano opachi automaticamente quando gli occupanti di una stanza raggiungo una certa soglia di densità, dando così ulteriore privacy.

Nel loro libro Interactive Architecture, Michael Fox e Miles Kemp descrivono questo approccio più adattivo come un “sistema multiple-loop in cui qualcuno entra nella conversazione, uno scambio continuo e costruttivo di informazioni.” Enfatizzo io, poiché ritengo che ci sia una sottile ma forte distinzione: piuttosto che creare spazi immutabili, che non cambiano per definire una particolare esperienza, suggeriscono che gli abitanti e la struttura possono—e dovrebbero— influenzarsi reciprocamente.

Questo è il nostro futuro. Piuttosto che creare design sconnessi per un numero sempre crescente di device web, dovremmo trattarli come aspetti della stessa esperienza. Possiamo disegnare per un’esperienza visiva ottimale, ma incorporare le tecnologie basate sugli standard all’interno dei nostri design per renderli non solo più flessibili, ma anche più adattabili al media che li rende. In breve, dobbiamo fare pratica con il responsive web design. Ma come?

Vi presento la “media query”#section3

Fin dai tempi di CSS 2.1, i nostri fogli di stile hanno goduto, in qualche misura, della consapevolezza dell’esistenza di vari device attraverso i media types. Se avete in qualche occasione scritto un foglio di stile per la stampa, avete già familiarità con il concetto:

  media="screen" />

media="print" />

Nella speranza di poter progettare qualcosa di più che stampe di pagine ben formattate, la specifica CSS ci ha fornito una collezione di media type accettabili, ciascuno pensato per avere come obiettivo una specifica classe di device web-ready. Ma la maggior parte dei browser e dei device non ha mai accolto in pieno lo spirito della specifica, lasciando un’implementazione imperfetta per molti media type, oppure ignorandoli totalmente.

Grazie al cielo, il W3C ha creato le media queries come parte della specifica CSS3, migliorando le possibilità dei media types. Una media query ci permette di avere come obiettivo non solo certe classi di device, ma di ispezionare per davvero le caratteristiche del device che rende il nostro lavoro. Ad esempio, facendo seguito alla recente ascesa di WebKit mobile, le media queries sono diventate una tecnica client-side popolare per inviare un foglio di stile su misura agli iPhone, ai telefoni Android e agli altri generi di telefono. Per fare ciò, potremmo incorporare una query nell’attributo media di un foglio di stile collegato.

  media="screen and (max-device-width: 480px)"
href="shetland.css" />

La query contiene due componenti:

  1. un media type (screen),
  2. l’effettiva query racchiusa tra parentesi, contenente una particolare media feature (max-device-width) da ispezionare, seguita dal valore target (480px).

In italiano corrente, stiamo chiedendo al device se la sua risoluzione orizzontale (max-device-width) è uguale o minore di 480px. Se questo test passa—in altre parole, se stiamo vedendo il nostro lavoro su un device con uno schermo piccolo come l’iPhone—allora il device caricherà shetland.css. Altrimenti, il link è ignorato in toto.

I designer hanno fatto esperimenti con layout coscienti della risoluzione in passato, per la maggior parte basandosi su soluzioni guidate da JS, come l’eccellente script di Cameron Adams. Ma la media query fornisce una moltitudine di features che si estendono ben oltre la risoluzione dello schermo, ampliando enormemente la sfera di quello che può essere testato con le nostre queries. Inoltre, si possono testare valori multipli di una proprietà in una singola query, collegandoli insieme con la keyword and:

           media="screen and (max-device-width: 480px) and (resolution: 163dpi)"
href="shetland.css" />

In aggiunta a ciò, non ci limitiamo ad incorporare le media queries nei nostri link: possiamo includerle nel nostro CSS sia come parte di una regola @media:

	@media screen and (max-device-width: 480px) {
.column {
float: none;
}
}

sia come parte di una direttiva @import

@import url("shetland.css") screen and (max-device-width: 480px);

Tuttavia, in ciascun caso, l’effetto è il medesimo: se il device passa il test posto dalla nostra media query, il CSS adeguato viene applicato al nostro markup. Le media queries, in breve, sono dei commenti condizionali per noi altri: piuttosto che avere come target una specifica versione di uno specifico browser, possiamo correggere chirurgicamente dei problemi nel nostro layout al suo scalarsi oltre la sua iniziale ed ideale risoluzione.

Adattarsi, reagire e risolvere#section4

Poniamo di nuovo l’attenzione sulle immagini alla base della nostra pagina. Nel loro layout di default, il CSS adeguato attualmente è così:

    .figure {
float: left;
margin: 0 3.317535545023696682% 1.5em 0; /* 21px / 633px */
width: 31.121642969984202211%; /* 197px / 633px */
}

li#f-mycroft, li#f-winter {
margin-right: 0;
}

Ho omesso numerose proprietà tipografiche per concentrarmi solo sul layout: ciascun elemento .figure è di dimensione circa un terzo della colonna che la contiene, con il margine destro messo a zero per ciascuna delle due figure alla fine di ciascuna riga (li#f-mycroft, li#f-winter). Questo funziona abbastanza bene, finché la viewport è o notevolmente più piccola o più grande che nella nostra grafica originale. Con le media queries, possiamo applicare aggiustamenti puntigliosi specifici per ciascuna risoluzione, adattando il nostro design a rispondere meglio ai cambiamenti nella visualizzazione.

Per prima cosa, linearizziamo la nostra pagina una volta che la viewport rientra sotto una certa soglia di risoluzione—facciamo 600px. Così, in fondo al nostro foglio di stile creiamo un nuovo blocco @media, in questo modo:

    @media screen and (max-width: 600px) {
.mast,
.intro,
.main,
.footer {
float: none;
width: auto;
}
}

Se andate a vedere la nostra pagina aggiornata in un browser desktop moderno e riducete la dimensione della finestra sotto i 600px, la media query disabiliterà i float negli elementi maggiori del design, impilando ciascun blocco uno sull’altro nel flusso del documento. Quindi, il nostro design miniaturizzato sta prendendo forma in maniera carina, ma le immagini non si riducono ancora così intelligentemente. Se introduciamo una nuova media query, possiamo alterare il loro layout di conseguenza:

    @media screen and (max-width: 400px) {
.figure,
li#f-mycroft {
margin-right: 3.317535545023696682%; /* 21px / 633px */
width: 48.341232227488151658%; /* 306px / 633px */
}

li#f-watson,
li#f-moriarty {
margin-right: 0;
}
}

Le nostre figure possono cambiare in maniera reattiva il proprio layout per adattarsi meglio ai display più piccoli.

Non badate alle percentuali sgradevoli: stiamo semplicemente ricalcolando le larghezze della griglia fluida per far tornare il nuovo layout linearizzato. In breve, stiamo passando da un layout a tre colonne ad uno a due colonne, quando la larghezza della viewport scende sotto i 400px, rendendo le immagini più prominenti.

In effetti, potremmo usare lo stesso approccio per i display con schermi molto grandi. Per le grandi risoluzioni, possiamo adottare un piazzamento di sei immagini in orizzontale, mettendole tutte su una stessa riga:

    @media screen and (min-width: 1300px) {
.figure,
li#f-mycroft {
margin-right: 3.317535545023696682%; /* 21px / 633px */
width: 13.902053712480252764%; /* 88px / 633px */
}
}

Adesso le nostre immagini stanno bene in ciascun estremo del range delle risoluzioni, avendo ottimizzato il loro layout affinché cambi a seconda della larghezza della finestra e della risoluzione del device.

Specificando una maggiore min-width in una nuova media query, possiamo spostare le nostre immagini su una singola riga.

Ma questo è solo l’inizio. Lavorando a partire dalle media queries che abbiamo inserito nel nostro CSS, possiamo alterare molto di più del piazzamento di poche immagini: possiamo introdurre nuovi ed alternativi layout in accordo con ciascun range di risoluzione, magari rendendo la navigazione più prominente in una vista widescreen o riposizionandola sopra il logo nei display più piccoli.

Progettando in maniera reattiva, possiamo non solo linearizzare il nostro contenuto sui device più piccoli, ma anche ottimizzare la sua presentazione su un certo range di display.

Tuttavia, il responsive design non è limitato ai cambi di layout. Le media queries ci permettono di mettere in atto alcune ottimizzazioni incredibili quando le nostre pagine si trasformano: possiamo aumentare l’area target dei link per gli schermi più piccoli, essere maggiormente compatibili con la Legge di Fitts sui device touch, mostrare o nascondere selettivamente gli elementi che potrebbero migliorare la navigazione di una pagina, possiamo persino mettere in atto il responsive typesetting per alterare gradualmente la dimensione e l’interlinea addizionale del nostro testo, ottimizzando l’esperienza di lettura a seconda del display su cui viene visualizzato.

Alcune note tecniche#section5

Si noti che le media queries godono di un supporto incredibilmente robusto tra i browser moderni. I browser desktop come Safari 3+, Chrome, Firefox 3.5+ e Opera 7+ offrono supporto nativo per il parsing delle media queries, così come succede nei più recenti browser per dispositivi mobili come Opera Mobile e mobile WebKit. Ovviamente, le versioni più vecchie di questi browser desktop non supportanto le media queries, e, mentre Microsoft si è impegnata a supportare le media queries in IE9, Internet Explorer al momento non ne offre un’implementazione nativa.

Tuttavia, se siete interessati ad implementare il supporto per le media query nei legacy browser, c’è una strada rivestita d’argento tinta di Javascript:

  • Un plugin jQuery del 2007 offre un supporto per le media query piuttosto limitato, implementando solo le proprietà dei media min-width e max-width quando sono attaccate ad elementi link separati
  • Più recentemente è stata realizzata css3-mediaqueries.js, una libreria che promette di far fare il parsing, testare ed applicare in maniera trasparente le Media Queries di CSS3 a IE 5+, Firefox 1+ and Safari 2 quando sono incluse mediante i blocchi @media. Nonostante sia parecchio in release 1.0, l’ho personalmente trovata piuttosto robusta e mi sono riproposto di seguirne lo sviluppo.

Ma se usare JavaScript non vi affascina, è perfettamente comprensibile. Tuttavia, questo rinforza l’opzione di costruire il proprio layout basandosi su una griglia flessibile, assicurandovi che il design goda di un po’ di flessibilità nei browser e nei devices che non utilizzano le media queries.

Come andare avanti#section6

Griglie fluide, immagini flessibili e media queries sono i tre ingredienti tecnici per il responsive web design, che però richiede anche un modo diverso di pensare. Piuttosto che mettere in quarantena il nostro contenuto in esperienze disparate e per specifici device, possiamo usare le media query per mettere in atto il progressive enhancement sul nostro lavoro all’interno di diversi contesti di visualizzazione. Ciò non vuol dire che non vi sia un business case per siti separati che si indirizzano a specifici device: ad esempio, se gli scopi dell’utente per il vostro sito mobile sono molto più limitati come sfera d’azione rispetto al suo equivalente desktop, allora dare un contenuto diverso a ciascuna versione può essere l’approccio migliore.

Ma questo modo di pensare al design non deve per forza essere il nostro default. Ora più che mai, ci troviamo a progettare dei lavori che verranno visti attraverso una quantità di diverse esperienze. Il responsive web design ci offre un modo per andare avanti, finalmente permettendoci di “progettare per il flusso ed il riflusso delle cose”.

Illustrazioni {carlok}

4 Reader Comments

Rispondi a Valeria Annulla risposta

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *

Altro da ALA

Webwaste

In questo estratto da World Wide Waste, Gerry McGovern esamina l'impatto ambientale di siti web pieni zeppi di asset inutili. Digital is physical. Sembra economico e gratis ma non lo è: ci costa la Terra.
Industry