Que fait Pages de proposition GOV.UK ?
Objectif
Produire une page HTML unique et autonome qui argue pour une direction, explique une idée ou présente un changement, en utilisant les styles réels du GOV.UK Design System et une petite bibliothèque de composants réutilisables.
Le principe directeur : montrer le contenu, ne pas le raconter. Une liste de choses qu'une équipe possède devient une grille de cartes. Un ensemble d'étapes devient un flux. Une comparaison devient un tableau avec les différences mises en évidence. Le texte est le tissu conjonctif entre les composants, pas le principal moyen de transporter l'information.
Décrivez le contenu ; cette compétence gère l'apparence.
La sortie est un fichier HTML unique
Les pages créées avec cette compétence sont partagées sous forme de fichiers, souvent téléchargés sur SharePoint ou une bibliothèque de documents similaire et liés à partir de là. Donc :
- Tout réside dans un seul fichier
.html. Le CSS, les polices et les images sont intégrés (polices et images sous forme de Data URIs base64). Pas de feuilles de style externes, de scripts, de polices ou d'images. - La page doit se lire correctement avec JavaScript désactivé. Certaines bibliothèques de documents suppriment ou bloquent les scripts dans les aperçus. Les composants interactifs (comme le sélecteur de vue) sont des améliorations : l'état par défaut affiché sans JavaScript doit être compréhensible en soi.
- Pas d'étape de construction pour le lecteur. Le fichier s'ouvre directement dans un navigateur.
Fichiers
page-starter.htmlest une page vierge : le CSS de GOV.UK Frontend, les polices GDS Transport intégrées en base64, le CSS complet des composants, une bannière de statut, un héros et un pied de page avec un journal des modifications. Chaque nouvelle page commence comme une copie de ce fichier. GDS Transport est sous licence pour une utilisation exclusive sur GOV.UK ; en dehors de GOV.UK, remplacez-la par une autre police de caractères (voirNOTICE.md).docs/index.htmlest la page de documentation pour cette compétence, et elle a été construite avec cette compétence. Sa section « Composants » est la référence visuelle : chaque composant, nommé et étiqueté, avec quand l'utiliser, quand l'éviter, et un exemple en direct. Copiez le balisage des composants à partir des blocsgx-specimen__demo. Ne copiez pas les classesgx-; elles ne stylisent que la page de documentation. Elle utilise le même CSS de composant que le starter, donc le balisage copié fonctionne sans modifications.
Structure du document
Définissez l'argumentation avant de choisir les composants. La plupart des propositions suivent cet ordre ; supprimez les sections dont le contenu n'a pas besoin.
| Section | Ce qu'elle fait | Composants qui conviennent souvent |
|---|---|---|
| Statut et héros | Indique ce qu'est le document et la chose à retenir | Bannière de statut, héros |
| Ce que c'est | Explique l'idée, si le public peut ne pas la connaître | Catégories, éventail, couches, paire de code |
| Ce que cela nous apporte | Les avantages, tôt, pour chaque groupe dans la salle | Grille d'avantages, carte large |
| Pourquoi maintenant | Le problème tel qu'il se présente, avec des preuves | Silos, statistiques, tableau comparatif, plusieurs-vers-un, citation de recherche |
| Comment cela fonctionne | L'approche proposée | Flux, avant et après, hub et rayon, entonnoir, exemple concret |
| Qui possède quoi | Responsabilités | Responsabilités, panneau |
| Par où commencer | Périmètre et ordre | Phases, chronologie |
| Risques | Ce qui pourrait mal tourner | Risque |
| Questions ouvertes | Ce dont vous avez besoin des lecteurs | Questions ouvertes |
| Succès | Comment vous saurez si cela a fonctionné | Mesures de succès, résultat |
| Pied de page | Version et journal des modifications | Journal des modifications |
Placez « Pourquoi maintenant » en premier uniquement lorsque les lecteurs comprennent déjà l'espace de solution (voir « Principes éditoriaux »).
Catalogue des composants
Chaque composant a un nom. Les personnes utilisant cette compétence peuvent demander des composants par leur nom (« utilisez un entonnoir pour montrer d'où viennent les candidatures »), et vous devez utiliser les mêmes noms lorsque vous les suggérez. La section « Composants » de docs/index.html montre chacun en direct, avec sa classe, quand l'utiliser et quand l'éviter. Copiez le balisage à partir de là.
Éléments de page
| Nom | Classe | Utilisez-le quand |
|---|---|---|
| Bannière de statut | pt-topbanner | Chaque page. Affiche la version et une ligne sur ce qu'est le document. |
| Héros | pt-hero | Chaque page. Un tag d'accroche, le titre, et la phrase la plus percutante du document. |
| Note d'accompagnement | pt-note | Informations méta sous un diagramme, un tableau ou un ensemble de statistiques : sources, réserves, « illustratif ». |
| Journal des modifications | pt-footer | Le pied de page de chaque page. Entrée la plus récente en premier. |
Cartes
| Nom | Classe | Utilisez-le quand |
|---|---|---|
| Grille d'avantages | pt-owns-grid | Trois ou quatre choses livrées, possédées ou acquises. |
| Carte large | pt-owns-card--wide | Un élément qui a besoin de plus d'espace que ses voisins, ou pour éviter qu'une seule carte reste seule sur une ligne. |
| Principes | pt-works-grid | Trois principes ou méthodes de travail. |
| Catégories | pt-categories | Types d'une chose, chacun avec un petit visuel qui montre la catégorie. |
| Panneau | pt-card | Un point qui a besoin de plus d'espace qu'une carte de grille, stylisé comme toutes les autres cartes. |
| Risque | govuk-inset-text pt-card pt-card--warning | Un risque à prévenir, énoncé clairement et basé sur l'expérience. |
| Résultat | pt-card pt-card--success | Ce que cela devient si cela fonctionne. |
Nombres
| Nom | Classe | Utilisez-le quand |
|---|---|---|
| Statistiques | pt-baseline-grid | Chiffres clés. Chaque nombre a une étiquette simple, et l'ensemble totalise un montant déclaré si possible. |
Diagrammes
| Nom | Classe | Utilisez-le quand |
|---|---|---|
| Éventail | pt-fanout | Une source alimentant plusieurs sorties. |
| Entonnoir | pt-fanin | Plusieurs sources qui convergent en une seule chose : entrées d'une décision, données alimentant un enregistrement, équipes contribuant à un service. Fonctionne mieux avec trois à cinq entrées. L'exemple dessine quatre courbes, commençant à y 12,5, 37,5, 62,5 et 87,5 ; pour un nombre différent d'entrées, commencez chaque courbe au centre de son entrée (pour trois : 16,7, 50 et 83,3). |
| Hub et rayon | pt-hub | Une chose centrale avec jusqu'à quatre parties qui s'y connectent. |
| Silos | pt-silos | La même chose détenue séparément à plusieurs endroits, sans rien pour les relier. Signalez la copie qui diffère. |
| Plusieurs-vers-un | pt-many-to-one | Plusieurs noms ou chemins qui mènent à la même chose : doublons, alias, travaux qui se chevauchent. |
| Avant et après | pt-before-after | La même chose aujourd'hui et telle que proposée, côte à côte. |
| Couches | pt-layers | Niveaux qui s'empilent les uns sur les autres, reliés par des flèches étiquetées. Les étiquettes des connecteurs sont en poids normal. |
| Flux | pt-flow | Un processus avec des étapes numérotées et un état final. Marquez les destinations non décidées comme ouvertes avec un tag « Approche à convenir ». |
| Phases | pt-phases | Étapes du travail dans un ordre réel. L'étape en cours est remplie. |
| Chronologie | pt-timeline | Jalons datés. Jalons passés remplis, futurs vides. |
| Spectre | pt-spectrum | Où les choses se situent sur une plage entre deux extrêmes : maturité, effort, risque. |
| Équipes | pt-squads | Comment les équipes sont liées, en particulier les restructurations. Marquez une équipe changeant d'état en pointillé. |
Tableaux et listes
| Nom | Classe | Utilisez-le quand |
|---|---|---|
| Tableau comparatif | pt-compare | Plusieurs options ou lieux côte à côte. Groupez les lignes et mettez en évidence la valeur différente sur toute la cellule. |
| Responsabilités | pt-split | Qui est responsable de quoi, deux groupes côte à côte. |
| Questions ouvertes | pt-questions | Questions auxquelles vous voulez des réponses, chacune étiquetée avec le destinataire. |
| Mesures de succès | pt-check-list | Cinq ou six résultats vérifiables. |
Exemples et preuves
| Nom | Classe | Utilisez-le quand |
|---|---|---|
| Exemple concret | pt-example | Un cas concret : un visuel, puis comment chaque endroit le traite aujourd'hui. |
| Citation de recherche | pt-quote | Ce qu'un utilisateur, collègue ou partie prenante a réellement dit, avec qui l'a dit. |
| Paire de code | pt-code-pair | Données, code ou configuration, seuls ou côte à côte. Étiquetez les extraits simplifiés « Illustratif ». |
| Point de couleur | pt-swatch | Une couleur ou un statut affiché en ligne, dans un tableau ou une phrase. Toujours associé à une étiquette textuelle. |
Interactif
| Nom | Classe | Utilisez-le quand |
|---|---|---|
| Sélecteur de vue | pt-views | Basculer un diagramme entre deux états, par exemple « Aujourd'hui » et « Proposé ». Optionnel, nécessite JavaScript. |
Si le contenu ne correspond à aucun de ceux-ci, écrivez un court paragraphe (ça va, avec modération) ou ajoutez un composant (voir « Extension de la bibliothèque »).
Principes éditoriaux
Structure
- Un document, un fil conducteur. Chaque composant doit servir l'argument central. Si quelque chose est intéressant mais non essentiel, supprimez-le.
- Expliquez l'idée avant de la défendre lorsque le public peut ne pas la connaître. L'approche problème d'abord fonctionne lorsque les gens comprennent déjà l'espace de solution. Quand ce n'est pas le cas, une section sur le problème se lit comme une liste de plaintes sans issue. Voir « Structure du document » pour l'ordre par défaut.
- Placez les avantages tôt. Les lecteurs décident s'ils s'intéressent dans les un ou deux premiers écrans.
- Montrez toute l'étendue avec le premier exemple. Si le premier exemple est étroit, les lecteurs supposent que toute la proposition est étroite. Lorsque l'idée s'applique largement, commencez par un exemple qui suggère l'étendue, puis utilisez le cas étroit comme preuve.
- Supprimez les sections qui ne sont pas nécessaires. Si une section concerne une décision pour une autre conversation, laissez-la de côté.
Langue
- Introduisez un terme avant de l'utiliser. Cela inclut les titres, les étiquettes et les groupes de tableaux. Si le terme apparaît avant d'être expliqué, utilisez une description simple à la place.
- Donnez à chaque terme un seul rôle. Si deux mots similaires apparaissent tous les deux (par exemple « décision » pour un choix unique et « approche » pour l'ensemble de la méthode), gardez chacun à son propre sens tout au long du document.
- Décrivez une approche comme « une façon courante », pas « la façon », à moins que ce ne soit vraiment la seule. C'est plus précis et invite à la discussion.
- Utilisez des mots qui décrivent, pas qui blâment. « Défini à certains endroits, pas à d'autres » décrit une situation. « Lacunes » ou « manquant » implique que quelqu'un a échoué.
- Lorsque l'auteur fournit le texte, utilisez-le tel quel. Corrigez uniquement la grammaire et dites ce que vous avez changé.
Preuves
- Utilisez des données réelles provenant de la source (le système, le tableur, l'exportation), pas des chiffres rappelés ou estimés. Dites d'où viennent les chiffres.
- Signalez tout ce qui est lu à partir d'une capture d'écran ou d'un résumé afin qu'il puisse être vérifié avant que la page ne soit partagée.
- N'exagérez pas le statut. Si quelque chose a été bien accueilli mais pas formellement accepté, dites-le précisément, ou laissez le statut de côté.
- Marquez les choix non décidés comme non décidés. Un tag « Approche à convenir » sur une option est mieux que de présenter une supposition comme une décision.
Ton avec des publics mixtes
- Soyez équilibré. Lorsque vous montrez un problème impliquant plusieurs équipes ou lieux, montrez la part de chacun. Une page qui singularise un groupe est lue de manière défensive par ce groupe.
- Formulez les avantages partagés pour chaque groupe dans la salle. Décrivez ce que chaque groupe gagne dans ses propres termes. Ne nommez pas la friction entre les groupes dans le document, même si c'est la véritable motivation. Les avantages peuvent y répondre sans la décrire.
Style maison
Le style maison par défaut, modifiez-le selon les besoins :
- Anglais britannique, titres en casse de phrase, virgule Oxford
- Pas de tirets cadratins ; restructurez avec une virgule, deux-points, point-virgule ou point
- Pas de constructions « ce n'est pas X, c'est Y »
- Pas de métaphores militaires ou de combat
- « gouvernement » en minuscule sauf s'il fait partie d'un nom propre
- Simple, direct, confiant ; chaque mot mérite sa place, et les lignes d'introduction ne répètent pas les lignes à retenir
Règles visuelles
- Un seul traitement des cartes partout. Les cartes sont blanches, avec une bordure grise de 1 px, une bordure supérieure bleue de 4 px, une icône facultative, un petit titre (
govuk-heading-s) et un petit texte de corps (govuk-body-s). N'inventez pas de styles de cartes ponctuels ; restylez le nouveau contenu pour qu'il corresponde. - Pas d'orphelins dans les grilles. Si une grille laisse une seule carte sur une ligne, rendez cette carte large ou modifiez le nombre de colonnes.
- Les échantillons de couleur sont des cercles, correspondant aux pages de couleurs du GOV.UK Design System.
- Les tableaux comparatifs mettent en évidence la cellule entière, pas un arrière-plan en ligne derrière le texte, afin que les valeurs restent alignées dans chaque colonne. Chaque cellule et en-tête de groupe partagent le même bord gauche.
- Les étiquettes des connecteurs dans les diagrammes sont en poids normal. Le gras est pour les titres et la chose pointée.
- Notes d'accompagnement (
pt-note) : texte de corps petit 16 px dans la couleur de texte secondaire (#505a5f). Utilisez pour les informations méta sous un diagramme, un tableau ou un ensemble de statistiques : réserves, sources, étiquettes « illustratif ». - Les blocs de code côte à côte ont la même hauteur.
- Les diagrammes utilisent
box-sizing: border-box(défini dans le CSS du composant) afin que le rembourrage et les bordures ne poussent jamais un composant hors de son cadre. - Le tag du héros reste sur une seule ligne. Les tags GOV.UK ont une largeur maximale de 160 px par défaut ; le CSS du composant l'augmente pour le héros et la bannière.
- Les polices ou images personnalisées doivent être intégrées, et uniquement si leur licence le permet. Vérifiez d'abord la licence. Les polices de caractères personnalisées nécessitent souvent un centrage vertical manuel : mesurez le texte rendu et ajustez le rembourrage.
- Accessibilité : donnez aux diagrammes une alternative textuelle (`role=