Don't show notifications for messages already appearing on screen #3114
Comments
|
We can use the setting |
|
We did have a bug and a fix for that very recently. |
|
Chris and I experimented a bit (with his iPhone, on chat.zulip.org) and determined that the behavior here isn't quite anything I thought it was. :-) In particular we didn't actually succeed in reproducing getting a notification while the app was on the screen. This even after he set "Send mobile notificatinos even if I'm online" to true. So the first step in doing something here will be to try to pin down what the existing pattern of behavior is for how notifications interact with the app already being open. Stepping back to the original description / request: I think it's actually important that there should be a notification when you get a (notifiable) message, even when you're actively using the app -- if you're using it in some other narrow, or anywhere else that means you're not going to immediately see the message in the app. We wouldn't want it to be the case that when you're actively using the app, that causes you to not see PMs unless you keep actively checking for them. But I do think it's a not-great experience if you're actively participating in a PM thread, and you keep getting a ding and a banner for every message the other / another person sends in the thread. The ideal behavior here might be: when you're looking at a message list, suppress notifications for messages that would appear in that same message list. |
|
Yeah, I believe that's the right UX design. |
|
Just to extend that commentary, what we do in the webapp is we suppress notifications for messages that appear onscreen; which is a bit different from being in the message list (but I think matches the user expectation for whether it's annoying or useful to get a ding). |
|
Yeah, that makes sense. That might be the ideal behavior for the mobile app, too. One difference from web is that we have the "N unreads" banner, which is prominent at the top of the screen (in the same general area a notification would appear, in fact) in a way that the counts in the left sidebar aren't. But, when I think about situations where this would arise -- like I'm catching up on a long thread, and someone @-mentions me in it, down below what's onscreen -- I feel like I do want the notification. |
gnprice
changed the title
|
Bump to mention that we've heard a complaint about this on czo. |
|
The same user who highlighted this issue for us a few months ago has provided a video. It shows that the behavior they're currently seeing is the same one originally reported in this issue, unlike what we saw in experiments described above at #3114 (comment) . Specifically:
I suspect that what we're seeing is an OS difference. That video shows an Android device; the experiment above was on iOS. So I suspect the situation is:
The behavior we want is a mix of these, where whether we show a notification depends on whether the message will already be shown on-screen. This will require implementing some new logic in order to be able to use that information when determining what notifications to show. |
I agree.
Correct; I've got a few bullet points to brainstorm at #4241 (comment). |
|
any update? |
|
No, sorry, @andreasoc. Progress on iOS notification work is stalled on #4115 (comment). |
On iOS, for zulip#4897, we instead want to use the native notification-sound functionality. So, do that, by adding a line to AppDelegate.m. We should still carve out an exception: we won't need to notify the user if the relevant item (a new or updated message) is already on the user's screen. Doing so could be annoying; for example, you don't need to be notified about every single message in an active PM conversation. That's issue zulip#3114, and it'll take some work. But this change improves the behavior on iOS and it matches the existing behavior on Android. On Android, this JS function call has apparently been duplicating the notification sound that gets played at a lower level, so it's fine for Android to remove this. Fixes: zulip#4897
On iOS, for zulip#4897, we instead want to use the native notification-sound functionality. So, do that, by adding a line to AppDelegate.m. We should still carve out an exception: we won't need to notify the user if the relevant item (a new or updated message) is already on the user's screen. Doing so could be annoying; for example, you don't need to be notified about every single message in an active PM conversation. That's issue zulip#3114, and it'll take some work. But this change improves the behavior on iOS and it matches the existing behavior on Android. On Android, this JS function call has apparently been duplicating the notification sound that gets played at a lower level, so it's fine for Android to remove this. Fixes: zulip#4897
On iOS, for zulip#4897, we instead want to use the native notification-sound functionality. So, do that, by adding a line to AppDelegate.m. We should still carve out an exception: we won't need to notify the user if the relevant item (a new or updated message) is already on the user's screen. Doing so could be annoying; for example, you don't need to be notified about every single message in an active PM conversation. That's issue zulip#3114, and it'll take some work. But this change improves the behavior on iOS and it matches the existing behavior on Android. On Android, this JS function call has apparently been duplicating the notification sound that gets played at a lower level, so it's fine for Android to remove this. Fixes: zulip#4897
On iOS, for zulip#4897, we instead want to use the native notification-sound functionality. So, do that, by adding a line to AppDelegate.m. We should still carve out an exception: we won't need to notify the user if the relevant item (a new or updated message) is already on the user's screen. Doing so could be annoying; for example, you don't need to be notified about every single message in an active PM conversation. That's issue zulip#3114, and it'll take some work. But this change improves the behavior on iOS and it matches the existing behavior on Android. On Android, this JS function call has apparently been duplicating the notification sound that gets played at a lower level, so it's fine for Android to remove this. Fixes: zulip#4897
On iOS, for zulip#4897, we instead want to use the native notification-sound functionality. So, do that, by adding a line to AppDelegate.m. We should still carve out an exception: we won't need to notify the user if the relevant item (a new or updated message) is already on the user's screen. Doing so could be annoying; for example, you don't need to be notified about every single message in an active PM conversation. That's issue zulip#3114, and it'll take some work. But this change improves the behavior on iOS and it matches the existing behavior on Android. On Android, this JS function call has apparently been duplicating the notification sound that gets played at a lower level, so it's fine for Android to remove this. Fixes: zulip#4897
|
CZO discussion with some details |
[edit: see refinements below] If the app is on-screen, currently being used, do not show notifications!
The text was updated successfully, but these errors were encountered: