Notifications panel: Easily explore bundled notifications
Closed, ResolvedPublic

Description

Allow users to explore the individual notifications contained in a bundle in order to allow users to triage and avoid being forced to mark all of them as read at once.

Design details

Bundled notifications provide a secondary "expand" action to allow users to access the individual items.

One-item bundles
Bundles are groups of similar notifications. Thus, it does not make sense to have a bundle of just one item.
This also means that as the items inside a bundle are marked as read, the bundle will turn into a regular notification once there is only one bundle item left. In order to avoid confusion, a transition can help to visually communicate that the bundle is replaced by the internal notification. I illustrated the idea below:

Unseen notification highlight
In order to provide a subtle indication about the new notifications users get (to distinguish them from the ones that remain unread), new notifications become briefly highlighted as soon the panel gets open.
The bundle may get highlighted if it contains new notifications since the last time the panel was opened. However, the individual notifications inside the bundle should not become highlighted when the bundle becomes expanded since the distraction can be higher than the value the highlight provides.

Related

For the specific case of cross-wiki notifications (T114350), a similar approach is followed to present multiple notifications. However, since cross-wiki notifications are very different to each other, several specific aspects are considered. So refer to the corresponding ticket for details on how the cross-wiki notification bundle work.

Related Objects

There are a very large number of changes, so older changes are hidden. Show Older Changes

Notes from talking through this with @MSchottlender-WMF:

  • When clicking a sub-notification, do we take the primary action (follow the link to the page) or do we expand the notification into full rendering (so the user can see the timestamp etc)? That would reduce the difference between what compressed and non-compressed notifications look like.
  • When you click the "X" for the bundle item (the parent of the subnotifications), what happens? Does it mark all of the subnotifications as read?
  • What appears in the dotdotdot menu for the bundle item? "Mark as read", perhaps?
  • How does bundling interact with the unread count? Is the bundle counted as 1, or is each subnotification counted separately? In other words, in your mockup, should the number displayed in the badge be 3 or 7?
  • How does bundling interact with seen-ness? If I view these notifications from the mockup, then close the popup, then someone links to "Rice" from another page, then I open the popup again, does the bundle get the "unseen" animation, or only the new subnotification?
    • The 3 vs 7 question above also influences how the badge would change in this event: it would either still say 3 but become colored instead of grey, or the number would increase from 7 to 8
  • How does bundling interact with the "mark as read when seen" nature of alerts? Does it makes sense to mark sub-notifications as read if the user didn't expand the bundle?

When clicking a sub-notification, do we take the primary action (follow the link to the page) or do we expand the notification into full rendering (so the user can see the timestamp etc)?

The sub-notifications are not supposed to expand. You can act on their main action by clicking on them and access any additional action they may have through the "..." menu (if it was a regular notification, some of their actions would be visible initially, but we want to present them in a more compact way here so we reduce the prominence of secondary actions).

Regarding the timestamp, I reviewed the designs to also include it in the compact notifications (and it make sense form what I saw in the testing sessions for cross-wiki notifications). I'll update the designs in this ticket. Meanwhile, you can check the case of the external notification bundle in this prototype.

When you click the "X" for the bundle item (the parent of the subnotifications), what happens? Does it mark all of the subnotifications as read?

Yes. Discarding the bundle marks all notifications as read. This aligns with the current behaviour, where bundles cannot be expanded.

What appears in the dotdotdot menu for the bundle item? "Mark as read", perhaps?

