Aller au contenu

Design réactif

Les approches

Ce n'est pas un secret: de nos jours, la plateforme la plus utilisée pour consulter le web est le mobile. Il est donc très important que nos interfaces soient adaptées à la résolution de ces appareils, ainsi qu'aux capacités des ressources limités qu'ils offrent, afin d'offrir à l'utilisateur la meilleur expérience possible.

Lorsqu'on doit créer une interface et supporter plusieurs plateformes avec différents niveaux de capacités, il existe deux approches possibles :

  • Développement en amélioration progressive
  • Développement en dégradation progressive

Amélioration progressive

L'amélioration progressive consiste à créer en premier lieu une interface adaptée à la plateforme la moins performante. Cette version contient alors la base des fonctionnalités, mais est concentrée sur l'essentiel du contenu, ce qui est vraiment important. Par la suite, on pourra bâtir sur cette version en ajoutant des effets, des interactions supplémentaires, du contenu complémentaire, etc. pour les plateformes plus performantes commes les tablettes et les PC.

Dégradation progressive

La dégradation progressive est l'inverse de l'amélioration progressive. On développe une interface complète avec toutes les fonctionnalités et interactions possibles, pour les plateformes les plus performantes. Puis, on ajuste l'interface pour qu'elle s'adapte aux plateformes moins performantes. On doit alors couper des fonctionnalités et parfois même du contenu.

Avec la popularité des appareils mobiles, l'amélioration progressive est l'approche la plus logique à adopter (et la plus populaire). On appelle cette approche : Le Mobile First.

Le Mobile first

Le mobile first est l'approche où on commence par concevoir pour mobiles (appareils plus petits, aux ressources limitées), puis on ajoute des fonctionnalités, styles, contenus pour écrans plus grands.

Mobile First

En se penchant d'abord sur la version mobile, on se concentre sur ce qui est vraiment important. On sera plus en mesure de mettre l'emphase sur le produit et ses points saillants, plutôt que de tenter d'en mettre plein la vue inutilement.

Par ailleurs, Google a annoncé en 2018 que dorénavant, leurs outils d'indexation et d'ordonnancement des résultats priorisera la version mobile des sites web, afin de faciliter les recherches web sur mobile. En effet, un site fait pour le PC est souvent plus lourd à charger et ne s'adapte pas toujours à la taille d'écran du mobile. Ils tentent ainsi de répondre à la demande, maintenant plus grande sur mobile que sur ordinateur.

Mais au-delà du développement d'une interface d'abord mobile, le Mobile First est aussi une ligne de pensée à adopter pour ainsi modifier toute notre chaîne de production. Tout doit être pensé "mobile" avant même de pouvoir réfléchir à l'interface de plus grande taille : le contenu, l'ergonomie, la convivialité, la rapidité de chargement, etc. On s'assurera d'avoir une interface fonctionnelle mobile avant tout, dont le contenu est le stricte nécessaire pour l'utilisateur.

🎯 Les objectifs visés par un développement en mobile first ?

  • Présentation adaptée aux petits écrans
  • Contenu utile pour les utilisateurs
  • Meilleures performances possibles, même via une connexion limitée

Pages réactives

Avec la popularité des tablettes et appareils mobiles, on a noté plusieurs problèmes liés à l'affichage des sites web sur de petits écrans ainsi qu'à l'utilisation de certaines fonctionnalités avec le tactile (par exemple, l'état hover n'existe pas pour le doigt - seulement pour la souris).

Ainsi, dans les débuts, on développait et on maintenait deux sites différents. Bien entendu, cette méthode de travail demande le double de temps dans toutes les étapes de production du site.

On a donc recherché des méthodes mieux adaptées à la réalité à laquelle on devait faire face (plus de mobiles, mises à jour fréquentes, etc.), pour en arriver aux sites web réactif (responsive web design).

