Was ist Mermaid
Oftmals helfen Diagramme Informationen und Zusammenhänge schnell visuell zu erfassen. Genau dabei kann Mermaid in einer Obsidian-Notiz helfen. Mermaid ist eine JavaScript-basierte Bibliothek, die in Obsidian integriert ist und dir eine textbasierte Auszeichnungssprache bietet, mit der du schnell verschiedene Diagrammtypen umsetzen kannst. So erstellst du im Obsidian-Editor schnell mit wenigen Zeilen Code ein Flussdiagramm in einem Codeblock und Obsidian rendert dann das Diagramm.
Das klingt zunächst umständlich, hat aber einen entscheidenden Vorteil: Diagramme sind reiner Text, liegen also als lesbare Zeichen in der Markdown-Datei, lassen sich schnell editieren und kopieren ohne eine Obsidian verlassen zu müssen. Da der Mermaid Code Text kannst du auch ein LLM nutzen, um aus einem Datensatz Diagramme zu erstellen.
Obsidian unterstützt Mermaid nativ, also ohne Plugin. Bisher wurde ein Mermaid-Codeblock immer als Diagramm gerendert, mit der Obsidian Version ≥ 1.13 ist das nicht mehr der Fall. Nun muss du zunächst das Feature in den Einstellungen anschalten. Falls es nicht angeschaltet ist bekommst du einen Hinweis an dem Mermaid Codeblock, dass du Mermaid aktivieren musst.
Erste Schritte
Ein einfacher Mermaid-Block sieht im Quelltext so aus:
```mermaid
flowchart LR
A[Start] --> B[Schritt 1] --> C[Ende]
```
--- config: theme: 'default' --- flowchart LR A[Start] --> B[Schritt 1] --> C[Ende]
Der Bezeichner mermaid nach den drei Backticks in der ersten Zeile des Code-Blocks teilt Obsidian mit, dass der Inhalt an den Mermaid-Renderer übergeben werden soll. Ohne diesen Hinweis würde Obsidian den Block als reinen Text darstellen.
flowchart legt den Diagrammtyp fest.
LR bestimmt die Richtung des Graphen. Die vier Optionen sind LR (links nach rechts), RL (rechts nach links), TD oder TB (oben nach unten) und BT (unten nach oben).
A[Start] definiert einen Knoten. A ist der interne Bezeichner, den Mermaid zur Verknüpfung verwendet und der im Diagramm nicht sichtbar ist. [Start] ist die Beschriftung, die im Rechteck angezeigt wird. Der Bezeichner muss innerhalb des Diagramms eindeutig sein, die Beschriftung darf beliebig sein.
Ein Bezeichner kann ein beliebiger String sein, er muss aber einige Bedingungen erfüllen:
- Er muss in dem Diagramm nur einmal vorkommen
- Er darf keine Leerzeichen enthalten
- Er darf nicht mit Mermaid-Schlüsselwörtern kollidieren
Als eine bewährte Methode haben sich aber Buchstaben oder Buchstabe-Zahl-Kombinationen durchgesetzt, da sie helfen, den Ablauf im Auge zu behalten.
--> zeichnet einen gerichteten Pfeil vom linken zum rechten Knoten.
B[Schritt 1] und C[Ende] folgen demselben Muster wie A.
Die Kette A --> B --> C ist eine Kurzschreibweise für zwei separate Verbindungen und gleichbedeutend mit:
A --> B
B --> C
Wenn du nicht im Quellcode-Modus bist, wirst du nun das Diagramm sehen, wenn du den Code-Block verlässt
--- config: theme: 'default' --- flowchart LR A[Start] --> B[Schritt 1] --> C[Ende]
Hinweis zu den Codebeispielen
Die gerenderten Diagramme in diesem Artikel enthalten einen Frontmatter-Block zur Theme-Einstellung.
--- config: theme: 'default' ---Dieser fehlt in den Codebeispielen die zum Kopieren gedacht sind. Falls du deine Diagramme nur in Obsidian nutzt, kannst du ihn ignorieren. Mehr dazu im Abschnitt Diagramme anpassen.
Der einfache Flowchart hat dir gezeigt wie ein Mermaid-Block grundsätzlich aufgebaut ist. Jetzt gehen wir tiefer in die wichtigsten Diagrammtypen, angefangen mit dem Flowchart, aber etwas detailierter.
Flowchart
Der Flowchart ist der vielseitigste und am häufigsten verwendete Diagrammtyp in Mermaid. Er eignet sich überall dort, wo ein Ablauf mit Entscheidungen, Verzweigungen oder parallelen Pfaden visualisiert werden soll: Workflows, Entscheidungsbäume, Programmlogik oder Prozessdokumentation. Das einfachste Beispiel wurde bereits in der Einleitung gezeigt.
Richtung und Knotenformen
Die Richtung eines Flowcharts wird direkt hinter dem Schlüsselwort flowchart angegeben: LR (links nach rechts), RL, TD oder TB (oben nach unten) und BT (unten nach oben). So kannst du z.B. das obige Beispiel leicht umdrehen.
--- config: theme: 'default' --- flowchart BT A[Start] --> B[Schritt 1] --> C[Ende]
Für die Knoten kannst du verschiedene Formen verwenden. In der Prozessdarstellung haben sie meist eine semantische Bedeutung, die sich aus Standards wie ISO 5807 oder UML ableitet.
Rechteck [Text] ist der generische Prozessschritt, also “hier passiert etwas”.
--- config: theme: 'default' --- flowchart LR A[Rechteck]
Abgerundetes Rechteck (Text) und Stadion ([Text]) markieren Anfang und Ende eines Prozesses, den sogenannten Terminal. In der Praxis werden beide dafür verwendet, die Stadionform ist dabei die modernere Variante.
--- config: theme: 'default' --- flowchart A(Abgerundetes Rechteck) B([Stadion])
Subroutine [[Text]] zeigt an dass hier ein Unterprozess oder eine wiederverwendbare Funktion aufgerufen wird, die anderswo definiert ist.
--- config: theme: 'default' --- flowchart LR A[[Subroutine]]
Datenbank [(Text)] steht für gespeicherte Daten, also Datenbanken, Dateien oder andere persistente Speicher.
--- config: theme: 'default' --- flowchart LR A[(Datenbank)]
Kreis ((Text)) ist der Verbindungsmarker, im Standard als Konnektor bezeichnet. Er wird verwendet um Diagramme seitenübergreifend zu verbinden oder lange Pfeile durch einen benannten Sprungpunkt zu ersetzen.
--- config: theme: 'default' --- flowchart LR A((Kreis))
Doppelkreis (((Text))) ist eine Variante des Konnektors und wird im Kontext von Petri-Netzen für finale Zustände verwendet.
--- config: theme: 'default' --- flowchart LR A(((Doppelkreis)))
Raute {Text} ist die Entscheidung mit mehreren möglichen Ausgängen, klassisch Ja/Nein.
--- config: theme: 'default' --- flowchart LR A{Raute}
Hexagon {{Text}} steht für eine Vorbereitung oder Initialisierung, also ein Schritt der Variablen setzt bevor der eigentliche Prozess beginnt.
--- config: theme: 'default' --- flowchart LR A{{Hexagon}}
Parallelogramm [/Text/] kennzeichnet Ein- und Ausgabe, also wenn Daten von außen ins System kommen oder nach außen gehen. Die gespiegelte Variante [\Text\] hat dieselbe Semantik, die Schrägung zeigt nur in die andere Richtung.
--- config: theme: 'default' --- flowchart A[/Parallelogramm/] B[\gespiegelt\]
Trapez [/Text\] und seine gespiegelte Variante [\Text/] haben keine fest etablierte Semantik im klassischen Standard, tauchen aber gelegentlich für manuelle Operationen oder Vorbereitungsschritte auf.
--- config: theme: 'default' --- flowchart A[/==Trapez==/\] B[\gespiegelt/]
Asymmetrische Form >Text] ist ein nach rechts zeigender Pfeilknoten ohne standardisierte Bedeutung, in der Praxis selten verwendet.
--- config: theme: 'default' --- flowchart LR A>Asymmetrische Form]
Weitere Knotenformen
Ab Mermaid Version 11.3 und der Obsidian Version 1.7 gibt es zusätzlich über 30 neue Formen mit einer eigenen Syntax:
```mermaid
flowchart
A@{ shape: cloud, label: "Externe Quelle"}
B@{ shape: document, label: "Bericht"}
C@{ shape: delay, label: "Verzögerung"}
```
Anmerkung: In Obsidian wird das obige Beispiel unterstütz, in Quartz leider noch nicht. Daher musste ich an dieser Stelle auf ein Bild zurückgreifen.
Eine vollständige Liste dieser neuen Knotenformen findest du in der Mermaid Flowchart Doku
Verbindungen und Beschriftungen
Für die Verbindung zwischen den Knoten kannst du verschiedene Typen auswählen:
A --> B %% einfacher Pfeil
A --- B %% Linie ohne Pfeil
A -.-> B %% gestrichelter Pfeil
A ==> B %% dicker Pfeil
A -- Text --> B %% Pfeil mit Beschriftung
A -->|Text| B %% alternative Schreibweise
A --o B %% Kreis als Ziel
A --x B %% Kreuz als Ziel
A <--> B %% bidirektionaler Pfeil
Wie jeder bei jedem Code sind Kommentare wichtig. Die werden, wie in dem obigen Beipiel, mit
%% eingeleitet. Der Kommentar wird nicht im Diagramm angezeigt.
Subgraphen
Für die Übersichtlichkeit ist es oft sinnvoll, einzelne Knoten in benannte Gruppen zusammenzufassen. Das ist besonders nützlich wenn ein Prozess mehrere Verantwortungsbereiche hat:
```mermaid
flowchart TD
subgraph Erfassen
A([Eingang]) --> B[Lesen]
B --> C{Relevant?}
end
subgraph Verarbeiten
D[Notiz erstellen] --> E[Verlinken]
E --> F[Tag vergeben]
end
subgraph Ablegen
G[(Vault)]
end
C -->|Ja| D
C -->|Nein| H[Verwerfen]
F --> G
```
--- config: theme: 'default' --- flowchart TD subgraph Erfassen A([Eingang]) --> B[Lesen] B --> C{Relevant?} end subgraph Verarbeiten D[Notiz erstellen] --> E[Verlinken] E --> F[Tag vergeben] end subgraph Ablegen G[(Vault)] end C -->|Ja| D C -->|Nein| H[Verwerfen] F --> G
Längere Verbindungen
Durch zusätzliche Bindestriche in der Pfeilsyntax lässt sich eine Verbindung über mehrere Ebenen strecken, was bei komplexen Graphen die Lesbarkeit verbessern kann:
A --> B
B ----> E %% überspringt zwei Ebenen
--- config: theme: 'default' --- flowchart TD A[Idee] --> B[Entwurf] B --> C[Review] C --> D[Freigabe] B ----> E[Archiv]
Sequence Diagram
Das Sequenzdiagramm wird überall dort eingesetzt wo es darum geht zu zeigen wer in welcher Reihenfolge mit wem kommuniziert. Typische Anwendungsfälle sind:
- Die Dokumentation von API-Aufrufen zwischen Systemen, also zum Beispiel wie eine App mit einem Server spricht und was dabei hin und her geht. Das ist der klassische Entwickler-Anwendungsfall.
- Die Darstellung von Authentifizierungsabläufen, etwa wie ein Login-Prozess mit mehreren beteiligten Diensten funktioniert.
- Die Beschreibung von Plugin-Interaktionen in Obsidian, wie das Beispiel zeigt. Wer ruft was auf, wer antwortet mit was.
Es eignet sich auch gut um Arbeitsabläufe mit mehreren Beteiligten zu dokumentieren, also zum Beispiel einen Redaktionsprozess wo Autor, Lektor und Verlag nacheinander aktiv werden, oder einen Support-Workflow wo Nutzer, Helpdesk und Fachabteilung miteinander kommunizieren.
Der entscheidende Unterschied zum Flowchart: beim Flowchart steht der Prozess im Vordergrund, beim Sequenzdiagramm die Kommunikation zwischen den Beteiligten. Sobald mehr als eine Person oder ein System beteiligt ist und die Reihenfolge der Nachrichten wichtig ist, ist das Sequenzdiagramm die bessere Wahl.
Im Code werden zunächst alle Teilnehmer mit ihrem Typ festgelegt. Neben dem actor als Strichmännchen und dem participant als Box sind noch einige andere Teilnehmertypenmöglich. Die explizite Definition ist nur notwendig, wenn du verschiedene Teilnehmertypen verwenden möchtest. Ohne sie werden alle Teilnehmer als Box gerendert.
Nachdem die Teilnehmer definiert sind, werden die Schritte der Sequenz festgelegt, wobei die Position der Zeile die zeitliche Reihenfolge abbildet.
Die Syntax ist einfach: die Akteure werden mit einem Pfeil --> verbunden, und nach einem Doppelpunkt folgt der Text der über dem Pfeil erscheinen soll:
Autor->>Redaktion: Schickt Artikel ein
Daraus resultiert dann die Darstellung (5), aber auch die Reihenfolge der Akteure im Kopf und Fuss-Bereich. So geht es dann Schritt für Schritt weiter.
Für die Verbindung zwischen den Akteuren bietet Mermaid wieder eine Vielzahl von Verbindungstypen, die nicht identisch sind mit den Pfeilen im Flowchart.
In dem Beispiel nutzen wir nur die durchgezogene Linie ->>und die gestrichelte Linie -->>.
```mermaid
sequenceDiagram
actor Autor
participant Redaktion
participant Lektor
actor Leser
Autor->>Redaktion: Schickt Artikel ein
Redaktion->>Lektor: Weiterleitung zur Prüfung
Lektor-->>Autor: Feedback mit Änderungswünsche
Autor->>Lektor: Überarbeitete Version
Lektor-->>Redaktion: Freigabe
Redaktion->>Leser: Veröffentlichung
```
Class Diagram
Klassendiagramme werden in der Softwareentwicklung verwendet um Objekte und ihre Beziehungen zu modellieren.
Eine solche Klassenbox besteht klassischerweise aus drei Bereichen und der Verbindung zu anderen Klassen. Die drei Bereiche sind:
- (1) Der Klassenname
- (2) Die Attribute der Klassen
- (3) Die Methoden die Objekte dieser Klasse ausführen können
- (4) Visualisiert die Beziehung zwischen zwei Klassen.
Die Zahl 1 an der Pfeil (4) bedeutet, dass auf dieser Seite immer genau ein Projekt steht. Der Punkt auf der anderen Seite steht für “beliebig viele”. Zusammen gelesen bedeutet das: ein Projekt enthält beliebig viele Notizen.
Auch die Klassendiagramme haben eine eignen Syntax für die Pfeile:
A --> B Assoziation
A ..> B Abhängigkeit (gestrichelt)
A --|> B Vererbung (Dreieck ausgefüllt)
A ..|> B Realisierung (gestrichelt mit Dreieck)
A --* B Komposition (ausgefüllte Raute)
A --o B Aggregation (offene Raute)
A -- B einfache Linie ohne Pfeilspitze
Die Klassendiagramme sind sehr speziell für die Softwareentwicklung konzipiert, lassen sich aber auch in anderen Bereiche einsetzten wo es um Beziehungen zwischen Personen und/oder Objekten geht.
Hier nun ein eher Softwarebezogenes Beispiel:
--- config: theme: 'default' --- classDiagram class Notiz { +String titel +Date erstellt +List tags +bearbeiten() +exportieren() } class Projekt { +String name +String status +hinzufuegen(notiz) } class Tag { +String name +zaehlen() int } Projekt "1" --> "*" Notiz : enthält Notiz "*" --> "*" Tag : hat
State Diagram
Mit einem Zustandsdiagramm kann visualisiert werden, welche Zustände ein Objekt annehmen kann und wie die Übergänge von einem Zustand in den nächsten sind. Dabei steht nicht der Ablauf im Vordergrund, wie bei einem Flowchart, sondern das Objekt selbst und seine Zustände.
Eine Notiz in Obsidian kann neu eingegangen, in Bearbeitung, blockiert oder abgeschlossen sein. Das Zustandsdiagramm macht diese Zustände und die Übergänge zwischen ihnen sichtbar.
Für Nicht-Informatiker ist das Werkzeug überall dort nützlich wo Dinge einen definierten Lebenszyklus haben: ein Ticket im Support, ein Artikel im Redaktionsprozess, eine Aufgabe im Projektmanagement, oder eben eine Notiz im PKM-System.
Syntax
[*] ist ein Sonderzeichen und steht für den Start- beziehungsweise Endpunkt. Am Anfang einer Verbindung ist es der Einstieg ins Diagramm, am Ende einer Verbindung bedeutet es dass das Objekt seinen Lebenszyklus abgeschlossen hat.
Inbox --> InBearbeitung : aufgreifen definiert einen Übergang. Links steht der Ausgangszustand, rechts der Zielzustand, und nach dem Doppelpunkt steht das Ereignis oder die Aktion die den Übergang auslöst.
Was das Beispiel außerdem zeigt: ein Zustand kann mehrere mögliche Übergänge haben. Abgeschlossen kann entweder direkt enden [*] oder ins Archiv wechseln. Und Übergänge können auch rückwärts laufen, Wartend kann wieder zu InBearbeitung werden wenn die Blockade aufgehoben ist.
Beispiel: Notiz-Lebenszyklus
Das Diagramm unten zeigt den kompletten Weg einer Notiz vom Eingang bis zur Ablage. Eine neue Notiz landet zuerst in der Inbox. Von dort wird sie aufgegriffen und wandert in die Bearbeitung. Wenn etwas fehlt oder eine Entscheidung aussteht, wechselt sie in den Wartezustand und kommt zurück sobald die Blockade aufgehoben ist. Nach Abschluss gibt es zwei Wege: direktes Beenden oder Archivieren.
--- config: theme: 'default' --- stateDiagram-v2 [*] --> Inbox Inbox --> InBearbeitung : aufgreifen InBearbeitung --> Wartend : blockiert Wartend --> InBearbeitung : freigegeben InBearbeitung --> Abgeschlossen : fertig Abgeschlossen --> Archiv : archivieren Abgeschlossen --> [*] Archiv --> [*]
```mermaid
sequenceDiagram
actor Autor
participant Redaktion
participant Lektor
actor Leser
Autor->>Redaktion: Schickt Artikel ein
Redaktion->>Lektor: Weiterleitung zur Prüfung
Lektor-->>Autor: Feedback mit Änderungswünsche
Autor->>Lektor: Überarbeitete Version
Lektor-->>Redaktion: Freigabe
Redaktion->>Leser: Veröffentlichung
```
Entity Relationship Diagram
Ein ER-Diagramm zeigt welche Dinge es in einem System gibt, welche Eigenschaften sie haben und wie sie miteinander zusammenhängen. Es stammt aus der Datenbankwelt wo es zur Planung von Tabellenstrukturen eingesetzt wird, ist aber eigentlich ein universelles Werkzeug für alle Situationen wo man Dinge, ihre Merkmale und ihre Beziehungen strukturiert darstellen will.
Der Unterschied zum Klassendiagramm ist, dass das ER-Diagramm den Aufbau der Datensätze und Tabellen zeigt, während das Klassendiagramm Objekte und ihr Verhalten visualisiert.
Außerhalb der Programmierung macht ein ER-Diagramm überall Sinn wo Daten strukturiert erfasst werden: eine Bibliothek mit Büchern, Autoren und Ausleihen, ein Verein mit Mitgliedern, Veranstaltungen und Beiträgen, oder ein Haushaltsbuch mit Kategorien, Ausgaben und Konten.
Syntax
Jede Entität bekommt einen Block mit ihren Attributen. PK steht für Primary Key, also das eindeutige Merkmal das jeden Datensatz identifiziert. FK steht für Foreign Key, ein Verweis auf einen Datensatz in einer anderen Entität.
Die Beziehungslinien folgen einer eigenen Notation die auf den ersten Blick kryptisch wirkt, aber einem einfachen Muster folgt:
NUTZER ||--o{ PROJEKT : "leitet"
Die Symbole links und rechts von -- beschreiben die Multiplizität auf jeder Seite. || bedeutet genau einer, o{ bedeutet null oder viele. Zusammen gelesen: ein Nutzer leitet null oder viele Projekte, und jedes Projekt gehört zu genau einem Nutzer.
Die vollständige Symbolübersicht:
o| null oder einer
|| genau einer
o{ null oder viele
|{ einer oder viele
Die Symbole können beide Richtungen abbilden. }o auf der linken Seite bedeutet null oder viele Mitglieder, o{ auf der rechten Seite bedeutet null oder viele Veranstaltungen.
Beispiel außerhalb der Programmierung: Vereinsverwaltung
--- config: theme: 'default' --- erDiagram MITGLIED { int id PK string name date eintrittsdatum } VERANSTALTUNG { int id PK string titel date datum string ort } BEITRAG { int id PK int mitglied_id FK date faellig boolean bezahlt } MITGLIED ||--o{ BEITRAG : "zahlt" MITGLIED }o--o{ VERANSTALTUNG : "nimmt teil"
Die }o--o{ Beziehung zwischen Mitglied und Veranstaltung ist eine sogenannte Viele-zu-Viele-Beziehung: ein Mitglied kann an vielen Veranstaltungen teilnehmen, und eine Veranstaltung hat viele Mitglieder.
Gantt Chart
Anders als die zuletzt gezeigten Diagrammtypen ist der Gantt Chart kein Werkzeug aus der Softwareentwicklung sondern ein klassisches Projektmanagement-Instrument das seit über hundert Jahren eingesetzt wird.
Ein Gantt-Chart hilfreich, da es Aufgaben, Abhängigkeiten und Zeiträume auf einen Blick zeigen kann.
Syntax
title setzt die Überschrift des Diagramms. dateFormat legt fest in welchem Format die Datumsangaben im Code geschrieben werden, YYYY-MM-DD ist das ISO-Standardformat.
section gruppiert zusammengehörige Aufgaben in einen benannten Bereich, vergleichbar mit einem Projektabschnitt oder einer Phase.
Jede Aufgabe folgt diesem Muster:
Aufgabenname :status, id, startdatum, dauer
Der Status ist optional und kennt drei Werte: done für abgeschlossen, active für laufend, und crit für kritisch. Ohne Statusangabe erscheint die Aufgabe in der Standardfarbe.
Die id ist ein interner Bezeichner der nur für Abhängigkeiten gebraucht wird. Mit after r1 als Startdatum sagt man Mermaid: diese Aufgabe beginnt sobald die Aufgabe mit der id r1 abgeschlossen ist. Die Dauer wird als 3d für drei Tage oder als konkretes Enddatum angegeben.
Beispiel: Blogpost planen
--- config: theme: 'default' --- gantt title Blogpost veröffentlichen dateFormat YYYY-MM-DD section Vorbereitung Thema festlegen :done, t1, 2025-03-01, 1d Recherche :done, t2, after t1, 3d section Schreiben Erster Entwurf :active, s1, after t2, 4d Überarbeitung :crit, s2, after s1, 2d section Veröffentlichung Bilder erstellen : b1, after s2, 1d Korrekturlesen : k1, after s2, 1d Online stellen : v1, after b1, 1d
```mermaid
gantt
title Blogpost veröffentlichen
dateFormat YYYY-MM-DD
section Vorbereitung
Thema festlegen :done, t1, 2025-03-01, 1d
Recherche :done, t2, after t1, 3d
section Schreiben
Erster Entwurf :active, s1, after t2, 4d
Überarbeitung :crit, s2, after s1, 2d
section Veröffentlichung
Bilder erstellen : b1, after s2, 1d
Korrekturlesen : k1, after s2, 1d
Online stellen : v1, after b1, 1d
```
crit markiert die Überarbeitung als kritischen Schritt, also einen der den Gesamtzeitplan gefährdet wenn er sich verzögert. Außerdem zeigt das Beispiel dass b1 und k1 beide nach s2 beginnen und damit parallel laufen, Bilder erstellen und Korrekturlesen können gleichzeitig erledigt werden.
Die Schreibweise ist dann aber doch recht komplex. Aber wwenn du die Daten eines solchen Projektes vorliegen hast, kannst mit ein LLM wie Claude auffordern, daraus ein Mermaid-Gantt-Chart zu erstellen.
Pie Chart
Das Tortendiagramm gehört zu den beliebtesten Diagrammtypen überhaupt, es wird gerne genutzt, ist aber nicht immer die beste Wahl. Ein Tortendiagramm funktioniert in den Fällen gut, wo es um Anteile eines Ganzen geht und es nicht mehr als fünf bis sechs Segmente gibt, die dann auch nicht zu klein sind. Sobald viele kleine Tortenstücke entstehen oder man Werte miteinander vergleichen will, ist ein Balkendiagramm fast immer lesbarer.
Syntax
Die Syntax ist die einfachste aller Mermaid-Diagrammtypen. title setzt die Überschrift, danach folgen die Segmente mit dem Namen in Anführungszeichen und Wert nach dem Doppelpunkt. Die Werte müssen keine Prozentzahlen sein, Mermaid berechnet die Anteile automatisch aus den angegebenen Zahlen.
pie title Mein Diagramm
"Segment A" : 42
"Segment B" : 58
Du musst aber selbst darauf achten, dass die Summer der einzelnen Tortenstücke 100ergibt. Ansonsten wird das Tortendiagramm nicht korrekt gerendert.
Ansonsten ist das Tortendiagramm ist bewusst einfach gehalten.
Beispiel: Zeitverteilung in der Woche
```mermaid
pie title Womit verbringe ich meine Zeit?
"Tiefe Arbeit" : 12
"Meetings" : 8
"E-Mails" : 6
"Administratives" : 4
"Sonstiges" : 3
```
--- config: theme: 'default' --- pie title Womit verbringe ich meine Zeit? "Tiefe Arbeit" : 12 "Meetings" : 8 "E-Mails" : 6 "Administratives" : 4 "Sonstiges" : 3
XY Chart
Der XY Chart ist einer der jüngeren Diagrammtypen in Mermaid. Anders als der Pie Chart eignet er sich besonders gut für Verläufe und Vergleiche über mehrere Datenpunkte hinweg, also überall dort wo man sehen will wie sich etwas entwickelt oder wie verschiedene Kategorien im Verhältnis zueinander stehen.
Syntax
xychart ist der Diagrammtyp. x-axis definiert die horizontale Achse, entweder als Liste von Beschriftungen in eckigen Klammern oder als Zahlenbereich. y-axis definiert die vertikale Achse mit Beschriftung und optionalem Wertebereich. Danach folgen die Datenreihen als bar für Balken oder line für Linien, jeweils mit den Werten in eckigen Klammern.
Beispiel 1: Balkendiagramm
```mermaid
---
config:
xyChart:
width: 600
height: 400
---
xychart
title "Notizen pro Monat"
x-axis ["Jan", "Feb", "Mrz", "Apr", "Mai", "Jun"]
y-axis "Anzahl Notizen" 0 --> 50
bar [12, 19, 15, 28, 34, 22]
```
--- config: theme: 'default' xyChart: width: 600 height: 400 --- xychart-beta title "Notizen pro Monat" x-axis ["Jan", "Feb", "Mrz", "Apr", "Mai", "Jun"] y-axis "Anzahl Notizen" 0 --> 50 bar [12, 19, 15, 28, 34, 22]
Anmerkung: Im gerenderten Beispiel ist als Diagrammtyp xychart-beta abgegeben, da Obsidian eine neuere Version von Mermaid implementiert hat, reicht im Code-Block xychart.
Beispiel 2: Liniendiagramm
```mermaid
---
config:
themeVariables:
xyChart:
plotColorPalette: 'red'
xyChart:
width: 600
height: 400
---
xychart
title "Wöchentliche Schreibzeit in Stunden"
x-axis ["KW1", "KW2", "KW3", "KW4", "KW5", "KW6"]
y-axis "Stunden" 0 --> 20
line [4, 7, 5, 12, 9, 15]
```
Die XY Charts bieten einige Einstellmöglichkeiten, die im Mermaid-Frontmatter definiert werden. In dem Beispiel die Größe, aber auch, über die speziellen themeVariables für das xyChart, die Farbe der Linie.
--- config: theme: 'default' themeVariables: xyChart: plotColorPalette: 'red' xyChart: width: 600 height: 400 --- xychart-beta title "Wöchentliche Schreibzeit in Stunden" x-axis ["KW1", "KW2", "KW3", "KW4", "KW5", "KW6"] y-axis "Stunden" 0 --> 20 line [4, 7, 5, 12, 9, 15]
Anmerkung: Im gerenderten Beispiel ist als Diagrammtyp xychart-beta abgegeben, da Obsidian eine neuere Version von Mermaid implementiert hat, reicht im Code-Block xychart.
Was sonst noch möglich ist
Mehrere Datenreihen im selben Diagramm sind möglich indem man einfach mehrere bar oder line Einträge untereinander schreibt. Unter xyChart im Frontmatter-Block lassen sich width, height und plotReservedSpacePercent anpassen, letzteres steuert wie viel Platz die eigentliche Zeichenfläche im Verhältnis zu Achsenbeschriftungen bekommt. Stacked Bars und gruppierte Balken sind aktuell nicht unterstützt, dafür bräuchte man ein externes Tool oder ein selbst gebautes SVG. Viele weitere Beispiele und Konfigurationsmöglichkeiten findest du in der Dokumentation.
Mindmap
Eine Mindmap in Mermaid ist ein Darstellungswerkzeug, kein Denkwerkzeug. Das klingt nach einer Kleinigkeit, ist aber ein wichtiger Unterschied. Wenn du mit Mermaid eine Mindmap erstellst, solltest du deine Gedanken bereits sortiert haben und sie nur noch strukturiert darstellen wollen. Für das eigentliche Erarbeiten einer Mindmap sind Papier und Bleistift oder ein interaktives Tool wie Freemind die bessere Wahl.
```mermaid
mindmap
root((Obsidian))
Kernfunktionen
Markdown-Editor
Graph View
Backlinks
Tags
Plugins
Dataview
Templater
Calendar
Mermaid
Flowchart
Sequenz
Gantt
Mindmaps
```
--- config: theme: 'default' --- mindmap root((Obsidian)) Kernfunktionen Markdown-Editor Graph View Backlinks Tags Plugins Dataview Templater Calendar Mermaid Flowchart Sequenz Gantt Mindmaps
Timeline
Die Timeline braucht kaum Einarbeitung. Ereignisse werden in chronologischer Reihenfolge von links nach rechts dargestellt. Sie eignet sich für historische Übersichten, Produktgeschichten, Projektmeilensteine oder den Lebenslauf eines Konzepts. Anders als der Gantt Chart zeigt sie keine Dauer von Aufgaben sondern einzelne Zeitpunkte und Ereignisse.
Syntax
Die Syntax ist bewusst minimal gehalten. Nach title folgen die Einträge im Format Zeitangabe : Ereignis. Die Zeitangabe kann eine Jahreszahl, ein Datum oder jeder beliebige Text sein, Mermaid interpretiert sie nicht als echtes Datum sondern als Beschriftung.
Ein Zeitpunkt kann mehrere Ereignisse enthalten. Dafür gibt es zwei gleichwertige Schreibweisen:
2020 : Obsidian erscheint : Roam Research wird populär
Oder mit Einrückung in der Folgezeile, was bei längeren Einträgen lesbarer ist:
2020 : Obsidian erscheint
: Roam Research wird populär
Beide Ereignisse landen dann unter demselben Zeitpunkt in der Timeline.
Abschnitte
Mit section lassen sich Ereignisse in farblich unterschiedliche Gruppen einteilen:
--- config: theme: 'default' --- timeline title Mein PKM-Weg section Papier 1995 : Erste Notizbücher 2005 : GTD nach David Allen section Digital 2010 : Evernote 2015 : Apple Notes 2018 : Notion 2020 : Obsidian erscheint : Roam Research wird populär section PKM 2021 : Obsidian entdeckt 2022 : Zettelkasten eingeführt 2023 : Vault vollständig migriert
```mermaid
timeline
title Mein PKM-Weg
section Papier
1995 : Erste Notizbücher
2005 : GTD nach David Allen
section Digital
2010 : Evernote
2015 : Apple Notes
2018 : Notion
2020 : Obsidian erscheint
: Roam Research wird populär
section PKM
2021 : Obsidian entdeckt
2022 : Zettelkasten eingeführt
2023 : Vault vollständig migriert
```
section ist besonders nützlich wenn man verschiedene Phasen oder Kategorien voneinander abgrenzen möchte. Jede Sektion bekommt automatisch eine eigene Farbe, ohne dass man selbst Hand anlegen muss.
Einschränkungen
Die Timeline hat keine Unterstützung für genaue Datumsangaben mit automatischer Skalierung wie der Gantt Chart. Die Abstände zwischen den Zeitpunkten sind immer gleich groß, egal ob zwischen zwei Einträgen ein Jahr oder zwanzig Jahre liegen. Für präzise zeitliche Verhältnisse ist der Gantt Chart die bessere Wahl.
Quadrant Chart
Im Quadrant Chart wird eine Fläche in vier Bereiche aufgeteilt, in denen Punkte positioniert werden. Jeder Punkt steht für eine Idee, eine Aufgabe oder ein Objekt, und seine Position im Diagramm bewertet es entlang zweier Achsen gleichzeitig.
Das Prinzip ist bekannt aus der Eisenhower-Matrix die Aufgaben nach Dringlichkeit und Wichtigkeit einteilt, lässt sich aber auf alles anwenden wo zwei Kriterien gleichzeitig eine Rolle spielen: Filme, Produkte, Ideen oder Entscheidungen.
Syntax
x-axis und y-axis definieren die beiden Achsen mit je einer Beschriftung für den niedrigen und den hohen Wert, getrennt durch -->. Beschriftungen mit Leerzeichen müssen in Anführungszeichen stehen. Umlaute sind leider nicht erlaubt und führen zu einem Parsing-Fehler, also ae statt ä.
quadrant-1 bis quadrant-4 beschriften die vier Felder. Die Nummerierung folgt dem mathematischen Standard: quadrant-1 ist oben rechts, quadrant-2 oben links, quadrant-3 unten links und quadrant-4 unten rechts.
Punkte werden mit Name, Doppelpunkt und zwei Koordinaten in eckigen Klammern definiert:
Blogartikel schreiben: [0.75, 0.85]
Die Koordinaten sind Dezimalwerte zwischen 0 und 1, wobei 0 dem linken beziehungsweise unteren Rand entspricht und 1 dem rechten beziehungsweise oberen. Der erste Wert ist die Position auf der X-Achse, der zweite auf der Y-Achse.
Beispiel: Eisenhower-Matrix
--- config: theme: 'default' --- quadrantChart title Aufgaben nach Eisenhower x-axis "Nicht dringend" --> "Dringend" y-axis "Nicht wichtig" --> "Wichtig" quadrant-1 Sofort erledigen quadrant-2 Planen quadrant-3 Delegieren quadrant-4 Eliminieren Steuererklarung: [0.9, 0.9] Artikel schreiben: [0.2, 0.8] Newsletter lesen: [0.8, 0.2] Social Media: [0.3, 0.15] Weiterbildung: [0.25, 0.75] Meetings vorbereiten: [0.7, 0.7]
```mermaid
quadrantChart
title Aufgaben nach Eisenhower
x-axis "Nicht dringend" --> "Dringend"
y-axis "Nicht wichtig" --> "Wichtig"
quadrant-1 Sofort erledigen
quadrant-2 Planen
quadrant-3 Delegieren
quadrant-4 Eliminieren
Steuererklarung: [0.9, 0.9]
Artikel schreiben: [0.2, 0.8]
Newsletter lesen: [0.8, 0.2]
Social Media: [0.3, 0.15]
Weiterbildung: [0.25, 0.75]
Meetings vorbereiten: [0.7, 0.7]
```
Einschränkungen
Die Punkte haben alle dieselbe Farbe und Größe, eine individuelle Einfärbung einzelner Punkte ist nicht möglich. Und verträgt der Parser keine Umlaute in Punktnamen oder Achsenbeschriftungen.
Git Graph
Der Git Graph ist ursprünglich für Entwickler gedacht, die mit dem Versionskontrollsystem Git arbeiten. Git verwaltet den Verlauf eines Projekts in sogenannten Commits, also gespeicherten Zuständen, und Branches sind parallele Entwicklungsstränge die später wieder zusammengeführt werden. Der Git Graph macht diese Struktur sichtbar.
Der Git Graph ist der einzige Mermaid-Diagrammtyp der parallele Stränge mit Verzweigungen und Zusammenführungen visualisiert, ähnlich wie eine U-Bahn-Karte Linien zeigt die sich an bestimmten Stationen treffen und wieder trennen. Das macht ihn auch außerhalb der Softwareentwicklung interessant. Ein Buchprojekt mit parallel geschriebenen Kapiteln, eine Produktentwicklung mit mehreren Teams oder ein Redaktionsprozess mit verschiedenen Autoren lassen sich damit überraschend gut abbilden, solange man keine Zeitachse braucht. Denn das ist der wesentliche Unterschied zum Gantt Chart, der keine Daten oder Dauern kennt, sondern nur Reihenfolge und Struktur zeigt.
Syntax
commit fügt einen Schritt zum aktuellen Strang hinzu. Mit id: bekommt er eine lesbare Beschriftung, ohne id generiert Mermaid einen zufälligen Bezeichner.
branch erstellt einen neuen Strang vom aktuellen Punkt aus. checkout wechselt auf einen anderen Strang. merge führt einen Strang in den aktuellen zurück.
Beispiel: Buchprojekt
--- config: theme: 'default' --- gitGraph commit id: "Projektstart" commit id: "Gliederung fertig" branch kapitel-1 branch kapitel-2 checkout kapitel-1 commit id: "Entwurf K1" commit id: "Review K1" checkout kapitel-2 commit id: "Entwurf K2" checkout main merge kapitel-1 id: "K1 abgenommen" checkout kapitel-2 commit id: "Review K2" checkout main merge kapitel-2 id: "K2 abgenommen" commit id: "Lektorat" commit id: "Druckfreigabe"
```mermaid
gitGraph
commit id: "Projektstart"
commit id: "Gliederung fertig"
branch kapitel-1
branch kapitel-2
checkout kapitel-1
commit id: "Entwurf K1"
commit id: "Review K1"
checkout kapitel-2
commit id: "Entwurf K2"
checkout main
merge kapitel-1 id: "K1 abgenommen"
checkout kapitel-2
commit id: "Review K2"
checkout main
merge kapitel-2 id: "K2 abgenommen"
commit id: "Lektorat"
commit id: "Druckfreigabe"
```
Die hier gezeigten Diagrammtypen decken die gängigsten Anwendungsfälle ab, Mermaid bietet aber noch weitere spezialisierte Typen wie Sankey-Diagramme, Kanban-Boards, Requirement-Diagramme und einiges mehr. Eine vollständige Übersicht findet sich in der offiziellen Dokumentation auf https://mermaid.js.org/intro/.
Diagramme anpassen: Farben, Größe und Themes
Mermaid bietet drei Ebenen der Anpassung die sich gegenseitig ergänzen: der Frontmatter-Block steuert das gesamte Diagramm, classDef und style steuern einzelne Knoten, und linkStyle steuert einzelne Verbindungspfeile. Die drei Ebenen können kombiniert werden, wobei spezifischere Angaben immer Vorrang vor allgemeineren haben. Ein style auf einem einzelnen Knoten schlägt also immer das Theme.
Ebene 1: Der Frontmatter-Block
Die empfohlene Methode seit Mermaid 10.5 ist der Frontmatter-Block direkt im Diagrammcode. Er steuert Theme, Schrift, Layout-Engine und typspezifische Einstellungen global für das gesamte Diagramm:
--- config: theme: 'forest' look: 'handDrawn' fontFamily: 'Georgia, serif' fontSize: 14 flowchart: curve: 'basis' nodeSpacing: 50 rankSpacing: 80 --- flowchart LR A[Idee] --> B[Entwurf] --> C[Fertig]
```mermaid
---
config:
theme: 'forest'
look: 'handDrawn'
fontFamily: 'Georgia, serif'
fontSize: 14
flowchart:
curve: 'basis'
nodeSpacing: 50
rankSpacing: 80
---
flowchart LR
A[Idee] --> B[Entwurf] --> C[Fertig]
```
look: 'handDrawn' gibt dem Diagramm einen Skizzen-Stil als wäre es von Hand gezeichnet, was für informelle Notizen und Brainstorming-Ergebnisse sehr gut passt. Weitere Looks sind neo und classic, wobei classic der Standard ist.
Die fünf eingebauten Themes sind default für das klassische Mermaid-Blau, neutral für zurückhaltende Grautöne, forest für Grüntöne, dark für dunkle Hintergründe und base für vollständige manuelle Kontrolle. Der Unterschied zwischen base und den anderen ist dass base kaum eigene Farben mitbringt und damit der Ausgangspunkt für eigene Farbdefinitionen über themeVariables ist. Bei den anderen Themes funktionieren themeVariables zwar teilweise auch, aber nicht vollständig und nicht zuverlässig vorhersehbar.
themeVariables erlauben es einzelne Farbvariablen eines gewählten Themes zu überschreiben. Die wichtigsten sind primaryColor für die Hauptfarbe der Knoten, primaryTextColor für die Schriftfarbe, primaryBorderColor für Rahmen, lineColor für Verbindungspfeile, secondaryColor und tertiaryColor für Akzentfarben. Du solltest all Werte als Hex-Farben angeben, CSS-Farbnamen wie red oder blue funktionieren nicht überall. Eine vollständige Liste aller verfügbaren Variablen findet sich in der offiziellen Dokumentation unter https://mermaid.js.org/config/theming.html.
Für einige Diagrammtypen wie den XY Chart gibt es eine eigene themeVariables-Option namens plotColorPalette, die unabhängig vom gewählten Theme funktioniert, also auch mit default:
---
config:
theme: 'default'
themeVariables:
xyChart:
plotColorPalette: '#4a90d9,#e74c3c,#2ecc71'
xyChart:
width: 600
height: 400
---
Die Farben werden der Reihe nach den bar und line Einträgen zugewiesen. Mehrere Datenreihen bekommen also automatisch verschiedene Farben aus der Liste.
Typspezifische Konfigurationsblöcke die direkt unter config stehen erweitern die Möglichkeiten je nach Diagrammtyp. Für flowchart sind das curve für die Form der Verbindungslinien, nodeSpacing für den horizontalen Abstand zwischen Knoten und rankSpacing für den vertikalen Abstand zwischen Ebenen. Für sequence gibt es showSequenceNumbers um Nachrichten automatisch zu nummerieren, und mirrorActors um die Teilnehmerboxen auch am unteren Rand des Diagramms zu wiederholen. Für gantt lässt sich mit axisFormat das Datumsformat der Zeitachse steuern, zum Beispiel '%d.%m' für das deutsche Format.
Ebene 2: Knoten und Pfeile im Diagrammcode
Für einzelne Knoten und Verbindungspfeile gibt es drei Werkzeuge die alle am Ende des Diagrammcodes platziert werden, nach allen Verbindungsdefinitionen. Das hält die Struktur des Diagramms oben sauber und das visuelle Dressing unten zusammen, ähnlich wie CSS am Ende eines HTML-Dokuments.
style färbt einen einzelnen Knoten direkt ein:
style A fill:#e8f4f8,stroke:#4a90d9,color:#1a1a1a,stroke-width:2px
fill setzt die Hintergrundfarbe, stroke die Rahmenfarbe, color die Schriftfarbe und stroke-width die Rahmenbreite. Alle Werte sind CSS-Eigenschaften, also sind auch stroke-dasharray für gestrichelte Rahmen oder font-weight für fette Schrift gültig. style eignet sich für Einzelfälle, wird aber schnell unübersichtlich, wenn mehrere Knoten dasselbe Aussehen bekommen sollen.
classDef definiert eine benannte Stilklasse die beliebig oft wiederverwendet werden kann:
classDef wichtig fill:#fff3cd,stroke:#e6ac00,color:#1a1a1a
Die Zuweisung an einen Knoten funktioniert auf zwei Arten. Entweder direkt in der Verbindungszeile über den ::: Operator:
A([Start]):::wichtig --> B[Schritt]
Oder über eine separate class-Anweisung am Ende, die auch mehrere Knoten auf einmal ansprechen kann:
class A,C,E wichtig
Wenn eine Klasse den Namen default trägt, wird sie automatisch auf alle Knoten angewendet, die keine explizite Klasse haben. Das ist praktisch um dem gesamten Diagramm eine einheitliche Grundfarbe zu geben und nur einzelne Knoten davon abweichen zu lassen:
classDef default fill:#f0f0f0,stroke:#999,color:#1a1a1a
linkStyle spricht Verbindungspfeile über ihren Index an, also die Reihenfolge in der sie im Code definiert wurden. Aber Achtung: Der Index des ersten Links ist 0 und nicht 1:
linkStyle 0 stroke:#4a90d9,stroke-width:2px
linkStyle default stroke:#999
linkStyle default gilt für alle Pfeile, die nicht explizit angesprochen werden, und ist praktisch um dem gesamten Diagramm eine einheitliche Pfeilfarbe zu geben.
Und hier ein Beispiel:
--- config: theme: 'base' themeVariables: primaryColor: '#f0f7fc' primaryTextColor: '#1a1a2e' primaryBorderColor: '#4a90d9' lineColor: '#4a90d9' --- flowchart TD A([Start]):::gruen --> B{Prüfen} B -->|OK| C[Verarbeiten]:::gruen B -->|Fehler| D[Korrigieren]:::rot D --> B C --> E[(Archiv)]:::blau C --> F[Benachrichtigung]:::gelb classDef gruen fill:#d4edda,stroke:#5a9e52,color:#1a1a1a classDef rot fill:#f8d7da,stroke:#c0392b,color:#1a1a1a classDef blau fill:#d6eaf8,stroke:#2980b9,color:#1a1a1a classDef gelb fill:#fff3cd,stroke:#e6ac00,color:#1a1a1a linkStyle 0,2 stroke:#5a9e52,stroke-width:2px linkStyle 3 stroke:#c0392b,stroke-width:2px linkStyle default stroke:#4a90d9
```mermaid
---
config:
theme: 'base'
themeVariables:
primaryColor: '#f0f7fc'
primaryTextColor: '#1a1a2e'
primaryBorderColor: '#4a90d9'
lineColor: '#4a90d9'
---
flowchart TD
A([Start]):::gruen --> B{Prüfen}
B -->|OK| C[Verarbeiten]:::gruen
B -->|Fehler| D[Korrigieren]:::rot
D --> B
C --> E[(Archiv)]:::blau
C --> F[Benachrichtigung]:::gelb
classDef gruen fill:#d4edda,stroke:#5a9e52,color:#1a1a1a
classDef rot fill:#f8d7da,stroke:#c0392b,color:#1a1a1a
classDef blau fill:#d6eaf8,stroke:#2980b9,color:#1a1a1a
classDef gelb fill:#fff3cd,stroke:#e6ac00,color:#1a1a1a
linkStyle 0,2 stroke:#5a9e52,stroke-width:2px
linkStyle 3 stroke:#c0392b,stroke-width:2px
linkStyle default stroke:#4a90d9
```
Die ältere %%{init}%% Direktive
Vor Mermaid 10.5 war die %%{init}%% Direktive als erste Zeile im Diagrammblock die einzige Möglichkeit das Theme zu setzen:
%%{init: {'theme': 'neutral'}}%%
flowchart LR
A --> B
Sie funktioniert noch in allen Versionen und taucht in vielen älteren Anleitungen und Foren-Antworten auf, gilt aber seit Mermaid 10.5 als veraltet. Wenn du sie in fremden Diagrammen siehst, versteht du jetzt, was sie tut, für neue Diagramme ist der Frontmatter-Block die bessere Wahl.
Notizen verlinken in Diagrammen
Obsidian erlaubt es, Knoten in einem Diagramm direkt mit Notizen im Vault zu verknüpfen. Dazu weist man den gewünschten Knoten die Klasse internal-link zu:
```mermaid
graph TD
Biologie --> Chemie
class Biologie,Chemie internal-link;
```
Ein Klick auf den Knoten im gerenderten Diagramm öffnet dann die gleichnamige Notiz, genau wie ein normaler WikiLink. Der Knotentext wird dabei als Linkziel verwendet, der Bezeichner spielt keine Rolle.
Wer viele Knoten auf einmal verlinken möchte, kann alle Bezeichner in einer einzigen class-Anweisung auflisten:
```mermaid
graph TD
A[Biologie]
B[Chemie]
C[Physik]
A --> B
B --> C
class A,B,C,D,E,F,G,H,I,J,K,L,M,N,O,P,Q,R,S,T,U,V,W,X,Y,Z internal-link;
```
Das eignet sich besonders gut wenn das Diagramm als Navigation durch einen Themenbereich des Vaults dienen soll, zum Beispiel eine Mindmap oder ein Flowchart der Konzepte miteinander verbindet die alle als eigene Notizen existieren.
Zwei Einschränkungen sind zu beachten: Notizen mit Sonderzeichen im Namen müssen in doppelte Anführungszeichen gesetzt werden, also class "⨳ Sonderzeichen" internal-link. Und interne Links aus Diagrammen tauchen nicht in der Graph View auf.
Fazit
Dieser Artikel kratzt an der Oberfläche dessen was Mermaid kann. Die gezeigten Diagrammtypen und Konfigurationsmöglichkeiten sind ein Einstieg, kein vollständiges Handbuch. Wer tiefer einsteigen möchte findet in der offiziellen Dokumentation unter https://mermaid.js.org/intro/ die vollständige Syntaxreferenz für alle Typen, inklusive weiterer Diagramme wie Sankey, Kanban, Paketdiagramme und Architekturdiagramme die hier nicht behandelt wurden.
Was Mermaid in Obsidian bringt
Der größte Vorteil ist die Nähe zum Text. Ein Diagramm lebt direkt in der Notiz, wird mit ihr versioniert, durchsucht und verlinkt. Es gibt keine externe Datei, kein separates Tool, keinen Export der irgendwann nicht mehr zur Notiz passt. Wenn du deinen Vault konsequent pflegst, kannst du Zusammenhänge die sich schlecht in Prosa fassen lassen als Diagramm direkt dort ablegen wo der Gedanke entstanden ist.
Dazu kommt die niedrige Einstiegshürde. Ein einfacher Flowchart oder eine Timeline ist in wenigen Zeilen geschrieben und sofort gerendert. Du brauchst keine Designkenntnisse und kein Gespür für Layout, Mermaid übernimmt die Positionierung automatisch.
Wo Mermaid an seine Grenzen stößt
Mermaid ist ein Darstellungswerkzeug, kein Denkwerkzeug. Wenn du noch mitten im Strukturieren bist, wirst du die fehlende Interaktivität vermissen. Knoten lassen sich nicht per Drag and Drop verschieben, Strukturen nicht spontan umbauen. Für echtes Brainstorming oder iteratives Diagrammzeichnen sind spezialisierte Tools wie Excalidraw, das übrigens auch als Obsidian-Plugin verfügbar ist, die bessere Wahl.
Die Syntax ist außerdem pro Diagrammtyp unterschiedlich und muss separat gelernt werden. Wenn du selten Diagramme zeichnest, wirst du jedes Mal nachschlagen. Und komplexe Diagramme mit vielen Knoten können in Obsidian langsam rendern und sind im Code schwer zu lesen und zu warten.
Umlaute und Sonderzeichen sind in manchen Diagrammtypen problematisch, wie der Quadrant Chart gezeigt hat. Wenn du auf Deutsch schreibst musst du damit rechnen gelegentlich auf Workarounds zurückgreifen zu müssen.
Warum es sich trotzdem lohnt
Die Fähigkeit Zusammenhänge schnell und ohne Medienbruch zu visualisieren ist für einen gut gepflegten Vault mehr wert als es auf den ersten Blick scheint. Ein Zustandsdiagramm das den Lebenszyklus einer Notiz beschreibt, eine Timeline die ein Rechercheprojekt strukturiert, ein Sequenzdiagramm das einen Workflow dokumentiert: das sind keine Spielereien sondern echte Denkwerkzeuge die deinen Vault über reine Textsammlungen hinaus heben.
Du musst nicht alle Diagrammtypen kennen und einsetzen. Wenn du dir einen oder zwei Typen aneignest die zu deiner Arbeitsweise passen, hast du bereits gewonnen. Der Rest wartet im Hinterkopf bis ein Problem auftaucht das sich besser zeichnen als schreiben lässt.
Weiterführende Quellen
Ein wichtiger Hinweis vorab: die folgende Dokumentation bezieht sich auf Mermaid als JavaScript-Bibliothek, nicht auf die Obsidian-Integration. Das bedeutet zweierlei. Erstens ist nicht jede Funktion die die Dokumentation beschreibt auch in Obsidian verfügbar, da Obsidian immer eine bestimmte Mermaid-Version mitbringt und neue Features erst mit einem Obsidian-Update ankommen. Zweitens beziehen sich viele Konfigurationsoptionen auf die direkte Einbindung von Mermaid in eigene Webseiten per JavaScript, also Dinge wie initialize() oder securityLevel die in Obsidian bereits intern verwaltet werden und für dich als Nutzer nicht relevant sind. Was du in Obsidian steuern kannst ist der Frontmatter-Block, classDef, style und linkStyle, alles andere ist in der Regel gekapselt.
https://mermaid.js.org/intro/ ist der Einstieg in die offizielle Dokumentation mit der vollständigen Syntaxreferenz aller Diagrammtypen.
https://mermaid.js.org/config/theming.html dokumentiert alle verfügbaren themeVariables für eigene Farbdefinitionen.
https://mermaid.live ist der offizielle Live Editor, ideal um Diagramme auszuprobieren bevor du sie in Obsidian überträgst.
https://mermaid.js.org/config/schema-docs/config.html listet alle Konfigurationsoptionen des Frontmatter-Blocks vollständig auf.
https://obsidian.md/help/advanced-syntax#Diagram ist die offizielle Obsidian-Dokumentation zu Mermaid, überschaubar und auf das Wesentliche reduziert. Sie beschreibt genau das was Obsidian direkt unterstützt, also ohne den Overhead der vollständigen Mermaid-Dokumentation, und ist damit der bessere Einstieg wenn du wissen möchtest was in Obsidian garantiert funktioniert.