Nextcloud Breeze Light als wartungsarmes Theme richtig umsetzen

Ein Thema, das selten auf der Agenda steht

Wer eine Nextcloud betreibt, spricht meist über Speicher, Datenbanken, Backups, Verschlüsselung, vielleicht noch über Reverse Proxy und Fail2ban. Die Oberfläche dagegen, also das, was Nutzerinnen und Nutzer täglich acht Stunden lang anstarren, fristet ein Nischendasein. Das ist insofern bemerkenswert, als dass sich die Wahrnehmung einer Plattform zu einem erheblichen Teil über ihr Erscheinungsbild entscheidet. Ein Dateimanager, der alle zwei Jahre ein Facelift bekommt, ein Kalender, dessen Farbschema je nach Version kippt, eine Talk-Oberfläche, die im Corporate Design plötzlich als Fremdkörper wirkt: Das sind keine kosmetischen Probleme, sondern Reibungsverluste im Betrieb.

In dieser Ecke wird es interessant, wenn der Begriff Breeze fällt. Breeze ist die Designsprache der KDE-Community, seit Plasma 5 im Jahr 2014 den Vorgänger Oxygen ablöste. Es gibt Breeze als dunkle Variante, als helle Variante, als Icon-Set, als Fensterdekoration. Und es gibt, was viele nicht wissen, seit Jahren eine mehr oder weniger gepflegte Umsetzung für Nextcloud. Der vorliegende Beitrag beschäftigt sich mit der hellen Spielart, also mit dem, was man gemeinhin als Breeze Light bezeichnet – und mit der Frage, wie man so etwas auf einer produktiv genutzten Instanz sauber umsetzt, ohne sich bei jedem Major-Update das eigene Werk zu zerschießen.

Vorweg eine Einordnung, die wichtig ist und in Foren regelmäßig zu Missverständnissen führt: Ein offizielles, von Nextcloud GmbH gepflegtes Theme namens „Breeze Light“ existiert nicht. Was es gibt, ist eine von der Community getragene Dunkelvariante, dazu die Bordmittel der Theming-App, das Theme-Verzeichnis auf Dateisystemebene und die Möglichkeit, per eigener App Stylesheets nachzuladen. Breeze Light in einer Nextcloud ist deshalb in aller Regel ein Selbstbau – allerdings einer, der sich mit überschaubarem Aufwand realisieren lässt und dessen Ergebnis sich durchaus sehen lassen kann.

Woher Breeze kommt – und was davon übrig bleibt

Die Designsprache von KDE Plasma entstand nicht im luftleeren Raum. Sie war eine Reaktion auf die verspielte, glänzende Optik der späten 2000er und auf die Kritik, dass freie Desktop-Oberflächen zwar funktional, aber visuell beliebig seien. Breeze setzt seitdem auf flächige Darstellung, klare Kanten, dünne Trennlinien und eine zurückhaltende Farbpalette mit einem markanten Blau als Akzent. Verläufe und Schlagschatten kommen sparsam vor, Radien bleiben klein, die Typografie orientiert sich an Noto Sans. Wer die Breeze-Werte nachschaut, findet ein Farbschema, das vergleichsweise nüchtern daherkommt:

• Fensterfläche (Window): #eff0f1 – ein warmes, ganz leicht gräuliches Weiß
• Eingabeflächen und Listen (View, Button): #ffffff beziehungsweise #fcfcfc
• Text (Window Text, View Text): #232629
• Akzent (Highlight): #3daee9
• Text auf Akzent (Highlighted Text): #ffffff
• Verlinkungen: #2980b9

Das ist, wohlgemerkt, der Stand des klassischen Breeze-Light-Farbschemas. KDE hat über die Jahre nachjustiert, es gibt Varianten mit anderen Blautönen und in Plasma 6 eine überarbeitete Palette. Für eine Webanwendung ist das insofern unerheblich, als dass man ohnehin nicht eins zu eins übernehmen kann. Was sich übertragen lässt, ist die Haltung: viel Weißraum, wenig Effekthascherei, ein einziger kräftiger Akzent, ansonsten Zurückhaltung. Was sich nicht übertragen lässt, sind Fensterdekorationen, native Widgets, Qt-spezifische Animationen oder das Verhalten von Kontextmenüs. Ein Nextcloud-Theme ist am Ende ein Stylesheet gegen ein DOM, nicht ein Desktop-Theme gegen eine Widget-Bibliothek.

