Presence is not collaboration

In March 2020, a small green dot acquired more responsibility than it could carry.

Work, study, and ordinary coordination moved abruptly into homes. Video calls, chat, shared documents, and status indicators became the visible architecture of being together. When a person appeared online, the interface offered a reassuring story: they were here, reachable, and participating.

The dot could usually prove only that a client had communicated recently.

A browser could be open while its person cared for someone, read a difficult document, lost connectivity, stepped away, or tried to concentrate. A gray dot could mean sleep, deliberate focus, an unsupported device, or a background process that stopped reporting. Presence was a narrow technical observation that products routinely promoted into a social conclusion.

While designing D4U7, I removed the general presence indicator. Collaboration needed stronger evidence and more humane uncertainty.

Presence collapsed several questions

The word “available” hid different states:

• Can the service deliver an update to one of this person's devices?
• Is a relevant room open in the foreground?
• Has the person seen the latest revision?
• Do they understand what changed?
• Have they accepted an action?
• Are they able and willing to respond now?
• Are they making progress elsewhere?

An online signal answered, at best, an approximation of the first two. Interface design often let it imply the rest.

That implication changed behavior. A message to an online person felt urgent even if the subject was not. A delayed response looked like disregard rather than a normal attention boundary. A person could remain visibly active across applications and still miss the decision that mattered.

D4U7 separated observable states. Delivery, acknowledged revision, explicit action acceptance, and authored contribution were different records. Willingness, understanding, and progress were not inferred from a heartbeat.

The product became less socially fluent and more precise. It stopped turning connectivity into character.

The heartbeat measured a device

My first prototype sent a heartbeat while a room page was open. The server marked the participant present for a short interval. It looked simple until I tested ordinary browser behavior.

Background tabs throttled timers. Laptops slept. Phones switched networks. A service worker could wake without the page being visible. Multiple tabs reported the same account. A briefly disconnected client remained marked online until timeout, while a returning client appeared offline until its next heartbeat.

I could improve the protocol with visibility events, connection IDs, and shorter intervals. The result would still describe browser activity, not human availability.

The technical uncertainty mattered because the social interpretation was strong. A false green dot could invite an interruption. A false gray dot could exclude someone from a decision. Increasing heartbeat frequency would spend battery and network traffic to sharpen a claim the system was not entitled to make.

I kept connection state where it helped the local interface—showing whether this tab could currently synchronize—and removed it from the participant list.

The device needed honest status. The person did not need to be rendered as a device.

Fast response was not evidence of useful work

Presence indicators often sit beside last-active times and response expectations. Together they create a measurable surface around visibility.

That surface rewards work the system can observe: replying, reacting, joining, moving a cursor, or keeping a client awake. Reading, thinking, testing an alternative, and waiting for a better time can look identical to absence.

D4U7 was designed for decisions that benefited from delayed thought. Optimizing for immediate response would undermine the product's purpose. I chose deadlines and explicit blockers instead of ambient urgency.

A room said when input was needed and what consequence the deadline carried. A question could name the participant or role whose answer blocked a proposal. A reminder could be scheduled according to that commitment. The interface did not need to watch whether the person happened to be online in between.

This shifted accountability from visible activity to agreed state. A missed deadline remained a fact. Silence before the deadline remained space.

The distinction was especially important when home schedules became irregular. People needed a product that tolerated asynchronous contribution, not one that reconstructed an office hallway through green dots.

Read receipts appeared to offer stronger evidence than presence. A message reached a device and was displayed. The interface could show who had seen it.

Display still did not prove comprehension or agreement. A notification preview might count as read. A person could skim without absorbing a changed constraint. A long thread could be opened at the latest message while important context remained unread.

D4U7 tracked an acknowledged room revision for consequential handoffs. A person chose Caught up through revision 18 after reviewing the digest. This was not automatic surveillance. It was an explicit statement with a defined object.

Action acceptance was separate. A person could acknowledge the final decision and decline or question an assigned follow-up. Dissent could remain visible while understanding was confirmed.

For casual conversation, no receipt was required. The stronger signal appeared only where ambiguity would create duplicated or blocked work.

This added a small interaction and removed a large interpretive burden. The system stopped treating a viewport event as a social commitment.

