Introduction aux concepts de Responsive Web Design, méthodos, outils et REX sur ces méthodes (Avantages, inconvénients, coûts...) pour le BreizhCamp 2013

1. RWD
Conception d’IHM Web adaptatives
BreizhCamp 2013
Ven. 14 juin
@JulienLeThuaut

2. 2
RWD – Responsive Web Design
Sommaire
• Contexte & problématique
• Concept du « Responsive design »
• Focus sur les Media-queries CSS3
• Les techniques de mise en œuvre
• Les outils, frameworks existants
• Bilan 1 : Avantages / Inconvénients
• Impacts sur un projet : Conception / Intégration / Développement
• Bilan 2 : Le coût du « Responsive Design »

3. 3
Contexte & problématique
Constat : La consultation des sites sur Internet tend de plus en plus à
se faire via des appareils mobiles, aux multiples formats (Taille,
résolution, O/S, navigateur, support tactile, orientation, qualité
connexion réseau, etc.)
 http://gs.statcounter.com/#mobile_vs_desktop-ww-monthly-200812-201212

4. 4
Contexte & problématique
 De plus en plus d’internautes disent accéder au web
« uniquement » depuis leur mobile/tablette !

5. Contexte & problématique
 Et ça va s’amplifier ! (Sources : lesnumeriques)

6. 6
Contexte & problématique
Solution 1 : Concevoir un site par plateforme ?
Temps et coût de conception plus important, revient à créer plusieurs sites
Solution 2 : Appli native ? (IOS, Android…)
Problématique différente
Solution 3 : Concevoir un unique site avec une mise en page fluide
(tailles variables) ?
Pas une nouveauté ! Le Web est fluide de base, mode des années 2000
(tables), etc..
Mais… aucune mise en page, qu’elle soit fixe ou variable, ne peut s’adapter de
façon homogène et optimale à un contexte autre que celui pour lequel elle a
été conçue 

7. 7
Contexte & problématique
Alors ?
Peut-on produire aujourd’hui un site ou une
interface Web, pouvant à la fois :
être visualisée et utilisée sur tout type de plateforme ?
et ceci dans des résolutions différentes et des contextes
d’utilisation différents ?

8. Contexte & problématique
Concevoir un site en utilisant les techniques de « Responsive Design »
= design adaptatif/réactif

9. Contexte & problématique
Alors, le Responsive Web Design :
Mode ?
Tendance ?
Concept magique ?
Ou nouveau standard ?

10. 10
Le concept
A partir d’un code HTML unique, mettre en œuvre un ensemble de
mécanismes permettant l’adaptation (taille, agencement, structure,…)
de ce site à diverses résolutions, orientations, etc.

11. 11
Le concept
OK, donc comment ça fonctionne ?
Le RWD = ensemble de techniques, et basé sur 3 principes fondamentaux :
• Définition d’un layout fluide (Taille des éléments en %, grilles CSS)
• Intégration de média flexibles (Images, vidéos, textures…)
• Utilisation de media-queries : adapter le site lorsque le rendu n’est plus
acceptable
L’UI est conçue pour s’adapter à certaines [plages de] résolutions. On parle de
« Breakpoints » (Points de rupture, points de bascule).
On peut déterminer autant de breakpoints que l’on souhaite pour un projet.
(0 < > 480px < > 960px <> 1024 px <> 1280px <> 1600 px <> etc.)

12. Le concept
Autres démos : http://mediaqueri.es/

13. 13
TECH : Focus sur les media-queries
Media-queries CSS : conditions dans l’application des styles CSS
Critères de tests
•Taille écran (largeur min-max, hauteur min-max)
•Résolution écran (PPI)
•Orientation (Paysage, portrait)
•Type d’appareil (screen, handheld, print, tv, etc.)
•Autres
Ces critères peuvent être combinés :
Ex. : si taille max écran = 480px et orientation = portrait

14. Exemple :
Utilisation pour un layout en colonnes « responsive »
Quel support ?
Media-queries > CSS3 (Caniuse) donc pas supportées sous IE<9 (respond.js)
Mais supporté pas l’ensemble des navigateurs mobiles du marché 
TECH : Focus sur les media-queries

15. 15
TECH : Focus sur les media-queries
Combien de points de ruptures ?
Minimum 1 : Petits écrans <> Grands écrans (bascule à 480px)
Maximum 2 : Petits <> moyens <> grands écrans (480 / 768 )
Souvent définis par les frameworks (critère de choix ?)

16. 16
Techniques et mise en œuvre du RWD - illustrations
Ce qu’on va pouvoir adapter
Layout flexible / Grilles (Fluide / RWD)
Images / Vidéos (demo)
Taille des éléments HTML
Affichage/Masquage d’éléments
Éléments de navigation / Menus
Typographie (rem)
Formulaires/Tableaux (RDT)
Etc.

17. 17
Techniques et mise en œuvre du RWD - illustrations
Exemple concret et complet : Site du Smashing magazine

18. 18
Bilan : Principaux avantages
Proposer une seule version d’un site Web visualisable et utilisable via de multiples
terminaux est une démarche très avantageuse pour plusieurs raisons 
•Pas besoin de créer plusieurs sites/applis dédiées à un type d’appareil précis
•Pas de mécanisme à mettre en place (et à maintenir) pour basculer automatiquement
l’utilisateur vers la version du site adéquate (ex. test UserAgent)
•Même sur un appareil donné, si la taille du navigateur est modifiée (Redimensionnement
de fenêtre, orientation), le contenu va s’adapter
•Un seul code à maintenir (bugs, modification de contenu)
•SEO : Ne pénalise pas le référencement du site (Duplicate content)
•Touche un maximum d’utilisateurs
 Si le site n’est pas destiné à un type d’appareil particulier, il y a un grand intérêt
à privilégier une conception « responsive »

19. 19
Bilan : Inconvénients majeurs
Proposer une seule version d’un site Web optimisée sur tous les
terminaux est utopique !
Il faudra forcément faire des compromis qui peuvent ne pas être
satisfaisant pour l’utilisateur.
Difficile d’envisager une interface Web unique confortable à la fois sur
les petits et grands écrans : soit le site sera étriqué sur grand écran
avec des boutons surdimensionnés, soit il faudra sans cesse zoomer dans
la page pour pouvoir lire le contenu sur un petit écran…
Contenus tiers : Ex. codes embarqués, iframes (ex. boutons FB) 

20. 20
Bilan : Possibles inconvénients, points d’attention
Coût de conception augmenté par rapport à un site/une interface « classique » ?
Nécessite plus de temps et de compétences (Conception, réalisation, tests) donc coûte plus cher à
mettre en œuvre
 Mais, doit pouvoir être maitrisé et cadré (ex. Utilisation de frameworks ?)
Liberté de l’utilisateur limitée ?
Risque de brider l’utilisateur en l’empêchant d’accéder à la version qu’il souhaite visualiser !
Concepts d’Opt-in / Opt-out ?
Problématiques en cours d’étude…
Design épuré = manque d’originalité ?
C’est un risque, possibilité de voir de plus en plus de sites « responsive » fortement semblables,
surtout du fait de l’utilisation de Frameworks ou de templates responsive.
Grilles souvent décriées car plus un outil de typographie plébiscité par les designers issus du print…
Attention à ne pas sacrifier l’identité du client seulement par contrainte technique !

21. 21
Donc ?
Pour choisir entre le responsive ou les versions séparées, tout dépend
donc :
•du nombre de terminaux visés
•du type de contenu et d’interaction que le site propose (donc de l’effort de
maintenance)
•Du degré de complexité des interfaces (Visuelles ou non…)
•de la compétence HTML/CSS dans l’équipe
Une analyse fine doit être faite au départ du projet.
Si des expériences clairement différentes doivent être proposées sur mobile,
tablette, desktop ou TV, il faut alors plus imaginer une solution dédiée par support !
Sinon ! Let’s GOOOO

22. 22
TECH : Outils / Frameworks
Frameworks simples (grilles fluides [+ templates HTML et Photoshop])
•1140 CSS Grid
•Columnal
•Ingrid
•…
Frameworks évolués (Composants + scripts + styles CSS prédéfinis + grilles + templates
HTML, etc.)
•Foundation
•Twitter bootstrap
•Gumby
•Skeleton
•…
Cloner, créer son propre framework ou sa solution Hybride

23. 23
TECH : Quelques limites
Attention : Modification de l’apparence seulement et pas du contenu
 L’ensemble du DOM est évalué par le navigateur donc tous les médias (images, vidéos)
présentes dans le HTML sont chargées, même si masquées par le CSS
NB : Possibilité de « tricher » : Scripts JS (ex. mobiledetect.js)
Optimisations par certains navigateurs (Contenu masqué non chargé)
Certains Frameworks complexes, difficilement customisables (design)
Tests sur plusieurs navigateurs nécessaires
 Évaluation du CSS et rendu pas tout le temps identique… même si cela tend à
s’améliorer
Tests sur un navigateur desktop seulement pas suffisant 
Moteurs de rendus des navigateurs différents en fonction des plateformes…
(Adobe Inspect)

24. 24
UI/UX : Impacts sur le design / graphisme
Comment aborder la conception :
Quelle approche :
• Desktop first vs. Mobile first ?
• Progressive enhancement vs. Graceful degradation ?
Maquettage : toutes les résolutions ? version principale seulement ?
Définition de comportement génériques sur les éléments HTML lors du passage d’une
résolution à une autre ? Ou re-définition sur chaque projet de comportement spécifiques ?
Pistes :
- Templates zoning (Visio, papier, Web)
- Prototypes / Site de démo / Maquettes de démo
- Frameworks
 A éviter : 3 Résolutions à concevoir + à maquetter + à intégrer + à maintenir = Budget
de 3 sites distincts

25. 25
Réflexions : Les impacts sur la méthodo, le cycle de vie du projet
Quels impacts sur la conception (maquettage)
 Créativité : Se limiter forcément sur des
schémas d’interface simples (Lignes et
colonnes, grilles) ? 
 Doit-on vraiment réaliser plusieurs
maquettes ou peut-on définir et utiliser des
comportements génériques (modèles) qui
s’appliqueront à l’UI ? (ex. Une ligne
divisée en 3 blocs horizontaux sur PC =
Empilement vertical des blocs sur mobile)
 Nouveaux documents de schématisation
plutôt qu’une maquette ? (Content-
choreography)
Les patterns à la rescousse !

26. 26
Réflexions : Les impacts sur la méthodo, le cycle de vie du projet
Utilisation ou définition de design patterns RWD

27. 27
Réflexions : Les impacts sur la méthodo, le cycle de vie du projet
Utilisation ou définition de design patterns RWD

28. 28
Réflexions : Les impacts sur la méthodo, le cycle de vie du projet
Utilisation ou définition de design patterns RWD

29. 29
Réflexions : Les impacts sur la méthodo, le cycle de vie du projet
Utilisation ou définition de design patterns RWD

30. 30
Réflexions : Les impacts sur la méthodo, le cycle de vie du projet
Quels impacts sur L’intégration HTML (Mobile-first / Desktop-first)
 Communication / échanges / collaboration indispensable dès le début entre
graphiste et intégrateur
 Process de production linéaire : Graphiste > Intégrateur > Développeur : Pas
adapté !
 Utilisation de nouveaux outils/Frameworks ou codage from-scratch ?
 Mise à jour de la méthodo de l’intégrateur, codes réutilisables à faire évoluer,
gabarits à mettre à jour…
 Procédure de tests plus longue (toutes les résolutions ?), retouches nécessaires au
cas par cas ? (Utile : Responsinator, Adobe EDGE Inspect, BrowserStack)
 RWD = Concept encore jeune. Best-practices pas encore forcément identifiées 
Place de l’intégrateur/développeur au sein de la chaîne de production plus importante sur
ce type de projet. Le graphiste n’est pas le seul maître du rendu final de l’application.
Si pas de graphiste ou d’intégrateur CSS  Framework

31. 31
Réflexions : Les impacts sur la méthodo, le cycle de vie du projet
Quels impacts sur le développement ( Client / Serveur )
 Être « responsive » au niveau de l’affichage n’est pas suffisant !
 Optimisation des performances, de l’utilisabilité, des requêtes serveur
aussi à prendre en compte
Récent concept de RESS : Responsive web design Server Side
 Appliquer des conditions basées sur la résolution, le device, l’orientation
côté serveur et par exemple, produire un code HTML structuré
différemment en fonction de ces infos (RESS)

32. 32
Bilan : Impacts sur le coût
Assez difficile à évaluer/chiffrer car dépend du contexte/client 
Hypothèses :
• Un site « responsive » avec 3 résolutions == Cout site classique x 3 ? 
 Si autant de travail sur chaque version, c’est fortement possible !
 Peu souhaitable
• Un site « responsive » avec 3 résolutions >= Cout site classique x 3 ? 
 C’est le risque si mal conçu, si trop d’aller-retour client, si trop de règles spécifiques à
certaines versions du site !
 Peu être plus pertinent d’imaginer 3 projets distincts dans ce cas…
•Un site « responsive » avec 3 résolutions <= Cout site classique x 3 ? 
 C’est le but à atteindre en :
• améliorant la méthodo de conception/production progressivement (Retour d’exp.)
• optimisant le travail de l’équipe (Nouveaux documents de conception, outils,
utilisation de frameworks)
• Sensibilisant le client sur le coût réel du RWD (Ce n’est pas magique ni gratuit !)
•Un site « responsive » avec 3 versions == Cout site classique ?
 Très peu probable car forcément plus de travail (Conception, maquettage, intégration,
tests)

33. 33
C’est tout pour aujourd’hui !