The semantic difference between view, comment, and edit permissions

What it is

Document collaboration permissions usually compress into three tiers — view (read, leave no trace), comment (read and annotate, cannot touch the body), edit (change content and structure) — and these are not merely technical capability switches: each encodes a stance of participation: observer, advisor, co-author. The tiers only work when users understand the semantics accurately. Someone who mistakes comment for view leaves annotations they never meant to publish; someone who mistakes view for edit keeps poking a grayed-out button and suspects their own incompetence. The value of permission tiers is not security granularity but letting each person know, before entering the document, what kind of participation is expected of them.

Why it happens

The three-tier structure holds because it maps three levels of trust in modification rights. View: the content is a read-only stream to you — you consume without affecting document state — fit for announcements and finalized reference material. Comment: an elegant middle layer — your thinking enters the document's periphery (annotations anchored to specific content) without touching the body, while the author keeps full authority; it lets "offering input" stop short of "changing content," protecting both the social cost of feedback and the integrity of the text. Edit: you rewrite shared state directly, your operations fusing with the author's on the same plane; your role graduates from advisor to co-author. The crux is that the semantic boundaries between tiers must be clean: whether commenters see each other's annotations and can reply, whether viewers can copy and export — which tier owns these edge behaviors must match user expectation, and any mismatch produces the misuses above. Finer granularity beyond three tiers (can edit but cannot reshare, can comment but cannot @-mention) steeply raises cognitive cost and should stay unexpanded absent a specific need.

Where it stops holding

Three tiers are the document-collaboration sweet spot, not a universal structure. Spreadsheets and databases often need a fourth tier (can add rows but not change structure, can edit one's own fields but not others') because row- and column-level needs are real; in code collaboration "edit" splits further into can-commit and can-merge once review enters the picture. The three-tier semantics also presuppose permissions as static identities assigned per person. Dynamic control (temporary revocation, time-boxed opening) has to extend the model with validity periods and exception rules, shifting complexity into the understandability of inheritance and exceptions — another matter for this same group.

Applying it

• Express the tiers with one icon-and-wording family (the eye/speech-bubble/pencil metaphor set), identical in the assignment UI and the grantee's UI.
• Keep under-permitted entry points visible but grayed with an explanation ("you need edit permission to change this paragraph"), turning tier boundaries into learnable feedback.
• Define edge behaviors explicitly and document them: commenter-to-commenter visibility, viewer copy/export, editor re-sharing rights.
• Introduce a fourth tier only when row/column-level control is truly needed, and align its defaults with the three-tier semantics so old vocabulary is not redefined.
• Verification: assign participants different tiers and ask them to predict "can I do X" item by item against actual capability; prediction errors clustered on edge behaviors mean the semantics need patching.

Related

• Same group: V3.07.1 Sharing scope must be persistently visible next to the content · V3.07.3 Expanding the sharing scope requires explicit confirmation · V3.07.4 The understandability of permission inheritance and exceptions · V3.07.5 Permission changes must notify affected collaborators
• Nearby: V6.04 Approvals and Review · V2.01 Presence Awareness
• Search terms: permission tiers · read-only access · comment-only access · role-based sharing