so I’m currently working on allowing to define different strategies for grouping notifications: the idea being that right now there’s only one algorithm for grouping notifications, but users might want to use different type of algorithm depending on the output (e.g. different kind of grouping for email notif) and developers might want to be able to provide their own algorithm for their specific usecases (e.g. being able to specify that a custom event is always kept separated).
The problem I have now is that since those grouping strategies might change dynamically, it might lead to some inconsistency with the way we display the number of unread events. For example: right now, we always display by default grouped events (by type and doc), so if I have two events about an edition of the same doc they would appear grouped together and the counter will display 1 unread event.
Now let’s say we change in the future the way to group those events: they could appear as two separated events, so I would have 2 unread events.
So in order to always keep the consistency of the number of unread events, I’m thinking about changing its behaviour so that the number always consider the individual events, and never the group of events.
So in my example above it would always display 2 unread events, even when the events are shown grouped.
One side effect advantage of this, is that it would allow to mark a single specific event as read, instead of having to mark the whole group as read.
We’d probably need to be more explicit on the number of events a grouped event contain, so that it’s more clear for the users when they see the number of unread events, but that’s probably a good direction to go to IMO.
wdyt?
[Edit: to be a bit more clear, I mean having this kind of UI (extracted from a test so that explains the difference in terms of icon style):]
I may have read the proposal too quickly but, if I understand correctly, the groups will still be collapsed by default, right?
Thus, for the image you sent, the user would see 3 in the bubble, but when clicking on the bell, they would see 2 items:
Linux as a title commented by
Linux as a tittle edited by
This may look like a bug more than anything, especially as the function to unfold a groups is really hidden and anybody hardly uses it.
This is because the current grouping strategy has as a main purpose to palliate the fact that we don’t store an ‘editing session’ of a user (that may contain multiple saves) as a single event, but as multiple events, and so we use this grouping as a way to hide that away, and we make it rather ‘hard’ for the user to see the events in a group, because nobody actually cares about them.
I assume that your new grouping strategies may have more of a semantic purpose than this.
I’m not against changing the global displayed number, but we should probably also work on the groups display in order to bring forward the grouped events.
For example, for this standard grouping, I guess it may be enough to display, in the title of the group, the number of events from the group: “Linux as a title edited twice by NotificationsITuser1”, so that the global count is coherent with what the user reads in the list of groups…
I agree with Anca. We need the counter number to match what the user sees in the notifications pane (and right now it doesn’t match: 3 events on the bell but only 2 listed). If there could be “1” displayed in inside a red circle for the first event and “2” for the second one, then it would match. I’m not sure if just mentioning “Linux as a title edited twice by NotificationsITuser1” would be enough as you need to read it and to parse “twice” into 2 and realize we’re talking about events. Having the same kind of visual would help IMO.
One idea would be to say:
“commented (1) time by”
“edited (3) times by”
where (...) represents a bubble with the number in it.
Not 100% sure about it but that’s probably an idea to consider.
