- Les services GOV.UK doivent fonctionner selon une approche HTML d’abord afin que les utilisateurs puissent accomplir leurs tâches essentielles, quels que soient le navigateur, l’appareil ou l’état de la connexion, et l’amélioration progressive est requise pour tous les services publics
- Le HTML possède une tolérance aux pannes : il ignore les balises qu’il ne connaît pas et continue l’analyse, ce qui augmente les chances de préserver la navigation et les fonctions de base même sur des navigateurs anciens ou des pages comportant certaines erreurs
- Le CSS et le JavaScript sont des couches plus fragiles : en CSS, un ensemble de règles peut être ignoré si un sélecteur n’est pas reconnu, et en JavaScript, une syntaxe non prise en charge ou une erreur d’API peut interrompre l’exécution du reste du code
- Le JavaScript doit servir à améliorer le HTML et le CSS plutôt qu’à remplacer les fonctions essentielles, et même un champ d’autocomplétion doit reposer sur un élément natif comme
<select>afin que l’utilisateur puisse continuer si cela échoue - Les frameworks JavaScript côté client et les SPA peuvent créer des contraintes de performance, d’accessibilité et de maintenance ; ils ne sont donc pas nécessaires pour des services centrés sur le GOV.UK Design System plutôt que sur une interface complexe
Principes de base de l’amélioration progressive
- Un service de qualité doit être conçu de manière robuste, et l’amélioration progressive est une approche qui consiste à faire fonctionner sites web et applications à partir du HTML
- On construit d’abord le fonctionnement de base en HTML, puis on n’ajoute qu’ensuite des couches comme le CSS et le JavaScript
- Tous les services publics doivent suivre l’amélioration progressive, même si une partie du service ou un service parent nécessite du JavaScript
- L’amélioration progressive apporte les bénéfices suivants
- le service devient plus robuste et de meilleure qualité
- il a davantage de chances de fonctionner quel que soit le navigateur ou l’appareil
- les fonctions les plus fondamentales marchent et répondent aux besoins essentiels de l’utilisateur
- elle encourage les bonnes pratiques comme le balisage sémantique, ce qui améliore l’accessibilité
- elle facilite l’usage du service pour les personnes ayant des contraintes d’appareil ou de connexion
- Si vous utilisez une solution COTS ou confiez le service à un prestataire externe, il faut envisager d’inclure l’amélioration progressive dans les exigences de la stratégie d’achat
Commencer par le HTML
- Les services publics doivent fonctionner avec le HTML seul
- Exemples de services devant fonctionner avec le HTML seul
- des services transactionnels comme des formulaires où l’utilisateur fournit des informations à l’administration
- des services de type smart answers, par exemple Registering a birth abroad
- des sites axés sur le contenu comme les foreign travel advice de GOV.UK
- La couche HTML est tolérante aux pannes par conception
- le navigateur ignore les balises qu’il ne comprend pas et continue autant que possible l’analyse du document
- même s’il y a des bugs dans le HTML ou si des fonctionnalités réservées aux navigateurs récents sont utilisées, un navigateur ancien a de bonnes chances de pouvoir charger le service
- L’utilisateur doit pouvoir naviguer dans le service avec le HTML seul
- Il faut utiliser un balisage sémantique correct et organiser logiquement l’ordre source et la structure du document
Comment utiliser le CSS
- Le CSS peut être utilisé pour donner au service l’apparence de GOV.UK
- La couche CSS est relativement tolérante aux pannes
- le navigateur ignore les déclarations individuelles qu’il ne comprend pas
- si vous utilisez une propriété réservée aux navigateurs récents, seule cette déclaration peut être ignorée
- En revanche, si le navigateur rencontre un sélecteur qu’il ne comprend pas, il peut ignorer tout l’ensemble de règles
- Le CSS peut ne pas se charger pour diverses raisons
- Pour que le site conserve une apparence correcte même si le JavaScript ne se charge pas, il faut éviter des techniques comme le CSS-in-JS
Comment utiliser le JavaScript
- Le JavaScript peut être utilisé pour ajouter des éléments interactifs au service
- La couche JavaScript n’est pas tolérante aux pannes
- si le navigateur de l’utilisateur rencontre une syntaxe ou un appel d’API non pris en charge, une erreur se produit
- en cas d’erreur, le reste du JavaScript ne s’exécute pas
- Si le service est conçu sans tenir compte de cette possibilité, l’utilisateur peut se retrouver dans l’incapacité de l’utiliser
- Voici comment augmenter les chances que le JavaScript fonctionne correctement dans différents navigateurs
- utiliser la détection de fonctionnalités pour les API navigateur
- inclure des polyfills pour les fonctionnalités des navigateurs récents
- transpiler le JavaScript vers une syntaxe commune comprise par les navigateurs cibles
- utiliser des tests automatisés ou un linter
- effectuer des tests manuels réguliers, y compris sur des appareils anciens ou peu performants
- La transpilation et les polyfills peuvent fortement augmenter la taille du JavaScript
- il faut en prendre en compte les compromis
- comme l’usage des navigateurs évolue, ces décisions doivent être réévaluées régulièrement
- Lorsque c’est possible, le JavaScript doit améliorer un HTML et un CSS qui fournissent déjà la même fonction essentielle
- un champ d’autocomplétion peut être conçu comme une amélioration d’un élément
<select>ou d’un autre élément natif similaire - même si le JavaScript échoue, l’utilisateur peut continuer à effectuer l’action nécessaire
- un champ d’autocomplétion peut être conçu comme une amélioration d’un élément
Alternatives au JavaScript et canaux complémentaires
- Si l’on estime qu’un service ne peut être réalisé qu’en JavaScript, il faut d’abord vérifier si une solution plus simple en HTML et CSS peut répondre aux besoins des utilisateurs
- Si vous envisagez de proposer des graphiques interactifs en JavaScript, vous pouvez envisager les alternatives suivantes
- afficher les données sous forme de tableau
- permettre l’export des données pour qu’elles puissent être analysées dans une autre application
- pré-rendre le graphique sous forme d’image
- Si la fonction essentielle du service ne peut pas être fournie sans JavaScript, il faut offrir à l’utilisateur un autre moyen d’utiliser le service
- téléphone
- visite au bureau
Frameworks JavaScript côté client
- Si le service est principalement composé de composants du GOV.UK Design System et n’a pas d’interface complexe, il n’a pas besoin d’un framework JavaScript côté client
- Les composants du GOV.UK Design System incluent une méthode pour intégrer du JavaScript dans un service sans framework
- Les frameworks JavaScript côté client peuvent être utiles pour construire des interfaces complexes, mais ils peuvent aussi introduire plusieurs problèmes
- Les problèmes potentiels liés à l’usage d’un framework sont les suivants
- augmentation de la taille globale du code et déplacement du traitement côté client, ce qui peut créer des problèmes de performance pour les personnes sur réseau lent ou appareil peu puissant
- dépendance à du code tiers que les développeurs ne contrôlent pas, ce qui peut imposer des changements importants au service pour suivre l’évolution du framework
- avec le temps, si le framework perd en popularité, il peut devenir difficile de trouver des personnes ayant les compétences nécessaires pour le maintenir
- Si vous utilisez un framework JavaScript, vous devez remplir les conditions suivantes
- pouvoir justifier par des preuves le bénéfice apporté aux utilisateurs par l’usage de JavaScript
- connaître les impacts négatifs et être capable de les atténuer
- vérifier que les bénéfices l’emportent sur les problèmes potentiels
- n’utiliser le framework que pour les parties de l’interface impossibles à réaliser avec le HTML et le CSS seuls
- concevoir chaque partie de l’interface comme un composant distinct
- La séparation en composants permet, si le chargement du JavaScript échoue, de limiter l’échec à ce seul composant tandis que le reste de la page continue à se charger normalement
- Le JavaScript doit uniquement servir à améliorer le HTML et le CSS, et l’utilisateur doit pouvoir continuer à utiliser le service même en cas d’échec
Pourquoi le CSS et le JavaScript peuvent échouer
- Le CSS et le JavaScript peuvent ne pas se charger ou ne pas s’exécuter pour de nombreuses raisons
- erreur réseau temporaire
- extension de navigateur tierce comme un bloqueur de publicité
- indisponibilité d’un fournisseur tiers lors de l’usage d’un réseau de diffusion de contenu
- échec de résolution DNS
- bug introduit par une mise à jour du navigateur
- bug dans un JavaScript tiers exécuté délibérément sur la même page
- pare-feu d’entreprise utilisés dans de grandes organisations comme des banques ou des administrations qui bloquent, suppriment ou modifient le contenu
- opérateurs de réseau mobile qui modifient le contenu pour réduire le temps de chargement et la consommation de bande passante
- pare-feu personnels ou logiciels antivirus qui modifient ou bloquent le contenu
- fournisseur d’accès à Internet qui injecte son propre code dans la page sur une connexion non sécurisée, et ce code entre en conflit avec celui du service
- Certains utilisateurs peuvent désactiver volontairement des fonctionnalités du navigateur
- Le service doit respecter ce choix et rester utilisable pour ces utilisateurs
Pourquoi il faut éviter les applications monopage (SPA)
- Il ne faut pas construire le service comme une application monopage (SPA)
- Une SPA est une approche dans laquelle le chargement des pages du service est géré par le JavaScript plutôt que par le navigateur
- Les SPA apportent peu d’avantages et peuvent nuire à l’accessibilité
- les personnes utilisant des technologies d’assistance peuvent ne pas être informées qu’un changement de contexte équivalent à une nouvelle page a eu lieu
- la gestion du focus lors des changements de page peut ne pas fonctionner correctement
- les utilisateurs peuvent ne pas pouvoir naviguer avec les boutons précédent et suivant du navigateur
- ils peuvent ne pas réussir à se rétablir après des erreurs comme une coupure de connexion réseau
Critères de test
- Si certains composants du service dépendent fortement du JavaScript ou d’un framework JavaScript, il faut vérifier les points suivants
- ils fonctionnent sur différents navigateurs et appareils
- ils fonctionnent avec des technologies d’assistance
- ils passent des tests garantissant de bonnes performances
- Lorsque c’est possible, il faut vérifier au moyen de tests d’accessibilité que ces composants fonctionnent correctement dans le service
1 commentaires
Avis sur Hacker News
« Si vous utilisez un framework JavaScript, vous devriez pouvoir justifier par des arguments en quoi l’usage de JavaScript bénéficie à l’utilisateur » : calmons-nous un peu
Un bon critère est le suivant : si l’app peut fonctionner en offline-first, comme une application de bureau, alors il est acceptable d’en faire une application monopage
Photopea, Google Docs/Sheets, tldraw en sont des exemples ; dans ces cas, cela peut être plus réactif et meilleur qu’une app navigateur multipage
Ainsi, les principaux inconvénients — la navigation entre pages et la nécessité d’une connexion Internet — disparaissent
Mais si l’app a besoin d’une connexion Internet et de plusieurs pages, mieux vaut laisser le navigateur gérer la navigation de façon robuste face aux pannes
Si vous avez besoin de quelque chose de type GUI de bureau, hors ligne ou sur plusieurs systèmes d’exploitation, une application monopage est avantageuse ; si vous voulez simplement créer un site web, une application monopage n’est peut-être pas optimale
L’application monopage en soi et la complexité nécessaire pour la créer sont deux choses différentes
J’ai commencé le web quand j’étais enfant, dans les années 90. Je ne savais même pas ce qu’étaient CSS ou JS, et pour moi JS se limitait à copier-coller des scripts magiques qui faisaient clignoter des trucs
Plus tard, j’ai créé des sites dynamiques en PHP pour des entreprises locales, et j’ai alors appris un peu de JS et de CSS
Puis j’ai arrêté le développement web parce que j’en avais assez de passer trop de temps à faire fonctionner les choses dans des navigateurs horribles comme IE6
Je m’en suis éloigné pendant près de six ans, puis je suis revenu vers 2015, quand j’ai compris qu’un serveur web serait utile pour mon travail
Et j’ai été choqué de voir que le monde avait oublié beaucoup de ce qu’on savait autrefois sur HTML et CSS
Avant, on créait plusieurs feuilles de style pour un site ; on le faisait d’abord fonctionner sans JS, puis on ajoutait JS comme amélioration progressive. Cette approche a été oubliée
J’ai aussi vu des développeurs web faire toute la validation de formulaires uniquement en JS, sans rien côté serveur ; étonnamment, c’est encore courant aujourd’hui
Le schéma pourtant classique où le serveur valide et où JS ne fait qu’afficher le résultat semble mal connu. Tout le monde a l’air soit de dupliquer l’implémentation, soit de ne pas faire de validation serveur du tout
Après avoir vu ça, ce que les gens faisaient sur le web ne m’impressionnait plus. Ce n’était plus le web que je connaissais, seulement des « applications » faites en JS, et défendre une approche web d’abord était une bataille perdue
J’ai commencé enfant avec HTML 3.2/XHTML et CSS, puis quelques années plus tard j’ai travaillé avec Django + jQuery, avant de m’intéresser davantage à l’infra
Il y a environ un an, j’ai travaillé avec une équipe de développement web et j’ai regardé ce qu’ils faisaient : je ne comprenais plus rien
La complexité était écrasante, et ils semblaient passer la majeure partie de leur temps à faire de la gestion de complexité : réduire les temps de build, résoudre des problèmes de dépendances, traiter des problèmes TypeScript bizarres, gérer les erreurs entre plusieurs composants
À l’époque Django+jQuery, l’accent restait mis sur ce que l’utilisateur pouvait voir et utiliser
Bien sûr, on ne peut jamais faire confiance au client, donc il faut revalider plus tard côté serveur
Réduire la charge serveur est utile
C’est un bon conseil, mais dire que « les utilisateurs de technologies d’assistance ne peuvent pas percevoir le même changement de contexte lorsqu’ils arrivent sur une nouvelle page », que « le focus n’est pas géré lors des changements de page », qu’« il est impossible de naviguer avec les boutons précédent/suivant du navigateur », ou qu’« en cas de perte de connexion réseau, on ne peut pas récupérer après une erreur », ce n’est pas strictement vrai, non ?
Beaucoup, peut-être la plupart, des applications monopages ne s’en préoccupent pas, mais ces choses peuvent aussi être implémentées dans une application monopage
Dès qu’on entre dans le territoire des applications monopages, il faut réinventer beaucoup de roues pour revenir à un niveau équivalent, ou remplacer des fonctionnalités natives par des substituts JS
Prenez les formulaires multipages : combien d’applications monopages stockent tout en mémoire puis n’envoient qu’une seule requête à la fin ?
Sans JS, le backend aurait enregistré l’état à chaque étape, afin qu’on puisse revenir au formulaire plus tard ou rafraîchir sans rien perdre
Pourquoi imposer ce bazar alors qu’un site web HTML de base fonctionne correctement avec ses comportements par défaut ?
Si l’utilisateur n’autorise pas la modification a posteriori de l’historique de navigation, il ne reste qu’une seule option
Construire correctement l’historique du navigateur au moment où l’historique est utilisé
J’aimerais que tout Internet suive ce conseil
Ce qui est ancien redevient nouveau
Ne devrait-on pas privilégier la solution la plus simple possible plutôt que ce qui est à la mode aujourd’hui ?
Ce n’est pas parce que le reste de l’industrie était ivre de JS que tout le monde l’était
Pourquoi Linux ne figure-t-il pas dans cette liste ?
https://www.gov.uk/service-manual/technology/designing-for-d...
Une réponse un peu plus sérieuse, mais dans le même esprit, c’est qu’il existe des dizaines de distributions et, si l’on inclut les forks de la famille Mozilla, une dizaine de navigateurs aussi.
On pourrait choisir une distribution/un navigateur « officiel », mais la base d’utilisateurs de ce choix deviendrait extrêmement réduite.
Même Ubuntu semble représenter environ 1 % de part de marché des systèmes d’exploitation de bureau, d’après des chiffres calculables à partir d’indicateurs indirects.
Question sérieuse : à lire les commentaires, cette approche semble plaire.
Alors pourquoi la tendance générale va-t-elle vers l’utilisation de frameworks comme React et de JavaScript, parfois inutilement ?
C’est léger, la mise en page est propre, l’accessibilité est bonne, et ça fonctionne généralement avec un minimum de JavaScript, voire sans JavaScript du tout.
À l’inverse, je n’aime pas la plupart des applications monopages. Elles cassent beaucoup de fonctionnalités attendues du navigateur, sont inutilisables sans JavaScript et chargent souvent toutes sortes de lourdes dépendances depuis plusieurs sites tiers.
Mais ce que les utilisateurs aiment et ce que les développeurs aiment et peuvent construire rapidement sont souvent des choses très différentes.
Une fois qu’une chose est acceptée comme standard de l’industrie, choisir de suivre le mouvement est une décision sûre.
En plus, personne ne fait de relations développeurs pour HTML/CSS/JS pur.
Quand on cherche comment faire quelque chose, presque tout ce qu’on trouve concerne des frameworks.
Si vous écrivez un programme qui tourne sur votre propre ordinateur, vous en payez directement le coût, et vous devez au moins expliquer à la finance pourquoi les coûts cloud ont augmenté de 5 %.
Mais quand vous faites tourner un logiciel sur l’appareil de quelqu’un d’autre, comme un développeur frontend, le coût est presque nul.
Les signaux négatifs doivent passer par des signalements d’utilisateurs, des tickets de support, peut-être des posts sur Twitter, et ce processus comporte beaucoup de biais de sélection, avec un fort risque de ne pas voir l’ensemble du tableau.
Au bout du compte, tout est une question d’incitations.
Le web remplace les clients lourds traditionnels, et ces clients supposaient eux aussi une connexion réseau assez stable et certaines spécifications de plateforme.
Les systèmes gouvernementaux doivent fonctionner sur le plus petit dénominateur commun, même si ce n’est pas fréquent.
Une startup tech peut exister au départ avec un seul client, et croire qu’en grandissant, ses exigences deviendront globalement courantes.
En réalité, je pense que c’est précisément parce qu’ils sont développeurs frontend qu’ils n’aiment pas cette approche : sinon, il ne resterait presque plus de frontend à développer.
C’est aussi la méthode que j’essaie de suivre : servir du HTML avec des données préchargées côté serveur, traiter côté client ce qui peut l’être pour réduire les allers-retours serveur, faire des mises en page responsive avec un minimum de CSS, et utiliser du JS pur.
Si nécessaire, on peut séparer en pages web distinctes.
Pourtant, pour mes collègues, le simple fait d’utiliser seulement HTML, CSS et du JS pur semble sonner bizarre et dépassé.
Il ne manque rien de particulier.
L’article dit aussi qu’utiliser systématiquement uniquement le côté serveur n’est pas du bon génie logiciel.
Il faut noter qu’il dit « peut causer des problèmes », et non « cause des problèmes ».
Les frameworks JavaScript côté client peuvent aider à créer des services avec des interfaces utilisateur complexes, mais ils peuvent augmenter la taille totale de la base de code et déplacer le traitement vers le client, créant des problèmes de performance pour les utilisateurs sur des réseaux lents ou des appareils peu puissants.
Ils peuvent rendre dépendant de code tiers que les développeurs ne contrôlent pas, et nécessiter de gros changements dans le service pour suivre l’évolution du framework.
Si le framework perd en popularité, il peut aussi devenir difficile de trouver des personnes pour en assurer la maintenance.
Si vous utilisez un framework JavaScript, vous devez le justifier par des preuves en montrant quel bénéfice il apporte aux utilisateurs, comprendre et atténuer ses effets négatifs, et déterminer si les bénéfices l’emportent sur les problèmes potentiels.
Il faut aussi ne l’utiliser que pour les parties de l’interface utilisateur qui ne peuvent pas être réalisées uniquement avec HTML et CSS, et concevoir chaque partie comme un composant séparé.
En séparant les composants, si le chargement de JavaScript échoue, seul le composant concerné échoue, tandis que le reste de la page se charge comme d’habitude.