shaunbent/govuk-proposal-pages

GOV.UK Vorschlagsseiten

Zweck

Erstellen einer einzelnen, eigenständigen HTML-Seite, die eine Richtung argumentiert, eine Idee erklärt oder eine Änderung bewirbt, unter Verwendung der echten GOV.UK Design System Styles und einer kleinen Bibliothek wiederverwendbarer Komponenten.

Das leitende Prinzip: Zeige den Inhalt, erzähle ihn nicht. Eine Liste der Dinge, die ein Team besitzt, wird zu einem Kartenraster. Eine Reihe von Schritten wird zu einem Ablauf. Ein Vergleich wird zu einer Tabelle mit hervorgehobenen Unterschieden. Prosa ist das verbindende Gewebe zwischen Komponenten, nicht die Hauptart der Informationsvermittlung.

Beschreibe den Inhalt; diese Fähigkeit kümmert sich um das Aussehen.

Die Ausgabe ist eine HTML-Datei

Mit dieser Fähigkeit erstellte Seiten werden als Dateien geteilt, oft auf SharePoint oder einer ähnlichen Dokumentenbibliothek hochgeladen und von dort verlinkt. Daher:

• Alles befindet sich in einer einzigen .html-Datei. CSS, Schriftarten und Bilder sind eingebettet (Schriftarten und Bilder als base64-Daten-URIs). Keine externen Stylesheets, Skripte, Schriftarten oder Bilder.
• Die Seite muss bei deaktiviertem JavaScript korrekt gelesen werden können. Einige Dokumentenbibliotheken entfernen oder blockieren Skripte in Vorschauen. Interaktive Komponenten (wie der Ansichtsumschalter) sind Verbesserungen: Der standardmäßige Zustand, der ohne JavaScript angezeigt wird, muss eigenständig sinnvoll sein.
• Kein Build-Schritt für den Leser. Die Datei wird direkt in einem Browser geöffnet.

Dateien

• page-starter.html ist eine leere Seite: das GOV.UK Frontend CSS, die GDS Transport Schriftarten als base64 eingebettet, das vollständige Komponenten-CSS, ein Statusbanner, ein Hero und eine Fußzeile mit einem Änderungsprotokoll. Jede neue Seite beginnt als Kopie dieser Datei. GDS Transport ist nur für die GOV.UK-Nutzung lizenziert; außerhalb von GOV.UK durch eine andere Schriftart ersetzen (siehe NOTICE.md).
• docs/index.html ist die Dokumentationsseite für diese Fähigkeit und wurde mit der Fähigkeit erstellt. Ihr Abschnitt „Komponenten“ ist die visuelle Referenz: jede Komponente, benannt und beschriftet, mit Angaben zur Verwendung, zur Vermeidung und einem Live-Beispiel. Kopiere das Markup der Komponente aus den gx-specimen__demo-Blöcken dort. Kopiere nicht die gx--Klassen; sie gestalten nur die Dokumentationsseite. Sie verwendet dasselbe Komponenten-CSS wie der Starter, sodass kopiertes Markup ohne Änderungen funktioniert.

Dokumentenstruktur

Erarbeite das Argument, bevor du Komponenten auswählst. Die meisten Vorschläge folgen dieser Reihenfolge; lasse die Abschnitte weg, die der Inhalt nicht benötigt.

