[Request]: compact / concise notifications

[dilinger]

Describe the request

Currently every like or boost or follow gets the entire post listed in a notification. Having a popular toot easily overwhelms notifications. Elk.zone solves this by combining likes/boosts for the same toot, and also doesn't display images for ones own toots, like so:

Quite a difference compared to Tuba:

I would suggest two things:

1. Don't display images when a user's own toot is boosted/liked. I wrote the toot, I know the content, I don't need my notifications filled with the same image(s) over and over. I'd suggest still continuing to display images for other circumstances (eg, someone replies with an image); just not for toots authored by the main user.

2. Combine multiple likes and boots for the same toot into one notification entry. It doesn't have to be fancy (like, I wouldn't try and combine them out-of-order or anything; if 3 people boost Toot A, then someone boosts Toot B, and then another person boosts Toot A, there's no need to show Toot A with 4 boots in the same entry; just showing a notification timeline of "3 boosts for A, 1 boost for B, and 1 boost for A" would be a huge improvement). It could be as simple as something like the following, which I just mocked up (somewhat awkwardly) in gimp:

I'm unsure if this should be an option in settings or just the default. I dislike Elk's super-concise notifications (I do want to see the names of people who boosted/liked, not just tiny profile pic images). But I think if the same information were retained while also removing redundant stuff (so implementing the suggestion to combine notifications, while not implementing the suggestion to not display images), there would be no need for a settings option.

Implementation Details

• This should be an option in settings.
• This should be only available to some fediverse backends. (Include which ones on the above field).
• This is client-only (and shouldn't sync with the instance).
• This follows the GNOME HIG.

[nekohayo]

I think that instead of stacking up the usernames, it should try to list them in a string (or little avatars with hover tooltips, like in your screenshot from Elk) up to a handful (five?) on one line showing the latest 5 ones, and stuff all the rest into a ", and %d others." count string... And then offer the ability to inspect the detailed list in a separate window by clicking some meatballs menu on that notification, a bit like the ability to inspect the list of favorites/boosts when viewing an individual post outside the notifications view.

[dilinger]

I do like the idea of having some kind of expansion menu or tree. It could be as simple as something like "[+] 4 people liked this", and then you click the [+] and you get a more detailed list of the four people who liked it.

That said I'm not a UX expert, nor am I super familiar w/ GNOME's HIG. There's lots of different ways to implement this kind of change.

[GeopJr]

Main blocker for this is that I am not sure how this should work.

For example if the timeline is:

• boost
• reply
• reply
• group of 3 favs

and another fav comes in, how should it be grouped?

• fav
• boost
• reply
• reply
• group of 3 favs

or

• group of 4 favs
• boost
• reply
• reply

If it's the second one, how deep should it go until we make another group?

Other questions might arise when implementing it too

[nekohayo]

I think the way most other implementations / social networks do it is, they use the replies as "separators" between group sets. Within each group set, both boost and favs are grouped within a single listview row item, like what you see at the top of the 1st screenshot by OP above; i.e. within the row, you have a line with all the booster avatars and a line with all the favs' avatars. If a reply comes in afterwards, it "breaks" the grouping and any further boosts/favs will create a new group above the reply... so in your examples, it becomes:

State 1:

• group containing a single boost for now (and any future boosts and favs)
• reply
• reply
• group of 3 favs

State 2:

• modified group containing: 1 boost, + the new fav
• reply
• reply
• group of 3 favs

State 3:

• modified group containing: 1 boost, + the 4 new favs
• reply
• reply
• group of 3 favs

how deep should it go until we make another group?

My hunch is: "until there is a new reply, or notifications from another* toot"...

*: It might be possible to add some extra smarts about this, and "juggle" two (or more) top-pinned groups that are not "broken" by replies...

That is, if you care about preserving the chronology of notifications of course. If chronology doesn't matter, the ordering of things (group sets vs replies) could shift dynamically...

[GeopJr]

Some edge cases to consider:

For context, timelines are pagination based, you get the next page when you go to the end.

What if everything is just favs/boosts? do we just spam the server forever until we reach a reply - which we might never do? how long do we search for?/if you made a post a year ago and now it got viral again, when do we stop searching?

Maybe do grouping only on the first page?

[GeopJr]

Other interesting reads:

mastodon/mastodon#1483 (Danielle suggested it 7 years ago!)
mastodon/mastodon-android#160
mastodon/mastodon#11446

[GeopJr]

We are working on improving notifications in 4.3, and this includes notifications grouping. This will most likely be done server-side.

mastodon/mastodon#1483 (comment)

Honestly, the best solution. Should wait for it!

[Baralheia]

We are working on improving notifications in 4.3, and this includes notifications grouping. This will most likely be done server-side.

mastodon/mastodon#1483 (comment)

Honestly, the best solution. Should wait for it!

Now that Mastodon 4.3 is here with the new native grouped notifications api, are there any plans for implementing this in Tuba?

[GeopJr]

Yes #1193