Ein figlet-Banner am Anfang einer README ist wie ein Logo: gut gemacht, hebt es das Projekt sofort hervor. Schlecht gemacht, wirkt es wie ein Hobby-Projekt aus 2003. Die Trennlinie ist erstaunlich schmal.
Wann lohnt sich ein ASCII-Banner?
Drei Fälle, in denen ich es für richtig halte:
- Bei CLI-Tools. Wenn das Tool ohnehin per Terminal benutzt wird, passt ein ASCII-Banner direkt in die Markenidentitaet. Beispiel: kubectl, neofetch, lazygit haben alle ASCII-Komponenten.
- Bei Open-Source-Showcase-Projekten. Wenn das Repo primär beworben werden soll (also viele Sterne und Forks holen), zieht ein gut gemachtes Banner Klicks.
- Bei sehr trockenen Themen. Ein figlet-Banner kann ein Compliance-Tool oder eine Datenbank-Migration wenigstens optisch aufpeppen.
Drei Fälle, in denen es eher schadet:
- Im README eines internen Firmen-Repos. Hier ist es Zeit-Verschwendung, ein gut bezeichneter Titel reicht.
- Bei einem Library-README, wo Entwickler in zwei Sekunden die Install-Anweisung suchen. Das Banner verzögert den Lese-Fluss.
- Bei Repos, die nicht beworben werden müssen (z.B. private Hilfsskripte).
Schrift-Wahl im README
GitHub rendert README in einer Proportional-Schrift, ASCII Art muss in einen Code-Block. Im Code-Block nutzt GitHub die Schrift SF Mono auf Mac, Cascadia Code auf Windows, Liberation Mono auf Linux. Alle drei sind eng gesetzt, weshalb breitere figlet-Schriften gut wirken.
Empfehlungen:
- Slant: kursiv, lesbar, professionell. Default-Wahl für Projekt-Titel.
- Standard: überall lesbar, neutral.
- Big: nur für sehr kurze Worte (max 5-6 Buchstaben), sonst sprengt es die Breite.
- Vermeide Graffiti und 3D ASCII in seriosen Repos, sieht zu hobby aus.
Banner-Syntax in README.md
Code-Block mit drei Backticks, optional die Sprach-Markierung text:
```text
____ _
/ ___|_ __ ___ __ _| |_
| | _| '__/ _ \/ _` | __|
| |_| | | | __/ (_| | |_
\____|_| \___|\__,_|\__|
```
Wichtig: KEIN HTML-Center-Tag (<center>) verwenden, das deprecierte GitHub seit Jahren stillschweigend. Wer das Banner zentrieren will, nutzt ein <div align="center">.
Zusammenspiel mit Shields/Badges
Banner direkt über den Shields wirken am besten. Reihenfolge im README:
- ASCII-Banner mit Projektname
- Tagline / Untertitel (eine Zeile)
- Shields (Build-Status, npm-Version, License)
- Eine knappe Einleitung (zwei Sätze)
- Inhaltsverzeichnis oder Install-Befehl
Live-Beispiele aus der Wildbahn
Wer Vorbilder sucht, schaue sich diese Repos an:
- junegunn/fzf: minimales Standard-Banner.
- jesseduffield/lazygit: GIF statt Banner, aber sehr durchdacht.
- charmbracelet/gum: gar kein Banner, dafür ein interaktives Beispiel-GIF.
Erkenntnis: nicht jedes erfolgreiche CLI-Tool braucht ein ASCII-Banner. Lieber ein gutes Demo-GIF als ein mittelmäßiges Banner.
Wartbarkeit
Wenn dein Projektname später umbenannt wird, musst du das Banner neu generieren und einchecken. Es lohnt, im Repo eine Datei banner.txt abzulegen mit dem rohen Banner, dann sieht jeder neue Maintainer wo es herkam. Optional: ein Shell-Skript scripts/regen-banner.sh mit dem figlet-Befehl, mit dem das Banner ursprunglich erzeugt wurde.