Aujourd'hui, le web réactif se développe en mobile first, surtout lorsqu'on développe un tout nouveau site où aucune contrainte de rétrocompatibilité n'est présente. Mais il faut savoir qu'il est possible de développer en web réactif sans obligatoirement appliquer le mobile first... Il y a vraiment une distinction entre les deux notions.

Responsive design : design d'interfaces flexibles qui s'adaptent aux dimensions de l'écran

Mobile first : méthode de travail qui consiste à développer l'interface mobile avant tout

Selon w3Schools

Le responsive web design se résume à utiliser le HTML et le CSS pour automatiquement redimensionner, cacher, élargir ou rapetisser des éléments d'une page, afin d'offrir une belle présentation sur toutes les plateformes (ordinateurs, tablettes et mobiles).

Source: https://www.w3schools.com/html/html_responsive.asp

La base d'un site réactif

Créer un site web réactif apporte des bénéfices, dont :

  • Une seule version du site à maintenir
  • Évolue bien dans le temps
  • Supporte d'emblée les nouveaux modèles d'appareils

Pour créer ce genre de site, quelques notions essentielles forment la base :

  • Ajuster le viewport
  • Dimensions fluides avec unités relatives
  • Tailles en "border-box"
  • Images et vidéos utilisent une largeur (width ou max-width) de 100%
  • Utiliser des requêtes média en CSS (media queries)

Tailles d'écrans et orientation

Ainsi, pour développer une interface réactive, il faut établir quelles sont les limites de tailles (breakpoints) qui détermineront à quel moment l'interface recalculera son affichage.

Les tailles d'écrans seront influencés par l'appareil utilisé, mais aussi par son orientation.

Orientation

L'orientation indique si l'appareil est utilisé en mode portrait ou en mode paysage.

Orientation

Taille

La taille représente le nombre de pixels en largeur et en hauteur disponibles pour l'affichage.

Sur plusieurs sites de référence, on mentionne que pour un site réactif, on devrait minimalement supporter quatre tailles d'écrans :

Appareils Taille
Petits écrans / appareils mobiles < 600 pixels
Écrans moyens / tablettes en portrait < 900 pixels
Écrans moyens / tablettes en paysage < 1200 pixels
Écrans larges / ordinateurs 1200+ pixels

Ces valeurs sont des valeurs génériques pouvant combler un large éventail d'appareils.

Malheureusement, il n'y a pas de standard au niveau des tailles d'écrans d'appareils. En effet, si on veut travailler avec des modèles spécifiques de iPhone ou d'Android, on doit alors se fier aux spécifications de ces appareils et ajouter du code CSS pour traiter ces tailles spécifiques différemment. Par contre, si on ne voit pas de raison de cibler des modèles bien particuliers, alors il est mieux d'établir nos breakpoints basées sur notre design plutôt que sur des tailles de modèles.

Ainsi, bien que ces limites soient un point de départ, il est toujours bon de les tester avec notre design. Il est possible que pour notre design particulier, on doive ajuster ces limites.

Bon à savoir

Sur le site de CSS Tricks, on retrouve une liste complète des tailles d'écrans pour un grand nombre de modèles de mobiles, tablettes, portables et objets intelligents.

https://css-tricks.com/snippets/css/media-queries-for-standard-devices/

Pour développer un site en mobile first, on utilisera alors l'affichage mobile par défaut, puis on ajoutera des validations pour les autres tailles d'écrans, qui ajusteront l'affichage pour les appareils plus grands.

Les images

Il faut porter une attention particulière aux images lorsqu'on développe une interface réactive. Non seulement, elles doivent s'adapter à la taille d'écran, mais on devrait aussi s'assurer de limiter les téléchargements inutiles au client et fournir la bonne taille d'image plutôt que des images trop grandes. Ceci optimise les performance de notre interface.

