Conception réactive: pourquoi vous le faites mal

La conception réactive n'est pas une mode qui est née à cause d'une technique CSS cool, c'est une réponse à un problème. Souvenez-vous toujours de cela et demandez-vous constamment si vous résolvez vraiment ce problème. Si vous utilisez le copier-coller pour insérer vos points d'arrêt de requête multimédia, votre solution peut être défectueuse.

Voyons pourquoi les requêtes médiatiques existent et comment nous pouvons les exploiter pour vraiment résoudre le dilemme du web omniprésent. Voyons pourquoi vous devez laisser votre contenu déterminer les points d'arrêt d'une mise en page, et non des tailles d'écran hypothétiques.

Cet article fait partie de notre série sur «regarder au-delà de la conception de bureau», présentée en partenariat avec Heart Internet VPS.

L'idée derrière les requêtes médiatiques

Pour entamer ce débat correctement, il est nécessaire de discuter de la raison pour laquelle les requêtes des médias sont soudainement devenues si populaires. La réponse est bien sûr que «Responsive Design», un terme inventé par Ethan Marcotte, est un moyen fantastique de résoudre un problème toujours croissant pour les concepteurs de sites Web.

Alors que tout le monde se déchaînait sur la façon dont le «web mobile» allait dépasser le traditionnel, la révolution qui a eu lieu était beaucoup plus radicale: le web est devenu omniprésent.

Ce «problème» est grand pour le monde dans son ensemble, mais c'est un vrai casse-tête pour nous. Au cours de la dernière décennie, le Web mondial s'est transformé en quelque chose de nouveau. Il n'est plus lié par les murs que nous avions précédemment établis. Je l'ai déjà dit, mais cela vaut la peine d'être répété. Alors que tout le monde se déchaînait sur la façon dont le «web mobile» allait dépasser le traditionnel, la révolution qui a eu lieu était beaucoup plus radicale: le web est devenu omniprésent.

Pour l'instant, nous n'accédons pas au Web à partir d'un seul point. Nous n'avons pas abandonné nos ordinateurs portables au profit des smartphones comme l'avaient prédit les «experts». Au lieu de cela, le Web est partout où nous sommes. Ce n'est pas seulement dans nos téléphones et ordinateurs, c'est dans nos tablettes, iPod, systèmes de jeux, téléviseurs et même voitures.

Cette tendance ne se poursuivra qu'avec le temps. Le design réactif nous fait passer une saison de création de sites mobiles distincts et nous entrons dans une ère où nous développons un site qui évolue et s'adapte à l'appareil sur lequel il est consulté. À l'aide de requêtes multimédias, nous pouvons présenter des CSS spécifiques à un nombre illimité de tailles de fenêtres et nous assurer que tout le monde a la meilleure expérience possible.

Le problème de la conception réactive

La section ci-dessus n'est pas une diatribe semi-historique destinée à remplir l'espace, c'est un regard important sur les objectifs que le design réactif est censé atteindre. La question devient alors: atteint-elle ces objectifs? La conception réactive résout-elle adéquatement le problème de l'ubiquité?

La réponse est compliquée, au mieux je peux dire, "cela dépend de la façon dont vous le faites." C'est une déclaration déroutante, n'est-ce pas? La conception réactive est simple: utilisez des requêtes multimédias pour proposer des CSS personnalisés à différentes tailles de fenêtres. C'est ainsi que tout le monde l'aborde, non? Alors, comment peut-il y avoir une bonne et une mauvaise voie?

La complexité survient lorsque nous commençons à discuter d'une partie cruciale de cette technique: quelles requêtes multimédias dois-je utiliser? Ou, autrement dit, quels «points d'arrêt» dois-je cibler pour les CSS personnalisés? La réponse populaire actuelle commence de manière prévisible avec les meilleurs appareils «mobiles» du marché: l'iPhone et l'iPad (signalez les commentaires des utilisateurs Android en colère). À partir de ces archétypes, nous établissons des tailles de smartphones et de tablettes dites «génériques». Ensuite, nous montons et abordons les ordinateurs portables et les petits ordinateurs de bureau et enfin les grands écrans. Un ensemble standard de requêtes multimédias, comme celui de CSS-Tricks, a généralement neuf ou dix points d'arrêt préétablis.

Et si nous nous concentrions sur les besoins d'une conception spécifique au lieu d'un cas d'utilisation hypothétique de l'appareil? Et si nous construisions des dispositions qui fonctionnaient simplement partout?

Pour être juste, ce système fonctionne dans une certaine mesure. Nous avons tous vu de nombreux sites réactifs construits à l'aide d'un ensemble similaire à celui de Coyier ci-dessus. Cependant, je ne peux m'empêcher de penser que cela répète en quelque sorte la même erreur que nous avons commise en concevant des «sites mobiles» il y a quelques années. Ici, l'accent est mis sur l'appareil qui visualise le site. Avant même de construire le site, nous avons ces points d'arrêt à l'esprit.

