UX about notifications

#1

I want to use this topic to collect some insights into UX best practices around notifications. Not all are on top of my head, so I will add replies when I remember the sources.

@aschrijver mentioned the other day, that

Matrix is a context-switching training apparatus.

That got me thinking. I know, that notifications can be bad, i.e. cause stress:

I originally answered, that by design (even though perhaps not intended), a lack of customisation for colour, typography or layout makes it harder to recall, where something was mentioned. You perhaps remember from school day, that a certain fact was written on the right page of a book in the lower third part. But on apps everything looks the same. A good UX would allow some level of customisation. For example, Threema allows to define a background image to chat rooms.

@Gusted pointed to keyboard shortcuts on Discord, that allows to traverse easily between mentions. That allows for a quick catchup (with context) but requires recalling a hidden feature: the keyboard shortcut itself.

1 Like
#2

Something I feel bothered about with GitHub notifications, but could be generalised is this:

In GitHub I receive notifications for repositories I follow. I can adjust it to a certain degree, but it’s not fulfilling the needs I have.

Let’s say, I’m interested in PRs. But only those of a selected number of people (just look at mdn/content to see a vibrant repository). Imagine, that the code was broken up into smaller ownerships (CODEOWNERS) help only so far. Or I can’t stand certain people / have a few favourites, whatever. I can’t filter my notifications further. I could perhaps define e-mail filters and operate that way.

Or perhaps I don’t want to receive PR notifications of someone, because that person has the tendency to flood my inbox with many small ones / comments a lot.

There could be many reasons to offer a notification filter based on people instead of organisations.

2 Likes
#3

I recently just eliminated some repos too cut down on having to manually delete email notifications from some projects.

Foundkey was one in particular where the signal to noise ratio just wasn’t productive trying to follow, so the same problem exists with Gitea for me.

In GitHub, I ended up forking some projects, as a reminder that i want to follow those repos. I can see them and periodically visit the upstream, otherwise i might forget to check them.

Definitely not ideal.

On the other hand, here in discourse, i get periodic updates of “what’s new”, as a sort of digest. I can look at that notification that has a summary and then decide to look or delete the email. I can also follow individual topics… Much better for time management.

1 Like
#4

A challenge is that there’s some many different ways that people use things.

I do not use the dashboard on Github or Codeberg, for instance. Especially Github is a wild Christmas tree, or a Boeing 747 cockpit. No need. The activity feed is not useful for me. I star repo’s as bookmarks (slight interest) and/or appreciation (cool project). I follow repo’s if I intend to inspect them more closely later on.

In GH and Codeberg I only check Participating notifications. The small time I was following all Forgejo repo’s showed me that that does not work for me.

So yes, more fine-grained filter would work. But it should be flexible to address all the different needs.

Here there would be a nice use case for Linked Data, if a FOSS project’s entire information structure would be a Linked Open Data graph, then you could query it any way you’d want. Right now that data goes into hard-coded DB data models.

#5

Main problem with GH is, ironically, UX customization, thats, close to non-existant.
In FOSS (Codeberg) you dont like how sthj is presented? No problem. Just code your own solution, send a PR and good luck :slight_smile: