Agreed with Matt. I wasn't involved in the discussions referenced, I think, but my opinion is that you cannot simply give people a boolean option on this kind of thing. "firehose of sewage or nothing" means a lot of people are going to go for "nothing", at which point we've sort of undermined the entire system. On 10 January 2013 20:19, Matthew Flaschen <mflaschen(a)wikimedia.org> wrote: On 01/10/2013 01:36 PM, Ryan Kaldari wrote: From where I'm standing, I think there should be sane defaults, but each notification type should be separately configurable. If not, you risk people turning everything off, or worse, using the wiki less. Matt Flaschen

Yes, bundling will be on a per notification basis, i.e. some notifications will be bundlable and some probably won't. Ryan Kaldari On 1/9/13 1:35 PM, Oliver Keyes wrote: > Great :). Any thoughts on distinguishing bundle-worthy/individual-worthy types of alert? > > On 9 January 2013 21:32, Fabrice Florin <fflorin(a)wikimedia.org> wrote: > Hi guys, > > Just wanted to let you know that Benny and Kaldari just deployed a first fix to this page link feature, to make sure that it restricts it only to 'content namespace' on MediaWiki. > > For example, this notification will no longer be sent if someone puts a page link on a talkpage. > > We'll keep making improvements on this and related features in coming weeks, as outlined below. > > In the meantime, if someone really dislikes this feature, you can turn off email notifications for it on your preference page: > > http://www.mediawiki.org/wiki/Special:Preferences#mw-prefsection-echo > > Cheers, > > > -f > > > P.S.: Matthew and Oliver's recommendation to create a separate 'your page was moved' notification is duly noted and will be added to the wishlist. Keep in mind that right now we are focusing on building core features for new users, so it's likely this would take place later this year, not right away. > > > > On Jan 9, 2013, at 10:58 AM, Fabrice Florin wrote: > >> Thank you all for these great comments and suggestions! >> >> They will be very helpful for our next steps, not just for the page link feature, but for the other core features we're planning right now. >> >> Here is a quick summary of what I think are new features to consider: >> >> * Restrict the definition of a page link >> We would only focus on article namespace links, and remove talkpage links or other page links that could create spam. We would also remove any redirects or page moves from that definition. Some of these things could be done partially today (e.g. exclude talkpage links), if we can get a deployment window. >> >> * Make email notifications opt-in for experienced users >> By default, we would uncheck the preferences box for page links, so that experienced users are not flooded with more information than they want. So if you have more than 100? edits, that preference would be disabled until you choose to enable it. >> >> * Keep email notifications enabled for new users >> This feature is actually quite valuable for new users, so they can find out what is happening with their new page. So we would check the box for anyone that has less than 100? edits, so they can benefit from this feature. I have to say that for myself, it is one of the most useful notification I have found on MediaWiki, since I rarely get talk page messages or have my edit reverted, even though I'm very active (I understand this would be different on a more active Wiki). >> >> * Bundle email notifications >> As Luke points out, spammy emails is one of the biggest risk we are facing with this project, and it is much better to send too few notifications rather than too many. So we should look for bundling solutions that allow us to either: >> - stop sending emails after you've reached your daily limit (which could be a preference: 'don't send me more than 5 emails a day'); or >> - only send 1 email every 4? hours or something like that (which could also be a preference: 'only send me 1 email every 4 hours')); or >> - send a 'digest' email after you have received x notifications per day (e.g.: '15 people linked pages you created today. See all your notifications') >> Intelligent bundling is perhaps one of the greatest design challenges for this project, and I recommend that we all focus our energy to tackling this problem in coming weeks. >> >> * Flyout dismiss >> We definitely want to add a way to dismiss notifications by type in the flyout. We had planned to do this in the second release, but could accelerate this if need be. I still think bundling is a higher priority. This will also be a tricky one to implement, because matching the user intent may prove hairy. >> >> Thanks again for all your great feedback and creative ideas, which are music to my ears! >> >> To be continued, >> >> >> Fabrice >> >> >> On Jan 9, 2013, at 10:25 AM, Luke Welling WMF wrote: >> >>> Erik's point "But it's definitely too spammy to turn it on for established users by default." is key. >>> >>> We need to be very careful about turning on any email notifications for existing users. It's something that a significant number of people are very touchy about, and annoys everybody if sent in high volume. >>> >>> I don't like magic thresholds where the system behaviour changes without user interaction. People expect computers to behave predictably. If you sent me an email every 2 days to say something had happened to my article then stopped, I'd assume that my article was no longer being linked to, not that I'd crossed over x edits and now need to enable the preference manually. If we really want to go that way, you need to tell people it happened, and how to undo it. >>> >>> I think the best approach with email is to enable it for new users, so they see the place is alive, but only suggest to existing users that they turn it on, even if "suggesting" means as a one off sending them a sample of what this week's digest would look like for them. >>> >>> Even for new users we should have cadence controls in place before we launch on busier wikis. Nobody wants 10+ emails a day. Best practice is one immediate one, then bundle up subsequent ones for a few hours, but if that is too much work for V1, only trying to send every x hours and risking delaying the first one by x hours is a better compromise than risking sending 100 mails a day. >>> >>> Luke >> >> >> >> On Jan 9, 2013, at 10:22 AM, Oliver Keyes wrote: >> >>> It turns out it currently sends you a notification when a page is moved, because that creates a redirect aimed at it. oy. >>> >>> On 9 January 2013 11:35, Oliver Keyes <okeyes(a)wikimedia.org> wrote: >>> >>> >>> On 9 January 2013 06:47, Steven Walling <swalling(a)wikimedia.org> wrote: >>> On Tue, Jan 8, 2013 at 10:35 PM, Erik Moeller <erik(a)wikimedia.org> wrote: >>> I do get these too a fair bit from mediawiki.org, about 5-10 a day. I >>> actually kinda like them, but I'm an information junkie. >>> >>> To clarify here: I like the onsite notification, I just don't like the email. The notification feels like serendipitous information discovery, where I get to learn something I couldn't otherwise. The email feels like work, probably because I can more easily ignore a notification in the flyout. >>> >>> On the "easy to disable" front, I'm not sure if this is on the roadmap >>> already, but having an inline way to dismiss notifications of a >>> certain type would IMO be nice, e.g. a simple "Disable this type of >>> alert" link within the actual notification itself. >>> >>> Great idea! Giving people an immediate touch point means they feel like they have control, like swatting a fly. >>> >>> This would be awesome. I can't imagine the backlash if we deploy the feature as it's currently written on enwiki. >> >> >> On Jan 9, 2013, at 3:35 AM, Oliver Keyes wrote: >> >>> >>> >>> On 9 January 2013 06:47, Steven Walling <swalling(a)wikimedia.org> wrote: >>> On Tue, Jan 8, 2013 at 10:35 PM, Erik Moeller <erik(a)wikimedia.org> wrote: >>> I do get these too a fair bit from mediawiki.org, about 5-10 a day. I >>> actually kinda like them, but I'm an information junkie. >>> >>> To clarify here: I like the onsite notification, I just don't like the email. The notification feels like serendipitous information discovery, where I get to learn something I couldn't otherwise. The email feels like work, probably because I can more easily ignore a notification in the flyout. >>> >>> On the "easy to disable" front, I'm not sure if this is on the roadmap >>> already, but having an inline way to dismiss notifications of a >>> certain type would IMO be nice, e.g. a simple "Disable this type of >>> alert" link within the actual notification itself. >>> >>> Great idea! Giving people an immediate touch point means they feel like they have control, like swatting a fly. >>> >>> This would be awesome. I can't imagine the backlash if we deploy the feature as it's currently written on enwiki. >>> -- >> >> >> On Jan 8, 2013, at 10:47 PM, Steven Walling wrote: >> >>> On Tue, Jan 8, 2013 at 10:35 PM, Erik Moeller <erik(a)wikimedia.org> wrote: >>> I do get these too a fair bit from mediawiki.org, about 5-10 a day. I >>> actually kinda like them, but I'm an information junkie. >>> >>> To clarify here: I like the onsite notification, I just don't like the email. The notification feels like serendipitous information discovery, where I get to learn something I couldn't otherwise. The email feels like work, probably because I can more easily ignore a notification in the flyout. >>> >>> On the "easy to disable" front, I'm not sure if this is on the roadmap >>> already, but having an inline way to dismiss notifications of a >>> certain type would IMO be nice, e.g. a simple "Disable this type of >>> alert" link within the actual notification itself. >>> >>> Great idea! Giving people an immediate touch point means they feel like they have control, like swatting a fly. >>> >>> -- >>> Steven Walling >>> https://wikimediafoundation.org/ >> >> >> On Jan 8, 2013, at 10:35 PM, Erik Moeller wrote: >> >>> On Tue, Jan 8, 2013 at 3:15 PM, Vibha Bamba <vbamba(a)wikimedia.org> wrote: >>> >>>> if we were to define thresholds > only notify when its been linked to 10 >>>> other articles >>>> and switch this on for users with under x edits only? >>> >>> I think it'd need to be restricted to new users, and also limited to >>> links from within the article namespace (otherwise you get too much >>> meta-crud). Beyond that, if it's easy to disable, I think it could be >>> a nice way to surface activity and "aliveness" to new users. But it's >>> definitely too spammy to turn it on for established users by default. >>> Thresholds might make things too complicated though. >>> >>> I do get these too a fair bit from mediawiki.org, about 5-10 a day. I >>> actually kinda like them, but I'm an information junkie. >>> >>> On the "easy to disable" front, I'm not sure if this is on the roadmap >>> already, but having an inline way to dismiss notifications of a >>> certain type would IMO be nice, e.g. a simple "Disable this type of >>> alert" link within the actual notification itself. >>> >>> Erik >>> -- >>> Erik Möller >>> VP of Engineering and Product Development, Wikimedia Foundation >> >> On Jan 8, 2013, at 3:15 PM, Vibha Bamba wrote: >> >>> Would this notification make sense: >>> if we were to define thresholds > only notify when its been linked to 10 other articles >>> and switch this on for users with under x edits only? >>> >>> On Tue, Jan 8, 2013 at 2:54 PM, Steven Walling <swalling(a)wikimedia.org> wrote: >>> I have gotten four emails about this cross-linking notification this morning alone. Too much noise. >>> >>> ---------- Forwarded message ---------- >>> From: MediaWiki Mail <wiki(a)wikimedia.org> >>> Date: Tue, Jan 8, 2013 at 2:53 PM >>> Subject: A page you started was cross referenced on MediaWiki >>> To: Steven <swalling(a)wikimedia.org> >>> >>> >>> Onboarding new Wikipedians was linked by MediaWiki user Superm401, from this page: Guided tours >>> >>> View more: >>> >>> http://www.mediawiki.org/wiki/Guided_tours >>> >>> ________________________________________________ >>> >>> To control which e-mails we send you, visit: >>> http://www.mediawiki.org/wiki/Special:Preferences#mw-prefsection-echo >>> >>> Wikimedia Foundation, 149 New Montgomery St., 3rd Fl., San Francisco, CA 94105. >>>