Quelques trucs de base sont suggérés :

  • Utiliser des images SVG pour les images non photographiques

  • Utiliser des pourcentages pour établir les tailles d'images

    Exemple 1:

    img {
    max-width: 100%;
}

    La propriété max-width s'assure que l'image ne prendra jamais plus de 100% de l'espace alloué à son parent : elle sera redimensionnée pour remplir l'esapce sans déborder. Si l'image st plus petite que la taille de son parent, elle s'affichera alors à 100% de sa taille normale.

    Exemple 2:

    img {
    width: 100%;
}

    La propriété width s'assure que l'image prenne 100% de l'espace alloué à son parent en tout temps. SI l'image est plus petite que la taille de son parent, elle sera alors étirée pour remplir l'espace.

  • Utiliser la balise <picture> plutôt que la balise <img> lorsque possible

    La balise <picture> permet de définir plusieurs sources d'images pour différentes tailles d'écrans. Le navigateur tentera d'utiliser la meilleure source fournie pour l'affichage actuel. Si aucune des sources fournie ne correspond aux critères d'affichage actuels, alors une balise <img> doit être fournie pour l'image par défaut.

    Exemple :

    <picture>
    <source srcset="img/surfer-200-200.jpg" media="(max-width: 600px)">
    <source srcset="img/surfer-300-300.jpg" media="(max-width: 900px)">
    <img src="img/painted-hand-298-332.jpg" />
</picture>

  • Avoir différentes tailles d'images pour les images de fond et appliquer la bonne selon la taille d'écran

    ⚠️ Cette technique utilise les media queries, dont l'explication est plus détaillée dans la section design réactif du site du cours.

    Exemple :

    header {
    height: 30%;
    width: 100%;
    background-image: url(images/small-header.jpg);
    background-position: center;
}

@media all and (min-width: 600px) {
    header {
        background-image: url(images/large-header.jpg);
        background-position: center;
    }
}

Source: MDN : The building blocs of responsive design

Les unités de taille à privilégier

