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

Projects page redesign — tree-first, filter chips (Alle / Mine / Pinned / Status), search-primary, view selector #10

New Issue
Open
opened 2026-05-07 19:54:04 +00:00 by mAi · 1 comment
mAi commented 2026-05-07 19:54:04 +00:00
Collaborator
Copy Link

Goal

Redesign /projects to be a user-friendly way to find a project or get an overview across multiple projects by specific criteria. m's framing (2026-05-07 21:52):

"The Projects Page needs to become nicer. I would like the default view to be a view of all clients - and one can filter very nicely. 'All' / 'Only mine' / Pinned / by status... The tree view is much nicer and more natural than the flat view. The search should be the main thing for 'ad-hoc' view, for favourites / pinned or other views we need to have a selector."

Locked direction (m, 2026-05-07)

  • Default view: tree, rooted at clients, with all descendants navigable
  • Quick-filter chips at the top: "Alle" / "Nur meine" / "Angepinnt" / "nach Status" / further filter axes the inventor proposes
  • Search is the primary ad-hoc tool — prominent, not buried
  • A view selector for favourites / pinned / saved views (likely overlaps with Custom Views #5 — inventor reconciles)
  • Tree-first — flat-list view stays available but isn't the default

Sketch

┌─ /projects ───────────────────────────────────────────┐
│ [🔍 Search …………………………………………………………………………………………]      │
│                                                       │
│ View: [Alle | Nur meine | Angepinnt | Status: …| ⋯]   │
│                                                       │
│ ▾ Siemens AG                                  ⋆       │
│   ▾ Siemens vs. Apple                          ⋆      │
│     ▸ Patent EP 1234567                              │
│       ▸ Case 14-vs-Müller                            │
│   ▾ Siemens vs. Bosch                                 │
│     …                                                 │
│ ▸ Audi AG                                             │
│ ▸ Daimler AG                                    ⋆     │
└───────────────────────────────────────────────────────┘

⋆ = pinned. Click a pin star to (un)pin. Tree state (open/collapse) persists per user.

Open design questions (for inventor — m will answer in design pass)

Default + filter axes

  1. Default landing. Tree of all visible clients with all collapsed except "Nur meine" expanded? OR last-viewed? OR a "Most recent activity" sort? Inventor recommendation, m signs off.
  2. Filter chips for v1. Pin down the v1 chip set:
    • "Alle" (default)
    • "Nur meine" (where I'm directly on the team OR derived)
    • "Angepinnt" (filter to pinned only)
    • "Status: …" (multi-select: open / on-hold / closed / archived)
    • "Typ: …" (Client / Litigation / Patent / Case)
    • "Mit aktiven Fristen" (has at least one open deadline)
    • others?
  3. Filter combinatorics. Do chips OR or AND? Recommend AND (chips compose), with within-chip values OR (e.g. status=open OR on-hold).

Tree view + UX

  1. Tree state persistence. Per-user open/collapse state stored in paliad.user_views-equivalent? Or session-only? Recommend session-only at v1 + ?expand=<csv> URL param for share-links; persistent later.
  2. Deep-link to a node. /projects?focus=<uuid> opens the tree with ancestors expanded + node scrolled into view. Useful for sidebar links, search hits, breadcrumb navigation.
  3. Lazy loading. Big trees (Siemens AG with 100s of cases): load top-level + N descendants by default? Lazy-expand on click? Inventor: confirm scaling pattern.
  4. Inline counts per node. Show (N Fristen, M Termine) as a badge per row? Per-node only, or per-subtree (aggregated)? Recommend subtree-aggregated by default (aligns with t-139 hierarchy aggregation). Inventor: confirm.
  5. Action affordances per row. Pin star, click-to-open detail, right-click for context menu? Hover-reveal vs always-visible? Mobile: how do these adapt?

Pinning

  1. Pin storage. New table paliad.user_pinned_projects (user_id, project_id, created_at) — simple. Recommend yes.
  2. Pin display. Pinned items get a star marker in the tree, AND a "Angepinnt" filter chip surfaces a flat-list of pinned-only? Or pinned items pulled to a top "⋆ Angepinnt" subtree above all clients? Inventor: pick.
  3. Pin syncing. Pins are per-user (not project-team). Confirm.

Search

  1. Search scope. Project title only? Title + parent path? Title + descendant titles ("find Cases under Müller")? Recommend title + parent-path with full-text on titles (existing FTS infra likely).
  2. Search shape. Inline filter (search input filters the tree in-place, hiding non-matches but keeping ancestor context)? Or modal results (Cmd-K style)? Recommend in-place filter for the v1 default; Cmd-K is for the global search.
  3. Empty-state. "No projects match — clear search?" + maybe "Create new client" affordance.

Saved views / Custom Views integration

  1. Overlap with Custom Views (#5 / t-144). Custom Views already has the "saved view of paliad rows" abstraction. Two paths:
  • (a) /projects gets its own selector, system views Hardcoded as chips; user pins/saved-filters are separate.
  • (b) /projects becomes one entry-point into Custom Views, where the system views ("Alle Projekte tree", "Meine Projekte", "Angepinnt") are seeded user_views with RenderShape: tree + filter specs.
  • Inventor: decide. (b) is more elegant but requires extending t-144's render shapes (a 4th shape "tree") and adjusting FilterSpec to express tree-state — that's significant. (a) is faster, less unification.
  1. "Most recent activity" sort. Useful for finding what you worked on last week. Out of scope for v1?

Mobile

  1. Mobile tree. Trees on phones are often awkward. Indented list? Drill-in (tap to push, breadcrumb to pop)? Recommend drill-in for ≤ 768px.

Performance

  1. Initial load size. Visible-projects-tree could be hundreds of rows for global_admin. Recommend lazy-load past the first N (50?) per parent, with "alle laden" affordance.
  2. Search responsiveness. Debounce (200ms?) + cap result count (top 20 hits with "show all") to keep typing snappy.

Out of scope (v1)

  • Drag-to-reorder projects (tree shape is data-driven, not user-orderable).
  • Bulk operations on multiple projects.
  • Project-level analytics dashboards.
  • Cross-project rollups (covered by /events / /agenda / Custom Views).
  • Sharing pinned-list with others.

References

  • paliad.projects — schema with path ltree, hierarchical
  • frontend/src/projects.tsx + client/projects.ts — current /projects page (flat list)
  • paliad.can_see_project() — visibility predicate (ancestor-walk + derivation per t-139)
  • t-139 hierarchy aggregation — descendant-count primitives the new tree can use
  • t-144 Custom Views — overlap point Q15 (saved views with tree shape)
  • frontend/src/components/Sidebar.tsx — has its own mini-tree for project navigation; styles + handlers reusable
  • frontend/src/client/project-indent.ts — existing indented-list helper (can be repurposed)

Inventor brief

  • Role: inventor (not noether — busy on Paliadin coder shift; not kepler — on profession-vs-role design awaiting m's engagement). Hire fresh.
  • Branch: mai/<inventor>/inventor-projects-page
  • Deliverable: docs/design-projects-page-2026-05-07.md. Four sub-designs:
    1. Filter axes + chip set + combinatorics (Q2-Q3)
    2. Tree view + UX + pinning (Q4-Q11, Q17)
    3. Search shape + integration (Q12-Q14, Q19)
    4. Custom-Views integration decision (Q15-Q16) + performance (Q18)
  • Inventor STOPs after design. Surface the open questions via PWA form OR AskUserQuestion (inventor's call) — do NOT dump as a markdown §X.Y list. m's dogma: make it easy for m. (memory: paliad/dogma — make it easy for m)
  • Awaits m's go on the design before any coder shift.

NOT cronus per memory directive (cronus retired from paliad).

## Goal Redesign `/projects` to be a user-friendly way to find a project or get an overview across multiple projects by specific criteria. m's framing (2026-05-07 21:52): > "The Projects Page needs to become nicer. I would like the default view to be a view of all clients - and one can filter very nicely. 'All' / 'Only mine' / Pinned / by status... The tree view is much nicer and more natural than the flat view. The search should be the main thing for 'ad-hoc' view, for favourites / pinned or other views we need to have a selector." ## Locked direction (m, 2026-05-07) - **Default view:** tree, rooted at clients, with all descendants navigable - **Quick-filter chips at the top:** "Alle" / "Nur meine" / "Angepinnt" / "nach Status" / further filter axes the inventor proposes - **Search is the primary ad-hoc tool** — prominent, not buried - **A view selector** for favourites / pinned / saved views (likely overlaps with Custom Views #5 — inventor reconciles) - **Tree-first** — flat-list view stays available but isn't the default ## Sketch ``` ┌─ /projects ───────────────────────────────────────────┐ │ [🔍 Search …………………………………………………………………………………………] │ │ │ │ View: [Alle | Nur meine | Angepinnt | Status: …| ⋯] │ │ │ │ ▾ Siemens AG ⋆ │ │ ▾ Siemens vs. Apple ⋆ │ │ ▸ Patent EP 1234567 │ │ ▸ Case 14-vs-Müller │ │ ▾ Siemens vs. Bosch │ │ … │ │ ▸ Audi AG │ │ ▸ Daimler AG ⋆ │ └───────────────────────────────────────────────────────┘ ``` ⋆ = pinned. Click a pin star to (un)pin. Tree state (open/collapse) persists per user. ## Open design questions (for inventor — m will answer in design pass) ### Default + filter axes 1. **Default landing.** Tree of all visible clients with all collapsed except "Nur meine" expanded? OR last-viewed? OR a "Most recent activity" sort? Inventor recommendation, m signs off. 2. **Filter chips for v1.** Pin down the v1 chip set: - "Alle" (default) - "Nur meine" (where I'm directly on the team OR derived) - "Angepinnt" (filter to pinned only) - "Status: …" (multi-select: open / on-hold / closed / archived) - "Typ: …" (Client / Litigation / Patent / Case) - "Mit aktiven Fristen" (has at least one open deadline) - others? 3. **Filter combinatorics.** Do chips OR or AND? Recommend AND (chips compose), with within-chip values OR (e.g. status=open OR on-hold). ### Tree view + UX 4. **Tree state persistence.** Per-user open/collapse state stored in `paliad.user_views`-equivalent? Or session-only? Recommend session-only at v1 + `?expand=<csv>` URL param for share-links; persistent later. 5. **Deep-link to a node.** `/projects?focus=<uuid>` opens the tree with ancestors expanded + node scrolled into view. Useful for sidebar links, search hits, breadcrumb navigation. 6. **Lazy loading.** Big trees (Siemens AG with 100s of cases): load top-level + N descendants by default? Lazy-expand on click? Inventor: confirm scaling pattern. 7. **Inline counts per node.** Show `(N Fristen, M Termine)` as a badge per row? Per-node only, or per-subtree (aggregated)? Recommend subtree-aggregated by default (aligns with t-139 hierarchy aggregation). Inventor: confirm. 8. **Action affordances per row.** Pin star, click-to-open detail, right-click for context menu? Hover-reveal vs always-visible? Mobile: how do these adapt? ### Pinning 9. **Pin storage.** New table `paliad.user_pinned_projects (user_id, project_id, created_at)` — simple. Recommend yes. 10. **Pin display.** Pinned items get a star marker in the tree, AND a "Angepinnt" filter chip surfaces a flat-list of pinned-only? Or pinned items pulled to a top "⋆ Angepinnt" subtree above all clients? Inventor: pick. 11. **Pin syncing.** Pins are per-user (not project-team). Confirm. ### Search 12. **Search scope.** Project title only? Title + parent path? Title + descendant titles ("find Cases under Müller")? Recommend title + parent-path with full-text on titles (existing FTS infra likely). 13. **Search shape.** Inline filter (search input filters the tree in-place, hiding non-matches but keeping ancestor context)? Or modal results (Cmd-K style)? Recommend in-place filter for the v1 default; Cmd-K is for the global search. 14. **Empty-state.** "No projects match — clear search?" + maybe "Create new client" affordance. ### Saved views / Custom Views integration 15. **Overlap with Custom Views (#5 / t-144).** Custom Views already has the "saved view of paliad rows" abstraction. Two paths: - (a) /projects gets its own selector, system views Hardcoded as chips; user pins/saved-filters are separate. - (b) /projects becomes one entry-point into Custom Views, where the system views ("Alle Projekte tree", "Meine Projekte", "Angepinnt") are seeded user_views with `RenderShape: tree` + filter specs. - Inventor: decide. (b) is more elegant but requires extending t-144's render shapes (a 4th shape "tree") and adjusting FilterSpec to express tree-state — that's significant. (a) is faster, less unification. 16. **"Most recent activity" sort.** Useful for finding what you worked on last week. Out of scope for v1? ### Mobile 17. **Mobile tree.** Trees on phones are often awkward. Indented list? Drill-in (tap to push, breadcrumb to pop)? Recommend drill-in for ≤ 768px. ### Performance 18. **Initial load size.** Visible-projects-tree could be hundreds of rows for global_admin. Recommend lazy-load past the first N (50?) per parent, with "alle laden" affordance. 19. **Search responsiveness.** Debounce (200ms?) + cap result count (top 20 hits with "show all") to keep typing snappy. ## Out of scope (v1) - Drag-to-reorder projects (tree shape is data-driven, not user-orderable). - Bulk operations on multiple projects. - Project-level analytics dashboards. - Cross-project rollups (covered by /events / /agenda / Custom Views). - Sharing pinned-list with others. ## References - `paliad.projects` — schema with `path ltree`, hierarchical - `frontend/src/projects.tsx` + `client/projects.ts` — current /projects page (flat list) - `paliad.can_see_project()` — visibility predicate (ancestor-walk + derivation per t-139) - t-139 hierarchy aggregation — descendant-count primitives the new tree can use - t-144 Custom Views — overlap point Q15 (saved views with tree shape) - `frontend/src/components/Sidebar.tsx` — has its own mini-tree for project navigation; styles + handlers reusable - `frontend/src/client/project-indent.ts` — existing indented-list helper (can be repurposed) ## Inventor brief - Role: inventor (not noether — busy on Paliadin coder shift; not kepler — on profession-vs-role design awaiting m's engagement). Hire fresh. - Branch: `mai/<inventor>/inventor-projects-page` - Deliverable: `docs/design-projects-page-2026-05-07.md`. Four sub-designs: 1. Filter axes + chip set + combinatorics (Q2-Q3) 2. Tree view + UX + pinning (Q4-Q11, Q17) 3. Search shape + integration (Q12-Q14, Q19) 4. Custom-Views integration decision (Q15-Q16) + performance (Q18) - Inventor STOPs after design. Surface the open questions via PWA form OR AskUserQuestion (inventor's call) — **do NOT dump as a markdown §X.Y list. m's dogma: make it easy for m.** (memory: paliad/dogma — make it easy for m) - Awaits m's go on the design before any coder shift. NOT cronus per memory directive (cronus retired from paliad).
mAi self-assigned this 2026-05-07 19:54:04 +00:00
mAi commented 2026-05-07 20:48:22 +00:00
Author
Collaborator
Copy Link

PR 2 (Cards view + drag-rearrange named layouts) merged into main as 552c920 — bundling 4e1d311 (backend: migration 061 paliad.user_card_layouts + CardLayoutService + LayoutSpec validator + CardsPreview endpoint) and aeeded7 (frontend: projects-cards.ts 796 LoC with HTML5 drag-and-drop edit mode + named layout picker).

Head-side review checks all green:

  • CSS tokens: only --color-*, --hlc-*-rgb, --font-mono, --radius-md — all exist in paliad's token system, no dark-mode contrast leaks.
  • Migration 061: no RAISE EXCEPTION, owner-only RLS, partial unique index for at-most-one-default-per-user invariant.
  • Schema head was v60 pre-merge; migration 061 will run on Dokploy deploy.
  • Build green per worker verification (go build, go vet, go test, bun run build, tsc --noEmit).

Combined with PR 1 (1061685), the t-paliad-149 /projects redesign is shipped: tree+chips+pin+search (PR1) and cards view + per-user drag-rearrange named layouts (PR2).

PR 2 (Cards view + drag-rearrange named layouts) merged into main as [`552c920`](https://mgit.msbls.de/m/paliad/commit/552c920) — bundling [`4e1d311`](https://mgit.msbls.de/m/paliad/commit/4e1d311) (backend: migration 061 `paliad.user_card_layouts` + `CardLayoutService` + `LayoutSpec` validator + `CardsPreview` endpoint) and [`aeeded7`](https://mgit.msbls.de/m/paliad/commit/aeeded7) (frontend: `projects-cards.ts` 796 LoC with HTML5 drag-and-drop edit mode + named layout picker). Head-side review checks all green: - CSS tokens: only `--color-*`, `--hlc-*-rgb`, `--font-mono`, `--radius-md` — all exist in paliad's token system, no dark-mode contrast leaks. - Migration 061: no `RAISE EXCEPTION`, owner-only RLS, partial unique index for at-most-one-default-per-user invariant. - Schema head was v60 pre-merge; migration 061 will run on Dokploy deploy. - Build green per worker verification (`go build`, `go vet`, `go test`, `bun run build`, `tsc --noEmit`). Combined with [PR 1 (`1061685`)](https://mgit.msbls.de/m/paliad/commit/1061685), the t-paliad-149 /projects redesign is shipped: tree+chips+pin+search (PR1) and cards view + per-user drag-rearrange named layouts (PR2).
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#10
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?