*TL;DR *It needs to support a common use case, which is that the user just wants to clearly delete a single item. In its current state, the feature doesn't make sense to me and breaks a few ingrained patterns.

Are there any notification systems that operate on an "inbox zero" style mechanic? Arguably Quora's does (they drop off the flyout when read) but Quora's notification system is just so hideous I can't imagine that we'd want to take anything away from it. On Mar 27, 2013, at 12:02 PM, Steven Walling <swalling(a)wikimedia.org> wrote: wrote: wants to clearly delete a single item. few ingrained patterns. MediaWiki dot org, I always am confused by the current behavior of the X button on individual notifications, and as a user would much prefer it simply remove an item from the flyout, with the optional follow up question of removing all of that type in the future. it seems redesigning along these lines is probably not feasible before then. My suggestion would be to simply disable the Dismiss feature in its current state, perhaps also ask our users on enwiki about how they'd like this behavior to work, and then make a call in the weeks following launch. That way we're adding to the product at our leisure, rather than trying to rewire a feature already in front of tons of users. and for soliciting more. --- 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

*TL;DR *It needs to support a common use case, which is that the user just wants to clearly delete a single item. In its current state, the feature doesn't make sense to me and breaks a few ingrained patterns. X is a dismissal affordance, plain and simple. When you hit X, the item should just go away. If it's the first time dismissing an item of a certain category, you should be presented with a dialog that lets you disable them all. Currently, the behavior is: 1. Click X. 2. See a dialog asking me if I want to Dismiss all notifications of a certain type, or "Cancel." There is no option to just remove the individual item from my notifications. If there is an option, I'm not aware of it as a user. 3. Click "Cancel" because I might want notifications of that type in the future. 4. Feel sad that i can't clean out my list of notifications and I just have to sit there and watch messages decay in the list. This feels akin to the desire for zero inbox. If I get an email from someone and click "Delete," then receive the dialog in (2), I'd be super confused. I just wanted to clear out my inbox, and I want to receive an email from that person later. I'd propose redesigning the dialog in (2) to have three actions: 1. Just delete this one item (most prominent) 2. Disable notifications of this kind 3. Cancel Munaf On Wed, Mar 27, 2013 at 11:26 AM, Fabrice Florin &lt;fflorin(a)wikimedia.org <mailto:fflorin@wikimedia.org>> wrote: Hi folks, We would appreciate your views on the current version of the Dismiss feature, as described here: http://www.mediawiki.org/wiki/Echo_(Notifications)/Feature_requirements#Dis… <http://www.mediawiki.org/wiki/Echo_%28Notifications%29/Feature_requirements#Dismiss> This 'Dismiss' tool enables users to turn off notifications categories they don't want to see in the flyout or the all-notifications page, so they don't have to go to the preferences page if they don't want to. If you haven't already, you can test this feature here on MediaWiki: http://www.mediawiki.org/wiki/Special:Notifications Krinkle and a couple other folks have raised concerns about this feature here on Bugzilla: https://bugzilla.wikimedia.org/show_bug.cgi?id=46587 What do you think? Is this feature useful to you in its current form? Note that currently it only lets you turn off an entire notification category (instead of just removing individual notifications). In that sense, it 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/ Would you prefer to have the 'X' button simply close that individual notification? (without the option to turn off all notifications from that category?) Or would you prefer this 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]]" We are debating 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. Look forward to your recommendations! I have also attached below earlier email threads on this topic. All the best, Fabrice _____________________________________ On Mar 6, 2013, at 9:25 AM, Fabrice Florin wrote: On Jan 11, 2013, at 11:59 AM, Fabrice Florin wrote: I agree with Kaldari on this point. We need to keep this feature simple - and make it easy for users to turn it on or off. We already have a user preference for it here: http://www.mediawiki.org/wiki/Special:Preferences#mw-prefsection-echo Currently, it disables email notifications only. But given that Wikipedians may want more control, a case could be made that these preferences could apply to both onsite and email. Or we could have separate checkboxes for these options, for even more granularity, as Google does (see screenshot). Another option is to provide the dismiss option in the flyout, which we discussed in a separate thread, as Facebook does (see screenshot). This would enable users to completely remove notification types they don' want, both onsite and by email. I propose we discuss this with Vibha during our meeting with her on Monday and reach a resolution then. If the solution is simple, we can push it in our next deployment on Thursday. Until then, please turn off the user preference for this feature if it really bothers you. Thanks, Fabrice On Jan 10, 2013, at 1:50 PM, Brandon Harris wrote: On Jan 10, 2013, at 1:46 PM, Matthew Flaschen &lt;mflaschen(a)wikimedia.org <mailto:mflaschen@wikimedia.org>> wrote: I agree. Not just, "dismiss this one", but "Don't show this type of notification again" right on the notification itself (not necessarily those phrasings). 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 On Thu, Jan 10, 2013 at 1:33 PM, Fabrice Florin &lt;fflorin(a)wikimedia.org <mailto:fflorin@wikimedia.org>> wrote: 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. I also think that bundling can help in a number of ways, as outlined in my feature list below (I am including the entire thread, to make sure nobody feels left out from that discussion) I will create a feature requirement stub for both options (and a few more) in coming days, and we can prioritize them as a team in next week's planning session. But this discussion is touching upon the central challenge for this product: how to make sure that we inform people without spamming them. It will take us a while to completely solve this challenge, but we should not ship anything that doesn't have some good solutions to this difficult problem, IMHO. Cheers, Fabrice On Tue, Jan 8, 2013 at 10:35 PM, Erik Moeller &lt;erik(a)wikimedia.org <mailto:erik@wikimedia.org>> wrote: 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. On 9 January 2013 11:35, Oliver Keyes &lt;okeyes(a)wikimedia.org <mailto:okeyes@wikimedia.org>> wrote: On 9 January 2013 06:47, Steven Walling &lt;swalling(a)wikimedia.org <mailto:swalling@wikimedia.org>> wrote: Great idea! Giving people an immediate touch point means they feel like they have control, like swatting a fly. _______________________________________________ EE mailing list EE(a)lists.wikimedia.org <mailto:EE@lists.wikimedia.org> https://lists.wikimedia.org/mailman/listinfo/ee _______________________________________________ EE mailing list EE(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee

On 03/27/2013 03:09 PM, Isarra Yos wrote: You can still disable the notification category in Special:Preferences . It may be worthwhile to keep the main Echo interface (not preferences) simpler if they choose not to disable the category the first time. Matt Flaschen _______________________________________________ EE mailing list EE(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee

I propose: 1) The safest thing that allows to build incrementally for now is 'Ive read this > Remove it' 2 ) In addition to this we could support a clear all new from the flyout so a user doesn't have to dismiss one at a time. This still leaves us with the problem of cross linking notification which may be large in volume > we could make that an 'opt in' Dismissing entire categories needs more fine tuning. Other than cross links, so far we dont have enough evidence that users will want to switch entire categories off. Users will want to unfollow specific things > Articles > Discussions etc. We need more time and back end support to figure that out. On Wed, Mar 27, 2013 at 12:17 PM, Isarra Yos &lt;zhorishna(a)gmail.com&gt; wrote:

As someone who has spent time directly observing user behaviour for many years - we have lots and lots of evidence. For example; are you aware that users semi-automatically and/or rapidly create articles? Usually translated from other projects. I sincerely doubt that they will want a notification every time. On 27 March 2013 19:32, Vibha Bamba &lt;vbamba(a)wikimedia.org&gt; wrote: -- Oliver Keyes Community Liaison, Product Development Wikimedia Foundation _______________________________________________ EE mailing list EE(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee

I am certainly talking about the power user; my point is that we *do*have use cases here :). I strongly agree that new users are unlikely to create a volume of edits or articles in a single go, but given that our job with EE is to turn them *into* power users, and being able to create mechanisms to do this requires some kind of community acceptance, it seems illogical to make product decisions based on the short-term. I'm happy to wait until we have *more* evidence, and other people are convinced this might be worth looking into, but "I think you may be talking about the power user here" is never a valid argument for a feature that hits non-newcomers. On 27 March 2013 20:02, Vibha Bamba &lt;vbamba(a)wikimedia.org&gt; wrote: -- Oliver Keyes Community Liaison, Product Development Wikimedia Foundation _______________________________________________ EE mailing list EE(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee

