{"id":71,"date":"2010-06-08T10:54:52","date_gmt":"2010-06-08T08:54:52","guid":{"rendered":"https:\/\/alistapart.com\/it\/article\/web-design-reattivo\/"},"modified":"2010-06-08T10:54:52","modified_gmt":"2010-06-08T08:54:52","slug":"web-design-reattivo","status":"publish","type":"article","link":"https:\/\/alistapart.com\/it\/article\/web-design-reattivo\/","title":{"rendered":"Responsive Web Design"},"content":{"rendered":"
\n

Il controllo che i designer possono esercitare nella stampa, e che spesso desiderano anche nel web, \u00e8 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\u00e0. Ma prima di tutto, dobbiamo accettare il flusso ed il riflusso delle cose.<\/p>\n

John Allsopp<\/cite>, \u201cA Dao of Web Design<\/a>\u201d<\/address>\n<\/blockquote>\n

L’architetto inglese Christopher Wren una volta fece una battuta affermando che il suo settore \u201cmira all’Eternit\u00e0\u201d e c’\u00e8 qualcosa di affascinante in questa formula: a differenza del web, di cui spesso si ha l’impressione che aspiri alla prossima settimana, l’architettura \u00e8 una disciplina molto ben definita dalla sua stabilit\u00e0. Le fondamenta di una costruzione ne definiscono il suo ingombro, che definisce la sua struttura portante, che d\u00e0 forma alla facciata. Ogni fase del processo architetturale \u00e8 pi\u00f9 immutabile e pi\u00f9 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.<\/p>\n

Lavorare sul web, comunque, \u00e8 una questione totalmente differente. Il nostro lavoro \u00e8 definito dalla sua transitoriet\u00e0, 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\u00f2.<\/p>\n

Tuttavia il panorama sta cambiando, forse pi\u00f9 velocemente di quanto preferiremmo. Si stima che la navigazione internet mediante dispositivi mobili sopravanzer\u00e0 quella attraverso dispositivi desktop in un periodo che va dai tre<\/a> ai cinque anni<\/a>. Due delle tre console di gioco che dominano il mercato sono dotate di browser web (e uno di questi<\/a> \u00e8 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.<\/p>\n

Negli anni recenti, ho avuto sempre pi\u00f9 spesso a che fare con aziende che richiedevano \u201cun sito per iPhone\u201d come parte del loro progetto. \u00c8 una frase interessante: in apparenza, ovviamente, parla della qualit\u00e0 di WebKit come browser per dispositivi mobili, cos\u00ec come di un business case<\/a> che ci fa andare oltre il desktop. Ma come designer, penso che spesso tali richieste esplicite ci diano conforto, perch\u00e9 ci permettono di dividere in scomparti i problemi che ci si parano davanti. Possiamo confinare l’esperienza mobile su sottodomini<\/a> separati<\/a>, spazi distinti e separati dal \u201csito non-iPhone\u201d. Ma cosa verr\u00e0 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?<\/p>\n

\n

Fondamenta Flessibili<\/h2>\n

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

<\/a><\/p>\n

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.<\/p>\n<\/div>\n

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<\/a> 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\u00f9 piccole di 800\u00d7600, l’illustrazione dietro al logo viene presto tagliata, il testo di navigazione pu\u00f2 andare a capo in modo sconveniente e le immagini lungo il bordo inferiore divengono troppo appiccicate per apparire leggibili. E non \u00e8 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.<\/p>\n

In breve, il nostro design flessibile funziona abbastanza bene nel contesto centrato sul desktop per cui \u00e8 stato progettato, ma non \u00e8 ottimizzato per estendersi molto oltre questo.<\/p>\n<\/div>\n

\n

Diventare reattivi<\/h2>\n

Recentemente, una disciplina emergente chiamata \u201carchitettura reattiva<\/dfn>\u201d ha cominciato a chiedersi come gli spazi fisici possano reagire<\/em> alla presenza delle persone che li attraversano. Attraverso una combinazione di robotica incorporata e materiali di trazione, gli architetti stanno sperimentando con installazioni artistiche<\/a> e pareti in muratura<\/a> 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\u00e0 prodotto una \u201ctecnologia per vetri intelligenti\u201d che diventano opachi automaticamente<\/a> quando gli occupanti di una stanza raggiungo una certa soglia di densit\u00e0, dando cos\u00ec ulteriore privacy.<\/p>\n

Nel loro libro Interactive Architecture<\/cite>, Michael Fox e Miles Kemp descrivono questo approccio pi\u00f9 adattivo come un \u201csistema multiple-loop in cui qualcuno entra nella conversazione, uno scambio continuo e costruttivo di informazioni<\/em>.\u201d Enfatizzo io, poich\u00e9 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\u2014e dovrebbero\u2014 influenzarsi reciprocamente.<\/p>\n

Questo \u00e8 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\u00f9 flessibili, ma anche pi\u00f9 adattabili al media che li rende. In breve, dobbiamo fare pratica con il responsive web design<\/em>. Ma come?<\/p>\n<\/div>\n

\n

Vi presento la \u201cmedia query\u201d<\/h2>\n

Fin dai tempi di CSS 2.1<\/abbr>, i nostri fogli di stile hanno goduto, in qualche misura, della consapevolezza dell’esistenza di vari device attraverso i media types<\/dfn><\/a>. Se avete in qualche occasione scritto un foglio di stile per la stampa<\/a>, avete gi\u00e0 familiarit\u00e0 con il concetto:<\/p>\n

  media=\"screen\" \/>

\t  media=\"print\" \/>
  <\/code><\/pre>\n
Nella speranza di poter progettare qualcosa di pi\u00f9 che stampe di pagine ben formattate, la specifica CSS<\/abbr> ci ha fornito una collezione di media type accettabili<\/a>, 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<\/a> per molti media type, oppure ignorandoli totalmente.<\/p>\n
Grazie al cielo, il W3C<\/abbr> ha creato le media queries<\/dfn><\/a> come parte della specifica CSS3<\/abbr>, migliorando le possibilit\u00e0 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\u00f2, potremmo incorporare una query nell’attributo media<\/code> di un foglio di stile collegato.<\/p>\n
  media=\"screen and (max-device-width: 480px)\"
  href=\"shetland.css\" \/><\/code><\/pre>\n
La query contiene due componenti:<\/p>\n
    \n
  1. un media type (screen<\/code>),<\/li>\n
  2. l’effettiva query racchiusa tra parentesi, contenente una particolare media feature<\/dfn> (max-device-width<\/code>) da ispezionare, seguita dal valore target (480px<\/code>).<\/li>\n<\/ol>\n
    In italiano corrente, stiamo chiedendo al device se la sua risoluzione orizzontale (max-device-width<\/code>) \u00e8 uguale o minore di 480px<\/code>. Se questo test passa\u2014in altre parole, se stiamo vedendo il nostro lavoro su un device con uno schermo piccolo come l’iPhone\u2014allora il device caricher\u00e0 shetland.css<\/code>. Altrimenti, il link<\/code> \u00e8 ignorato in toto.<\/p>\n
    I designer hanno fatto esperimenti con layout coscienti della risoluzione in passato, per la maggior parte basandosi su soluzioni guidate da JS<\/abbr>, come l’eccellente script di Cameron Adams<\/a>. Ma la media query fornisce una moltitudine di features<\/a> che si estendono ben oltre la risoluzione dello schermo, ampliando enormemente la sfera di quello che pu\u00f2 essere testato con le nostre queries. Inoltre, si possono testare valori multipli di una propriet\u00e0 in una singola query, collegandoli insieme con la keyword and<\/code>:<\/p>\n
               media=\"screen and (max-device-width: 480px) and (resolution: 163dpi)\"
           href=\"shetland.css\" \/>
        <\/code>
      <\/pre>\n
    In aggiunta a ci\u00f2, non ci limitiamo ad incorporare le media queries nei nostri link<\/code>: possiamo includerle nel nostro CSS<\/abbr> sia come parte di una regola @media<\/code>:<\/p>\n
    \t@media screen and (max-device-width: 480px) {
      \t        .column {
        \t\t   float: none;
      \t\t}
    \t      }
    \t<\/code>
      <\/pre>\n
    sia come parte di una direttiva @import<\/code><\/p>\n
    @import url(\"shetland.css\") screen and (max-device-width: 480px);<\/code><\/pre>\n
    Tuttavia, in ciascun caso, l’effetto \u00e8 il medesimo: se il device passa il test posto dalla nostra media query, il CSS<\/abbr> adeguato viene applicato al nostro markup. Le media queries, in breve, sono dei commenti condizionali<\/a> 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.<\/p>\n<\/div>\n
    \n
    Adattarsi, reagire e risolvere<\/h2>\n
    Poniamo di nuovo l’attenzione sulle immagini alla base della nostra pagina. Nel loro layout di default, il CSS<\/abbr> adeguato attualmente \u00e8 cos\u00ec:<\/p>\n
        .figure {
                float: left;
      \t    margin: 0 3.317535545023696682% 1.5em 0;   \/* 21px \/ 633px *\/
      \t    width: 31.121642969984202211%;             \/* 197px \/ 633px *\/
    \t  }

    \t  li#f-mycroft, li#f-winter {
      \t    margin-right: 0;
    \t  }
        <\/code>
      <\/pre>\n
    Ho omesso numerose propriet\u00e0 tipografiche per concentrarmi solo sul layout: ciascun elemento .figure<\/code> \u00e8 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<\/code>). Questo funziona abbastanza bene, finch\u00e9 la viewport \u00e8 o notevolmente pi\u00f9 piccola o pi\u00f9 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.<\/p>\n
    Per prima cosa, linearizziamo la nostra pagina una volta che la viewport rientra sotto una certa soglia di risoluzione\u2014facciamo 600px<\/code>. Cos\u00ec, in fondo al nostro foglio di stile creiamo un nuovo blocco @media<\/code>, in questo modo:<\/p>\n
        @media screen and (max-width: 600px) {
      \t    .mast,
      \t    .intro,
    \t    .main,
      \t    .footer {
        \t       float: none;
        \t       width: auto;
      \t    }
    \t  }
         <\/code>
      <\/pre>\n
    Se andate a vedere la nostra pagina aggiornata<\/a> in un browser desktop moderno e riducete la dimensione della finestra sotto i 600px<\/code>, la media query disabiliter\u00e0 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\u00ec intelligentemente. Se introduciamo una nuova media query, possiamo alterare il loro layout di conseguenza:<\/p>\n
        @media screen and (max-width: 400px) {
                .figure,
      \t    li#f-mycroft {
        \t      margin-right: 3.317535545023696682%;    \/* 21px \/ 633px *\/
        \t      width: 48.341232227488151658%;          \/* 306px \/ 633px *\/
      \t    }

    \t    li#f-watson,
      \t    li#f-moriarty {
        \t      margin-right: 0;
      \t    }
    \t  }
         <\/code>
       <\/pre>\n
    <\/a><\/p>\n
    Le nostre figure possono cambiare in maniera reattiva il proprio layout per adattarsi meglio ai display pi\u00f9 piccoli<\/a>.<\/p>\n<\/div>\n
    Non badate alle percentuali sgradevoli: stiamo semplicemente ricalcolando le larghezze della griglia fluida<\/a> per far tornare il nuovo layout linearizzato. In breve, stiamo passando da un layout a tre colonne ad uno a due colonne<\/a>, quando la larghezza della viewport scende sotto i 400px<\/code>, rendendo le immagini pi\u00f9 prominenti.<\/p>\n
    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<\/a>:<\/p>\n
        @media screen and (min-width: 1300px) {
                 .figure,
                 li#f-mycroft {
                   margin-right: 3.317535545023696682%;    \/* 21px \/ 633px *\/
                   width: 13.902053712480252764%;          \/* 88px \/ 633px *\/
                 }
              }
        <\/code>
       <\/pre>\n
    Adesso le nostre immagini stanno bene in ciascun estremo del range delle risoluzioni<\/a>, avendo ottimizzato il loro layout affinch\u00e9 cambi a seconda della larghezza della finestra e della risoluzione del device.<\/p>\n
    <\/a><\/p>\n
    Specificando una maggiore min-width<\/code> in una nuova media query, possiamo spostare le nostre immagini su una singola riga<\/a>.<\/p>\n<\/div>\n
    Ma questo \u00e8 solo l’inizio. Lavorando a partire dalle media queries che abbiamo inserito nel nostro CSS<\/abbr>, possiamo alterare molto di pi\u00f9 del piazzamento di poche immagini: possiamo introdurre nuovi ed alternativi layout<\/a> in accordo con ciascun range di risoluzione, magari rendendo la navigazione pi\u00f9 prominente in una vista widescreen o riposizionandola sopra il logo nei display pi\u00f9 piccoli.<\/p>\n
    <\/a><\/p>\n
    Progettando in maniera reattiva, possiamo non solo linearizzare il nostro contenuto sui device pi\u00f9 piccoli, ma anche ottimizzare la sua presentazione su un certo range di display<\/a>.<\/p>\n<\/div>\n
    Tuttavia, il responsive design non \u00e8 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\u00f9 piccoli, essere maggiormente compatibili con la Legge di Fitts<\/a> 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<\/a> 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.<\/p>\n
    Alcune note tecniche<\/h3>\n
    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\u00ec come succede nei pi\u00f9 recenti browser per dispositivi mobili come Opera Mobile e mobile WebKit. Ovviamente, le versioni pi\u00f9 vecchie di questi browser desktop non supportanto le media queries, e, mentre Microsoft si \u00e8 impegnata a supportare le media queries in IE9<\/abbr><\/a>, Internet Explorer al momento non ne offre un’implementazione nativa.<\/p>\n
    Tuttavia, se siete interessati ad implementare il supporto per le media query nei legacy browser, c’\u00e8 una strada rivestita d’argento tinta di Javascript:<\/p>\n