V3.04.4Mutual visibility of follow relationshipsdesign

Who follows whom must be visible to both sides

Aliases: follow relationship visibility · bidirectional follow cue · follower list

What it is

Following is a relationship: someone has handed you their viewport, and you are being "watched-along-with." That relationship must be visible to both sides — the leader sees who is following, and the follower sees whom they are following. Invisible follow relationships fail in both directions: a leader unaware of followers navigates recklessly and shakes them off; a follower who cannot see whom they follow mistakes a change of leader for a change of content when the frame switches in multi-person settings. Making the attribution of the relationship continuously legible is the precondition for followers to adapt their behavior and for leaders to accept guidance responsibility — when the ownership of a shared state is not persistently visible, people cannot tell which relationship is currently in effect, and follow relationships are that rule applied here.

Why it happens

Visibility changes behavior on both ends. For the leader, seeing the follower roster induces guidance responsibility: slowing down before moves, announcing jumps, waiting for someone visibly left behind — none of those restraints exist when the roster is empty, and the person simply navigates at their own pace. For the follower, a persistent "following Zhang" badge makes it possible to attribute frame motion to "Zhang is moving" rather than "the document is changing on its own," and to know whom to ask when the view lurches. In multi-person settings, visibility also carries the topology: if A follows B and C follows A, the chain must be drawable, or the person in the middle never learns they are indirectly dragging a tail. Relationship visibility is also the followed party's informational bottom line — who is watching my viewport should at least be something I can look up, which is the same root as the general rule in collaborative tools that symmetric visibility of awareness information decides whether it reads as collaboration support or as surveillance.

Where it stops holding

"Visible to both sides" is not "broadcast to everyone." The circle entitled to know a follow relationship should be limited to the two parties; showing the whole group who follows whom (especially alongside presence indicators) turns neutral browsing into public alliance-making and attention-signaling, changing the social meaning of following. Visible granularity also decays with scale: a three-to-five-person session can list names, while a broadcast-style follow by dozens needs only a count with expand-on-demand.

Applying it

  • Keep a persistent "following <name>" status bar on the follower's side, with the detach control right next to it.
  • Show the follower list (small groups) or count (large groups) on the leader's side, and make recent detachments glanceable.
  • Where chained following exists (following another follower), mark upstream and downstream for every link so "whom I am dragging along" is never a blind spot.
  • Restrict knowledge of the relationship to the two parties: by default, do not show third parties who follows whom.
  • Verification: in usability tests, ask followers "why did the frame just move?" and leaders "who is following you right now?"; the share who cannot answer maps directly onto the visibility gap.

Related

  • Same group: V3.04.1 Follow mode replicates one person's viewport changes to everyone else · V3.04.2 Fast movement by the followed party disorients followers · V3.04.3 Following must be escapable at any time, returning to one's own place · V3.04.5 Shared viewing suits presentation, not parallel work
  • Nearby: V2.01 Presence Awareness · V2.09 The Boundary between Awareness Information and Surveillance
  • Search terms: mutual visibility · follow relationship · follower list · symmetric awareness

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/V3.04.4