Sur les meilleures pratiques en matière de conception Web réactive

Bonjour,

Je travaille sur un projet qui implique la création d'un site Web réactif et je contacte cette communauté pour obtenir des conseils et des bonnes pratiques.

Spécifiquement; Je m'efforce de garantir que le site Web offre une expérience utilisateur optimale sur différents appareils ; des ordinateurs de bureau aux smartphones. Bien que j'aie fait quelques recherches et mis en œuvre plusieurs techniques telles que les requêtes multimédias et les dispositions de grille flexibles ; Je cherche à affiner mon approche et à en apprendre davantage sur les stratégies avancées.

Comment déterminer les meilleurs points d’arrêt pour différents appareils ? Existe-t-il des outils ou des méthodes que vous utilisez pour tester et optimiser efficacement ces points d'arrêt ?

Flexbox vs Grid Layout : dans quels scénarios préférez-vous utiliser Flexbox plutôt que CSS Grid ? ou vice versa? Je suis curieux de savoir comment ces modèles de mise en page fonctionnent dans les conceptions réactives et de connaître les conseils pratiques que vous pourriez avoir pour les exploiter.

Quelles sont vos techniques de prédilection pour garantir qu'un site réactif se charge rapidement sur tous les appareils ? Des recommandations pour optimiser les images ou minimiser CSS/JavaScript pour améliorer les performances ?

Suivez-vous des pratiques spécifiques pour vous assurer que les conceptions réactives sont également accessibles aux utilisateurs handicapés ?

Merci d'avance pour votre aide et votre assistance.
Modifié par besossenorita (25 Jul 2024 - 08:27)

Bonjour,

Avant tout il ne faut pas confondre "réactif" et "responsive", a priori si je pars de ce que vous décrivez vous évoquez plutôt le responsive design.

Alors la première chose à savoir c'est qu'il faut coder en mobile first. Je vous laisse rechercher ce que signifie ces mots clés de manière fine mais, pour l'instant, disons qu'il s'agit de coder en priorité pour les téléphones mobiles et ensuite de surcharger les règles CSS pour les ordinateurs de bureau.

Les points de rupture, c'est la structure du site web qui les détermines, pas les devices des appareils des utilisateurs*** : premièrement il y aurait beaucoup trop de modèles à prendre en compte, ensuite c'est bien plus logique de régler les points de rupture par rapport à la structure du site.

Pour ce faire vous avez dû entendre parler des Media Queries. Ça, c'était à l'époque de grand papa, maintenant on a les Container Queries. Mais avec les systèmes de grilles actuels (grid et flex) il y a beaucoup de cas de figure où vous pouvez même carrément vous en passer.

Flexbox vs grid : le premier a tendance à se structurer par rapport à son contenu, le deuxième par rapport au template du site. Par exemple, pour la structure d'un site web, grid layout est à préférer. En plus ça sera plus performant.

Pour auditer le front de votre site commencez par utiliser un des outils les plus importants disponible gratuitement dans la console d'inspection de votre navigateur Chrome : Lighthouse. Ça vous donnera des informations sur la structure front de votre code, sur les performances, sur le localStorage, sur l'accessibilité, etc ; avec des conseils pratiques et éventuellement des ressources à lire pour comprendre le pourquoi du comment (par exemple, pour les images, utiliser les attributs srcset et compression WEBP ou AVIF plutôt que du JPEG).

L'accessibilité est un monde en soit, difficile à retranscrire ici. Disons-le clairement : entre les préconisations théoriques et le concret de ce que peuvent faire les lecteurs d'écrans il peut y avoir un monde et pour le développeur c'est le foutoir complet (un peu moins dernièrement). On a parfois l'impression d'être un voyant qui doit retranscrire en braille un livre a destination de non voyants (pour ne citer qu'eux) avec pour outils un vieux dictionnaire braille incomplet et pas à jour qui donnera des certitudes qui au final se révèleront fausses, mais on ne s'en apercevrait que très tard car on a du mal à avoir un retour sur ce que l'on produit à ce niveau. C'est incroyable le nombre de croyances à fausses que l'on trouve sur le web à ce sujet. Commencez par utilisez la bonne sémantique pour votre code HTML, une sémantique appropriée et valide, ensuite seulement vous vous pencherez sur les spécifications ARIA.

J'ai survolé toutes les questions - elles étaient un peu nombreuses pour un seul post - pour en venir au plus important maintenant : quoi que vous fassiez codez en composants. Que vous utilisiez des frameworks, qui de toute façon utilisent le plus souvent ce concept, ou que vous codiez vos styles et vos scripts de manière monolithique, ne perdez jamais de vue que vous serez toujours gagnant à décomposer votre code en composants.

Je donne un exemple : j'ai besoin d'un slideshow (ou d'un accordéon, ou d'une série d'onglets, etc) sur une des pages de mon site et pour cela je vais créer des styles et des scripts. Très bien, mais je ne vais pas réfléchir à la manière dont je vais l'intégrer seulement pour cette unique page, mais potentiellement pour toutes les pages web de mon site, et même plusieurs fois sur une page. Du coup tout le code développé va s'en ressentir (je ne vais pas cibler une unique ID dans une page mais plutôt une classe CSS générique que je récupérerai dans un tableau JavaScript, etc). C'est sans doute le conseil le plus précieux que de mon côté je pourrais vous donner. Les points évoqués plus haut vous les trouverez aisément en ligne, mais cette histoire de composants il ne faut pas passer à côté.

___
*** Ça c'est pour la beauté de la théorie mais dans la pratique ce n'est pas toujours vrai : à la sortie du premier iPhone les dev's de Facebook avaient plié leur site web en quatre pour le rendre compatible avec le device du iPhone de première génération. Hors de question d'imaginer que le site ne soit pas optimisé pour le téléphone le plus hype du moment.

Modifié par Olivier C (25 Jul 2024 - 22:16)