These are amazing, and I think the sub-grouping makes things easier to read and control.

I do have a question about one piece, though. The [x] button on every unread notification: Right now, clicking it marks the notification as "read", but is this not confusing? If we look at other services, the X button does different things altogether, and that might be confusing. In Facebook, the [x] hides the alert and asks you (inline) whether you want to ignore all messages of this type (a smaller version of the ... menu in the mockups) and on Google+ the [x] marks as 'read' but the Google+ popup doesn't show unread messages on the main popup, so it looks like it deleted it.

I was always a little confused about those "x" buttons, because they seem to not be very consistent. The "x" is usually for "close" actions (like in overlays and dialogs, even in the Notification Volume dialog in the mockups above) -- so should we continue using [x] for "mark this notification as unread" or should we maybe change the icon? Am I the only one to find it a little confusing?

I was always a little confused about those "x" buttons, because they seem to not be very consistent. The "x" is usually for "close" actions (like in overlays and dialogs, even in the Notification Volume dialog in the mockups above) -- so should we continue using [x] for "mark this notification as unread" or should we maybe change the icon?

I think it is a valid point. There is some flexibility in the situations were the "X" can be used and still work, but we need to be careful of not bending the rules too much.

The "X" icon communicates the intent of getting rid of something (close, dismiss, remove, etc.): I'm no longer interested on something (a window, panel, item of a list, etc.) and I want it out of my way. The removal can be persistent or not, or have follow-up actions. I think the examples you mention fit in the model despite their different details.

In our case, I think the "X" works well for the discovery part: As a user, I'm not interested in the details of my article being linked from 10 other articles, and I find the "x" as the way to get rid of this piece of information. If we ask users to dismiss the notifications they consider irrelevant, I don't expect users to have problems of identifying the "X" as the mechanism to achieve that.

I think the problem is in the second part of the interaction. Where the removed item is still present somewhere else. Although it makes sense to show the recently read notifications to facilitate recurrent access, it may not be immediately obvious why the item you just removed appears somewhere else, and the user needs to connect the dots. So I think there is some misalignment there and it makes total sense to look for a solution that is (a) easily discoverable and (b) its outcome meets the user expectations.

The "X" symbol has been well stablished in the "recent" years, and other alternatives have the risk of affecting negatively the discoverability part, which seems the higher priority in this context (where the panel represents a quick overview that needs to be fast to operate).

In my explorations I tried other alternatives such as a done checkbox similar to items from a to-do list (but it was making the managing art more prominent than the notification content), and a small activity dot similar to what some email clients (which requires to figure out it represents the read status and you can acto on it). I'm totally open to keep exploring more options (and ideas are welcome), but for now I decided to keep the current mechanism and, as we improve other areas, observe which issues users find while using the notification panel, learn more about the details, and try some alternatives.

Some questions from team meeting, for further consideration:

What order do we show the cross-wiki notifications?
Alphabetical by project could use the Roman-alphabet codes (example: en, fr, he, pt) but it's not very friendly to languages with other alphabets.
Probably better to use most recent on top.

Compact notifications: How do we show the time? That's important to figuring out whether you need to click it or not.

Should there be an "expand" or "expand all" link if you want to see the full notifications?

Mark all as read: This wiki's notifications, or all of them? (Maybe ask after click: This wiki vs All wikis)

Bundling cross-wiki notifications -- put all other wikis under one bundled notifc? or have one bundle for each other project? (ie: "5 more alerts on Meta" and "4 more alerts on French WP" instead of "9 more alerts on other projects")

For alerts: are we marking cross-wiki alerts as read when you open the panel? Or just mark the local ones as read?

As we discussed in our meeting, I think that the notification bundling should be a bit more flexible. My idea is to maybe try to bundle per-wiki, showing the most recent unread notification in that wiki and then bundling the rest.

I'm aware that this is putting the solution before the problem, though, so here's my proposed scenario to explain why I think this is needed. Obviously, there could be other solutions. I'm also hoping my description of the problem is clear -- if anyone wants to add to it, feel free:

Scenario #1: Prolific admin or steward interested in multiple projects

• Imagine a user who has multiple watch lists for process discussions in several wikis:
  • Participates in talk page discussion of 10 articles in enwiki
  • Participates in process discussions on hewiki
  • Participates in 'image of the day' discussion on Commons
  • Has 20 images they uploaded to Commons
• The user is has these cross-wiki notifications:
  • enwiki:
    • 1 hours ago: Comment on a talk page
    • 1 day ago: Mention on a talk page
  • hewiki:
    • 1 day ago: Comment on their personal talk page
    • 1 week ago: 4 comments on an article talk page
    • 10 unread messages on the talk page from about a week ago
  • Commons:
    • 1 minute ago: Image of the day nomination
    • 1 hour ago: Comment on some nomination
    • 5 hours ago: Comment on an uploaded image