Mais les appareils changent. Nous avons déjà établi que le Web est connecté à presque tout avec un interrupteur d'alimentation, alors pourquoi insistons-nous encore une fois sur les tailles d'écran courantes? Existe-t-il une meilleure alternative? Et si nous nous concentrions sur les besoins d'une conception spécifique au lieu d'un cas d'utilisation hypothétique de l'appareil? Et si nous construisions des dispositions qui fonctionnaient simplement partout?

Conception réactive axée sur le contenu

Les problèmes susmentionnés avec les requêtes médias préétablies ne m'ont été rencontrés que lorsque j'ai creusé et commencé vraiment à produire du travail réactif par moi-même. En théorie, les suggestions standard sont excellentes mais une fois que vous les appliquez à une conception complexe, vous découvrirez que ces points d'arrêt ne la couvrent pas toujours. Le problème, comme les concepteurs du Boston Globe l'ont rapidement découvert une fois le site mis en ligne, est que des problèmes surviennent «entre les deux» (pour mémoire, ce projet est fantastique et tous les problèmes de mise en page ont été largement résolus). Les choses deviennent désordonnées lorsque la conception est à une taille que vous n'avez pas prise en compte et que vous devez aller réparer les trous après coup.

Je dis cela en tant que fanboy d'Apple: arrêtez de concevoir des sites Web pour l'iPhone.

Ma question est, pourquoi ne commençons-nous pas là? Au lieu de se lancer dans un projet avec un ensemble d'appareils, et par conséquent des requêtes médiatiques, à l'esprit, pourquoi ne laissons-nous pas le design décider? Chaque mise en page Web a un point où la taille du navigateur diminue son intégrité. Notre travail en tant que concepteurs, à la lumière du problème de l'ubiquité, devrait être de trouver cette taille et d'en tenir compte, puis de faire mousser, rincer et répéter jusqu'à ce que tous les points faibles soient pris en compte.

Je dis cela en tant que fanboy d'Apple: arrêtez de concevoir des sites Web pour l'iPhone. Au lieu de cela, concevez un site Web qui conserve son intégrité car la taille de sa fenêtre d'affichage est réduite à tout état possible. Gardez à l'esprit des appareils spécifiques comme guide pour votre conception (exemple: les petits appareils ont tendance à être tactiles, alors faites des liens volumineux), mais ne mettez pas vos oeillères et ne regardez pas la situation dans son ensemble: que votre conception devrait bien paraître sur n'importe quel écran.

Un nouveau workflow

À quoi ressemble un workflow de conception réactive orientée contenu? C'est plus simple que vous ne le pensez. De toute évidence, vous avez besoin d'un point de départ quelconque. Si vous voulez démarrer sur mobile et monter, c'est parfait. Si vous voulez commencer grand et redescendre, c'est super aussi. Personnellement, je trouve très difficile de vraiment creuser dans un design et de le faire correctement si je commence au niveau mobile, mais il existe de nombreux arguments solides pour le faire de cette façon.

Quelque chose de magique se produit lorsque vous suivez ce flux de travail.

En théorie, supposons que vous commenciez avec un grand site de 1 020 pixels de large. Vérifiez-le sur le plus grand écran sur lequel vous pouvez mettre la main et assurez-vous qu'il a fière allure. Faites maintenant glisser la fenêtre et réduisez-la jusqu'à ce que le design devienne laid. Voilà votre premier point d'arrêt. Définissez une requête multimédia pour ce point et corrigez tout ce dont vous avez besoin. Une fois que vous avez terminé, saisissez cette fenêtre et trouvez le prochain point de laideur. Répétez ces étapes jusqu'à ce que vous soyez satisfait de la plage que vous avez prise en compte.

Mais qu'en est-il de l'iPad? Qu'en est-il du Kindle Fire ou de la dernière tentative de Samsung d'être pertinent? Quelque chose de magique se produit lorsque vous suivez ce flux de travail. Vous venez de faire en sorte que la mise en page soit bonne à peu près n'importe quelle taille. Si vous l'avez bien fait, alors lorsque vous le tirerez sur votre téléphone ou votre tablette, cela aura fière allure.

Disposition uniquement
Gardez à l'esprit que cette discussion se réfère uniquement aux ratios de mise en page. Vous ne sortez absolument pas des tests de fonctionnalité sur différents navigateurs et appareils. La conception réactive ne fait rien pour expliquer le fait que différents moteurs de navigation interprètent différemment HTML, CSS et JavaScript.

Conclusion

Pour résumer, les requêtes médiatiques et la conception réactive nous fournissent un outil incroyablement puissant pour tenir compte du fait que les sites Web sont consultés par toutes sortes d'écrans et de tailles de fenêtres. Cependant, une fois que nous avons commencé à rattacher nos conceptions à une poignée d'appareils, nous sommes de retour là où nous avons commencé. Votre objectif devrait plutôt être de créer une mise en page si polyvalente qu'elle puisse gérer presque toutes les tailles de fenêtres.

Tout cela est bien en théorie, mais où est l'exemple? Le point de départ de cette discussion est venu d'une récente tentative de ma part de construire une galerie d'images réactive. Consultez cet article pour voir à quoi pourrait ressembler un flux de travail de conception réactive orienté contenu.