Ein dunkler Bildschirm mit Amber-Akzent

Lange Zeit sah Pixelklicker aus wie das, was es war: ein funktionales Baseline-Theme. Dunkel, ein Amber-Akzent, sonst nichts. Das war kein Versehen, sondern Absicht. Ich wollte Struktur und Styling konsequent getrennt halten – erst soll die Mechanik stehen, dann kümmert man sich um das Aussehen. Das Design war bewusst aufgeschoben.

Irgendwann kam aber der Punkt, an dem das Projekt eine eigene Identität brauchte. Nicht „noch ein sauberes, dunkles Dev-Blog-Theme", sondern etwas mit Wiedererkennungswert. Etwas, das den Namen „Pixelklicker" aufgreift, statt ihn nur oben in die Navigation zu schreiben. Als Inspiration hatte ich freek.dev im Kopf – nur gern eine Spur verspielter.

Die eigentliche Frage: hübsch oder bedeutungsvoll?

Hier lag die Spannung. Ich hätte einfach einen generischen „cleanen" Look bauen können. Eine Signaturfarbe wählen, ein bisschen Whitespace, fertig. Das wäre schnell gegangen und hätte ordentlich ausgesehen – aber eben auch austauschbar.

Die Alternative war ein Konzept mit Bedeutung: ein Motiv, das den Namen tatsächlich erklärt. Genau an diesem Punkt entscheidet sich, ob ein Theme nur hübsch oder eigenständig ist. Und mir war klar: Ein einzelner Akzentton macht noch keine Marke.

Drei Quadrate, die alles erklären

Der Durchbruch war eine fast banale Erinnerung daran, wie ein Bildschirm überhaupt funktioniert: Ein Pixel besteht aus drei Subpixeln – einem roten, einem grünen und einem blauen. Das wurde die Marke.

Daraus entstand ein kleines Drei-Quadrat-Logo in RGB, das sich überall im Theme wiederholt. Es ist eigenständig, und es erklärt den Namen visuell, ohne dass man ein Wort dazu schreiben muss. Drumherum kam das „Klicker"-Motiv: ein anklickbares Pixel-Raster, dazu ein leichter C64/Amiga-Vibe, der die ganze Sache erdet, ohne in Nostalgie-Kitsch zu kippen.

Wichtig war mir die Reihenfolge der Arbeit. Bevor irgendetwas ins System wanderte, habe ich erst statische HTML-Vorschauen gebaut und am Bild abgestimmt. Design-Entscheidungen trifft man besser an der fertigen Optik als mitten im Code, wo jede Diskussionsrunde teuer wird.

Sackgasse Nr. 1: Der coole Cursor, der nervte

Zum „Klicker"-Gedanken gehörte für mich zuerst ein custom Pixel-Mauszeiger. In der Vorschau sah das großartig aus – verspielt, thematisch passend, ein echter Hingucker.

Im Alltag war er schlicht störend. Ein Mauszeiger ist ein Werkzeug, das man hunderte Male pro Minute benutzt, und genau da darf eine Spielerei nicht im Weg stehen. Also flog er wieder raus.

Die verspielte Energie ist aber nicht verloren gegangen, sie ist nur umgezogen: in eine Hover-Animation des Logos. Wenn man darüberfährt, „blinken" die drei Subpixel in einer Welle. Spielerei dort, wo sie niemanden nervt – das war das Learning aus diesem Irrweg.

Sackgasse Nr. 2: Der Dark-Mode mit Gedächtnislücke

Der gemeinere Stolperstein war der Light/Dark-Umschalter. Ein simpler Sonne/Mond-Toggle, der die gewählte Variante in localStorage ablegt. Funktionierte – bis man navigierte oder neu lud. Dann sprang das Theme zurück.

Das war eines dieser Bugs, die sich erst falsch anfühlen, bis man versteht, was passiert. Der Toggle setzte den localStorage-Wert korrekt. Das Problem lag woanders: Livewires wire:navigate arbeitet SPA-artig und ersetzt beim Navigieren den <html>-Tag durch die frische Server-Version – inklusive class="...dark" aus dem Server-Default. Das Kopf-Script, das die gespeicherte Präferenz anwendet, lief dabei aber nicht erneut. Es feuerte nur beim ersten Parsen der Seite.

Die Lösung war, das Theme nicht nur einmal beim initialen Load anzuwenden, sondern auch bei jedem livewire:navigated-Event (und sicherheitshalber bei DOMContentLoaded):

js
function applyTheme() {
    const theme = localStorage.getItem('theme');
    document.documentElement.classList.toggle('dark', theme === 'dark');
}

// Erster Load
document.addEventListener('DOMContentLoaded', applyTheme);

// Nach jeder Livewire-Navigation, weil <html> ersetzt wurde
document.addEventListener('livewire:navigated', applyTheme);

Seitdem bleibt die Wahl, wo sie hingehört: beim Nutzer.

Was jetzt funktioniert

Am Ende steht ein eigenständiges „Pixelklicker"-Theme:

  • Light/Dark mit persistentem Sonne/Mond-Toggle, der auch nach Reload und Navigation hält.
  • Die RGB-Subpixel-Marke als wiederkehrendes Drei-Quadrat-Logo mit der Wellen-Hover-Animation.
  • Pixel-Details und ein leichter C64/Amiga-Vibe als roter Faden.
  • Ein blogmäßiges Devlog und eine Artikelseite mit Inhaltsverzeichnis.

Und das Beste: Die Optik bleibt sauber von der Struktur getrennt. Das Theme ist jederzeit umbaubar, ohne dass die Mechanik darunter wackelt – genau dafür hatte ich das Design am Anfang ja aufgeschoben.

Was ich mitnehme

  • Ein Konzept, das den Namen erklärt, ist stärker als „nur hübsch". Das RGB-Subpixel hätte ich nie über eine bloße Farbwahl bekommen.
  • wire:navigate ist SPA-artig. Alles, was vom DOM-Zustand abhängt – Theme-Klasse, Scrollspy, Init-Scripts – muss auf livewire:navigated reagieren, nicht nur auf den ersten Load. Sonst lebt man mit Bugs, die „manchmal" auftreten.
  • Vorschau zuerst. Statische HTML-Mockups vor dem Einbau ins System haben mir etliche Diskussionsrunden im Code erspart.
  • Spielerei nur dort, wo sie nicht stört. Der Pixel-Cursor war ein guter Reminder: Cool reicht nicht, es muss sich auch nach dem zehnten Klick noch gut anfühlen.