Turn the cog icon into a menu
Closed, ResolvedPublic

Description

When visiting Special:Notifications, don't mark all notifications as read. Instead, provide controls similar to the ones in the flyouts for marking specific notifications or all notifications as read.

Design details

Based on T115316, the following changes are proposed:

  • Visually distinguish read and unread notifications at the notification page. This is needed to communicate there are unread items and surface the effects of marking them as read. This can be done by displaying them in the same way they are in the panel with one or more of the following: using background color contrast and providing controls to mark them as read. DONE
  • Provide a control to mark a given group as read (notifications are grouped by day in the page). If all notifications are read, the button will be disabled. DONE
  • Turn the cog icon into a menu to provide access to the more advanced options: mark all as read, notification settings and the learn more link (mockup below). OUTSTANDING

There are a very large number of changes, so older changes are hidden. Show Older Changes
Mattflaschen-WMF renamed this task from Make "mark as read" an explicit action on Special:Notifications to Make "mark as read" an explicit action on current version of Special:Notifications.Mar 10 2016, 5:18 PM
Mattflaschen-WMF renamed this task from Make "mark as read" an explicit action on current version of Special:Notifications to Make "mark as read" an explicit action on current no-JS version of Special:Notifications.

@Pginer-WMF, should we add some more emphasis on the difference in the current no-javascript view of the Special:Notifications page?

Which is the state you refer to as "the current no-javascript view of the Special:Notifications page"?
Currently there is no distinction at all for read/unread notifications in the Notification page.
The general idea is to represent notifications as we do for the notification panel. We also have plans (T126214) to distinguish read/unread better, but the result should affect both the notification page and the panel, we should not have something special for the page only. Both should remain consistent.

Sorry, yes, at this moment and for the sake of the above gerrit commit, I am only speaking about the no-js experience in the Special:Notifications page.

The problem at the moment is that technically speaking, the implementation between the (javascript-driven) notification panel and the (non-javascript) Special:Notifications page is completely separate. We were discussing the idea of converting Special:Notifications to get the design to be exactly the same, but that was shot down for now in favor of adding the minimal actions into the existing implementation and concentrating the rest of the effort on the Javascript-driven Special:Notifications page.

Up until the current patch, all notifications in the Special:Notifications page were automatically marked as "read" because that page automatically marked them as read, so we don't really have a good way of presenting unread notifications.

The current patch, however, overrides that. We are adding "X" (mark as read) to unread notifications, and are removing the auto-mark-as-read from Special:Notifications, so we need a way to indicate unread notifications to the users...

Ideally, we would do that with the same design, but given the above decision, we need an interim solution - and hence my question about it. If we want to show things more or less the same as the panel, we will need to make the background of all read notifications in that page grey, and the unread ones white. I'm not sure that works well with the current implementation (which is what we're working on for now)

I hope that makes more sense?

And given all of that -- what should I do with the read/unread notifications? Add some different style? Add a "unread" label (for accessibility?)

I hope that makes more sense?

Yes. Thanks @Mooeypoo for all the details!

And given all of that -- what should I do with the read/unread notifications? Add some different style? Add a "unread" label (for accessibility?)

As for the minimal changes, I'd consider:

  • Add the mark as read "X" icon to unread notifications.
  • Add a grey background to the read notifications.
  • Align sections to the left and adjust the unbalanced margins of the notification items now that their background will become more visible. This may be done in a follow-up ticket if more details are needed.

As for the minimal changes, I'd consider:

  • Add the mark as read "X" icon to unread notifications.
  • Add a grey background to the read notifications.
  • Align sections to the left and adjust the unbalanced margins of the notification items now that their background will become more visible. This may be done in a follow-up ticket if more details are needed.

Done, done and done. Awaiting review in the patch above.

Done, done and done. Awaiting review in the patch above.

Awesome. Thanks!

Change 265641 abandoned by Mooeypoo:
Don't auto mark notifications as read in Special:Notifications

Reason:
This is being dealt with in I54dba5f86d28a06965

https://gerrit.wikimedia.org/r/265641

This comment was removed by SBisson.
SBisson reopened this task as Open.May 10 2016, 3:25 PM

Reopening: this task is about marking one notification as read on Special:Notifications in NO-JS mode.

I'm ready to merge this. @Pginer-WMF can you OK the design (or propose changes)?

Remember that this is soon going to be the NO-JS experience only. The JS experience should be identical to the flyout in terms of style and layout.