Der Vergleich mit anderen Designsprachen lohnt trotzdem. GNOME setzt mit Adwaita auf runde Ecken und großzügige Abstände, Material Design auf Elevation und Schatten, Apples Human Interface Guidelines auf Tiefe und Unschärfe. Breeze ist in dieser Runde das nüchternste Angebot, und genau das macht es für Arbeitswerkzeuge attraktiv. Eine Dateiliste mit 400 Einträgen profitiert davon, dass die Zeilen nicht durch abwechselnde Hintergründe und schwebende Karten zerrissen werden.

Wie Theming in Nextcloud technisch funktioniert

Bevor man Farbwerte hin und her schiebt, sollte man verstehen, an welchen Stellen Nextcloud überhaupt beeinflussbar ist. Man kann grob drei Ebenen unterscheiden, die unterschiedlich weit reichen und unterschiedlich gut dokumentiert sind.

Ebene eins: die Theming-App

Die Theming-App ist Teil des Serverkerns und über die Administrationsoberfläche unter „Design“ erreichbar. Sie steuert das Logo, den Produktnamen, den Slogan, das Hintergrundbild der Anmeldeseite, die Primärfarbe, dazu Impressums- und Datenschutz-Link. Die dort gesetzten Werte landen nicht als statische Datei auf der Platte, sondern werden dynamisch ausgeliefert: Nextcloud generiert daraus Stylesheets unterhalb von /apps/theming/theme/<name>.css – die gängigen Varianten heißen default.css, light.css und dark.css. Wer neugierig ist, kann diese Datei im Browser aufrufen und sieht dann sehr schön, welche CSS-Variablen aus der Primärfarbe abgeleitet werden.

Dasselbe lässt sich per Kommandozeile erledigen, was für automatisierte Deployments der deutlich vernünftigere Weg ist. Der Befehl heißt occ theming:config und nimmt Schlüssel-Wert-Paare entgegen, etwa occ theming:config color "#3daee9" oder occ theming:config name "Meine Cloud". Je nach Version und Schlüssel funktioniert das mit Hex-Werten, Dateipfaden oder Klartext. Ein Blick in die Hilfe (occ theming:config --help) erspart hier viel Herumprobieren, weil sich die akzeptierten Schlüssel zwischen Major-Versionen durchaus unterscheiden.

Ebene zwei: die Nutzereinstellungen

Parallel dazu hat jeder Account unter „Darstellung und Barrierefreiheit“ die Wahl zwischen Hell, Dunkel und der Systemeinstellung. Diese Wahl wird pro Nutzer gespeichert und über Stimmt mit den Einstellungen des Betriebssystems überein – realisiert über prefers-color-scheme. Hinzu kommt die Accessibility-App, die unter anderem einen kontrastreichen Modus und größere Schrift anbietet.

Das ist der Punkt, an dem viele selbstgebaute Themes scheitern. Man baut eine wunderschöne helle Oberfläche, übersieht aber, dass ein Teil der Belegschaft den Rechner abends auf Dunkelmodus stellt. Ist die Nutzerwahl nicht gesperrt, bekommen diese Leute dann eine halbherzig mitgezogene oder gar keine Dunkelvariante zu sehen – und das Ergebnis ist schlechter als der unveränderte Standard. Die Administrationsoberfläche bietet deshalb die Option, die Nutzerwahl zu unterbinden. Technisch nachvollziehbar, ergonomisch fragwürdig. Dazu später mehr.

Ebene drei: Dateisystem und Apps

Die dritte Ebene ist die mächtigste und die wartungsintensivste. Nextcloud unterstützt ein Verzeichnis themes/ im Installationsordner, in dem sich eigene Themes ablegen lassen. Klassischerweise besteht so ein Theme aus einer defaults.php, in der Standardwerte für Name, Slogan, Farbe und URL hinterlegt sind, plus – je nach Version und Anspruch – eigenen CSS- oder SCSS-Dateien, die Core-Stylesheets überschreiben. Das ist der Weg, den man geht, wenn Branding zentral und unabhängig von der Datenbank ausgerollt werden soll.

