search

element-hq / element-web

A glossy Matrix collaboration client for the web.
https://element.io
GNU Affero General Public License v3.0
11.15k stars 1.99k forks source link

Notification badge should count message instead of rooms #12208

Open nadonomy opened 4 years ago

nadonomy commented 4 years ago

Haven't debugged in detail, but the notification count displayed on the OS level of the electron app doesn't always seem to accurately match the count of red/priority notifications in the client itself:

Screenshot 2020-02-03 at 10 10 49
nadonomy commented 4 years ago

On closer inspection, I suspect the count is the number of rooms which contain priority notifications, where instead it should be the count of notifications itself.

aaronraimist commented 4 years ago

This isn't electron specific, this is also how notification counts work in the browser

jryans commented 4 years ago

It looks like @ara4n last changed the behaviour here to count rooms for the application badge as part of https://github.com/matrix-org/matrix-react-sdk/commit/fd09d5c57049083719b59a3bbf65a33015d15269 from 2016. It might be worth checking if he's attached to the current room count behaviour...?

nadonomy commented 4 years ago

I'd strongly advocate for the default behaviour to be for the notification badge to represent the number of (message) notifications— it reduces confusion and leverages affordance users have from other platforms.

If we're motivated to solve use cases where advanced users might have too many message notifications and we want to improve the signal:noise ratio of the badge count, we could consider having an opt in (labs?) setting which changes to this behaviour.

On Tue, 4 Feb 2020 at 00:11, J. Ryan Stinnett notifications@github.com wrote:

It looks like @ara4n https://github.com/ara4n last changed the behaviour here to count rooms for the application badge as part of matrix-org/matrix-react-sdk@fd09d5c https://github.com/matrix-org/matrix-react-sdk/commit/fd09d5c57049083719b59a3bbf65a33015d15269 from 2016. It might be worth checking if he's attached to current room count behaviour...?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/vector-im/riot-web/issues/12208?email_source=notifications&email_token=ABDJTMLEEBFTHHXSASH3KW3RBCXBTA5CNFSM4KPCNRTKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEKV37BQ#issuecomment-581681030, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABDJTMLN6GTZVFLM2V6PCWLRBCXBTANCNFSM4KPCNRTA .

ara4n commented 4 years ago

Platforms vary considerably on how they handle this, based on their traffic patterns and notif settings. At the time I had a comparison between WA, FB, TG, etc, all of whom handled it differently (or were experimenting with it too - istr WA switched behaviour around the time).

We tried it both ways back in 2016, and from dogfooding it was very very clear that it was much more useful to know how many missed conversations you had, rather than being told "you have lots of unread messages; god knows whether it's one busy conversation or a mix". So we switched it to tell you how many different rooms have been trying to get your attention - rather than the total number of missed messages.

I haven't heard anyone complain about the change since (until this bug).

ara4n commented 4 years ago

@nadonomy can we close this? i'm pretty confident that the proposal is flawed - it's much more useful for me to know that 3 people are trying to talk to me, than that I have 50 missed messages (distributed over an unknown set of rooms).

nadonomy commented 4 years ago

@nadonomy can we close this? i'm pretty confident that the proposal is flawed - it's much more useful for me to know that 3 people are trying to talk to me, than that I have 50 missed messages (distributed over an unknown set of rooms).

I don't think it's that black and white at all to just outright close. I can see the rationale for the decision in 2016 but there's a few important things at play:

  1. As folk building the protocol its unsurprising we're thinking about the problem as room first, as everything in matrix is built around rooms. But really, users intentions and goals generally revolve around messages.
  2. We're now shipping huge improvements to Notifications which presents a model for notifications that non-technical end users can actually understand.
  3. Although the behaviour can vary across other platforms, the largest platforms all use message counts. Leveraging this affordance is wise.
  4. This is how desktop and mobile platforms work already— which we have no control over, and we can also imagine that OS vendors have spent more time & resources researching the problem & its solutions. Our current solution is tantamount to an OS saying "I only care about how many apps have notifications, not how many notifications I have!".

I wouldn't expect users to actively report this as a bug, but I think it contributes subconsciously to cognitive load, and an overall lack of confidence in the product. I would anticipate it coming up at some point though, perhaps when we do more qualitative user research.

Given how we triage issues in general— we could label this as p2/p3 & suggestion?