I'm ready to merge this. @Pginer-WMF can you OK the design (or propose changes)?

Remember that this is soon going to be the NO-JS experience only. The JS experience should be identical to the flyout in terms of style and layout.

It looks good in general, but we could polish a couple of aspects:

  • Alignment. As illustrated below, it's not visually clear which is the width of the list. By making the line of the daily groups be the same as the Notifications header, and move the "X" icons accordingly. Note that the X should still have some space around it (10px).

  • Contrast of the X icons. The X icons seem too dark, if we could apply opacity in a similar way as we do in the panel (e.g., ~80% initial and 100% on hover, we may want to check the exact approach) it would be less prominent and we could communicate interactivity better.

Change 276256 merged by jenkins-bot:
Add mark-as-read button to notifications in Special:Notifications

https://gerrit.wikimedia.org/r/276256

Change 276376 merged by jenkins-bot:
Add 'mark section as read' to Special:Notifications

https://gerrit.wikimedia.org/r/276376

Etonkovidova added a subscriber: Etonkovidova.EditedMay 12 2016, 8:21 PM

Checked in betalabs.
The following are done

  • the auto-mark-read action is removed

The following seems to be done also:

Add the mark as read "X" icon to unread notifications.
Add a grey background to the read notifications.
Align sections to the left and adjust the unbalanced margins >of the notification items now that their background will >become more visible.

My notes:

  1. from my comments on T134204: Add "mark as read" buttons for each day on the no-JS Special:Notifications page
  • do we really need to display Special:NotificationsMarkRead > page after a user explicitly clicked on 'MARK AS READ' ?
  • 'MARK AS READ' is all capitalized
  • the button 'MARK AS READ' pushes date labels up
  1. What happened to the gear icon? It's not present anymore in betalabs, but it's present in production.

Some screenshots:


jmatazzoni added a subscriber: jmatazzoni.EditedMay 26 2016, 9:07 PM

Taking these in order:

do we really need to display Special:NotificationsMarkRead > page after a user explicitly clicked on 'MARK AS READ' ?

Matt is making this happen.

'MARK AS READ' is all capitalized

Stephane.has a patch for T134204 pending that should fix this.

the button 'MARK AS READ' pushes date labels up

@Pginer-WMF will file a separate ticket for style changes.

What happened to the gear icon? It's not present anymore in betalabs, but it's present in production.

Bring the gear back with the menu. But, contrary to what it says in the Description above, change the "Notifications settings" item to say "Preferences".

jmatazzoni removed Mooeypoo as the assignee of this task.May 27 2016, 12:02 AM

There's one outstanding item on this ticket: to bring back the gear icon/menu, as detailed in the Description.

NOTE: Contrary to what it says in the Description, in the menu, instead of "Notifications settings" please make the menu say "Preferences".
jmatazzoni updated the task description. (Show Details)May 27 2016, 12:10 AM
jmatazzoni renamed this task from Make "mark as read" an explicit action on current no-JS version of Special:Notifications to Turn the cog icon into a menu on the no-JS Notifications page.
jmatazzoni renamed this task from Turn the cog icon into a menu on the no-JS Notifications page to Turn the cog icon into a menu .Jun 3 2016, 6:33 PM

Just to make sure - this is for the "no-JS" version, correct? The JS version looks and behaves completely differently, and we were discussing adding a different button for mark-all-as-read.

Mooeypoo claimed this task.Jun 23 2016, 6:14 PM

Just to make sure - this is for the "no-JS" version, correct? The JS version looks and behaves completely differently, and we were discussing adding a different button for mark-all-as-read.

My understanding is that this task is for the regular JS-enabled page. Some aspects are already done, other aspects of the mockups are outdated (e.g., the use of the "X" to mark as read was changed by another ticket).

The pending parts of the ticket to do consist of replacing the current help icon (at the right side of the page heading) with a menu that provides access to three options: (a) marking all unread notifications from the selected wiki as read (for users that want to start from a blank slate), (b) access the notification preferences (a link that was lost in the process of updating the page) and (c) link to help.

In this way we provide access to advanced features without adding separate entry points that distract from the regular activities of checking your notifications.

The reason I ask is because the screenshot is for the no-js notifications page. Should we work on this for no-js, js-version, or both?

I started on a very VERY work-in-progress for no-js, but there's a bunch of problems with it. If we're going for the javascript version, I'll shift focus and we can get back to this WIP later.

Change 296485 had a related patch set uploaded (by Mooeypoo):
[wip] Add settings cog menu and mark all read button to Special:Notifications

