Jump to: navigation, search

About this board

This discussion uses Flow, a new discussion style similar to many internet forums. To add your feedback, scroll to the end of any comment and click "Reply", or type your comment in the box at the end of the thread, where it says Reply to "Feedback requests - Notifications badges, and grouping notifications by type". Or you can start a new topic, with the form on top of this page. That's all, pretty much.

By clicking "Add topic", you agree to our Terms of Use and agree to irrevocably release your text under the CC BY-SA 3.0 License and GFDL
Ymblanter (talkcontribs)

Thanks for the beta-feature, seems very convenient. The problem is that if I open it it shows all notifications as read (which I understand will be fixed later and is fine with me for the time being), but the number of unread notifications remains non-zero unless I actually go and read all of them one by one (this is from my experience in the English Wikipedia). In Wikidata, I get the FLOW talk page messages notifications in the same box, and there is a option to mark all of them as read without going to every page. If I click on that option, it resets the number of messages to zero. It would be great to have the same option for cross-wiki notifications. Thanks.

Ymblanter (talkcontribs)

BTW I am not a regular Mediawiki editor, and I hope the replies will show up on my notification window in other projects.

Roan Kattouw (WMF) (talkcontribs)

There is a "mark all as read" button, but that (deliberately) doesn't mark notifications from other wikis as read. However, you can click the "X" icons to mark individual notifications as read, and you can click the "X" icon next to the cross-wiki message (the "You have messages from 2 other wikis" thing) to mark all notifications from other wikis as read. Hope that helps. We realize "X" isn't the clearest symbol for "mark as read", so we're working on figuring out what to use instead.

And yes, my reply should show up in your notification window on other projects, if you enabled the beta feature there. That's the point of this feature ;)

Ymblanter (talkcontribs)

It did show up in my notifications. X was indeed not clear (and if I click on it the message disappears from the list - I am not sure whether it is good or bad, but the FLOW messages do not disappear if I click on read, and there should probably be a record somewhere), so I would appreciate a clearer visualization, but for the time being it should be fine. Dank je wel Roan.

Roan Kattouw (WMF) (talkcontribs)

Yeah, the fact that they disappear is not that clear. It's consistent, because only unread foreign notifications are listed (so once a notification becomes read, it isn't listed any more), but you're not the first person who's expressed that it confused them.

