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
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
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
I agree with Howie that these two systems serve a different purposes.
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