https://gerrit.wikimedia.org/r/296485

Pginer-WMF added a comment.EditedJun 29 2016, 7:34 AM

jmatazzoni changed the title from "Turn the cog icon into a menu on the no-JS Notifications page" to "Turn the cog icon into a menu ".

From my conversation with @jmatazzoni, my understanding was that supporting this for the JS version was the priority.

The reason I ask is because the screenshot is for the no-js notifications page.

The mockup was reflecting one of the iterations before filters were added. This is a ticket that was created before those menus were added. Not sure what makes it non-JS.

In T115528#2106328 there was a similar confusion. This lead to the creation of T129460 for the JS version, but the cog menu part was also not done there and the current ticker was reused to capture the pending part (which in retrospect, leaving T129460 open may have caused less confusion).

Change 296674 had a related patch set uploaded (by Mooeypoo):
[wip] Add a cog menu to Special:Notifications

https://gerrit.wikimedia.org/r/296674

There are some usability issues that arose when I added the 'mark all as read' button that we should discuss:

  • When do we show this button?
    • When viewing locally, only when there are any unread notifications (even in following pages?) or only when we see these unread notifications (When we are in a page where those exist) ?
    • What about when we are looking at remote sources? Do we show the button then, and does it mark the remote notifications as all read? If so, it seems a little out of "scope" (it's outside of the filter view) - will it be understood that the 'mark all read' is talking about all notifications in the current source? Or do we just leave it as a local mark-all-read (since that's also pretty disruptive, marking everything read) and do we need to change the wording if so?
  • What's the scope of this button? (Continuing from the above point -- )
    • Does this button marks all notifications as read locally only?
    • Does it mark as read all notifications in the wiki we're looking at (so, source-dependent, if we are looking at a foreign wiki?)
    • Does it depend on specific filters? (If you're in a specific page view, will it mark only those notifications pertaining to that page, or all notifications ever on that wiki?) etc.
  • When we click the button, the notifications list is updated. Do we show the 'loading' animation?
    • If we don't, the user doesn't have any indication for whether the process worked. On the other hand, the process becomes "invisible" in the sense that the user can continue doing whatever they want without interruption from a loading state (the mark-all-read happens in the background).
    • If we do show it, that creates a weird issue where if you have a couple of unread notifications that are not in the current page (so you don't see them) and you click on "mark all read", the loading animation starts, and when it finishes, you see the exact same page.
  • Do we want to change the text of the button? It's a bit confusing.
    • We're using "mark all as read" in the popup, but there we're only marking the visible notifications as read, not all. That usually isn't a problem (according to stats, we don't have many or any users with more than 25 local unread notifications) but in the Special:Notifications page that is actually an issue, because unread notifications can appear in pages that you don't currently see.
    • There was a suggestion to make this slightly more clear by changing the text to something like "Mark all 12 notifications read" which tells the user exactly what will happen.

Just a suggestion in my view -- if we are limiting the scope of the button to what we're currently looking at, we might want to consider putting it inside the "main" notification view (where it is clear that buttons operate on the content). Otherwise, I think we might want to change the language of the button, or maybe even use something different altogether for this behavior?

Anyways, awaiting @Pginer-WMF and @jmatazzoni 's input on these issues

By the way - it may be that we'd like to separate this task (or commit, for that matter) to two pieces:

  • The cog menu, including 'help' and 'settings'
  • The 'mark all read' button

If we end up having a discussion about 'mark all read' we could continue incrementally with the cog menu without it until we solve that usability question.

Thanks for your comments @Mooeypoo. Some ideas below:

As mentioned in T115528#2404250, the main usecase we want to support with "mark all as read" is for users to start with a blank slate (or "get everything out of the way" as put in T115528#2059395).

The action should not be affected by pagination. Pagination is a way to view the main piece of information which is the long list of notifications, but the page represents the whole list. Thus, if there are three pages, "mark as read" will have effects in all of them (all items in those three pages will become read).

The filters (wikis and pages) should be taken into account. That is, if I select English Wikipedia (even if I'm in a different wiki), all notifications from English Wikipedia (and only English Wikipedia) will become read after I click the action. This involves cross-wiki behaviour in some cases, but it is not much different than selecting a different wiki and clicking "mark group as read" for each group.

I think we can also take page filters in consideration. Making the effect of mark as read to affect the items associated with those pages. This is not essential, but I think that provides flexibility without limiting the user options: if the user wants/expects the action to affect the whole wiki when a page is selected, she just has to select the wiki and apply the action there (while the opposite case would be more problematic).

If there are unread notifications in the current view of the user, the user will see the status change. I'm not sure I understand the "loading" comment since clicking the "mark group as read" seems to have the effect immediately on the affected items. This should be the same, but affecting all groups of the current wiki.

I don't think we need further notice in terms of the effects of mark as read. Not so long ago, "mark all as read" was triggered automatically just by visiting the page. So we already added some caution steps to avoid accidentally triggering it. Having said that, I think it's a good idea to surface the number of items affected ( "Mark all 12 notifications read").

Regarding what to do when the action does not apply (because all notifications are read already), I'd suggest to provide the action disabled to communicate that this is possible when it makes sense.

In summary: "Mark all as read" is a convenient shortcut to go through all pages clicking the "mark group as read" in just one click.

Awesome, thanks @Pginer-WMF !

So I think this button goes as a sort of "in context mark-all-read" which means you mark-all-read whatever view you have in front of you. If you are in enwiki's Special:Notifications but you clicked the User_talk filter for hewiki, then the 'mark all read' button should mark all notifications as read in hewiki (and in the specific page, if possible)

Did I get that right?

If so, I still think that the button should be inside the main view rather than in the cog menu. The cog menu feels to me to be detached from whatever filters we have, and so the word "all" in mark-all-as-read is confusing.

Regardless of that, there's a small technical issue (which we can bypass slightly) -- right now, we can only mark all read entire sections in wikis (remote or local) without regard to page filters. We can probably implement something like this in the future, but it doesn't exist yet.

Do you want me to display this button:

  1. Only when we're not in a page filter ?
  2. Or make the text absolutely clear that regardless where we are, this will mark everything in that wiki as read ?

I see where we want to go with this and the functionality, but to be honest, I really think this is confusing behavior right now. I think we should consider moving this button elsewhere (maybe even near the pagination and read/unread filters, so it's clear) and/or change its text.

Either way, we can start, as usual, incrementally, and check if things work well. It's just a bunch of considerations that I need to verify code-wise, so I want to make sure at least the base behavior is covered so it is implemented correctly.

Did I get that right?

Yes

If so, I still think that the button should be inside the main view rather than in the cog menu. The cog menu feels to me to be detached from whatever filters we have, and so the word "all" in mark-all-as-read is confusing.

This is a valid point from the information hierarchy perspective. However, this is an action that is expected to be used with very low frequency and it has side effects, so it makes sense to keep it away from the navigation controls the user can click safely in a quick exploration.
As an interaction pattern it is also not uncommon to find global actions at the top of the visual hierarchy affected by filters. In Gmail, a similar functionality ("mark all as read") is available under their "more" menu (affecting the items on the selected "folder").

Regardless of that, there's a small technical issue (which we can bypass slightly) -- right now, we can only mark all read entire sections in wikis (remote or local) without regard to page filters. We can probably implement something like this in the future, but it doesn't exist yet.

Do you want me to display this button:

  1. Only when we're not in a page filter ?
  2. Or make the text absolutely clear that regardless where we are, this will mark everything in that wiki as read ?

If there are some technical limitations, I don't think we want to invest a lot in this part of the functionality. I'd go with 2. We can make it explicit that the effects are on the whole wiki: "Mark all notifications on English Wikipedia as read", or "Mark all notifications on the selected wiki as read" if we cannot integrate the wiki name.

Change 296674 merged by jenkins-bot:
Add a mark-all-read button and a settings menu to Special:Notifications

https://gerrit.wikimedia.org/r/296674

@Mooeypoo, on Beta I see the cog now but I still see the Preferences link underneath the page title. Since that link has been made redundant, I'm pretty sure it's meant to be removed, yes?

BTW, I know there is a mockup somewhere from Pau that shows how this is meant to look on a JS page, in combination with page navigation, etc. Can you post that mockup to the page so Elena can use it for QA? Thanks.

Etonkovidova added a comment.EditedJul 21 2016, 10:41 PM

Checked in betalabs. All functionality that the cog is supposed to do is there.
Below some questions for @Pginer-WMF and/or @jmatazzoni for final approval
When non-local wiki is selected


With pagination

  1. When there are no notificaitons on the selected wiki (or is a filtered view), the cog icon changes the position, so the page looks like this:

dewiki does not have any notificaitons, so when a user on dewiki will see the cog icon not at the right side of the page.

  1. There is a difference in links for the help icons

Production - opens in a new tab href="/wiki/Wikipedia:Notifications/FAQ"

betalabs opens in the same tab
http://www.mediawiki.org/wiki/Special:MyLanguage/Help:Notifications/Special:Notifications

3) The side menu counters for unread notificaitons do not get updated unless the page is manually refreshed.
Not updating after

  • some of the notifications were marked as read or unread
  • when a group of notifications is Marked as read
  • when 'Mark all as read' is clicked

And the counters do not get updated even if after doing all of the actions above, a user switches between wikis or the filter tabs. Especially confusing with pageless notifications (see examples in T140842: Special:Notifications: Pageless notifications not present in the list of unread notifications).

As per @Mooeypoo on the ticket:

When we click the button, the notifications list is updated. Do we show the 'loading' animation? If we don't, the user doesn't have any indication for

It might be a good idea to directly signal to a user that the action of 'Mark all as read' is successfully completed which also allows us to refresh the counters.
Otherwise, all kinds of confusing page states are presented to a user.

e.g. the screenshot show that a user after marking all as read in enwiki, selects Unread filter and sees 'no notifications', but the sidebar counter still shows five unread notifications:

The design was visible in older mockups, and as we were talking about this, @Pginer-WMF pointed me to them. Specifically, you can see it on the second image in the task description here: T115316: Better organisation of the Notification Page

3) The side menu counters for unread notificaitons do not get updated unless the page is manually refreshed.
Not updating after

Yes, we should perhaps open a new task (for consideration for the future, perhaps) to get the sidebar to update itself in general. The current "starter" version of the sidebar does not get updated by any user action on the page at all until the page is refreshed.

This is mostly because updating the sidebar has some potential UX issues of its own that we decided to solve in the future -- so for the moment, this is expected behavior, but it could probably use a ticket of its own so we can consider the challenges and benefits and come up with the behavior that we want to implement.

So, pertaining to this particular ticket - this is expected. The sidebar doesn't update itself at all not just for the mark-all-read button.

Thanks for pointing out these inconsistencies in the numbering system Elena. I like the idea of updating the counter at least when the user changes wikis. @Mooeypoo, I take it that is not as simple as it sounds to us layfolk? If it's complicated, I think this all works well enough and we can move on.

Meanwhile, what about the much simpler issue I pointed out above:

@Mooeypoo, on Beta I see the cog now but I still see the Preferences link underneath the page title. Since that link has been made redundant, I'm pretty sure it's meant to be removed, yes?

If there's no reason to keep that redundant link, please remove it. Thanks.

Elena writes:

Following @jmatazzoni comment above, filed the task - T141141: Notifications page: remove mw-echo-special-header-link

I see why you did this, but I think getting rid of the link really should be part of this task. I'd like it to be completed before the cog goes live. @Mooeypoo, can you please remove that link? Or is there more to it than I imagine?

Change 300671 had a related patch set uploaded (by Mooeypoo):
Hide the 'preferences' link from Special:Notifications JS

https://gerrit.wikimedia.org/r/300671

Elena writes:

Following @jmatazzoni comment above, filed the task - T141141: Notifications page: remove mw-echo-special-header-link

I see why you did this, but I think getting rid of the link really should be part of this task. I'd like it to be completed before the cog goes live. @Mooeypoo, can you please remove that link? Or is there more to it than I imagine?

Yep, done in the followup commit.

Just to be clear, the 'Preferences' link was removed only from the Javascript version. The no-JS version still shows it - along with the "help" link on the side.

Change 300671 merged by jenkins-bot:
Hide the 'preferences' link from Special:Notifications JS

https://gerrit.wikimedia.org/r/300671

Checked in betalabs.

For JS enabled page, the link Preference is gone;

no-JS version still has it:

Change 300687 had a related patch set uploaded (by Mooeypoo):
Adjust mobile view for the new settings cog menu

https://gerrit.wikimedia.org/r/300687

Change 300687 merged by jenkins-bot:
Adjust mobile view for the new settings cog menu

https://gerrit.wikimedia.org/r/300687

jmatazzoni closed this task as Resolved.Jul 27 2016, 5:45 PM

Change 296485 abandoned by Catrope:
[wip] Add settings cog menu and mark all read button to Special:Notifications

https://gerrit.wikimedia.org/r/296485

Restricted Application added a project: Collaboration-Team-Triage. · View Herald TranscriptAug 2 2016, 8:02 PM