Description

This proposal is discussing the presentation of the notifications state of a page and the possible actions. This new UI should replace the current switches from the notification menu:

Vocabulary

• followed: there's an inclusive filter for a resource or its parent
• blocked: there's an exclusive filter for a resource or its parent
• follow or block: add the inclusive (respectively exclusive) filter for a resource
• unfollow: remove an inclusive filter for a resource

We need to make a difference between unfollow and block because the result is not the same: an exclusive filter will also "mute" targeted events

Move the information & actions to the content menu

Why: because the state of the current page and the actions of the current page are better placed in the contextual menu of the current page rather than in the notification menu.

Also, having a button inline with all the actions allow to easily make a drop down menu or a dialog.

The icon changes to represent the state of notifications of the current page.

The click on the button will open a dialog with a detailed information about the state of the current page (whether it's on or off and why; when only part of the events are enabled, this needs to be presented as "partially on", not partially "off").

Possible design for button icon

We need to be able to represent different states for the button available that would represent the current watch status of the current page.
At the very least a user would need to be able to know:
  - if the page is followed for all events
  - if the page is blocked for all events
  - if the page has no specific state defined (i.e. the default behaviour, i.e. unfollowed, is used for it)
  - if the page has a partial/custom filter defined

Ideally we need icons that represents those concepts.

Using bells

• not set:
• followed:
• blocked:
• custom:

Other proposal using volume

I (Simon) find the volume concept interesting for notifications since there's a lot of variability in it, that can be used to express the different states.

We would need to upgrade Font Awesome to properly use this, it already works by using the Extension for FA5.

The page is watched for all events:

The page is blocked for all events:

The page has no specific state:

The page is partially watched:

Presentation of possible actions

Principle:

• all actions and complex config can be done from the user profile, so this menu does not need to be exhaustive.
• a user may or may not receive notifications for any given page
• if the user clicks the bell button on a page (and not go in their user preferences) in the following cases:
  • if they receive notifications for that page, their objective is to stop receiving notifications anymore
  • if they don't receive notifications for that page,  their objective is to start receiving notifications for that page.
  • the options displayed when clicking the button should offer an answer to these objectives
• whatever the state of notifications of a page, it can be because of a setting on the page itself or on one of the parents of the page
  • the displayed options need to provide the answer to the objective regardless of whether they apply to the current page or one of the parents; these options will be displayed in the same list, as possible answers to the same objective.

This is opposite to today when switches are actually both showing a state and allowing actions, but the actions they enabled are not tailored towards an objective.

Usecases

All following usecases are written in the context of a normal user browsing pages: the filters we're talking about are Scope notification filter available in the settings of that user. Also, for each usecase, once the state changed UI is refreshed. And we enter a new usecase.

UC1. A page is explicitly followed (with children or not)

This usecase happens when the user has an inclusive filter for all formats and all event types for the current page, or for the current space in case of a non-terminal page.

In such case, the user wants to stop receiving notifications, so the only possible action proposed for the user is to unfollow the page: when the action is performed, the modal is refreshed to display the new state, which can be UC2 or UC5.

The information to display to the user should be something like: "You are receiving notifications for this page".

UC2. A page is followed through a parent

This usecase happens when the user has at least one inclusive filter for all formats and all event types, for a parent space of the current page, or for the whole wiki of the current page, and no exclusive filter exists before that inclusive filter.

In such case, the user wants to stop receiving notifications, but they might not want to stop receiving notifications for other pages of the hierarchy. So we propose different choices:

• they can block the current page: after this action is done we're in UC3
• if the current page is not terminal, they can block the current space (so the page and its children): after this action is done we're also in UC3
• if the first filter in the hierarchy making the page followed concerns a space (and the page exists? or and the user has right to see it?) we propose to the user to go to that location to allow unfollowing it there: by doing so they'll get to UC1
• if the only filter in the hierarchy concerns the whole wiki, we propose the user to unfollow the whole wiki leading to UC5

Note that we don't provide any way to unfollow a whole hierarchy: the idea is for the users to iterate, to unfollow each space one by one, as the unfollow might impact lots of different pages.

The information to display to the user should be something like: "You are receiving notifications for this page thanks to a parent".

UC3. A page is explicitly blocked (with children or not)

This usecase happens when the user has en exclusive filter for all formats and all event types for the current page, or for the current space in case of a non-terminal page.

In such case, the user wants to start receiving target notifications, and probably to start receiving notifications. For now we only provide a single action: to unblock the page, which might lead the user to different state:

• UC4 if there's another exclusive filter in the hierarchy
• UC2 if there's actually an inclusive filter in the hierarchy
• UC5 if there's no filter in the hierarchy

The UI should make clear the unblocking won't be enough to receive all notifications, and that they might need to then follow the page explicitely. We could decide to allow performing both actions at once in a second time, but note that it's adding complexity as following the page wouldn't be always needed, i.e. if there's already an inclusive filter in the hierarchy.

The information to display to the user should be something like: "All notifications are blocked for this page".

UC4. A page is blocked through a parent

This usecase happens when the user has en exclusive filter for all formats and all event types for a space in the hierarchy of the current page, or for the whole wiki, and no inclusive filter exists before that exclusive filter.

In such case, the user wants to start receiving some notifications: maybe all, maybe only the target notifications they don't receive. So we provide different options:

• follow the current page, leading to UC1
• follow the current space, if it's not a terminal page, leading to UC1 too
• if the first exclusive filter in the hierarchy concerns a space, then go that space (and the page exists? or and the user has right to see it?) to allow unblocking it there, leading to UC4
• if the exclusive filter concerns the whole wiki: we propose to unblock the whole wiki leading to UC5

The information to display to the user should be something like: "All notifications are blocked for this page because of one parent".

UC5. No setting is defined on the page

This usecase happens when there's no filter at all (inclusive or exclusive) in the hierarchy of the current page. Note that if a filter exists in the hierarchy, targeting part of the events or of the formats, then we're in UC6.

In such case, the user wants to start receiving notifications, since by default they won't receive any notifications. So we provide different options:

• follow the current page, leading to UC1
• follow the current space, if it's not a terminal page, also leading to UC1
• follow the current wiki, leading to UC2

(Note that maybe we should also allow to block the current page, as we can imagine that a user wants to stop receiving target notifications on a hierarchy they never followed explicitly.)

The information to display to the user should be something like: "You are not receiving notifications for this page".

UC6. There is a custom filter on the page (different format, or different type)

This usecase happens when there's a filter for the current page or one of its parent, that do not concerns all event types, and/or all formats.

In such case, we have no idea what the user would want to do, since we don't even know why the filter has been created: it could not have been created through the options we've defined in the UI.

So we inform the user about the fact that there's filters for the current page, but that they're custom and they might remove or disable them in the custom settings if they want to use the standard watch features.

Interaction between usecases

Chart representing the interactions between the different usecases, and showing that there's no way to reach UC6 by using defined actions in other UCs.