Activity feed

Problem Context

• Events may come from people, channels, repositories, projects, tasks, apps, bots, automations, meetings, reminders, comments, mentions, reactions, shares, merges, deployments, assignments, or approvals.
• Users open the feed to catch up, triage, scan, reply, clear, mark read, filter, jump to source objects, or personalize which activity types deserve attention.
• Events may be personal to the user, workspace-wide, organization-scoped, repository-scoped, channel-scoped, object-scoped, or app-generated.
• The surface may overlap with notification center, feed, timeline, activity log, comments, mentions, presence, and following/subscription behavior, so event ownership and lifecycle rules must be explicit.

Selection Rules

• Choose activity feed when the primary task is catching up on recent collaboration or system activity across work objects rather than reading broad content or managing audit evidence.
• Use feed when the stream is primarily article-like posts, stories, media, recommendations, or content consumption.
• Use notification center when the item lifecycle depends on unseen badges, unread state, mark-read, preferences, cleanup, and retained notification history.
• Use activity log when users need searchable, exportable, retained evidence of actor/action/object records with compliance or investigation detail.
• Use timeline when the user needs a bounded chronological history for one case, process, project, object, or order.
• Use comments, mentions, and threaded discussion for the underlying conversation; activity feed should preview and route to them rather than becoming the conversation system.
• Use presence for current online, viewing, typing, or availability state; only surface presence in activity feed when it becomes a meaningful event such as joined, assigned, or started presenting.
• Include actor, verb, object, source, timestamp, event type, preview, scope, and destination before adding visual density or ranking controls.
• Offer filters for meaningful activity types such as unread, mentions, replies, reactions, channel activity, app events, reminders, repository events, and cleared items.
• Suppress, group, or collapse noisy repeated events such as many reactions, automated sync churn, duplicate app posts, cursor movement, and frequent status changes.

Required States

• Default feed state with actor, verb, object, timestamp, source, type icon, preview, scope, and destination for each activity item.
• Unread, read, cleared, selected, replied, opened, muted, hidden, grouped, collapsed, and expanded item states.
• Filters for all activity, unread, mentions, replies, reactions, channel or project activity, app events, reminders, repository events, and cleared items where supported.
• Dense layout, detailed layout, custom saved view, and mobile compact states.
• New activity waiting, live refresh paused, refresh failed, stale feed, offline, loading, empty, no matching filter, and retention-expired states.
• Inline reply, open in source, set reminder, mute thread, turn off noisy type, mark all read, clear one, clear selected, and restore cleared states.
• Grouped repeated activity, bot activity, external app activity, VIP or priority activity, private/no-disclosure activity, and permission-limited activity states.
• Synchronization state with notification center so cleared, read, and opened events do not contradict the badge or inbox.
• Responsive state where actor, verb, object, type, timestamp, and action destination remain readable.

Interaction Contract

• Each item represents one meaningful work activity or a grouped set with stable actor, action, object, source, timestamp, type, preview, scope, and destination.
• Opening an activity routes to the underlying channel, message, thread, repository, task, meeting, app, file, or object and updates read or cleared state according to product policy.
• Reply, clear, mark read, set reminder, mute, and open-source actions apply to the named activity item or group only.
• Filters change visible items without deleting events; clear and mark-read actions provide immediate feedback and preserve recoverability where supported.
• Dense and detailed layouts preserve the same activity identity and actions, only changing how much preview context is shown.
• Saved views preserve filter combinations and do not silently change notification eligibility or underlying subscription settings.
• Activity feed state synchronizes with notification center, mention surfaces, thread views, and related-object state when the same event appears in multiple places.
• No-disclosure and permission-limited events hide restricted object names, previews, or actors while still explaining why the item cannot be opened.

Implementation Checklist

• Define event schema for actor, actor type, verb, object, object type, source app, workspace, channel or project, timestamp, event type, preview, destination URL, read state, clear state, priority, grouping key, and retention.
• Separate activity-feed records from notification records, audit-log records, timeline milestones, comments, mentions, reactions, presence heartbeats, and broad content feed items in the data model.
• Build activity-type filters, unread filter, cleared filter, source filter, custom saved views, dense/detail toggle, mark-read, clear, bulk clear, inline reply, reminder, mute, and open-source actions.
• Group repeated reactions, bot updates, deployment churn, bulk repository events, and high-volume channel posts without hiding high-priority mentions or failures.
• Model retention and expiry, stale feed refresh, offline fallback, permission-limited destinations, deleted objects, private channels, blocked users, and external app failures.
• Synchronize activity state with notification center, thread views, mentions, related object pages, and preferences so items do not reappear unexpectedly.
• Test mobile compact layout, keyboard navigation, screen-reader item names, long actor names, localization of actor-verb-object text, grouped event expansion, filter empty states, and deep-link return behavior.

Common Generated-UI Mistakes

• Using activity feed as an audit log without evidence fields, export, or retention guarantees.
• Using activity feed as a notification center without clear unread, badge, preference, or cleanup semantics.
• Dumping every low-level system event, presence update, typing event, or cursor movement into the feed.
• Hiding actor, object, event type, source app, or timestamp until users open the item.
• Making clear, reply, or mute actions affect a thread or channel different from the visible item.
• Mixing algorithmic content recommendations with work events without labels.
• Letting private or permission-limited activity reveal object titles, channel names, or actors.
• Providing filters that only hide items visually while badge and saved-view state still count them.

Critique Questions

• What events are meaningful enough for catch-up, and which belong only in audit logs, notifications, comments, or live presence?
• Can users tell who did what, to which object, in which source, and when?
• Which activity types can users filter, clear, mark read, mute, or save as views?
• What happens when the user opens the underlying object from another route?
• How are repeated reactions, bot events, deployment churn, and noisy app updates grouped or suppressed?
• Which items expire from the activity feed, and where can users find durable evidence afterward?
• How are permission-limited or private-channel events represented without leaking restricted context?