Feature: UX Improvments to Notifications

[nickytonline]

Type of feature

🎨 Style

Current behavior

I put this under style, but it's more of a UX improvement.

Notifications work well, but one thing I noticed when someone posts several highlights is it's just noise as the notifications say the same thing.

For example in this screen shot, user CBID2 posted seven highlights, but the notification message is the same.

Suggested solution

I'm wondering if we could group them to say e.g. user CBID2 posted seven highlights, or surface more information about the specific highlight like the the title of the highlight or the associated PR/issue for the highlight so that highlights are less generic.

It may also encourage people to click on the hihglight if there is more context about the highlight.

Additional context

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

Contributing Docs

• I agree to follow this project's Contribution Docs

[takanome-dev]

I like your suggestion, @nickytonline
I tried grouping the notifs by user to see how that would works, see screenshot

I think we can do something like that, will try to add visuals later.

Other ideas and suggestions are welcomed 🙏

[babblebey]

I think we can take some cue from the concept of "Notification Aggregation", group notification of events that happens around close time range into one.

I remember hearing a talk in this regard during a session at OSCAFest'23 from a speaker at Novu

We can have a grouped notification like:

CBID2 & 4 Others Created new highlights

...and Onlick this take user to the /feed routes following tab.

[dev-phantom]

Instead of the somewhat lengthy CBID2 & 4 Others Created new highlights ,we can present notifications like this: CBID2 Created 4 new highlights. This approach offers several advantages:

1. Clarity: Users instantly know who performed the action (CBID2) and what they did (created 4 new highlights). There's no need to click or expand for more details.
2. Efficiency: It saves users time. They can quickly understand the notification's meaning without additional steps.
3. Reduced Clutter: Notifications are concise and to the point, which can make the notification feed less overwhelming.
4. Consistency: It establishes a consistent and user-friendly format for notifications, enhancing the overall user experience.

[takanome-dev]

cc @isabensusan, thoughts on this?

[nickytonline]

As part of my onboarding, I'll be working on this.

.take

[nickytonline]

For this issue @isabensusan. I'm thinking a first pass would be to add more context to the highlight.

Instead of

Something like this with the title or the type of highlight if no title present, although I do have to see if we surface any info about the highlight aside from the URL.

A second pass at this could be potentially grouping them, but I think if there is more context in each highlight notification, that should be good.

dev.to (I am biased 😅) have more like mini embeds of content in the notifications which I do like, but I think for now at least, that's probably too much info since we're only surfacing highlights at the moment in notifications.

Thoughts?

[isabensusan]

Hey @nickytonline ! Thanks for this, I like the approach of gradually adding more context to the notification, starting with adding the highlight type to the notification. In the future we could add a preview snippet as well, the same way dev.to handles it.

As a second part of this update, I'd take a look at adding some sort of notification control where we let users decide what they want or don't want to see as notifications. I'll create a new issue for that and mention this one.