Expansion state should persist for the session
Aliases: remember expanded nodes · tree open state · in-session expansion
What it is
Expanding a tree lays down a working path in space: which parents are open, which stretch of subtree is in view, is navigation the user just did. Session-persistent tree expansion asks that this path not be silently taken back during the same use — leaving and returning, refreshing a slice of data, selecting another node should not fold the branches already opened. It is not about how depth is drawn. It is about whether the scene the user spread out is still there.
Why it happens
The tree’s visible shape is external memory bought with a chain of expand actions. Working memory does not keep “which seven folders I opened”; they remain in view because the interface is remembering them. A redraw that returns to “all collapsed but the root” wipes that external memory, and the user must click the same sequence again. Local refresh, virtualised recycling of nodes, and auto-collapsing side branches on a new selection are common erasers: to the program they are a state reset; to the user they are getting lost. Persistence here is not a long-term preference. It treats expansion as navigation state, at the same rank as the current selection and scroll position. Whether it survives across sessions is a separate ledger. Keep the scene inside the session first; decide later whether it is a preference.
Studying it
Have people expand a deep path for a task, then insert a redraw (switching a sidebar, applying a filter, selecting a side branch) and ask them to continue. Record re-expand counts, time to the original node, and reports that “the tree closed.” Independent variables: kind of redraw, whether the expansion set is kept, whether side branches auto-collapse. Dependent variables: path reconstruction cost, rate of believing a node was deleted. “Is it nice to use” is not a substitute for “is the expansion set still there.”
Where it stops holding
When the root dataset is replaced (another repo, another account), old expansions point at ghosts and should clear. If node ids are unstable and reload with new keys, “persistence” is only collapsing a new tree. Very deep, very bushy trees may hit a performance ceiling if every expansion is stored — that is an implementation cap, not a reason to collapse everything every time; keep the recent path rather than every branch. A read-only demo tree that retells from the root each visit resets on purpose, as narrative.
Applying it
- Treat expanded node ids as navigation state, stored with the selection for the session. Restore by id on a local refresh, not by visual position.
- Do not auto-collapse side branches on a new selection unless those branches are mutually exclusive with the new task, and then collapse with a visible motion rather than a cut.
- When the root data is replaced, clear the expansion set explicitly and start from the new root, so expansions do not point at deleted nodes.
- How to check: expand a three-level path, do something that redraws the tree, and look back. If the path is gone, find which reset wiped it.