Die zweite Spielart ist eine eigene App, die sich in den Rendering-Prozess einklinkt. Genau so funktioniert die erwähnte Breeze-Dark-Umsetzung: Die App registriert sich für das Ereignis, das vor dem Rendern der Seite ausgelöst wird, und lädt dort per Util::addStyle() ein eigenes Stylesheet nach. Der Vorteil liegt auf der Hand – die App lässt sich aktivieren, deaktivieren, versionieren und verteilen wie jede andere Erweiterung. Der Nachteil ebenfalls: Man muss sie pflegen, und man muss damit leben, dass Nextcloud intern mit jeder Major-Version an der CSS-Struktur schraubt.

Wichtig für das Verständnis: Nextcloud kompiliert seine Stylesheets serverseitig aus SCSS. Die Variablen, die dabei zusammenlaufen, sind im Kern in core/css/variables.scss definiert und werden zur Laufzeit als CSS Custom Properties ins Dokument geschrieben. Genau diese Custom Properties sind der Hebel, an dem ein Breeze-Light-Theme ansetzt. Es sind eine ganze Menge, aber die wichtigsten kennt man schnell:

• --color-primary, --color-primary-text, --color-primary-element sowie die zugehörigen Hover- und Light-Varianten
• --color-main-background und --color-main-background-rgb
• --color-main-text, --color-text-maxcontrast, --color-text-light, --color-text-lighter
• --color-border, --color-border-dark, --color-border-maxcontrast
• --color-background-dark, --color-background-darker, --color-background-plain
• --border-radius, --border-radius-large, --border-radius-pill
• --color-box-shadow, --color-scrollbar, --background-invert-if-dark

Wer diese Liste einmal in den Entwicklerwerkzeugen des Browsers durchgeht, versteht binnen zehn Minuten, warum ein Nextcloud-Theme nie mit drei Farbwerten getan ist. Und warum ein Theme, das nur die Primärfarbe setzt, in der halben Oberfläche nichts bewirkt.

Breeze Light konkret: Farben, Flächen, Kanten

Die Übertragung der Breeze-Light-Palette auf Nextcloud ist im Kern eine Übersetzungsarbeit. Die Fensterfläche #eff0f1 wird zur Hauptfläche, die Eingabeflächen werden weiß, der Text bekommt #232629, Trennlinien ein freundliches Grau um #d6d9dc. Radien bleiben klein – vier Pixel sind ein guter Ausgangswert, acht sind schon zu viel für den Breeze-Charakter. Schatten werden auf ein Minimum reduziert: ein Hauch von 0 1px 2px rgba(0,0,0,0.06) dort, wo eine Ebene wirklich schweben muss, etwa bei Dropdown-Menüs.

Ein realistischer Auszug für ein Custom-CSS oder ein Theme-Stylesheet könnte so aussehen:

:root {
  --color-primary: #0f6b9c;
  --color-primary-text: #ffffff;
  --color-primary-element: #3daee9;
  --color-primary-element-light: #d3ebf9;
  --color-main-background: #eff0f1;
  --color-main-background-rgb: 239, 240, 241;
  --color-main-text: #232629;
  --color-text-maxcontrast: #4c545b;
  --color-border: #d6d9dc;
  --color-border-dark: #b3b9bf;
  --border-radius: 4px;
}

body {
  color-scheme: light;
}

An dieser Stelle kommt ein Detail ins Spiel, das in vielen Anleitungen fehlt und regelmäßig für Frust sorgt: --color-main-background-rgb. Nextcloud verwendet diesen Wert, um halbtransparente Flächen zu erzeugen, etwa beim Sticky-Header, bei Overlays oder beim Hintergrund von Dialogfenstern. Ändert man --color-main-background, aber nicht das RGB-Tripel, entstehen an diesen Stellen Farbstiche, die man zunächst für einen Rendering-Fehler hält. Also: immer beide Werte pflegen.

