UX: Tag-Typeahead/Chips zeigen den Baumpfad, um gleichnamige Eltern/Kind-Tags zu unterscheiden (Follow-up zu #730) #734

New Issue

marcel · 2026-06-06T11:09:59+02:00

marcel commented

2026-06-06 11:09:59 +02:00

Summary

Follow-up to #730 (and a sibling of #732). The canonical tag tree legitimately contains names that differ only by case — a parent container and its same-named lowercase child (Weihnachten parent / Weihnachten/weihnachten child), or two siblings (Reise/Reisepläne / Reise/reisepläne). #730 made name→tag resolution deterministic and accepted the free-text semantics as-is (option A): typing the bare word weihnachten binds to the deep child, typing Weihnachten binds to the parent container.

That is correct and predictable, but invisible to the author: in the tag typeahead and on the selected chips, two tags render as the same label with no way to tell which node will be (or has been) attached.

Proposal

Disambiguate same-named tags in the UI by surfacing the tree path (e.g. Weihnachten › weihnachten or the source_ref path), at minimum when a name collision exists:

Typeahead dropdown: when more than one tag shares a case-folded name, show the tree path / parent breadcrumb on each option so the author picks the intended node deliberately.
Selected chips: for a tag whose bare name is ambiguous, show enough path context (tooltip or inline breadcrumb) that the attached node is identifiable.

Keep the common (non-colliding) case visually unchanged — only colliding names need the extra context, so the chrome stays calm for the 60+ author audience.

Out of scope

The deeper fix of round-tripping tag IDs instead of names is tracked separately in #732. This issue is purely the display/affordance layer; it is useful with or without #732.

Notes

Frontend-only (tag typeahead component + chips). The tree path is already available via source_ref / parentId on the tag model.
Raised in the PR #733 review (Elicit, requirements; Leonie, UX).

## Summary Follow-up to #730 (and a sibling of #732). The canonical tag tree legitimately contains names that differ only by case — a parent container and its same-named lowercase child (`Weihnachten` parent / `Weihnachten/weihnachten` child), or two siblings (`Reise/Reisepläne` / `Reise/reisepläne`). #730 made name→tag resolution deterministic and accepted the free-text semantics as-is (option A): typing the bare word `weihnachten` binds to the **deep child**, typing `Weihnachten` binds to the **parent container**. That is correct and predictable, but **invisible to the author**: in the tag typeahead and on the selected chips, two tags render as the same label with no way to tell which node will be (or has been) attached. ## Proposal Disambiguate same-named tags in the UI by surfacing the **tree path** (e.g. `Weihnachten › weihnachten` or the `source_ref` path), at minimum when a name collision exists: - **Typeahead dropdown:** when more than one tag shares a case-folded name, show the tree path / parent breadcrumb on each option so the author picks the intended node deliberately. - **Selected chips:** for a tag whose bare name is ambiguous, show enough path context (tooltip or inline breadcrumb) that the attached node is identifiable. Keep the common (non-colliding) case visually unchanged — only colliding names need the extra context, so the chrome stays calm for the 60+ author audience. ## Out of scope - The deeper fix of round-tripping tag **IDs** instead of names is tracked separately in #732. This issue is purely the **display/affordance** layer; it is useful with or without #732. ## Notes - Frontend-only (tag typeahead component + chips). The tree path is already available via `source_ref` / `parentId` on the tag model. - Raised in the PR #733 review (Elicit, requirements; Leonie, UX).

marcel added the P3-later ui labels 2026-06-06 11:10:05 +02:00

marcel referenced this issue

2026-06-06 11:10:55 +02:00

fix(tag): resolve case-colliding tag names without throwing (#730) #733

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: marcel/familienarchiv#734