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

Modal redesign: unified modal pattern + rework of suggest-changes modal #45

New Issue
Open
opened 2026-05-20 08:35:05 +00:00 by mAi · 0 comments
mAi commented 2026-05-20 08:35:05 +00:00
Collaborator
Copy Link

Trigger

m's feedback 2026-05-20 10:36 on the suggest-changes modal (just shipped via t-paliad-216 Slice B):

I dont like the "suggest correction" modal — it should basically be a modal for all deadline information with an additional "comment" field — currently the layout isnt nice either, font size etc. We dont have too many modals yet but I think we should have a unified modal approach.

Two asks bundled: (a) fix the suggest-changes modal specifically, (b) establish a unified modal pattern for paliad so future modals (and the existing ones being retrofitted) share the same shape, typography, layout, and behaviour.

Immediate fix — suggest-changes modal

The current approval-edit-modal.ts (introduced 2026-05-20 in commit 66a0676) renders only the editable subset of fields per entity_type (deadlines: due_date / title / description; appointments: title / start_time / end_time / location). m wants:

  • All deadline information visible in the modal — title, description, due_date, original_due_date, warning_date, source, rule_code, notes, project context, requester, the original payload diff. Whether each field is editable in the suggest-changes flow is a design call (default: every field the deadline-edit form normally exposes is editable here too; read-only fields like created_at, updated_at, approved_by stay read-only).
  • The Vorschlagskommentar comment field stays — visible alongside everything else (not as an afterthought at the bottom).
  • Typography / layout polish — font sizes, spacing, section dividers between identity / dates / status / comment. The current implementation borrows the entity-edit shape; visually it ends up cramped and inconsistent with the rest of the app.

Same treatment for the appointment variant of the modal.

Longer-term — unified modal pattern

Current modal surfaces in the frontend (incomplete list, audit during design):

  • frontend/src/client/components/approval-edit-modal.ts (the one this issue is reworking)
  • frontend/src/client/filter-bar/save-modal.ts
  • frontend/src/client/event-types.ts
  • frontend/src/client/broadcast.ts
  • frontend/src/client/fristenrechner.ts
  • TSX-rendered modals on deadlines-detail.tsx, appointments-calendar.tsx, admin-*.tsx, etc.

Each surface today defines its own DOM shape, its own CSS, its own close behaviour, its own focus management. The result: every modal looks subtly different, and contributors copy whichever modal was nearest when they needed one.