Der zweite Klassiker ist der Primärton. #3daee9 ist hübsch, aber als Hintergrund für weiße Schrift ein Problem. Das Kontrastverhältnis liegt rechnerisch bei etwa 2,5 zu 1 und damit deutlich unter den 4,5 zu 1, die die WCAG für normalen Text fordert. Man hat nun zwei Möglichkeiten. Entweder man dunkelt den Ton ab – Werte um #0f6b9c bis #1b7fb4 funktionieren mit weißer Schrift deutlich besser. Oder man bleibt beim hellen Blau und setzt dunkle Beschriftung darauf, was optisch an moderne Buttons erinnert, aber nur funktioniert, wenn man es konsequent durchhält. Beides ist vertretbar, das Mischen beider Ansätze in derselben Oberfläche ist es nicht.

Ein weiterer Punkt, der gern unterschätzt wird: --color-text-light und --color-text-lighter sind im Nextcloud-Standard bereits grenzwertig kontrastarm. Sie werden für Zeitstempel, Dateigrößen, sekundäre Beschriftungen und Platzhaltertexte verwendet. Wer sie im Rahmen eines hellen Themes noch weiter aufhellt, um „luftiger“ zu wirken, produziert unlesbare Metadaten. Hier lohnt es sich, gegen den Impuls zu arbeiten und die Grautöne eher dunkler zu halten als im Original.

Der Anmeldebildschirm als Sonderfall

Die Login-Seite gehorcht eigenen Regeln. Sie zieht sich einen Hintergrund aus dem Theming, legt bei Bedarf einen Weichzeichner darüber und setzt das Anmeldefenster darauf ab. Wer dort ein helles Hintergrundbild mit heller Schrift kombiniert, produziert eine Seite, die nur bei gutem Willen lesbar ist. Ein Breeze-Light-Theme tut gut daran, die Anmeldeseite entweder mit einer ruhigen, entsättigten Grafik oder gleich mit der einfachen Fensterfarbe zu betreiben. Das wirkt nüchterner, ist aber reproduzierbar und in jedem Browser gleich.

Drei Wege zur Umsetzung – mit unterschiedlichen Konsequenzen

Variante A: Theming-App plus Custom CSS

Der schnellste Weg. Man setzt in der Administrationsoberfläche Primärfarbe, Name und Logo, und schreibt alles Weitere in das Feld für eigenes CSS, das die Theming-App mitbringt. Dieses CSS wird als App-Konfiguration gespeichert und lässt sich auch per Kommandozeile setzen:

occ config:app:set theming_customcss customcss --value=":root { --color-main-background: #eff0f1; }"

Vorteile: kein Dateizugriff nötig, überlebt Updates, in fünf Minuten erledigt. Nachteile: Die Länge des Feldes ist begrenzt, man kann keine Variablen vorberechnen, und man kämpft gelegentlich mit Spezifitäten, weil die eigenen Regeln gegen die kompilierten Core-Stylesheets anlaufen. Für ein dezentes Branding reicht es fast immer, für ein vollständig durchentwickeltes Theme eher nicht.

Variante B: Eigenes Theme im themes/-Verzeichnis

Der traditionelle Weg. Man legt unterhalb des Installationsverzeichnisses einen Ordner themes/breezelight/ an und befüllt ihn mit einer defaults.php sowie – je nach Version und Zielsetzung – eigenen Stylesheets. Der große Vorteil: Das Verzeichnis liegt außerhalb des Cores, wird bei Updates nicht angefasst und kann in ein eigenes Git-Repository wandern. Der große Nachteil: Man muss selbst dafür sorgen, dass die eigenen Überschreibungen nach einem Major-Upgrade noch greifen. In einer Testinstanz lässt sich das gut nachvollziehen – man installiert die neue Version, ruft die wichtigsten Ansichten auf und sieht binnen Minuten, welche Selektoren ins Leere laufen.

Wie weit man mit dem Theme-Verzeichnis kommt, hängt an der Version und an der Bereitschaft, sich mit der SCSS-Struktur zu beschäftigen. Für Branding über defaults.php ist der Weg robust und offiziell vorgesehen. Für tiefe Eingriffe in die Oberfläche ist er es nur, solange man die Struktur des Cores im Blick behält.

Variante C: Eigene App als Theme-Träger

Der professionellste, aber auch aufwendigste Weg. Man baut eine kleine App, die sich in den Rendering-Prozess einklinkt und ein Stylesheet nachlädt. Vorbild ist die Breeze-Dark-Erweiterung, die genau so arbeitet. Vorteile: Das Theme lässt sich als App aktivieren und deaktivieren, versionieren, in einem internen Store verteilen und sauber vom Core trennen. Nachteile: Man betreibt ab diesem Moment Softwareentwicklung mit allem, was dazugehört – Kompatibilitätsprüfungen, Changelog, Release-Prozess, Verantwortlichkeiten. Für eine einzelne Instanz ist das überdimensioniert. Für einen Anbieter, der Nextcloud als White-Label an mehrere Kunden ausliefert, kann es genau richtig sein.

Testumgebung: erst spielen, dann ausrollen

Niemand sollte ein Theme direkt auf einer Instanz mit 2.000 aktiven Konten entwickeln. Eine Wegwerf-Umgebung ist mit Docker in wenigen Minuten aufgesetzt, und man kann sie nach Belieben zerschießen:

services:
  nextcloud:
    image: nextcloud:apache
    ports:
      - "8080:80"
    environment:
      - NEXTCLOUD_ADMIN_USER=admin
      - NEXTCLOUD_ADMIN_PASSWORD=bitte-aendern
    volumes:
      - ./html:/var/www/html
      - ./themes/breezelight:/var/www/html/themes/breezelight

Danach arbeitet man mit einem kurzen Alias und kann alle relevanten Einstellungen per Skript reproduzieren:

alias occ='docker compose exec -u www-data nextcloud php occ'

occ app:enable theming
occ theming:config color "#0f6b9c"
occ theming:config name "Breeze Light"
occ theming:config slogan "Dateien, Kalender, Gespräche"
occ maintenance:repair

Wichtig bei Änderungen an Stylesheets: Nextcloud kompiliert SCSS serverseitig und legt die Ergebnisse in einem Cache-Verzeichnis unterhalb des appdata-Ordners ab. Nach Anpassungen sollte man diesen Cache leeren beziehungsweise occ maintenance:repair laufen lassen und im Browser ohne Cache neu laden. Sonst diskutiert man über Farben, die längst geändert wurden – ein Klassiker, der schon so manche Mittagspause gefressen hat.

Die Stolperfallen, die wirklich wehtun

Ein Theme zu schreiben ist Handwerk. Ein Theme zu betreiben ist Betrieb. Die folgenden Punkte sind die, die erfahrungsgemäß am häufigsten übersehen werden.

Der Modus des Nutzers. Steht die Darstellung bei „System“, richtet sich Nextcloud nach prefers-color-scheme. Wer nur eine helle Variante baut und die Nutzerwahl nicht sperrt, überlässt das Erscheinungsbild dem Betriebssystem. Sperrt man die Nutzerwahl, nimmt man den Leuten eine Funktion weg, die manche aus gesundheitlichen Gründen brauchen. Der pragmatische Mittelweg: eine anständige helle Basis bauen und zusätzlich eine Dunkelvariante pflegen, die zumindest dieselben Flächenwerte und Radien verwendet. Zwei Stylesheets mit derselben Struktur sind leichter zu warten als ein halbherziges.

Logos und Invertierung. Nextcloud arbeitet mit den Variablen --background-invert-if-dark und --background-invert-if-bright, um Logos auf dunklen und hellen Flächen gleichermaßen sichtbar zu machen. Ein einfarbig weißes Logo funktioniert auf der hellen Fensterfläche nicht. Wer sein Theme also auf hell umstellt, braucht entweder ein dunkles Logo oder einen gesetzten Hintergrund für den Headerbereich, auf dem das Logo weiterhin lesbar ist.

App-eigene Farben. Kalender, Deck, Talk und Forms bringen eigene Farbdefinitionen mit, die sich nicht alle über die globalen Variablen steuern lassen. Talk etwa zeigt im Anruf eine eigene, dunkle Videooberfläche, die sich bewusst wenig um das globale Theme schert. Das ist kein Fehler, sondern Absicht. Wer ein konsistentes Bild will, muss diese Bereiche einzeln prüfen – und dann entscheiden, ob ein Eingriff überhaupt sinnvoll ist.

