Notification Inbox

Hey everyone,

We have a jira ticket (XWIKI-19217) about creating an inbox view for our notifications. I would like to present here a version of this inbox for discussion.

  • This ticked impact directly on the discussion we are having on the notification central, so I took that proposal and made some changes here. In case we choose to do not go through this one, then that version should be used as implementation reference.
  • As always I would like to reiterate that these images are mockups only.

One of the problems pointed in the ticket is the use of space on the notification center (bell icon) so a separate page would help us to alleviate the problem and organize the features better with additional screen space.

Proposal for the main view:
inbox view

This of course would change the proposal of the notification central to be more light, with fewer features but quicker to navigate. Also, only new notifications would be shown here
Features moved to the inbox that were here originally:

  • rss
  • settings
  • detailed view
  • load more notifications

notif center

Note that navigation to the object of the notification is still available, doing so would automatically mark the object as “read”

The flow of these screens would be the notification central being a gate to the complete list of notifications in the inbox, allowing the user to quickly glance at new notifications without being overwhelmed with a lot of options and features right away.

Check the video below about what I mean.

So tell me, what do you think about it?


thanks for this proposal. I have a few questions / remarks.

First of all, the screenshot of the inbox is not clear how you’re proposing to handle thousands of notifications: do you plan to have pagination or an infinite scroll? filtering options of notifications? Also would that be possible to have capability to unmark a notif as read? In which case would it appear back in the notif area under the bell?

Speaking about the notif area under the bell: I’m not yet fully convinced that it’s a good idea to completely remove the settings links there: I’m still wondering if we shouldn’t keep at least a gear icon to access settings from there. Also it feels a bit odd to me that the notif immediately disappear when you access it and it’s marked as read. Finally: what should the area displays when everything’s has been read? And what’s the behaviour of this area when you have says 30 unread notifications: do you display a subset and invite to consult the notification inbox?

Good catch on the pagination and filtering, I will update the proposal.

Undoing the read status is not something I was thinking of. If necessary, we could provide this feature in the inbox page, without showing the “unmarked” notification again on the pop-up. My reasoning is the user already “saw” the notification but marked it as unread, so it is something that the user wants to come back to later but not being reminded again and again with a red mark on the header. Think of the pop-up being a quick glance into new notifications, while the inbox view is the main page for all notifications.

Sure, we could do that.

Maybe because the current implementation in Xwiki is different. But this proposal is not so different from an e-mail client that marks new email as read as soon as you access it.

On the pop-up, the same message we have today. “No notifications available”. Personally, I would change it to “No new notifications available.” On the inbox view, all notifications would be available but visually differentiated between old and new.

We could have a “Load More” past a certain number of new notifications and a “See All Notifications” button that lead to the inbox.

I forgot to mark @lucaa in this discussion since she is the one who opened the jira. @lucaa Sorry about the late ping.

Let’s put that aside for now: it’s probably a minor feature. Now for info from a strict implementation point of view, right now there’s currently no way to distinguish from the storage an event that has been once read and an event that was never read.

I think that I would only always put a fix number of notifications in the area, but each time an event is read (and then removed) I’d load another one which wasn’t displayed. And I’d keep only the link to see all notif so that you can mark the notif as read one by one, or you can just go to the inbox to see them all.
Also it means we might need a way to “Mark all as read” in the inbox, or to select them to mark them as read there at once.

Hey @surli thank you for the feedback. I did some changes based on it, as you can see below.

For the filtering, I put a search box that would look into the text content of the notification and filter based on that (so it could be Page Name, or user or time). I don’t really know what is possible or practical from the programming side, so maybe it is something we should discuss further. Of course, we could always provide more sophisticated searches in this box, like GitHub does with tokens and all, but I don’t know the validity of that based of the time it would be needed to program.

For the navigation aspect I did some buttons just to jump pages but without links going to any specific pages (01, 02, 03, etc). The way I see it, notifications paging are not something the user will need a great amount of granularity in the interactions. But of course, maybe we have some edge cases that I don’t know about.

Without new notifications
no new notifications

New Notifications with counter
notifications bell

Inbox with filtering options and buttons for navigation
inbox view

Inbox without filter applied
inbox view - filtered

Technically, I think we should try to use the LiveData UI component to display the notifications in the inbox page, since that component already implements several features (filtering, sorting, pagination, etc).

If we want a different UI than the table view of LD, it’s possible to implement a custom view.

1 Like

That’s interesting, I will look into it.

I think that’s good even with LiveData: we have a ticket for allowing to support cursor-based pagination in LiveData, see: Loading.... I’m not sure we can properly compute a number of notifications so computing number of pages might be complicated (depending on rights etc).

Regarding using a LiveData that would provide consistency indeed but I’m wondering how to handle the granularity of notifications: do we keep grouping notifications or do we only display any single event without any grouping? I’m afraid it won’t be good if we group: e.g. in a group you can have multiple author of a change in a page so filtering wouldn’t work properly.

Hello all,

@tkrieck : the proposal looks very nice, with the reserve that we should try as much as possible to use livedata, which should allow us to have filters on all metadata of notifications, ideally (date, page, author, etc).

In order to decide what we show where, I think we may need to clarify the state of a notification:

  • unread
  • read
  • read and deleted (non-existent after having been displayed).

(I think these are the current states of the notifications now).

In the context of your proposal, the display in the popup is somewhat ambiguous:

  • afaiu, in your proposal, it displays unread notifications only
  • the ‘clear notifications’ button would delete notifications, not mark them as read
    • this will make the notifications disappear from the popup
  • in your proposal, clicking on a notification from the popup would mark it as read, so it will disappear from the popup

Thus, the disappearance from the popup is rather ambiguous. We either offer both “remove all” and “mark all as read” options in the popup, so that the user understands clearly what will happen, or we offer none and it will have the default behaviour of only showing unread notifications and the management of deleting notifications will be done in the inbox view.

I agree with @surli that we can keep an access to settings in the popup, but we can move it next to “all notifications”, I would say, at the bottom.

Thanks for the nice work!