I agree with Matt and Oliver as well. I don't think we can avoid giving people individual control of which notifications they receive. But I definitely think that adding a dismiss option in the flyout is an effective way to give people that control, so they don't have to go to the preferences page if they don't want to.

But this discussion is touching upon the central challenge for this product: how to make sure that we inform people without spamming them.

On Jan 10, 2013, at 1:46 PM, Matthew Flaschen <mflaschen(a)wikimedia.org> wrote: 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]]" --- Brandon Harris, Senior Designer, Wikimedia Foundation Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate _______________________________________________ EE mailing list EE(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee

Facebook has a really nice design along those lines, which I think we can emulate. See these screenshots <https://docs.google.com/a/wikimedia.org/presentation/d/1ZRqi7bo8W-HgzJ_riskqFMTIPBIlWDmwMURbmnvr19w/edit#slide=id.g2ee45dc7_1_58> in our best practices deck. I am starting to think that the "<page> was linked" should not be subject to individual notifications at all.

Pages you created in the past being linked by others are a different kind of interaction that is not human-to-human, but more akin to, for example, someone visiting a blog page that you wrote some time in the past.

I guess that by "bundling" you refer to present several notifications of the same type as a single element. I think that aggregating them by type is something really good for certain kind of notifications, but other content-related notifications may benefit from being aggregated by content. Thats especially relevant when several individual events are correlated or can be interpreted as signs of a more global event (which is somewhat related to the concerns raised by Chris). For example, if a page receives 1k reads, 20 comments and 2 cross-link, it may be useful to present that as a single "Your page on Higgs Boson is becoming popular (1k reads, 20 comments and linked by 2 other pages today)". More than a specific solution I wanted to make sure that different kinds of aggregation critera are considered when the "bundling" discussion happens. Pau On Thu, Jan 10, 2013 at 11:50 PM, Matthew Flaschen < mflaschen(a)wikimedia.org&gt; wrote: -- Pau Giner Interaction Designer Wikimedia Foundation _______________________________________________ EE mailing list EE(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee

I've heard the "a page you created in the last 30 days was linked to" idea from a couple of people so let me put in my vote against. I really dislike complicated, mysterious behaviour. If the logic can't cleanly be described in the text description of the notification, then I think it's the wrong logic. I don't think any notification type wants a day limit filter, or a for users with <x edits filter, or any other logic that will be confusing to recipients. The cure for spam is to not auto enable email notifications for existing accounts, and to put work into email cadence controls across all notification types (except talk page messages) before launching to "real" users. Applying weird custom business logic to different notification types is a recipe for bugs and confusion and will just lead to more weird single case cures when you hit power users who still hit their personal spam threshold on 30 day limited pages. Simple consistent behaviour is better for the users and better for the codebase. Luke On Thu, Jan 10, 2013 at 2:50 PM, Matthew Flaschen &lt;mflaschen(a)wikimedia.org _______________________________________________ EE mailing list EE(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee