Coarse View / Fine View Toggle¶
Interface control — instantiates Equivalence-Relation Refinement and Coarsening
A runtime control that lets each user read the same underlying data at the resolution their task needs, stepping between coarse and fine classes without ever changing the relation itself.
Sometimes the disagreement isn't over which granularity is right — it's that different users genuinely need different granularities at the same time. A Coarse View / Fine View Toggle resolves that by making resolution a view setting rather than a property of the data: the same records are projected up to broad classes or down to fine ones on demand, and each user picks the rung that fits their task. Its defining move is that it changes nothing about the equivalence relation — no class is split, merged, or renamed underneath — it only chooses which level of an existing ladder to render. A crisis manager sees three severity bands; the analyst behind them sees forty diagnostic codes; both are reading the identical cases through the identical mapping, just zoomed differently.
Example¶
A national mapping agency publishes a single interactive map of administrative boundaries. A cabinet minister opens it zoomed out and sees 13 regions; a logistics planner zooms in and the same territory resolves into 340 districts; a field surveyor zooms further to thousands of wards. Nobody has re-drawn anything — the toggle is simply reading a fixed containment ladder (ward ⊂ district ⊂ region) and rendering whichever level the current zoom selects. The payoff is that when the planner points at a district and the minister points at the region that contains it, they are provably talking about the same ground: the shared mapping guarantees the fine view rolls up to exactly the coarse view. A population figure shown at region level is the sum of its districts; drilling down never contradicts the number that was shown above it. The toggle gives three audiences three resolutions and one reconcilable truth.
How it works¶
The toggle's distinguishing method is projection over a fixed ladder, not re-computation. It leans on a pre-existing hierarchy that assigns every fine class to exactly one coarser parent, so moving up is aggregation and moving down is disaggregation, and the two are always consistent. What it adds on top of that structure is the per-user selection: a zoom level, a role default, a saved preference, or an explicit expand/collapse. Crucially it is read-only with respect to the relation — a user viewing the coarse level has not merged anything; close the view and the fine classes are still there, untouched, for the next user who needs them. The toggle also carries the level label into anything the user exports, so a figure is never quoted without the resolution it was taken at.
Tuning parameters¶
- Number of rungs exposed — just coarse/fine, or many intermediate levels. More rungs fit more tasks but crowd the control and tempt users to stall between levels.
- Default level per role — which rung a given user lands on first. A good default means most users never touch the control; a wrong one trains them to always override it.
- Roll-up consistency guarantee — whether the coarse view is forced to equal the aggregate of the fine (strict) or may use an independent coarse summary (loose). Strict keeps the levels reconcilable; loose allows a hand-tuned overview at the cost of drill-down surprises.
- Level stickiness — whether the chosen resolution persists across sessions and shared links, so a link opens at the sender's level rather than a default.
- Cross-level linking — whether selecting an item at one level highlights its counterpart at another, making the containment visible rather than implied.
When it helps, and when it misleads¶
Its strength is dissolving a false either/or: a system does not have to pick one granularity globally when a hierarchical resolution ladder plus a toggle can serve every audience its own view off one shared mapping. It is the low-commitment answer when both coarse and fine distinctions matter — no data migration, no lost detail, nothing to revert.
It misleads when users mistake a view for a decision. Someone who only ever looks at the coarse view can conclude the fine distinctions don't exist and start acting as if they were merged — the toggle silently becomes a policy nobody chose. It also invites inconsistent roll-ups when the coarse level is allowed to drift from the sum of its parts, so a number shown at the top no longer survives a drill-down — a failure that erodes trust fast because it looks like a data error.[n1] The classic misuse is shipping a coarse dashboard as if it were a simplified ontology, quietly hiding variance that some stakeholder needed to see. The discipline is to keep roll-ups strict, label every figure with its level, and remember that the toggle presents the relation — it must not be the thing that decides it.
How it implements the components¶
The toggle fills the presentation-side components — the ones a runtime view control can own:
multi_stakeholder_resolution_view— its whole reason for being: different users operate at different resolutions simultaneously off one shared mapping, each seeing the level their task needs.hierarchical_resolution_ladder— it exposes the ladder to the user as a navigable control, turning a static multi-level structure into something a reader can step up and down at will.
It does not define the class structure or the sameness basis behind the ladder — equivalence_basis_criteria — that is the Hierarchical Taxonomy or Lattice, which the toggle only reads from; and it never actually changes membership, so it holds no split/merge or migration machinery.
Related¶
- Instantiates: Equivalence-Relation Refinement and Coarsening — serves multiple resolutions of one relation without changing it.
- Consumes: Hierarchical Taxonomy or Lattice supplies the fixed ladder of classes the toggle projects onto.
- Sibling mechanisms: Hierarchical Taxonomy or Lattice · Equivalence Class Crosswalk Table · Granularity Tuning Rubric · Classification Confusion or Error Matrix · Periodic Relation Granularity Review
Editorial Notes¶
Form Classification¶
Form family: Interface, Display & Cue
Rationale: A runtime control that lets each user read the same underlying data at the resolution their task needs, stepping between coarse and fine classes without ever changing the relation itself, making its operative form a prompt, display, template, or perceptual cue that shapes attention and input at the point of use.
Independent corroboration: The frozen evidence defines Coarse View / Fine View Toggle as 'A runtime control that lets each user read the same underlying data at the resolution their task needs, stepping between coarse and fine classes without ever changing the relation itself', so its operative form is Interface, Display & Cue.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Human-Computer Interaction
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: Interface design established semantic zoom and runtime detail controls over one stable underlying dataset.
Related originating lineages:
- Library & Information Science — Hierarchical classification supplies the consistent coarse-to-fine mapping.
Review resolution: Both reviewers agree on human_computer_interaction as primary. Reading the mechanism confirms that its defining operation belongs to that lineage; the final record retains library_information_science only as materially formative origin and keeps present-day application breadth separate from provenance.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
[n1] In cartography and computer graphics, level of detail (LOD) is the practice of rendering the same object at a resolution matched to how it is being viewed. A coarse/fine toggle is an LOD control over a category system; the roll-up consistency guarantee is what keeps its levels from disagreeing the way naively independent LODs would. ↩