As for the Flow messages -- the difference there is "local" notifications (notifications from the wiki you're on) vs "foreign" ones (notifications from other wikis).

As for keeping a record somewhere -- there is one, but it will be on the wiki the notification came from. So notifications about this conversation, once you've marked them as read, won't appear on other wikis any more but you can still see them on this wiki (

Ymblanter (talkcontribs)

Sure, but for example today I got a notification from Sundanese Wikipedia. I am sure in a week I will not be able to remember what the hell this project was. In this case, it was a usual greeting, I probably accidentally created a user account there, and it is not at all important, but I can imagine that in some situations it could be handy. This is absolutely not the first priority, but if this "global record" could be made I would appreciate it. (May be it comes for free with the global watchlist, I do not know).

Roan Kattouw (WMF) (talkcontribs)

That's a sensible request. We're going to work on improving Special:Notifications next, and something like this could be included there. It may be tricky from a technical perspective, though, because we don't currently have good tracking of read notifications (as opposed to unread ones) across wikis.

Ymblanter (talkcontribs)

Great, thanks.

Reply to "Read notifications"

Feedback request - Notifications badges, and grouping notifications by type

Summary by Trizek (WMF)
This discussion uses Flow, a new discussion style similar to many internet forums. To add your feedback, scroll to the end of any comment and click "Reply", or type your comment in the box at the end of the thread, where it says Reply to "Feedback requests - Notifications badges, and grouping notifications by type".
Quiddity (WMF) (talkcontribs)

A translatable version is at Notifications/Sorting schemes

The overall task is: Deciding how to sort the notification-types (e.g. "new usertalkpage message", "your edit was reverted", "a page you created has been linked to", "thanks", etc) into 2 groups. The current sorting has some problems. There are 2 more logical alternatives which the team is trying to decide between, and wants your feedback on (your preferences, or concerns). The recommendation is we start off with the "By urgency" grouping.

Please share your feedback at the Phabricator task or here on

Problem to solve

There are currently two Notification fly-out menus, one for Alerts and one for Messages. Different notification types show up on different menus. There have been criticism over time that the scheme for dividing up the messages is unclear and/or inconsistent. These criticisms include the following:

  • Ideas of "urgency" and "requiring follow up" are mixed together, making it difficult to explain or predict why different items are in each fly-out.
  • Currently, "Alert" items are automatically "marked as read" on opening the fly-out. Yet some of these require follow-up or other action to be fully understood (e.g., Mention), so this feature's value is not always clear.
  • Because "Alerts" are perceived as "Urgent", the "Thanks" and other items seem out of place in that fly-out.


  • To create a scheme that is easy to understand, learn, and predict.
  • To give editors clearer information about their new notifications.
  • To reduce unnecessary distraction from non-urgent notifications.
  • Something that works well for editors who get large (and small) quantities of notifications.
  • Something that scales well, as new (requested) notification types are created.
  • Something that scales well, once cross-wiki notifications are available.


See examples of the most common notification types at File:Notifications Catalog.png.


  1. Current
  2. Urgent versus Non-Urgent
  3. Follow-up versus No follow-up (is a reply needed/likely)

(This table has no annotations, and just shows the most common notification-types. See a more detailed version here at googledocs which also includes a 4th (more complicated) alternative.)

Three Alternative Schemes for Separating Notifications into the 2 Different Fly-Out Menus
View Mockup of this Concept in Action View a Mockup of this Concept In Action
welcome edit-user-talk edit-user-talk welcome welcome edit-user-talk
reverted flow-new-topic reverted page-linked page-linked reverted
page-linked flow-post-reply mention edit-thank user-rights mention
mention flow-post-edited user-rights flow-thank edit-thank flow-new-topic
user-rights flow-topic-renamed emailuser flow-new-topic flow-thank flow-post-reply
emailuser flow-mention flow-post-edited flow-post-reply flow-topic-renamed flow-post-edited
edit-thank flow-mention flow-topic-renamed cx-first-translation flow-mention
flow-thank cx-first-translation cx-tenth-translation emailuser
cx-first-translation cx-tenth-translation cx-hundredth-translation
cx-tenth-translation cx-hundredth-translation
Ideas of Urgency and Follow up are mingled in ways that are inconsistent, making this difficult to explain or predict. Division, while subjective, is clear and will track with some users' expectations (given the red badge color). The division is subjective. Given differing working styles, some users will disagree with assignment of individual items. Division is relatively clear and explicable and tracks with a hypothetical use case ("I'll just check these all quickly now.") Division, while relatively objective, is nonstandard and may be difficult to label simply for users. ("Alerts" vs. "For Follow Up"?)
Because some "Alert" items require follow-up and are not self-contained (e.g., Mention), ability to Mark as Read on open is of questionable value Factor of urgency may provide an aid to triage ("check these first") Ability to automatically mark as read is appropriate and can be preserved. The main shortcoming of this scheme is that it doesn't give users any information about urgency. So, the question is, which would users prefer to be informed about: "I have some items I can dispatch quickly (which this does), or "I have some items that are important" (for which there is no indication).
Because alerts are perceived as Urgent, Thank Yous and other items seem out of place. Fairly close to current scheme We've discussed adding a "pinning" feature to notifications. When we do, that might make this divsion less valuable.
In this scheme, an effort was made to determine the messages that users would want to know right away vs. those that they may regard as less pressing. Urgency was more or less arrived at by consensus in consultation with various team members. What to label these: "Alerts" works reasonably well, since it does carry a connotation of urgency. But many of the Alerts are arguably Messages as well (e.g., edit-user-talk). Suggest "Notices" as not sounding to deprecatory but connoting a lower level of urgency. The division here is based on the idea that some messages are relatively self-contained and can be fully understood based on the info in the notification, while others require follow up simply to understand what happened. Flow-new-topic is marked as requiring follow up. This is a very common type and not that vital, so a good candidate for automatic Mark as Read. If we use this scheme, we might want to reclassify Flow-new-topic, which is questionable for Requires Follow Up anyway...
The red, "Urgent," badge color for Alerts is recommended for this scheme. In labelling the non-urgent items, we need to be careful that some groups (e.g., Translation) don't perceive that we are labelling their activities less important. Talk, Mention and Revert are the most clicked on notification types according to the graph linked to below. So, segregating them For Follow Up seems to make sense. [1]
Many of the Urgent (Alert) items require follow-up (e.g., edit-user-talk), so use of automatic Mark as Read is not recommended. Since urgency is not the dividing line, would recommend not using red for Alerts.
Whatamidoing (WMF) (talkcontribs)
This discussion uses Flow, a new discussion style similar to many internet forums. To add your feedback, scroll to the end of any comment and click "Reply", or type your comment in the box at the end of the thread, where it says Reply to "Feedback requests - Notifications badges, and grouping notifications by type".
Trizek (WMF) (talkcontribs)

@Whatamidoing (WMF), I've copied this banner on the topic summary on the top of this conversation.

Jmorgan (WMF) (talkcontribs)

Remind me: is the currently implemented sorting solution "reverse chronological order by date/time"?

Quiddity (WMF) (talkcontribs)

@Jmorgan (WMF) within each of the 2 panels/flyouts, yes, that is the order that old read-notifications are displayed in.

However, in the 2nd ("Messages") flyout, unread-notifications are kept at the top. That is one of the factors (i.e. should the "Alerts" flyout continue to "mark all as read" as soon as we open it?) in this overall bigger question, of how we divide the notification-types, between each of the 2 panels.

Jmorgan (WMF) (talkcontribs)

Thanks, I understand a little better now @Quiddity (WMF). 'nother question: how do you determine what is an "alert" vs. a "notice" (or an "alert" vs "for follow-up"? I ask because (to take one example), "edit-thank" appears as an Notice in option #1, but an "Alert" in option #2.

Reply to "Feedback request - Notifications badges, and grouping notifications by type"

Update about on-going work on Notifications, especially cross-wiki notifications

Quiddity (WMF) (talkcontribs)

Hi, this is an update on the work we in the Collaboration team are doing. Our focus is on cross-wiki notifications and other back-end improvements to that system. Our long-term goals are to make various improvements to the Notification system.

Notifications are at the core of many different on-wiki activities. Making notifications easy to find and use can help those processes. We are focusing our immediate plans on supporting cross-wiki notifications. These will help editors stay informed about the changes they care about on every Wikimedia project on which they work. This is especially important for the editors who work on more than one wiki. Examples include if you upload to Commons, curate on Wikidata, or edit in two or more languages.

The team has spent the last few weeks researching the existing and proposed features. This has included examining existing tools such as Crosswatch. We've been considering the problems of:

  • technical performance (scaling the requests across 800+ wikis),
  • user preferences (both existing and desired),
  • user interface design possibilities (how it should work),
  • how to release an initial, user-testable version for feedback and improvement, and
  • how to measure the impact of the project (reducing the time it takes to process a notification).

We are also doing user research via 1-on-1 interviews. In these we ask active editors about their current notification usage and pain-points. Using a prototype we are evolving, we get feedback on directions to take the design.

Details and further reading

You can read more about the technical details at: Requests for comment/Cross-wiki notifications.

Some of the new backend improvements to Echo: phab:T107823 ("Rewrite EchoNotificationFormatter") and linked tasks.

User preference options are:

User interface design possibilities cover several questions. For example, how should cross-wiki notifications look within the pop-up? How and when should we add enhancements to the Special:Notifications page to filter things? We are drafting and discussing these in:

  • phab:T114357 (Clarifications to the currently confusing "primary/secondary" link, and proposed future enhancements)
  • phab:T114356 (Bundled notifications)
  • phab:T115264 (Controlling notification 'volume' based on the type or location)
  • phab:T115845 (Clearer use of the notification badges (colored number in personal toolbar))
  • phab:T115316 (Better organisation of the Special:Notifications page)

Note: Most of these are not part of the cross-wiki notifications feature. We won't for sure roll all these out together with the main change.

We started user research at phab:T114086 and it continues at phab:T116741 . (Note: You can sign-up as a volunteer at .)

A user-testable release is still just in planning. We decided on a Beta Feature on each wiki as the most scalable and least confusing of all the do-able options. Read our plans in phab:T114237 ("Present cross-wiki notifications as a beta feature to users"). This will help users to try the feature anytime, disabling it if it interferes with their work in some context, and easily suggest how the tool could be improved.

There is no system for users having or setting cross-wiki preferences. Waiting to building this would take a long time. For now, we plan to let you enable the Beta Feature at each wiki on which you want to test it. This will let you have a small-scale Beta Feature that you can all try out. We will be able to discover bugs, edge-cases, iterate more, and get even more feedback. Later, when we know what features you need, we can build such a cross-wiki preferences system (including the task linked above).

Whilst you wait, we would love to hear your feedback on the above. What comments, what design ideas, and what technical concerns do you have? Please tell us on the linked tasks if you can.

I'll send further updates, when the planned Beta Feature is about to be ready.

On behalf of the Collaboration team, thank you to everyone who has given your help already.

Reply to "Update about on-going work on Notifications, especially cross-wiki notifications"
Subfader (talkcontribs)

Remove "new topics" notification if they get deleted

Quiddity (WMF) (talkcontribs)

This task is tracked at Phab:T93673

Reply to "Don't notify me about deleted topics"

Is it that one can only mention as many as 10 people

Bluedeck (talkcontribs)

in a single edit?

Quiddity (WMF) (talkcontribs)

Most of the templates have a 5 or 10 parameter limit (e.g. this wiki's Template:Reply to has a 5 user limit, per instance).

Echo itself, currently has a 50-user limit. Any more than that, and the edit is assumed to be spam or an error, and no notifications are sent.

There are a few feature-requests for improving the current system, particularly Phab:T68078 and Phab:T108293.

Reply to "Is it that one can only mention as many as 10 people"
PeterEssexHeritage (talkcontribs)

I would like the option to receive notification by email for any event. This would mean that infrequent users, like me, would not have to log-in to the Wiki to check things.

The emails should include as much information as possible about the notified event, in the email body.

The emails should keep being sent, even if the user hasn't logged-in to check the previously notified event.

Quiddity (WMF) (talkcontribs)

Thanks for the suggestion, and the detailed use-case explanation on phabricator. :)

As you probably saw, I've merged the task you filed, into the older task (Phab:T114587 into Phab:T33928).

That said, Echo is not part of the software used for sending these watchlist notifications - Echo is an extension that is only ~3 years old, and watchlist notifications are part of "core" mediawiki. However, there have been discussions about changing that, and hopefully things will change in time, as the developers decide how to best handle these things.

Hope that helps.

PeterEssexHeritage (talkcontribs)

Thanks, Quiddity.

I would also like my comments here to be taken into account for all Echo notifications, as well as Watchlist notifications.

As a relatively infrequent user, I would like to monitor everything from my email client without logging-in to Wiki - email is where many of the notifications I receive about other things arrive.

Ideally, the emails would have taglines in the subject, or be from a specific email address so they can be automatically filed for checking together.

Reply to "Email Notifications for Everything!"
Subfader (talkcontribs)

2 years later there is still no watchlist support?

I plan to add Echo on my wiki, but this will be the first thing users will miss.

PeterEssexHeritage (talkcontribs)

Email Notification for Pages on User's Watchlist

The current system of email notifications for pages on a user's watchlist needs improvement:

- It is not clear which types of edits (normal, minor, or bot) will trigger emails.

- Because the notification emails stop if a user doesn't visit the changed page while logged-in, it can be difficult to report any problems with the notification emails, because the reporter will always be asked if they are sure they visited the page.

- I would personally like a notification email for every change to a page on my watchlist, whether I visited the page after the last change or not.

- The current system has reported bugs.

See the following tasks in Phabricator: - Enotif doesn't send email if page on watchlist edited following a minor edit and enotif not configured to send minor edits. - Minor bot edits don't trigger email notifications even with "E-mail me also for minor edits of pages" selected. - Wikipedia Watchlist Notification Emails Not Arriving. - Email notification for every single change to a page on watchlist.

Reply to "Watchlist notifications"

Splitting notifications into Alerts and Messages

Quiddity (WMF) (talkcontribs)

Next week's software update will include the first steps of some significant updates to the Echo system. We need your feedback, to plan the next steps.

There's going to be a change to the icon that opens the flyout, (the list of items etc). There will be two icons: one for alerts and one for messages. (see phab:T108190 for extensive details). You can see an example here:

The first flyout ("alerts") will still contain most of the notifications, for now.

The second flyout ("messages") will contain notifications about your new usertalk-page messages (and flow messages on the wikis using it).

This change is based on longterm feedback from highly active editors, that they would like a clearer indication than just a "red number", of what type of notification is waiting for them. (See phab:T58476 and linked tasks.) A number of options were suggested, and this is the first step towards that.

We'd appreciate further feedback on this change: What other notification types should be moved into the "messages" section? The list of existing notification types includes: usertalk messages, thanks, mentions, page-links, page-reviews, edit-reverts, system messages. There are more types being discussed.

(Some editors have suggested splitting every single notification type into a unique icon, but there are already a dozen sub-types of notification, with more expected in the long-term, so that is unfeasible.)

Thank you!

Side-note: Work has also begun on Cross-wiki Notifications (phab:T67661).

בנימין (talkcontribs)

A very good idea! Much more convenient than the current notifications system.

Davidwr (talkcontribs)

Make it a "preferences" choice.

I would like to see each type of message have 4 choices: "alert icon" (which would need to be developed), "notice icon", "message icon", and "off."

If it's not feasible to have a separate choice for each type of message, then at least consolidate messages that are logically similar to each other in one group. At a minimum, I can see 3 "groupings": 1) messages on your talk page, 2) notices/messages that mention you by name such as en:Template:ping, and 3) everything else. A possible 4th grouping would be "official notices," but that would require a way for functionaries to mark a message or other notice as "official."

Nyuszika7H (talkcontribs)

I agree, separating mentions and things like thanks would be nice.

Quiddity (WMF) (talkcontribs)

I've just updated the main project page, with a complete list of all the existing notification types, and a complete list of all the proposed/partially-developed notification types. ("complete" as far as I could find). That should help give more context to the scale of the potential increase in the long-term, and clearer details for this discussion about how to group the existing notification types.

Personally, I'd also like to see the "mentions" and the "course talkpage edited" moved into the "messages" list, plus any future notifications that involve discussion/signatures and where a discussion-edit is the expected or desired response.

Johan (WMF) (talkcontribs)

There's a discussion on the Swedish Wikipedia Village Pump where several users have said it would be nice to be able to choose between one and two flyouts. I've replied to the discussion and pointed out that they're welcome to add feedback here as well, if they want to.

Nizil Shah (talkcontribs)

I like the change but now we have three titles of conversation pages: Talk (eg. Wikipedia), Discussion (eg. Wikidata) and now Messages in Notification. Can we unite all three in one title? Separate Alert is good than all combining Notifications.

And yes, crosswiki alert is much awaited. :)

Nizil Shah (talkcontribs)

And yes what will happen to Notifications in Mobile view? They still not divided.

WhatamIdoing (talkcontribs)

I am so happy about this change. It makes dealing with in particular much easier, because I can see at a glance, without clicking, whether the notification is yet another thread (I've got a pair of active pages on my watchlist) or someone actually looking for me. This is great.

DESiegel (talkcontribs)

I would like to see this change reverted. I found the combined list easy to deal with, now there are two separate things to deal with. But more importantly, the previous lsit could be opened as a separate page in a separate browser tab, whcih is whow I routinely did it, leavign the tab open asa I attended to the various notifications. Now I can't do that, and I see thsi loss of functionality asa larger than any possible gain from differing icons. I also feel that the additional space the icon takes up isn['t sorth it. Can a user preference be added that woudl restore the old system, please? ~~~~

Quiddity (WMF) (talkcontribs)

The bug about not currently being able to easily open special:notifications in a new tab, is tracked at phab:T112004. Sorry about that. In the meantime, you can click the link at the bottom of either 'flyout' menu, "All notifications".

Nikkimaria (talkcontribs)

I also would like the option to use the old version, please. I find the new version takes up a lot of space, among other issues.

Jdforrester (WMF) (talkcontribs)

[Reposting on behalf of Peridon for whom the "Reply" button apparently doesn't appear]

As I can't find any other way into this not exactly clear threading system, I'm posting here. I'd like to have an opt-out as well. I use Monobook as I find Vector appalling, and those two black blots on their little grey boxes are distracting. I also can't see any point in separating the lists. Previously, you needed one click to see all. Now, if you have both sorts of notification, you need two clicks. That's progress? Looks more like finding something to twiddle... This is Peridon, as the signing code doesn't work, and I can't find a way to start a new post. I would like an option to open in a new window, never mind tabs. I hate tabs. I can find no way of signing or making bold on this page, so <bold>Peridon</bold> 17.28 BST 11th September 2015 will have to do.
Jdforrester (WMF) (talkcontribs)

[Reposting on behalf of Peridon for whom the "Reply" button apparently does appear, but they choose not to use it.]

I didn't consider myself to be 'replying', I considered I was 'posting'. Gawd knows where this comment is going to go... Ah. There's a </> thing that reminds me of those esoteric symbols on clothing labels - supposedly clear for all languages but understood by none.

[Peridon, please stop editing other people's comments. On most wikis such actions are very much frowned upon and might even get you blocked. :-)]

Nyuszika7H (talkcontribs)

On the Hungarian Wikipedia, the text in the new notification flyouts seems to be all lowercase:

Roan Kattouw (WMF) (talkcontribs)

That's likely due to local CSS, I'll look into this later today.

Roan Kattouw (WMF) (talkcontribs)

This change should fix it; it'll take 5-10 minutes for it to propagate though.

Peridon (talkcontribs)

It would be rather nice to get a little help with editing on what to me is a foreign system. I don't frequent MW - the notifications I received when signing in here were from four years ago. I saw ... at one side of a post with the option to edit, and 'Reply' at the other. Not wanting to reply to the actual post I went for the ... with Edit. This method of operation may be common in forums and places like Facebook that I don't frequent either. A little bit of helpful advice on where to click would be similar to the advice I am frequently giving to newbies to wikicode and procedure at enwiki. If this is Flow, I am very glad we apparently aren't getting it. If it's something else, you can keep it here and I'll stick to enwiki completely. If this ends up in someone else's post, you can move it or leave it, and block me or not as you choose.

So that's how it works. To others, probably logical. To me, counter-intuitive.
PerfektesChaos (talkcontribs)

I do appreciate the separation into alerting and less urgent issues.

I would recommend the following classification, ignoring the interpretation that a blue bubble is reserved for conversation:

  • thanks
    • Definitely not alerting, shall not distract from work.
    • blue
  • own talk page
    • May trigger orange bar, too, if not out-opted.
    • Also present on watchlist.
    • Keep blue, even if important for me.
  • page-link
    • Please do not bother me.
    • blue
  • page-review
    • Fine, like thanked, but I would not feel urged to react if I would be a newbie.
    • blue
  • edit-revert
    • Ooops. What's going on here? Scandal! Who the f...
    • RED
  • system message
    • My user rights changed? Revocation or advancing? Pretty important.
    • My email is changing, or my password or whatever? Not on a daily base.
    • RED
  • email was sent to me
    • T56130 is heading for that.
    • Seems to be an important private message.
    • RED
Dhtwiki (talkcontribs)

This multi-colored scheme is what I think would be helpful, but possibly with green for "Thanked", and possibly other types where blue has been suggested.

Quiddity (WMF) (talkcontribs)

Temporarily reverted

We've had to temporarily revert the Echo changes due to an unintended performance regression (phab:T112401) and a severe bug for Safari users on Commons (phab:T112552). Very sorry about the disruption. :-(

Please continue to give suggestions on ways to group the various notification types, to ease the horror that many editors feel at a regularly refreshing/incrementing red-badge that they're never sure if it's urgent or not, or might want faster access to. A partial list of proposed notification types is at Echo (Notifications)#Suggested new notification types, with more to come. Much thanks to all who have, already.

DrKay (talkcontribs)

There seems little point in having a separate "Talk" link as well as the message notification button. They seem to serve much the same function: notifying you of a message (with an orange bar in one case and a blue flag in the other) and both linking to the same page.

PerfektesChaos (talkcontribs)


These are two issues:

  1. The orange bar, which alerts me that something happened to my own talk page, which concerns me personally.
  2. The blue field, which indicates that one of many less urgent events happened. For the moment and on your wiki there might be no other activity, but I presume this will change quite soon. Please see the text above.
Ningauble (talkcontribs)

Much ado about nothing. Foundation resources and volunteer efforts are not being well spent on this sort of fiddling with the interface.

CFCF (talkcontribs)

Great improvement, hope you get it running soon again. I don't really think it needs more tweaking than this, these are the two main notification types.

The Drover's Wife (talkcontribs)

This is receiving a significant amount of criticism and should never have been implemented without an RfC and an actual consensus to implement. It should be opt-in if existent at all. I came here wondering why the site had been fixed and was a bit shocked that those responsible had actually listened and was upset to discover that it had just been because of a bug.

IJBall (talkcontribs)

I'd personally like to see the various different types under 'Notifications' (in the new system) leading to a "color coded" Notification icon: e.g. Reverts=red, Thanks=green, Mentions=blue (or some other color), etc. If you can get the new system to do that, I'll consider it a fairly significant success as it would be much more functional, and a definite improvement over the old system.

Quiddity (WMF) (talkcontribs)

@IJBall, Thanks, and that's been suggested before, with comments and links to older onwiki threads at Phab:T57359 - iirc the main difficulty is regarding how to color the icon, if there are multiple types of new notification, though if there was a hierarchy of importance we could potentially just use the color of the highest-priority (e.g. 'red' types would take priority). There were also some concerns about added code-complexity, but I'm not sure how severe those were.

WhatamIdoing (talkcontribs)

The bugs have been marked as resolved. How much longer do we have to wait to get this back?

Mooeypoo (talkcontribs)

The code will be pushed in the next deployment train on Tuesday (to MW) and Wednesday everywhere else.

Roan Kattouw (WMF) (talkcontribs)

Slight correction: it'll go to on Tuesday (today), to non-Wikipedias on Wednesday, and to Wikipedias on Thursday.

Dan Mihai Pitea (talkcontribs)

Has anybody given consideration to the fact that the color red might increase aggressiveness in Wikipedia users?

Trizek (WMF) (talkcontribs)

@Dan Mihai Pitea That's why we want to split notifications between alerts (red) and messages (blue).

WhatamIdoing (talkcontribs)

I'm so glad that this is back. Now I can go to Mw: and see at a glance that there's really only one thing for me, and everything else is basically a watchlist item (new Flow threads on multiple pages). Thanks.

Reply to "Splitting notifications into Alerts and Messages"

Splitting notifications feedback... great idea! (not sure how to reply to proper thread or where to type body of message)

LT910001 (talkcontribs)


Copied proposal from English Wikipedia "WP:PUMP" discussion

GregKaye (talkcontribs)

Not knowing where else to post I started a discussion at Wikipedia:Village pump (proposals) with the following content:

= Propose that the, top of window, [icon #] [icon #] links follow the text based links to which they relate =

Currently we present:

:<big>♣</big> Name&nbsp; [icon #] [icon #]&nbsp; Talk&nbsp; Sandbox&nbsp; Preferences&nbsp; Beta&nbsp; Watchlist&nbsp; Contributions&nbsp; Log out

'''Basic proposal'''

The [bell #] symbol relates to <s>a user's</s> an editor's login so as to mainly present alerts on locations that the editor has been mentioned in (simultaneously signed) pings.  To state the obvious, thanks given for on referenced edits (at points where the User name is also displayed) are also listed amongst alert notifications.

The [speech bubble #] access to "Your messages" notifications relates to contributions to the "User talk:" page of the editor.   

The proposed sequence of links would present:

:<big>♣</big> Name&nbsp; [icon #]&nbsp; Talk&nbsp; [icon #]&nbsp; Sandbox&nbsp; Preferences&nbsp; Beta&nbsp; Watchlist&nbsp; Contributions&nbsp; Log out

'''Proposal with spacing adjustment'''

At present the two [icon #] [icon #] are presented close together and the initial head and shoulders icon also appears to me to be presented relatively close to the user name text with greater spacing is provided between the other links.  I would suggest that each [icon #] link could be presented with similarly close proximity to the related and preceding link.  This would present:

:<big>♣</big> Name [icon #]&nbsp; Talk [icon #]&nbsp; Sandbox&nbsp; Preferences&nbsp; Beta&nbsp; Watchlist&nbsp; Contributions&nbsp; Log out

I think that the basic change proposed will present the links in a more intuitive way.


I'm not sure if this is the way to sign here but - ~~~~


PerfektesChaos (talkcontribs)

I am not sure whether I understood correctly what you describe and suggest.

I learnt that you want to have these Icons mixed with textual links between.

Please note two aspects:

  1. The two Icons are just a filter of two views on only one and the same thing, the Notifications.
    • There are the alerting messages,
    • and there are the less urgent messages.
    • Consequently, the red and blue are kept close together and should be regarded as one unit.
  2. The current subdivision available for you might suggest that the blue field and the [Talk] have always the same contents.
    • That is not the case; not on all wikis and not in eternity. While the blue field does also contain flow conversations like this right now, it may count for all less urgent things which are currently still appearing as red alert.
    • [Talk] is about your personal page only.
Reply to "Copied proposal from English Wikipedia "WP:PUMP" discussion"