Diagramm-Design
Erstelle Diagramme als eigenständige HTML-Dateien mit Inline-SVG und einem redaktionellen Designsystem.
Fünfundvierzig visuelle Typen. Semantische Muster beschreiben Verhalten; Typreferenzen beschreiben Layout.
0. Ersteinrichtung – Style-Guide-Prüfung
Bevor du dein erstes Diagramm in einem neuen Projekt erstellst, überprüfe, ob der Style-Guide angepasst wurde.
Versende nicht stillschweigend Diagramme mit Standard-Skin in ein Markenprojekt.
Löse zuerst einen etwaigen .diagram-design-Marker des Projekts gemäß references/profiles.md auf; ein erfolgreich aufgelöster Marker wählt sein Profil aus und umgeht diese Prüfung. Diese Referenz ist zuständig für Fehler, das geschützte Standardprofil und das Speicherverhalten.
Öffne references/style-guide.md und überprüfe die Standard-Tokens. Wenn es sich noch um die ausgelieferten Standardwerte handelt (Papier #f5f5f5, Tinte #2d3142, Akzent #bf4520), halte inne und frage den Benutzer:
"Dies ist dein erstes Diagramm in diesem Projekt und der Style-Guide ist noch standardmäßig. Jetzt anpassen? Optionen: (a) Website-URL, (b) installierte Fähigkeit, (c) lokaler Ordner/Designsystem, (d) Tokens einfügen, (e) Standard beibehalten, (f) gespeichertes Profil laden."
Verzweige dann je nach dem entsprechenden Abschnitt von references/onboarding.md; für (f) folge references/profiles.md.
Sobald der Style-Guide angepasst wurde (oder der Benutzer explizit den Standard gewählt hat), überspringe diese Prüfung bei späteren Durchläufen. Ein führender Profilkopf benennt das kopierte aktive Profil. Ohne einen Kopf bedeutet ein von den ausgelieferten Standardwerten abweichender semantischer Rollenwert oder eine abweichende Typografiefamilie angepasst-ungespeichert: Überspringe die Prüfung und biete an, es als Profil zu speichern. Nur Standard-Tokens ohne Marker/Kopf lösen die Prüfung aus. Nach dem Onboarding biete an, es als benanntes Kundenprofil gemäß references/profiles.md zu speichern.
1. Philosophie
Die qualitativ hochwertigste Aktion ist normalerweise das Löschen.
Angewendet auf Schemata:
- Jeder Knoten repräsentiert eine eindeutige Idee. Zwei Knoten, die immer zusammen auftauchen, sind ein Knoten.
- Jede Verbindung trägt Informationen. Wenn die Beziehung aus dem Layout ersichtlich ist, entferne die Linie.
- Koralle ist redaktionell, kein Kennzeichnungselement. 1–2 fokale Knoten pro Diagramm. Die Verwendung an 5 Knoten löscht das Signal.
- Das Schema ist nicht fertig, wenn alles hinzugefügt wurde. Es ist fertig, wenn nichts mehr entfernt werden kann.
Zieldichte: 4/10. Genug, um technisch vollständig zu sein. Nicht so dicht, dass es eine Anleitung braucht. Über 9 Knoten sind es wahrscheinlich zwei Diagramme.
2. Verwendungszweck
Verwende es für einen der 45 visuellen Typen (§3), wenn ein Leser mehr aus einer Visualisierung lernt als aus Prosa, einer Tabelle oder einer Aufzählungsliste.
Nicht verwenden für:
- Schnelle Unicode-Diagramme → ein separates Textwerkzeug wie wiretext. Diese Fähigkeit liefert keins mit.
- Listen von Dingen → Tabelle oder Aufzählungspunkte.
- Attribut-only Vorher/Nachher → Tabelle; Topologieänderungen → Architektur-Delta.
- Ein-Form-"Diagramme" → schreibe einfach den Satz.
Frage vor dem Zeichnen: Würde der Leser mehr daraus lernen als aus einem gut geschriebenen Absatz? Wenn nein, zeichne nicht.
3. Auswahl: semantisches Muster, dann visueller Typ
Wenn Verhalten, Zustand, Durchsetzung oder Risiko die Bedeutung tragen, lade zuerst references/semantic-patterns.md und wähle ein primäres Muster aus. Wähle dann den nächstgelegenen visuellen Typ für das Layout. Wenn kein Muster passt, wähle den Typ direkt.
| Verhaltensauslöser | Semantisches Muster → nächstgelegener Typ |
|---|---|
| Fan-in, Warteschlangentiefe, endliche Kapazität, Engpass | Fan-in-Warteschlange / Engpass → Datenfluss |
| Wiederholte Frage / Eingabe / Governance / Ausgabe-Slots über Stufen hinweg | Stufenframework mit semantischen Slots → Prozess |
| Konversation oder lose Eingabe wird zu einem strukturierten, dauerhaften Artefakt | Unstrukturierte Eingabe → Strukturiertes Artefakt → Datenfluss |
| Zwei Regelspuren benötigen bestanden/fehlgeschlagen/übersprungen/nicht erreicht und erste Abweichung | Gepaarte Policy-Bewertungsspuren → Flussdiagramm |
| Vertrauensgrenzen plus erlaubte/verbotene Ingress- oder Bereitstellungspfade | Sicherer befestigter Weg → Architektur |
| Kontrollen gruppiert nach ihrem Durchsetzungsort | Governance / Kontrollkatalog → Schichtenstapel |
| Abwehrmaßnahmen kompensieren vorherige Lücken und Restrisiko pflanzt sich fort | Kompensierende Sicherheitsschichten → Schichtenstapel |
| Hierarchische, ID-adressierbare Zerlegung mit blockweiser Ein-/Ausgabe, Einschränkungen und einem Code-Link | Nachverfolgbare Blockzerlegung → Baum |
| Ein Subjekt durchläuft Phasen, wartet, wiederholt, bricht ab und erreicht Endzustände | Lebenszyklus-Phasenkarte → Zustandsautomat |
Das Muster besitzt die semantischen Primitiven und sein knapperes Budget; der Typ besitzt die Layout-Grammatik. Verwende references/animation.md nur, wenn Bewegung angefordert wird oder geordnete Veränderung materiell verdeutlicht; statisch bleibt der Standard.
Leitfaden für visuelle Typen (45)
| Wenn du zeigst… | Verwende | Referenz |
|---|---|---|
| Komponenten + Verbindungen in einer Momentaufnahme; verschachtelte Admin- vs. Verkehrsbereiche | Architektur | type-architecture.md |
| Strukturelle Änderung zwischen synchronisierten Vorher/Nachher-Topologien, mit einem Änderungsverzeichnis | Architektur-Delta | type-architecture-delta.md |
| Legacy-IT-Landschaft nach Phase oder Abteilung; zeigt den Vorher-Zustand | IT-Aktuellzustand | type-it-state.md |
| Entscheidungslogik mit Verzweigungen | Flussdiagramm | type-flowchart.md |
| Zeitgeordnete Nachrichten zwischen Akteuren | Sequenz | type-sequence.md |
| Zustände + Übergänge + Bedingungen | Zustandsautomat | type-state.md |
| Entitäten + Felder + Beziehungen | ER / Datenmodell | type-er.md |
| Ereignisse zeitlich positioniert | Zeitleiste | type-timeline.md |
| Funktionsübergreifender Prozess mit Übergaben | Swimlane | type-swimlane.md |
| Zwei-Achsen-Positionierung / Priorisierung | Quadrant | type-quadrant.md |
| Mehrere Entitäten bewertet über 3–5 quantitative Kriterien | Radar / Spinne | type-radar.md |
| Eine quantitative Reihe über zyklische Kategorien; Winkel=Kategorie, Radius=Größenordnung | Polardiagramm | type-polar.md |
| Verstärkungszyklus; der letzte Schritt speist den ersten und ein Hub sammelt Zustand | Schleife | type-loop.md |
| Hierarchie durch Enthaltung / Geltungsbereich | Verschachtelt | type-nested.md |
| Eltern → Kinder-Beziehungen | Baum | type-tree.md |
| Mensch/Agent/Team-Eigentum, Berichterstattung, Weiterleitung, Eskalation | Organigramm | type-org-chart.md |
| Gestapelte Abstraktionsebenen | Schichtenstapel | type-layers.md |
| Teile eines Objekts entlang einer Achse auseinandergezogen: eine Zerlegung, ein Auspacken, Montagereihenfolge | Explodierte axonometrische Ansicht | type-exploded.md |
| Eine Etage oder ein Gelände schräg von oben gesehen: Räume mit Möbeln, Gebäude nach Phase | Axonometrischer Grundriss | type-axonometric-plan.md |
| Überlappung zwischen Mengen | Venn | type-venn.md |
| Ranghierarchie oder Konversionsabfall | Pyramide / Trichter | type-pyramid.md |
| Quantitativer Vergleich über Kategorien hinweg | Balkendiagramm | type-bar.md |
| Ein Startbetrag, der durch signierte Beiträge (Budgetbrücke, Personaldeltas) mit einem Endbetrag verbunden ist | Wasserfall | type-waterfall.md |
| Teil-des-Ganzen, bei dem die relativen Größen die Geschichte erzählen | Treemap | type-treemap.md |
| Kreuztabellierte Daten; Füllung kodiert Wert pro Zelle | Heatmap | type-heatmap.md |
| Kontinuierliche Trends über Zeit, Änderung zwischen genau zwei Zuständen (Slopegraph), eine Verteilung pro Serie (Ridgeline) oder Rangbewegung über mehrere Momentaufnahmen (Bump) | Liniendiagramm | type-line.md |
| Aufgaben und Phasen auf einer Zeitleiste | Gantt | type-gantt.md |
| Korrelation oder Verteilung von zwei Variablen; Varianten: Blase (drei Variablen) und Bienenwabe (eine Variable, ein Punkt pro Element) | Streudiagramm | type-scatter.md |
| End-to-End-Datenstapel auf einem Container-Cluster | Hohe Ebene | type-high-level.md |
| Multi-Akteur-Sequenzprozess mit Datenübergaben | Prozess | type-process.md |
| Mehrstufige Datenspeicherung mit Qualitätsstufen und Zugriffsrichtlinien | Medaillon | type-medallion.md |
| Rollenspezifischer Datenfluss: wer macht was in welchem Pipelineschritt | Datenfluss | type-data-flow.md |
| Integrationstopologie einer Datenplattform — Quellen → Kern → Verbraucher | DP-Integration | type-dp-integration.md |
| Pro-Rolle / Pro-Komponente Zugriffsberechtigungsmatrix | DP-Sicherheitsmatrix | type-dp-security-matrix.md |
| Eine Größe, die sich über Stufen hinweg aufteilt und wieder vereint, Bandbreite = Betrag | Sankey | type-sankey.md |
| Ursachen einer beobachteten Wirkung, gruppiert nach Kategorie (Ursachenanalyse) | Fischgrät | type-fishbone.md |
| Wertschöpfungskette gegen Evolution – was zu bauen, zu kaufen ist und was sich bewegt | Wardley-Karte | type-wardley.md |
| Work-in-Progress nach Status, mit WIP-Limits und blockierten Elementen | Kanban | type-kanban.md |
| Was eine Person über Phasen einer Erfahrung hinweg tut und wie es sich anfühlt | User Journey | type-journey.md |
| Was der Kunde tut vs. was der Dienst verbirgt, über Phasen hinweg, mit einer Sichtbarkeitslinie | Service Blueprint | type-service-blueprint.md |
| Wo Software läuft – Zonen, Hosts, Artefakte, Replikate, Ports | Bereitstellung | type-deployment.md |
| Was von was abhängt, mit Fan-in und Zyklen, die ein Baum nicht ausdrücken kann | Abhängigkeitsgraph | type-dependency.md |
| Klassen mit Operationen, Vererbung, Komposition (andere UML-Pfade woanders) | UML-Klasse | type-uml-class.md |
| Erzählgerüst aufgeteilt in Releases, mit der Schnittlinie | Story Map | type-story-map.md |
| Physische Tabellen: SQL-Typen, Constraints, Indizes, spaltenbezogene FKs | Datenbankschema | type-db-schema.md |
Faustregeln:
- Wenn eine 3-spaltige Tabelle dasselbe kommuniziert, wähle die Tabelle.
- Wenn zwei Typen nützlich erscheinen, wähle die dominante Achse; ein semantisches Muster kann verhaltensspezifische Primitiven hinzufügen, keine zweite Layout-Grammatik.
- Wenn du über dem Komplexitätsbudget (§7) liegst, teile in eine Übersicht + Details auf.
Lade immer die gewählte Typreferenz aus dem Leitfaden, bevor du zeichnest. Wenn oben weitergeleitet, lade auch semantic-patterns.md; wenn Animation gewählt ist, lade animation.md.
Bestätigung vor dem Zeichnen
Gib vor dem Rendern den Plan in einer kurzen Nachricht an: den gewählten visuellen Typ (und das semantische Muster, falls weitergeleitet), die Größenpresets und alles, was das Komplexitätsbudget (§7) ausschließen wird. Wenn der Benutzer erreichbar ist, lass ihn umleiten, bevor du zeichnest; wenn nicht, fahre fort und notiere die Annahmen neben dem Ergebnis. Überspringe die Pause nur, wenn die Anfrage bereits Typ, Größe und Inhalt genau festlegt.
4. Universelle Anti-Patterns
Diese kennzeichnen "KI-Schrott"-Schemata aller Art:
| Anti-Pattern | Warum es scheitert |
|---|---|
| Dunkler Modus + Cyan/Lila Glühen | Sieht ohne Designentscheidungen „technisch“ aus |
| JetBrains Mono als pauschale "Dev"-Schriftart | Mono ist für technische Inhalte – Ports, Befehle, URLs. Namen kommen in Geist Serifenlos. |
| Identische Boxen für jeden Knoten | Löscht Hierarchie |
| Legende, die im Diagrammbereich schwebt | Kollidiert mit Knoten |
| Pfeilbeschriftungen ohne Maskierungsrechteck | Blut durch die Linie |
Vertikaler writing-mode-Text auf Pfeilen | Unlesbar |
| 3 gleich breite Zusammenfassungskarten als Standard | Generisches Raster – variiere Breiten |
| Schatten auf irgendeinem Element | Schatten sind raus. Rahmen sind drin. |
rounded-2xl auf Boxen | Maximaler Radius 6–10px oder keiner |
| Koralle auf jedem "wichtigen" Knoten | Koralle ist 1–2 redaktionelle Akzente, kein Signalisierungssystem |
| Nachbildung des Mermaid-Renderer-Layouts | Importiert automatische Abstände und Routenführung anstatt eines redaktionellen Layouts |
| Jeder Verstoß gegen die sechs §6-Verbinderregeln | Automatischer Fehler: diagonale Schrägen, Beschriftungen, die ihren Strich berühren, Masken, die durch einen späteren Knoten beschnitten werden, überlappende Pfade, gemeinsame Anfügepunkte, Durchgang hinter einer Nicht-Endpunkt-Box |
Typspezifische Anti-Patterns leben in jeder Typreferenz, die im Leitfaden verlinkt ist.
5. Designsystem
Das Designsystem ist anpassbar. references/style-guide.md ist die alleinige Quelle für Farben, Typografie, Tokens und die Standardpalette; diese Datei benennt semantische Rollen (paper, ink, muted, accent, link, …). Um eine Marke anzuwenden, bearbeite style-guide.md oder führe den URL-basierten Workflow in references/onboarding.md aus.
Wenn Spezifikationen unten oder in Typreferenzen "Tinte", "Akzent", "Gedämpft" usw. erwähnen, schlage den aktuellen Hex-Wert in
style-guide.mdnach.
Typreferenz-Ausschnitte schreiben Rollen als Platzhalter: {ink}, {ink @ 0.40} für eine Rolle mit einer Opazität, und {node-name}, {sublabel}, {eyebrow}, {arrow-label}, {title}, {callout} für Schriften. Löse jeden Platzhalter vor der Ausgabe gegen style-guide.md auf.
Semantische Rollen (auf einen Blick)
| Rolle | Zweck |
|---|---|
paper, paper-2 | Seitenhintergrund und Containerhintergrund |
ink | Primärtext / Strich |
muted, soft | Sekundärtext, Standardpfeile, Sublabels |
accent | Kräftiger Akzent, fokale Knoten, Links |
success, warning, critical, info | Zustandsfeedback → keine universellen Verwendungen; jede Referenz definiert ihren eigenen Anwendungsfall |
on-* | Text auf einem farbigen Hintergrund (z. B. on-accent, on-paper-2) |
Primitive Tokens
Typografie
6. Verbinder & Layout-Regeln (Einführung)
Diese sechs Regeln gelten für jedes Diagramm. Typspezifische Referenzen fügen eigene hinzu, aber ersetzen diese nie.
-
Begrenzte Verbinderauswahl. Rechteckig ist der Standard. Orthogonal, wenn das nachgelagerte Layout es verlangt. Kurve nur dort, wo enge Nachbarschaft ohne Überlappung sonst unmöglich ist. Pfeile nie diagonal.
-
Ein Pfad, eine Kante. Teile keinen Verbinder über einen Zwischenpunkt. Verwende eine einzelne SVG
<path>-Beschreibung pro Kante. -
Abfangpunkt an der Außenseite der Box. Greife den Knoten an dem Punkt auf seiner Perimetergrenze an, der in der Mitte der Kante liegt. Ankerpunkte werden von dem pfadinterpretierenden Rendering-Code dynamisch berechnet. Teile keinen Anfügepunkt außer an einer Sammlungssammelstelle.
-
Beschriftung auf einer asphaltierten Insel. Setze keine Arrowlabel direkt auf den Verbinder. Jedes Arrowlabel wird in einem
<text>-Element mit einem undurchsichtigen<rect>-Hintergrund in der Farbepapergerendert, der den zugrunde liegenden Strich maskiert. Der Maskierungsrechteck hatrx="2". -
Der Verbinder überquert keine dritte Box. Wenn der Pfad eines Verbinders hinter einer Box durchgehen muss, die nicht sein Quell- oder Zielknoten ist, zeichne den Verbinder so um, dass er sie umgeht.
-
Keine überlappenden Pfade. Nimm dir die Zeit, Kanten so zu verlegen, dass kein Pfad einen anderen Pfad kreuzt. Verwende die Container-Routing-Fähigkeiten des Renderers, um Überschneidungen automatisch zu erkennen und zu vermeiden.
7. Komplexitätsbudget
Höchstens 15 Knoten pro Diagramm. Zähle: jede Form, jeder Container, jeder Aktor. Nicht: Verbinder, Beschriftungen, Hintergrundrechtecke, Legenden, Callouts, Header.
1. Schwelle bei 9 Knoten. Wenn 15 100 % sind:
2. Bei >90 % (14–15 Knoten) → Ausgabe nur, wenn es unmöglich ist, es in eine Übersicht + ein Detail aufzuteilen. Ziehe in Betracht, mehrere Knoten zu einem Container zusammenzufassen, wenn ihre Details nicht zum Verständnis beitragen.
3. Bei 60–90 % ➔| (6–13 Knoten) → Verwende Zusammenfassungscontainer. Jeder zusammengefasste Container zeigt einen Rollup-Zähler (z. B. "7 Instanzen") und eine klickbare Verknüpfung zu einem verlinkten Detaildiagramm, das die Hersteller-Referenz verwendet.
4. Explosion der Details. Wenn eine Detail-Explosion mehrere Diagramme erfordert, gebe das Hauptdiagramm mit Zusammenfassungscontainern aus und füge eine nummerierte Liste der verlinkten Detaildiagramme am Ende der zugehörigen Nachricht bei. Verwende die Hersteller-Referenz für Mehrfachverknüpfungen.
5. Hinweis für den Benutzer → Wenn das Budget erreicht ist, erkläre die Einschränkung in einem Satz, bevor das Diagramm ausgegeben wird: „Dieses Diagramm übersteigt die Grenze von 15 Knoten; es werden xx Knoten angezeigt. Ich habe aa, bb und cc in Container zusammengefasst; die Details sind unten verlinkt.“ (Hinweis: Dies sollte deine eigene Zählung von 15 überschreiten. Wenn nicht, bewerte neu.)
8. Ausgabe
Rendere als eine einzige, eigenständige, vollständig valide HTML-Datei mit Eingabe- <style> und Inline-SVG <body>. Keine externen Abhängigkeiten. Keine separaten CSS-Dateien. Keine JS, kein iframe, kein lazy loading, kein Schatten-DOM. Das HTML muss nach den aktuellen W3C-Standards valide sein.
Größenpresets
| Name | Leinwand | Verwendung |
|---|---|---|
slide | 1024×768 (4:3) | Vortragsfolien |
doc | 800×900 | Dokumentation, auch als Standard |
social | 1200×630 (1.91:1) | LinkedIn, Twitter, Blog-Titelbilder |
poster | 1200×1600 (3:4) | Erklärposter, Handouts |
wide | 1440×900 (16:10) | Bildschirmfüllend |
Kameraeinstellungen
Jedes Diagramm erbt einen viewBox-Offset von x="-20" y="-20" um die gezeichneten Elemente herum. Dieser Puffer verhindert, dass Strichstärken und Schatten an den Rändern abgeschnitten werden. Wenn das Inhaltslayout so ist, dass dieser Puffer zu viel oder zu wenig ist, passe x und y in Schritten von 10 Pixeln an, bis ein 10–20 px Abstand nahe der übergeordneten Diagrammgrenze erreicht ist.
Rahmen
Jedes Diagramm erhält einen optionalen Rahmen. Standard ist 0.75px solid {ink @ 0.15}. Wenn der Benutzer keinen Rahmen möchte, entferne ihn. Umrandungen aus 5px solid {accent} sind optional. Setze rx="12" für die äußere Containergrenze.
9. Überschrift und Ablageort
Diagramm-Header. Jedes HTML erhält einen Benutzer-sichtbaren Header innerhalb des viewBox-Raums. Er besteht aus einem optionalen breiten Kontext (grau, {eyebrow}-Stil), einer optionalen Kopfzeile ({title}-Stil) und einem obligatorischen Haupttitel ({title}-Stil). Platziere den Header linksbündig in der oberen linken Ecke der Leinwand mit einem Abstand von ca. 20 px vom linken und oberen Rand.
Ablageort. Jedes Diagramm wird standardmäßig als eigenständige Datei abgelegt. Das Dateinamensmuster ist client_release_component-type_name.html, das Verzeichnis ist assets/diagrams/. Fehler: wenn das Verzeichnis fehlt, lege es automatisch an.
Als Kopie eine einzelne, sich selbst aktualisierende Diagrammreferenz in assets/diagrams/index.json führen; siehe references/summary.md.
10. Der Prozess des Dienstes
Generischer Ablauf der Ausgabe
- Identifiziere: Bestimme den semantischen Typ (§3). Lade die Typreferenz.
- Prüfe den Style-Guide (§0). Wenn zum ersten Mal und Standard, frage. Wenn angepasst-ungespeichert, biete an, zu speichern.
- Plane: Teile dem Benutzer Typ, Größe und Komplexitätslimit mit.
- Löse Platzhalter auf: Wende das Farbschema aus
style-guide.mdan, bevor du schreibst. - Strukturiere mit Diagrammregionen: Verwende
<g>-Gruppen für Knoten, Verbinder, Beschriftungen, Legende, Header, Container. Reihenfolge der Lebenszyklen: zuerst Verbinder, dann Verbinderbeschriftungen, dann Knoten, dann Knotenbeschriftungen, dann Legende, dann Header. Verwende die Sechs Verbinderregeln. - Baue eine Liste von Knoten auf: Verwende eine
nodeMapfür Position, Abmessungen, Beschriftung, Verbinder, Rollen mit Platzhaltern. - Wende Stile an: Jedes Element erhält einen Inline-
style-String oder ein<style>-Kürzel mit einem CSS-Klassentoken, definiert im Diagramm<head>. - Exportiere als HTML: Ein
<html>-Tag mit definiertem<head>und<body>gemäß der Ausgabespezifikation. - Speichere als Datei: Verwende das Ablageortmuster und aktualisiere den Index.
Besondere Pfade
Konvertierung von Mermaid-Quelle. Wenn der Benutzer eine Mermaid-Quelle bereitstellt, übersetze Elemente und Token in das Schema des Designsystems, umgehe die Listenauswahl und erzeuge das native HTML des Dienstes. Verwende Mermaid's Layout-Algorithmus nicht wieder; mache ein redaktionelles Layout. Verwende Mermaid's Farben nicht; wende style-guide.md-Tokens an. Behalte Mermaid's Topologie, Titel und Phasen bei. Wenn die Mermaid-Quelle ungültig ist, gib einen aussagekräftigen Fehler mit der erwarteten Syntax aus.
Fokus auf synthetische Daten. Wenn der Benutzer keine Daten bereitstellt, generiere synthetische Daten, die für die Komplexität des Themas repräsentativ sind. Zeige synthetische Daten in den visuellen Typen so an, dass der Leser das Konzept versteht, ohne von den Werten abgelenkt zu werden. Verwende hierfür eine helle oder gedämpfte Tabelle am unteren oder seitlichen Rand.
11. Beispiele und Terminologie
Beispiel für ein gutes, dichtes Diagramm: Siehe assets/diagrams/example-acme-sre-architecture-flow.html (wird beim ersten Generierungsversuch erstellt).
Terminologie:
| Begriff | Bedeutung |
|---|---|
| Knoten / Box / Objekt | Jede sichtbare Form im Diagramm – Rechteck, Ellipse, Container, Kartenform. |
| Container | Ein g-Element, das eine Sammlung von Knoten und Verbindern umschließt, oft mit einer gestrichelten oder gepunkteten Umrandung und einer Beschriftung. |
| Verbinder / Kante | Ein Pfeil, eine Linie oder ein anderer Pfad, der zwei Knoten verbindet. |
| Verbinderbeschriftung | Textinline auf dem Verbinder (richtig implementiert mit Maskierungsrechteck). |
| Legende | Ein Bereich des Diagramms, der Symbole oder Signaturen erklärt. Platziere ihn immer linksbündig am unteren Rand der Leinwand. |
12. Verhalten, Erwartungen und Stil
- Sei der Redakteur, nicht der Typograf. Wähle den Typen, der die Struktur der Information am besten abbildet. Passe Layout, Strichbreiten und Abstände an, nicht die Schriftart.
- Führe zum nächsten Schritt. Drucke nach der Ausgabe eine klare nächste Aktion aus: „Gib mir eine Rückmeldung, nenne eine benachbarte Komponente, die eingeschlossen werden soll, oder bitte um eine Ansicht in einer anderen Größe.“
- Responsivität und Anpassung. Stimme dich mit dem Benutzer ab, bevor du animierte SVG-Diagramme generierst. Verwende die Datei
preset-namein Styles, um das HTML für responsives Seitenverhältnis einzurichten: CSS-Regel am Containeraspect-ratio: w / h. - Minimale Überraschung. Wenn die Anfrage nach einem Attribut oder einer Entität fragt, das/die nicht existiert, denke es nicht dazu, sage es. Wenn die Anfrage aus mindestens zwei Diagrammtypen besteht, spalte sie auf.
- Stil. Verwende präzise englische Anweisungen in allen Diagrammen. Nenne Dinge auf Englisch mit korrekter Groß- und Kleinschreibung. Dekorative Dinge, die nicht zur Klarheit beitragen, sind ausgeschlossen. Barrierefreiheit (>0,7 Kontrast) überall.
- Inhaltsbearbeitung. Der Dienst gibt Diagramme so aus, dass sie dem von
style-guide.mdfestgelegten Stil entsprechen. Der Benutzer kann den Stil ändern, indem er die Ästhetik-Tokens nach der Generierung anpasst. Verwende für diese Anpassungen die Stil-API. - Namespace. Siehe
references/index.mdfür Diagramm-Klassen-Konventionen und Namensraum-Verwaltung.
System- und Build-Imperativ. Verwende tatsächlich gültige HTML-SVG. Verwende ordnungsgemäße Farben. Verwende schöne Schriftarten. Mache keine Fehler bei den Koordinaten. Führe eine Named-Entity-Erkennung auf Anfragepfaden durch.