Duplicate pins and regular nav must stay in sync
Aliases: duplicate nav state · alias not copy
What it is
The same place on the tree and in the pin bay is two doors. State on those doors must stay in sync: selected, unread, disabled, renamed, gone — both sides should say the same thing. Out of sync, people think they are two places, or that the pin is a stale copy.
Why it happens
A shortcut is an alias for arrival, not a copy of the object. Aliases often become a second record in the implementation: the tree item has an unread count, the pin stores another; the tree item is removed by permission, the pin still lights. Entering from the pin then shows an empty or error page, and trust moves from “short-cut” to “this product’s doors lie”. Selected state is the more common desync: enter a page from the tree and the pin still looks unselected, so people think they have not gone in; or both highlight, and selected-as-location is spent.
Rename and move are another desync. The tree node changes name or moves from group A to B; the pin still shows the old name and lands on the new place (or a missing page). The alias did not follow the reference, and the shortcut became a broken link.
Where it stops holding
If “recently opened” is designed as history rather than an alias, it may keep the name of a deleted object and mark it invalid — history semantics, not a sync failure. An offline cache may show a stale unread briefly, but must align once connected, and must not let a pin perform a write that will fail offline without saying so. The two surfaces may look different (pins tighter, tree fuller); the state bits (selected, badge, availability) may not.
Applying it
- Store a pin as a reference to the tree node. Unread, name, permission, and selected all read from one source; do not write two.
- When a node is deleted or unauthorised, the pin vanishes immediately or marks itself invalid; do not keep pretending it is enterable.
- Entering from either door updates selected state on both surfaces. No double highlight, no double dark.
- How to check: rename, mark unread, and revoke permission on the tree, and watch the pin bay reflect in the same moment. After entering from the pin, the tree item should show as current place. Plant a pin to a deleted node; the click must yield an invalid explanation, not a blank page.
Related
- Within the group: E5.16.1 Shortcuts let frequent functions skip the full hierarchy · E5.16.2 Pinned items must stay few, or they stop being shortcuts · E5.16.3 Customizability of shortcuts shapes long-term use
- Adjacent: E5.17 Navigation Badges and Hints · E5.18 Permission Visibility of Navigation
- Search terms:
duplicate navigation·pin sync·selected state