Epic: Activity feed

[chillu]

Overview

While we have the ability to view individual histories of objects, there's no way to see them in context - e.g. identify why a content block was marked as changed, when in reality it's an image contained in the content block that has changed. This story was split out from General purpose history viewer

This card is an epic, please use the Zenhub.com browser extension to see related cards.

Notes

• Designs https://projects.invisionapp.com/dsm/silver-stripe/silver-stripe/folder/components/5c68f96ffb26bb0018525d20

[chillu]

@clarkepaul There's already a card for activity feeds - can you please put it into the UX backlog?

@tractorcow or @unclecheese Can you please have a think about the feasibility of creating a "flattened" activity feed as described above, in terms of database schema and ORM performance?

[chillu]

Some of my comments from a conversation with Sam around #110:

Regarding activity feed, you can only base it on ChangeSet data when you do cascading publish (creating one changeset). If you allow owned/related objects in the graph to be published separately, it all falls apart

For me, the main purpose of activity feeds is to describe what unpublished edits have happened since that particular record (usually a page) was last published. Without drilling into a dozen owned/related object views and their respective histories. So in that context, changesets don’t actually matter too much since they won’t even exist for those draft change.

Then there’s the separate purpose of viewing a flattened history of the whole object graph, where the concern above would become relevant. I think that’s a much lower priority though.

[newleeland]

Potential Activity feed design

Existing AC's (with alterations)

• If the viewed page has versioned dependants, these are displayed with a summary of changes (saves) since last published
• I can easily navigate into history views for versioned dependants I can view the difference between the changes and the last published record (live)
• The summary of changes is displayed in page editing context to give authors a quick overview
• Each list item relates to a single record
• Changes don't need to be published to be listed
• All changes are listed regardless of nesting level Nested changes give context on where they are located
• All changes are sorted descending by date
• The list can be paginated The list can scroll
• The record for the activity as well as actions taken (delete, edit, etc) are clear
• It's clear which point in the feed is currently published for the page record (and what later draft changes are)
• Changes include changes to relationships i.e. Added (link), Removed (unlink)

Potential additional AC's

• User can see who and when changes were made
• Activity information shown is intuitive for the user to easily identify how and where an item has changed
  • Page changes action + Label name (~Edited URL segment)
  • File changes action, Type of item, Filename (-Removed image "Hero.jpg")
  • Block changes Action, Type of item, Block name (~Added Block "Hero banner")
  • Gridfield changes Action, Item name, Gridfield name (~Added "John" to "Staff" )

Notes

• There are few way to show an item is "taken out" from a page, Archived, Removed (e.g. file) and Deleted (which is a fallback).

[clarkepaul]

AC's "The list can be paginated"

In the designed UI having a scroll within the popover makes more sense.

It's clear which point in the feed is currently published for the page record (and what later draft changes are)

On top of this I think it only makes sense to show changes since it was last published (not a complete history, would be good to capture that in the AC's

[chillu]

Aside: This is somewhat related to showing block content when searching for page content: silverstripe/silverstripe-elemental#189 (comment). For activity feed, we want to denormalise an object graph (or make them easily queryable), for block search we want to denormalise the content itself.

[chillu]

This is getting traction again through the underlying data model discussions on #195

[chillu]

@newleeland @clarkepaul There's different ways in which a user might want to find out what has changed.

1. All changes since last login (across pages)
2. Draft changes compared to current live version, while viewing page
3. Changes contained in a specific version (history view)
4. Changes contained between two selected versions (in history view)
5. Draft changes compared to current live version, while listing page (e.g. in tree or search results)

Could you have a think on how these variations would be implemented? Variation 1 requires some sort of dashboard landing page in the CMS, but I'd want us to ensure what we're building here works for as many variations as possible. Variation 3 is quite relevant for blocks sites with multiple authors. Variation 5 one is a bit of an edge case, but we could fairly easily implement this anywhere we have a "modified" indicator (e.g. tree, assets section). Might be worthwhile as an advanced feature? Would fit the existing popover designs.

[clarkepaul]

pt1. This would be the global activity feed, we are doing some experimental designs for this shortly as part of a bigger set of work.
pt2. Thats this issue, although it isn't a visual indication.
pt3. This is already achievable when you compare with a previous version so not sure how pressing this one would be. We could do some visual indications like a "NEW", "UPDATED" tag by field labels, which would work for pt.2 as well although I think it might add some clutter to the UI.
pt4. My proposed UI for this is that the user can expand a draft page in the history list, to see the activity which has gone into that version (e.g. content block updates). This would be the same info from a page activity. We can provide a quick mockup for this.

[chillu]

pt3. This is already achievable when you compare with a previous version so not sure how pressing this one would be.

It doesn't roll up changes on deep ownership graphs, you have to click through individual diff screens on each owned object to get an idea. That's quite different from what's discussed here (and less useful). In the end, when you're an author looking at a list of versions on a record, the intent is to understand what happened in that version. If this involves changes in a deep ownership graph, it should still be easy to discover that, right?

pt4. My proposed UI for this is that the user can expand a draft page in the history list, to see the activity which has gone into that version

This scenario is aimed at comparing two arbitrary versions, with changes on all intermediate versions rolled up into that list. I don't see how that can be achieved by expanding a draft page in the history list?

[clarkepaul]

For pt4 I'm thinking something along the lines of this, fYI this is just screenshots chucked together so not exactly what I'm proposing but should give you an idea (swap out page edits for block edits). The child changes could potentially link to individual history. So pretty much the same as the activity feed.

Image updated at top of page

[ScopeyNZ]

Should we move this issue to versioned-admin?

[chillu]

@silverstripeux I've isolated out a card for the version history viewer. For now, the ACs are limited to showing snapshots in the same way as versions (not in inlined activity feed items), to get a first cut over the line quickly. We'll show the activity feed inside the version detail form instead. No mention of grouping etc, just a rough first cut. Doesn't replace this card, just a step towards it.

[chillu]

@silverstripeux When you compare a version and a snapshot (or a snapshot with another snapshot), they have activity feed items which are relevant to the comparison, just as much as the actual comparison between the field contents on the record. Do you want to have a crack at designing this into the comparison view?

[clarkepaul]

Yup would be keen @chillu

[ScopeyNZ]

Not sure where to capture this suggestion:

It would be nice to have API to add events to the activity feed. At the moment entries are calculated from changes to owned version objects - and the only events that are shown (given the feed is shown "since last publish") are saves. It would be great if we could include "Copied to [fluent locale]" as an event in the feed. I assume bespoke projects may like to indicate other things in the feed too.

[clarkepaul]

Could include new member added to CMS, or site settings updates too.

[chillu]

It would be nice to have API to add events to the activity feed

Good idea, although unless it's exposed as a VersionSnapshot data model, it'll be hard to weave that into the existing structures. We can add a Comment on a snapshot, but it would need to tie to a specific record. In that way, it's different from an unstructured event stream. We could layer such a thing on top of versioned and versioned snapshots, but I'll let you write a performant UNION query for it then ;)

[dnsl48]

VersionedSnapshots isn't the best candidate for such extensions. Ideally it would be a separate "ActivityFeed" component which peeks into snapshots and other custom events and then generates a common event feed.

Currently every snapshot can be considered as some extra metadata for a version and it always implies a new version of something owned has been created. There's 1to1 relationship between a version and a snapshot. If we want to show something else, which doesn't belong to the activity feed owner or doesn't have a version, then we shouldn't tie it to the snapshots functionality.