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

Symmetric date-range filter (centered ALL, past/future fans) — inventor design #79

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

m's report (2026-05-25 12:44)

I am also not happy with the timeline filters in the different forms and filters... this should be simplified and more intuitive - whether past or future and how far. Maybe we can make a date selection improvement? Maybe "ALL" is in the middle, then left is past (and how far, until the whole past) and right is future - so we do the same: next 7 / 14 / 30 / 90 days / All Future.

Maybe we could have some kind of date filtering mini modal where we also have the date filtering slicer that we use on upckommentar.de (have a look there)

Phase: inventor design (READ-ONLY)

Inventor → coder gate per project CLAUDE.md.

Context

Date-range filters today are scattered across forms / filter bars / event lists — each with its own input style. m wants a single, opinionated, symmetric picker:

  • Center: ALL
  • Left fan: past 7 / 14 / 30 / 90 days / whole past
  • Right fan: next 7 / 14 / 30 / 90 days / All Future

Plus possibly a mini modal with a slicer-style date filter, modelled on the one used on upckommentar.de (UPCommentary/upc-kommentar repo).

What inventor should do

  1. Audit current date-range affordances across paliad — list every place a user picks past/future window (events filter, custom view filters, deadline form date range, browse-a-proceeding, dashboard widgets, /inbox future state, etc.). Be exhaustive.
  2. Look at upckommentar's slicer — check git -C ~/dev/upc-kommentar (path on mRiver may differ; verify) or the live site. Capture the visual + interaction pattern in the design doc. Screenshot-equivalent description if no actual screenshots.
  3. Design the symmetric picker as a single React-flavoured component (we don't run React but the TSX renderer follows the same conventions). Layout:
    • Default closed state: a single button labelled with the current selection ("Alle Zeiten", "Nächste 30 Tage", "Letzte 7 Tage", custom range).
    • Open: the symmetric chip row with past on the left, ALL center, future on the right.
    • Custom range: a date-pair input at the bottom of the popover.
  4. Decide reuse contract — what component API replaces every existing date-range affordance? How does it serialize into URL query params / form fields?
  5. Optional mini modal vs popover — m mentioned a "date filtering mini modal". Inventor decides whether popover (simpler) or modal (more prominent) is the right pattern. Default (R): popover for filters, modal only where the user is explicitly invoking a date filter as a tool (rare). Justify.
  6. Migration plan — which call sites get migrated in this slice vs later. Default (R): one component lands; the highest-traffic call site (events filter) migrates first; lower-traffic sites migrate in a follow-up.

Deliverable

docs/design-date-range-picker-2026-05-25.md on branch mai/<inventor>/date-range-picker-design. Sections:

  • §0 TL;DR
  • §1 Current state (catalogue of every date-range affordance in paliad today)
  • §2 upckommentar slicer pattern (what it does, what's worth borrowing)
  • §3 Component design (props, states, layout sketch)
  • §4 URL / form serialization contract
  • §5 Migration plan (which call sites in slice A, B, C)
  • §6 Visual decisions (chip labels, accent for currently-selected, custom-range entry)
  • §7 Edge cases (timezones, far-past truncation, overlapping selections)
  • §8 Open questions for m

Hard rules

  • READ-ONLY design phase. No code.
  • Head answers questions — NO AskUserQuestion. Inventor uses mai instruct head. Defaults to (R); escalate only material picks (esp. modal-vs-popover and the urgency of the migration).
  • Compare against upckommentar live or in repo; do NOT hallucinate the slicer pattern from imagination.

When done

Push design doc + mai report completed with "DESIGN READY FOR REVIEW". Inventor stays parked. Head gates coder shift.

Out of scope

  • Time-of-day picking (separate concern).
  • Recurring-event windows (events feed handles this elsewhere).
  • Per-language adjustments beyond DE/EN labels.
## m's report (2026-05-25 12:44) > I am also not happy with the timeline filters in the different forms and filters... this should be simplified and more intuitive - whether past or future and how far. Maybe we can make a date selection improvement? Maybe "ALL" is in the middle, then left is past (and how far, until the whole past) and right is future - so we do the same: next 7 / 14 / 30 / 90 days / All Future. > > Maybe we could have some kind of date filtering mini modal where we also have the date filtering slicer that we use on upckommentar.de (have a look there) ## Phase: inventor design (READ-ONLY) Inventor → coder gate per project CLAUDE.md. ## Context Date-range filters today are scattered across forms / filter bars / event lists — each with its own input style. m wants a single, opinionated, symmetric picker: - Center: **ALL** - Left fan: **past 7 / 14 / 30 / 90 days / whole past** - Right fan: **next 7 / 14 / 30 / 90 days / All Future** Plus possibly a **mini modal** with a slicer-style date filter, modelled on the one used on `upckommentar.de` (UPCommentary/upc-kommentar repo). ## What inventor should do 1. **Audit current date-range affordances** across paliad — list every place a user picks past/future window (events filter, custom view filters, deadline form date range, browse-a-proceeding, dashboard widgets, /inbox future state, etc.). Be exhaustive. 2. **Look at upckommentar's slicer** — check `git -C ~/dev/upc-kommentar` (path on mRiver may differ; verify) or the live site. Capture the visual + interaction pattern in the design doc. Screenshot-equivalent description if no actual screenshots. 3. **Design the symmetric picker** as a single React-flavoured component (we don't run React but the TSX renderer follows the same conventions). Layout: - Default closed state: a single button labelled with the current selection ("Alle Zeiten", "Nächste 30 Tage", "Letzte 7 Tage", custom range). - Open: the symmetric chip row with past on the left, ALL center, future on the right. - Custom range: a date-pair input at the bottom of the popover. 4. **Decide reuse contract** — what component API replaces every existing date-range affordance? How does it serialize into URL query params / form fields? 5. **Optional mini modal vs popover** — m mentioned a "date filtering mini modal". Inventor decides whether popover (simpler) or modal (more prominent) is the right pattern. Default (R): popover for filters, modal only where the user is explicitly invoking a date filter as a tool (rare). Justify. 6. **Migration plan** — which call sites get migrated in this slice vs later. Default (R): one component lands; the highest-traffic call site (events filter) migrates first; lower-traffic sites migrate in a follow-up. ## Deliverable `docs/design-date-range-picker-2026-05-25.md` on branch `mai/<inventor>/date-range-picker-design`. Sections: - §0 TL;DR - §1 Current state (catalogue of every date-range affordance in paliad today) - §2 upckommentar slicer pattern (what it does, what's worth borrowing) - §3 Component design (props, states, layout sketch) - §4 URL / form serialization contract - §5 Migration plan (which call sites in slice A, B, C) - §6 Visual decisions (chip labels, accent for currently-selected, custom-range entry) - §7 Edge cases (timezones, far-past truncation, overlapping selections) - §8 Open questions for m ## Hard rules - READ-ONLY design phase. No code. - **Head answers questions** — NO AskUserQuestion. Inventor uses `mai instruct head`. Defaults to (R); escalate only material picks (esp. modal-vs-popover and the urgency of the migration). - Compare against upckommentar live or in repo; do NOT hallucinate the slicer pattern from imagination. ## When done Push design doc + `mai report completed` with "DESIGN READY FOR REVIEW". Inventor stays parked. Head gates coder shift. ## Out of scope - Time-of-day picking (separate concern). - Recurring-event windows (events feed handles this elsewhere). - Per-language adjustments beyond DE/EN labels.
mAi self-assigned this 2026-05-25 11:23:31 +00:00
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 mAi
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: m/paliad#79
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?