One person’s edit mode must not hijack others’ viewing

What it is

The same object can be open for many people at once. When one of them leaves view for edit, only their surface should change: their toolbar, their caret. Everyone else should stay in view. Their body should not suddenly become a typed page, their scroll should not be yanked, they should not be kicked out or forced to follow. This is independence of mode across sessions. Someone else’s caret as prevention is collaboration awareness. Here the question is whether one’s own view shell is replaced by someone else’s edit shell.

Why it happens

Early collaboration treated a document as a projector: one person pressed Edit, the room switched. That is a shared window, not a shared object. In a modern product each person has a session; mode is a session property, not an object property. If “the document is being edited” is implemented as a global flag, late arrivers land in someone else’s toolbar, readers watch the body jump, a selection is dragged away, shortcuts become formatting. A softer form is follow mode on by default: one person scrolls, every viewport follows. Viewing is a stable page; someone else’s edit mode is noise. Independence does not forbid seeing carets. It forbids someone else’s mode rewriting one’s chrome and viewport.

Studying it

Two people open one document. Jia enters edit, scrolls, types. Measure Yi’s mode, scroll position, whether Yi is ejected. Compare a global edit lock, follow-on-by-default, fully independent sessions.

Independent variables: edit mode as object-level versus session-level, follow default, whether Jia’s save reloads Yi’s page. Dependent variables: Yi switched into edit, Yi’s reading position lost, Yi believing they entered edit.

Two people sharing one display is screen share, not this test. Use two devices. If Jia cannot write, the task is void. Yi seeing Jia’s caret is not interference—that is presence; Yi’s shell should still be view.

Where it stops holding

Pair programming or a teacher driving student screens needs explicit follow or control, off by default, with “you are being led” visible to both and an exit. An object-level lock (only one editor at a time) is a different product choice; Yi should see “Jia is editing; you remain in view,” not a broken edit shell of their own. A presentation mode that syncs everyone to one page is a third mode, entered voluntarily. Whether two tabs of the same identity share mode is a multi-window issue: they should usually stay independent, or one tab entering edit wrecks the other tab used for comparison.

Applying it

• Store edit/view on the session, not as a global flag on the object. Jia enters edit; Yi keeps view chrome.
• Follow, present, and take control are explicit switches, off by default; both sides can leave.
• Jia’s save or autosave must not full-refresh Yi’s view; Yi’s scroll and collapsed sections stay.
• Verify: Jia enters edit, scrolls to the end, changes a sentence. Yi should still be reading at the original place, with no toolbar, not ejected. Ask Yi whether they can edit; the answer should match whether Yi tapped Edit, not whether Jia did.

Related

• Within the group: H8.09.1 Edit and view modes need a readable visual split · H8.09.2 The edit entry appears only when the person may edit · H8.09.3 Unexpected exit should keep a draft, not drop the work
• Adjacent: H8.07 Collaborative Edit Conflicts · V3.04 Follow Mode and Co-browsing · V2.01 Presence Awareness
• Search terms: independent sessions · follow mode · edit mode isolation