Created attachment 11988
Screenshot of where the close button is absent.

Attached:

Created attachment 11989
Screenshot of where the close button is present.

Attached:

Created attachment 11990
Screenshot of when the close button is clicked (the inline preferences interface).

Attached:

CCing the designer.

hi Krinkle,
I completely agree with you that the simple functionality a user needs is:
-Remove this specific notification/ Mark as read (which removes notifications from the flyout)
-Unfollow this article/ discussion
-Clear New

This simple approach was products decision and I agree with you that it is confusing and does not accomplish anything.

I'm passing this on to Fabrice (Product Owner) for him to comment.

Thanks, Krinkle!

You make some good points, and we have just reached out to community members on our editor engagement list, to get this perspective on the current version of the Dismiss feature, as described here:
http://www.mediawiki.org/wiki/Echo_(Notifications)/Feature_requirements#Dismiss

Based on these discussions, we will determine whether to change the current version of Dismiss before we deploy to en-wiki, or remove it entirely, or try it out in its current form to get more community feedback.

The choices we're considering for changing this feature include:

1. have the 'X' button simply close that individual notification (without the option to turn off all notifications from that category?)

2. look for a compromise solution which lets you do both, as proposed earlier by Brandon:

Hover over the notification and there's an "(x)" that appears on the right side.
Click that and it dismisses the notification but also asks "Do you want to hide all notifications of this kind?"
[y/n control]

• if "n/cancel", dismiss/hide current element, do nothing else.
• if "y" set "hide this type" preference for the user. show message about "you can set your preferences [[here]]"

Note that in its current form, the feature is similar to Facebook's 'User Opt-Out' feature, which lets you turn off notifications from an application or group, as described here:
https://developers.facebook.com/docs/concepts/notifications/

But your concerns are well taken. With that in mind, Brandon's proposal may be an effective way to address both requirements with a single feature.

What do you think? We'll keep you posted on what we find out from our other discussions. Cheers.

Just to be clear: my suggestion was a 2 minute thought experiment targeted at trying to prevent users from having to go to an arcane and confusing notifications settings page when they want to unsubscribe from an entire group of notifications, not from dismissing specific notifications.

I think we have a confluence of issues here and what needs to be decided is what use case we want to support.

0) Mark Single Notification as Read. This should be happening automatically, ne?

1. Mark All As Read. This should be a no-brainer. I personally find it irritating that I have to actually go to my "full notifications page" to have all my notifications marked as read (if there are more "fresh" ones than can appear in the flyout, which I wish scrolled to new ones).

2. Delete/Dismiss Single Notification. That seems to be what we're trying to do with the current behavior but I might want to ask "why?" Notifications are transient and chronologically bound - or should be. They aren't emails.

3. Unsubscribe/Mute Single Event. This is like, "Yes, I know I created the article about Flow, stop telling me when people link to it". I want to stop receiving notifications about *that specific thing only*, and may still want to be told when *other* pages I create are linked. (This makes more sense with conversations). Facebook does this from their flyout but only for conversations (and it's an "unfollow"). I don't necessarily know that we can support this as it is probably technically unfeasible and I don't see this as a strong use case.

4. Unsubscribe from Global Notification Type. "Never, ever tell me about pages I created being linked to again." This is a strong use case to support, in my opinion.

It's unclear what we're trying to support here.

The unsubscribe from single event functionality (similar to Facebook) would require additional back-end support, so that is probably the most time-intensive of all the options from a dev point-of-view.

swalling wrote:

Just a heads up: Fabrice wisely decided to take this question to the Editor Engagement list where we can get wider input.

More comments following his request at http://lists.wikimedia.org/pipermail/ee/2013-March/000301.html

(In reply to comment #9)

Fabrice wisely decided to take this question to the Editor
Engagement list where we can get wider input.

What was the outcome / summary of that mailing list discussion?

Hi Andre,

Thanks for following up.

Based on our email discussions, our team decided to remove the Dismiss feature from our first release on en-wiki later this month, and to explore a different design approach in coming weeks. Once we reach consensus about the new designs, we may re-introduce this feature in a revised form.

For now, I recommend that we keep this ticket open until the Dismiss feature has been removed from the current version of the Notifications tool, then mark it as resolved.

Thanks for everyone who contributed to the discussion of this feature!

I just want to raise a few points:

1. What is the decision on making the Close button permanent? I found it confusing too when it appeared once and then didn't at other times.

2. All notifications are currently marked as read soon after I open up the notification flyout but *actually* I only read the first one and then pondered over to my talk page. I think notifs should be marked as read only when I click on them or I click on a button on the side saying "mark as read". But the red color should be removed because I am already warned once that there are x notifs.

3. At first I found it weird that the notif flyout took so much time to load, but then I noticed that it is loaded using Ajax each time. This is cool, but then the red color should also show automatically when something happens(as happens in FB), I guess this can be done by doing periodic calls to the Api? and when we are doing periodic calls we may not need to call when the user clicks on it and just show the cached results so the user doesn't have to keep waiting.

I now think the 3rd one can be a separate bug actually :p

I'm pretty sure the button is gone now. Closing as FIXED.