Abschnitt	Funktion	Häufig passende Komponenten
Status und Hero	Sagt, was das Dokument ist und die eine Erkenntnis	Statusbanner, Hero
Was es ist	Erklärt die Idee, falls das Publikum sie nicht kennt	Kategorien, Fächerung, Schichten, Code-Paar
Was es uns bringt	Die Vorteile, frühzeitig, für jede Gruppe im Raum	Nutzenraster, Breite Karte
Warum jetzt	Das Problem, wie es ist, mit Beweisen	Silos, Statistiken, Vergleichstabelle, Viele-zu-Eins, Forschungszitat
Wie es funktioniert	Der vorgeschlagene Ansatz	Ablauf, Vorher und Nachher, Hub-and-Spoke, Einsammeln, Durchgerechnetes Beispiel
Wer besitzt was	Verantwortlichkeiten	Verantwortlichkeiten, Panel
Wo wir beginnen	Umfang und Reihenfolge	Phasen, Zeitleiste
Risiken	Was schiefgehen könnte	Risiko
Offene Fragen	Was du von den Lesern brauchst	Offene Fragen
Erfolg	Wie du weißt, dass es funktioniert hat	Erfolgsmaßnahmen, Ergebnis
Fußzeile	Version und Änderungsprotokoll	Änderungsprotokoll

Setze „Warum jetzt“ nur dann an den Anfang, wenn die Leser den Lösungsraum bereits verstehen (siehe „Editorialprinzipien“).

Komponentenkatalog

Jede Komponente hat einen Namen. Personen, die diese Fähigkeit nutzen, können Komponenten beim Namen nennen („Verwende eine Einsammel-Komponente, um zu zeigen, woher die Anwendungen kommen“), und du solltest dieselben Namen verwenden, wenn du sie vorschlägst. Der Abschnitt „Komponenten“ in docs/index.html zeigt jede live, mit ihrer Klasse, wann sie verwendet werden soll und wann nicht. Kopiere das Markup von dort.

Seitenmöbel

Name	Klasse	Verwende sie, wenn
Statusbanner	pt-topbanner	Jede Seite. Zeigt die Version und eine Zeile, was das Dokument ist.
Hero	pt-hero	Jede Seite. Ein Überbegriff-Tag, der Titel und der schärfste Satz im Dokument.
Unterstützende Notiz	pt-note	Metainformationen unter einem Diagramm, einer Tabelle oder einer Reihe von Statistiken: Quellen, Einschränkungen, „illustrativ“.
Änderungsprotokoll	pt-footer	Die Fußzeile jeder Seite. Neuester Eintrag zuerst.

Karten

Name	Klasse	Verwende sie, wenn
Nutzenraster	pt-owns-grid	Drei oder vier gelieferte, besessene oder gewonnene Dinge.
Breite Karte	pt-owns-card--wide	Ein Element, das mehr Platz als seine Geschwister benötigt, oder um zu vermeiden, dass eine Karte allein in einer Zeile sitzt.
Prinzipien	pt-works-grid	Drei Prinzipien oder Arbeitsweisen.
Kategorien	pt-categories	Typen einer Sache, jede mit einem kleinen visuellen Element, das die Kategorie zeigt.
Panel	pt-card	Ein Punkt, der mehr Platz als eine Rasterkarte benötigt, gestaltet wie jede andere Karte.
Risiko	govuk-inset-text pt-card pt-card--warning	Ein Risiko, vor dem geschützt werden muss, klar und aus Erfahrung formuliert.
Ergebnis	pt-card pt-card--success	Was daraus wird, wenn es funktioniert.

Zahlen

Name	Klasse	Verwende sie, wenn
Statistiken	pt-baseline-grid	Schlagzeilenzahlen. Jede Zahl hat ein einfaches Label, und die Menge summiert sich zu einer angegebenen Gesamtzahl, wo möglich.

Diagramme

