There's no way to remove an item from Special:Notifications, e.g. by marking it read/trashed/spam. This is particularly troubling given the false positives rate of the notifications, but would be a bug in any case.
The X icon that appears on hover is not a way to remove the item (as I expected) but rather to change preferences on that kind of item; it's not offered for things that can't be disabled, like talk page notifications.

Special:Notifications is a log of all the notifications you receive. It's not designed to be curatable. (The designers strongly opposed an in-box type model for this.) Most of your interactions with the notifications should theoretically be taking place in the flyout from the red badge icon. That's where it might make more sense to have some remove functionality. Personally, I was thinking that it might be best for the flyout to just show all of your unread notifications (rather than X most recent) and automatically remove them all from the flyout after you close it. There's going to be another meeting on Wednesday to discuss this so let me know if you have any ideas.

I've already asked this in the past and heard no clear response: why should notifications be private? I see no reason for it.
I'm not saying to kill Special:Notifications, I just think that the read/unread feature you want for the flyout should be mirrored on the special page in the very same way for user experience consistency.
The user needing to see the full log of notifications including spam and vandalism is an edge case: logs belong to logs and "replace Special:Log" is an extremely bad requirement for the special page. No logging system duplication should be pursued, or the decision will probably have horrible and catastrophic consequences in the future, see the example of the AFT logs and other superstructures.

Anti-abuse measures are required for any feature of this nature. Not only the ability to remove notifications (or mark them as spam), but also the ability to block or ignore notifications from particular sources. If Echo does not have anti-abuse functionality built-in already, it's a blocker to further deployment.

Left some comments at Talk:Echo_(Notifications)/Feature_requirements. Anyway, let's get this bug discussion back on track. What sort of dismiss functionality would you like to see. There are lots of options:

There's also the possibility of dismissing notifications from particular users or regarding particular pages, but we decided that would overly complicate things since we would need to keep track of a lot of 'unsubscription' data for every user and give them preferences for changing all of those decisions (which would create a lot of complicated UX).

Also, should there be categories of notifications that are not unsubscribable? Right now there are two: 'System' notifications ("Welcome to Wikipedia", "You've been blocked", "You are now an administrator", etc.) and Talk Page Post notifications. For Talk Page Notifications we allow unsubscribing from email, but not from the web notifications. The thought here is that (1) we wanted to mirror the existing talk page notification system (2) we were worried about people accidentally turning off talk page notifications (3) is there ever a legitimate reason to turn off talk page notifications?

Add Comment

Text is available under the Creative Commons Attribution-ShareAlike 3.0 License; code is available under the GNU General Public License or other appropriate open source licenses. By using this site, you agree to the Terms of Use and Privacy Policy. · Wikimedia Foundation · Privacy Policy · Terms of Use · Disclaimer

Column Prototype

This is a very early prototype of a persistent column. It is not expected to work yet, and leaving it open will activate other new features which will break things. Press "\" (backslash) on your keyboard to close it now.