Associative entries must sit beside the primary structure, not replace it

What it is

Associative entries solve the sideways hop; they do not teach the map on a first visit. They must sit beside the primary structure, not replace it. A global or hierarchical spine remains the learnable skeleton; related links, see-also, and compatible items are shortcuts laid on that skeleton. Remove the spine and leave only in-page jumps, and newcomers have no reusable coordinate system, while returning users cannot generalize one successful hop to the next task.

Beside means both kinds of entry are reachable, with split duties—not related links promoted into global nav pretending to be a class.

Why it happens

The primary structure is a map shared across tasks: people can remember, by walking it, that policies live under Support and parts live under Products. Associative edges are task-specific; sofa → table this time does not help invoice → tax table next time. If the primary structure is withdrawn, people can only re-walk last time’s chain; when that chain breaks (content taken down, recommendations swapped), there is no retreat.

Rosenfeld and Morville treat hypertext as a supplement on hierarchy, not a second navigation that can ship alone. The learning mechanisms differ: the spine uses spatial memory and stable order; associations use relation type and the current object. Neither memory substitutes for the other. Making associative entries the only path asks every person to weave a net from scratch, a net that will not transfer to the next task or the next user.

Studying it

Compare three conditions—spine only, associations only, both—on a mix of along-tree and cross-branch find-item tasks.

• Paradigms: find-item experiments on one content set; score first tasks (no prior) separately from repeated tasks.
• Independent variables: global nav present or absent, density of associative links, whether relation types are named.
• Dependent variables: first-task success (should lean on the spine), path length on cross-branch tasks (should lean on associations), lostness when the spine is absent.
• Methodological note: experts can patch a links-only condition with search, masking the spine’s value for newcomers. Isolate first arrival. High click-through on related links does not prove global nav can go—it only proves the shortcut was used.

Where it stops holding

A tiny site of a handful of pages will collapse primary structure and associations into one link set; splitting them is ceremony. Pure hypertext documents (a novel, an essay in HTML) already take body links as their spine; site-style global nav is not their primary structure. In an app with one object type and one task (tickets only), the “spine” may be a list plus filters rather than a section tree; associations should still overlay the list, not replace it.

Applying it

• Keep related, compatible, and see-also in the content area or beside the object; do not replace spine items in the top bar or sidebar.
• Pages landed via an associative link still show full global nav and the object’s place in the primary structure, so a shortcut can return to the skeleton.
• When content is retired or a relation dies, remove the associative entry; do not regroup the spine around it.
• Verify by switching off every related/see-also and leaving global nav: along-tree tasks should still complete. Then switch off global nav and leave related links: first-time users should not complete along-tree tasks stably. Failure on the first check means the spine is too weak; surprising success on the second means the so-called associations have grown into a hidden second spine and should be promoted and managed in the open.

Related

• Within the group: G2.03.1 Associative navigation offers lateral jumps across levels · G2.03.2 Network structure lacks a sense of place
• Adjacent: G1.09 Types of organization systems · G2.06 Global and local navigation · G2.01 Hierarchical navigation
• Search terms: primary navigation · associative overlay · see also