Con la lezione precedente dovrebbe essere chiaro che l’obiettivo che ci poniamo con il Responsive Web Design è quello di permettere a chiunque di consultare il sito web realizzato indipendentemente dal dispositivo utilizzato.
Abbiamo già dimostrato che nel tempo gli accessi da desktop sono diminuiti fino ad arrivare al fatidico 2013 in cui gli accessi da mobile hanno superato quelli del computer fisso portando a oggi circa 2 miliardi di persone che utilizzano lo smartphone o il tablet per consultare i siti web preferiti.
Oltre ai problemi di dimensioni e di assenza del mouse dobbiamo tener conto anche di un altro fattore molto più importante, la velocità con la quale questi dispositivi si connettono su Internet.
Fino a qualche anno fa era pratica comune quella di poter utilizzare delle immagini per creare i nostri bottoni e accattivanti sfondi, ma come abbiamo già affrontato all’interno del corso su Sass questo rallenta inevitabilmente il caricamento del nostro sito web.
Oltre a dover impiegare più tempo per scaricare le singole immagini, questa pratica forza il nostro browser ad aprire una nuova connessione HTTP per ogni elemento e dato che ciascuna di queste ha dei tempi morti che non possiamo eliminare (generalmente si parla di 200ms a chiamata), il nostro sito risulta più lento del dovuto.
Ti ho già presentato la tecnica degli Sprite CSS e questo non è il momento di affrontare nuovamente questo argomento, la cosa più interessante che dovresti sapere è che ad oggi per la costruzione degli elementi del layout si cerca di limitare al minimo l’uso delle immagini.
Grazie alle nuove proprietà CSS siamo in grado di creare delle vere e proprie forme e con i web fonts siamo in grado di richiamare facilmente delle icone andando a dichiarare un codice HTML, niente immagini.
In questo corso vedremo alcuni di questi elementi e scopriremo nel dettaglio come sia possibile crearne di propri ma la cosa fondamentale sulla quale ti vorrei far riflettere è la possibilità di escludere gran parte delle immagini per lasciare che sia il browser a disegnare per noi questi elementi.
Basta guardare i bottoni presenti su skillsAndMore, sono forme semplici ne sono sicuro, ma hai notato l’effetto 3D che è stato realizzato?
Pensa che fino a non molto tempo fa avremmo dovuto utilizzare un’immagine di sfondo per creare un effetto del genere e invece oggi basta semplicemente un border-bottom impostato a un colore più scuro e una leggera transizione per dare l’impressione che il plugin venga premuto al passaggio del mouse.
Purtroppo questo effetto perde qualsiasi significato quando ci spostiamo su device touch che non hanno questo componente e anche se vedremo alcune soluzioni che si possono applicare, la cosa importante è sempre una: mettere in evidenza il link. Utilizzando il mouse è molto semplice pensare che basta aggiungere una sottolineatura e trasformare il cursore in una manina per far capire che l’elemento sul quale ci troviamo è un link, ma con un dispositivo touch tutti questi indizi vengono annullati e bisogna assicurarci che i link presenti nella pagina siano facili da distinguere.
Questa è soltanto una delle considerazioni che devono essere prese in considerazione quando si sviluppa un sito web che deve essere responsive, ma se continuiamo a pensare a quali elementi togliere da un layout creato appositamente per le versioni desktop per adattarlo alle versioni ridotte stiamo facendo qualcosa di sbagliato.
Un primo approccio al Mobile First
Sono sicuro che se hai già sviluppato dei siti web, pensare al desktop è la cosa che risulta più naturale, in fin dei conti il desktop è anche lo strumento all’interno del quale creiamo e testiamo i nostri siti web, ma con i dati che ti ho fornito precedentemente adesso sai che ci sono 2 miliardi di persone che non utilizzano spesso questo dispositivo.
Essere in grado di adattare un sito web e i suoi contenuti a schermi di piccole dimensioni è una cosa fondamentale per quanto riguarda la creazione di un web moderno, ormai dovrebbe essere chiaro.
La cosa che forse non è molto chiara è il peso che un sito ottimizzato per il desktop possa avere rispetto a un sito ottimizzato per il mobile generalmente è più grande.
Come ti puoi immaginare sul desktop abbiamo la possibilità di avere più pixel, caricare immagini di dimensioni più grandi e anche (in teoria) una banda dati più larga in grado di scaricare più dati in minor tempo.
Tutti questi fattori ci permettono di creare un sito web più carico dal punto di vista dei contenuti grafici e personalizzazioni JavaScript.
Purtroppo non possiamo dire la stessa cosa dei dispositivi mobile.
I processori grafici e la RAM dei dispositivi mobile sono generalmente molto inferiori rispetto a quelli che troviamo in un qualsiasi computer e questo comporta molto spesso dei rallentamenti nella fruibilità del sito che non sono neanche dovuti direttamente alla già scarsa velocità di download. Semplicemente i cellulari (e i tablet) si sforzano molto di più a creare le stesse animazioni o visualizzare le stesse immagini rispetto a un computer desktop.
Messo in luce questi vari aspetti cerchiamo adesso di capire perché tradurre un layout pensato per il desktop in uno per il mobile è un grosso errore.
Come dicevo precedentemente, il layout desktop è molto più ricco di informazioni e se partiamo da questo per togliere degli elementi non facciamo altro che caricare comunque il nostro browser di informazioni che non verranno utilizzate, ma che comunque verranno caricate inutilmente.
Perché succede una cosa del genere?
Per prima cosa cerchiamo di chiarire come funziona la scrittura di codice CSS per applicare le regole del Responsive Web Design.
Come dovresti sapere le regole CSS utilizzano i selettori per identificare quali elementi devono essere personalizzati dalle proprietà inserite all’interno della regola. È possibile sovrascrivere queste regole utilizzando dei selettori più specifici o sfruttando anche la caratteristica a cascata dei nostri fogli di stile.
Se non ti ricordi, la cascata di un CSS, significa che se al rigo 1 inserisco la regola #box{ background-color: red; } e al rigo 32 inserisco la regola #box{ background-color: green; } il nostro elemento avrà un colore di sfondo verde perché questo è stato dichiarato successivamente al primo e visto che i selettori hanno la stessa specificità, la cascata fa caricare l’ultimo valore dichiarato.
La stessa logica della cascata si può utilizzare nella creazione di siti web responsive.
Esiste una regola, la media query che scopriremo a breve, che permette di specificare una determinata risoluzione per applicare le regole CSS e anche in questo caso la funzionalità della cascata funziona perfettamente.
#box{
background-color: red;
}
/*
Le regole verranno applicate alle risoluzioni
minori di 800px
*/
@media (max-width: 800px){
#box{
background-color: green;
}
}La prima cosa che vorrei mettere in chiaro, anche se potrebbe essere ovvia, è che la stringa che inizia con @media è, in parte, inventata perché il nostro browser non è in grado di comprendere delle condizioni scritte in italiano.
Io ho inserito massima risoluzione 800px per farti capire che il codice che si trova al suo interno verrà applicato agli schermi di dimensioni inferiori agli 800px; quindi andiamo a mirare sia tablet che smartphone.
Quella che vedi è una classica logica Desktop First, una delle più sbagliate. Basta leggere questo piccolo blocco di codice per capire che con questo approccio si rischia soltanto di creare un gran numero di proprietà per personalizzare il layout a schermi ridotti.
Capisco che probabilmente può essere un approccio utile quando ci troviamo di fronte alla richiesta di rendere responsive un sito web statico, ma al tempo stesso ecco perché è una tecnica che si dovrebbe evitare.
Quello che succede è che quando il browser del nostro smartphone carica la pagina web, prima colorerà il nostro box del colore rosso e successivamente, quando arriverà a leggere le proprietà dedicate alla sua risoluzione, lo trasformerà in verde.
Tutto questo succede a livello di rendering e difficilmente lo potremmo vedere in azione, ma questo non cambia il fatto che stiamo rallentando il nostro sito web.
Quando il browser legge i CSS che gli forniamo, li legge dall’alto in basso, questo significa che prima si troverà a leggere ed elaborare tutti gli stili applicati al sito web in versione desktop per poi rimuoverli e applicare le modifiche specifiche per la risoluzione incontrata.
Riconosco che in questo esempio abbiamo modificato soltanto il colore di sfondo, ma prova a pensare se oltre a questo avremmo dovuto modificare anche padding, margini, bordi e le disposizioni dei nostri elementi; il browser perderebbe in sacco di tempo a fare queste operazioni.
Ecco perché nei primi tempi in cui si applicava il responsive web design ci siamo affidati alla logica del Mobile First.
Al posto di iniziare dalle più pesanti regole dedicate al desktop è stato deciso di applicare prima le regole dedicate al mobile e soltanto successivamente aggiungere le personalizzazioni dedicate al desktop.
#box{
background-color: green;
}
/*
Le regole verranno applicate alle risoluzioni
maggiori di 800px
*/
@media (min-width: 800px){
#box{
background-color: transparent;
background-image: url("url/immagine.jpg");
}
}Come puoi notare ora è tutto diverso! Adesso per prima cosa si applica il colore di sfondo verde indipendentemente dalla risoluzione e grazie alla regola @media inseriamo le regole CSS contenute soltanto su schermi di dimensioni maggiori agli 800px.
Questo significa che, come nell’esempio, se ritengo di essere su una risoluzione abbastanza grande posso anche sostituire il colore di sfondo con un’immagine visto che adesso sappiamo di avere più spazio per poter mostrare i nostri elementi.
Ma il punto focale di questa pratica è la possibilità di aggiungere le regole CSS soltanto se necessario.
Si inizia con l’applicare le regole CSS più semplici, quelle che anche dispositivi meno potenti come quelli mobile sono in grado di renderizzare senza troppi problemi per poi andare ad aggiungere le regole più complesse soltanto se la risoluzione ce lo permette.
Questo è sicuramente un approccio molto utile e pratico, ma richiede un cambiamento di mentalità perché in fase di progettazione è ormai superfluo pensare al sito web come un elemento dedicato principalmente ai desktop; proprio perché questa non è più la verità.
Servirà del tempo e molta pratica, ma anche grazie a questo corso imparerai man mano l’importanza di questo cambiamento; per essere in grado di aggiungere funzionalità piuttosto che toglierle, per utilizzare veramente la logica del Mobile First è necessario comprendere quali siano quelle essenziali per andare man mano ad aggiungere le altre all’aumentare dei pixel disponibili nello schermo.
L’evoluzione in Content First e i suoi benefici
C’è però un fatto che viene completamente a mancare se andiamo ad applicare soltanto la logica del Mobile First.
Con le descrizioni precedenti è stato messo in evidenza la possibilità di adattare il nostro sviluppo applicando una logica che ci permette di applicare prima impostazioni dedicate a schermi piccoli per aggiungere man mano quelle dedicate agli schermi più grandi.
Se rimaniamo fermi su questo concetto sembra semplicemente che sia un gioco di pixel, se lo schermo è largo X allora applichiamo queste proprietà.
Per quanto questo sia comunque un ragionamento importante quando ci troviamo di fronte alla necessità di sviluppare siti web responsive, non è assolutamente abbastanza!
Come abbiamo sempre detto i siti web perderebbero gran parte della loro utilità se dovessero venire a mancare i contenuti, elementi sono essenziali alla diffusione e all’utilizzo del sito, e per questo non possiamo fare un ragionamento basato soltanto sul mobile.
Questo anche perché quando si pensa relativamente al mobile si cerca sempre di ridurre tutto a una condizione in percentuale, in base alla grandezza in pixel dello schermo si passa a impostare la larghezza dei vari contenitori a una percentuale.
Se ti ricordi nella lezione precedente abbiamo parlato di elementi che galleggiano. Nelle Fondamenta del Web Design abbiamo detto che ogni elemento blocco tende a occupare tutta la larghezza di una pagina e se vogliamo approfittare della costruzione di un layout multi colonna dovremmo ridurre la larghezza di questi contenitori e farli galleggiare uno di fianco all’altro.
Capita molto spesso di realizzare un layout con la colonna principale, quella dedicata ai contenuti, più grande rispetto alla sidebar. Nel mio lavoro mi trovo molto spesso a creare dei layout che dedicano circa il 70% della larghezza della pagina al contenuto principale e il resto della larghezza ai contenuti in secondo rilievo, come quelli della sidebar.
Su questo stesso sito stiamo invece sperimentando un layout senza colonna, ma questa scelta è stata presa in base ai contenuti che stiamo pubblicando, per i testi delle lezioni non vogliamo distrarti in alcun modo.
È comunque ovvio che in alcune tipologie di contenuto siano presenti soluzioni differenti; molti siti presentano layout molto interessanti che organizzano bene i contenuti presenti nella pagina.
Però basare tutti questi layout su una semplice percentuale non basta. Il problema deriva dal fatto che le percentuali si basano sulla grandezza in pixel dei nostri elementi, basta vedere l’esempio precedente dove controllavamo che la finestra del browser non fosse più grande, o più piccola, di 800px.
Basando le nostre modifiche sulla larghezza dei contenitori questo potrebbe comportare dei problemi se nel browser utilizzato sono state selezionate delle regole differenti per i caratteri da utilizzare nel sito.
Ecco perché dal Mobile First siamo giunti in un approccio dove è il contenuto quello da tenere in considerazione, siamo giunti a scoprire il Content First.
Come ti spiegherò nella prossima lezione, un approccio Content First ci spinge a utilizzare delle unità di misura ancora più elastiche delle percentuali che ci permetteranno di adattare il nostro layout alla forma che il contenuto potrà assumere.
Se pensassimo soltanto alla grandezza dei dispositivi in pixel, gestire il layout su delle media query basate su questa unità di misura e percentuali, avremmo sì un layout che si adatta alla schermo ma che probabilmente distrugge comunque l’esperienza utente.
Quindi l’unità di misura che utilizzeremo al posto di % e px sarà: rem.
Il rem è un ottima unità di misura perché si basa sulla grandezza del carattere definita nell’elemento html e questo ci garantisce un giusto rapporto con le diverse dimensioni che il nostro contenuto potrebbe avere. Oltre a questo è un’unità di misura molto più intelligente perché, basandosi sulla grandezza del carattere, le dimensioni in pixel diventano inutili dato che saremo in grado di predire il comportamento del nostro contenuto indipendentemente dalla risoluzione.
Nelle prossime lezioni spero di farti capire ulteriormente perché questo approccio risulti ancora più interessante e flessibile rispetto agli altri approcci discussi.
Quando si sviluppa per il web bisogna sempre stare attenti alle dimensioni dei nostri file e anche alle operazioni che andiamo a richiedere. Aggiungere delle regole piuttosto che rimuoverle ha molto più senso nella struttura a cascata dei fogli di stile.
Nella prossima lezione andremo a fare qualche esperimento con le diverse unità di misura che possiamo utilizzare e ne vedremo i differenti risultati.
Spero che gli esempi forniti in questa lezione siano stati sufficienti per permetterti di chiarirti le idee su questi concetti, la cosa importante di queste prime due lezioni era capire il tipo di approccio passando prima per un po’ di storia.
Sono state lezioni importanti perché sapere perché oggi si usa un determinato approccio permette di capirlo più a fondo e utilizzarlo come se fosse una seconda natura.