Presence

Problem Context

• Users are deciding whether to message, call, assign, review, wait, join, follow up, or interpret another person's current availability in a workspace, document, channel, dashboard, issue, or task.
• Presence may be calculated from app activity, device activity, calendar events, active calls, focus time, working hours, manual overrides, notification pause, file views, or current co-viewing sessions.
• The signal may be delayed, stale, privacy-limited, hidden for external users, unknown, or suppressed by user preference, admin setting, domain boundary, or object permission.
• Presence may affect actions such as call routing, notification delivery, assignment timing, follow-up reminders, co-editing awareness, and escalation paths, but it is not automatically an audit record.

Selection Rules

• Choose presence when the user needs a transient availability, co-attendance, last-seen, or active-viewer signal attached to a person, group, file, channel, task, or conversation.
• Use mentions when the task is to address or notify someone inside authored content; mentions can consult presence but they create an attention event rather than display availability.
• Use notification center when the user needs retained inbox triage, unread state, preference controls, and notification history across objects.
• Use activity log when the product must preserve durable evidence of who viewed, changed, routed, or was notified about something.
• Use comments or threaded discussion when the collaboration unit is authored conversation; presence can show who is reading or available but should not replace conversation state.
• Use profile setup for stable identity and work details; presence should only show time-bound state, recency, and availability source.
• Use settings management for configuring status defaults, working hours, privacy visibility, external sharing, and notification behavior.
• Show restricted, unknown, stale, or hidden presence states instead of guessing when privacy, domain, permission, stale sync, or API limits prevent a reliable signal.

Required States

• Available, active, away, busy, in a meeting, in a call, presenting, focusing, do not disturb, out of office, offline, unknown, and hidden states where supported.
• Manual status, automatic status, status duration, status message, working-hours state, paused-notification state, and calendar-derived state.
• Fresh, stale, reconnecting, delayed, last-updated, last-seen, and source-unavailable states.
• Single-person presence, group summary, co-viewer list, anonymous viewer, external viewer hidden, same-domain activity visible, and privacy-restricted states.
• Action-aware states such as call available, call blocked, message allowed, banner suppressed, notify when available, route to next available, and follow-up scheduled.
• Mobile condensed badge, expanded presence detail, tooltip or popover detail, accessible text label, and screen-reader-only state summary.
• Permission denied, external access hidden, user view-history hidden, admin privacy mode enabled, and activity-dashboard-not-audit states.
• Presence conflict, multiple devices, manual override, automatic reset, and presence unknown fallback states.

Interaction Contract

• Presence badges identify the person or group, status label, recency, and source in text, not color alone.
• Selecting or focusing a presence indicator reveals more detail such as status message, last updated time, working-hours note, privacy reason, current object viewers, or action options.
• Actions that depend on presence respect do-not-disturb, busy, offline, privacy, and priority rules; they explain whether messages, calls, banners, or routing will behave differently.
• Stale or delayed presence values show last updated time and fallback behavior rather than staying visually equivalent to live status.
• Privacy settings, external access rules, hidden view history, and domain restrictions are honored before showing viewer names, last-seen times, or status details.
• Presence changes update without moving focus, stealing attention, or rewriting user intent; screen-reader users receive concise state changes only when relevant.
• If presence is used for routing, escalation, or assignment, the system records the actual decision event separately from the transient presence value.

Implementation Checklist

• Define presence states, source priority, stale thresholds, privacy boundaries, external sharing rules, status duration, user override behavior, and action implications before drawing badges.
• Design badge, label, expanded detail, co-viewer list, unknown state, hidden state, stale state, and action affordances for desktop, mobile, keyboard, and screen-reader access.
• Map presence to actions such as call, message, notify later, route, assign, join, or wait without assuming every available-looking person can be interrupted.
• Show status freshness and source when the value comes from calendar, device activity, manual override, co-viewing, file activity, or API updates.
• Respect privacy controls for view history, external access, same-domain limits, hidden users, anonymous users, and admin privacy mode.
• Test delayed updates, multiple devices, manual overrides, do-not-disturb, out-of-office, offline fallback, anonymous viewers, hidden activity, and stale API data.

Common Generated-UI Mistakes

• Using only color dots without text labels, source, or recency.
• Treating presence as employee monitoring or audit evidence.
• Leaving stale active states on screen after disconnects or sync failures.
• Ignoring do-not-disturb, busy, call, meeting, or priority rules when offering interruptive actions.
• Showing viewer names or last-seen times across privacy, domain, guest, or external organization boundaries.
• Conflating presence with unread notifications, mentions, assignments, comments, or activity history.
• Hiding unknown or restricted presence and making users think nobody is present.
• Letting presence animations distract from the primary task or cause layout shifts.

Critique Questions

• What exact person, group, file, channel, task, or object does this presence signal describe?
• What status is shown in text, and when was it last updated?
• Is the signal automatic, manual, calendar-derived, device-derived, activity-derived, or co-viewing-derived?
• What privacy setting, external access rule, or permission boundary controls whether the signal is visible?
• Which actions change when the person is busy, in do-not-disturb, offline, away, or unknown?
• Can users tell the difference between live presence, last-seen activity, file view history, and audit history?