Externe Integrationen. Collabora und OnlyOffice werden in einem eigenen Frame geladen beziehungsweise in eine eigene Umgebung eingebettet. Sie übernehmen das Nextcloud-Theme nicht. Hier hilft nur, deren eigene Theming-Optionen zu nutzen, etwa per Konfigurationsdatei auf Seiten des Office-Servers. Das Ergebnis wird nie deckungsgleich sein, und das ist auch in Ordnung, solange die Grundstimmung nicht völlig aus dem Rahmen fällt.

E-Mails. Das Theming wirkt auch auf Einladungen, Passwort-Zurücksetzungen und Benachrichtigungen. Ein Logo, das auf einem hellen Hintergrund entworfen wurde, sieht in einem E-Mail-Client mit dunkler Vorschau anders aus als gedacht. Ein kurzer Test in drei verschiedenen Clients ist hier gut investierte Zeit.

Mobile Clients. Die Android- und iOS-Apps übernehmen das Theming nur in Teilen – in der Regel Logo und Primärfarbe auf dem Anmeldebildschirm. Danach folgt die App ihrer eigenen Darstellung. Wer denkt, er könne das Erscheinungsbild der mobilen Anwendung per Server-Theme steuern, wird enttäuscht.

Spezifität und !important. Nextcloud rendert große Teile der Oberfläche mit Vue-Komponenten, die ihre eigenen Styles mitbringen. Wer mit !important arbeitet, um sich durchzusetzen, gewinnt kurzfristig und verliert langfristig: Nach dem nächsten Frontend-Update steht eine Sammlung von Regeln im Stylesheet, von denen niemand mehr weiß, welche überhaupt noch greift. Besser ist es, über die Custom Properties zu arbeiten – die sind ausdrücklich als Schnittstelle gedacht.

Barrierefreiheit ist kein Anhängsel

Bei einem öffentlich zugänglichen Angebot ist Barrierefreiheit längst keine Kür mehr. In Deutschland verpflichtet das Barrierefreiheitsstärkungsgesetz seit Mitte 2025 bestimmte Produkte und Dienstleistungen zu entsprechenden Anforderungen, öffentliche Stellen orientieren sich ohnehin an BITV 2.0 und der EN 301 549. Für eine rein interne Nextcloud gelten diese Regeln zwar nicht automatisch, aber die Argumente sind dieselben: Wer lesen muss, um zu arbeiten, profitiert von ausreichendem Kontrast, klaren Fokuszuständen und ausreichenden Trefferflächen.

Konkret heißt das für ein Breeze-Light-Theme:

• Text auf Flächen sollte mindestens 4,5 zu 1 erreichen, große Überschriften mindestens 3 zu 1.
• Interaktive Elemente brauchen einen deutlich sichtbaren Fokusring. Nextcloud setzt hier auf :focus-visible; eigene Regeln dürfen das nicht überschreiben oder unsichtbar machen.
• Zustände dürfen nicht allein über Farbe transportiert werden. Rot gegen Grün ist für rund acht Prozent der Männer schlecht unterscheidbar – ein Icon oder eine Textmarke gehört dazu.
• Der Kontrastmodus der Accessibility-App darf nicht durch das eigene Theme ausgehebelt werden. Wer dessen Klassen überschreibt, sollte sie im Betriebssystem-Modus „Hoher Kontrast“ gegenprüfen.

Praktische Hilfsmittel sind die Kontrastprüfer in den Entwicklerwerkzeugen gängiger Browser, die Erweiterung axe DevTools, ein Durchlauf mit Lighthouse und nicht zuletzt ein Test mit aktivierter Tastaturnavigation. Wer fünf Minuten lang ausschließlich mit Tab, Eingabe und Escape durch die eigene Oberfläche navigiert, entdeckt dabei regelmäßig Dinge, die ihm vorher nie aufgefallen sind.

Betrieb, Updates und die Frage der Verantwortlichkeit

