EE April 2013

ee@lists.wikimedia.org

22 participants
23 discussions

Today's deployed changes to GettingStarted
by Steven Walling 05 Apr '13

05 Apr '13

Hey all, For those of you following the "Getting Started" project we're working on in E3,[1] we made the following updates today... 1. We disabled the A/B split test, so all new users on English Wikipedia will see the latest version of Special:GettingStarted after registration. Dario and I are working on quantitative analysis about the success of this new version, and I have some qualitative analysis of the kinds of edits being made via the new version nearly ready to post. 2. Echo, the notifications feature, isn't yet deployed to English Wikipedia, but we have finished up building notifications for welcoming newly-registered people, and invite them to either make their first edit or keep going, by visiting the task list at GettingStarted. (You can't yet test these on MediaWiki.org, since GettingStarted is not deployed there. Let me know if you're interested in hearing more about these or want to try them out.) -- Steven Walling https://wikimediafoundation.org/ 1. https://www.mediawiki.org/wiki/Onboarding_new_Wikipedians

1 0

Apologies
by Isarra Yos 02 Apr '13

02 Apr '13

Hey all. It seems I have made a bit of a mess here, for which I can only apologise - things were said and certain words and feelings were exchanged that were not exactly productive. In particular I feel I should apologise to Vibha - I was feeling frustrated and unheard, but even so I realise should not have made that comment about the time it takes to make an icon, so I'm sorry. I appreciate that we are all swamped presently, and had no intention of downplaying that. Even in general, however, this has added considerable unnecessary stress, and I would like to apologise for derailing the thread like that. Much of this could have been taken to more appropriate venues or kept private, but unfortunately I acted with little forethought. Sorry about all this. I genuinely want to be helpful, but it can be difficult at times to figure out how to do that. Can we all just pretend I didn't say anything? Thanks, Kim -- -— Isarra

2 1

Echo Dismiss Feature Question
by Fabrice Florin 01 Apr '13

01 Apr '13

Hi folks, We would appreciate your views on the current version of the Dismiss feature, as described here: http://www.mediawiki.org/wiki/Echo_(Notifications)/Feature_requirements#Dis… 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(a)wikimedia.org> wrote: >> On Tue, Mar 5, 2013 at 5:44 PM, Ryan Kaldari <rkaldari(a)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(a)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(a)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(a)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(a)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(a)wikimedia.org> wrote: On 9 January 2013 06:47, Steven Walling <swalling(a)wikimedia.org> wrote: Great idea! Giving people an immediate touch point means they feel like they have control, like swatting a fly.

12 40

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

EE April 2013