2. AGENDA
1 Constat : La grande fragmentation
2 Comment s’armer face à tous ses écrans
3 Les enjeux design et conception
4 La méthodologie
5 Les enjeux techniques du responsive
6 Le choix du responsive
7 Conclusion
4. LES RAPPORTS DE FORCE ONT CHANGÉ EN 2 ANS
50
45
40
35
30
25
IE
Chrome
Firefox
20
Safari
Opera
15
Other
10
5
0
statcounter.com
5. LES RAPPORTS DE FORCE ONT CHANGÉ EN 2 ANS
50
45
40
Chrome
35
30
25
20
Internet
Explorer
IE
Chrome
Firefox
Safari
Opera
15
Other
10
5
0
statcounter.com
6. LE TRAFIC SMARTPHONE PRESQUE DOUBLÉ EN 1 AN
20%
18%
16%
14%
12%
10%
8%
Mobile
6%
4%
2%
0%
statcounter.com
7. LE TRAFIC SMARTPHONE PRESQUE DOUBLÉ EN 1 AN
20%
18%
16%
14%
On peut anticiper que la part de marché du
12%
smartphone mondial va passer les 20% en fin
10%
d’année
8%
Mobile
6%
4%
2%
0%
statcounter.com
8. Hier encore,
Le marché tournait autour de 3 résolutions
principales :
•
•
•
UN ORDINATEUR,
UN IPHONE,
UN IPAD …
9. APPLE ET SON ÉCRAN RETINA
a lancé la course au dpi* et à la finesse
des écrans
LE NOMBRE DE RÉSOLUTIONS SE VOIT DONC MULTIPLIÉ
*Dot Per Inch
10. APPLE LANCE LA COURSE AU DPI : LE RETINA
iPad
iPad Retina
12. 2012 – 2013
Le nombre de terminaux Android a progressé
de façon incontestable
13. ANDROID DÉPASSE IOS AU NIVEAU MONDIAL
45
40
35
30
Android
25
iOS
Nokia/ Symbian
20
Samsung
15
10
JUILLET
2012
BlackBerry OS
Autre
Sony Ericsson
5
0
statcounter.com
14. UN NOMBRE DE TERMINAUX CONSIDÉRABLE EST SOUS ANDROID
opensignalmaps
15. ET UN NOMBRE DE RÉSOLUTIONS AD-HOC
231
RÉSOLUTIONS
opensignalmaps
17. LA « PHABLET » : EST-CE UNE TABLETTE? UN SMARTPHONE?
18. PEU IMPORTE !
Désormais,
On ne doit plus catégoriser ni parler de résolution,
on doit penser en TAILLES D’ÉCRANS
19. LA PERFORMANCE DES SMARTPHONES AU CŒUR DU SUJET
Firefox OS
• Bon support HTML5
• Petit écran
• Petit processeur
Samsung Galaxy Y
• Android 2.3 – 2011
• Petit écran
20. La durée de vie
et la qualité des terminaux
sont très aléatoires !
Rien ne nous informe sur les mises à jours de certains terminaux,
Android 2.3 datant de 2010 équipe encore 30% des
smartphonesAndroid du marché
26. LA SEULE CHOSE
DONT ON PEUT ÊTRE SÛR.
IL Y A LE WEB
SMARTPHONES
TABLETTE
DESKTOP
TÉLÉ
ETC …
Et on devra traiter la plupart des supports de la même
façon.
28. CHANGER NOTRE MODE DE SUPPORT
DU
SUPPORT
NAVIGATEUR
AU
SUPPORT
FORMAT
Le support navigateur,
c’est faire en sorte que le code s’adapte au browser
Le support format,
c’est faire en sorte que le browser sélectionne la partie du code qui lui
est adressée
29. UN NOUVEAU PATTERN DE CONCEPTION
Un consensus sur un pattern de conception a été trouvé :
LE RESPONSIVE WEB DESIGN
Design Fluide
RWD
Taille de texte
adaptée
Réorganisation du
layout
Un fonctionnement par paliers de tailles d’écrans
30. « ANCIENS SUPPORTS »
LE POINT COMMUN ENTRE :
• Internet Explorer 7-8
• Android 2.3
• iOS < 5
Des navigateurs archaïques,
mais qu’on doit supporter car ils représentent encore
une grosse part du marché.
Mais COMMENT ?
31. AMÉLIORATION PROGRESSIVE
Développer en respectant les standards W3C
1 Certaines fonctionnalités des nouveaux navigateurs seront
2
simulées sur les plus anciens (ex : Flash pour balise
Vidéo, Javascript pour les animations,…)
Certaines subtilités graphiques ou motion ne seront pas présentes
(coins arrondis, motion, text-shadows,…)
Une expérience optimale pour les derniers navigateurs et les
mobiles performants
Une expérience fonctionnelle pour les autres
Un fonctionnement par paliers de fonctionnalités
32. UN SUPPORT PAR PALIERS
IL S’AGIT DE DÉFINIR DES PALIERS :
• de tailles d’écrans
• de fonctionnalités
Les paliers sont liés à la technicité du sujet.
Voici un exemple sur un site présentant beaucoup de
motion
34. TECHNIQUEMENT ?
Comment détecter les paliers techniquement :
Paliers fonctionnels :
• Modernizr (Librairie JS permettant de détecter les
nouvelles fonctionnalités JS)
• Détection du User-Agent (dernier recours)
Si on souhaite baisser intentionnellement le fonctionnel (ex: les
animations sur Android 2.3 qui les supporte mais mal )
Gestion des évènements spécifiques à certains support
Paliers de résolutions :
• CSS Media-queries (nouveauté CSS3 implémentée par les
derniers browsers)
Les anciens browsers (desktop) n’ont pas besoin de supporter
ces résolutions et bénéficieront d’une CSS par défaut
37. LE LANGAGE DU RESPONSIVE
On définie donc des paliers sur lesquels on va appliquer des layouts* de
présentation
Small
Medium
Large
X-large
*gabarits
39. L’ABSENCE DE DESIGN STATIQUE
Les techniques de
Design ont évolué :
• On peut définir le palier
minimum
et le palier maximum
• On crée des éléments
plus
que des mises en pages
• On passe d’un design
statique
à une maquette HTML
vivante
Le RWD est en opposition avec le principe de pixel perfect
40. LA NAVIGATION
La stratégie de navigation reste un choix important.
Plusieurs pattern existent avec leurs avantages et
inconvénients.
1/ Volet
Pour
•
•
•
Espace
Design
Pattern
Facebook
Contre
•
•
Confusant
Compatibilité
41. LA NAVIGATION
La stratégie de navigation reste un choix important.
Plusieurs pattern existent avec leurs avantages et
inconvénients.
2/ Bascule
Pour
•
•
•
Contexte
Design
Compatibilité
Contre
•
•
Javascript
Performance
42. LA NAVIGATION
La stratégie de navigation reste un choix important.
Plusieurs pattern existent avec leurs avantages et
inconvénients.
3/ Liste de sélection
Pour
•
•
•
Espace
Identifiable
Compatibilité
Contre
•
•
•
Design
Confusant
Javascript
44. LE RESPONSIVE IMPLIQUE
UNE MÉTHODOLOGIE ADAPTÉE
Les différents enjeux du Responsive Web Design impliquent une
phase de conception importante.
Ceci afin de pérenniser la réflexion et d’anticiper au mieux les
prochaines innovations, sans sacrifier le fonctionnel et l’utilisateur
final.
Elle permettra d’analyser le besoin exact, de prioriser les
éléments à afficher ou non sur les différents périphériques ou
encore de déterminer quel « layout » RWD adopter.
Cette conception peut se répartir de la manière suivante :
DÉFINITION DE
L’ARCHITECTURE
RESPONSIVE ET
L’ADAPTABILITÉ
IDENTIFICATION
DES IMPACTS
TECHNIQUES
PROTOTYPAGE
TESTS
UTILISATEURS
45. MÉTHODOLOGIE PROJET
DÉFINITION DE
L’ARCHITECTURE
RESPONSIVE ET
L’ADAPTABILITÉ
Etude des usages
sur les différents
L
devices
L
WS
Analyse du
parcours
utilisateur
Priorisation
fonctionnelle
Segmentation
marketing cibles AX
L benchmark, CRM
Matérialisation des
parcours client et
L
personae
L
Périmètre
fonctionnel
et éditorial
IDENTIFICATION
DES IMPACTS
TECHNIQUES
PROTOTYPAGE
TESTS
UTILISATEURS
Impacts techniques
avec le back & le
WS
CMS client
Analyse de la
pertinence du
contenus selon le
WS
contexte
Test sur prototype
cliquable
WS
Impact SEO
Wireframes des
fonctionnalités
adaptées
Analyse des
résultats et
adaptations
L
L
Impact Analytics
Modélisation des
différents
L patterns, mobile first
Impact tracking
Développement d’un
prototype HTML
L
L
L
WS
L
livrables
WS
workshops
46. MÉTHODOLOGIE PROJET
UNE ÉQUIPE MODULAIRE DÉDIÉE AUX EXPÉRIENCES
MULTIPLES, TRAVAILLANT DE FAÇON COLLABORATIVE
Product Owner
Chef de projet
Développeurs front
Consultant UX
Directeur Artistique
Creative Technologist
Expert Analytics
Expert Mobile
Développeurs back
48. PROCESSUS DE VALIDATION GRAPHIQUE
La validation des croquis puis
du prototype aboutit à
des PSD
MAQUETTES
PSD
PROTO HTML
CROQUIS
Pour correspondre
au cycle actuel
49. PROCESSUS DE VALIDATION GRAPHIQUE
On peut imaginer un processus itératif.
C’est ce vers quoi l’industrie tend.
CROQUIS
PROTO HTML
Binôme :
Créatif
Développeur
PSD
50. CONCEPTION : ONE MORE THING ?
Il faut bien choisir sa cible
• Smartphone ≠ Smartphone, un iPhone 4 ne doit pas
être traité comme un Galaxy S4.
• Un projet responsive est un projet web, les
smartphones anciens ne peuvent pas suivre malgré
toutes les optimisations
Les formats évoluent, il vaut mieux ne pas trop figer
ses paliers de rendu.
• L’apparition des phablets ou du 5S et son écran
allongé démontrent qu’il faut rester ouvert à la
variation des points de ruptures au cours du projet.
• Ex: iPhone 5 en mode paysage
53. LES MÉDIAS
LE PRINCIPAL ENJEU DES MEDIAS :
ADRESSER LES BONNES IMAGES
1ÈRE SOLUTION /
UTILISER LE USER-AGENT (BROWSER SNIFFING)
La liste de user-agents ou la base de donnée
sera-t-elle toujours à jour ?
Pouvons-nous penser que un device = une taille d’écran ?
Fonctionnalité Galaxy & bientôt Android : split view
Les tablettes chinoises qui masquent leur user agent
Les tablettes Windows 8, les laptops win7/ win8
Les technologies de déportation d’écran : Airplay, Allshare, Smartglass, ..
54. LES MÉDIAS
LE PRINCIPAL ENJEU DES MEDIAS :
ADRESSER LES BONNES IMAGES
1ÈRE SOLUTION /
UTILISER LE USER-AGENT (BROWSER SNIFFING)
La liste de user-agents ou la base de donnée
sera-t-elle toujours à jour ?
Seul le client connaît sa résolution au
moment de son usage
Pouvons-nous penser que un device = une taille d’écran ?
!
Fonctionnalité Galaxy & bientôt Android : split view
Les tablettes chinoises qui masquent leur user agent
Les tablettes Windows 8, les laptops win7/ win8
Les technologies de déportation d’écran : Airplay, Allshare, Smartglass, ..
55. LES IMAGES, LE VRAI CHALLENGE DU FLUIDE
RÉSOLUTION
ECRAN
QUALITÉ DE
L’IMAGE
Laptop
en fibre
Télévision 4k
en bas débit
Galaxy Note 2
en 4g
Netbook
en wifi
Windows surface
en 3g
Iphone 5
en edge
BANDE
PASSANTE
56. LES IMAGES, LE VRAI CHALLENGE DU FLUIDE
RÉSOLUTION
ECRAN
QUALITÉ DE
L’IMAGE
Laptop
en fibre
Télévision 4k
en bas débit
Galaxy Note 2
en 4g
!
Résolutions d’écrans &
capacité réseau
ne sont désormais plus liés Netbook
en wifi
Windows surface
en 3g
Iphone 5
en edge
BANDE
PASSANTE
57. LES POINTS D’ACTION
Deux problématiques à travailler :
1
LA
BONNE IMAGE
PAR DEVICE
2
Utilisation native de l’api
w3c network information asap
1
LE
CHARGEMENT
Mise en place d’un polyfill
de détection de bande passante
Participation à la réflexion w3c autour de
l’implémentation de la balise picture et d’autres
solutions
2
Support du RETINA par le pattern 2x
3
Pas de double hit de téléchargement
58. SÉLECTION DE LA BONNE IMAGE
Le w3c et ses participants
évoquent trois pistes encore à l’état de brouillon
PICTURE
ELEMENT
SRC SET
SRC N
CLIENTS
HINT
59. NOS ORIENTATIONS À DATE
PICTURE
ELEMENT
SRC SET
SRC N
CLIENTS
HINT
Aucune solution n’est implémentée par les navigateurs pour le moment.
Il s’agit de trouver celle qui paraît la plus pertinente et d’utiliser/réaliser un
polyfill.
Les contraintes habituelles doivent être respectées
SEO
ACCESSIBILITÉ
PERFORMANCE
Pour le moment nous avons testé et éprouvé sur nos projets la solution
« picture element » qui nous a donné satisfaction.
Mais la communauté s’engage de plus en plus sur la solution src N
60. LES VIDÉOS
L’utilisation de la balise HTML5 vidéo induit un
nombre conséquent de types de sources.
Navigateur / Device
Formats Vidéo
Encodage Audio
Chrome
MP4*, WebM
AAC, MP3, Vorbis
Firefox
MP4, WebM
AAC, MP3, Vorbis
Internet Explorer 9+
MP4
AAC, MP3
Safari
MP4
AAC, MP3
iOS
MP4
AAC, MP3
Android
MP4
AAC, MP3
Opéra
WebM
Vorbis
* Chrome a annoncé qu’ils allait arrêter
le support du MP4 mais ne l’ont jamais fait
61. LES VIDÉOS
DES PLATEFORMES
existent et adressent déjà les différents écrans.
C’est à ces plateformes d’adresser les problématiques de
mobilité liées aux différences de formats et à la bande passante
62. PERFORMANCE
L’ENJEU MAJEUR EST D’ARRIVER À :
• Un site en responsive web design mais qui prend en compte les
exigences du public mobile
• Une vitesse de chargement des pages exemplaire
• Un ressenti utilisateur idéal
LA PERFORMANCE WEB EST AU CŒUR D’UNE BONNE EXPÉRIENCE UTILISATEUR
63. PERFORMANCE
Viewport
Optimiser ce que l’utilisateur
voit :
• LazyLoad des images au scroll
• Chargement des blocs à la
volée
Un kit HTML, JS, CSS léger
Les blocs sont non visibles, donc
inactifs et les images ne sont pas
chargées
et adapté au mobile
Ne pas hésiter à abaisser le
rendu des devices lents
Compresser les scripts
COMPRESSER LES IMAGES
64. PERFORMANCE, KPI
DES INDICATEURS TECHNIQUES CLÉS DE PERFORMANCE
Start Render (time to glass)
Le moment précis où la page commence à s’afficher et le contenu texte est
disponible.
Page Load
Moment où la page et ses contenus sont entièrement chargés (tous les
scripts et toutes les images)
Il vaut mieux privilégier l’optimisation du start-render qui permet d’offrir
une performance ressentie optimale à l’utilisateur.
Au cours de la navigation les autres éléments se chargent.
65. DES PARCOURS ADAPTÉS
Les medias-queries adaptent la forme,
pas le fonctionnel
EX
Un tunnel d’achat sur smartphone
ne doit pas avoir les mêmes champs et
les mêmes étapes
que sur ordinateur
IL S’AGIT DONC D’ADAPTER LE PARCOURS AU DEVICE
RESS / RESPONSIVE & SERVER-SIDE COMPONENTS
67. LA CONTRIBUTION
Les outils de contribution, CMS, doivent s’adapter au
responsive web design :
LE CMS DOIT PERMETTRE
• D’adresser des visuels adaptés à chacun des écrans
• De les redimensionner
• De gérer les vidéos provenant de plateformes externes
• De gérer les différences fonctionnelles
• D’adapter le contenu
• De visualiser sur les différents formats
68. UN PETIT MOT SUR LE SEO
Que pense Google
du responsive web design ?
https://developers.google.com/webmasters/smartphone-sites/
71. LA RECETTE CÔTÉ DEV
AUTOMATISER pour éviter les régressions
Mettre en place une couverture de tests unitaires côté JS/CSS
• Karma & Jasmine
Mettre des tests de navigation
• PhantomJS + Casper
• Sélénium
Automatiser les tests de rendu multi device :
• testSwarm
72. LES OUTILS DU CHEF DE PROJET
Des « bookmarklets » responsive
• Resizer
• Etc…
Un outil permettant de forcer le User-Agent
• Chrome tools
• Plugins firefox
Les simulateurs
• Android (installer le SDK)
• iOS (être sous Mac OSX et installer Xcode)
Des machines virtuelles
• VirtualBox + Modern.ie (une bonne solution gratuite et cross OS)
DES SMARTPHONES, pour les tests finaux
• Rien ne remplace le test sur mobile, notamment pour juger de la
performance et des problématiques spécifique à l’accélération 3D
ou aux évènements
74. UN SITE RESPONSIVE OU ADAPTIVE ?
RESPONSIVE
WEB DESIGN
Le contenu est fluide et réagit pour
s’adapter à n’importe quelle taille
d’écran et type de format.
75. UN SITE RESPONSIVE OU ADAPTIVE ?
ADAPTIVE
WEB DESIGN
Le contenu va être modifié selon des
formats et types d’écrans prédéfinis.
76. IL FAUT PENSER À L’USAGE
“
La première chose que vous devez faire
est d’oublier les buzzwords et autre jargon
et vous concentrer sur les besoins réels
de votre entreprise.
Christina Warren
http://mashable.com/2013/08/06/responsive-vs-native-app/
77. UN SITE RESPONSIVE OU ADAPTIVE ?
Le responsive, ce n’est pas qu’adapter du contenu à un
écran mobile
Un site mobile nécessitant un fonctionnel particulièrement
différent de celui présent sur le site desktop ne devrait pas
être en RWD
• Géolocalisation
Un site très lourd de type RIA ne devrait pas se retrouver tel
quel sur mobile
• Facebook
• Gmail
Un site dont le contenu doit être adapté au support ne se
prête pas au RWD
• Ligne éditoriale spécifique au mobile
78. DU FLUIDE POUR LE SMARTPHONE
Ne pas faire de responsive
ne signifie pas pour autant
un layout fixe.
≠
Un site mobile doit être adapté à tous
les mobiles et orientations et utilisera
donc certains aspects du package
« responsive »
• Medias-queries pour adapter polices et
organisation du layout
• Layout fluide pour gérer les différences
de formats entre mobile (Galaxy S4 vs.
Note 3 vs. iPhone 5s etc…
• Adaptives images pour offrir l’image
optimale par support
80. POUR RÉSUMER
1 Le responsive n’est pas un raccourci
2 Ce n’est pas une technologie, c’est une
méthodologie et des avancées techniques
3 Il implique une grosse phase de conception
4 Il a des enjeux techniques, qui sont parfois
insolubles
5 Il doit être implémenté sur un projet en toutes
connaissances de cause
6 RESS semble être un bon compromis pour
permettre des parcours fonctionnels idéaux partout
81. MERCI !
Ekino
157, rue Anatole France
92300 Levallois-Perret
@3k1n0
@NewsDuFront
www.ekino.com