Name	Klasse	Verwende sie, wenn
Fächerung	pt-fanout	Eine Quelle, die mehrere Ausgaben speist.
Einsammeln	pt-fanin	Mehrere Quellen, die zu einer Sache zusammenkommen: Eingaben für eine Entscheidung, Daten, die einen Datensatz speisen, Teams, die zu einem Dienst beitragen. Funktioniert am besten mit drei bis fünf Eingaben. Das Beispiel zeichnet vier Kurven, beginnend bei y 12,5, 37,5, 62,5 und 87,5; für eine andere Anzahl von Eingaben beginne jede Kurve im Zentrum ihrer Eingabe (für drei: 16,7, 50 und 83,3).
Hub-and-Spoke	pt-hub	Eine zentrale Sache mit bis zu vier Teilen, die mit ihr verbunden sind.
Silos	pt-silos	Dieselbe Sache, an mehreren Orten separat gehalten, ohne Verbindung. Markiere die Kopie, die sich unterscheidet.
Viele-zu-Eins	pt-many-to-one	Mehrere Namen oder Wege, die zur selben Sache führen: Duplikate, Aliase, überlappende Arbeit.
Vorher und Nachher	pt-before-after	Dieselbe Sache heute und wie vorgeschlagen, nebeneinander.
Schichten	pt-layers	Ebenen, die aufeinander aufbauen, verbunden durch beschriftete Pfeile. Verbinderbeschriftungen sind in normaler Schriftstärke.
Ablauf	pt-flow	Ein Prozess mit nummerierten Schritten und einem Endzustand. Markiere unentschiedene Ziele als offen mit einem Tag „Ansicht zu vereinbaren“.
Phasen	pt-phases	Arbeitsphasen in einer echten Reihenfolge. Die aktuelle Phase ist ausgefüllt.
Zeitleiste	pt-timeline	Datierte Meilensteine. Vergangene Meilensteine ausgefüllt, zukünftige hohl.
Spektrum	pt-spectrum	Wo Dinge auf einer Spanne zwischen zwei Enden liegen: Reife, Aufwand, Risiko.
Teams	pt-squads	Wie Teams zueinander stehen, insbesondere bei Umstrukturierungen. Markiere ein Team, das seinen Status ändert, als gestrichelt.

Tabellen und Listen

Name	Klasse	Verwende sie, wenn
Vergleichstabelle	pt-compare	Mehrere Optionen oder Orte nebeneinander. Gruppiere Zeilen und hebe den abweichenden Wert auf der gesamten Zelle hervor.
Verantwortlichkeiten	pt-split	Wer für was verantwortlich ist, zwei Gruppen nebeneinander.
Offene Fragen	pt-questions	Fragen, die du beantwortet haben möchtest, jede mit einem Tag versehen, für wen sie ist.
Erfolgsmaßnahmen	pt-check-list	Fünf oder sechs abhakbare Ergebnisse.

Beispiele und Beweise

Name	Klasse	Verwende sie, wenn
Durchgerechnetes Beispiel	pt-example	Ein konkreter Fall: eine Visualisierung, dann wie jeder Ort es heute handhabt.
Forschungszitat	pt-quote	Was ein Benutzer, Kollege oder Stakeholder tatsächlich gesagt hat, mit wem es gesagt wurde.
Code-Paar	pt-code-pair	Daten, Code oder Konfiguration, allein oder nebeneinander. Beschrifte vereinfachte Ausschnitte mit „Illustrativ“.
Farbpunkt	pt-swatch	Eine Farbe oder ein Status, inline in einer Tabelle oder einem Satz angezeigt. Immer mit einem Textlabel kombiniert.

Interaktiv

Name	Klasse	Verwende sie, wenn
Ansichtsumschalter	pt-views	Ein Diagramm zwischen zwei Zuständen umschalten, z. B. „Heute“ und „Vorgeschlagen“. Optional, benötigt JavaScript.

Wenn der Inhalt in keine dieser Kategorien passt, schreibe einen kurzen Absatz (in Maßen in Ordnung) oder füge eine Komponente hinzu (siehe „Erweiterung der Bibliothek“).

Editorialprinzipien

Struktur