That's an argument for 'they might not find the feature as useful'. Will they be directly inconvenienced by the feature? Not that I can see. But since we're in agreement that, well, we're not in agreement, it's probably worth mooting this conversation until there comes a time when we have more evidence on how things work in practise, or other people want to take up the baton. On 27 March 2013 20:23, Vibha Bamba &lt;vbamba(a)wikimedia.org&gt; wrote: -- Oliver Keyes Community Liaison, Product Development Wikimedia Foundation _______________________________________________ EE mailing list EE(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee

I generally like the feature in its current form. It's not exactly how I'd have specified it. I think consistency in UX is vital so if it were just up to me, I would not have different handling for talk and system notifications. But that's a relatively minor issue. The big question I'd ask now is "Is there a realistic chance that we'll add fine grained control in V1.1?" If there is, then type based disabling is dangerous. It limits what we can turn on later. For example, if somebody has turned off all page link notifications because they were getting dozens for a single uninteresting page they created, and we later add per page disabling of that type, we can't reasonably turn it back on for that user. Undoing their manual preference settings would be obnoxious. We've lost them from that feature forever even if we improve it. Luke On Wed, Mar 27, 2013 at 4:27 PM, Vibha Bamba &lt;vbamba(a)wikimedia.org&gt; wrote: _______________________________________________ EE mailing list EE(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee

I have two prototypes to share that will help solve this problem that I can share on monday at my desk. On Wed, Mar 27, 2013 at 2:59 PM, Benny Situ &lt;bsitu(a)wikimedia.org&gt; wrote:

Speaking as one of the several remote employees on the E2 team, I would suggest taking that sharing list in reverse order :). On 29 March 2013 23:31, Vibha Bamba &lt;vbamba(a)wikimedia.org&gt; wrote: -- Oliver Keyes Community Liaison, Product Development Wikimedia Foundation _______________________________________________ EE mailing list EE(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee

*Just to clarify: *The shareout will be during the Monday meeting. It seems like everyone is already attending this meeting. *As a follow up, I will post the mocks and conversation tot his thread so any folks who couldn't make it can participate.* Thank You. On Fri, Mar 29, 2013 at 4:35 PM, Vibha Bamba &lt;vbamba(a)wikimedia.org&gt; wrote:

So, wide-in-scope-and-slightly-TL;DR followup: I'd ask for us to avoid statements like "if you want to see them, come by my desk".

This is not something specific to this situation, and I want to take clear I'm not taking issue with anyone in particular (Vibha and I discussed the issue, the designs will be in the Monday meeting, no harm, no foul)., but: I think we have a tendency to have a lot of discussions in-office. This is something I noticed particularly on my most recent visit to the WMF HQ, when it became clear precisely how many discussions and ideas were being had and nixed and pushed forward before seeing the light of day from a remote worker's perspective, probably aided by meetings people like Siebrand, Tomasz, Arthur and I have been having with HR and OIT about bridging the office-remote divide. It's being done becaise we all want the WMF to work efficiently and quickly. This is understandable, it's laudable, it's inevitable given the state of perpetual pressure we're under; we have a thousand things we need to fix and only the resources to fix ten correctly. We need to move fast and we need to move in the right direction so that we can get ***something*, the 90 percent product, out rather than spending eternity spinning our wheels on the 100 percent product. But, here's the rub: much like the relationship between quitting drinking and living longer, keeping things in-person doesn't actually make us move faster, it just makes it feel faster. Like it or not, we've got geographically distributed employees. A lot of them work from SF, sure, but we've got people in Spain, the Netherlands, India, Australia, the UK. And when important discussions happen in-person, we exclude them from the conversation. This doesn't make things faster or better, because they *work here* - because they're tasked with implementing the outcome of the discussion, or providing feedback on it. And when they're excluded from the conversations, we end up having bits of them again and again because what's obvious context to someone who /was/ in the meetings isn't necessarily obvious to people outside them. We end up having fewer perspectives in decision-making, we end up with a dozen discussions with 13 participants instead of concentrating that into one meeting. We might find a resolution on Day 1, and take until Day 14 to have everyone on side. In other words: we're not working more efficiently at all; we're working less efficiently. Product Development is ultimately a process and sub-department that doesn't set much stock by hierarchy. We can't just declare "this meeting happened and a decision has been made" without getting at least stubborn acceptance of the idea by a lot of people. If they weren't in that meeting...more meetings. More conversations. Less speed. I get the desire to move quickly, and I applaud it. But as a department, we need to get better at quickly crushing the voice that says "I'll just wander over to their desk", because some people don't have desks in SF. We have a duty to efficiency, which is not served by meeting after meeting on the same points with different people. We have a duty to transparency, which is not served by shutting our volunteers and a substantial chunk of our employees out of the inner workings of the sausage factory. We have a duty to Get Stuff Done Fast: and this is best served by having everyone on side and pushing in the same direction. On 29 March 2013 23:50, Vibha Bamba &lt;vbamba(a)wikimedia.org&gt; wrote: -- Oliver Keyes Community Liaison, Product Development Wikimedia Foundation _______________________________________________ EE mailing list EE(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee

/The previous email was simply an email sent in a hurry. //And it is being treated out of proportion. / /I assure you we have no intent of working without consensus./ / / I sent an 'immediate follow up email' where I specifically stated that folks should join the 'Monday meeting' which has been set up for this purpose along with general feature roundup. Discussions and mocks will be posted on mediawiki to follow up for those who cannot participate so they can join in with comments. The reason this occurred is because the email was sent in a hurry. I would also request everyone to understand that we are shortstaffed on the design team. We have been unable to hire a visual designer since Lindsey left around September last year. Munaf and I are covering production work on E2, E3 and Mobile & design Outreach. This includes both interaction and visual design. Just to put things into perspective: It takes one hour to make a simple icon if it has to be done right. The email sent in a hurry because at any given time 2 designers are balancing a lot of work and sometimes we need to close things out or narrow solutions before we can manage a discussion between 15 people. Please recognize that we are doing our best to make sure teams are supported. We absolutely acknowledge that remote staff needs to and must be involved. If anyone has any concerns please feel free to chat with Howie and me. I would really appreciate that we close this thread. It is simply a misunderstanding and nothing else. Thanks Vibha On Sat, Mar 30, 2013 at 8:38 AM, Oliver Keyes &lt;okeyes(a)wikimedia.org <mailto:okeyes@wikimedia.org>> wrote: So, wide-in-scope-and-slightly-TL;DR followup: I'd ask for us to avoid statements like "if you want to see them, come by my desk". This is not something specific to this situation, and I want to take clear I'm not taking issue with anyone in particular (Vibha and I discussed the issue, the designs will be in the Monday meeting, no harm, no foul)., but: I think we have a tendency to have a lot of discussions in-office. This is something I noticed particularly on my most recent visit to the WMF HQ, when it became clear precisely how many discussions and ideas were being had and nixed and pushed forward before seeing the light of day from a remote worker's perspective, probably aided by meetings people like Siebrand, Tomasz, Arthur and I have been having with HR and OIT about bridging the office-remote divide. It's being done becaise we all want the WMF to work efficiently and quickly. This is understandable, it's laudable, it's inevitable given the state of perpetual pressure we're under; we have a thousand things we need to fix and only the resources to fix ten correctly. We need to move fast and we need to move in the right direction so that we can get /*/something*, the 90 percent product, out rather than spending eternity spinning our wheels on the 100 percent product. But, here's the rub: much like the relationship between quitting drinking and living longer, keeping things in-person doesn't actually make us move faster, it just makes it feel faster. Like it or not, we've got geographically distributed employees. A lot of them work from SF, sure, but we've got people in Spain, the Netherlands, India, Australia, the UK. And when important discussions happen in-person, we exclude them from the conversation. This doesn't make things faster or better, because they *work here* - because they're tasked with implementing the outcome of the discussion, or providing feedback on it. And when they're excluded from the conversations, we end up having bits of them again and again because what's obvious context to someone who /was/ in the meetings isn't necessarily obvious to people outside them. We end up having fewer perspectives in decision-making, we end up with a dozen discussions with 13 participants instead of concentrating that into one meeting. We might find a resolution on Day 1, and take until Day 14 to have everyone on side. In other words: we're not working more efficiently at all; we're working less efficiently. Product Development is ultimately a process and sub-department that doesn't set much stock by hierarchy. We can't just declare "this meeting happened and a decision has been made" without getting at least stubborn acceptance of the idea by a lot of people. If they weren't in that meeting...more meetings. More conversations. Less speed. I get the desire to move quickly, and I applaud it. But as a department, we need to get better at quickly crushing the voice that says "I'll just wander over to their desk", because some people don't have desks in SF. We have a duty to efficiency, which is not served by meeting after meeting on the same points with different people. We have a duty to transparency, which is not served by shutting our volunteers and a substantial chunk of our employees out of the inner workings of the sausage factory. We have a duty to Get Stuff Done Fast: and this is best served by having everyone on side and pushing in the same direction. On 29 March 2013 23:50, Vibha Bamba &lt;vbamba(a)wikimedia.org <mailto:vbamba@wikimedia.org>> wrote: Also: If anyone has ideas, please feel free to make simple wireframes and share them during the Monday syncup. I think showing how this interaction will better anchor and guide the discussion. Thanks On Fri, Mar 29, 2013 at 4:48 PM, Vibha Bamba &lt;vbamba(a)wikimedia.org <mailto:vbamba@wikimedia.org>> wrote: *Just to clarify: *The shareout will be during the Monday meeting. It seems like everyone is already attending this meeting. /As a follow up, I will post the mocks and conversation tot his thread so any folks who couldn't make it can participate./ Thank You. On Fri, Mar 29, 2013 at 4:35 PM, Vibha Bamba &lt;vbamba(a)wikimedia.org <mailto:vbamba@wikimedia.org>> wrote: They are interactive mockups with motion and its too hard to share them without seeing them live. I believe you will join the Monday meeting? On Fri, Mar 29, 2013 at 4:33 PM, Oliver Keyes &lt;okeyes(a)wikimedia.org <mailto:okeyes@wikimedia.org>> wrote: Speaking as one of the several remote employees on the E2 team, I would suggest taking that sharing list in reverse order :). On 29 March 2013 23:31, Vibha Bamba &lt;vbamba(a)wikimedia.org <mailto:vbamba@wikimedia.org>> wrote: I will also share these in the team meeting and then we can discuss the conclusion and I will post a PDF on Mediawiki. Thanks Vibha On Fri, Mar 29, 2013 at 4:31 PM, Vibha Bamba &lt;vbamba(a)wikimedia.org <mailto:vbamba@wikimedia.org>> wrote: I have two prototypes to share that will help solve this problem that I can share on monday at my desk. On Wed, Mar 27, 2013 at 2:59 PM, Benny Situ &lt;bsitu(a)wikimedia.org <mailto:bsitu@wikimedia.org>> wrote: I did not go through every thread in this conversation, what problem is 'clear/go away' trying to solve? Is it because the notification topic is not interesting to the user or is it because it disturbs the user view in the flyout? 'clearing' existing ones doesn't prevent new ones from coming in. Or is it just because we want to provide more UI control to end users? I receive emails from amazon regularly and I would view them occasionally to see what's on sale , I would never check/delete them because I know that new emails will push them out of the first page. If I am getting sick of receiving such email I would just unsubscribe. I am not sure about implementing such function, I think it totally depends on personal preference ( in such case, majority rules, :) ). On Wed, Mar 27, 2013 at 1:33 PM, Luke Welling WMF &lt;lwelling(a)wikimedia.org <mailto:lwelling@wikimedia.org>> wrote: I generally like the feature in its current form. It's not exactly how I'd have specified it. I think consistency in UX is vital so if it were just up to me, I would not have different handling for talk and system notifications. But that's a relatively minor issue. The big question I'd ask now is "Is there a realistic chance that we'll add fine grained control in V1.1?" If there is, then type based disabling is dangerous. It limits what we can turn on later. For example, if somebody has turned off all page link notifications because they were getting dozens for a single uninteresting page they created, and we later add per page disabling of that type, we can't reasonably turn it back on for that user. Undoing their manual preference settings would be obnoxious. We've lost them from that feature forever even if we improve it. Luke On Wed, Mar 27, 2013 at 4:27 PM, Vibha Bamba &lt;vbamba(a)wikimedia.org <mailto:vbamba@wikimedia.org>> wrote: Ryan, can you request you to comment on tech feasibility analysis for 2 things: -A simple 'Go away/Remove this notification' -And a 'Clear All' for visible notifications in the flyout? On Wed, Mar 27, 2013 at 1:25 PM, Oliver Keyes &lt;okeyes(a)wikimedia.org <mailto:okeyes@wikimedia.org>> wrote: That's an argument for 'they might not find the feature as useful'. Will they be directly inconvenienced by the feature? Not that I can see. But since we're in agreement that, well, we're not in agreement, it's probably worth mooting this conversation until there comes a time when we have more evidence on how things work in practise, or other people want to take up the baton. On 27 March 2013 20:23, Vibha Bamba &lt;vbamba(a)wikimedia.org <mailto:vbamba@wikimedia.org>> wrote: Right. So I agree we need solutions that will work across a spectrum of engagement levels. But turning categories off also doesn't work for new users, /their volume and velocity of notifications/ is much smaller than the power user. On Wed, Mar 27, 2013 at 1:19 PM, Oliver Keyes &lt;okeyes(a)wikimedia.org <mailto:okeyes@wikimedia.org>> wrote: I am certainly talking about the power user; my point is that we /do/ have use cases here :). I strongly agree that new users are unlikely to create a volume of edits or articles in a single go, but given that our job with EE is to turn them /into/ power users, and being able to create mechanisms to do this requires some kind of community acceptance, it seems illogical to make product decisions based on the short-term. I'm happy to wait until we have /more/ evidence, and other people are convinced this might be worth looking into, but "I think you may be talking about the power user here" is never a valid argument for a feature that hits non-newcomers. On 27 March 2013 20:02, Vibha Bamba &lt;vbamba(a)wikimedia.org <mailto:vbamba@wikimedia.org>> wrote: Oliver, I think you may be talking about the power user here: New users are unlikely to create a volume of edits or articles in a single go. Certain categories *cannot *be switched off: -Systme Messages -Talk Page messages You bring up a very valid case, but I doubt that the solution is turning entire categories off from the flyout. If it is spam for power users, they can turn things off in Preferences. Facebook provides a very sophisticated level of control in the flyouts by letting you mute : -Notification from User X (*Not* all talk messages) -Notifications about Event X (*Not* all events) -Notifications from X wall Post (Not all your wall posts, just this specific one) -Notifications from the status you posted (Not your entire wall) -Notifications for a language from a service (Not even the entire app in all cases) This is the level of control we may need for some categories, but it needs more thinking, I dont think we are there yet. On Wed, Mar 27, 2013 at 12:34 PM, Oliver Keyes &lt;okeyes(a)wikimedia.org <mailto:okeyes@wikimedia.org>> wrote: As someone who has spent time directly observing user behaviour for many years - we have lots and lots of evidence. For example; are you aware that users semi-automatically and/or rapidly create articles? Usually translated from other projects. I sincerely doubt that they will want a notification every time. On 27 March 2013 19:32, Vibha Bamba &lt;vbamba(a)wikimedia.org <mailto:vbamba@wikimedia.org>> wrote: To clarify: 1) The safest thing that allows to build incrementally for now is 'Ive read this > Remove it' which is a really a simple *'Go Away'* 2 ) In addition to this we could support a*'Clear All Read'* from the flyout so a user doesn't have to dismiss one at a time. This still leaves us with the problem of cross linking notification which may be large in volume could make that an *'Opt In'* The reason I think turning off categories in the flyout is problematic is: 1. Dismissing entire categories needs more fine tuning. Users will want to unfollow specific things Articles Discussions etc. 2. Switching off categories also prevents us from incremental fine tune controls in the short term. 3. Other than cross links, so far we dont have enough evidence that users will want to switch entire categories off. We need more time and back end support to figure that out. On Wed, Mar 27, 2013 at 12:23 PM, Vibha Bamba &lt;vbamba(a)wikimedia.org <mailto:vbamba@wikimedia.org>> wrote: I propose: 1) The safest thing that allows to build incrementally for now is 'Ive read this Remove it' 2 ) In addition to this we could support a clear all new from the flyout so a user doesn't have to dismiss one at a time. This still leaves us with the problem of cross linking notification which may be large in volume we could make that an 'opt in' Dismissing entire categories needs more fine tuning. Other than cross links, so far we dont have enough evidence that users will want to switch entire categories off. Users will want to unfollow specific things Articles Discussions etc. We need more time and back end support to figure that out. On Wed, Mar 27, 2013 at 12:17 PM, Isarra Yos &lt;zhorishna(a)gmail.com <mailto:zhorishna@gmail.com>> wrote: But having the option there at all, if its to be removed later for simplicity, could even cause problems - how quickly would users figure out that they dont want a kind of message? On the first one, it probably wont seem worth dismissing all of the type - might be interesting to get more. But once they get twenty in the next day, then it would probably sink in that okay, this is really annoying. But where did the option go? Wasnt there an option? If anything it might lead them away from their preferences because their preferences are not where they saw the option initially. On 27/03/2013 13:11, Matthew Flaschen wrote: On 03/27/2013 03:09 PM, Isarra Yos wrote: Perhaps Im misunderstanding something, but if someone is trying to dismiss several, they wont want a dialog showing up every time, but at the same time even if they dont want to disable all of the type the first time that doesnt mean they wont want to do that later. The option, if its going to be there, needs to be there somewhat consistently. You can still disable the notification category in Special:Preferences . It may be worthwhile to keep the main Echo interface (not preferences) simpler if they choose not to disable the category the first time. Matt Flaschen _______________________________________________ EE mailing list EE(a)lists.wikimedia.org <mailto:EE@lists.wikimedia.org> https://lists.wikimedia.org/mailman/listinfo/ee -- -— Isarra _______________________________________________ EE mailing list EE(a)lists.wikimedia.org <mailto:EE@lists.wikimedia.org> https://lists.wikimedia.org/mailman/listinfo/ee _______________________________________________ EE mailing list EE(a)lists.wikimedia.org <mailto:EE@lists.wikimedia.org> https://lists.wikimedia.org/mailman/listinfo/ee -- Oliver Keyes Community Liaison, Product Development Wikimedia Foundation _______________________________________________ EE mailing list EE(a)lists.wikimedia.org <mailto:EE@lists.wikimedia.org> https://lists.wikimedia.org/mailman/listinfo/ee _______________________________________________ EE mailing list EE(a)lists.wikimedia.org <mailto:EE@lists.wikimedia.org> https://lists.wikimedia.org/mailman/listinfo/ee -- Oliver Keyes Community Liaison, Product Development Wikimedia Foundation _______________________________________________ EE mailing list EE(a)lists.wikimedia.org <mailto:EE@lists.wikimedia.org> https://lists.wikimedia.org/mailman/listinfo/ee _______________________________________________ EE mailing list EE(a)lists.wikimedia.org <mailto:EE@lists.wikimedia.org> https://lists.wikimedia.org/mailman/listinfo/ee -- Oliver Keyes Community Liaison, Product Development Wikimedia Foundation _______________________________________________ EE mailing list EE(a)lists.wikimedia.org <mailto:EE@lists.wikimedia.org> https://lists.wikimedia.org/mailman/listinfo/ee _______________________________________________ EE mailing list EE(a)lists.wikimedia.org <mailto:EE@lists.wikimedia.org> https://lists.wikimedia.org/mailman/listinfo/ee _______________________________________________ EE mailing list EE(a)lists.wikimedia.org <mailto:EE@lists.wikimedia.org> https://lists.wikimedia.org/mailman/listinfo/ee _______________________________________________ EE mailing list EE(a)lists.wikimedia.org <mailto:EE@lists.wikimedia.org> https://lists.wikimedia.org/mailman/listinfo/ee _______________________________________________ EE mailing list EE(a)lists.wikimedia.org <mailto:EE@lists.wikimedia.org> https://lists.wikimedia.org/mailman/listinfo/ee -- Oliver Keyes Community Liaison, Product Development Wikimedia Foundation _______________________________________________ EE mailing list EE(a)lists.wikimedia.org <mailto:EE@lists.wikimedia.org> https://lists.wikimedia.org/mailman/listinfo/ee _______________________________________________ EE mailing list EE(a)lists.wikimedia.org <mailto:EE@lists.wikimedia.org> https://lists.wikimedia.org/mailman/listinfo/ee -- Oliver Keyes Community Liaison, Product Development Wikimedia Foundation _______________________________________________ EE mailing list EE(a)lists.wikimedia.org <mailto:EE@lists.wikimedia.org> https://lists.wikimedia.org/mailman/listinfo/ee _______________________________________________ EE mailing list EE(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee

On Saturday, March 30, 2013, Isarra Yos wrote: Please don't lecture Vibha or anyone else about the time it should take them to do their job. It's extremely rude. *The previous email was simply an email sent in a hurry. **And it is > being treated out of proportion. * > *I assure you we have no intent of working without consensus.* > * > * > I sent an 'immediate follow up email' where I specifically stated that > folks should join the 'Monday meeting' which has been set up for this > purpose along with general feature roundup. Discussions and mocks will be > posted on mediawiki to follow up for those who cannot participate so they > can join in with comments. > > The reason this occurred is because the email was sent in a hurry. > I would also request everyone to understand that we are shortstaffed on > the design team. > We have been unable to hire a visual designer since Lindsey left around > September last year. > Munaf and I are covering production work on E2, E3 and Mobile & design > Outreach. This includes both interaction and visual design. > Just to put things into perspective: It takes one hour to make a simple > icon if it has to be done right. > > The email sent in a hurry because at any given time 2 designers are > balancing a lot of work and sometimes we need to close things out or narrow > solutions before we can manage a discussion between 15 people. > Please recognize that we are doing our best to make sure teams are > supported. We absolutely acknowledge that remote staff needs to and must be > involved. > > If anyone has any concerns please feel free to chat with Howie and me. > I would really appreciate that we close this thread. > It is simply a misunderstanding and nothing else. > > Thanks > Vibha > On Sat, Mar 30, 2013 at 8:38 AM, Oliver Keyes &lt;okeyes(a)wikimedia.org&gt;wrote;wrote: > > So, wide-in-scope-and-slightly-TL;DR followup: > > I'd ask for us to avoid statements like "if you want to see them, come by > my desk". > > This is not something specific to this situation, and I want to take > clear I'm not taking issue with anyone in particular (Vibha and I discussed > the issue, the designs will be in the Monday meeting, no harm, no foul)., > but: I think we have a tendency to have a lot of discussions in-office. > This is something I noticed particularly on my most recent visit to the WMF > HQ, when it became clear precisely how many discussions and ideas were > being had and nixed and pushed forward before seeing the light of day from > a remote worker's perspective, probably aided by meetings people like > Siebrand, Tomasz, Arthur and I have been having with HR and OIT about > bridging the office-remote divide. It's being done becaise we all want the > WMF to work efficiently and quickly. This is understandable, it's laudable, > it's inevitable given the state of perpetual pressure we're under; we have > a thousand things we need to fix and only the resources to fix ten > correctly. We need to move fast and we need to move in the right direction > so that we can get ***something*, the 90 percent product, out rather > than spending eternity spinning our wheels on the 100 percent product. But, > here's the rub: much like the relationship between quitting drinking and > living longer, keeping things in-person doesn't actually make us move > faster, it just makes it feel faster. > > Like it or not, we've got geographically distributed employees. A lot of > them work from SF, sure, but we've got people in Spain, the Netherlands, > India, Australia, the UK. And when important discussions happen in-person, > we exclude them from the conversation. This doesn't make things faste -- Steven Walling https://wikimediafoundation.org/ _______________________________________________ EE mailing list EE(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee

Sending things in a hurry is understandable

According to https://www.mediawiki.org/**wiki/Echo/Feature_** requirements#Started_Page_-_**Linked<https://www.mediawiki.org/wiki/Echo… text we're supposed to use for the 'page linked' notification is: Portland Public Library was linked by Peteforsyth. <See all links to this page>. In this case, I think it is more useful and interesting to know where your article was linked from rather than who performed the linking. Personally, I would suggest: Portland Public Library was linked from Libraries of Oregon. <See all links to this page>. Thoughts? Ryan Kaldari ______________________________**_________________ EE mailing list EE(a)lists.wikimedia.org https://lists.wikimedia.org/**mailman/listinfo/ee<https://lists.wikimedi…

That would work for me too, though I could go either way. -f On Mar 27, 2013, at 1:19 PM, Oliver Keyes wrote: I'd agree with that. Or we could have "user" linked your page "blank" to "blank", although that might be too many links. On 27 March 2013 20:00, Ryan Kaldari &lt;rkaldari(a)wikimedia.org&gt; wrote: -- Oliver Keyes Community Liaison, Product Development Wikimedia Foundation _______________________________________________ EE mailing list EE(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee _______________________________ Fabrice Florin Product Manager, Editor Engagement Wikimedia Foundation http://en.wikipedia.org/wiki/User:Fabrice_Florin_(WMF) Donate to keep Wikipedia free: https://donate.wikimedia.org/ _______________________________________________ EE mailing list EE(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee

On 03/27/2013 04:00 PM, Ryan Kaldari wrote: https://www.mediawiki.org/wiki/Echo/Feature_requirements#Started_Page_-_Lin… Agreed, it should either show both the linker and location of the link ("linked from"), or just "linked from". If too many links is an issue, I don't think the user who made the link needs to be linked. Matt Flaschen _______________________________________________ EE mailing list EE(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee