Ein Dashboard, das sich anpasst: Raster, Widgets und Sichtbarkeiten

Ein Dashboard mit mehreren Kacheln Foto: Negative Space · StockSnap (CC0 1.0), via Openverse

Ein Dashboard ist eine merkwürdige Sache. Es soll auf den ersten Blick genau das zeigen, was gerade wichtig ist — nur ist "wichtig" für jede Person etwas anderes. Die Trainerin im Studio will die Belegung des Tages sehen, die Praxis interessiert sich für offene Termine, und wer eine ganze Organisation führt, blickt auf Umsatz und Mitgliederzahlen. Ein einziges, festgezurrtes Layout kann diese Ansprüche nicht gleichzeitig erfüllen, ohne für alle ein bisschen falsch zu sein.

Diese Woche geht es darum, wie wir das Dashboard von Xircuit gebaut haben, damit es sich an die Person anpasst statt umgekehrt — und welche überraschend kniffligen Entscheidungen hinter einem scheinbar simplen Raster aus Kacheln stecken.

Warum ein starres Layout nicht reicht

Der einfachste Weg wäre gewesen, eine feste Anordnung zu entwerfen, sie hübsch zu machen und damit fertig zu sein. Genau das haben wir am Anfang auch getan. Es funktionierte, solange man selbst der einzige Nutzer war. Sobald aber die ersten echten Organisationen dazukamen, wurde klar: Was für ein Fitnessstudio oben stehen muss, ist für eine Physiotherapie Beiwerk — und andersherum.

Wir wollten deshalb kein Dashboard, das wir vorgeben, sondern eines, das man sich selbst zusammenstellt. Die Leitidee war ein Raster, in dem jede Kachel ein eigenständiges Widget ist, das sich frei bewegen und in der Größe verändern lässt. Nicht als Spielerei, sondern weil die Reihenfolge und Größe einer Information selbst schon Bedeutung trägt: Was groß und oben liegt, wird zuerst gelesen.

Das Raster: Gridstack und 16 Widgets

Für das Raster setzen wir auf Gridstack, eine bewährte Bibliothek für Drag-and-drop-Layouts. Sie kümmert sich um das, was man leicht unterschätzt — das saubere Einrasten der Kacheln, das Verschieben benachbarter Elemente, das Zusammenspiel mit unterschiedlichen Bildschirmbreiten. Wir binden sie über einen schmalen JavaScript-Interop-Layer in unsere Blazor-Hybrid-Oberfläche ein, sodass die eigentliche Logik und der Zustand in .NET bleiben und nur die Gestensteuerung im Browser passiert.

Auf diesem Raster liegen aktuell 16 Widgets. Jedes davon ist in sich abgeschlossen: Es weiß, welche Daten es braucht, wie es sie darstellt und wie groß es sinnvollerweise sein möchte. Man greift eine Kachel, zieht sie an eine neue Stelle, packt sie an der Ecke und macht sie breiter — und das Raster ordnet den Rest darum herum neu an. Was zunächst nach reiner Kosmetik aussieht, ist in Wahrheit der Kern der Personalisierung: Die Anordnung ist die Konfiguration.

Drei Scopes: Gerät, Mitglied, Organisation

Sobald man Anordnungen speichert, stellt sich sofort die Frage: Für wen eigentlich? Ein Layout, das ich am großen Monitor im Büro einrichte, ist auf dem Tablet an der Rezeption unbrauchbar. Und was für mich persönlich gilt, muss nicht für die ganze Organisation gelten.

Deshalb wird die Anordnung pro Gerät gespeichert. Wer sich am Desktop ein breites, dichtes Layout baut, findet auf dem Tablet weiterhin eine passende, kompaktere Variante vor. Darüber hinaus kennt das System drei Scopes, die sich überlagern:

Mitglied — die persönliche Ansicht, die nur mich betrifft.
Organisation — ein geteiltes Layout, das für alle in einer Organisation als Ausgangspunkt dient.
Plattform — eine übergreifende Voreinstellung, die greift, bevor irgendjemand etwas angepasst hat.

Diese Staffelung sorgt dafür, dass niemand vor einem leeren Bildschirm sitzt. Es gibt immer eine sinnvolle Vorgabe, und jede Ebene darf sie für sich verfeinern, ohne die darunterliegende zu zerstören.

Ein Raster aus Kacheln Foto: Rawpixel (CC0 1.0), via Openverse

Die Position und Größe einer Kachel sind das eine — was sie inhaltlich zeigt, das andere. Ein Widget, das eine Kennzahl darstellt, soll vielleicht einen anderen Zeitraum oder eine andere Einheit anzeigen, ohne dass wir dafür jedes Mal ein neues Widget bauen.

Dafür trägt jedes Widget ein kleines Zahnrad. Ein Klick darauf öffnet einen Dialog, dessen Felder nicht fest verdrahtet sind, sondern aus dem Katalog stammen: Jedes Widget deklariert dort, welche Einstellungen es überhaupt kennt. Der Dialog baut sich aus dieser Deklaration auf, und was die Nutzerin einstellt, landet als JSON direkt am Widget. So bleibt die Konfiguration erweiterbar — kommt ein neues Widget mit neuen Optionen hinzu, muss ich am Dialog selbst nichts ändern; er liest einfach die Deklaration und zeigt die passenden Felder.

Dieser katalogbasierte Ansatz hat sich als eine der besseren Entscheidungen erwiesen. Er trennt sauber, was ein Widget kann, von der Frage, wie man es einstellt, und hält die Oberfläche generisch statt für jedes Widget handgeschrieben.

Trend-Widgets und der Zeitbereich

Ein konkretes Beispiel, an dem sich die Konfiguration bewährt hat, sind die Trend-Widgets. Sie zeigen den Verlauf einer Kennzahl über die Zeit — und dabei ist die entscheidende Frage natürlich: über welche Zeit? Die letzten sieben Tage erzählen eine andere Geschichte als das laufende Quartal.

Also haben wir den Trend-Widgets einen konfigurierbaren Zeitbereich gegeben. Über denselben Zahnrad-Dialog wählt man den Zeitraum, und das Widget zeichnet seine Kurve entsprechend neu. Interessant ist der Weg dorthin: Die Funktion lief zunächst hinter einem Flag, damit wir sie im echten Betrieb ausprobieren konnten, ohne sie schon jedem aufzudrängen. Erst als klar war, dass sie stabil ist und sich richtig anfühlt, haben wir das Flag entfernt und den Zeitbereich fest verankert. Dieses schrittweise Vorgehen — erst hinter einem Flag, dann fest — ist bei uns eher die Regel als die Ausnahme, gerade bei Dingen, die den täglichen Blick der Nutzer verändern.

Der Blick über alle Organisationen

Wer mehrere Organisationen betreut, braucht mehr als die Summe einzelner Dashboards. Dafür gibt es ein eigenes Alle-Organisationen-Dashboard, das die Kennzahlen nicht getrennt nebeneinanderstellt, sondern über alle Organisationen hinweg aggregiert. Statt zwischen Ansichten hin- und herzuspringen, sieht man das Gesamtbild in einem Aufwasch.

Weil hier naturgemäß sensiblere, zusammengeführte Zahlen sichtbar werden, hängt an diesem Dashboard ein eigener Zugriffsschutz. Nicht jeder, der eine einzelne Organisation sehen darf, darf auch den aggregierten Überblick sehen — diese Grenze ziehen wir bewusst und getrennt von den normalen Rollen. Datensparsamkeit und klare Berechtigungen sind bei einer Plattform, die mit Gesundheits- und Mitgliederdaten arbeitet, keine Kür, sondern Pflicht.