m/paliad
1
0
Fork 0
Code Issues 146 Pull Requests 8 Actions 1 Packages Projects Releases Wiki Activity

Site mode: global scope (Project / Gerichtssystem) that pre-filters the whole UI #28

New Issue
Open
opened 2026-05-09 09:02:11 +00:00 by mAi · 0 comments
mAi commented 2026-05-09 09:02:11 +00:00
Collaborator
Copy Link

Idea (m, Voice 2026-05-09 11:01)

"Eine weitere Idee für unser Paliad-Projekt — ist ein Seitenmodus, und dieser Modus bestimmt beispielsweise dann nur ein Projekt oder nur ein Gerichtssystem. Und wenn man in diesem Modus ist, ist der Rest der Seite darauf ausgelegt und alles ist schon vorausgewählt. Das heißt, ich kann beispielsweise sagen, ich bin jetzt im Projekt-B-Modus und danach ist überall quasi schon der Projekt-B-Filter gesetzt und ich sehe auch nur noch Projekt B. Das muss ein bisschen prominent funktionieren."

Feature concept

A site-wide scope mode — a globally-pinned context that the entire UI honours until the user steps out of it.

When in Mode: <Project B>:

  • Every list / search / filter is pre-filtered to Project B (no need to manually filter on every page)
  • Every "create new X" form pre-fills project = Project B
  • Every dashboard / widget / counter scopes to Project B
  • The UI shows visibly + prominently that a mode is active (so the user doesn't get confused why some data is "missing")

Same idea for a Mode: <Gerichtssystem X> (e.g., scope to UPC, EPG, DPMA, or specific Local Division).

UX surface (rough)

  • Mode indicator: prominent header banner / persistent chip, e.g. 📌 Modus: Projekt B [×]
  • Mode switcher: a dropdown / picker at the top of the page; recently-used modes for quick switching
  • Exit mode: one click to return to the unscoped (default) view
  • Persistence: mode survives page reloads (localStorage or per-user pref)
  • URL marker: optionally include the mode in the URL so a bookmark restores the mode

Open questions for design phase

  • Mode-types: only project and court system from the start, or generic scope system that other dimensions (party, judge, time-window) plug into later?
  • Mutual exclusivity: only ONE mode at a time, or stackable (Project B AND Gerichtssystem UPC)?
  • Scope of the filter: every page, or per-page opt-out for pages where it doesn't make sense (e.g., global search across projects)?
  • How does it interact with the existing per-page filter UI — does setting a filter inside a mode override the mode filter, or refine it?
  • Per-user vs. per-session scope: does the mode persist across devices via user-prefs, or is it browser-local?

Out of scope (initial issue)

  • Implementation — this issue is just the parked idea. Inventor / designer phase comes when m wants to build it.
  • Mode permissions (i.e., who can set what mode) — comes with the design doc.

Workflow

Park-only for now. When m wants to build:

  1. Inventor designs UX + state-management approach (per-user pref, store, URL sync)
  2. Coder implements stage 1: Project mode (single mode type, prominent indicator, persistent)
  3. Coder implements stage 2: Gerichtssystem mode + multi-mode if decided
  4. Generalise to a scope mode framework if the pattern proves out

Refs

  • m's voice 2026-05-09 11:01 (parking request)
  • Existing Paliad filter UI (per-page) — needs reading before design phase to understand current state
## Idea (m, Voice 2026-05-09 11:01) > "Eine weitere Idee für unser Paliad-Projekt — ist ein Seitenmodus, und dieser Modus bestimmt beispielsweise dann nur ein Projekt oder nur ein Gerichtssystem. Und wenn man in diesem Modus ist, ist der Rest der Seite darauf ausgelegt und alles ist schon vorausgewählt. Das heißt, ich kann beispielsweise sagen, ich bin jetzt im Projekt-B-Modus und danach ist überall quasi schon der Projekt-B-Filter gesetzt und ich sehe auch nur noch Projekt B. Das muss ein bisschen prominent funktionieren." ## Feature concept A site-wide **scope mode** — a globally-pinned context that the entire UI honours until the user steps out of it. When in `Mode: <Project B>`: - Every list / search / filter is pre-filtered to Project B (no need to manually filter on every page) - Every "create new X" form pre-fills `project = Project B` - Every dashboard / widget / counter scopes to Project B - The UI shows visibly + prominently that a mode is active (so the user doesn't get confused why some data is "missing") Same idea for a `Mode: <Gerichtssystem X>` (e.g., scope to UPC, EPG, DPMA, or specific Local Division). ## UX surface (rough) - **Mode indicator**: prominent header banner / persistent chip, e.g. `📌 Modus: Projekt B [×]` - **Mode switcher**: a dropdown / picker at the top of the page; recently-used modes for quick switching - **Exit mode**: one click to return to the unscoped (default) view - **Persistence**: mode survives page reloads (localStorage or per-user pref) - **URL marker**: optionally include the mode in the URL so a bookmark restores the mode ## Open questions for design phase - Mode-types: only `project` and `court system` from the start, or generic `scope` system that other dimensions (party, judge, time-window) plug into later? - Mutual exclusivity: only ONE mode at a time, or stackable (Project B AND Gerichtssystem UPC)? - Scope of the filter: every page, or per-page opt-out for pages where it doesn't make sense (e.g., global search across projects)? - How does it interact with the existing per-page filter UI — does setting a filter inside a mode override the mode filter, or refine it? - Per-user vs. per-session scope: does the mode persist across devices via user-prefs, or is it browser-local? ## Out of scope (initial issue) - Implementation — this issue is just the parked idea. Inventor / designer phase comes when m wants to build it. - Mode permissions (i.e., who can set what mode) — comes with the design doc. ## Workflow Park-only for now. When m wants to build: 1. Inventor designs UX + state-management approach (per-user pref, store, URL sync) 2. Coder implements stage 1: Project mode (single mode type, prominent indicator, persistent) 3. Coder implements stage 2: Gerichtssystem mode + multi-mode if decided 4. Generalise to a `scope mode` framework if the pattern proves out ## Refs - m's voice 2026-05-09 11:01 (parking request) - Existing Paliad filter UI (per-page) — needs reading before design phase to understand current state
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
deferred
Parked — not pursuing now, may un-park later
done
Work completed by an agent; awaiting m to close
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
mAi m
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: m/paliad#28
No description provided.
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?