• Ein Dokument, ein roter Faden. Jede Komponente sollte dem zentralen Argument dienen. Wenn etwas interessant, aber nicht tragend ist, streiche es.
• Erkläre die Idee, bevor du den Fall dafür machst, wenn das Publikum die Idee möglicherweise nicht kennt. Problem-zuerst funktioniert, wenn die Leute den Lösungsraum bereits verstehen. Wenn nicht, liest sich ein Problemabschnitt wie eine Liste von Beschwerden ohne Ausweg. Siehe „Dokumentenstruktur“ für die Standardreihenfolge.
• Setze die Vorteile früh. Leser entscheiden innerhalb der ersten ein oder zwei Bildschirme, ob sie sich interessieren.
• Zeige den vollen Umfang mit dem ersten Beispiel. Wenn das erste Beispiel eng ist, nehmen Leser an, dass der gesamte Vorschlag eng ist. Wenn die Idee breit anwendbar ist, eröffne mit einem Beispiel, das auf die Breite hindeutet, und verwende dann den engen Fall als Beweis.
• Schneide Abschnitte weg, die nicht da sein müssen. Wenn ein Abschnitt eine Entscheidung für ein anderes Gespräch betrifft, lasse ihn weg.

Sprache

• Führe einen Begriff ein, bevor du ihn verwendest. Dies umfasst Überschriften, Labels und Tabellengruppen. Wenn der Begriff erscheint, bevor er erklärt wird, verwende stattdessen eine einfache Beschreibung.
• Gib jedem Begriff eine Aufgabe. Wenn zwei ähnliche Wörter beide vorkommen (z. B. „Entscheidung“ für eine einzelne Wahl und „Ansatz“ für die gesamte Methode), behalte jedes durchgängig bei seiner eigenen Bedeutung.
• Beschreibe einen Ansatz als „einen üblichen Weg“, nicht als „den Weg“, es sei denn, es ist wirklich der einzige Weg. Es ist genauer und lädt zur Diskussion ein.
• Verwende Wörter, die beschreiben, nicht beschuldigen. „An manchen Orten definiert, an anderen nicht“ beschreibt eine Situation. „Lücken“ oder „fehlend“ impliziert, dass jemand versagt hat.
• Wenn der Autor Formulierungen bereitstellt, verwende sie wie geschrieben. Korrigiere nur die Grammatik und sage, was du geändert hast.

Beweise

• Verwende echte Daten aus der Quelle (dem System, der Tabelle, dem Export), keine erinnerten oder geschätzten Zahlen. Sage, woher die Zahlen kommen.
• Markiere alles, was von einem Screenshot oder einer Zusammenfassung abgelesen wurde, damit es überprüft werden kann, bevor die Seite geteilt wird.
• Behaupte keinen Status über das Maß hinaus. Wenn etwas gut aufgenommen, aber nicht formell vereinbart wurde, sage es genau so oder lasse den Status weg.
• Markiere unentschiedene Entscheidungen als unentschieden. Ein Tag „Ansicht zu vereinbaren“ auf einer Option ist besser, als eine Schätzung als Entscheidung zu präsentieren.

Ton bei gemischtem Publikum

• Sei ausgewogen. Wenn du ein Problem zeigst, das mehrere Teams oder Orte betrifft, zeige den Anteil jedes einzelnen. Eine Seite, die eine einzelne Gruppe hervorhebt, wird von dieser Gruppe defensiv gelesen.
• Rahme gemeinsame Vorteile für jede Gruppe im Raum. Beschreibe, was jede Gruppe in ihren eigenen Begriffen gewinnt. Nenne die Reibung zwischen Gruppen nicht im Dokument, auch wenn sie die wirkliche Motivation ist. Die Vorteile können sie angehen, ohne sie zu beschreiben.

Hausstil

Der Standard-Hausstil, ändere ihn nach Bedarf:

• Britisches Englisch, Überschriften im Satzfall, Oxford-Komma
• Keine Gedankenstriche; umstrukturieren mit Komma, Doppelpunkt, Semikolon oder Punkt
• Keine „es ist nicht X, es ist Y“-Konstruktionen
• Keine militärischen oder Kampfmetaphern
• „government“ kleingeschrieben, es sei denn, es ist Teil eines Namens
• Klar, direkt, selbstbewusst; jedes Wort verdient seinen Platz, und Einleitungszeilen wiederholen keine Kernaussagen

Visuelle Regeln

