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#Dism...
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:
Thanks for all your good insights about this proposed feature, which we had planned to tackle after the first release.
I find Facebook's approach to be pretty intuitive. It seems to be working well for people I know, and I have never heard anyone complain about it.
With Echo, we also limit the number of notifications shown in the flyout based on your screen size, and support limited scrolling up to about 10 notifications. After that, you are encouraged to go to the 'All notifications' page, where you can find at least a week's worth of notifications (we currently support an infinite number of notifications on that archive page, but may have to cut back to a month's worth or so).
Currently, we highlight new notifications in the flyout, so it's easy to tell them apart from old notifications, which seems effective. We then un-hilight them after you have viewed the flyout, which is also consistent with Facebook's approach. An argument could be made that perhaps we should only un-hilight that notification if you have actually clicked on it, but I believe we can wait on this until we have done a usability study.
Since we are already using an 'X' button to dismiss notification types which you don't want to see anymore, it would be awkward to add on additional functionality to that button for dismissing just that particular notification, because it would clutter the user interface.
So a 'Mark all as read' button might be a more effective way to address requests like Antoine's, as described in this proposed feature: http://www.mediawiki.org/wiki/Echo/Feature_requirements#Mark_all_as_read
Though I would argue that the current UI provides a practical solution by automatically un-highlighting notifications you have seen in the flyout, as well as limiting the number of notifications in that flyout.
Either way, I recommend that we wait on this feature until after the first release on Enwiki, which will generate a lot of user feedback which may provide more insights from our community.
I do not support the second suggestion to enable viewing all notifications in the flyout, which would seem highly impractical to me. That's what the "All-notification" page is for, and it's only a click away.
My 2 cents,
Fabrice
On Mar 6, 2013, at 8:47 AM, Luke Welling WMF wrote:
The Facebook approach is nice. The number they show initially varies with screen resolution and their scrolling and lazy loading work well.
Most of it would be relatively easy to copy, although I suspect a lot of testing (or a lot of bug reports) have gone into correctly guessing the number of elements to show based on screen size.
The best thing imho about their approach is that they react to all page visits, and very clearly show a bold notification for a notification sent after you visited that page and a more subtle version for a notification that you have already seen the triggering change for.
That's how they solve the feeling of being overwhelmed by notifications. It keeps the new number down and means that a new notification should only refer to a change you have not seen.
Sadly most people (including us) compromise and show notifications as "new" if you have not seen the notification before, and clear their new status before you click through rather than maintaining the relationship between trigger and notification to give a more accurate version of "new".
The Quora compromise on the same UI feature is different but silly. They keep notifications marked new until you manually clear them. I rarely use Quora and have a completely useless readout that tells me I have 200 new notifications.
Unfortunately I think adding "untriggers" alongside all the notification triggers is significant work, so it should remain a potential future enhancement.
Luke Welling
On Tue, Mar 5, 2013 at 9:13 PM, Erik Moeller erik@wikimedia.org wrote: On Tue, Mar 5, 2013 at 5:44 PM, Ryan Kaldari rkaldari@wikimedia.org wrote:
Both Antoine (hashar) and Reedy have mentioned that they want the ability to remove individual notices after they are read (or clear all read notifications) from the flyout.
One thing I'm wondering about is whether the high number of notifs that are immediately displayed when you click may be contributing to that - the feeling of being overwhelmed by old notifs + desire to make some disappear. FB/web has a pretty sophisticated approach:
- On first click you have a smaller window of notifications (4-5).
- Once you attempt to scroll the notifs list expands vertically to
accommodate a longer list. 3) Scrolling supports dynamic loading of additional notifs for roughly a week's of backlog (which seems to be identical to what's available in "See all").
-- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation
Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate
On Mar 5, 2013, at 5:51 PM, Steven Walling wrote:
On Tue, Mar 5, 2013 at 5:44 PM, Ryan Kaldari rkaldari@wikimedia.org wrote: Both Antoine (hashar) and Reedy have mentioned that they want the ability to remove individual notices after they are read (or clear all read notifications) from the flyout.
This I definitely agree with. You see this pattern in notifications in several contexts (Android ICS has it, Quora, FB I think?).
I'm not sure this is a great idea. If someone really wants to focus on viewing and responding to all unread notifications, asking them to go to a queue of it is likely the simplest and best UX choice IMO.
-- Steven Walling https://wikimediafoundation.org/ _______________________________________________
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 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 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 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 okeyes@wikimedia.org wrote: On 9 January 2013 06:47, Steven Walling swalling@wikimedia.org wrote: Great idea! Giving people an immediate touch point means they feel like they have control, like swatting a fly.
*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 fflorin@wikimedia.orgwrote:
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#Dism...
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:
Thanks for all your good insights about this proposed feature, which we had planned to tackle after the first release.
I find Facebook's approach to be pretty intuitive. It seems to be working well for people I know, and I have never heard anyone complain about it.
With Echo, we also limit the number of notifications shown in the flyout based on your screen size, and support limited scrolling up to about 10 notifications. After that, you are encouraged to go to the 'All notifications' page, where you can find at least a week's worth of notifications (we currently support an infinite number of notifications on that archive page, but may have to cut back to a month's worth or so).
Currently, we highlight new notifications in the flyout, so it's easy to tell them apart from old notifications, which seems effective. We then un-hilight them after you have viewed the flyout, which is also consistent with Facebook's approach. An argument could be made that perhaps we should only un-hilight that notification if you have actually clicked on it, but I believe we can wait on this until we have done a usability study.
Since we are already using an 'X' button to dismiss notification types which you don't want to see anymore, it would be awkward to add on additional functionality to that button for dismissing just that particular notification, because it would clutter the user interface.
So a 'Mark all as read' button might be a more effective way to address requests like Antoine's, as described in this proposed feature: http://www.mediawiki.org/wiki/Echo/Feature_requirements#Mark_all_as_read
Though I would argue that the current UI provides a practical solution by automatically un-highlighting notifications you have seen in the flyout, as well as limiting the number of notifications in that flyout.
Either way, I recommend that we wait on this feature until after the first release on Enwiki, which will generate a lot of user feedback which may provide more insights from our community.
I do not support the second suggestion to enable viewing all notifications in the flyout, which would seem highly impractical to me. That's what the "All-notification" page is for, and it's only a click away.
My 2 cents,
Fabrice
On Mar 6, 2013, at 8:47 AM, Luke Welling WMF wrote:
The Facebook approach is nice. The number they show initially varies with screen resolution and their scrolling and lazy loading work well.
Most of it would be relatively easy to copy, although I suspect a lot of testing (or a lot of bug reports) have gone into correctly guessing the number of elements to show based on screen size.
The best thing imho about their approach is that they react to all page visits, and very clearly show a bold notification for a notification sent after you visited that page and a more subtle version for a notification that you have already seen the triggering change for.
That's how they solve the feeling of being overwhelmed by notifications. It keeps the new number down and means that a new notification should only refer to a change you have not seen.
Sadly most people (including us) compromise and show notifications as "new" if you have not seen the notification before, and clear their new status before you click through rather than maintaining the relationship between trigger and notification to give a more accurate version of "new".
The Quora compromise on the same UI feature is different but silly. They keep notifications marked new until you manually clear them. I rarely use Quora and have a completely useless readout that tells me I have 200 new notifications.
Unfortunately I think adding "untriggers" alongside all the notification triggers is significant work, so it should remain a potential future enhancement.
Luke Welling
On Tue, Mar 5, 2013 at 9:13 PM, Erik Moeller erik@wikimedia.org wrote:
On Tue, Mar 5, 2013 at 5:44 PM, Ryan Kaldari rkaldari@wikimedia.org wrote:
Both Antoine (hashar) and Reedy have mentioned that they want the
ability to
remove individual notices after they are read (or clear all read notifications) from the flyout.
One thing I'm wondering about is whether the high number of notifs that are immediately displayed when you click may be contributing to that - the feeling of being overwhelmed by old notifs + desire to make some disappear. FB/web has a pretty sophisticated approach:
- On first click you have a smaller window of notifications (4-5).
- Once you attempt to scroll the notifs list expands vertically to
accommodate a longer list. 3) Scrolling supports dynamic loading of additional notifs for roughly a week's of backlog (which seems to be identical to what's available in "See all").
-- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation
Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate
On Mar 5, 2013, at 5:51 PM, Steven Walling wrote:
On Tue, Mar 5, 2013 at 5:44 PM, Ryan Kaldari rkaldari@wikimedia.org wrote:
Both Antoine (hashar) and Reedy have mentioned that they want the ability to remove individual notices after they are read (or clear all read notifications) from the flyout.
This I definitely agree with. You see this pattern in notifications in several contexts (Android ICS has it, Quora, FB I think?).
I'm not sure this is a great idea. If someone really wants to focus on viewing and responding to all unread notifications, asking them to go to a queue of it is likely the simplest and best UX choice IMO.
-- Steven Walling https://wikimediafoundation.org/ _______________________________________________
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 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 <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 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 okeyes@wikimedia.org wrote: On 9 January 2013 06:47, Steven Walling 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@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee
On Wed, Mar 27, 2013 at 11:55 AM, Munaf Assaf massaf@wikimedia.org wrote:
*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.
Strong +1 to Munaf's assessment. When I've been using notifications on 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.
Logistically speaking we're getting very close to the enwiki launch, and 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.
Thanks a lot for keeping up with all the feedback on this list Fabrice, and for soliciting more.
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@wikimedia.org wrote:
On Wed, Mar 27, 2013 at 11:55 AM, Munaf Assaf massaf@wikimedia.org wrote: 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.
Strong +1 to Munaf's assessment. When I've been using notifications on 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.
Logistically speaking we're getting very close to the enwiki launch, and 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.
Thanks a lot for keeping up with all the feedback on this list Fabrice, and for soliciting more.
-- Steven Walling https://wikimediafoundation.org/ _______________________________________________ EE mailing list EE@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee
--- Brandon Harris, Senior Designer, Wikimedia Foundation
Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
I think that an inbox zero mechanic sort of works if we treat notifications as a utopian watchlist - but I think we should really *avoid* doing that :/.
On 27 March 2013 19:05, Brandon Harris bharris@wikimedia.org wrote:
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@wikimedia.org wrote:
On Wed, Mar 27, 2013 at 11:55 AM, Munaf Assaf massaf@wikimedia.org
wrote:
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.
Strong +1 to Munaf's assessment. When I've been using notifications on
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.
Logistically speaking we're getting very close to the enwiki launch, and
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.
Thanks a lot for keeping up with all the feedback on this list Fabrice,
and for soliciting more.
-- Steven Walling https://wikimediafoundation.org/ _______________________________________________ EE mailing list EE@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee
Brandon Harris, Senior Designer, Wikimedia Foundation
Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
EE mailing list EE@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee
On Wed, Mar 27, 2013 at 12:05 PM, Brandon Harris bharris@wikimedia.orgwrote:
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.
I don't following the inbox metaphor is precisely what we're talking about here anyway, so let's not go down that rat hole. All I know is that having a dismiss action on an individual notification in the flyout jump straight to a preferences change defies best practices and definitely my own expectations, after having used the feature a bit.
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.
On 27/03/2013 12:55, Munaf Assaf wrote:
*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:
- Click X.
- 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.
- Click "Cancel" because I might want notifications of that type in the future.
- 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:
- Just delete this one item (most prominent)
- Disable notifications of this kind
- Cancel
Munaf
On Wed, Mar 27, 2013 at 11:26 AM, Fabrice Florin <fflorin@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#Dismiss <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:Thanks for all your good insights about this proposed feature, which we had planned to tackle after the first release. I find Facebook's approach to be pretty intuitive. It seems to be working well for people I know, and I have never heard anyone complain about it. With Echo, we also limit the number of notifications shown in the flyout based on your screen size, and support limited scrolling up to about 10 notifications. After that, you are encouraged to go to the 'All notifications' page, where you can find at least a week's worth of notifications (we currently support an infinite number of notifications on that archive page, but may have to cut back to a month's worth or so). Currently, we highlight new notifications in the flyout, so it's easy to tell them apart from old notifications, which seems effective. We then un-hilight them after you have viewed the flyout, which is also consistent with Facebook's approach. An argument could be made that perhaps we should only un-hilight that notification if you have actually clicked on it, but I believe we can wait on this until we have done a usability study. Since we are already using an 'X' button to dismiss notification types which you don't want to see anymore, it would be awkward to add on additional functionality to that button for dismissing just that particular notification, because it would clutter the user interface. So a 'Mark all as read' button might be a more effective way to address requests like Antoine's, as described in this proposed feature: http://www.mediawiki.org/wiki/Echo/Feature_requirements#Mark_all_as_read Though I would argue that the current UI provides a practical solution by automatically un-highlighting notifications you have seen in the flyout, as well as limiting the number of notifications in that flyout. Either way, I recommend that we wait on this feature until after the first release on Enwiki, which will generate a lot of user feedback which may provide more insights from our community. I do not support the second suggestion to enable viewing all notifications in the flyout, which would seem highly impractical to me. That's what the "All-notification" page is for, and it's only a click away. My 2 cents, Fabrice On Mar 6, 2013, at 8:47 AM, Luke Welling WMF wrote:The Facebook approach is nice. The number they show initially varies with screen resolution and their scrolling and lazy loading work well. Most of it would be relatively easy to copy, although I suspect a lot of testing (or a lot of bug reports) have gone into correctly guessing the number of elements to show based on screen size. The best thing imho about their approach is that they react to all page visits, and very clearly show a bold notification for a notification sent after you visited that page and a more subtle version for a notification that you have already seen the triggering change for. That's how they solve the feeling of being overwhelmed by notifications. It keeps the new number down and means that a new notification should only refer to a change you have not seen. Sadly most people (including us) compromise and show notifications as "new" if you have not seen the notification before, and clear their new status before you click through rather than maintaining the relationship between trigger and notification to give a more accurate version of "new". The Quora compromise on the same UI feature is different but silly. They keep notifications marked new until you manually clear them. I rarely use Quora and have a completely useless readout that tells me I have 200 new notifications. Unfortunately I think adding "untriggers" alongside all the notification triggers is significant work, so it should remain a potential future enhancement. Luke Welling On Tue, Mar 5, 2013 at 9:13 PM, Erik Moeller <erik@wikimedia.org <mailto:erik@wikimedia.org>> wrote: On Tue, Mar 5, 2013 at 5:44 PM, Ryan Kaldari <rkaldari@wikimedia.org <mailto:rkaldari@wikimedia.org>> wrote: > Both Antoine (hashar) and Reedy have mentioned that they want the ability to > remove individual notices after they are read (or clear all read > notifications) from the flyout. One thing I'm wondering about is whether the high number of notifs that are immediately displayed when you click may be contributing to that - the feeling of being overwhelmed by old notifs + desire to make some disappear. FB/web has a pretty sophisticated approach: 1) On first click you have a smaller window of notifications (4-5). 2) Once you attempt to scroll the notifs list expands vertically to accommodate a longer list. 3) Scrolling supports dynamic loading of additional notifs for roughly a week's of backlog (which seems to be identical to what's available in "See all"). -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate _______________________________________________On Mar 5, 2013, at 5:51 PM, Steven Walling wrote:On Tue, Mar 5, 2013 at 5:44 PM, Ryan Kaldari <rkaldari@wikimedia.org <mailto:rkaldari@wikimedia.org>> wrote: Both Antoine (hashar) and Reedy have mentioned that they want the ability to remove individual notices after they are read (or clear all read notifications) from the flyout. This I definitely agree with. You see this pattern in notifications in several contexts (Android ICS has it, Quora, FB I think?). I'm not sure this is a great idea. If someone really wants to focus on viewing and responding to all unread notifications, asking them to go to a queue of it is likely the simplest and best UX choice IMO. -- Steven Walling https://wikimediafoundation.org/ _______________________________________________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 <mflaschen@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 <fflorin@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 <erik@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 <okeyes@wikimedia.org <mailto:okeyes@wikimedia.org>> wrote: On 9 January 2013 06:47, Steven Walling <swalling@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@lists.wikimedia.org <mailto:EE@lists.wikimedia.org> https://lists.wikimedia.org/mailman/listinfo/ee
EE mailing list EE@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee
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
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@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 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@lists.wikimedia.org https://lists.wikimedia.org/**mailman/listinfo/eehttps://lists.wikimedia.org/mailman/listinfo/ee
-- -— Isarra
______________________________**_________________ EE mailing list EE@lists.wikimedia.org https://lists.wikimedia.org/**mailman/listinfo/eehttps://lists.wikimedia.org/mailman/listinfo/ee
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 > we 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 vbamba@wikimedia.org wrote:
I propose:
- 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 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@lists.wikimedia.org https://lists.wikimedia.org/**mailman/listinfo/eehttps://lists.wikimedia.org/mailman/listinfo/ee
-- -— Isarra
______________________________**_________________ EE mailing list EE@lists.wikimedia.org https://lists.wikimedia.org/**mailman/listinfo/eehttps://lists.wikimedia.org/mailman/listinfo/ee
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 vbamba@wikimedia.org wrote:
To clarify:
- 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 > we could make that an *'Opt In'*
The reason I think turning off categories in the flyout is problematic is:
- 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 vbamba@wikimedia.orgwrote:
I propose:
- 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 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@lists.wikimedia.org https://lists.wikimedia.org/**mailman/listinfo/eehttps://lists.wikimedia.org/mailman/listinfo/ee
-- -— Isarra
______________________________**_________________ EE mailing list EE@lists.wikimedia.org https://lists.wikimedia.org/**mailman/listinfo/eehttps://lists.wikimedia.org/mailman/listinfo/ee
EE mailing list EE@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee
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 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 vbamba@wikimedia.org wrote:
To clarify:
- 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 > we could make that an *'Opt In'*
The reason I think turning off categories in the flyout is problematic is:
- 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 vbamba@wikimedia.orgwrote:
I propose:
- 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 zhorishna@gmail.comwrote:
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@lists.wikimedia.org https://lists.wikimedia.org/**mailman/listinfo/eehttps://lists.wikimedia.org/mailman/listinfo/ee
-- -— Isarra
______________________________**_________________ EE mailing list EE@lists.wikimedia.org https://lists.wikimedia.org/**mailman/listinfo/eehttps://lists.wikimedia.org/mailman/listinfo/ee
EE mailing list EE@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee
-- Oliver Keyes Community Liaison, Product Development Wikimedia Foundation
EE mailing list EE@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 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 okeyes@wikimedia.orgwrote:
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 vbamba@wikimedia.org wrote:
To clarify:
- 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 > we could make that an *'Opt In'*
The reason I think turning off categories in the flyout is problematic is:
- 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 vbamba@wikimedia.orgwrote:
I propose:
- 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 zhorishna@gmail.comwrote:
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@lists.wikimedia.org https://lists.wikimedia.org/**mailman/listinfo/eehttps://lists.wikimedia.org/mailman/listinfo/ee
-- -— Isarra
______________________________**_________________ EE mailing list EE@lists.wikimedia.org https://lists.wikimedia.org/**mailman/listinfo/eehttps://lists.wikimedia.org/mailman/listinfo/ee
EE mailing list EE@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee
-- Oliver Keyes Community Liaison, Product Development Wikimedia Foundation
EE mailing list EE@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee
EE mailing list EE@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee
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 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 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 okeyes@wikimedia.orgwrote:
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 vbamba@wikimedia.org wrote:
To clarify:
- 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 > we could make that an *'Opt In'*
The reason I think turning off categories in the flyout is problematic is:
- 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 vbamba@wikimedia.orgwrote:
I propose:
- 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 zhorishna@gmail.comwrote:
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@lists.wikimedia.org > https://lists.wikimedia.org/**mailman/listinfo/eehttps://lists.wikimedia.org/mailman/listinfo/ee >
-- -— Isarra
______________________________**_________________ EE mailing list EE@lists.wikimedia.org https://lists.wikimedia.org/**mailman/listinfo/eehttps://lists.wikimedia.org/mailman/listinfo/ee
EE mailing list EE@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee
-- Oliver Keyes Community Liaison, Product Development Wikimedia Foundation
EE mailing list EE@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee
EE mailing list EE@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee
-- Oliver Keyes Community Liaison, Product Development Wikimedia Foundation
EE mailing list EE@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 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 okeyes@wikimedia.orgwrote:
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 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 okeyes@wikimedia.orgwrote:
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 vbamba@wikimedia.org wrote:
To clarify:
- 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 > we could make that an *'Opt In'*
The reason I think turning off categories in the flyout is problematic is:
- 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 vbamba@wikimedia.orgwrote:
I propose:
- 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 zhorishna@gmail.comwrote:
> 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@lists.wikimedia.org >> https://lists.wikimedia.org/**mailman/listinfo/eehttps://lists.wikimedia.org/mailman/listinfo/ee >> > > > -- > -— Isarra > > > > ______________________________**_________________ > EE mailing list > EE@lists.wikimedia.org > https://lists.wikimedia.org/**mailman/listinfo/eehttps://lists.wikimedia.org/mailman/listinfo/ee >
EE mailing list EE@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee
-- Oliver Keyes Community Liaison, Product Development Wikimedia Foundation
EE mailing list EE@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee
EE mailing list EE@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee
-- Oliver Keyes Community Liaison, Product Development Wikimedia Foundation
EE mailing list EE@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee
EE mailing list EE@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee
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 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 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 okeyes@wikimedia.orgwrote:
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 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 okeyes@wikimedia.orgwrote:
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 vbamba@wikimedia.org wrote:
To clarify:
- 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 > we could make that an *'Opt In'*
The reason I think turning off categories in the flyout is problematic is:
- 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 vbamba@wikimedia.orgwrote:
> 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 zhorishna@gmail.comwrote: > >> 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@lists.wikimedia.org >>> https://lists.wikimedia.org/**mailman/listinfo/eehttps://lists.wikimedia.org/mailman/listinfo/ee >>> >> >> >> -- >> -— Isarra >> >> >> >> ______________________________**_________________ >> EE mailing list >> EE@lists.wikimedia.org >> https://lists.wikimedia.org/**mailman/listinfo/eehttps://lists.wikimedia.org/mailman/listinfo/ee >> > >
EE mailing list EE@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee
-- Oliver Keyes Community Liaison, Product Development Wikimedia Foundation
EE mailing list EE@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee
EE mailing list EE@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee
-- Oliver Keyes Community Liaison, Product Development Wikimedia Foundation
EE mailing list EE@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee
EE mailing list EE@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee
-- Oliver Keyes Community Liaison, Product Development Wikimedia Foundation
EE mailing list EE@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 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 okeyes@wikimedia.orgwrote:
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 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 okeyes@wikimedia.orgwrote:
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 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 okeyes@wikimedia.orgwrote:
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 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 > we 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 vbamba@wikimedia.orgwrote: > >> 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 zhorishna@gmail.comwrote: >> >>> 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@lists.wikimedia.org >>>> https://lists.wikimedia.org/**mailman/listinfo/eehttps://lists.wikimedia.org/mailman/listinfo/ee >>>> >>> >>> >>> -- >>> -— Isarra >>> >>> >>> >>> ______________________________**_________________ >>> EE mailing list >>> EE@lists.wikimedia.org >>> https://lists.wikimedia.org/**mailman/listinfo/eehttps://lists.wikimedia.org/mailman/listinfo/ee >>> >> >> > > _______________________________________________ > EE mailing list > EE@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/ee > >
-- Oliver Keyes Community Liaison, Product Development Wikimedia Foundation
EE mailing list EE@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee
EE mailing list EE@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee
-- Oliver Keyes Community Liaison, Product Development Wikimedia Foundation
EE mailing list EE@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee
EE mailing list EE@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee
-- Oliver Keyes Community Liaison, Product Development Wikimedia Foundation
EE mailing list EE@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee
EE mailing list EE@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee
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 lwelling@wikimedia.orgwrote:
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 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 okeyes@wikimedia.orgwrote:
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 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 okeyes@wikimedia.orgwrote:
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 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 okeyes@wikimedia.orgwrote:
> 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 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 > we 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 <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 zhorishna@gmail.comwrote: >>> >>>> 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@lists.wikimedia.org >>>>> https://lists.wikimedia.org/**mailman/listinfo/eehttps://lists.wikimedia.org/mailman/listinfo/ee >>>>> >>>> >>>> >>>> -- >>>> -— Isarra >>>> >>>> >>>> >>>> ______________________________**_________________ >>>> EE mailing list >>>> EE@lists.wikimedia.org >>>> https://lists.wikimedia.org/**mailman/listinfo/eehttps://lists.wikimedia.org/mailman/listinfo/ee >>>> >>> >>> >> >> _______________________________________________ >> EE mailing list >> EE@lists.wikimedia.org >> https://lists.wikimedia.org/mailman/listinfo/ee >> >> > > > -- > Oliver Keyes > Community Liaison, Product Development > Wikimedia Foundation > > _______________________________________________ > EE mailing list > EE@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/ee > >
EE mailing list EE@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee
-- Oliver Keyes Community Liaison, Product Development Wikimedia Foundation
EE mailing list EE@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee
EE mailing list EE@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee
-- Oliver Keyes Community Liaison, Product Development Wikimedia Foundation
EE mailing list EE@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee
EE mailing list EE@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee
EE mailing list EE@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 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 lwelling@wikimedia.orgwrote:
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 vbamba@wikimedia.orgwrote:
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 okeyes@wikimedia.orgwrote:
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 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 okeyes@wikimedia.orgwrote:
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 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 <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 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 > we 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 < >>> 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 <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@lists.wikimedia.org >>>>>> https://lists.wikimedia.org/**mailman/listinfo/eehttps://lists.wikimedia.org/mailman/listinfo/ee >>>>>> >>>>> >>>>> >>>>> -- >>>>> -— Isarra >>>>> >>>>> >>>>> >>>>> ______________________________**_________________ >>>>> EE mailing list >>>>> EE@lists.wikimedia.org >>>>> https://lists.wikimedia.org/**mailman/listinfo/eehttps://lists.wikimedia.org/mailman/listinfo/ee >>>>> >>>> >>>> >>> >>> _______________________________________________ >>> EE mailing list >>> EE@lists.wikimedia.org >>> https://lists.wikimedia.org/mailman/listinfo/ee >>> >>> >> >> >> -- >> Oliver Keyes >> Community Liaison, Product Development >> Wikimedia Foundation >> >> _______________________________________________ >> EE mailing list >> EE@lists.wikimedia.org >> https://lists.wikimedia.org/mailman/listinfo/ee >> >> > > _______________________________________________ > EE mailing list > EE@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/ee > >
-- Oliver Keyes Community Liaison, Product Development Wikimedia Foundation
EE mailing list EE@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee
EE mailing list EE@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee
-- Oliver Keyes Community Liaison, Product Development Wikimedia Foundation
EE mailing list EE@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee
EE mailing list EE@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee
EE mailing list EE@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee
EE mailing list EE@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee
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 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 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 <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 vbamba@wikimedia.orgwrote:
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 okeyes@wikimedia.orgwrote:
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 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 okeyes@wikimedia.orgwrote:
> 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 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 < >> 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 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 > we 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 < >>>> 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 < >>>>> 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@lists.wikimedia.org >>>>>>> https://lists.wikimedia.org/**mailman/listinfo/eehttps://lists.wikimedia.org/mailman/listinfo/ee >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> -— Isarra >>>>>> >>>>>> >>>>>> >>>>>> ______________________________**_________________ >>>>>> EE mailing list >>>>>> EE@lists.wikimedia.org >>>>>> https://lists.wikimedia.org/**mailman/listinfo/eehttps://lists.wikimedia.org/mailman/listinfo/ee >>>>>> >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> EE mailing list >>>> EE@lists.wikimedia.org >>>> https://lists.wikimedia.org/mailman/listinfo/ee >>>> >>>> >>> >>> >>> -- >>> Oliver Keyes >>> Community Liaison, Product Development >>> Wikimedia Foundation >>> >>> _______________________________________________ >>> EE mailing list >>> EE@lists.wikimedia.org >>> https://lists.wikimedia.org/mailman/listinfo/ee >>> >>> >> >> _______________________________________________ >> EE mailing list >> EE@lists.wikimedia.org >> https://lists.wikimedia.org/mailman/listinfo/ee >> >> > > > -- > Oliver Keyes > Community Liaison, Product Development > Wikimedia Foundation > > _______________________________________________ > EE mailing list > EE@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/ee > >
EE mailing list EE@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee
-- Oliver Keyes Community Liaison, Product Development Wikimedia Foundation
EE mailing list EE@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee
EE mailing list EE@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee
EE mailing list EE@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee
EE mailing list EE@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee
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 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 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 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 < 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 vbamba@wikimedia.orgwrote:
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 okeyes@wikimedia.orgwrote:
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 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 okeyes@wikimedia.orgwrote: > >> 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 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 < >>> 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 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 > we 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 < >>>>> 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 < >>>>>> 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@lists.wikimedia.org >>>>>>>> https://lists.wikimedia.org/**mailman/listinfo/eehttps://lists.wikimedia.org/mailman/listinfo/ee >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> -— Isarra >>>>>>> >>>>>>> >>>>>>> >>>>>>> ______________________________**_________________ >>>>>>> EE mailing list >>>>>>> EE@lists.wikimedia.org >>>>>>> https://lists.wikimedia.org/**mailman/listinfo/eehttps://lists.wikimedia.org/mailman/listinfo/ee >>>>>>> >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> EE mailing list >>>>> EE@lists.wikimedia.org >>>>> https://lists.wikimedia.org/mailman/listinfo/ee >>>>> >>>>> >>>> >>>> >>>> -- >>>> Oliver Keyes >>>> Community Liaison, Product Development >>>> Wikimedia Foundation >>>> >>>> _______________________________________________ >>>> EE mailing list >>>> EE@lists.wikimedia.org >>>> https://lists.wikimedia.org/mailman/listinfo/ee >>>> >>>> >>> >>> _______________________________________________ >>> EE mailing list >>> EE@lists.wikimedia.org >>> https://lists.wikimedia.org/mailman/listinfo/ee >>> >>> >> >> >> -- >> Oliver Keyes >> Community Liaison, Product Development >> Wikimedia Foundation >> >> _______________________________________________ >> EE mailing list >> EE@lists.wikimedia.org >> https://lists.wikimedia.org/mailman/listinfo/ee >> >> > > _______________________________________________ > EE mailing list > EE@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/ee > >
-- Oliver Keyes Community Liaison, Product Development Wikimedia Foundation
EE mailing list EE@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee
EE mailing list EE@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee
EE mailing list EE@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee
EE mailing list EE@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee
EE mailing list EE@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee
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 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 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 vbamba@wikimedia.orgwrote:
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 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 < 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 vbamba@wikimedia.orgwrote:
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 okeyes@wikimedia.orgwrote:
> 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 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 <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 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 < >>>> 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 vbamba@wikimedia.orgwrote: >>>>> >>>>>> 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 > we 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 < >>>>>> 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 < >>>>>>> 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@lists.wikimedia.org >>>>>>>>> https://lists.wikimedia.org/**mailman/listinfo/eehttps://lists.wikimedia.org/mailman/listinfo/ee >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> -— Isarra >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ______________________________**_________________ >>>>>>>> EE mailing list >>>>>>>> EE@lists.wikimedia.org >>>>>>>> https://lists.wikimedia.org/**mailman/listinfo/eehttps://lists.wikimedia.org/mailman/listinfo/ee >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> EE mailing list >>>>>> EE@lists.wikimedia.org >>>>>> https://lists.wikimedia.org/mailman/listinfo/ee >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Oliver Keyes >>>>> Community Liaison, Product Development >>>>> Wikimedia Foundation >>>>> >>>>> _______________________________________________ >>>>> EE mailing list >>>>> EE@lists.wikimedia.org >>>>> https://lists.wikimedia.org/mailman/listinfo/ee >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> EE mailing list >>>> EE@lists.wikimedia.org >>>> https://lists.wikimedia.org/mailman/listinfo/ee >>>> >>>> >>> >>> >>> -- >>> Oliver Keyes >>> Community Liaison, Product Development >>> Wikimedia Foundation >>> >>> _______________________________________________ >>> EE mailing list >>> EE@lists.wikimedia.org >>> https://lists.wikimedia.org/mailman/listinfo/ee >>> >>> >> >> _______________________________________________ >> EE mailing list >> EE@lists.wikimedia.org >> https://lists.wikimedia.org/mailman/listinfo/ee >> >> > > > -- > Oliver Keyes > Community Liaison, Product Development > Wikimedia Foundation > > _______________________________________________ > EE mailing list > EE@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/ee > >
EE mailing list EE@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee
EE mailing list EE@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee
EE mailing list EE@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee
EE mailing list EE@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee
-- Oliver Keyes Community Liaison, Product Development Wikimedia Foundation
EE mailing list EE@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 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 okeyes@wikimedia.orgwrote:
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 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 vbamba@wikimedia.orgwrote:
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 bsitu@wikimedia.orgwrote:
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 < 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 vbamba@wikimedia.orgwrote:
> 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 okeyes@wikimedia.orgwrote: > >> 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 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 < >>> 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 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 < >>>>> 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 vbamba@wikimedia.orgwrote: >>>>>> >>>>>>> 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 > we 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 < >>>>>>> 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 < >>>>>>>> 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@lists.wikimedia.org >>>>>>>>>> https://lists.wikimedia.org/**mailman/listinfo/eehttps://lists.wikimedia.org/mailman/listinfo/ee >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> -— Isarra >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> ______________________________**_________________ >>>>>>>>> EE mailing list >>>>>>>>> EE@lists.wikimedia.org >>>>>>>>> https://lists.wikimedia.org/**mailman/listinfo/eehttps://lists.wikimedia.org/mailman/listinfo/ee >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> EE mailing list >>>>>>> EE@lists.wikimedia.org >>>>>>> https://lists.wikimedia.org/mailman/listinfo/ee >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Oliver Keyes >>>>>> Community Liaison, Product Development >>>>>> Wikimedia Foundation >>>>>> >>>>>> _______________________________________________ >>>>>> EE mailing list >>>>>> EE@lists.wikimedia.org >>>>>> https://lists.wikimedia.org/mailman/listinfo/ee >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> EE mailing list >>>>> EE@lists.wikimedia.org >>>>> https://lists.wikimedia.org/mailman/listinfo/ee >>>>> >>>>> >>>> >>>> >>>> -- >>>> Oliver Keyes >>>> Community Liaison, Product Development >>>> Wikimedia Foundation >>>> >>>> _______________________________________________ >>>> EE mailing list >>>> EE@lists.wikimedia.org >>>> https://lists.wikimedia.org/mailman/listinfo/ee >>>> >>>> >>> >>> _______________________________________________ >>> EE mailing list >>> EE@lists.wikimedia.org >>> https://lists.wikimedia.org/mailman/listinfo/ee >>> >>> >> >> >> -- >> Oliver Keyes >> Community Liaison, Product Development >> Wikimedia Foundation >> >> _______________________________________________ >> EE mailing list >> EE@lists.wikimedia.org >> https://lists.wikimedia.org/mailman/listinfo/ee >> >> > > _______________________________________________ > EE mailing list > EE@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/ee > >
EE mailing list EE@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee
EE mailing list EE@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee
EE mailing list EE@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee
-- Oliver Keyes Community Liaison, Product Development Wikimedia Foundation
EE mailing list EE@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee
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 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 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 okeyes@wikimedia.orgwrote:
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 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 vbamba@wikimedia.orgwrote:
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 bsitu@wikimedia.orgwrote:
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 < 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 vbamba@wikimedia.orgwrote: > >> 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 <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 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 < >>>> 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 vbamba@wikimedia.orgwrote: >>>>> >>>>>> 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 < >>>>>> 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 vbamba@wikimedia.orgwrote: >>>>>>> >>>>>>>> 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 > we 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 < >>>>>>>> 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 < >>>>>>>>> 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@lists.wikimedia.org >>>>>>>>>>> https://lists.wikimedia.org/**mailman/listinfo/eehttps://lists.wikimedia.org/mailman/listinfo/ee >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> -— Isarra >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ______________________________**_________________ >>>>>>>>>> EE mailing list >>>>>>>>>> EE@lists.wikimedia.org >>>>>>>>>> https://lists.wikimedia.org/**mailman/listinfo/eehttps://lists.wikimedia.org/mailman/listinfo/ee >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> EE mailing list >>>>>>>> EE@lists.wikimedia.org >>>>>>>> https://lists.wikimedia.org/mailman/listinfo/ee >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Oliver Keyes >>>>>>> Community Liaison, Product Development >>>>>>> Wikimedia Foundation >>>>>>> >>>>>>> _______________________________________________ >>>>>>> EE mailing list >>>>>>> EE@lists.wikimedia.org >>>>>>> https://lists.wikimedia.org/mailman/listinfo/ee >>>>>>> >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> EE mailing list >>>>>> EE@lists.wikimedia.org >>>>>> https://lists.wikimedia.org/mailman/listinfo/ee >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Oliver Keyes >>>>> Community Liaison, Product Development >>>>> Wikimedia Foundation >>>>> >>>>> _______________________________________________ >>>>> EE mailing list >>>>> EE@lists.wikimedia.org >>>>> https://lists.wikimedia.org/mailman/listinfo/ee >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> EE mailing list >>>> EE@lists.wikimedia.org >>>> https://lists.wikimedia.org/mailman/listinfo/ee >>>> >>>> >>> >>> >>> -- >>> Oliver Keyes >>> Community Liaison, Product Development >>> Wikimedia Foundation >>> >>> _______________________________________________ >>> EE mailing list >>> EE@lists.wikimedia.org >>> https://lists.wikimedia.org/mailman/listinfo/ee >>> >>> >> >> _______________________________________________ >> EE mailing list >> EE@lists.wikimedia.org >> https://lists.wikimedia.org/mailman/listinfo/ee >> >> > > _______________________________________________ > EE mailing list > EE@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/ee > >
EE mailing list EE@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee
EE mailing list EE@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee
-- Oliver Keyes Community Liaison, Product Development Wikimedia Foundation
EE mailing list EE@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee
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 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 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 vbamba@wikimedia.orgwrote:
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 okeyes@wikimedia.orgwrote:
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 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 vbamba@wikimedia.orgwrote:
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 bsitu@wikimedia.orgwrote:
> 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 < > 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 vbamba@wikimedia.orgwrote: >> >>> 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 < >>> 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 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 < >>>>> 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 vbamba@wikimedia.orgwrote: >>>>>> >>>>>>> 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 < >>>>>>> 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 vbamba@wikimedia.orgwrote: >>>>>>>> >>>>>>>>> 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 > we 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 < >>>>>>>>> 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 < >>>>>>>>>> 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@lists.wikimedia.org >>>>>>>>>>>> https://lists.wikimedia.org/**mailman/listinfo/eehttps://lists.wikimedia.org/mailman/listinfo/ee >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> -— Isarra >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> ______________________________**_________________ >>>>>>>>>>> EE mailing list >>>>>>>>>>> EE@lists.wikimedia.org >>>>>>>>>>> https://lists.wikimedia.org/**mailman/listinfo/eehttps://lists.wikimedia.org/mailman/listinfo/ee >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> EE mailing list >>>>>>>>> EE@lists.wikimedia.org >>>>>>>>> https://lists.wikimedia.org/mailman/listinfo/ee >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Oliver Keyes >>>>>>>> Community Liaison, Product Development >>>>>>>> Wikimedia Foundation >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> EE mailing list >>>>>>>> EE@lists.wikimedia.org >>>>>>>> https://lists.wikimedia.org/mailman/listinfo/ee >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> EE mailing list >>>>>>> EE@lists.wikimedia.org >>>>>>> https://lists.wikimedia.org/mailman/listinfo/ee >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Oliver Keyes >>>>>> Community Liaison, Product Development >>>>>> Wikimedia Foundation >>>>>> >>>>>> _______________________________________________ >>>>>> EE mailing list >>>>>> EE@lists.wikimedia.org >>>>>> https://lists.wikimedia.org/mailman/listinfo/ee >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> EE mailing list >>>>> EE@lists.wikimedia.org >>>>> https://lists.wikimedia.org/mailman/listinfo/ee >>>>> >>>>> >>>> >>>> >>>> -- >>>> Oliver Keyes >>>> Community Liaison, Product Development >>>> Wikimedia Foundation >>>> >>>> _______________________________________________ >>>> EE mailing list >>>> EE@lists.wikimedia.org >>>> https://lists.wikimedia.org/mailman/listinfo/ee >>>> >>>> >>> >>> _______________________________________________ >>> EE mailing list >>> EE@lists.wikimedia.org >>> https://lists.wikimedia.org/mailman/listinfo/ee >>> >>> >> >> _______________________________________________ >> EE mailing list >> EE@lists.wikimedia.org >> https://lists.wikimedia.org/mailman/listinfo/ee >> >> > > _______________________________________________ > EE mailing list > EE@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/ee > >
EE mailing list EE@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee
-- Oliver Keyes Community Liaison, Product Development Wikimedia Foundation
EE mailing list EE@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee
EE mailing list EE@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee
On Sat, Mar 30, 2013 at 8:38 AM, Oliver Keyes 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".
I don't agree with everything Oliver says following, though it is quite eloquently put, and we could redirect the thread in to a discussion of remote participation... but I think his suggestion above is one to take in account for the future. When we share on a mailing list with remote WMF participants and/or on a public mailing list with community members obviously not in the office, we need to not limit our feedback mechanisms and calls to action to those with the advantage of being locally present.
Other than that, have a good weekend all. ;-)
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 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 vbamba@wikimedia.orgwrote:
*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 vbamba@wikimedia.orgwrote:
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 okeyes@wikimedia.orgwrote:
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 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 vbamba@wikimedia.orgwrote:
> 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 bsitu@wikimedia.orgwrote: > >> 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 < >> 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 <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 < >>>> 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 vbamba@wikimedia.orgwrote: >>>>> >>>>>> 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 < >>>>>> 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 vbamba@wikimedia.orgwrote: >>>>>>> >>>>>>>> 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 < >>>>>>>> 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 vbamba@wikimedia.orgwrote: >>>>>>>>> >>>>>>>>>> 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 > we 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 < >>>>>>>>>> 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 < >>>>>>>>>>> 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@lists.wikimedia.org >>>>>>>>>>>>> https://lists.wikimedia.org/**mailman/listinfo/eehttps://lists.wikimedia.org/mailman/listinfo/ee >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> -— Isarra >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> ______________________________**_________________ >>>>>>>>>>>> EE mailing list >>>>>>>>>>>> EE@lists.wikimedia.org >>>>>>>>>>>> https://lists.wikimedia.org/**mailman/listinfo/eehttps://lists.wikimedia.org/mailman/listinfo/ee >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> EE mailing list >>>>>>>>>> EE@lists.wikimedia.org >>>>>>>>>> https://lists.wikimedia.org/mailman/listinfo/ee >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Oliver Keyes >>>>>>>>> Community Liaison, Product Development >>>>>>>>> Wikimedia Foundation >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> EE mailing list >>>>>>>>> EE@lists.wikimedia.org >>>>>>>>> https://lists.wikimedia.org/mailman/listinfo/ee >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> EE mailing list >>>>>>>> EE@lists.wikimedia.org >>>>>>>> https://lists.wikimedia.org/mailman/listinfo/ee >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Oliver Keyes >>>>>>> Community Liaison, Product Development >>>>>>> Wikimedia Foundation >>>>>>> >>>>>>> _______________________________________________ >>>>>>> EE mailing list >>>>>>> EE@lists.wikimedia.org >>>>>>> https://lists.wikimedia.org/mailman/listinfo/ee >>>>>>> >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> EE mailing list >>>>>> EE@lists.wikimedia.org >>>>>> https://lists.wikimedia.org/mailman/listinfo/ee >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Oliver Keyes >>>>> Community Liaison, Product Development >>>>> Wikimedia Foundation >>>>> >>>>> _______________________________________________ >>>>> EE mailing list >>>>> EE@lists.wikimedia.org >>>>> https://lists.wikimedia.org/mailman/listinfo/ee >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> EE mailing list >>>> EE@lists.wikimedia.org >>>> https://lists.wikimedia.org/mailman/listinfo/ee >>>> >>>> >>> >>> _______________________________________________ >>> EE mailing list >>> EE@lists.wikimedia.org >>> https://lists.wikimedia.org/mailman/listinfo/ee >>> >>> >> >> _______________________________________________ >> EE mailing list >> EE@lists.wikimedia.org >> https://lists.wikimedia.org/mailman/listinfo/ee >> >> >
EE mailing list EE@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee
-- Oliver Keyes Community Liaison, Product Development Wikimedia Foundation
EE mailing list EE@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee
EE mailing list EE@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee
-- Oliver Keyes Community Liaison, Product Development Wikimedia Foundation
EE mailing list EE@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 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 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 vbamba@wikimedia.orgwrote:
*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 vbamba@wikimedia.orgwrote:
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 okeyes@wikimedia.orgwrote:
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 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 vbamba@wikimedia.orgwrote:
> 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 bsitu@wikimedia.orgwrote: > >> 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 < >> 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 <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 < >>>> 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 vbamba@wikimedia.orgwrote: >>>>> >>>>>> 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 < >>>>>> 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 vbamba@wikimedia.orgwrote: >>>>>>> >>>>>>>> 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 < >>>>>>>> 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 vbamba@wikimedia.orgwrote: >>>>>>>>> >>>>>>>>>> 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 > we 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 < >>>>>>>>>> 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 < >>>>>>>>>>> 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@lists.wikimedia.org >>>>>>>>>>>>> https://lists.wikimedia.org/**mailman/listinfo/eehttps://lists.wikimedia.org/mailman/listinfo/ee >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> -— Isarra >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> ______________________________**_________________ >>>>>>>>>>>> EE mailing list >>>>>>>>>>>> EE@lists.wikimedia.org >>>>>>>>>>>> https://lists.wikimedia.org/**mailman/listinfo/eehttps://lists.wikimedia.org/mailman/listinfo/ee >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> EE mailing list >>>>>>>>>> EE@lists.wikimedia.org >>>>>>>>>> https://lists.wikimedia.org/mailman/listinfo/ee >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Oliver Keyes >>>>>>>>> Community Liaison, Product Development >>>>>>>>> Wikimedia Foundation >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> EE mailing list >>>>>>>>> EE@lists.wikimedia.org >>>>>>>>> https://lists.wikimedia.org/mailman/listinfo/ee >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> EE mailing list >>>>>>>> EE@lists.wikimedia.org >>>>>>>> https://lists.wikimedia.org/mailman/listinfo/ee >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Oliver Keyes >>>>>>> Community Liaison, Product Development >>>>>>> Wikimedia Foundation >>>>>>> >>>>>>> _______________________________________________ >>>>>>> EE mailing list >>>>>>> EE@lists.wikimedia.org >>>>>>> https://lists.wikimedia.org/mailman/listinfo/ee >>>>>>> >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> EE mailing list >>>>>> EE@lists.wikimedia.org >>>>>> https://lists.wikimedia.org/mailman/listinfo/ee >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Oliver Keyes >>>>> Community Liaison, Product Development >>>>> Wikimedia Foundation >>>>> >>>>> _______________________________________________ >>>>> EE mailing list >>>>> EE@lists.wikimedia.org >>>>> https://lists.wikimedia.org/mailman/listinfo/ee >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> EE mailing list >>>> EE@lists.wikimedia.org >>>> https://lists.wikimedia.org/mailman/listinfo/ee >>>> >>>> >>> >>> _______________________________________________ >>> EE mailing list >>> EE@lists.wikimedia.org >>> https://lists.wikimedia.org/mailman/listinfo/ee >>> >>> >> >> _______________________________________________ >> EE mailing list >> EE@lists.wikimedia.org >> https://lists.wikimedia.org/mailman/listinfo/ee >> >> >
EE mailing list EE@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee
-- Oliver Keyes Community Liaison, Product Development Wikimedia Foundation
EE mailing list EE@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee
EE mailing list EE@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee
-- Oliver Keyes Community Liaison, Product Development Wikimedia Foundation
EE mailing list EE@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee
Sending things in a hurry is understandable, but regardless of how things are sent, the affects are felt. Not all of us receiving these emails work in the office, as Oliver states, so it alienates them especially as part of a larger tendency to leave them out of the loop in general, but nor are all the folks following this even staff. And while those of us who are volunteers, developers and users alike, understand that of course we will be left out at times, that doesn't make it any easier for us when a seemingly open discussion ends with 'this will be in the meeting' for the same reason we would be following in the first place - because we care. Because this affects us same as it affects all others working remotely who have to implement the results or implement around them, and because we will be using it. So please, be careful with what you say.
That said, it should not take an hour to do a simple icon. If it is part of an existing set with the general style already laid out, a single graphic like that should really be taking all of five minutes - if it isn't, there are probably deeper problems (perhaps with said general style?) at play. Perhaps if we talk later I might be able to help with that, but I suspect neither of us are in any shape presently to even deal with sorting that out.
On 31/03/13 05:05, Vibha Bamba wrote:
/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 <okeyes@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 <vbamba@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 <vbamba@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 <vbamba@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 <okeyes@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 <vbamba@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 <vbamba@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 <bsitu@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 <lwelling@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 <vbamba@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 <okeyes@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 <vbamba@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 <okeyes@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 <vbamba@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 <okeyes@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 <vbamba@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 > we 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 <vbamba@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 <zhorishna@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@lists.wikimedia.org <mailto:EE@lists.wikimedia.org> https://lists.wikimedia.org/mailman/listinfo/ee -- -— Isarra _______________________________________________ EE mailing list EE@lists.wikimedia.org <mailto:EE@lists.wikimedia.org> https://lists.wikimedia.org/mailman/listinfo/ee _______________________________________________ EE mailing list EE@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@lists.wikimedia.org <mailto:EE@lists.wikimedia.org> https://lists.wikimedia.org/mailman/listinfo/ee _______________________________________________ EE mailing list EE@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@lists.wikimedia.org <mailto:EE@lists.wikimedia.org> https://lists.wikimedia.org/mailman/listinfo/ee _______________________________________________ EE mailing list EE@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@lists.wikimedia.org <mailto:EE@lists.wikimedia.org> https://lists.wikimedia.org/mailman/listinfo/ee _______________________________________________ EE mailing list EE@lists.wikimedia.org <mailto:EE@lists.wikimedia.org> https://lists.wikimedia.org/mailman/listinfo/ee _______________________________________________ EE mailing list EE@lists.wikimedia.org <mailto:EE@lists.wikimedia.org> https://lists.wikimedia.org/mailman/listinfo/ee _______________________________________________ EE mailing list EE@lists.wikimedia.org <mailto:EE@lists.wikimedia.org> https://lists.wikimedia.org/mailman/listinfo/ee _______________________________________________ EE mailing list EE@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@lists.wikimedia.org <mailto:EE@lists.wikimedia.org> https://lists.wikimedia.org/mailman/listinfo/ee _______________________________________________ EE mailing list EE@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@lists.wikimedia.org <mailto:EE@lists.wikimedia.org> https://lists.wikimedia.org/mailman/listinfo/ee
EE mailing list EE@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee
On Saturday, March 30, 2013, Isarra Yos wrote:
That said, it should not take an hour to do a simple icon. If it is part of an existing set with the general style already laid out, a single graphic like that should really be taking all of five minutes - if it isn't, there are probably deeper problems (perhaps with said general style?) at play. Perhaps if we talk later I might be able to help with that, but I suspect neither of us are in any shape presently to even deal with sorting that out.
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 okeyes@wikimedia.orgwrote:
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
Adding Gayle.
On Sat, Mar 30, 2013 at 9:54 PM, Steven Walling swalling@wikimedia.orgwrote:
On Saturday, March 30, 2013, Isarra Yos wrote:
That said, it should not take an hour to do a simple icon. If it is part of an existing set with the general style already laid out, a single graphic like that should really be taking all of five minutes - if it isn't, there are probably deeper problems (perhaps with said general style?) at play. Perhaps if we talk later I might be able to help with that, but I suspect neither of us are in any shape presently to even deal with sorting that out.
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 okeyes@wikimedia.orgwrote:
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@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee
I was trying to offer the help. I apologise if that's not how it came across.
On 31/03/13 05:54, Steven Walling wrote:
On Saturday, March 30, 2013, Isarra Yos wrote:
That said, it should not take an hour to do a simple icon. If it is part of an existing set with the general style already laid out, a single graphic like that should really be taking all of five minutes - if it isn't, there are probably deeper problems (perhaps with said general style?) at play. Perhaps if we talk later I might be able to help with that, but I suspect neither of us are in any shape presently to even deal with sorting that out.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 <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 faste-- Steven Walling https://wikimediafoundation.org/
EE mailing list EE@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee
On Sat, Mar 30, 2013 at 9:50 PM, Isarra Yos zhorishna@gmail.com wrote:
Sending things in a hurry is understandable
Kim,
I have to agree with Steven that your comments here were unhelpful. I understand the general desire to reinforce the remote/in-person issue as well as the need to be in touch with volunteers, but Oliver already made this point, so at this point you're simply piling on. Moreover, the part of your comment Steven called out could indeed be read as aggressive and patronizing, even if it was not intended that way.
As Vibha requested, I suggest we close this thread and move on. Everyone understands the need to collaborate on-wiki/on-list where possible.
Enjoy your weekend, Erik
-- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation
Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate
I was under the impression Fabrice took the discussion here to try to get wider input. Vibha's comments came as a slap in the face of that, and while I know it was not what she intended, her response post did not seem to indicate much understanding beyond the fact sometimes we all send things in a hurry and at times don't send quite what we meant.
That said, text is a difficult medium in which to communicate effectively, and piling on can at times be the only way to get a message across - and I suppose you have. Perhaps I should just avoid this list in the future.
On 31/03/13 06:11, Erik Moeller wrote:
On Sat, Mar 30, 2013 at 9:50 PM, Isarra Yos zhorishna@gmail.com wrote:
Sending things in a hurry is understandable
Kim,
I have to agree with Steven that your comments here were unhelpful. I understand the general desire to reinforce the remote/in-person issue as well as the need to be in touch with volunteers, but Oliver already made this point, so at this point you're simply piling on. Moreover, the part of your comment Steven called out could indeed be read as aggressive and patronizing, even if it was not intended that way.
As Vibha requested, I suggest we close this thread and move on. Everyone understands the need to collaborate on-wiki/on-list where possible.
Enjoy your weekend, Erik
-- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation
Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate
EE mailing list EE@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee
Hi folks,
I'd like to give you a quick update on the status of the Echo Dismiss feature.
First, I would like to thank everyone who participated in this discussion: you've made some great suggestions, and your insights will help inform our next steps for solving this complex issue.
Though we made some good progress together last week, we have not yet reached consensus on this issue, as some people like the current version of that feature, while others like the 'Go away' idea, and a third group would like a combination of the two -- which we will want to explore some more in coming weeks.
Our next steps are to review this feedback in our weekly E2 team meeting tomorrow morning -- along with Vibha's mockups, which she will present on Google Hangouts (so that remote workers can see them as well). We also plan to post these mockups online after that meeting, and we will post another update later that day.
Based on our team meetings and more community feedback, we are open to removing this feature from the upcoming release of Echo in a couple weeks, if the consensus is that's the right thing to do. Given everything else that's on our plate for this deployment, it's likely that a new version would take a few more weeks to develop, and we would like to do this in consultation with community members. So you will all have an opportunity to comment some more, after we have concrete options for you to review.
Thanks again for all your great contributions. Stay tuned for our next update.
All the best,
Fabrice
P.S.: We're sorry that this email discussion got off track over the weekend, but I would like to reassure everyone that we will continue to exert our best efforts to make mockups and other feature proposals available online, so that all community members and remote workers can participate effectively in our discussions. Sorry for any inconvenience, and thanks for your understanding. :)
_______________________________
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/
According to https://www.mediawiki.org/wiki/Echo/Feature_requirements#Started_Page_-_Link... the 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
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 rkaldari@wikimedia.org wrote:
According to https://www.mediawiki.org/**wiki/Echo/Feature_** requirements#Started_Page_-_**Linkedhttps://www.mediawiki.org/wiki/Echo/Feature_requirements#Started_Page_-_Linkedthe 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@lists.wikimedia.org https://lists.wikimedia.org/**mailman/listinfo/eehttps://lists.wikimedia.org/mailman/listinfo/ee
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 rkaldari@wikimedia.org wrote: According to https://www.mediawiki.org/wiki/Echo/Feature_requirements#Started_Page_-_Link... the 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@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee
-- Oliver Keyes Community Liaison, Product Development Wikimedia Foundation _______________________________________________ EE mailing list EE@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/
I get the reluctance to have lots of links in the overlay, but I don't think there can be "too many links" in the view all view and html email*.
That extensive cross linking from article to article is a very Wikipedia trait to me. Following links from one article to related one via link in the text is a normal navigation pattern.
Facebook's view all view has up to 6 links per event in my current set (although the timestamp links to the same main target as one of the other links). If their userbase can handle 6 ours can manage at least that many.
Luke
* Text email would look clunky with lots, but it's an uncommon use case
On Wed, Mar 27, 2013 at 4:39 PM, Fabrice Florin fflorin@wikimedia.orgwrote:
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 rkaldari@wikimedia.org wrote:
According to https://www.mediawiki.org/**wiki/Echo/Feature_** requirements#Started_Page_-_**Linkedhttps://www.mediawiki.org/wiki/Echo/Feature_requirements#Started_Page_-_Linkedthe 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@lists.wikimedia.org https://lists.wikimedia.org/**mailman/listinfo/eehttps://lists.wikimedia.org/mailman/listinfo/ee
-- Oliver Keyes Community Liaison, Product Development Wikimedia Foundation _______________________________________________ EE mailing list EE@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@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee
On 03/27/2013 04:00 PM, Ryan Kaldari wrote:
According to https://www.mediawiki.org/wiki/Echo/Feature_requirements#Started_Page_-_Link... the 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>.
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
Sounds good! The bundle version would become: Portland Public Library was linked from Libraries of Oregon and X other pages <See all links to this page>
On Wed, Mar 27, 2013 at 3:03 PM, Matthew Flaschen mflaschen@wikimedia.orgwrote:
On 03/27/2013 04:00 PM, Ryan Kaldari wrote:
According to
https://www.mediawiki.org/wiki/Echo/Feature_requirements#Started_Page_-_Link...
the 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>.
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@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee