467 Stellen. Nicht durch einen anderen Strich ersetzt, sondern durch das
Satzzeichen, das an der jeweiligen Stelle richtig ist: Doppelpunkt, wo eine
Erlaeuterung folgt; Komma, wo der Satz weiterlaeuft; Punkt, wo zwei
Hauptsaetze aneinanderstiessen. Ein Halbgeviertstrich waere nur derselbe
Griff mit kuerzerem Strich gewesen.
Regelbasiert ersetzt und danach nachgeprueft, weil eine Regel allein nicht
reicht. Gefunden und einzeln korrigiert:
- Eingeschobene Saetze mit Strichpaar. Nur der oeffnende Strich passte ins
Muster, der schliessende blieb als "—," stehen. Drei Stellen, jetzt mit
Klammern oder als eigener Satz.
- Doppelte Doppelpunkte, wo beide Striche eines Paars zu Doppelpunkten wurden
("Globale Regeln: Schrift, Groessen, Abstaende: kommen aus HiveGrid").
Sieben Stellen in Doku und Oberflaeche, jetzt in Klammern.
- Pfade, denen ein Komma statt eines Doppelpunkts folgte.
- Ausgerichtete Kommentartabellen, in denen der Strich eine Spalte war.
Nicht angefasst: drei Geviertstriche, die keine Prosa sind, sondern
Tabellenplatzhalter fuer "kein Wert" (Trichter, Auftraege, Kunden). Dort ist
der Strich die Angabe selbst; ihn zu entfernen liesse leere Zellen zurueck.
tsc, lint, build, verify:carbon und verify:layout laufen sauber.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QPeZNwSeU7qG3RRCwaxEZX
9.5 KiB
Navigation und Seitenaufbau
Struktur
Die Seitenleiste zeigt nur unsere beiden Features. Kontakte, Leads, Pipelines, Postfach, Termine und Einstellungen stehen bereits in der Seitenleiste der Software und werden hier nicht verdoppelt, der Prototyp zeigt, was dazukommt, nicht was schon da ist.
HIVEGRID
├── Dashboard Begrüßungsbildschirm: Widget-Fläche /dashboard
└── Analytics ◄── der Prototyp lebt hier /analytics
├─────────────────────
└── Komponenten Bausteingalerie des Prototyps /komponenten
Gerendert wird mit derselben Komponente wie in der Software
(ui/components/SidebarWithSections, aus der Cloud-Fassung portiert) und
derselben Schrift (Instrument Sans, selbst gehostet aus denselben Dateien).
Für den Einbau: Verbindlich ist an dieser Seitenleiste die Struktur, zwei Einträge, Analytics mit innerer Leiste. Nicht verbindlich ist ihre Umsetzung hier. In der Software werden die zwei Einträge in die bestehende
AppSidebareingehängt und die innere Leiste über das dortigeSidebarIconsLayoutgebaut; unser Nachbau wird nicht mitportiert. Globale Regeln (Schrift, Größen, Abstände, Farben) kommen ausschließlich aus HiveGrid und werden von hier aus nicht überschrieben. Siehe ZIELSYSTEM.md Abschnitt 0.
Analytics ist ein einzelner Menüpunkt, kein aufklappbarer Bereich. Die fünf Analyse-Seiten sind darin über eine innere Leiste erreichbar:
/analytics Übersicht
/analytics/finanzen Finanzen
/analytics/auftraege Aufträge
/analytics/kunden Kunden
/analytics/team Team
Zwei Navigationsebenen für dieselbe Sache: Unterpunkte in der Seitenleiste und eine innere Leiste: würden nur konkurrieren.
Warum innere Leiste und nicht Reiter
Beides gibt es im Zielsystem, aber für verschiedene Aufgaben:
innere Leiste (SidebarIconsLayout) |
Reiter (Tabs) |
|
|---|---|---|
| Wofür | Arbeitsbereich mit Geschwisterseiten | Abschnitte innerhalb einer Seite |
| Beispiele | Leads, Termine, HR, Einstellungen: 17 Aufrufstellen | Formular-Editor, Chat-Dateien, Projekt-Teilbereiche, Übergabe-Dialog |
Analytics mit fünf Analyse-Seiten ist der erste Fall: strukturell dasselbe wie Leads mit seinen acht. Drei Gründe geben den Ausschlag:
- Kohärenz. Wer in der Software von Leads nach Analytics wechselt, findet dieselbe Bedienung an derselben Stelle.
- Der Platzeinwand trägt nicht. Die Leiste ist standardmäßig eine 32 px schmale Icon-Spalte und klappt erst bei Zeigerkontakt oder Tastaturfokus auf Beschriftungen aus (verzögert, damit sie beim Überstreichen nicht aufspringt). Sie kostet also kaum Breite, und die brauchen die Analyse-Seiten mit ihren fünfspaltigen Kennzahlenreihen und breiten Tabellen.
- Reiter sind dort der Rückfall, nicht die Wahl.
SidebarIconsLayoutzeigt unterhalbsmselbst eine Reiterleiste. Auf dem Schreibtisch Reiter zu verwenden hieße, die Handy-Notlösung zur Hauptform zu machen. Unser Nachbau übernimmt diesen Rückfall mit.
Ein weiterer Vorteil: Die Leiste wächst. Käme eine sechste Analyse-Seite dazu, ist das eine Zeile mehr, ein Reiterband würde eng.
„Dashboard" führt auf den Begrüßungsbildschirm unter /dashboard. Er hat
bewusst keine innere Leiste und keine Filterleiste: Er ist eine einzelne
Seite aus Kacheln, und jede Kachel trägt ihren eigenen Zeitraum. Das ist der
sichtbarste Unterschied zwischen den beiden Menüpunkten: Analytics ist ein
Bereich, das Dashboard eine Seite. Siehe
SCOPE-ANALYTICS-DASHBOARD.md.
Schmale Fenster
Unterhalb 768 px: derselbe Breakpoint, den die Software als MOBILE_BREAKPOINT
führt: fährt die Seitenleiste als Schublade über den Inhalt, statt ihn zu
verdrängen. Geöffnet wird sie über einen Hamburger links in der Kopfzeile.
Das ist nicht erfunden, sondern abgeglichen: SubframeAppShell im
Zielsystem rendert an derselben Stelle denselben Knopf: FeatherMenu, 32 × 32,
md:hidden, links vor dem Breadcrumb. Übernommen wurden auch das Verhalten der
Schublade (Abdeckung dahinter, Escape schließt, Fokus wandert beim Öffnen auf
den ersten Eintrag und kehrt beim Schließen zum Auslöser zurück) und die
Fokusfalle: Der Rahmen trägt role="dialog" und aria-modal, und ohne Falle
wäre das gegenüber einem Screenreader eine Unwahrheit.
Zwei Beobachtungen dazu, damit sie beim Einbau nicht als Fehler gelesen werden:
- Die geöffnete Schublade verdeckt den Hamburger. Geschlossen wird deshalb über Escape, einen Klick auf die Abdeckung oder eine Navigation. In der Software ist das genauso; der Umschaltzweig im Klickhandler ist dort wie hier praktisch unerreichbar.
- Der Einklapp-Knopf der Seitenleiste ist unterhalb
mdausgeblendet. Er ragt bauartbedingt 17 px nach rechts heraus und blieb sonst als angeschnittener, wirkungsloser Rest am linken Bildrand stehen.
Aufbau jeder Analyse-Seite
┌──────────────────────────────────────────────────────────────┐
│ Kopfzeile: Breadcrumb · Suche · Benachrichtigungen · Profil │ fest
├──────────────────────────────────────────────────────────────┤
│ Seitenkopf: Titel · Einordnung Aktualisieren Export ⇗ │
├──────────────────────────────────────────────────────────────┤
│ Filterleiste: Zeitraum │ Dimensionen │ zurücksetzen │ klebt oben
│ Aktive Filter als entfernbare Chips │
│ Ausgeblendete Widgets (nur wenn welche versteckt sind) │
├──────────────────────────────────────────────────────────────┤
│ KPI-Reihe (5 Karten, gleiche Höhe) │
│ [nur Übersicht] Handlungsbedarf über volle Breite │
│ Hauptdiagramm (2/3) │ Nebendiagramm (1/3) │
│ Detaildiagramme (2–3, oben bündig) │
│ Arbeitsliste (Tabelle) │
└──────────────────────────────────────────────────────────────┘
Die Reihenfolge folgt der Lesefrage: Wie steht es? → Was ist zu tun? → Wie hat es sich entwickelt? → Woran liegt es?
Auf der Übersicht steht der Handlungsbedarf direkt unter der KPI-Reihe und über die volle Breite. Sie ist die Seite der Geschäftsführung; dort ist „was ist zu tun" die zweite Frage, nicht die letzte. Jede Zeile trägt Betrag und Handlung („Mahnlauf starten", „Nachfassen"): eine Liste ohne Verb ist ein Bericht.
Auf den vier Detailseiten bleibt die Arbeitsliste unten: Dort ist sie die Konsequenz aus dem, was darüber steht.
Gleiche Kartenhöhe nur bei gleicher Struktur. Die KPI-Reihe wird gestreckt,
damit die fünf Karten als ein Objekt lesbar sind. Gemischte Reihen (Diagramm
mit fester Höhe neben Tabelle) stehen auf items-start: Strecken erzeugt dort
nur Weißraum.
Interaktionen
| Element | Verhalten |
|---|---|
| Zeitraum | Heute · 7 Tage · 30 Tage · Quartal · Jahr · Gesamt. Rechnet alle zeitraumbezogenen Kennzahlen und Charts neu, inklusive Vorperiodenvergleich |
| Dimensionsfilter | Mehrfachauswahl mit Suche; wirkt sofort. Nur Filter, die auf der Seite etwas bewirken, werden angeboten |
| Filter-Chips | Jede Einschränkung erscheint als Chip und lässt sich einzeln entfernen |
| Widget ausblenden | ⋯-Menü an jeder Karte. Ausgeblendete Karten erscheinen in der Filterleiste und lassen sich einzeln oder gesammelt zurückholen |
| Hover | Balken, Ringsegmente und Trichterstufen heben sich hervor, die übrigen treten zurück; Verläufe zeigen einen Tooltip mit allen Reihen des Datenpunkts |
| Handlungsbedarf | Jede Zeile ist ein Absprung in die zugehörige Arbeitsliste (im Prototyp Attrappe mit Hinweis) |
| Tastatur | Fokus ist auf allen interaktiven Elementen sichtbar; Filter-Dropdown und Karten-Menü schließen mit Escape und geben den Fokus zurück |
| Ringlegende | Klick hebt ein Segment dauerhaft hervor, erneuter Klick löst es wieder |
| Tabellen | Spaltenkopf sortiert, Suchfeld filtert, Blättern über Pfeile |
| Seitenleiste | Einklappbar; die Auswahl bleibt beim Seitenwechsel erhalten |
Filterauswahl und ausgeblendete Widgets überleben einen Reload
(localStorage, Schlüssel hivegrid.analytics.*).
Seitenabhängige Filterrelevanz
Definiert in features/dashboard/data/filtering.ts:
| Seite | Zeitraum | Gewerk | Auftragsstatus | Kundenquelle | Region | Mitarbeiter |
|---|---|---|---|---|---|---|
| Übersicht | ✓ | ✓ | ✓ | |||
| Finanzen | ✓ | ✓ | ✓ | ✓ | ||
| Aufträge | ✓ | ✓ | ✓ | ✓ | ✓ | |
| Kunden | ✓ | ✓ | ✓ | ✓ | ||
| Team | ✓ | ✓ | ✓ |
Ein Filter, der sichtbar ist aber nichts bewirkt, kostet Vertrauen in die Zahlen. Deshalb werden irrelevante Filter gar nicht erst angeboten, die Auswahl bleibt aber im Hintergrund erhalten und wirkt beim Seitenwechsel wieder.