Side-by-Side Legacy / Native Mode¶
Dual-mode interface — instantiates Legacy-Form Refashioning
Runs the old and new workflows at the same time and in view of each other, so users can work the familiar way, cross-check the native way, and fall back the instant they need to.
A Side-by-Side Legacy / Native Mode keeps both the old workflow and the new one live and visible at once, running on the same task, so a user can complete real work in the familiar mode, watch the native mode do the same job differently, and drop back to the old way the moment the new one is distrusted. Its defining idea is co-presence: nothing is disguised and nothing is hidden — the legacy mode is a genuine, first-class fallback, and the native mode standing next to it is a teacher-by-contrast. Because both run on live data, the interface quietly reveals two things the user could never see in a costume: what the new substrate can do that the old could not, and which old constraints were never really necessary.
Example¶
An airline retrofits its trainer aircraft with a glass cockpit but leaves the transition deliberately doubled. The instrument panel now shows a synthetic-vision native display — terrain shaded in 3-D, traffic and weather overlaid, the flight path drawn ahead — right beside a faithful emulation of the old "steam gauge" six-pack: round dials for airspeed, altitude, attitude. Both are live, both driven by the same sensors. A veteran pilot flies by the round dials she trusts and glances at the synthetic display to cross-check; if the new display ever looks wrong, the gauges remain the authority. Over training hours she notices the native display shows terrain and traffic the gauges physically cannot, and that the old habit of a fixed instrument-scan pattern — a constraint the round dials imposed — simply doesn't apply when the horizon is drawn for her. The old panel never disappears mid-transition; it is the boundary she can always retreat to.
How it works¶
- Two live panes, one task. The legacy and native workflows run simultaneously on the same underlying data; either can drive the work to completion.
- Draw the authority boundary. State exactly where the legacy mode remains authoritative and where the native mode takes over, so the user always knows which pane is safe to trust — and can retreat across a defined line, not into a void.
- Show the delta. The native pane visibly does what the old cannot, and visibly omits the constraints the old imposed — making both the new capability and the dropped constraint legible by direct comparison.
- Reconcile on conflict. When the two modes disagree, a stated rule decides which wins, so co-presence never becomes ambiguity.
Tuning parameters¶
- Pane parity — whether the two modes are co-equal or one is primary and the other a reference. Co-equal reassures cautious users; native-primary pushes learning but weakens the fallback's felt safety.
- Fallback scope — how much of the task the legacy mode can still fully perform. A complete fallback is safest and most expensive to maintain; a partial one lowers cost but strands users at its edges.
- Sync tightness — whether the panes mirror the same live state instant-to-instant or are allowed to diverge. Tight sync teaches by exact contrast; loose sync is cheaper but invites confusion.
- Reconciliation rule — which mode is authoritative when they conflict, and how visibly that is signalled.
When it helps, and when it misleads¶
Its strength is safe migration under high stakes: users are never stranded, they learn the native mode by watching it solve a task they already understand, and the constant contrast exposes exactly which inherited constraints were baggage. It is the mechanism of choice when the cost of a wrong, un-retreatable step is severe.
Its failure mode is the support burden and mode confusion of running two systems at once: users lose track of which mode they are in or which is authoritative, and act on the wrong one at the worst moment — the classic automation surprise.[n1] The classic misuse is keeping both modes forever with no authority discipline, doubling maintenance while the "temporary" fallback quietly becomes permanent. The guarding discipline is a crisp, always-visible authority boundary and a stated intent to retire the legacy pane — co-presence is a bridge, not a destination.
How it implements the components¶
fallback_and_compatibility_boundary— the legacy pane is a first-class, always-available fallback with an explicitly drawn line marking where it remains authoritative.substrate_affordance_map— the native pane, shown beside the old, makes visible what the new substrate can do that the old form could not.inherited_constraint_filter— running native next to legacy exposes which old-medium constraints (a fixed scan order, batch entry, one-record-at-a-time) no longer bind.
It does not disguise the new mode as the old beneath a single imitative skin (legitimacy_bridge_cue) — that is Skeuomorphic Onboarding Interface, which hides one mode rather than keeping both live. Nor does it set the calendar for retiring the legacy pane (phased_shedding_gate); that timetable is Legacy Pattern Deprecation Schedule.
Related¶
- Instantiates: Legacy-Form Refashioning — supplies the co-present fallback that lets a risky transition proceed without ever stranding the user.
- Consumes: Format Crosswalk and Migration Guide — the mapping that lets the two modes operate on the same data and agree on what each legacy element becomes.
- Sibling mechanisms: Skeuomorphic Onboarding Interface · Affordance Discovery Prototype · Legacy Pattern Deprecation Schedule · Format Crosswalk and Migration Guide · Substrate-Native Showcase Release · User Readiness Signal Panel · Design Rationale Changelog
Editorial Notes¶
Form Classification¶
Form family: Interface, Display & Cue
Rationale: Side-by-Side Legacy / Native Mode operates as a user-facing prompt, display, template, or perceptual cue that shapes attention and action at the point of use because it runs the old and new workflows at the same time and in view of each other, so users can work the familiar way, cross-check the native way, and fall back the instant they need to.
Independent corroboration: The frozen evidence defines Side-by-Side Legacy / Native Mode as 'Runs the old and new workflows at the same time and in view of each other, so users can work the familiar way, cross-check the native way, and fall back the instant they need to', so its operative form is Interface, Display & Cue.
Nearest alternative: Control, Automation & Runtime — Side-by-Side Legacy / Native Mode includes features of a live operational control that automatically routes, enforces, adapts, or responds during execution, but its defining operation is a user-facing prompt, display, template, or perceptual cue that shapes attention and action at the point of use.
Review outcome: Independent reviewer agreement; medium confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: Running old and new implementations in parallel for comparison and immediate fallback is a software migration and release-validation pattern. GOV.UK beta guidance retains the legacy service until the new one is proven; HCI contributes visible cross-checking for users.
Related originating lineages:
- Engineering & Design — Parallel operation qualifies a replacement without removing the proven path.
- Human-Computer Interaction — Parallel modes reduce learning risk and preserve user agency during transition.
- Innovation & Entrepreneurship — innovation_entrepreneurship contributes innovation management and experimental venture practice to this mechanism's defining operation—Runs the old and new workflows at the same time and in view of each other, so users can work the familiar way, cross-check the native way, and fall back the instant they need to—without displacing the selected primary historical lineage.
- Organizational & Management Science — Change management stages adoption while maintaining business continuity.
Review resolution: The blind reviewers disagree on primary lineage (computer_science versus human_computer_interaction). Authoritative or primary research supports computer_science as the best historical origin: Running old and new implementations in parallel for comparison and immediate fallback is a software migration and release-validation pattern. GOV.UK beta guidance retains the legacy service until the new one is proven; HCI contributes visible cross-checking for users. The cited NASA, Product Verification; GOV.UK Service Manual, How the Beta Phase Works directly supports the mechanism's defining operation. All independently supported contributing domains are retained without an arbitrary cap. origin_mode=cross_disciplinary_synthesis records lineage, while domain_reach=multi_domain records later applicability separately from provenance.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Researched adjudication after independent review; high confidence.
Sources consulted:
Notes¶
[n1] Mode confusion / automation surprise — a well-documented class of human-factors failure (studied by Nadine Sarter and David Woods, among others) in which an operator loses track of which mode a system is in and acts on the wrong one. It is the sharpest risk of any dual-mode interface and the reason the authority boundary must stay visible at all times. ↩