Some of the actions will be specific for the extension. I expect those to be similar to whatever they provide for individual items but applied for all items in the bundle. For example, let's imagine a notification like "Ludmilla linked Moai from Easter Island", that has some secondary actions like view the user page, and thank the user for her edit. Then, a bundled notification like "Moai was linked from Easter Island and 9 other pages" may include an action to thanks the authors of those 10 edits in a single go (while the individual notifications will allow you to thank users individually and visit their user page).
Other actions will be generic, but we have not decided them yet (it's ok if we start without an "...", or if it does not show automatically when it is empty). Some of the general actions we can consider include "mark as read" (we have the "X" but this will help to also provide the corresponding "mark as unread" for read items) and volume control which include a big range of possibilities (e.g., don't bundle this kind of notifications or don't get them at all) we need to select from.

The next iterations of design and research will include more examples and explorations of these kind of actions.

How does bundling interact with the unread count? Is the bundle counted as 1, or is each subnotification counted separately? In other words, in your mockup, should the number displayed in the badge be 3 or 7?

  1. The bundle is a group of closely related notifications, the counter counts individual notifications regardless of how they are grouped.

How does bundling interact with seen-ness? If I view these notifications from the mockup, then close the popup, then someone links to "Rice" from another page, then I open the popup again, does the bundle get the "unseen" animation, or only the new subnotification?

I think it makes sense to highlight the bundle to indicate that there is new activity on it. The bundle name is based on the information of the recent sub-notification (to anticipate information) so it will likely change. That is consistent on how the current non-expandable bundles work today.
The above makes especially sense when the bundle is presented as closed, for cases where the bundle is presented as expanded (e.., because it is the only item), it may make sense to only highlight the specific sub-notification.

How does bundling interact with the "mark as read when seen" nature of alerts? Does it makes sense to mark sub-notifications as read if the user didn't expand the bundle?

For contexts where notifications are automatically read, we may consider not bundling the notifications. If we expect alerts to be high priority items that users quickly consume them as they arrive, it may be preferred to have the detailed items without the need to interact with them to expand.

I'm not sure if there is any alert notification that we are currently presenting as a bundle. In addition, in case we do we are already marking the sub-notifications as read. The difference would be that we would provide more options to explore the individual items. So I don't see a problem with that.

However, my current thinking is to use bundles only for unread notifications (grouping closely related unread notifications together). When items are read they are added individually to the read section. Keeping bundles when notifications are read creates different kinds of inconsistencies (e.g, should a read notification become bundled with another that was read long time ago as part of a different bundle?). So for alerts it makes sense not to bundle notifications since they are going to get unbundled as soon as the panel is opened and they became read.

Pginer-WMF updated the task description. (Show Details)Oct 15 2015, 11:34 AM
Pginer-WMF updated the task description. (Show Details)Oct 16 2015, 4:04 PM

Yes. Discarding the bundle marks all notifications as read. This aligns with the current behaviour, where bundles cannot be expanded.

I don't think 'discard' is the best word for us to use here. It's not being discarded, just marked read.

I'm not sure if there is any alert notification that we are currently presenting as a bundle.

Just page-linked, as far as I know.

I have another question:

What happens if you click the bundle itself (not on 'Expand', just somewhere else)? Will it always navigate to a new page, sometimes, never?

I don't think 'discard' is the best word for us to use here. It's not being discarded, just marked read.

I agree. This is not terminology to be exposed to the user (where mark as read will be preferred). "Discard" was used to emphasise that the item was marked as read by using the "X" icon. We can just say that "Marking a bundle as read (by clicking it's "X") marks all the notifications contained in the bundle as read".

What happens if you click the bundle itself (not on 'Expand', just somewhere else)? Will it always navigate to a new page, sometimes, never?

My initial idea is to keep the same behaviour as we have now. Currently, a bundle of "10 new topics on talk:X" leads to "talk:X" page. The expandable bundle would do the same as the main action. It would just provide an additional option to expand and access the items individually, which is not possible now.
Here we are optimising to access the information quickly (assuming that for most users on most notifications, a summarised item is good enough for their needs), and leaving the detail access as a secondary option for more advanced users.
If that assumption is wrong (e.g., we find users trying to expand bundles and marking everything as read by accident), we can make the default action to become "expand" and add a secondary action for accessing the content.

Pginer-WMF updated the task description. (Show Details)Nov 17 2015, 1:38 PM
Restricted Application added a subscriber: StudiesWorld. · View Herald TranscriptNov 17 2015, 1:38 PM
Pginer-WMF updated the task description. (Show Details)Nov 19 2015, 12:24 PM

@MSchottlender-WMF I added details to the ticket about the questions you raised about "one-item bundles" and "unseen highlighting". Let me know if more clarifications are needed.

Jdforrester-WMF added a subscriber: Jdforrester-WMF.

For example, many "thanks" for the same edit ("Cronopio and 10 more thanked you for your edit on Moai") may be bundled. Bundling together "thanks" notifications from the same user ("Cronopio thanked you for your edits on "Moai" and 5 pages more") does not work as well in this case. So we may want to define more clear guidelines if there are none already.

Filed as T120152: Bundle "Thanks" notifications.

Still blocked by T120153: Change bundling system to allow individual treatment which is in its turn blocked by specific implementation tickets.

T114350: Notifications Panel: Support cross-wiki notifications addresses cross-wiki bundle notifications

On the backend, I think we need to have each presentation model calculate a "bundle hash", where things with the same hash should be bundled. The actual bundling can happen on the client side. We probably want to have the API make sure it returns a minimum amount of "bundles", i.e. if the first 25 events all belong to the same bundle, we'll only end up showing one item in the panel, so we might want to have the API do another query to meet a minimum number of bundles like 20? idk about that.

Change 272444 had a related patch set uploaded (by Catrope):
[WIP] Expandable bundles proof of concept

https://gerrit.wikimedia.org/r/272444

hashar awarded a token.Mar 2 2016, 8:08 PM

Change 272444 had a related patch set uploaded (by Catrope):
[WIP] Expandable bundles proof of concept

https://gerrit.wikimedia.org/r/272444

My general approach there seems to work (apart from some hacky parts that can be cleaned up), but there are some deeper issues.

It turns out that notifications with notification_bundle_base=0 are always marked as read, never as unread. That is to say, the read-ness of the entire bundle is tracked by the bundle base. For this feature, we want each non-base notification to have its own read-ness, which is probably easy-ish to do by not marking these as read when inserting them.

Did we decide what happens to a sub-notification when it's marked as read? Does it stay in the bundle, or does it detach from the bundle and become an individual notification? If the latter, we'd have to support that too (possibly by setting bundle_base back to 1 when marking as read).

Did we decide what happens to a sub-notification when it's marked as read? Does it stay in the bundle, or does it detach from the bundle and become an individual notification? If the latter, we'd have to support that too (possibly by setting bundle_base back to 1 when marking as read).

We are considering bundles as a group of unread notifications. As those notifications are marked as read, they are expected to no longer be part of the bundle. If one of those notifications is marked as unread again, it will group again with their similar ones inside the bundle.

I'm facing similar challenges in T93673: Remove Notifications about posts/topics that have been Moderated when moderating a notification that is part of a bundle.

The concept of bundle with bundle_base and bundle_display_hash makes sense for immutable bundles that effectively replace their individual constituents. In this case, we can probably get away with bundle_hash to represent what "can possibly be grouped together" and apply grouping when we fetch the data.

I don't know about the technical details, but dealing with bundle at the display level seems to provide some flexibility that can be beneficial for different cases (e.g., how bundled items may be displayed in the Notification Page and affected by filters, if we need to keep immutable bundles for some specific kinds of notifications, etc.).

Catrope added a comment.EditedApr 12 2016, 11:05 PM

Today Stephane and I discussed his patch for T93673/T120153, which addresses a lot of the backend problems. With his patch, bundled notifications can be marked as read individually, moderated/suppressed individually, and are counted in the notification counts. There may be some transition pain around notification counts (we may render counts that include bundled notifications before expandable bundles are done), but otherwise this looks good. We do still need to do T127813 which will be a bit of work.

One interesting question that came up: what should happen to bundled notifications when they're being viewed from a different wiki as cross-wiki notifications? Should we have nested bundles? Should we not bundle at all in this case? Something else? @jmatazzoni , @Pginer-WMF : ideas?

Pginer-WMF added a comment.EditedApr 13 2016, 7:39 AM

One interesting question that came up: what should happen to bundled notifications when they're being viewed from a different wiki as cross-wiki notifications? Should we have nested bundles? Should we not bundle at all in this case? Something else?

We should not have nested bundles.

When inside an cross-wiki bundle, presenting the bundle as a single non-expandable item (as we currently do) seems the best option to me. That is, if a user got 5 replies in a discussion from a different wiki, an "5 new replies" item will be shown inside the cross-wiki bundle (not 5 different items).

This provides a good enough summary of the activity without crowding the cross-wiki bundle with "repeated" items. The purpose of the notification panel is to support a quick overview, users can always access the local wiki if more detailed manipulation is needed.

Change 272444 abandoned by Catrope:
[WIP] Expandable bundles proof of concept

https://gerrit.wikimedia.org/r/272444

Change 293504 had a related patch set uploaded (by Sbisson):
[WIP] Expandable bundle

https://gerrit.wikimedia.org/r/293504

Change 293505 had a related patch set uploaded (by Sbisson):
Make notifications expandable

https://gerrit.wikimedia.org/r/293505

SBisson claimed this task.Jun 9 2016, 5:55 PM

Right now, a bundle about new topics in a board only shows the topic names:

I think we should display the user name that added the topic too.

Moriel observes that:

Right now, a bundle about new topics in a board only shows the topic names:

That is the correct language, according to T127813, which lists:

Flow-new-topic

  • Bundle: 5 new topics created on Moai.
  • Bundled message: "How the Moai moved?" [topic name]

I suppose we could change to:

Flow-new-topic

  • Bundle: 5 new topics created on Moai.
  • Bundled message: Ludmilla created "How the Moai moved?" [topic name]

But remember that topic names tend to be longer than the examples above, so adding the verbiage would likely increase wrapping (or does the message truncate?). And there is a certain simplicity to just listing the new topic names. And, of course, it's done ;-)

Does anyone have an opinion? @Pginer-WMF? @Quiddity?

I think it's also a matter of consistency.

"Ludmilla replied to [TOPIC]"

has the same issues of length as

"Ludmilla created [TOPIC]"

And we seem to use the first one for replies, so it seems to me to be more consistent to do the same for new topics, even just for that similarity.

On top of that, I also think that the username that created a topic is valuable enough to include it in the message.

Moriel wrote:

I think it's also a matter of consistency. "Ludmilla replied to [TOPIC]" has the same issues of length as "Ludmilla created [TOPIC]"

But according to T127813, that's not then message for bundled replies, which read:

Flow-post-reply
Bundled message: Ludmilla: “I don't think sails were used…” [excerpt]

Consistency aside, if people think the username is vital, then we can change this. Folks?

SBisson added a comment.EditedJun 16 2016, 9:11 PM

I think it's also a matter of consistency.

"Ludmilla replied to [TOPIC]"

That's not exactly how we do flow-reply. We include the actual text of the response, not the topic title to which they responded. (Ludmilla: "I think we should do X")

For new topics created on a board I'm following, the name of the user can be important but it don't know if it's worth sacrificing part of the topic title. I think consistency is generally less important than having the right information in the right context.

I agree with @SBisson.

For new topics, I think the most useful thing is to have a list of the topics (as a table of contents). Additional information may be relevant in some cases, but I don't think it's worth the effort of scanning through it most of the time.

For conversations you participated in, the user becomes more relevant.
While topic titles should be self-descriptive on the topic they are about, replies (e.g., "Yes! You are right.") require more context and the user is more likely to be relevant (e.g., is the user I replied to before?) to understand what they are about.

This will be deployed at the same schedule as T123018#2394112 --> User-notice

Change 293504 merged by jenkins-bot:
Expandable bundle

https://gerrit.wikimedia.org/r/293504

Change 293505 merged by jenkins-bot:
Make notifications expandable

https://gerrit.wikimedia.org/r/293505

Checked in betalabs along with T120153: Change bundling system to allow individual treatment

The screenshot shows bundled types of messages:

The same bundled messages displayed in a foreign wiki:


To follow up the discussion about presenting only topics in bundled new topics notifications, the longer topics look fine and correctly truncated.

The only thing that deviates from the specs - if one of the bundled notifications is 'Marked as read' in the flyout, it does not move away immediately. The flyout should be closed for changes to take place.

Unbundled notifications when being marked as read/unread, make their move immediately.

jmatazzoni closed this task as Resolved.Jul 5 2016, 11:08 PM