Talk:Notifications/Feature requirements

Flyout thoughts

1. New versus unread - why the distinction here? If it's a distinction in how we handle things ("new" versus "unread" versus "new and unread"), I'm not sure if new is worth distinguishing at all: If I have a dozen unread messages and two dozen read ones, some of which are new, I don't particularly need the system to (for example) prioritise the read-but-new ones. I've got unread stuff to deal with: that's my priority.
2. Re mentions, it seems to make more sense to link "this page" rather than explicitly mention a page. Wikipedia and talk pages (which are, realistically, where these messages will be used - people tend not to mention editors in article text) can get incredibly long. This also applies to things like deletion tags - if someone posts a copyvio note and you paste the entire, potential URL into the notifications window, it's going to get to be a very long window, particularly on mobile or tablet devices.
3. On mentions: what are we doing to compensate for the "someone who has a user name that matches an article/real world person" problem? An example would be en:User:John lilburne. Okeyes (WMF) (talk) 08:51, 6 November 2012 (UTC)

Positive Notifications for Echo

Hi guys,

We would be grateful for your advice on how to give more positive notifications to new users after their first edits.

We're looking for notification ideas that could lead new editors towards a "happy path" to encourage further contributions. Many studies have shown that positive reinforcement plays an important role in increasing a user's productivity, and we would like to provide at least one or two good solutions to support that goal in the first release of Echo at the end of March.

Here are some of the ideas which we have brainstormed to date, on our Echo feature requirements page:

• Useful edit notification
• Huggle/Cluebot Notifications
• Contributions since your last edit
• Positive notifications for active new users

What do you think of these first ideas? None of them may be perfect in their current formulation, but with your help, we could be improve them to provide a practical solution that helps engage new users to participate more productively. With everyone's guidance, we can do better than only send them negative notifications when their edits are reverted (which is like a slap in the face) -- or sending them no notifications whatsoever after their first edits (which is what we are doing now).

Do you have other ideas for positive notifications we could be sending to new users? Thanks in advance for your guidance! Fabrice Florin (WMF) (talk) 20:10, 1 February 2013 (UTC)

Bad requirements: reinventing logs and private notifications

I'm constantly finding that some current development assumptions are big roadblocks for proper features or bugfixes. However, I don't see any rationale for adopting such requirements, and I think it would make more sense to design requirements based on needs rather than the opposite?

1. "Notifications are private". There's no reason whatsoever for this. Nothing is private in MediaWiki, except EmailUser. This is the biggest flaw in the current design. I may be wrong, but I never managed to get a rationale or explanation for this point, despite asking repeatedly.
2. "Special:Notifications is a pretty replacement of Special:Log". Very bad requirement: it creates a need to reinvent logging and related features (search, filtering, revision deletion/oversight, interface, discovery paths, etc. etc.), something that failed miserably in the past (see AFT); it makes user experience consistency between the flyout and the special page impossible, forcing devs to develop two things rather than one.

Example of bug fix stopped by bad requirements: bugzilla:46692, from which this observation comes. Quoting myself, «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». If you use Special:Log, all the basic needs will already be satisfied and you'll be able to focus on actual features. --Nemo 12:59, 9 April 2013 (UTC)

Watchlists are private, of course. --MZMcBride (talk) 13:02, 9 April 2013 (UTC)

The list of watchlisted items is (like preferences), but Special:Watchlist is only a filter of Special:RecentChanges whose content is all public. --Nemo 13:07, 9 April 2013 (UTC) P.s.: bug 46689 is sort of related, too.

And notifications is just a filter of public actions that happen on the wiki (with the exception of the thanks notification). It's the same as every other notification system on the web. I'm sure you're familiar with them. What would be the advantage of making them public? One disadvantage is that we would then have to create complicated interfaces for flagging, oversighting, etc. So we would likely end up with another AFT. If anything would bloat the interface it would be this.

"Special:Notifications is a pretty replacement of Special:Log". No one ever said that. I just said it was "a log", which it is. It is not equivalent to Special:Log, nor does it need to be. Kaldari (talk) 17:25, 9 April 2013 (UTC)

Email notification defaults

Apparently the default setting is to send individual notifications as they come in via email? How is this good practice to apply this automatically? Aside from likely pissing users off, this could violate spam laws by sending unsolicited emails. Email notifications should definitely be opt-in. Sroc (talk) 12:05, 29 April 2013 (UTC)

Feedback on F2

I just got an unexpected notification on the English Wikipedia with the new scheme F2. In my opinion, it is as effective as the original orange bar but feels less intrusive. Congratulations, and thanks for implementing this excellent solution!

I do have two notes on details of the implementation that I think need addressing:

• F2's short orange bar takes so much space that it displaced my top row navigation elements to the point where the last links were moved into an extra row. It took me a moment to understand what was going on, so this might be confusing to some users. Only users with a small screen or large fonts will be affected, but these features could correlate with being prone to confusion by minor user interface variation.
• To get an idea of how the current implementation of F2 looks to screenreader users, I tested it with a text-only browser. (To be specific: I used links2, though I don't expect that's relevant.) Result: I could not find the text of the orange bar at all, which is not necessarily a problem. However, as has been pointed out before, the Echo notification comes at the bottom of the page in a navigation area that looks quite confusing in a text-only browser. In other words: For blind Wikipedia editors we currently have a serious regression, as in practice they are currently not getting any notification at all when they have messages. I guess it might be even easier to navigate to one's own talk page with a screenreader to see if there are new messages there, than to locate the Echo notification near the bottom of the page. Hans Adler (talk) 11:51, 12 May 2013 (UTC)

Two wishes

1. Currently it is not possible to send a notification to a user unless s/he is directly mentioned in the edit, or the discussion is taking place in her/his talk page. An additional field to specify users (possibly comma separated usernames) will be an added advantage for users who want to invite attention from other users to a discussion.
2. Current red background for the notification, immediately makes a feel of some-kind of warning. Even for simple 'mention' or 'thanks', it gives a red colour threat type notification. IMO, cool colour like 'mediawiki-blue' (;-)) is more appropriate.

--Praveenp (talk) 07:17, 28 November 2013 (UTC)

Started Page - Marked as reviewed

A discussion came up on Wikipedia, here about the confusion being caused by this particular feature. Can we default this notification to disabled for all users for page reviews of "good" pages that do not have any flags such as tags or potential deletion? VQuakr (talk) 05:36, 31 January 2014 (UTC)

Proposal: notified when a page you deleted has been restored

It could be useful being notified not only when someone rollbacks your edit (as it happens now), but also if someone restores a page you deleted (of course it should work for sysops only). @Quiddity: : was it already discussed and/or is it doable? --Superchilum (talk) 15:28, 2 September 2014 (UTC)

remove notification icons

Hi, is there an option somewhere to remove the 2 notification icons from the top of my wikipedia logged-in interface? I don't want stuff distracting my attention at the top of the page. I know I can turn off all notifications in the config screen, but the icons are still there and they have numbers on them and I'd prefer them not to be there. If there isn't an option, how do I propose its creation? Thanks very much! 80.193.152.43 17:16, 24 January 2018 (UTC)