Live cursors solved one problem and created another

Shared-document cursors can be genuinely helpful. They show that another edit is happening near the same text and reduce accidental collisions. They also make every pause visible.

D4U7 did not attempt general simultaneous editing. Contributions were designed to develop across hours, with immutable revisions and deliberate merge when concurrent changes met. A continuous cursor layer would add pressure without matching the model.

I kept a narrow collision warning. If two active editors held the same proposal revision, the editor said another session might produce a competing save. It did not show typing cadence, cursor position, or an animated avatar following each selection.

The warning described a technical risk: the shared base might diverge. It did not ask either person to surrender the document or respond immediately. Both drafts remained recoverable.

Presence was useful when attached to a concrete coordination hazard. It was harmful as a general proxy for participation.

The boundary helped keep the interface quiet enough for long-form thought.

Video calls made simultaneous presence obvious. A roster could show who joined, who spoke, and who remained until the end. The meeting could still finish without a usable decision.

The hidden work of a room—changed assumptions, informal agreement, unresolved dissent, and next actions—did not automatically survive the call. A recording preserved too much to serve as a quick handoff. Attendance proved neither understanding nor consent.

D4U7 treated a call as one possible coordination step. The resulting answer had to enter the room as a revised proposal, answered question, decision, or action. A short note could link the call when the context mattered, but the durable state did not depend on replaying it.

People absent from the call could review the outcome and evidence asynchronously. People present could correct the record if it misrepresented the discussion.

The product did not try to score speaking time or attendance. Those numbers were easy to collect and weakly related to the quality of the decision.

Being together can improve understanding. The record still needs to survive after together ends.

Missing response had multiple explanations

An unanswered question could mean it was unseen, unclear, unnecessary, uncomfortable, blocked on evidence, or addressed elsewhere. Presence did not choose among those explanations responsibly.

D4U7 represented what it could observe:

• The question is open at revision 7.
• It blocks proposal B.
• A response was requested by Friday.
• No response or explicit deferral has been recorded.

The interface could remind the intended participant, allow a delegate, extend the deadline, or let the room proceed with the uncertainty documented. It did not label the person unresponsive based on a status dot.

This repeated W93H's distinction between observation and hypothesis. Absence of evidence is often important. It still does not authorize an invented motive.

Product language mattered. “Awaiting response” described room state. “Bob is ignoring this” would describe a person with evidence the system did not possess.

The more socially consequential the inference, the more restrained the software needed to be.

Removing passive presence did not eliminate the need to communicate availability. People could set a small authored status with an expiry: focusing until 15:00, offline today, available for the scheduled review window, or delayed by connectivity.

The status was optional and contextual. It did not calculate productivity or override notification preferences. Expiry prevented a week-old “back soon” from becoming current truth.

I avoided a universal availability schedule in the prototype. The study circle used low-consequence planning, and participants did not need to publish their home routines to collaborate. A room deadline and notification preference supplied enough coordination.

Where a status affected a specific action, the action could be delegated or rescheduled explicitly. The product did not infer availability from calendar gaps, keyboard activity, or time-zone stereotypes.

Authored state was not perfectly accurate either. Plans change. Its advantage was epistemic: the person made the claim and bounded its lifetime.

The system offered a channel for context without pretending it could observe the person directly.

Even without dots, immediate notifications can create the same demand. If every contribution produces a ping, the fastest way to reduce anxiety is to remain continuously attentive.

D4U7 grouped updates into digests based on changed state. Immediate delivery was reserved for a small set of selected events: a decision deadline moved materially, a required conflict needed review, or an accepted action became blocked.

Mentions did not automatically override preferences. Otherwise any participant could convert an asynchronous room into an urgent channel by adding a name.

The digest said why an update mattered:

• Evidence used by the current proposal changed.
• Your open question received an answer.
• A decision was recorded and one action awaits acceptance.
• Your offline draft now has a conflicting server revision.

It did not say “17 new activities.” Volume was not consequence.

By making delivery policy explicit, the product allowed people to be absent without accumulating a punishment of contextless alerts.

Local connection state still mattered

Removing participant presence did not mean hiding network conditions. A person drafting offline needed to know which work remained local. A returning tab needed to say whether its room revision was current. A submitted operation with unknown outcome needed a recovery path.

D4U7 displayed four distinct local states:

connection: offline | connecting | online
document: current | behind | reconciling
draft: clean | local | saving | conflict
outbox: empty | pending | attention

An online connection did not imply a current document. A current snapshot did not imply that a local draft had been delivered. A delivered operation did not imply another participant had acknowledged it.

This was presence used at the correct boundary: the application described its own relationship to server state. It did not project that state onto another person.

The more precise local model also reduced social guesswork. “My contribution is still pending because this tab is offline” was a system fact the author could act on.

The study scenarios changed

The first usability scenario asked whether participants could see who was online and send a message. That measured the prototype I had copied rather than the asynchronous product I claimed to want.

I replaced it with return and handoff scenarios:

• Open a room after a day away and identify what changed.
• Find the current proposal without reading every comment.
• Acknowledge a decision while preserving dissent.
• Accept or decline a follow-up action explicitly.
• Continue drafting through a network interruption and understand what remains local.
• Resolve a concurrent edit without losing either version.

The evaluation asked participants to explain the room's current state and their next obligation. It did not ask whether the interface felt lively.

This changed which features appeared important. Revision digests, decision records, and conflict recovery moved ahead of animated avatars. The product became less impressive in a screenshot and more useful after time had passed.

Presence is visually persuasive because it can be shown instantly. Recovery quality takes a scenario to see.

Presence data created a retention question

Once a service records heartbeats, last-seen times, foreground state, or typing activity, those observations can outlive the fleeting coordination purpose that justified them. A current dot may need only a short-lived connection lease. An activity history can become a behavioral record.

Q2F8 had made me ask what product decision each retained event supported. D4U7 did not need a historical account of when participants opened rooms, how long tabs stayed visible, or how quickly they typed. I removed those events rather than collecting them and promising not to misuse them.

Security-relevant access, membership changes, exports, and document revisions still had explicit retention because they supported permissions and recovery. Ordinary reading remained private. The server knew enough to authorize a request and deliver the requested state; it did not turn that access into a participant activity feed.

Even the narrow edit-collision lease expired quickly and was not preserved as room history. It warned that two sessions shared a base revision, then disappeared when the risk ended.

This restraint improved the social design and reduced architecture. There was no presence fan-out service, historical activity table, or privacy setting trying to make passive observation acceptable after the fact. The product did not need to secure and explain data it had declined to create.

Removing presence was therefore more than hiding dots. It removed an information flow whose strongest future uses were unrelated to the quiet decision experience.

I did not turn asynchronous work into a universal rule.

An active safety incident, a sensitive interpersonal conflict, or a rapidly changing decision with irreversible consequence may require people to coordinate live. A pair debugging one difficult state transition can benefit from shared attention. Social conversation has value that no decision schema should attempt to justify.

D4U7 could suggest a focused conversation when a conflict remained unresolved or the decision window became too short. The important outcome returned to durable state afterward.

The choice was not synchronous or asynchronous as identities. It was how much coordination the consequence justified, who paid its timing cost, and what record needed to survive.

Presence became intentional and bounded instead of ambient. A scheduled session said why participants should align their attention. An always-on dot asked them to infer the reason continuously.

Good collaboration could include presence without being measured by it.

Removing the dots made absence ordinary

The participant list became quieter: names, relevant role in the room, acknowledged revision where needed, and explicit pending actions. No green, gray, or last-seen field tried to describe availability.

At first, the empty space felt like missing functionality. Then the room stopped inviting the question “why has this online person not replied?” The useful questions remained: is an answer required, by when, and what happens if it does not arrive?

Those questions could be designed. They produced deadlines, delegation, review windows, and explicit uncertainty. The dot had produced interpretation.

The sudden remote-work shift made coordination failures more visible and put enormous pressure on people to prove they were present. Software could either amplify that pressure or make delayed contribution a normal supported state.

D4U7 chose the latter. It preserved drafts, decisions, revisions, and handoffs so useful work did not require everyone to share a moment.

Presence can be warm, reassuring, and genuinely helpful. It is still not the same thing as collaboration. The durable evidence is what people can understand, decide, and carry forward after every dot has gone gray.

That evidence survives sleep, distance, interruption, and the honest limits of attention.