• Now the user is looking at their notifications in Hebrew Wikipedia
  • According to the current design, the user will have this list:

[ Comment on personal talk page (1 day ago) ]
[ 4 comments on talk page (1 week ago) ]
[ Unread message on page A (1 week ago) ]
[ Unread message on page B (1 week ago) ]
[ Unread message on page C (1 week ago) ]
[ ... ]
[ Unread message on page F (1 week ago) ]
[ BUNDLE FROM OTHER WIKIS (collapsed) ]
__ English Wikipedia
___ [ Comment on a talk page (1 hr ago) ]
___ [ X mentioned you on page Y (1 day ago ]
__ Wikimedia Commons
___ [ Image of the day nomination (1 minute ago) ]
___ [ Comment on nomination (1 hour ago) ]
___ [ Comment on uploaded image (5 hours ago) ]

• There are a couple of problems with the above:
  1. The notifications that were recieved 1 minute (or 1 hour) ago are buried inside a "vague" bundle of cross-wiki notifications. The user has to open the entire cross-wiki bundle to see that they have relatively urgent or new notifications.
  2. The local wiki notifications "push down" on cross-wiki notifications, so in this scenario, the user will have their new 1-hr old notifications buried below 10 old unread notifications from the local wiki.
  3. If the user switches to enwiki, the notifications window is now showing other (sometimes less important/recent) notifications. This can be a bit confusing and hide notifications the user cares about.

There are a few other minor issues with this but these are the ones that I think are most notable.

There are also many solutions to this, but I actually think that there's a relatively simple solution that can work here no matter which wiki the user is in. It will serve to not only "fix" the urgency/immediacy issue of showing recent notifications first, but also, I think, will serve to make a more unified look *between* wikis in the notification panel.

So if we bundle by smaller groupings of each wiki, the user's notification panel will look like this

• On hewiki:

[ COMMONS: Image of the day nomination (1 minute ago) ... expand for more from Commons ]
[ ENGLISH WIKI: Comment on a talk page (1 hour ago) ... expand for more from enwiki ]
[ Comment on personal talk page (1 day ago) ]
[ 4 comments on talk page (1 week ago) ]
[ Unread message on page A (1 week ago) ]
[ Unread message on page B (1 week ago) ]
[ Unread message on page C (1 week ago) ]
[ ... ]
[ Unread message on page F (1 week ago) ]

• If the user recieves another notification that is local to the wiki they're currently on (hewiki in our scenario) the list would be:

[ User A mentioned you on page B (1 second ago) ]
[ COMMONS: Image of the day nomination (1 minute ago) ... expand for more from Commons ]
[ ENGLISH WIKI: Comment on a talk page (1 hour ago) ... expand for more from enwiki ]
[ Comment on personal talk page (1 day ago) ]
[ 4 comments on talk page (1 week ago) ]
[ Unread message on page A (1 week ago) ]
[ ... ]
[ Unread message on page F (1 week ago) ]

• If the user clicks on the COMMONS bundle and reads the first notification (or marks it as read) the list would now be:

[ User A mentioned you on page B (1 second ago) ]
[ ENGLISH WIKI: Comment on a talk page (1 hour ago) ... expand for more from enwiki ]
[ COMMONS: Comment on nomination (1 hour ago) ... expand for more from Commons ]
[ Comment on personal talk page (1 day ago) ]
[ 4 comments on talk page (1 week ago) ]
[ Unread message on page A (1 week ago) ]
[ ... ]
[ Unread message on page F (1 week ago) ]

So, the "bundles" get their timestamp from the latest unread message in each of them, which puts them in the order of the master notification list in the popup.

I hope this makes sense, both the description of the problem and my idea for a solution. Let me know if there's a need for clarification.

The notifications that were received 1 minute (or 1 hour) ago are buried inside a "vague" bundle of cross-wiki notifications. The user has to open the entire cross-wiki bundle to see that they have relatively urgent or new notifications.

I thought that there would not be "a bundle of cross-wiki notifications". Notifications from different lang wiki are grouped together always.

the "bundles" get their timestamp from the latest unread message in each of them, which puts them in the order of the master notification list in the popup.

It's logical - the timestamp on the most recent notification should be displayed for a 'bundle'.

3. Are we considering another subdivision of notificationсs inside lang wikis?

Here are some screenshots from Wikia's cross-wiki notifications:

As we discussed in our meeting, I think that the notification bundling should be a bit more flexible.

Thanks @Mooeypoo for the detailed example.

I think the key question here is which is the relevance of location compared to the relevance of time. That is, are the most recent notifications always the most important ones regardless of where you are accessing them from? are the notifications of the current project always more relevant than other notifications from different projects? something in between?

There is a whole spectrum of options depending on how important we consider location with respect to time. Some possibilities (from more to less importance to location):

• Show all local notifications first, then a single expandable item representing notifications from other wikis at the end (as illustrated in this ticket description).
• Show all local notifications first, then one expandable item for each project containing their notifications (similar to the wikia approach mentioned at T113228#1671266).
• Show local notifications and a single expandable item representing external notifications ordered by the most recent event (similar to what is proposed in this ticket but the "10 more alerts form other wikis" will be moving up as new notifications are generated in those wikis).
• Show local notifications and one expandable item per external site ordered by time.
• Show local notifications and surface one notification per external site with access to the rest (ordered by time). Similar to what s proposed in T113228#1667845.
• Show all notifications from all sites together ordered by time.

Each point in that spectrum has its own pros and cons. Giving weight to local notifications can work well for users that go to Commons to focus on information about Commons first, but may be problematic if many unread notifications in Commons hide more recent notifications from other sites. Giving weight to time, especially if notifications from different sites start to mix together requires for us to communicate where each individual item comes from (increasing the complexity of the panel) and for users to pay attention to that as they scan the list of notifications (e.g., when a user gets two similar thank notifications from edits to the "Pizza" article, the user needs to figure out one is from Italian Wikipedia and the other is form the English one).

Personally, I wanted to avoid adding too much complexity to items (indicating in each item where it comes from) so that they can be quickly processed as you could expect from a notification panel. I see the notification page as the place where we can provide more advanced filtering options, allowing users to filter notifications by project, time, or even elements involved (e.g., about an article or from a given user).
In any case, more information on how are users processing cross-wiki notifications currently, and the issues they have with the proposed model (in the form of a prototype) will help us to identify which is the right balance.

I created a prototype to illustrate some of the proposed ideas. Some notes:

• When the page is reloaded the notification count is reset, but when navigating across the simulated wikis (Commons and Spanish Wikipedia) the counter is preserved.
• It is easy to extend the prototype with new notifications. Please let me know if there is a specific example notification you would like to add to make the example more realistic.

More details on how to test these ideas will be added in T114086

I've been clicking around on the prototype. I had kind of an odd response to one element, and it might be something to think about.

Here's the path I took:

1. Starting at the first prototype screen. The panel says I have 3 more messages from other wikis.
2. I click on Stanley K's exploding lightbulb. Now the panel says I have 4 more messages from other wikis.
3. I click on Plants in Space. Now the panel says I have 2 more messages from other wikis.

Now, thinking about it logically, I understand why that's happening -- the meaning of "other wikis" changes when you hop from one wiki to another. (Commons and Spanish are "other wikis" when I'm on English; Commons and English are "other wikis" when I'm on Spanish.)

Still, that's a tricky concept to get your head around, if you're in the middle of it.

I think it's easier to process that information if it's in this form:

1. I'm on English. I have 3 messages on English, 2 messages on Spanish, 1 message on Commons.
2. I click on Stanley K's exploding lightbulb. Now I have 1 message on Spanish, 3 messages on English, 1 message on Commons.
3. I click on Plants in Space. Now I have 2 messages on English, 1 message on Spanish, 1 message on Commons.

I think that's easier to understand, because it's treating all of the wikis the same way. The concept of "this wiki" and "other wikis" requires more processing.

That being said -- I don't know exactly how you do that in the design, so I'm not suggesting a particular solution. :) But that was my reaction interacting with the prototype, and you can see if the same thing comes up when you're showing this in research sessions.

The concept of "this wiki" and "other wikis" requires more processing.

I think it makes sense to make the origin of the notifications more explicit to avoid users to get disoriented, but I'd try to do it without adding a whole layer of classification or presenting one specific item for each possible site, since we don't want to make the panel feel busy which may discourage people to check it often.

One option is to emphasise the projects over the notification count:

For the simple case where you get notifications from just one other external wiki, the notification bundle will represent that project ("Messages from Commons"). For cases where there are notifications from different projects the bundle will act as the "more" action to expand the view to the whole list of notifications.
I updated the prototype to check how it would work in the same example.

In any case, all this depends on the notion of location, participation in multiple projects and the patterns users follow to complete their tasks. So feedback from users will help us to better understand how much structure is needed when organising the different notifications.

Epic task which could be declared resolved at some point in a far away future, hence removing Tracking-Neverending tag.

This is not something Growth-Team will work on in the near-to-medium term.