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:
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(a)wikimedia.org <mailto:fflorin@wikimedia.org>> wrote:
Hi folks,
We would appreciate your views on the current version of the
Dismiss feature, as described here:
http://www.mediawiki.org/wiki/Echo_(Notifications)/Feature_requirements#Dis…
<http://www.mediawiki.org/wiki/Echo_%28Notifications%29/Feature_requirements#Dismiss>
This 'Dismiss' tool enables users to turn off notifications
categories they don't want to see in the flyout or the
all-notifications page, so they don't have to go to the
preferences page if they don't want to.
If you haven't already, you can test this feature here on MediaWiki:
http://www.mediawiki.org/wiki/Special:Notifications
Krinkle and a couple other folks have raised concerns about this
feature here on Bugzilla:
https://bugzilla.wikimedia.org/show_bug.cgi?id=46587
What do you think? Is this feature useful to you in its current form?
Note that currently it only lets you turn off an entire
notification category (instead of just removing individual
notifications). In that sense, it is similar to Facebook's 'User
Opt-Out' feature, which lets you turn off notifications from an
application or group, as described here:
https://developers.facebook.com/docs/concepts/notifications/
Would you prefer to have the 'X' button simply close that
individual notification? (without the option to turn off all
notifications from that category?)
Or would you prefer this compromise solution which lets you do
both, as proposed earlier by Brandon:
Hover over the notification and there's an "(x)" that appears on
the right side.
Click that and it dismisses the notification but also asks "Do you
want to hide all notifications of this kind?"
[y/n control]
- if "n/cancel", dismiss/hide current element, do nothing else.
- if "y" set "hide this type" preference for the user. show
message about "you can set your preferences [[here]]"
We are debating whether to change the current version of Dismiss
before we deploy to en-wiki, or remove it entirely, or try it out
in its current form to get more community feedback.
Look forward to your recommendations! I have also attached below
earlier email threads on this topic.
All the best,
Fabrice
_____________________________________
On Mar 6, 2013, at 9:25 AM, Fabrice Florin wrote:
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
<mailto:erik@wikimedia.org>> wrote:
On Tue, Mar 5, 2013 at 5:44 PM, Ryan Kaldari
<rkaldari(a)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(a)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(a)wikimedia.org <mailto:mflaschen@wikimedia.org>> wrote:
I agree. Not just, "dismiss this one", but "Don't show this type
of
notification again" right on the notification itself (not necessarily
those phrasings).
Hover over the notification and there's an "(x)" that appears on
the right side.
Click that and it dismisses the notification but also asks "Do you
want to hide all notifications of this kind?"
[y/n control]
- if "n/cancel", dismiss/hide current element, do nothing else.
- if "y" set "hide this type" preference for the user. show
message about "you can set your preferences [[here]]"
---
Brandon Harris, Senior Designer, Wikimedia Foundation
On Thu, Jan 10, 2013 at 1:33 PM, Fabrice
Florin <fflorin(a)wikimedia.org <mailto:fflorin@wikimedia.org>> wrote:
I agree with Matt and Oliver as well.
I don't think we can avoid giving people individual control of
which notifications they receive.
But I definitely think that adding a dismiss option in the flyout
is an effective way to give people that control, so they don't
have to go to the preferences page if they don't want to.
I also think that bundling can help in a number of ways, as
outlined in my feature list below (I am including the entire
thread, to make sure nobody feels left out from that discussion)
I will create a feature requirement stub for both options (and a
few more) in coming days, and we can prioritize them as a team in
next week's planning session.
But this discussion is touching upon the central challenge for
this product: how to make sure that we inform people without
spamming them.
It will take us a while to completely solve this challenge, but we
should not ship anything that doesn't have some good solutions to
this difficult problem, IMHO.
Cheers,
Fabrice
On Tue, Jan 8, 2013 at 10:35 PM, Erik Moeller <erik(a)wikimedia.org
<mailto:erik@wikimedia.org>> wrote:
On the "easy to disable" front, I'm not sure if this is on the roadmap
already, but having an inline way to dismiss notifications of a
certain type would IMO be nice, e.g. a simple "Disable this type of
alert" link within the actual notification itself.
On 9 January 2013 11:35, Oliver Keyes <okeyes(a)wikimedia.org
<mailto:okeyes@wikimedia.org>> wrote:
On 9 January 2013 06:47, Steven Walling <swalling(a)wikimedia.org
<mailto:swalling@wikimedia.org>> wrote:
Great idea! Giving people an immediate touch point means they feel
like they have control, like swatting a fly.
_______________________________________________
EE mailing list
EE(a)lists.wikimedia.org <mailto:EE@lists.wikimedia.org>
https://lists.wikimedia.org/mailman/listinfo/ee
_______________________________________________
EE mailing list
EE(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/ee