• Einheitliche Kartengestaltung überall. Karten sind weiß, mit einem 1px grauen Rand, einem 4px blauen oberen Rand, einem optionalen Symbol, einer kleinen Überschrift (govuk-heading-s) und einem kleinen Fließtext (govuk-body-s). Erfinde keine einmaligen Kartenstile; gestalte neuen Inhalt entsprechend um.
• Keine Waisen in Rastern. Wenn ein Raster eine Karte allein in einer Zeile lassen würde, mache diese Karte breit oder ändere die Spaltenanzahl.
• Farbmuster sind Kreise, entsprechend den GOV.UK Design System Farbseiten.
• Vergleichstabellen heben die gesamte Zelle hervor, nicht einen inline-Hintergrund hinter dem Text, damit die Werte in jeder Spalte ausgerichtet bleiben. Jede Zelle und Gruppenüberschrift teilt sich die gleiche linke Kante.
• Verbindungsbeschriftungen in Diagrammen sind in normaler Schriftstärke. Fett ist für Überschriften und das, worauf gezeigt wird.
• Unterstützende Notizen (pt-note): 16px kleiner Fließtext in der sekundären Textfarbe (#505a5f). Verwende sie für Metainformationen unter einem Diagramm, einer Tabelle oder einer Reihe von Statistiken: Einschränkungen, Quellen, „illustrative“-Labels.
• Nebeneinander angeordnete Codeblöcke haben die gleiche Höhe.
• Diagramme verwenden box-sizing: border-box (im Komponenten-CSS gesetzt), sodass Padding und Ränder die Komponente nie aus ihrer Box drücken.
• Der Hero-Tag bleibt in einer Zeile. GOV.UK-Tags haben standardmäßig eine maximale Breite von 160px; das Komponenten-CSS hebt dies für Hero und Banner auf.
• Benutzerdefinierte Schriftarten oder Bilder müssen eingebettet sein, und nur, wenn es ihre Lizenz erlaubt. Überprüfe zuerst die Lizenz. Benutzerdefinierte Schriftarten benötigen oft manuelle vertikale Zentrierung: Miss den gerenderten Text und passe das Padding an.
• Barrierefreiheit: Gib Diagrammen eine Textalternative (role="img" mit einem aria-label, das angibt, was das Diagramm zeigt), behalte sichtbare Fokuszustände bei interaktiven Steuerelementen bei und verlasse dich nicht allein auf Farbe, um einen Unterschied zu zeigen (die hervorgehobenen Zellen sind auch fett).

Interaktive Komponenten

Der Ansichtsumschalter (pt-views) ermöglicht es einem Leser, ein Diagramm zwischen Zuständen umzuschalten, z. B. „heute“ und „vorgeschlagen“ oder „hell“ und „dunkel“. Er ist optional:

• Der Standardzustand muss der sein, der ohne JavaScript sinnvoll ist.
• Verwende echte <button>-Elemente mit aria-pressed.
• Halte das Skript inline und klein; der Starter enthält eines, das du wiederverwenden kannst.

Build-Workflow

1. Sammle zuerst den Inhalt: das Argument, die Beweise, für wen es ist und was du von ihnen möchtest. Die Auswahl von Komponenten, bevor der Inhalt klar ist, produziert eine polierte Seite mit dünnem Gehalt.
2. Plane die Abschnitte mit der „Dokumentenstruktur“ und wähle Komponenten beim Namen aus dem Katalog. Wenn die Person bestimmte Komponenten angefordert hat, verwende diese.
3. Kopiere page-starter.html in eine neue Datei. Fülle das Banner, den Hero und die Fußzeile aus.
4. Kopiere das Markup jeder Komponente aus dem Abschnitt „Komponenten“ von docs/index.html und ersetze den Platzhalterinhalt. Lasse niemals Platzhaltertext auf der Seite.
5. Wenn die Seite einen Ansichtsumschalter verwendet, behalte das Skript am Ende des Starters; andernfalls lösche es.
6. Überprüfe die Seite in einem …

… [für die Übersetzung gekürzt]