Il existe une multitude d'unités de taille possibles en CSS. De cette liste, on en tire deux grandes catégories:

  1. Mesures absolues

    Les mesures absolues sont des mesures fixes, qui ne s'adaptent pas à l'espace disponible.

    Elles sont donc à éviter!

    Les pixels, les centimètres, les millimètres sont quelques exemple d'unités absolues qu'il faut éviter d'utiliser le plus possible dans la création d'une interface réactive.

    Bien entendu, parfois il est difficile de s'en passer complètement...

  2. Mesures relatives (aussi appelées mesures fluides

    Les mesures relatives sont des mesures adaptives, qui permettent aux éléments de se redimensionner selon l'espace disponible. Elles sont relatives à une autre mesure. Ce sont ces mesures qui sont à préconiser pour l'affichage réactif.

    Exemples:

    Unité Decription
    % Pourcentage de la taille du parent.
    em Relative à la taille de police de l'élément parent.
    rem Relative à la taille de police de l'élément racine (root element). L'élément racine <html> est utilisé pour définir entre autre la taille de police par défaut à partir de laquelle les autres éléments de la page seront dimensionnés.
    vw Relative à la largeur disponible pour l'affichage (viewport width). 1vw = 1% de la largeur d'affichage.
    vh Relative à la hauteur disponible pour l'affichage (viewport height). 1vh = 1% de la hauteur d'affichage.

    D'autres mesures propres à certains éléments sont aussi disponibles. C'est le cas, entre autre, de l'unité fr utilisée pour la création des éléments grid.

La détection de la taille d'écran : viewport

Le viewport représente la fenêtre d'affichage, donc l'espace visible d'une page web. La fenêtre d'affichage diffère d'un appareil à l'autre et c'est pourquoi on doit adapter nos interfaces aux différentes tailles de fenêtres possibles.

Par contre, les navigateurs sur les appareils mobiles créent le rendu des pages pour un écran d'ordinateur, puis tentent d'afficher la page dans l'espace disponible. Malheureusement, ceci peut causer bien des problèmes à l'affichage et nécessiter que l'utilisateur doive zoomer/dézoomer pour bien voir le rendu final.

Pour forcer le navigateur à effectuer le rendu pour l'espace dont il a bel et bien disponible, on ajoute une donné méta à notre page HTML. C'est une pratique recommandée entre autre par Google et MDN pour assurer que nos limites dites breakpoints que nous déclarerons en CSS pourront s'appliquer correctement.

L'information à ajouter dans la secion <head>d'une page HTMl est la suivante :

<meta name="viewport" content="width=device-width, initial-scale=1.0, shrink-to-fit=no">

name=viewport indique que nous venons ici définir la fenêtre d'affichage.

width=device-width vient indiquer que la largeur de l'espace d'affichage est égale au nombre de pixels d'affichage de l'appareil utilisé

initial-scale=1.0 représente donc le zoom initial appliqué lorque la page est chargée dans le navigateur. Avec la valeur 1, on indique d'utiliser l'espace disponible avec un ratio 1:1 pour les pixels CSS appliqués sur les pixels physiques de l'appareil.

shrink-to-fit=no indique que si le contenu initial n'entre pas totalement sur la page, alors ne pas "dézoomer" pour faire entrer tout le contenu. En effet, une bonne page réactive s'occupe elle-même de la façon dont le contenu doit être traité sur petit écran, en cachant des portions de page ou en déplaçant des éléments. Ce ne devrait pas être le travail du navigateur qui, somme toute, ne fera que zoomer/dézoomer et offrira une expérience utilisateur indésirable.

Cette déclaration ne change rien sur ordinateur. C'est vraiment sur mobile qu'elle prend tout son sens.

Viewport

Source: Google: Responsive Web Design - Set the viewport

Source: MDN: The building blocs of responsive design - Viewport

Source: MDN: Utiliser la balise meta viewport pour contrôler la mise en page sur les navigateurs mobiles

Requêtes média en CSS

Selon MDN :

Les requêtes média (media queries) permettent de modifier l'apparence d'un site ou d'une application en fonction du type d'appareil (impression ou écran par exemple) et de ses caractéristiques (la résolution d'écran ou la largeur de la zone d'affichage (viewport) par exemple).

Source: MDN: Media queries

En d'autres mots, les requêtes média sont une méthode CSS pour modifier les éléments de l'interface en fonction de la taille de la fenêtre d'affichage.

Syntaxe

La syntaxe d'une requête média est la suivante :

@media not|only mediatype and (mediafeature and|or|not mediafeature) 
{
  Code-CSS;
}

Pour connaître toutes les valeurs possibles de mediatype et mediafeature :

MDN : les Media queries

Exemple de base

Premier exemple avec des éléments HTML de base.

Ici, les objets se placent par défaut à la verticale, puis on modifie la taille, le positionnement, et l'image de fond de blocs <div> lorsque la zone d'affichage offre un minimum de 900 pixels de large :

HTML

<div id="bloc-un">
    <h1>Titre du bloc un</h1>
    <p>Nullam tortor odio, placerat sed pellentesque eget, consectetur id mauris. Cras eu ornare tortor, 
    at porta dui. Interdum et malesuada fames ac ante ipsum primis in faucibus. Fusce id arcu et enim 
    efficitur sagittis. Suspendisse ac mollis tortor. Fusce porttitor, ex ac tincidunt rhoncus, est augue 
    tincidunt augue, in imperdiet eros magna non justo.</p>
</div>

<div id="bloc-deux">
</div>

CSS

* {
    box-sizing: border-box;
}

div {
    padding: 1em;
}

#bloc-un {
    width: 100%;
    background-color: plum;
}

#bloc-deux {
    width: 100%;
    height: 50vh;
    background-image: url(../img/skittles_640x960.jpg);
    background-clip:content-box;
    background-size: cover;
    background-position: center;
}

@media screen and (min-width: 900px) {

    #bloc-un {
        width: 50%;
        float: left;
    }

    #bloc-deux{
        width: 50%;
        float: left;
        background-image: url(../img/gummies_1280x853.jpg);
    }
}

Media small Media large