[1] What's the intended behavioral logic for the red dot indicator that prefixes a tab name?

This is to alert contributors that they have an unread message on the tab that they are not currently on (eg. I have both new alerts and new notices)

[2] We're planning to mark notifications as seen (different from read) on the API when they visit the Notifications Center – now that we're committed to the two tab approach, should we still be marking all notifications in both categories as seen (even if they haven't haven't explicitly visited both tabs) when they first visit the Notifications Center?

If possible can we only mark as seen the notifications that they have seen?

[3] Is the conceptual intent of these tabs to represent two separate tables (with independent scroll positions) or a single table with two different views into/filters on that data (alerts/notices – almost as if you're read status/inbox filtering)? From an engineering standpoint, it's far simpler if we think of it like a view into/filter on a single table of data, but wanted to be sure I understood the design intent.

The intent is for this to be two separate tables with two independent scroll positions. This is to match functionality on web, albeit within the same view.

[1] What's the intended behavioral logic for the red dot indicator that prefixes a tab name?

This is to alert contributors that they have an unread message on the tab that they are not currently on (eg. I have both new alerts and new notices)

@cmadeo Gotcha – so it's sounding like the logic is to always keep the red indicator for a tab on as long as there are unread (not necessarily unseen) notifications in a tab category. The moment all the notifications in a tab category are marked as read, then we turn off the red indicator for that tab category, correct?

I'm assuming the user's in-app user action entry way into the Notifications Center (via tapping the Bell icon in the Explore feed/Settings if Explore feed is disabled) is always to the "Mentions" tab, correct? If the user taps on a system iOS push notification though, and that notification type is an Activity type, then the user would be directed to the Notifications Center and the "Activity" tab. In both cases, even though the user may be on a tab that has the red indicator, we don't remove the red indicator until they explicitly marked any unread notifications in that tab category as read.

Just want to confirm this behavior is expected.

[2] We're planning to mark notifications as seen (different from read) on the API when they visit the Notifications Center – now that we're committed to the two tab approach, should we still be marking all notifications in both categories as seen (even if they haven't haven't explicitly visited both tabs) when they first visit the Notifications Center?

If possible can we only mark as seen the notifications that they have seen?

@Tsevener Do you think this behavior (marking as seen only the notifications in the Tab category the user has explicitly tapped into, Mentions or Alerts) will work for our purposes, instead of our previous approach of marking as seen all notifications once the user has entered the Notifications Center?

Hi @Dmantena!

I'm assuming the user's in-app user action entry way into the Notifications Center (via tapping the Bell icon in the Explore feed/Settings if Explore feed is disabled) is always to the "Mentions" tab, correct?

I was hoping that if someone receives a system push notification for a 'Notice' that we could push them to the 'Notice' view (vs the 'Alert' view) in the in-app notification center? This would be a potential path where someone can get to 'Notices' without passing through the default 'Alerts' view.

Gotcha – so it's sounding like the logic is to always keep the red indicator for a tab on as long as there are unread (not necessarily unseen) notifications in a tab category. The moment all the notifications in a tab category are marked as read, then we turn off the red indicator for that tab category, correct?

+

...even though the user may be on a tab that has the red indicator, we don't remove the red indicator until they explicitly marked any unread notifications in that tab category as read.

I'm prepared to be kinda torn about this once there's something for us to play around with (eg. in beta). After reading through your comments, my gut instinct is that it would be expected that the red dot disappear after you've tapped into the tab (eg 'seen' the notification') but I'm starting to get worried that we have a lot of different elements working in different ways. How hard would it be to prototype this and make a change after usability and internal testing?

If possible can we only mark as seen the notifications that they have seen?

Do you think this behavior (marking as seen only the notifications in the Tab category the user has explicitly tapped into, Mentions or Alerts) will work for our purposes, instead of our previous approach of marking as seen all notifications once the user has entered the Notifications Center?

So the mark as seen API does not work on an individual notification level, we cannot tell the server which particular notifications they have seen in the same way we can mark one as read (which does work on an individual level with the server). BUT it looks like we do have the ability to mark a type of notification as seen, which works for our tabbed purposes. So if they land on the Alerts tab, we call the mark as seen API with the alert type param, and when they land on the Notices tab make the same call with the message type param. See documentation here at the very bottom.

I think this should be fine for us. As far as I know we're just making this call behind the scenes so that Desktop gets the message for its badges, but we ourselves aren't actually going to use this timestamp for anything in our UI. Let me know if I'm missing something though.

I'm assuming the user's in-app user action entry way into the Notifications Center (via tapping the Bell icon in the Explore feed/Settings if Explore feed is disabled) is always to the "Mentions" tab, correct?

I was hoping that if someone receives a system push notification for a 'Notice' that we could push them to the 'Notice' view (vs the 'Alert' view) in the in-app notification center? This would be a potential path where someone can get to 'Notices' without passing through the default 'Alerts' view.

@cmadeo Makes sense! Tap actions originating from a iOS system notification, whether displayed on the OS itself or over the open app, routes the user to the appropriate tab in the in-app Notifications Center based on the notification type, whereas an explicit tap of the Bell icon directs the user to the left-most Tab ("Alerts").

I'm prepared to be kinda torn about this once there's something for us to play around with (eg. in beta). After reading through your comments, my gut instinct is that it would be expected that the red dot disappear after you've tapped into the tab (eg 'seen' the notification') but I'm starting to get worried that we have a lot of different elements working in different ways. How hard would it be to prototype this and make a change after usability and internal testing?

I don't expect the appearance logic of this red indicator to be challenging to change after we play around with it. So if we have to change it later, should be quite all right.

I empathize with your point about a lot of elements functioning in different ways here. This is another reason I was hesitant about us trying to solve this tab problem at start. It has negative spiral down effects into what the a. bell icon indicator and b. application badge indicate as well. If it's helpful to hear my perspective at all, I'd expect a user would be frustrated if removing an indicated red dot required them to mark all notifications in a tab category as read. I'd expect them tapping an indicated tab dot, seeing the dot remain when they left the tab, then later realizing (or never realizing) they had to mark all in a tab category as read to remove the dot would feel frustrating and like extra work. Whereas if we simply removed the red indicator upon tap, that would be a welcome, perhaps worthy, reward and not require what is tedious extra action of marking as read.

I think in general my same perspective applies to the Notifications bell indicator itself.

Agree with Toni's comment on the seen status and tabs:

I think this should be fine for us. As far as I know we're just making this call behind the scenes so that Desktop gets the message for its badges, but we ourselves aren't actually going to use this timestamp for anything in our UI.

Basically mark the category as seen when that tab is shown.