Change Details

Depending on the user activities (e.g.,act on pending work, look for a past piece of information, etc.) users may want to focus on the read, unread or both kinds of notifications. By providing a filter with the options for "all", "unread", and "read", users can focus on the corresponding subset of notifications. [[ http://pauginer.github.io/prototypes/notifications/notification-page/index.html | This prototype ]] and the mockup below illustrate the filters: {F3579493}

Depending on the user activities (e.g.,act on pending work, look for a past piece of information, etc.) users may want to focus on the read, unread or both kinds of notifications. By providing a filter with the options for "all", "unread", and "read", users can focus on the corresponding subset of notifications. [[ http://pauginer.github.io/prototypes/notifications/notification-page/index.html | This prototype ]] and the mockup below illustrate the filters: {F3579493} **Design details** - Status views should be bookmarkable. That is, the current view should reflect in the URL so that users can keep links and bookmarks directly to it. - Clicking on the current view will go to the first page of the results for that view. - If there are no notifications at all, an empty state message is provided. Note that this may only happen on 3rd party wikis, since the welcome notification makes this case very rare. The empty state provides a link to the "getting started" page, that is, the same the Welcome message points to (e.g., [[ https://en.wikipedia.org/wiki/Help:Getting_started | this one ]] in English Wikipedia). {F3758228} - If there are notifications but all of them are read, the "unread" view will show an empty state with an action to reset the filters (going to the "all" view) as the suggested next step: {F3758257} - If there are notifications but all of them are unread, the "read" view will show an empty state with an action to reset the filters (going to the "all" view) as the suggested next step: {F3758270} - When switching views context is kept based on the date groups. If the user is not on the first page, when switching to another view, the user will be shown whichever page is displaying the notifications for the same date the user was viewing. For example when a user moves to view last Monday notifications, and keeps switching between "all", "read" and "unread", the user will still be viewing the notifications for last Monday (note that the page number will be different for each view). If this adds too much complexity for an iteration, we can start by reseting the page as the user switches views and create a separate ticket.

Depending on the user activities (e.g.,act on pending work, look for a past piece of information, etc.) users may want to focus on the read, unread or both kinds of notifications. By providing a filter with the options for "all", "unread", and "read", users can focus on the corresponding subset of notifications. [[ http://pauginer.github.io/prototypes/notifications/notification-page/index.html | This prototype ]] and the mockup below illustrate the filters: {F3579493} **Design details** - Status views should be bookmarkable. That is, the current view should reflect in the URL so that users can keep links and bookmarks directly to it. - Clicking on the current view will go to the first page of the results for that view. - If there are no notifications at all, an empty state message is provided. Note that this may only happen on 3rd party wikis, since the welcome notification makes this case very rare. The empty state provides a link to the "getting started" page, that is, the same the Welcome message points to (e.g., [[ https://en.wikipedia.org/wiki/Help:Getting_started | this one ]] in English Wikipedia). {F3758228} - If there are notifications but all of them are read, the "unread" view will show an empty state with an action to reset the filters (going to the "all" view) as the suggested next step: {F3758257} - If there are notifications but all of them are unread, the "read" view will show an empty state with an action to reset the filters (going to the "all" view) as the suggested next step: {F3758270} - When switching views context is kept based on the date groups. If the user is not on the first page, when switching to another view, the user will be shown whichever page is displaying the notifications for the same date the user was viewing. For example when a user moves to view last Monday notifications, and keeps switching between "all", "read" and "unread", the user will still be viewing the notifications for last Monday (note that the page number will be different for each view). If this adds too much complexity for an iteration, we can start by reseting the page as the user switches views and create a separate ticket.