Suche fängt bei „Alle" an, Bereiche in der Kopfzeile sind Knöpfe
Prüfung / Lint, Typen, Tests (push) Canceled after 0s
Prüfung / Images bauen (pdf) (push) Canceled after 0s
Prüfung / Images bauen (web) (push) Canceled after 0s
Prüfung / Images bauen (worker) (push) Canceled after 0s
Images / bauen (pdf, docker/pdf.Dockerfile) (push) Canceled after 0s
Images / bauen (web, docker/web.Dockerfile) (push) Canceled after 0s
Images / bauen (worker, docker/worker.Dockerfile) (push) Canceled after 0s

**Suche.** Sie startete auf den Fallakten, und man musste die Art vorher
wählen — die falsche Reihenfolge: wer einen Namen eintippt, weiss noch nicht,
ob er eine Fallakte, ein Dokument oder eine Personalakte sucht. Er will wissen,
wo der Name vorkommt.

„Alle" ist jetzt der Auslieferungszustand und zeigt je Art fünf Treffer als
eigenen Block, mit dem Weg in die volle Liste daneben. Getrennte Blöcke statt
einer gemischten Liste nach Rang: ein Aktenzeichen neben einem Namen neben
einer Dokumentnummer hat keine erkennbare Ordnung. Die einzelnen Arten bleiben
als Filter, und nur dort gibt es Facetten und Blättern — beides bezieht sich
auf eine Grundmenge, ein Statusfilter über Fall- und Personalakten zugleich
wäre bei der einen ein Filter und bei der anderen ein Ausschluss.

**Kopfzeile.** Die Bereiche waren Textlinks: von einem Fliesstextlink nicht zu
unterscheiden und ohne Hinweis darauf, wo man gerade ist. Jetzt dieselbe
Knopfform wie alles Bedienbare, der aktive Bereich gefüllt.

Der gefüllte Zustand trägt hellen Text statt der Akzentfarbe: auf der getönten
Fläche wäre Akzent auf Akzent und der Kontrast fiele unter die Untergrenze.
Dazu etwas grosszügigere Polsterung an beiden Knopfgrössen, .btn-count für
Zahlen in Knöpfen, und kein Doppelring mehr am Profilbild.

Nachgesehen mit dem gebauten CSS im Browser, hell und dunkel.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
Harlekin
2026-09-03 21:59:06 +02:00
co-authored by Claude Opus 5
parent d867bc9b19
commit 74b52625c8
10 changed files with 335 additions and 92 deletions
+5
View File
@@ -14,6 +14,11 @@ Postgres Full-Text-Search, deutsche Konfiguration. Kein Elasticsearch.
Filter: Status, Fallart, Zeitraum, Beteiligte, Klassifizierung, Tags, nur meine Fälle.
**Die Suche sucht ohne Angabe über alle Arten.** Wer einen Namen eintippt, will wissen, wo er
vorkommt, und nicht zuerst entscheiden, wonach er sucht. Die gemeinsame Ansicht zeigt je Art
eine Handvoll Treffer als eigenen Block, mit dem Weg in die volle Liste daneben; die einzelnen
Arten bleiben als Filter, und nur dort gibt es Facetten und Blättern.
**Die Sichtbarkeitsprüfung gehört in dieselbe Abfrage**, nicht als Nachfilter. Sonst stimmen
Trefferzahl und Seitenlänge nicht und aus den Lücken lässt sich auf verborgene Akten
schließen. Gleiches gilt für Facettenzähler.
+26
View File
@@ -1213,3 +1213,29 @@ Der Test prüft die Regel und nicht die Zahl: er liest die Polsterung von `.fiel
und verlangt, dass Label-Abstand und Reihenabstand darüber liegen. Wer die Polsterung ändert,
fällt dort auf. Nachgemessen im Browser mit dem gebauten CSS: 8 px senkrecht gegen 5,6 px
Innenpolsterung, 13,6 px waagerecht gegen 11,2 px.
### Die Suche fängt bei „Alle" an
Die Suche startete auf den Fallakten, und man musste die Art vorher wählen. Das ist die
falsche Reihenfolge: wer einen Namen eintippt, weiss noch nicht, ob er eine Fallakte, ein
Dokument oder eine Personalakte sucht — er will wissen, **wo** der Name vorkommt.
`all` ist deshalb der Auslieferungszustand. Die gemeinsame Ansicht zeigt je Art fünf Treffer
als eigenen Block, mit dem Weg in die volle Liste daneben. Getrennte Blöcke und nicht eine
gemischte Liste nach Rang: ein Aktenzeichen neben einem Namen neben einer Dokumentnummer hat
keine erkennbare Ordnung.
Facetten und Blättern gibt es weiterhin nur bei einer einzelnen Art. Beides bezieht sich auf
**eine** Grundmenge — ein Statusfilter über Fallakten und Personalakten zugleich wäre bei der
einen Art ein Filter und bei der anderen ein Ausschluss.
### Die Bereiche in der Kopfzeile sind Knöpfe
Sie waren Textlinks: von einem Fliesstextlink nicht zu unterscheiden und ohne jeden Hinweis
darauf, wo man gerade ist. Jetzt tragen sie dieselbe Knopfform wie alles Bedienbare, und der
Bereich, in dem man steht, ist gefüllt.
Der gefüllte Zustand trägt **hellen Text statt der Akzentfarbe**: auf der getönten Fläche wäre
Akzent auf Akzent, und der Kontrast fiele unter die Untergrenze aus docs/10-design-system.md.
Aus demselben Grund liegt in einem Knopf steckende Zahl (`.btn-count`) in Mono und gedämpft —
sie ist eine Angabe, kein Teil der Beschriftung.