This seems nice. I wonder if we should always just show the full "$site - $lang" (or just $site if it's multilingual) though, rather than attempt to omit details where it'd be unambiguous.

I am more interested in crosswatch:
https://tools.wmflabs.org/crosswatch

But it seems to have been abandoned. It was improving rapidly, but lately suggestions have been ignored here:
*https://meta.wikimedia.org/wiki/Talk:Crosswatch

This notifications tool seems to be having similar problems in how to present the items. Grouped, chronological, and most important, scannability:
*https://www.google.com/search?q=scannability
*http://www.sitepoint.com/5-steps-scannable-lists - great article. The most important point in that article:

"So, for example, you might try to make all the list items fit on single lines, so that the eye can take in their initial words all at once."

Maybe someone can make all the list items fit on single lines on crosswatch too. By getting rid of the margins. At least provide an option for it.

In T114350#1800031, @Krenair wrote:

This seems nice. I wonder if we should always just show the full "$site - $lang" (or just $site if it's multilingual) though, rather than attempt to omit details where it'd be unambiguous.

I think it is a valid point. My preference was on making it more contextual, based on the assumption that most users won't be involved in a high number of projects (or not getting frequent notifications from all of them). For example, for users participating on Wikipedia on several languages, they may perceive these notifications as notifications from different languages. In addition, the fact that we have language-specific projects and multilingual ones already adds some variability in how we label them (e.g., it does not make much sense to indicate "Commons - all languages").

Having said that, since this is expected to be exposed as a beta feature (T114237) we'll have a better idea on how these are use in practise (with real notifications based on real on-wiki activities). That would be very useful to identify any confusion with this, and adjust accordingly.

In T114350#1805591, @Timeshifter wrote:

I am more interested in crosswatch:
https://tools.wmflabs.org/crosswatch

The notification panel is intended to provide a quick overview of the recent activity.
For advanced access to the different notifications (e.g., using filters to get all the notifications involving a given page or user), we plan to extend the notification page (T115316) which can be accessed from the "View all notifications" link in the notifications panel. This is still far in he roadmap (mockups are just illustrating early concepts, so don't take too literal) but it is intended to cover an area more comparable to crosswatch.
So we are really interesting on knowing about the usecases that you have experienced related to managing notifications (those that worked well with crosswatch and those that didn't). So feel free to provide any examples in T115316.

This notifications tool seems to be having similar problems in how to present the items.

Note that this specific task is for showing additional details about notifications from other wikis. The external notifications here are intended as a detail list to be expanded not as part of the main list. As I mentioned above, the notifications page can be useful to operate with all notifications regardless of their location at the same level.

@Mooeypoo, I added info in the ticket about colors, borders, shadows and other details:

Lat me know if any other detail is needed.

@Pginer-WMF: What should we do when the labels of foreign notifications are too long to fit on one line? In the current (unmerged) code, we truncate these labels to one line with an ellipsis, but that makes some notifications pretty uninformative:

If I remove the CSS rules that perform this truncation (white-space: nowrap; overflow: hidden; text-overflow: ellipsis;), it looks like this:

(Ignore the fact that unread foreign notifications are being shown, there's already a patch for that over at T119890.)

In T114350#1874980, @Catrope wrote:

@Pginer-WMF: What should we do when the labels of foreign notifications are too long to fit on one line?

I'd not force truncation here. Some thoughts:

• Notification text is expected to be already compact, and truncating it can result in missing relevant information.
• We can increase the width of the panel a bit to reduce the chances of notifications to require multiple lines.
• For cases where we want to surface user generated content we may want to do some truncation. For example, if we want to surface text from a user message instead of just announcing that you have a new message. But that is probably a case to consider separately since we are not supporting this in any notification type yet.

Questions came up about how many wikis should be shown in one cross-wiki bundle, and how many notifications should display for each wiki. Pau suggests the following as a starting point:

• No limit on the number of wikis shown (i.e., show all wikis that have UNREAD notifications).
• Apply the the same limit for each wiki as we use for the panel overall (i.e., 25) with the difference that we will show only UNREAD notifications.

One question, what happens in this cases:

• At mediawiki, I disable Flow notifications.
• At wiikidata, I enable Flow notifications

Now, if I open the cross-wiki bundle in mediawiki and wikidata, different things could happen,, either Flow notifications of the other Wiki are shown or the are not, depending of the notification settings of the Wiki you got the notification or the settings of the wiki you read the notification are applied. What would happen?

@MGChecker that is an interesting question. Our current thinking is the following:

• Cross-wiki notifications act as a window that let you see whichever notifications you have in another wiki.
• Notification settings allow you to adjust which notifications you receive in the current wiki.

In your example, you indicated that you are not interested in the Flow discussions about mediawiki issues. Thus, those are not visible from anywhere: You won't view them at mediawiki. You don't view them inside the cross-wiki bundle at wikidata or any other wiki.

Similarly, notifications related to Flow discussions about wikidata topics are visible from everywhere: the notification panel on Wikidata and the cross-wiki notification bundle on every other wiki (including mediawiki). Initially, since cross-wiki notifications will be exposed as a beta feature, you'll have to explicitly enable the feature in each wiki you want to view the cross-wiki notification bundle.

I think the above model meets the basic user expectations and it is a good starting point. It is totally possible that we identify that a greater degree of control is needed as we observe how the feature is being used in practice.

Really inetresting. I like this model really much, because it allows the user most possible control which notifications he wants to see. The only problem I see in this model that the overview about the settings in the different Wikis can get lost, but I think this is more a general problem of our current preferences.

On the use of the word “More” for the bundled message notification:

The message on the bundle at present is “More messages from Commons...”

I'd submit that the “More” here is extraneous and, in fact, confusing, since it's entirely possible that at times the ONLY messages will be from other wikis. e.g.,

I propose the message simply be “Messages from Commons” or “Messages from Commons and other wikis” It's cleaner and more clear.

Also, a question: in this example, is Commons called out because it is a) the wiki on which messages were received first or, b) the wiki on which the most messages were received?

@Pginer-WMF, I wanted to clarify what you said on Dec 14, 2:41 AM, above (and copied below), just to make sure I've got it right: You're saying in grouped or bundled x-wiki messages, don't truncate (which I agree with). So, basically, in terms of the information that's in the V 2.0 Notifications Spreadsheet, we're saying use the entire Header text, but omit the Body text.

Also, as long as we're talking about how these should look, we're saying put all the secondary links into the "..." menu. Is that right?

I'd not force truncation here. Some thoughts:

• Notification text is expected to be already compact, and truncating it can result in missing relevant information.
• We can increase the width of the panel a bit to reduce the chances of notifications to require multiple lines.
• For cases where we want to surface user generated content we may want to do some truncation. For example, if we want to surface text from a user message instead of just announcing that you have a new message. But that is probably a case to consider separately since we are not supporting this in any notification type yet.

(@Etonkovidova, making sure you saw this, since we were discussing the other day.)

In T114350#1987575, @jmatazzoni wrote:

On the use of the word “More” for the bundled message notification:

The message on the bundle at present is “More messages from Commons...”

I'd submit that the “More” here is extraneous and, in fact, confusing, since it's entirely possible that at times the ONLY messages will be from other wikis.

The idea was to use "More" only when there is more than one message. As illustrated in the "One-item bundle" section, the message in that case does not include the word "more" since there is only one item inside it. I think that "More" emphasises the idea that you will find additional items, marking the bundle item as an access point to those and not yet another notification. If we anticipate some issues with the word, we can consider removing it, but I have not seen any confusion related to it when we tested with users.

Also, a question: in this example, is Commons called out because it is a) the wiki on which messages were received first or, b) the wiki on which the most messages were received?

The idea is to show the one that has the most recent notification. That will be also the group on top that is shown when expanding the bundle.
This allows the following:

• Keep some consistency with the chronologic order the whole panel follows.
• Have an idea of what's new before opening the panel.

For example, if I notice that the cross-wiki bundle text changes from "More messages from Commons and other wikis" to "More messages from Spanish Wikipedia and other wikis", I know that something new happened in Spanish Wikipedia and that may inform my decision of checking the contents if I'm involved in more urgent activities there. When I expand the cross-wiki bundle, the notifications from Spanish Wikipedia will be shown first (with the recent one on top and possible other older unread notifications).

Also, as long as we're talking about how these should look, we're saying put all the secondary links into the "..." menu. Is that right?

Yes.
What some of the mockups are missing is the timestamp, which we are decided to include (although a more compact representation for timestamps could be useful in general, but that is a different story).

IIRC, we had a not that good feedback concerning the "..." menu. Or, at least, I've read comments concerning that menu, where people don't understand that is a menu.