marcel/familienarchiv
1
0
Fork 0
Code Issues 109 Pull Requests Actions Packages Projects Releases Wiki Activity

feat(stammbaum): surface node.generation in the side panel for phone readers #691

New Issue
Open
opened 2026-05-28 16:19:55 +02:00 by marcel · 0 comments
marcel commented 2026-05-28 16:19:55 +02:00
Owner
Copy Link

Context

#689 ships the Stammbaum generation gutter — a 100 px left-hand column
rendering G{n} per occupied row. The gutter is hidden entirely below
md (768 px) as a deliberate trade-off: 100 px of permanent chrome is
too costly on a 320 px screen, and the spec notes:

Mobile (< md) generation rendering — gutter is hidden on small
viewports; tree readers on phones do not see G{n} labels.
Deliberate trade-off. The side panel may surface generation per-node
once #361 lands.

Leonie raised this on the PR #690 review: mobile/senior readers
currently lose the G-index affordance entirely. The dual-audience
standard (readers on phones, transcribers on laptops) means readers are
exactly the audience that gets cut off.

What to do

Add a single line to the Stammbaum side panel (StammbaumSidePanel.svelte
or equivalent) that surfaces G{node.generation} for the selected node
when node.generation != null. This is per-node detail in an existing
chrome region — no new layout, no new chip; just a labelled line in the
same style as birth/death years.

Out of scope: any second filter UI, range slider, or chip filter — the
gutter remains the desktop-only affordance for cross-row scanning.

Acceptance

  • Stammbaum side panel shows G{node.generation} for the selected
    node when set, on every viewport (mobile + desktop)
  • No row added when node.generation == null
  • Existing side-panel structure / styling unchanged otherwise
  • Component test covers the present + absent case

References

  • Parent: #689 (feature/689-generation-gutter / PR #690)
  • Out-of-scope note: PR #690 body, "Mobile (< md) generation rendering"
  • Dependent on: nothing — independent of #361 (dagre swap)
## Context #689 ships the Stammbaum generation gutter — a 100 px left-hand column rendering `G{n}` per occupied row. The gutter is **hidden entirely below `md` (768 px)** as a deliberate trade-off: 100 px of permanent chrome is too costly on a 320 px screen, and the spec notes: > Mobile (`< md`) generation rendering — gutter is hidden on small > viewports; tree readers on phones do not see `G{n}` labels. > Deliberate trade-off. The side panel may surface generation per-node > once #361 lands. Leonie raised this on the PR #690 review: **mobile/senior readers currently lose the G-index affordance entirely**. The dual-audience standard (readers on phones, transcribers on laptops) means readers are exactly the audience that gets cut off. ## What to do Add a single line to the Stammbaum side panel (`StammbaumSidePanel.svelte` or equivalent) that surfaces `G{node.generation}` for the selected node when `node.generation != null`. This is per-node detail in an existing chrome region — no new layout, no new chip; just a labelled line in the same style as birth/death years. Out of scope: any second filter UI, range slider, or chip filter — the gutter remains the desktop-only affordance for cross-row scanning. ## Acceptance - [ ] Stammbaum side panel shows `G{node.generation}` for the selected node when set, on **every** viewport (mobile + desktop) - [ ] No row added when `node.generation == null` - [ ] Existing side-panel structure / styling unchanged otherwise - [ ] Component test covers the present + absent case ## References - Parent: #689 (`feature/689-generation-gutter` / PR #690) - Out-of-scope note: PR #690 body, "Mobile (`< md`) generation rendering" - Dependent on: nothing — independent of #361 (dagre swap)
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
P0-critical
Blocks a core user journey, causes data loss, or is a security/accessibility barrier. Work on this before P1+.
 P1-high
Significant friction on a main user journey; workaround exists but is non-obvious. Next up after P0.
 P2-medium
Noticeable improvement; doesn't block anything; schedule opportunistically.
 P3-later
Cosmetic or parking-lot work; fine to stay open indefinitely.
 audit
Read-only audit / assessment work; produces a report rather than changing code
 bug
Something isn't working
 cleanup
Removal of dead code, vague comments, naming violations, and scratch artifacts
 collaboration
We want to extend the family archive to have more collaboration tools
 conversation
descoped
We will do that later
 devops
documentation
README, ARCHITECTURE, GLOSSARY, CONTRIBUTING, per-domain docs
 epic
Marker for epic-level issues that group multiple child issues
 feature
file-upload
legibility
Codebase Legibility Refactor — preparing the codebase for human evaluation and bus-factor reduction
 needs-discussion
Has an open decision or design question that must be resolved before implementation can start.
 notification
person
phase-1: security
Security hygiene — must be done first
 phase-2: container-images
Production-ready multi-stage Docker images
 phase-3: prod-compose
Production compose overlay + Caddy reverse proxy
 phase-4: spring-prod-profile
Spring Boot production configuration profile
 phase-5: backups
Database and object storage backup strategy
 phase-6: deployment-docs
.env.example, DEPLOYMENT.md, runbook
 phase-7: monitoring
Prometheus, Loki, Grafana, Alertmanager
 refactor
Code restructuring without behaviour change
 security
test
ui
UI/UX and accessibility issues
 user
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
Jens marcel
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: marcel/familienarchiv#691
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?