Views – danwos

Ein Pull Request, viele Blicke

Für einen Developer ist ein Pull Request vor allem Code und grüne Tests. Für mich hängt daran viel mehr: das Feature selbst, UI und UX, die Docs, die Marketing-Farben, Codequalität und Wartbarkeit, wie tief und wie gut die Tests wirklich sind, ob die Requirements eingehalten werden oder sich schon leise davon entfernen – und noch einiges mehr.

Das alles einfach und schnell erfassbar zu zeigen, ist eine Herausforderung. Für einen einzelnen Pull Request reichen Dashboards und Kommentare. Will ich aber Dutzende Pull Requests im ganzen Produkt im Blick behalten, wird es schwer. Dann bleiben Dashboards für einzelne Checks – aber nie alles auf einmal.

Die Nadel im Heuhaufen

Am Ende suche ich die Nadel im Heuhaufen. Und die sieht für jede Rolle anders aus:

Rolle	Die Nadel
Developer	der eine rote Test zwischen hundert grünen
Projektleitung	das Feature, das seit Tagen hängt
Test	die Änderung, die kaum getestet ist
Kunden	die Anforderung, die nicht umgesetzt wurde
Marketing	die falsche Farbe im neuen Screen
Legal	die neue Lizenz in den Abhängigkeiten
Controlling	der Aufwand, der aus dem Ruder läuft

Lesen ist langsam

Ich glaube, Wörter zu lesen ist eine der schlechteren Arten, eine Situation zu erfassen. Stehen bei hundert Pull Requests „ok“, „in progress“, „backlog“ und „cancelled“ in der Statusspalte, ist die eine Zeile mit „failure“ schwer zu finden. In Farbe oder als Icon springt sie sofort ins Auge.

Als Text

#1201 ok
#1202 in progress
#1203 ok
#1204 ok
#1205 backlog
#1206 ok
#1207 in progress
#1208 backlog
#1209 backlog
#1210 ok
#1211 in progress
#1212 cancelled
#1213 ok
#1214 in progress
#1215 ok
#1216 in progress
#1217 ok
#1218 cancelled
#1219 ok
#1220 backlog
#1221 ok
#1222 cancelled
#1223 ok
#1224 in progress
#1225 ok
#1226 in progress
#1227 ok
#1228 ok
#1229 ok
#1230 ok
#1231 in progress
#1232 cancelled
#1233 ok
#1234 in progress
#1235 backlog
#1236 ok
#1237 backlog
#1238 backlog
#1239 ok
#1240 in progress
#1241 ok
#1242 ok
#1243 ok
#1244 cancelled
#1245 ok
#1246 ok
#1247 ok
#1248 ok
#1249 in progress
#1250 ok
#1251 in progress
#1252 ok
#1253 ok
#1254 ok
#1255 ok
#1256 ok
#1257 ok
#1258 backlog
#1259 ok
#1260 cancelled
#1261 ok
#1262 ok
#1263 backlog
#1264 ok
#1265 ok
#1266 ok
#1267 cancelled
#1268 failure
#1269 ok
#1270 ok
#1271 ok
#1272 ok
#1273 ok
#1274 ok
#1275 in progress
#1276 in progress
#1277 ok
#1278 backlog
#1279 in progress
#1280 ok
#1281 ok
#1282 in progress
#1283 cancelled
#1284 backlog
#1285 ok
#1286 ok
#1287 in progress
#1288 ok
#1289 ok
#1290 ok
#1291 backlog
#1292 in progress
#1293 ok
#1294 ok
#1295 cancelled
#1296 ok
#1297 backlog
#1298 backlog
#1299 in progress
#1300 ok

Als Farbe

ok
in progress
backlog
cancelled
failure

Spüren statt lesen

Daraus ist mein Motiv entstanden: Probleme sollen sich intuitiv erfahren und erspüren lassen. Ich will nicht lesen müssen, um eine Situation zu erfassen.

Neben Text zählen deshalb vor allem visuelle Reize – Farben, Formen und Strukturen. Bei großen Datenmengen hilft auch Tiefe: ein Raum in 3D statt flachem Text in einer Tabelle. Töne könnten ebenfalls eine wichtige Rolle spielen. Im Büroalltag lassen sie sich aber nur schwer in die Workflows einbauen.

Muster, die jeder kennt

Für die Darstellung greife ich gern auf Ideen und Konzepte zurück, die es schon gibt, weil sie intuitiv verstanden werden. Fast jeder kann eine Straßenkarte lesen und ihre Strukturen und Farben deuten: breite Straßen, dichte Städte, leeres Land dazwischen. Überträgt man diese Darstellung auf andere Daten, bekommt man schnell einen Einblick in ein Thema.

Mit Horus habe ich das spielerisch an echten Sphinx-Needs-Daten ausprobiert. Die Needs stehen als leuchtende Stadt im Raum: jede Gruppe ein Turm, jeder Need ein Stockwerk, die Farbe zeigt den Status. Verstöße gegen das Schema leuchten rot – man sieht sie von weitem, ohne eine Zeile zu lesen.

Die Sphinx-Needs-Demo als Stadt: ein Turm pro Need-Typ, die Stockwerke leuchten in der Farbe ihres Status.

Ein ausgewählter Need mit Inhalt und Links, die als Bögen zu anderen Türmen laufen.

Video und Erklärungen, wie Horus funktioniert, findest du auf der Tool-Seite von Horus.

Was Science-Fiction schon wusste

Das danwos-Monster steht staunend in einem 3D-Gitter, um es herum schweben vernetzte Objekte

Ein starker Ideengeber sind für mich die Computer-Interfaces aus Science-Fiction-Filmen und -Serien. Sei es das farbige 2D-Layout der Konsolen in Star Trek oder die 3D-Netzwerke, in denen die Computerhirne der Androiden in „Ghost in the Shell“ denken.

Oft sind die Ideen ganz schön abwegig – und tauchen erstaunlich früh auf. Im Klassiker „Hackers“ von 1995 ragen Dateien als 3D-Türme auf, und ein Virus läuft als Krümelmonster über den Bildschirm.

Heute liefert AI Daten in Mengen, die Menschen prüfen, kontrollieren und freigeben müssen. Da muss jede Idee willkommen sein, egal wie sehr sie mit dem aktuellen Stand bricht.

Ein Pull Request zum Drehen

Wie das aussehen kann, zeigt ein kleiner Versuch: ein Pull Request als Rolle. Jede Scheibe ist ein Qualitätskriterium – Tests, Docs, Requirements, Legal und mehr. Jede Scheibe ist wieder in Tortenstücke geteilt, bei den Tests etwa in Unit, Integration und System. Die Farbe zeigt, wie gut es um jedes Stück steht.

Von außen siehst du auf einen Blick, ob irgendwo etwas rot leuchtet. Erst wenn du genauer hinschauen willst, ziehst du die Rolle auseinander und liest, was dahinter steckt.

gut ≥ 80
mittel 60–79
kritisch < 60

Ziehen dreht die Rolle, ein Klick auf die Rolle zieht sie auseinander. Fährst du über ein Stück, siehst du seinen Wert. Die Werte sind ein Beispiel.

Tests: Unit 92, Integration 81, System 64
Docs: API 88, Handbuch 72, Changelog 95
Requirements: Abdeckung 86, Drift 68, Traceability 91
Codequalität: Komplexität 82, Duplikate 90, Stil 97
Wartbarkeit: Kopplung 76, Abhängigkeiten 84
UI & UX: Barrierefreiheit 63, Konsistenz 85, Markenfarben 93
Security: Schwachstellen 89, Secrets 100, Statische Analyse 79
Legal: Lizenzen 34, Copyright-Hinweise 90

Dutzende Pull Requests auf einmal

Eine Rolle hilft bei einem Pull Request. Spannend wird es bei Dutzenden. Hier stehen 48 Pull Requests aus vier Schichten eines Produkts im Raum – App, Service, Bibliothek und Plattform –, verbunden dort, wo einer vom anderen abhängt. Die meisten sind grün. Wo es rot und orange wird, siehst du sofort, auch zwischen allen anderen. Ein Klick holt dir die Rolle heran.

gut ≥ 80
mittel 60–79
kritisch < 60

Ziehen dreht das Netz, ein Klick auf eine Rolle zeigt sie groß. Fährst du über eine Rolle, siehst du ihren niedrigsten Wert. Die Daten sind ein Beispiel.

PR #1401, App: niedrigster Wert Tests · Unit 78
PR #1402, App: niedrigster Wert Codequalität · Duplikate 77
PR #1403, App: niedrigster Wert Security · Schwachstellen 69
PR #1404, App: niedrigster Wert Tests · System 85
PR #1405, App: niedrigster Wert Docs · API 85
PR #1406, App: niedrigster Wert Legal · Copyright-Hinweise 67
PR #1407, App: niedrigster Wert Requirements · Traceability 25
PR #1408, App: niedrigster Wert Legal · Copyright-Hinweise 86
PR #1409, App: niedrigster Wert Tests · System 67
PR #1410, App: niedrigster Wert Tests · Unit 76
PR #1411, App: niedrigster Wert Legal · Lizenzen 69
PR #1412, App: niedrigster Wert Docs · API 85
PR #1413, Service: niedrigster Wert Tests · Unit 84
PR #1414, Service: niedrigster Wert UI & UX · Markenfarben 68
PR #1415, Service: niedrigster Wert Tests · Integration 85
PR #1416, Service: niedrigster Wert Security · Secrets 84
PR #1417, Service: niedrigster Wert Tests · Unit 70
PR #1418, Service: niedrigster Wert Security · Statische Analyse 69
PR #1419, Service: niedrigster Wert Legal · Lizenzen 85
PR #1420, Service: niedrigster Wert Docs · Handbuch 84
PR #1421, Service: niedrigster Wert Docs · Handbuch 67
PR #1422, Service: niedrigster Wert UI & UX · Markenfarben 25
PR #1423, Service: niedrigster Wert Docs · Handbuch 84
PR #1424, Service: niedrigster Wert UI & UX · Konsistenz 73
PR #1425, Bibliothek: niedrigster Wert Wartbarkeit · Kopplung 85
PR #1426, Bibliothek: niedrigster Wert Docs · API 85
PR #1427, Bibliothek: niedrigster Wert Codequalität · Stil 79
PR #1428, Bibliothek: niedrigster Wert Security · Secrets 85
PR #1429, Bibliothek: niedrigster Wert UI & UX · Konsistenz 66
PR #1430, Bibliothek: niedrigster Wert Wartbarkeit · Abhängigkeiten 84
PR #1431, Bibliothek: niedrigster Wert UI & UX · Konsistenz 84
PR #1432, Bibliothek: niedrigster Wert Wartbarkeit · Abhängigkeiten 85
PR #1433, Bibliothek: niedrigster Wert Security · Statische Analyse 84
PR #1434, Bibliothek: niedrigster Wert Docs · Handbuch 85
PR #1435, Bibliothek: niedrigster Wert Codequalität · Komplexität 85
PR #1436, Bibliothek: niedrigster Wert Docs · Changelog 69
PR #1437, Plattform: niedrigster Wert Tests · System 85
PR #1438, Plattform: niedrigster Wert Docs · Handbuch 86
PR #1439, Plattform: niedrigster Wert UI & UX · Konsistenz 85
PR #1440, Plattform: niedrigster Wert Tests · System 26
PR #1441, Plattform: niedrigster Wert Docs · Changelog 70
PR #1442, Plattform: niedrigster Wert Docs · API 70
PR #1443, Plattform: niedrigster Wert Requirements · Traceability 78
PR #1444, Plattform: niedrigster Wert Tests · System 85
PR #1445, Plattform: niedrigster Wert Tests · Integration 84
PR #1446, Plattform: niedrigster Wert Codequalität · Duplikate 67
PR #1447, Plattform: niedrigster Wert Requirements · Traceability 84
PR #1448, Plattform: niedrigster Wert Wartbarkeit · Kopplung 84

Arbeiten in den Daten

Das danwos-Monster liegt mit VR-Brille auf einer geschwungenen Liege, links die Tastatur, rechts die Maus, und arbeitet

Virtual-Reality-Brillen könnten diese neue Welt tragen, und mit ihnen andere Modelle für Schreibtisch und Arbeitsplatz. Statt Tabellen auf zwei Bildschirmen liegt das Projekt dann als Raum um dich herum – und das Problem leuchtet dort, wo es ist.

Tools für Views und Visualisierung

Einiges davon habe ich schon gebaut. Horus ist die Stadt aus Needs. Sphinx-Preview zeigt beim Überfahren eines Links, was dahinter steckt, ohne die Seite zu wechseln. Sphinx-Data-Viewer macht aus großen JSON-Daten einen Baum, den du nur so weit aufklappst, wie du ihn brauchst.