I don't think an overlay like this it's an appropriate way to notify a user that someone edited a page they are watching, for instance. If the cost of adding a page to your watch list is that bubbles start popping up while you are trying to do other things, people are likely going to be incentivized not to add pages to their watch list. This unintended consequence is likely just one of many others.

Also, while the video shows a situation where multiple notifications are being shown at one time. I think it's great that this improvement adds support for such things, but we should be very cautious about this ever actually happening. Bubble notifications should only be used as a way to let the user know that the action they just took (probably by clicking something) has actually done something. This is similar to gmail's "message sent. undo" notification at the top center of the screen. One at a time, in immediate response to a user action on that page would be a reasonable target to shoot for.

- Trevor

On Tue, Aug 28, 2012 at 2:06 PM, Howie Fung <hfung@wikimedia.org> wrote:

I think we need to make the distinction between notifications and confirmations (similar to what Steven was saying) and make sure the UI affordances make sense.

Confirmations are in response to what you as a user did. Watchlist and post edit feedback are types of confirmations.
Notifications are in response to what someone else did that involves you.

My personal opinion is that we should use bubble-type for notifications very sparingly and judiciously. For confirmations, they make a lot of sense.

Re: Growl: the user has opted to install the app, giving permission for this type of notification.

Howie

On Tue, Aug 28, 2012 at 1:54 PM, Vibha Bamba <vbamba@wikimedia.org> wrote:

hi Erik,
Its a very slick component useful for quick transient messaging and is close to growlers seen on other sites, especially if we can easily control the temporality (2 seconds, 10 seconds)

I think It works well for Temporal or Flash Notifications when:

-The message is transient
-No deeper engagement is required and for the most part you will not need to retrive it.
-'You need to know' bits such as: You just completed 250 edits | 5 Other people are editing with you | | Feedback Sent | Edit Saved | etc that you dont have to act on.

-Notifications with engagement or new UX features belong in a more persistent device which supports rollup, retrival and archive.

In terms of echo I would classify this as our real time notifications piece but we need to carefully consider what types of real time notifications persist and which dont.

Protection Notices / Site Notices / Descriptor Messages etc.

Visually it could use a stronger foreground treatment and attract a users eye, currently its minimal but blends too much into the background.

my 0.02$

On Tue, Aug 28, 2012 at 1:44 AM, Erik Moeller <erik@wikimedia.org> wrote:
Cross-posting

---------- Forwarded message ----------
From: Erik Moeller <erik@wikimedia.org>
Date: Tue, Aug 28, 2012 at 1:44 AM
Subject: [Echo] Bubble notifications
To: WMF Editor Engagement Team <ee@lists.wikimedia.org>

Echo team & designers,

Trevor recently made some improvements to MediaWiki's UI library for
generating simple on-wiki notification messages, in order to make the
system more useful for the Visual Edtior. This basic change [1] is now
live on en.wp and can be seen when you add a page to your watchlist --
where previously you got a big, centered message, you now get a bubble
notification in the top right corner that disappears after a while,
unless your mouse is over it.

Daniel Friesen, a volunteer, is currently working on improving this
system further into a more general notification message front-end. [2]
This change has not been merged yet. You can find a video of the
system in action here:

https://www.mediawiki.org/wiki/File:Mw-notification.ogv

NB: This is purely a front-end, it doesn't know anything about the
notifications it displays.

Have the implications of this UI approach for Echo been considered
already? Specifically:

- Under what circumstances would a bubble notification be appropriate,
as opposed to the "just increment a number" approach? Right now
they're used for application messages ("You just added this article to
your watchlist"), not for service notifications ("The article Foo on
your watchlist has just been modified by User:Bar").

Different users likely have different preferences here (yay,
preferences), but I can see this type of real-time notification being
potentially very engaging and actually reducing the distraction
factor, compared with an increasing notification counter which forces
you to click on it to see what's going on.

- If we use this style of notification, how would we indicate the
connection between the bubble notification and the list of all
notifications to the user? Would we still increment a number?
Presumably yes, as the user may not be watching her browser tab while
it's displaying the notification. But then we'd have an odd mix of
application messages ("You have performed action X with result Y")
which don't increment the notification counter vs. service messages
which do.

- Is this design appropriate for touch devices (where we can't do the
mouseover detection to halt the timer), and if not, what changes would
make it more useful?

Some food for thought & considerations as we get further into echo,

Erik

[1] https://gerrit.wikimedia.org/r/#/c/17605/
[2] https://gerrit.wikimedia.org/r/#/c/19199/

--
Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation

Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate

--
Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation

Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate

_______________________________________________

Design mailing list
Design@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/design

_______________________________________________
Design mailing list
Design@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/design

_______________________________________________
Design mailing list
Design@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/design