Ein Theme ist Software. Wer es selbst baut, sollte es wie Software behandeln: in Git, mit Versionsständen, mit einem Changelog und mit einer kurzen Notiz, welcher Stand zu welcher Nextcloud-Version gehört. Bei einem Major-Upgrade ist der Ablauf dann immer derselbe: Testinstanz aktualisieren, Theme darauf ausrollen, die wichtigsten Ansichten durchklicken, Screenshots vergleichen, erst dann produktiv. Automatisierte Screenshot-Vergleiche mit Werkzeugen wie Playwright oder BackstopJS klingen nach Kanonen auf Spatzen, sparen aber genau die Fehler, die man sonst erst von den Nutzern gemeldet bekommt.

Nicht zuletzt stellt sich die Zuständigkeitsfrage. Ein selbstgebautes Theme hat keinen Maintainer in der Community, der es bei Problemen nachzieht. Es hat denjenigen, der es gebaut hat. Ist diese Person irgendwann nicht mehr im Haus, wird aus einem hübschen Detail ein Wartungsproblem. Wer das vermeiden will, dokumentiert die Entscheidungen: warum welche Variable auf welchen Wert gesetzt wurde, welche Bereiche bewusst ausgespart sind, welche Version zuletzt geprüft wurde. Das klingt banal, ist aber der Unterschied zwischen einem Theme, das fünf Jahre lebt, und einem, das nach zwei Jahren stillschweigend verschwindet.

Ein interessanter Aspekt in diesem Zusammenhang: Viele Häuser bauen am Ende ein deutlich kleineres Theme als ursprünglich geplant. Nicht aus Bequemlichkeit, sondern aus Erfahrung. Die Primärfarbe, das Logo, eine Handvoll Flächen und Kanten – das deckt den Großteil des Wiedererkennungswerts ab und lässt sich über Jahre stabil halten. Wer dagegen jede Schaltfläche einzeln nachbaut, bezahlt das mit Wartungsaufwand bei jedem Release.

Wann sich Breeze Light lohnt – und wann nicht

Es gibt Konstellationen, in denen die helle Breeze-Variante fast zwangsläufig auf die Agenda kommt. In Häusern, die auf KDE Plasma arbeiten, ist der Wiedererkennungseffekt offensichtlich. Bildungseinrichtungen, die ihre Cloud an das Corporate Design einer Hochschule angleichen müssen, profitieren von der Zurückhaltung der Palette. Agenturen und Dienstleister, die Nextcloud als White-Label betreiben, brauchen ohnehin ein eigenes Erscheinungsbild – und finden in Breeze eine Vorlage, die nicht nach Baukasten aussieht.

Es gibt aber auch Konstellationen, in denen man es bleiben lassen sollte. Wer nur eine kleine Instanz für zwanzig Personen betreibt und keine Ressourcen für die Pflege hat, fährt mit der Standardoberfläche plus angepasster Primärfarbe besser. Und wer die Anforderungen der Barrierefreiheit erfüllen muss, sollte vor dem ersten CSS-Entwurf klären, wie viel Arbeit in Kontrastprüfung und Testläufe fließen kann – sonst produziert man ein hübsches Theme, das nach der Prüfung wieder zerlegt werden muss.

Fazit

Nextcloud Breeze Light ist keine Erweiterung, die man herunterlädt und aktiviert. Es ist eine Designentscheidung, die man trifft und dann umsetzt – schnell und oberflächlich über die Theming-App mit eigenem CSS, solide über ein Theme im themes/-Verzeichnis, oder als gepflegte Eigenentwicklung in Form einer kleinen App. Die Designsprache von Breeze eignet sich dafür gut, weil sie dem Arbeitscharakter einer Cloud-Oberfläche entgegenkommt: ruhige Flächen, ein Akzent, klare Kanten, keine Effekte, die beim zehnten Ansehen nerven.

Der Aufwand liegt weniger im ersten Entwurf als im Betrieb. Wer die Custom Properties von Nextcloud als Schnittstelle begreift statt als Hindernis, wer Kontraste ernst nimmt, wer Cache-Verhalten kennt und wer einen Update-Prozess etabliert, bekommt eine Oberfläche, die aussieht, als hätte sie schon immer so ausgesehen. Alle anderen bekommen nach dem nächsten Major-Update einen Ordner voller CSS, das niemand mehr anfassen möchte. Der Unterschied zwischen beiden Ergebnissen liegt selten im Talent – er liegt in der Entscheidung, das Thema als Infrastruktur zu behandeln und nicht als Kosmetik.