Design goals for a unified modal primitive:

  • Single CSS section (probably under frontend/src/styles/) defining the modal frame: backdrop, container, header / body / footer regions, focus ring, scroll behaviour at long content, mobile breakpoint. Typography baseline matches the rest of the app (the existing .entity-table / .entity-event cards' type scale).
  • Single TS primitive (component or function) — openModal({title, body, footer, onClose}) or a class — that handles: focus trap, ESC-to-close, backdrop-click-to-close, ARIA roles, body-scroll-lock. Existing surfaces are retrofit (or stubbed for later refit; the existing ones don't have to all migrate in this issue).
  • Native <dialog> element if it works for our browser baseline (modern; supports showModal() + backdrop pseudo + native focus management); otherwise the existing div-based pattern with manual focus management.
  • One canonical example documented in docs/ for future contributors.

Out of scope

  • A generic form-builder framework. The modals carry entity-specific fields; the unified primitive is the frame, not the contents.
  • Visual redesign of the rest of the app — only the modal surface, plus typography consistency where modals touch it.
  • Retrofitting every existing modal in this issue. Suggest-changes is the immediate retrofit; the rest can come in follow-ups once the pattern is established. Audit during design which other modals are worth migrating now vs. later.

Acceptance

  • The suggest-changes modal renders all deadline / appointment information in a clean, scannable layout with the Vorschlagskommentar comment field prominent. Typography matches the rest of paliad.
  • A documented unified modal primitive exists in code + a one-pager in docs/design-modal-pattern-*.md.
  • At least the suggest-changes modal uses the new primitive end-to-end.
  • m can flip through the modal on a Mac laptop and an iPhone Safari without layout breakage.
  • ESC closes, backdrop click closes, focus traps inside, scroll-locks the body.

Role recommendation

inventor (hertz, retain context) — hertz just shipped the current suggest-changes modal end-to-end (Slices A+B+C), so re-engaging is cheaper than fresh-spawn. Design phase: audit existing modals + propose the unified primitive + lay out the suggest-changes redesign concretely. Then coder shift implements both.

Branch: mai/hertz/inventor-unified-modal.

## Trigger m's feedback 2026-05-20 10:36 on the suggest-changes modal (just shipped via t-paliad-216 Slice B): > I dont like the "suggest correction" modal — it should basically be a modal for all deadline information with an additional "comment" field — currently the layout isnt nice either, font size etc. We dont have too many modals yet but I think we should have a unified modal approach. Two asks bundled: (a) fix the suggest-changes modal specifically, (b) establish a unified modal pattern for paliad so future modals (and the existing ones being retrofitted) share the same shape, typography, layout, and behaviour. ## Immediate fix — suggest-changes modal The current `approval-edit-modal.ts` (introduced 2026-05-20 in commit `66a0676`) renders only the editable subset of fields per entity_type (deadlines: due_date / title / description; appointments: title / start_time / end_time / location). m wants: - **All deadline information visible in the modal** — title, description, due_date, original_due_date, warning_date, source, rule_code, notes, project context, requester, the original payload diff. Whether each field is editable in the suggest-changes flow is a design call (default: every field the deadline-edit form normally exposes is editable here too; read-only fields like `created_at`, `updated_at`, `approved_by` stay read-only). - **The Vorschlagskommentar comment field** stays — visible alongside everything else (not as an afterthought at the bottom). - **Typography / layout polish** — font sizes, spacing, section dividers between identity / dates / status / comment. The current implementation borrows the entity-edit shape; visually it ends up cramped and inconsistent with the rest of the app. Same treatment for the appointment variant of the modal. ## Longer-term — unified modal pattern Current modal surfaces in the frontend (incomplete list, audit during design): - `frontend/src/client/components/approval-edit-modal.ts` (the one this issue is reworking) - `frontend/src/client/filter-bar/save-modal.ts` - `frontend/src/client/event-types.ts` - `frontend/src/client/broadcast.ts` - `frontend/src/client/fristenrechner.ts` - TSX-rendered modals on `deadlines-detail.tsx`, `appointments-calendar.tsx`, `admin-*.tsx`, etc. Each surface today defines its own DOM shape, its own CSS, its own close behaviour, its own focus management. The result: every modal looks subtly different, and contributors copy whichever modal was nearest when they needed one. Design goals for a unified modal primitive: - Single CSS section (probably under `frontend/src/styles/`) defining the modal frame: backdrop, container, header / body / footer regions, focus ring, scroll behaviour at long content, mobile breakpoint. Typography baseline matches the rest of the app (the existing `.entity-table` / `.entity-event` cards' type scale). - Single TS primitive (component or function) — `openModal({title, body, footer, onClose})` or a class — that handles: focus trap, ESC-to-close, backdrop-click-to-close, ARIA roles, body-scroll-lock. Existing surfaces are retrofit (or stubbed for later refit; the existing ones don't have to all migrate in this issue). - Native `<dialog>` element if it works for our browser baseline (modern; supports `showModal()` + backdrop pseudo + native focus management); otherwise the existing div-based pattern with manual focus management. - One canonical example documented in `docs/` for future contributors. ## Out of scope - A generic form-builder framework. The modals carry entity-specific fields; the unified primitive is the **frame**, not the **contents**. - Visual redesign of the rest of the app — only the modal surface, plus typography consistency where modals touch it. - Retrofitting **every** existing modal in this issue. Suggest-changes is the immediate retrofit; the rest can come in follow-ups once the pattern is established. Audit during design which other modals are worth migrating now vs. later. ## Acceptance - The suggest-changes modal renders all deadline / appointment information in a clean, scannable layout with the Vorschlagskommentar comment field prominent. Typography matches the rest of paliad. - A documented unified modal primitive exists in code + a one-pager in `docs/design-modal-pattern-*.md`. - At least the suggest-changes modal uses the new primitive end-to-end. - m can flip through the modal on a Mac laptop and an iPhone Safari without layout breakage. - ESC closes, backdrop click closes, focus traps inside, scroll-locks the body. ## Role recommendation **inventor (hertz, retain context)** — hertz just shipped the current suggest-changes modal end-to-end (Slices A+B+C), so re-engaging is cheaper than fresh-spawn. Design phase: audit existing modals + propose the unified primitive + lay out the suggest-changes redesign concretely. Then coder shift implements both. Branch: `mai/hertz/inventor-unified-modal`.
mAi self-assigned this 2026-05-20 08:35:05 +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#45
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?