GeopJr / Tuba

Browse the Fediverse
https://tuba.geopjr.dev/
GNU General Public License v3.0
506 stars 55 forks source link

[Request]: compact / concise notifications #176

Open dilinger opened 1 year ago

dilinger commented 1 year ago

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:

image

Quite a difference compared to Tuba:

image

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:

Untitled

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

nekohayo commented 11 months ago

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 commented 11 months ago

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 commented 4 months ago

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

For example if the timeline is:

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

or

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 commented 4 months ago

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:

State 2:

State 3:

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 commented 4 months ago

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 commented 4 months ago

Other interesting reads:

https://github.com/mastodon/mastodon/issues/1483 (Danielle suggested it 7 years ago!) https://github.com/mastodon/mastodon-android/issues/160 https://github.com/mastodon/mastodon/pull/11446

GeopJr commented 4 months ago

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

https://github.com/mastodon/mastodon/issues/1483#issuecomment-1837488217

Honestly, the best solution. Should wait for it!