A little while ago Trevor Parscal changed our jsMessage setup to be a floating auto-hiding notification bubble. https://gerrit.wikimedia.org/r/#/c/17605/
The end implementation felt half-baked to me. Since it just swapped text for notification replacement. And didn't support multiple notifications. It even reused the same id as the previous message which was pretty much a completely different concept.
So I spent a night implementing a fully featured notification bubble system. Something that should work for watchlists, VisualEditor, and perhaps some other things like LQT, and perhaps anything we want to start making more dynamic. Same goes for anyone with a good Gadget idea that could use better notifications.
Here's a demo video of the new notification system: https://www.mediawiki.org/wiki/File:Mw-notification.ogv
The changeset is https://gerrit.wikimedia.org/r/#/c/19199/
I support this change, it's a great next step on the design work I put into https://gerrit.wikimedia.org/**r/#/c/17605/https://gerrit.wikimedia.org/r/#/c/17605/ and seems to be very clever in the way it handles multiple messages.
That said, it's a pretty big change to an area of code that Timo (Krinkle) has been working on a lot, and he's just left on vacation for a week, so I am hesitant to merge it without some more scrutiny.
So, if you feel up to scrutinizing, please do.
- Trevor
On Mon, Aug 13, 2012 at 10:18 AM, Daniel Friesen lists@nadir-seen-fire.comwrote:
A little while ago Trevor Parscal changed our jsMessage setup to be a floating auto-hiding notification bubble. https://gerrit.wikimedia.org/**r/#/c/17605/https://gerrit.wikimedia.org/r/#/c/17605/
The end implementation felt half-baked to me. Since it just swapped text for notification replacement. And didn't support multiple notifications. It even reused the same id as the previous message which was pretty much a completely different concept.
So I spent a night implementing a fully featured notification bubble system. Something that should work for watchlists, VisualEditor, and perhaps some other things like LQT, and perhaps anything we want to start making more dynamic. Same goes for anyone with a good Gadget idea that could use better notifications.
Here's a demo video of the new notification system: https://www.mediawiki.org/**wiki/File:Mw-notification.ogvhttps://www.mediawiki.org/wiki/File:Mw-notification.ogv
The changeset is https://gerrit.wikimedia.org/**r/#/c/19199/https://gerrit.wikimedia.org/r/#/c/19199/
-- ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
______________________________**_________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/**mailman/listinfo/wikitech-lhttps://lists.wikimedia.org/mailman/listinfo/wikitech-l
Daniel Friesen wrote:
Here's a demo video of the new notification system: https://www.mediawiki.org/wiki/File:Mw-notification.ogv
The changeset is https://gerrit.wikimedia.org/r/#/c/19199/
Thank you very much for putting that video together. It was very helpful to understand what you were referring to by "notification bubble." (Reminiscent of Mac OS X's Growl alerts, I think.) And thanks, of course, for submitting the patch set. Hopefully it'll be reviewed and merged in short order. :-)
MZMcBride
This looks like it would work brilliantly for Echo real time notifications. Does it accept arbitrary HTML as a payload?
On Mon, Aug 13, 2012 at 6:18 PM, Daniel Friesen lists@nadir-seen-fire.comwrote:
A little while ago Trevor Parscal changed our jsMessage setup to be a floating auto-hiding notification bubble. https://gerrit.wikimedia.org/**r/#/c/17605/https://gerrit.wikimedia.org/r/#/c/17605/
The end implementation felt half-baked to me. Since it just swapped text for notification replacement. And didn't support multiple notifications. It even reused the same id as the previous message which was pretty much a completely different concept.
So I spent a night implementing a fully featured notification bubble system. Something that should work for watchlists, VisualEditor, and perhaps some other things like LQT, and perhaps anything we want to start making more dynamic. Same goes for anyone with a good Gadget idea that could use better notifications.
Here's a demo video of the new notification system: https://www.mediawiki.org/**wiki/File:Mw-notification.ogvhttps://www.mediawiki.org/wiki/File:Mw-notification.ogv
The changeset is https://gerrit.wikimedia.org/**r/#/c/19199/https://gerrit.wikimedia.org/r/#/c/19199/
-- ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
______________________________**_________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/**mailman/listinfo/wikitech-lhttps://lists.wikimedia.org/mailman/listinfo/wikitech-l
I didn't like jsMessage's behaviour of mw.util.jsMessage( 'Foo' ); treating 'Foo' as html, so any string you pass will be treated as plaintext. But it does accept arbitrary DOM nodes and jQuery objects just like jsMessage did. And as a bonus it will also accept a mw.message instance and automatically call .parse() on it to get the html. If you have a raw html string just use jQuery's $.parseHTML.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
On 12-08-16 3:01 AM, Andrew Garrett wrote:
This looks like it would work brilliantly for Echo real time notifications. Does it accept arbitrary HTML as a payload?
On Mon, Aug 13, 2012 at 6:18 PM, Daniel Friesen <lists@nadir-seen-fire.com mailto:lists@nadir-seen-fire.com> wrote:
A little while ago Trevor Parscal changed our jsMessage setup to be a floating auto-hiding notification bubble. https://gerrit.wikimedia.org/r/#/c/17605/ The end implementation felt half-baked to me. Since it just swapped text for notification replacement. And didn't support multiple notifications. It even reused the same id as the previous message which was pretty much a completely different concept. So I spent a night implementing a fully featured notification bubble system. Something that should work for watchlists, VisualEditor, and perhaps some other things like LQT, and perhaps anything we want to start making more dynamic. Same goes for anyone with a good Gadget idea that could use better notifications. Here's a demo video of the new notification system: https://www.mediawiki.org/wiki/File:Mw-notification.ogv The changeset is https://gerrit.wikimedia.org/r/#/c/19199/ -- ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name] _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org <mailto:Wikitech-l@lists.wikimedia.org> https://lists.wikimedia.org/mailman/listinfo/wikitech-l-- Andrew Garrett Wikimedia Foundation agarrett@wikimedia.org mailto:agarrett@wikimedia.org
Le 13/08/12 19:18, Daniel Friesen a écrit :
So I spent a night implementing a fully featured notification bubble system. Something that should work for watchlists, VisualEditor, and perhaps some other things like LQT, and perhaps anything we want to start making more dynamic. Same goes for anyone with a good Gadget idea that could use better notifications.
Here's a demo video of the new notification system: https://www.mediawiki.org/wiki/File:Mw-notification.ogv
Well done :)
On August 13, Daniel Friesen wrote:
A little while ago Trevor Parscal changed our jsMessage setup to be a floating auto-hiding notification bubble. https://gerrit.wikimedia.org/r/#/c/17605/
That page, created on August 3, reads: "By being designed as a floating bubble instead of a static positioned element in regular document flow it also prevents the page flow from being interrupted and moved down a bit."
What if I spot a spelling error in a notification, can I copy the text and paste it to somebody's talk page? Or will the bubble hide as soon as I try to click on it? The auto-hide might be smooth for experienced computer users, but perhaps not for the elderly people that we try to recruit as new editors. How are they supposed to know that they should hover the mouse over the bubble in order to stop it from disappearing? Maybe it needs a pin symbol that hints at a way to make it stick?
On Tue, Aug 28, 2012 at 10:01 PM, Lars Aronsson lars@aronsson.se wrote:
The auto-hide might be smooth for experienced computer users, but perhaps not for the elderly people that we try to recruit as new editors.
That is one more use case for this: https://bugzilla.wikimedia.org/show_bug.cgi?id=30401
Helder
It looks like "NotifyOSD[1]" and think it will work very well with "echo[2]".
I think an interesting thing would be the ability to position it on the screen through the preferences[3]
[1]https://wiki.ubuntu.com/NotifyOSD [2]https://www.mediawiki.org/wiki/Echo_(Notifications) [3]https://www.mediawiki.org/wiki/Special:Preferences
2012/8/28 Helder . helder.wiki@gmail.com
On Tue, Aug 28, 2012 at 10:01 PM, Lars Aronsson lars@aronsson.se wrote:
The auto-hide might be smooth for experienced computer users, but perhaps not for the elderly people that we try to recruit as new editors.
That is one more use case for this: https://bugzilla.wikimedia.org/show_bug.cgi?id=30401
Helder
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Mon, Aug 13, 2012 at 10:18 AM, Daniel Friesen lists@nadir-seen-fire.com wrote:
So I spent a night implementing a fully featured notification bubble system. Something that should work for watchlists, VisualEditor, and perhaps some other things like LQT, and perhaps anything we want to start making more dynamic. Same goes for anyone with a good Gadget idea that could use better notifications.
Thanks for your work on this, Daniel. As an update, this has now been merged and deployed to all wikis (it's part of 1.20wmf11).
It's easy to play with - in e.g. Chrome, open the dev tools on any Wikipedia page (F12), and then enter on the console:
mw.notify( 'The Wikipedia Signpost app is out!' );
This creates a notification with no parameters/options. Running it repeatedly will stack the notifications.
As a second parameter, you can specify several options:
autoHide: true/false - should the notification time out after 5 seconds - if not, click to hide title: if specified, shown in bold text above the notification itself tag: if specified, a message with the same tag will replace the most recently displayed message with this tag
e.g.
mw.notify( 'The Wikipedia Signpost app is out!', { autoHide: false, title: 'Mobile updates', tag: 'mobile' } );
This example shows a notification that has to be clicked to be hidden, and that's tagged, so any other 'mobile' notifications will replace it.
Is the system documented somewhere already so gadget/script authors can start using it?
Erik
On Wed, Sep 12, 2012 at 11:09 PM, Erik Moeller erik@wikimedia.org wrote:
Is the system documented somewhere already so gadget/script authors can start using it?
+1 to docs for this, please. :)
My other question is similar to what Andrew asked earlier: what potential is there for including something more than just strings?
My team just finished up a test where simple "your edit was saved" confirmation messages lead to a significant bump in the editing activity of newbies on English Wikipedia.[1] The only core differences between the custom notification we built and bubble notifications are that it was center-aligned and that it included a checkmark icon. I would prefer to build on top of this if we're going to try and make an edit confirmation message a part of MediaWiki.
Steven
1. https://meta.wikimedia.org/wiki/Research:Post-edit_feedback
On Thu, 13 Sep 2012 15:03:04 -0700, Steven Walling steven.walling@gmail.com wrote:
On Wed, Sep 12, 2012 at 11:09 PM, Erik Moeller erik@wikimedia.org wrote:
Is the system documented somewhere already so gadget/script authors can start using it?
+1 to docs for this, please. :)
My other question is similar to what Andrew asked earlier: what potential is there for including something more than just strings?
My team just finished up a test where simple "your edit was saved" confirmation messages lead to a significant bump in the editing activity of newbies on English Wikipedia.[1] The only core differences between the custom notification we built and bubble notifications are that it was center-aligned and that it included a checkmark icon. I would prefer to build on top of this if we're going to try and make an edit confirmation message a part of MediaWiki.
mw.notify accepts DOM nodes and jQuery objects. So you can add in whatever html you want by parsing it into dom. mw.notify also accepts mw.Message objects so you can use `mw.notify( mw.message( 'foo' ) );` and it'll be parsed.
Steven
On Sep 14, 2012, at 3:11 AM, Daniel Friesen daniel@nadir-seen-fire.com wrote:
On Thu, 13 Sep 2012 15:03:04 -0700, Steven Walling steven.walling@gmail.com wrote:
On Wed, Sep 12, 2012 at 11:09 PM, Erik Moeller erik@wikimedia.org wrote:
Is the system documented somewhere already so gadget/script authors can start using it?
+1 to docs for this, please. :)
My other question is similar to what Andrew asked earlier: what potential is there for including something more than just strings?
My team just finished up a test where simple "your edit was saved" confirmation messages lead to a significant bump in the editing activity of newbies on English Wikipedia.[1] The only core differences between the custom notification we built and bubble notifications are that it was center-aligned and that it included a checkmark icon. I would prefer to build on top of this if we're going to try and make an edit confirmation message a part of MediaWiki.
mw.notify accepts DOM nodes and jQuery objects. So you can add in whatever html you want by parsing it into dom. mw.notify also accepts mw.Message objects so you can use `mw.notify( mw.message( 'foo' ) );` and it'll be parsed.
... yes, but now that we're on the subject, lets try to aim for standardization here instead of encouraging arbitrary HTML for layout (I'd like to phase that out sooner rather than later). We can allow HTML inside the body (e.g. for hyperlinks which are allowed even in edit summaries), though we could call jQuery .text() on html and disallow HTML completely (while still keeping output clean of html characters). We'll see about that later. One step at a time.
I propose to implement the following content options (in addition to the configuration options we have like "autoHide" and "tag"). Inspired by API for Notification Center as found in OS X and iOS:
* icon (optional) Must be square and transparent. Can potentially be displayed in different sizes. Important here to know that this icon is for source identification, not message type. I think it is good design to keep images out of notifications. No smilies, check marks or the like (unless the icon of a feature contains it).
* title (optional) Title of the message. If too long, will be auto-ellipsis-ified.
* body (required) Spans around up to 3 or 4 lines. If too long, will be auto-ellipsis-ified (in the case of a confirmation it would contain just one or two sentences, in case of a notification of en edit it might show (part of an) edit summary).
* buttons (optional, multi, recommendation is to use 2 buttons, not 1 or 3+ ) Similar to jQuery UI dialog buttons): Label text and callback function. There can be be no two buttons with the same label. When a message has buttons it basically becomes what would be called an "Alert" (has buttons and doesn't autohide) in "Notification Center" lingo (as opposed to "Banner", which autohides and has no buttons). It makes sense to automatically enforce autoHide:false if buttons are set.
Applications / Features that send many notifications might abstract part of this internally, like:
<code> var extPath = mw.config.get( 'wgExtensionAssetsPath' ) + '/Feature'; /** * @param {mw.Title} title * @param {Object} revision Information about revision as given by the API. */ Feature.prototype.editNotif = function( title, revision ) { return mw.notify({ content: {, icon: extPath + '/modules/ext.Feature.foo/images/notify.icon.png', title: title.getPrefixedText(), body: $.parseHTML( revision.parsedcomment ) }, config: { autoHide: true }); }; </code>
-- Krinkle
On Sat, 15 Sep 2012 06:11:31 -0700, Krinkle krinklemail@gmail.com wrote:
On Sep 14, 2012, at 3:11 AM, Daniel Friesen daniel@nadir-seen-fire.com wrote:
On Thu, 13 Sep 2012 15:03:04 -0700, Steven Walling steven.walling@gmail.com wrote:
On Wed, Sep 12, 2012 at 11:09 PM, Erik Moeller erik@wikimedia.org wrote:
Is the system documented somewhere already so gadget/script authors can start using it?
+1 to docs for this, please. :)
My other question is similar to what Andrew asked earlier: what potential is there for including something more than just strings?
My team just finished up a test where simple "your edit was saved" confirmation messages lead to a significant bump in the editing activity of newbies on English Wikipedia.[1] The only core differences between the custom notification we built and bubble notifications are that it was center-aligned and that it included a checkmark icon. I would prefer to build on top of this if we're going to try and make an edit confirmation message a part of MediaWiki.
mw.notify accepts DOM nodes and jQuery objects. So you can add in whatever html you want by parsing it into dom. mw.notify also accepts mw.Message objects so you can use `mw.notify( mw.message( 'foo' ) );` and it'll be parsed.
... yes, but now that we're on the subject, lets try to aim for standardization here instead of encouraging arbitrary HTML for layout (I'd like to phase that out sooner rather than later). We can allow HTML inside the body (e.g. for hyperlinks which are allowed even in edit summaries), though we could call jQuery .text() on html and disallow HTML completely (while still keeping output clean of html characters). We'll see about that later. One step at a time.
I propose to implement the following content options (in addition to the configuration options we have like "autoHide" and "tag"). Inspired by API for Notification Center as found in OS X and iOS:
- icon (optional)
Must be square and transparent. Can potentially be displayed in different sizes. Important here to know that this icon is for source identification, not message type. I think it is good design to keep images out of notifications. No smilies, check marks or the like (unless the icon of a feature contains it).
w3-notifications uses iconUrl, but yeah we could shorten it to icon.
- title (optional)
Title of the message. If too long, will be auto-ellipsis-ified.
Already in the options.
- body (required)
Spans around up to 3 or 4 lines. If too long, will be auto-ellipsis-ified (in the case of a confirmation it would contain just one or two sentences, in case of a notification of en edit it might show (part of an) edit summary).
The body/content of the message is the most important part of the notification. Displaying it is the whole purpose of the notification. Why should it be truncated?
Also we already have the mw.notify(body, options) form, we don't need to go putting body into the options.
- buttons (optional, multi, recommendation is to use 2 buttons, not 1 or
3+ ) Similar to jQuery UI dialog buttons): Label text and callback function. There can be be no two buttons with the same label. When a message has buttons it basically becomes what would be called an "Alert" (has buttons and doesn't autohide) in "Notification Center" lingo (as opposed to "Banner", which autohides and has no buttons). It makes sense to automatically enforce autoHide:false if buttons are set.
Applications / Features that send many notifications might abstract part of this internally, like:
<code> var extPath = mw.config.get( 'wgExtensionAssetsPath' ) + '/Feature'; /** * @param {mw.Title} title * @param {Object} revision Information about revision as given by the API. */ Feature.prototype.editNotif = function( title, revision ) { return mw.notify({ content: {, icon: extPath + '/modules/ext.Feature.foo/images/notify.icon.png', title: title.getPrefixedText(), body: $.parseHTML( revision.parsedcomment ) }, config: { autoHide: true }); }; </code>
-- Krinkle
On Sat, Sep 15, 2012 at 6:11 AM, Krinkle krinklemail@gmail.com wrote:
... yes, but now that we're on the subject, lets try to aim for standardization here instead of encouraging arbitrary HTML for layout (I'd like to phase that out sooner rather than later). We can allow HTML inside the body (e.g. for hyperlinks which are allowed even in edit summaries), though we could call jQuery .text() on html and disallow HTML completely (while still keeping output clean of html characters). We'll see about that later. One step at a time.
I propose to implement the following content options (in addition to the configuration options we have like "autoHide" and "tag"). Inspired by API for Notification Center as found in OS X and iOS:
- icon (optional)
Must be square and transparent. Can potentially be displayed in different sizes. Important here to know that this icon is for source identification, not message type. I think it is good design to keep images out of notifications. No smilies, check marks or the like (unless the icon of a feature contains it).
- title (optional)
Title of the message. If too long, will be auto-ellipsis-ified.
- body (required)
Spans around up to 3 or 4 lines. If too long, will be auto-ellipsis-ified (in the case of a confirmation it would contain just one or two sentences, in case of a notification of en edit it might show (part of an) edit summary).
- buttons (optional, multi, recommendation is to use 2 buttons, not 1 or
3+ ) Similar to jQuery UI dialog buttons): Label text and callback function. There can be be no two buttons with the same label. When a message has buttons it basically becomes what would be called an "Alert" (has buttons and doesn't autohide) in "Notification Center" lingo (as opposed to "Banner", which autohides and has no buttons). It makes sense to automatically enforce autoHide:false if buttons are set.
Applications / Features that send many notifications might abstract part of this internally, like:
<code> var extPath = mw.config.get( 'wgExtensionAssetsPath' ) + '/Feature'; /** * @param {mw.Title} title * @param {Object} revision Information about revision as given by the API. */ Feature.prototype.editNotif = function( title, revision ) { return mw.notify({ content: {, icon: extPath + '/modules/ext.Feature.foo/images/notify.icon.png', title: title.getPrefixedText(), body: $.parseHTML( revision.parsedcomment ) }, config: { autoHide: true }); }; </code>
Following up on what I said previously about wanting to build on top of this, there are some usability enhancements proposed at bug #40307.
On the truncation issue: length is already something of an issue, from my perspective. For example: the default watchlist message, which is 37 words, seems to have been written on the assumption that the notification container would be much wider. I've heard some complaints about it.[1] I'm not sure if truncation is the correct method, but we should do something to keep messages short.
Steven
1. "[10:22:25] Fluffernutter: the javascript "flash" for watchlisting is driving me very slightly nuts - it lasts too long and blocks out text" https://meta.wikimedia.org/wiki/IRC_office_hours/Office_hours_2012-09-08
Hoi, The default watchlist is 37 words ... these words are probably en.wikipedia measurements. To what extend have different scripts and different languages been considered ? Thanks. GerardM
On 18 September 2012 00:09, Steven Walling steven.walling@gmail.com wrote:
On Sat, Sep 15, 2012 at 6:11 AM, Krinkle krinklemail@gmail.com wrote:
... yes, but now that we're on the subject, lets try to aim for standardization here instead of encouraging arbitrary HTML for layout
(I'd
like to phase that out sooner rather than later). We can allow HTML
inside
the body (e.g. for hyperlinks which are allowed even in edit summaries), though we could call jQuery .text() on html and disallow HTML completely (while still keeping output clean of html characters). We'll see about
that
later. One step at a time.
I propose to implement the following content options (in addition to the configuration options we have like "autoHide" and "tag"). Inspired by API for Notification Center as found in OS X and iOS:
- icon (optional)
Must be square and transparent. Can potentially be displayed in different sizes. Important here to know that this icon is for source
identification,
not message type. I think it is good design to keep images out of notifications. No smilies, check marks or the like (unless the icon of a feature contains it).
- title (optional)
Title of the message. If too long, will be auto-ellipsis-ified.
- body (required)
Spans around up to 3 or 4 lines. If too long, will be auto-ellipsis-ified (in the case of a confirmation it would contain just one or two
sentences,
in case of a notification of en edit it might show (part of an) edit summary).
- buttons (optional, multi, recommendation is to use 2 buttons, not 1 or
3+ ) Similar to jQuery UI dialog buttons): Label text and callback function. There can be be no two buttons with the same label. When a message has buttons it basically becomes what would be called an "Alert" (has buttons and doesn't autohide) in "Notification Center" lingo (as opposed to "Banner", which autohides and has no buttons). It makes sense to automatically enforce autoHide:false if buttons are set.
Applications / Features that send many notifications might abstract part of this internally, like:
<code> var extPath = mw.config.get( 'wgExtensionAssetsPath' ) + '/Feature'; /** * @param {mw.Title} title * @param {Object} revision Information about revision as given by the
API.
*/ Feature.prototype.editNotif = function( title, revision ) { return mw.notify({ content: {, icon: extPath + '/modules/ext.Feature.foo/images/notify.icon.png', title: title.getPrefixedText(), body: $.parseHTML( revision.parsedcomment ) }, config: { autoHide: true }); };
</code>
Following up on what I said previously about wanting to build on top of this, there are some usability enhancements proposed at bug #40307.
On the truncation issue: length is already something of an issue, from my perspective. For example: the default watchlist message, which is 37 words, seems to have been written on the assumption that the notification container would be much wider. I've heard some complaints about it.[1] I'm not sure if truncation is the correct method, but we should do something to keep messages short.
Steven
- "[10:22:25] Fluffernutter: the javascript "flash" for watchlisting is
driving me very slightly nuts - it lasts too long and blocks out text" https://meta.wikimedia.org/wiki/IRC_office_hours/Office_hours_2012-09-08 _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
There is a huge usability issue with the current implementation. I just watched an article on commons and got a notification bubble, I then tried to use the down arrow to click global usage and couldn't actually get to the menu.
I don't seem to be able to dismiss the notification.....
On Tue, Sep 18, 2012 at 8:07 AM, Gerard Meijssen gerard.meijssen@gmail.comwrote:
Hoi, The default watchlist is 37 words ... these words are probably en.wikipedia measurements. To what extend have different scripts and different languages been considered ? Thanks. GerardM
On 18 September 2012 00:09, Steven Walling steven.walling@gmail.com wrote:
On Sat, Sep 15, 2012 at 6:11 AM, Krinkle krinklemail@gmail.com wrote:
... yes, but now that we're on the subject, lets try to aim for standardization here instead of encouraging arbitrary HTML for layout
(I'd
like to phase that out sooner rather than later). We can allow HTML
inside
the body (e.g. for hyperlinks which are allowed even in edit
summaries),
though we could call jQuery .text() on html and disallow HTML
completely
(while still keeping output clean of html characters). We'll see about
that
later. One step at a time.
I propose to implement the following content options (in addition to
the
configuration options we have like "autoHide" and "tag"). Inspired by
API
for Notification Center as found in OS X and iOS:
- icon (optional)
Must be square and transparent. Can potentially be displayed in
different
sizes. Important here to know that this icon is for source
identification,
not message type. I think it is good design to keep images out of notifications. No smilies, check marks or the like (unless the icon of
a
feature contains it).
- title (optional)
Title of the message. If too long, will be auto-ellipsis-ified.
- body (required)
Spans around up to 3 or 4 lines. If too long, will be
auto-ellipsis-ified
(in the case of a confirmation it would contain just one or two
sentences,
in case of a notification of en edit it might show (part of an) edit summary).
- buttons (optional, multi, recommendation is to use 2 buttons, not 1
or
3+ ) Similar to jQuery UI dialog buttons): Label text and callback function. There can be be no two buttons with the same label. When a message has buttons it basically becomes what would be called an "Alert" (has
buttons
and doesn't autohide) in "Notification Center" lingo (as opposed to "Banner", which autohides and has no buttons). It makes sense to automatically enforce autoHide:false if buttons are set.
Applications / Features that send many notifications might abstract
part
of this internally, like:
<code> var extPath = mw.config.get( 'wgExtensionAssetsPath' ) + '/Feature'; /** * @param {mw.Title} title * @param {Object} revision Information about revision as given by the
API.
*/ Feature.prototype.editNotif = function( title, revision ) { return mw.notify({ content: {, icon: extPath +
'/modules/ext.Feature.foo/images/notify.icon.png',
title: title.getPrefixedText(), body: $.parseHTML( revision.parsedcomment )}, config: { autoHide: true }); };
</code>
Following up on what I said previously about wanting to build on top of this, there are some usability enhancements proposed at bug #40307.
On the truncation issue: length is already something of an issue, from my perspective. For example: the default watchlist message, which is 37
words,
seems to have been written on the assumption that the notification container would be much wider. I've heard some complaints about it.[1]
I'm
not sure if truncation is the correct method, but we should do something
to
keep messages short.
Steven
- "[10:22:25] Fluffernutter: the javascript "flash" for watchlisting is
driving me very slightly nuts - it lasts too long and blocks out text" https://meta.wikimedia.org/wiki/IRC_office_hours/Office_hours_2012-09-08 _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Tue, Sep 18, 2012 at 5:11 PM, Jon Robson jdlrobson@gmail.com wrote:
There is a huge usability issue with the current implementation. I just watched an article on commons and got a notification bubble, I then tried to use the down arrow to click global usage and couldn't actually get to the menu.
The notifications time out after a few seconds, but the timeout doesn't trigger if you're mousing over them (so you're not accidentally losing a notification just as you're about to click in a link on it or whatever). Perhaps mousing over the down arrow could automatically dismiss any open notifications.
On Commons it seems to take 5 seconds to disappear which is too long as at this point I'm wondering how to dismiss it. A good ui pattern would be for it to fade out over those 5 seconds to show me what is happening and when I hover over it go back to no transparency to signal that it will fade automatically and I need to move my mouse over it to stop this.
FWIW I think clicking anywhere outside the box should make it disappear.
On Tue, Sep 18, 2012 at 5:14 PM, Erik Moeller erik@wikimedia.org wrote:
On Tue, Sep 18, 2012 at 5:11 PM, Jon Robson jdlrobson@gmail.com wrote:
There is a huge usability issue with the current implementation. I just watched an article on commons and got a notification bubble, I
then
tried to use the down arrow to click global usage and couldn't actually
get
to the menu.
The notifications time out after a few seconds, but the timeout doesn't trigger if you're mousing over them (so you're not accidentally losing a notification just as you're about to click in a link on it or whatever). Perhaps mousing over the down arrow could automatically dismiss any open notifications.
-- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation
Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Not sure if this is a known issue, but the notification is at the top of the document regardless of where you are on the page. Meaning if I'm at the bottom of a long article, I have to scroll up to the top to see the bubble. Should it not be relative to the scroll position?
I noticed this by firing off a mw.notify('hi james') in the console at the bottom of a long article. This may have gone unnoticed as it seems mw.notify is only triggered by UI components at the top of the page.
On Sep 18, 2012, at 5:11 PM, Jon Robson wrote:
There is a huge usability issue with the current implementation. I just watched an article on commons and got a notification bubble, I then tried to use the down arrow to click global usage and couldn't actually get to the menu.
I don't seem to be able to dismiss the notification.....
On Tue, Sep 18, 2012 at 8:07 AM, Gerard Meijssen gerard.meijssen@gmail.comwrote:
Hoi, The default watchlist is 37 words ... these words are probably en.wikipedia measurements. To what extend have different scripts and different languages been considered ? Thanks. GerardM
On 18 September 2012 00:09, Steven Walling steven.walling@gmail.com wrote:
On Sat, Sep 15, 2012 at 6:11 AM, Krinkle krinklemail@gmail.com wrote:
... yes, but now that we're on the subject, lets try to aim for standardization here instead of encouraging arbitrary HTML for layout
(I'd
like to phase that out sooner rather than later). We can allow HTML
inside
the body (e.g. for hyperlinks which are allowed even in edit
summaries),
though we could call jQuery .text() on html and disallow HTML
completely
(while still keeping output clean of html characters). We'll see about
that
later. One step at a time.
I propose to implement the following content options (in addition to
the
configuration options we have like "autoHide" and "tag"). Inspired by
API
for Notification Center as found in OS X and iOS:
- icon (optional)
Must be square and transparent. Can potentially be displayed in
different
sizes. Important here to know that this icon is for source
identification,
not message type. I think it is good design to keep images out of notifications. No smilies, check marks or the like (unless the icon of
a
feature contains it).
- title (optional)
Title of the message. If too long, will be auto-ellipsis-ified.
- body (required)
Spans around up to 3 or 4 lines. If too long, will be
auto-ellipsis-ified
(in the case of a confirmation it would contain just one or two
sentences,
in case of a notification of en edit it might show (part of an) edit summary).
- buttons (optional, multi, recommendation is to use 2 buttons, not 1
or
3+ ) Similar to jQuery UI dialog buttons): Label text and callback function. There can be be no two buttons with the same label. When a message has buttons it basically becomes what would be called an "Alert" (has
buttons
and doesn't autohide) in "Notification Center" lingo (as opposed to "Banner", which autohides and has no buttons). It makes sense to automatically enforce autoHide:false if buttons are set.
Applications / Features that send many notifications might abstract
part
of this internally, like:
<code> var extPath = mw.config.get( 'wgExtensionAssetsPath' ) + '/Feature'; /** * @param {mw.Title} title * @param {Object} revision Information about revision as given by the
API.
*/ Feature.prototype.editNotif = function( title, revision ) { return mw.notify({ content: {, icon: extPath +
'/modules/ext.Feature.foo/images/notify.icon.png',
title: title.getPrefixedText(), body: $.parseHTML( revision.parsedcomment )}, config: { autoHide: true }); };
</code>
Following up on what I said previously about wanting to build on top of this, there are some usability enhancements proposed at bug #40307.
On the truncation issue: length is already something of an issue, from my perspective. For example: the default watchlist message, which is 37
words,
seems to have been written on the assumption that the notification container would be much wider. I've heard some complaints about it.[1]
I'm
not sure if truncation is the correct method, but we should do something
to
keep messages short.
Steven
- "[10:22:25] Fluffernutter: the javascript "flash" for watchlisting is
driving me very slightly nuts - it lasts too long and blocks out text" https://meta.wikimedia.org/wiki/IRC_office_hours/Office_hours_2012-09-08 _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
-- Jon Robson http://jonrobson.me.uk @rakugojon _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Tue, Sep 18, 2012 at 9:28 PM, Jon Robson jdlrobson@gmail.com wrote:
On Commons it seems to take 5 seconds to disappear which is too long as at this point I'm wondering how to dismiss it.
I think the time should depend on the length of the message. The watchlist notification in Portuguese has ~46 words, and if I didn't know what it was saying, that information would be lost. Maybe it should allow us to see previous notifications by clicking somewhere.
On Tue, Sep 18, 2012 at 9:28 PM, Rob Moen rmoen@wikimedia.org wrote:
Not sure if this is a known issue, but the notification is at the top of the document regardless of where you are on the page. Meaning if I'm at the bottom of a long article, I have to scroll up to the top to see the bubble. Should it not be relative to the scroll position?
I noticed this by firing off a mw.notify('hi james') in the console at the bottom of a long article. This may have gone unnoticed as it seems mw.notify is only triggered by UI components at the top of the page.
+1. This is bothering me as well.
Helder
On Sep 19, 2012, at 2:57 AM, "Helder ." helder.wiki@gmail.com wrote:
On Tue, Sep 18, 2012 at 9:28 PM, Jon Robson jdlrobson@gmail.com wrote:
On Commons it seems to take 5 seconds to disappear which is too long as at this point I'm wondering how to dismiss it.
I think the time should depend on the length of the message. The watchlist notification in Portuguese has ~46 words, and if I didn't know what it was saying, that information would be lost. Maybe it should allow us to see previous notifications by clicking somewhere.
On Tue, Sep 18, 2012 at 9:28 PM, Rob Moen rmoen@wikimedia.org wrote:
Not sure if this is a known issue, but the notification is at the top of the document regardless of where you are on the page. Meaning if I'm at the bottom of a long article, I have to scroll up to the top to see the bubble. Should it not be relative to the scroll position?
I noticed this by firing off a mw.notify('hi james') in the console at the bottom of a long article. This may have gone unnoticed as it seems mw.notify is only triggered by UI components at the top of the page.
+1. This is bothering me as well.
Helder
I agree.
Just for the record though, lets not forget what it was just weeks ago:
* Only one message at a time, new one wiped previous one from existence unconditionally * No way to close it * Took up full width * At the top of the page (still) * Bumped down the article by the height of the message
So we are making some progress here.
Suggestions I saw so far in this thread: * Notification queue should follow scroll position (fixed position) * Add close button (even when they close regardless of click target, as visual clue) * Extend base framework for universal layout of messages. We already have title/body, to be extended with icon and buttons.
One potential problem with making them appear mid-page (fixed queue) is when the bottom of the page is reached. It should then start a new column to the left. Other wise it will continue down the page where it can't be seen due the queue following the scroll position.
Another thing I don't like is how they move up in the queue one after another. What I like about Growl and Notification Center is that messages stay fixed where they first appear. And new messages are added to the bottom (or next column), or, when the first position is available again, it will re-use those positions again.
That way users don't have to re-focus constantly and follow where which message went when dismissing some of them. This gets more important as we start to introduce notifications that do user interactions (sticky ones, which should not move but be sticky).
However that brings another problem: Resizing the window. The spreading of messages over multiple columns would have to either be re-build after resizing the window.
-- Krinkle
I'm glad this area is getting a lot of interest - unfortunately I haven't been able to keep up on this thread but I wanted to give a suggestion related to adding icons.
It's reasonable to take an option that provides a URL to an icon image, but we should have a common (customizable per skin and language) set of icons that can be used by symbolic name, like "success", "failure", "information", "error", etc.
This helps in a few ways:
- We can make sure they match the skin they are being used in - We can internationalize them - We can avoid having multiple icons for the same purpose - It makes it easier to use the icon feature
- Trevor
On Wed, Sep 19, 2012 at 9:56 AM, Krinkle krinklemail@gmail.com wrote:
On Sep 19, 2012, at 2:57 AM, "Helder ." helder.wiki@gmail.com wrote:
On Tue, Sep 18, 2012 at 9:28 PM, Jon Robson jdlrobson@gmail.com wrote:
On Commons it seems to take 5 seconds to disappear which is too long as
at
this point I'm wondering how to dismiss it.
I think the time should depend on the length of the message. The watchlist notification in Portuguese has ~46 words, and if I didn't know what it was saying, that information would be lost. Maybe it should allow us to see previous notifications by clicking
somewhere.
On Tue, Sep 18, 2012 at 9:28 PM, Rob Moen rmoen@wikimedia.org wrote:
Not sure if this is a known issue, but the notification is at the top
of the document regardless of where you are on the page. Meaning if I'm at the bottom of a long article, I have to scroll up to the top to see the bubble. Should it not be relative to the scroll position?
I noticed this by firing off a mw.notify('hi james') in the console at
the bottom of a long article. This may have gone unnoticed as it seems mw.notify is only triggered by UI components at the top of the page.
+1. This is bothering me as well.
Helder
I agree.
Just for the record though, lets not forget what it was just weeks ago:
- Only one message at a time, new one wiped previous one from existence
unconditionally
- No way to close it
- Took up full width
- At the top of the page (still)
- Bumped down the article by the height of the message
So we are making some progress here.
Suggestions I saw so far in this thread:
- Notification queue should follow scroll position (fixed position)
- Add close button (even when they close regardless of click target, as
visual clue)
- Extend base framework for universal layout of messages. We already have
title/body, to be extended with icon and buttons.
One potential problem with making them appear mid-page (fixed queue) is when the bottom of the page is reached. It should then start a new column to the left. Other wise it will continue down the page where it can't be seen due the queue following the scroll position.
Another thing I don't like is how they move up in the queue one after another. What I like about Growl and Notification Center is that messages stay fixed where they first appear. And new messages are added to the bottom (or next column), or, when the first position is available again, it will re-use those positions again.
That way users don't have to re-focus constantly and follow where which message went when dismissing some of them. This gets more important as we start to introduce notifications that do user interactions (sticky ones, which should not move but be sticky).
However that brings another problem: Resizing the window. The spreading of messages over multiple columns would have to either be re-build after resizing the window.
-- Krinkle
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Already in progress.
http://www.mediawiki.org/wiki/Wikimedia_Foundation_Design/Agora_Icon_Set
They'll eventually be in the Agora library as sprites.
Maybe I was unclear.
I'm not suggesting we make these icons so much as we make the notification system use them by name.
As in:
mw.notify( { // This is bad 'icon': ' http://upload.wikimedia.org/wikipedia/commons/4/32/check-icon.svg' /* other options here */ } );
vs.
mw.notify( { // This is good 'icon': 'check' /* other options here */ } );
- Trevor
On Wed, Sep 19, 2012 at 11:46 AM, Munaf Assaf massaf@wikimedia.org wrote:
Already in progress.
http://www.mediawiki.org/wiki/Wikimedia_Foundation_Design/Agora_Icon_Set
They'll eventually be in the Agora library as sprites.
-- Munaf Assaf
On Wednesday, September 19, 2012 at 11:41 AM, Trevor Parscal wrote:
I'm glad this area is getting a lot of interest - unfortunately I haven't been able to keep up on this thread but I wanted to give a suggestion related to adding icons.
It's reasonable to take an option that provides a URL to an icon image,
but
we should have a common (customizable per skin and language) set of icons that can be used by symbolic name, like "success", "failure", "information", "error", etc.
This helps in a few ways:
We can make sure they match the skin they are being used in
We can internationalize them
We can avoid having multiple icons for the same purpose
It makes it easier to use the icon feature
Trevor
On Wed, Sep 19, 2012 at 9:56 AM, Krinkle <krinklemail@gmail.com (mailto:
krinklemail@gmail.com)> wrote:
On Sep 19, 2012, at 2:57 AM, "Helder ." <helder.wiki@gmail.com(mailto:
helder.wiki@gmail.com)> wrote:
On Tue, Sep 18, 2012 at 9:28 PM, Jon Robson <jdlrobson@gmail.com(mailto:
jdlrobson@gmail.com)> wrote:
On Commons it seems to take 5 seconds to disappear which is too
long as
at
this point I'm wondering how to dismiss it.
I think the time should depend on the length of the message. The watchlist notification in Portuguese has ~46 words, and if I didn't know what it was saying, that information would be
lost.
Maybe it should allow us to see previous notifications by clicking
somewhere.
On Tue, Sep 18, 2012 at 9:28 PM, Rob Moen <rmoen@wikimedia.org(mailto:
rmoen@wikimedia.org)> wrote:
Not sure if this is a known issue, but the notification is at the
top
of the document regardless of where you are on the page. Meaning if
I'm at
the bottom of a long article, I have to scroll up to the top to see the bubble. Should it not be relative to the scroll position?
I noticed this by firing off a mw.notify('hi james') in the
console at
the bottom of a long article. This may have gone unnoticed as it seems mw.notify is only triggered by UI components at the top of the page.
+1. This is bothering me as well.
Helder
I agree.
Just for the record though, lets not forget what it was just weeks ago:
- Only one message at a time, new one wiped previous one from existence
unconditionally
- No way to close it
- Took up full width
- At the top of the page (still)
- Bumped down the article by the height of the message
So we are making some progress here.
Suggestions I saw so far in this thread:
- Notification queue should follow scroll position (fixed position)
- Add close button (even when they close regardless of click target, as
visual clue)
- Extend base framework for universal layout of messages. We already
have
title/body, to be extended with icon and buttons.
One potential problem with making them appear mid-page (fixed queue) is when the bottom of the page is reached. It should then start a new column to the left. Other wise it will continue down the page where it can't be seen due
the
queue following the scroll position.
Another thing I don't like is how they move up in the queue one after another. What I like about Growl and Notification Center is that messages stay
fixed
where they first appear. And new messages are added to the bottom (or
next
column), or, when the first position is available again, it will re-use those positions again.
That way users don't have to re-focus constantly and follow where which message went when dismissing some of them. This gets more important as we
start to
introduce notifications that do user interactions (sticky ones, which should not move but be sticky).
However that brings another problem: Resizing the window. The
spreading of
messages over multiple columns would have to either be re-build after resizing the window.
-- Krinkle
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org (mailto:Wikitech-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org (mailto:Wikitech-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
I wasn't clear; that's exactly what we're doing in the Agora CSS library.
On Wed, Sep 19, 2012 at 11:54 AM, Munaf Assaf massaf@wikimedia.org wrote:
I wasn't clear; that's exactly what we're doing in the Agora CSS library.
You are adding an icon feature to me.notify in the Agora CSS library?
I know the answer is "no, we are creating icons that can be used for that and other purposes", and that's great, it's just not what I'm suggesting (though it it related and important).
- Trevor
On Sep 19, 2012, at 8:41 PM, Trevor Parscal tparscal@wikimedia.org wrote:
I'm glad this area is getting a lot of interest - unfortunately I haven't been able to keep up on this thread but I wanted to give a suggestion related to adding icons.
It's reasonable to take an option that provides a URL to an icon image, but we should have a common (customizable per skin and language) set of icons that can be used by symbolic name, like "success", "failure", "information", "error", etc.
This helps in a few ways:
We can make sure they match the skin they are being used in
We can internationalize them
We can avoid having multiple icons for the same purpose
It makes it easier to use the icon feature
Trevor
Interesting idea. Though I must say I was (so far) thinking quite the opposite. I like your idea as well.
I was thinking not to use icons for the "type" of message. For one because it would have to be very well controlled to allow for adaption to skin, language and avoid duplication (though your proposal seems to handle that quite well). But also because: * it is hard to categorize a message in such a specific category * if possible, avoiding icons is a good thing in my opinion. Icons are nice, but sometimes a simple message suffices. But having some messages with and others without an icon doesn't seem nice either as it would break the grid and user expectation. Would we have a default icon? * it means we can't have an icon for source, only for type (because I believe having 2 icons is not an option)
I think source is more important than type. Where (groups of) modules in an extension, gadgets or core are "sources". Examples of sources that could be identified by their own icon:
Watchlist: * Added X to your watchlist. * An error occurred while removing X from your watchlist. * John edited X \ (snippet from edit summary)
Discussion: * John sent you a personal message. # edit on user talk page.. * John started a discussion on <subject>. * John commented on <thread name>.
Countervandalism Network gadgets: * Blacklisted Jack renamed X to Y. \ (log message) * John edited monitored page X. (edit summary)
As for messages confirming a user's own page and user actions, I've been thinking a bit lately. Maybe a notification bubble is not the right way to communicate confirmations of user's direct own actions. Here's a brief list of such messages (similar to the kind of messages one would see in the yellow bar of Google products like Gmail and Gerrit).
* Loading edit screen... * The conversation has been archived. [learn more] [undo] * Edit saved! * The page has been renamed. [undo]
It feels to me like these kind of messages would only be appropiate to appear through a notification bubble if they happened externally. Or if it was like a scheduled event, (so the messages lets the user know that the scheduled action took place and that it succeeded (or failed)). If they happened as a direct consequence of a user action, maybe it should appear inside the interface where it was performed?
Anyway, just my 2 cents :)
-- Krinkle
On Thu, 20 Sep 2012 15:48:27 -0700, Krinkle krinklemail@gmail.com wrote:
On Sep 19, 2012, at 8:41 PM, Trevor Parscal tparscal@wikimedia.org wrote:
I'm glad this area is getting a lot of interest - unfortunately I haven't been able to keep up on this thread but I wanted to give a suggestion related to adding icons.
It's reasonable to take an option that provides a URL to an icon image, but we should have a common (customizable per skin and language) set of icons that can be used by symbolic name, like "success", "failure", "information", "error", etc.
This helps in a few ways:
We can make sure they match the skin they are being used in
We can internationalize them
We can avoid having multiple icons for the same purpose
It makes it easier to use the icon feature
Trevor
Interesting idea. Though I must say I was (so far) thinking quite the opposite. I like your idea as well.
I was thinking not to use icons for the "type" of message. For one because it would have to be very well controlled to allow for adaption to skin, language and avoid duplication (though your proposal seems to handle that quite well). But also because:
- it is hard to categorize a message in such a specific category
- if possible, avoiding icons is a good thing in my opinion. Icons are
nice, but sometimes a simple message suffices. But having some messages with and others without an icon doesn't seem nice either as it would break the grid and user expectation. Would we have a default icon?
- it means we can't have an icon for source, only for type (because I
believe having 2 icons is not an option)
I think source is more important than type. Where (groups of) modules in an extension, gadgets or core are "sources". Examples of sources that could be identified by their own icon:
Watchlist:
- Added X to your watchlist.
- An error occurred while removing X from your watchlist.
- John edited X \ (snippet from edit summary)
Discussion:
- John sent you a personal message. # edit on user talk page..
- John started a discussion on <subject>.
- John commented on <thread name>.
Countervandalism Network gadgets:
- Blacklisted Jack renamed X to Y. \ (log message)
- John edited monitored page X. (edit summary)
As for messages confirming a user's own page and user actions, I've been thinking a bit lately. Maybe a notification bubble is not the right way to communicate confirmations of user's direct own actions. Here's a brief list of such messages (similar to the kind of messages one would see in the yellow bar of Google products like Gmail and Gerrit).
- Loading edit screen...
- The conversation has been archived. [learn more] [undo]
- Edit saved!
- The page has been renamed. [undo]
It feels to me like these kind of messages would only be appropiate to appear through a notification bubble if they happened externally. Or if it was like a scheduled event, (so the messages lets the user know that the scheduled action took place and that it succeeded (or failed)). If they happened as a direct consequence of a user action, maybe it should appear inside the interface where it was performed?
Those notifications on Google make sense because the saving is done dynamically and the user remains on the page itself with no other way to know that their action was completed. Naturally they don't make sense in most of our cases because we aren't using ajax, you end up getting sent to the result/another page, etc... But say if we start offering a "Safe draft" button and instead of sending the user to another page we save that draft dynamically and leave the user on the same page to continue writing the draft. Then a "Your draft has been saved." notification will make sense.
Anyway, just my 2 cents :)
-- Krinkle
On Sep 20, 2012, at 3:48 PM, Krinkle wrote:
If they happened as a direct consequence of a user action, maybe it should appear inside the interface where it was performed?
Agreed, interaction related notifications should be localized in the interface where the action is be performed. This increases visibility and implies a connection to the user action.
On 21/09/2012 11:46, Rob Moen wrote:
On Sep 20, 2012, at 3:48 PM, Krinkle wrote:
If they happened as a direct consequence of a user action, maybe it should appear inside the interface where it was performed?
Agreed, interaction related notifications should be localized in the interface where the action is be performed. This increases visibility and implies a connection to the user action. _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Aye, and while putting notices in the things themselves would only be feasible with some, still tying the other notices to the relevant part of the page would probably help. Like if when clicking the star to watch something, the bubble appeared pointing to the watchlist, that would make the connection between the star and the list itself better than any block of text explaining it ever could...
On Sat, 22 Sep 2012 00:10:11 -0700, Isarra Yos zhorishna@gmail.com wrote:
On 21/09/2012 11:46, Rob Moen wrote:
On Sep 20, 2012, at 3:48 PM, Krinkle wrote:
If they happened as a direct consequence of a user action, maybe it should appear inside the interface where it was performed?
Agreed, interaction related notifications should be localized in the interface where the action is be performed. This increases visibility and implies a connection to the user action.
Aye, and while putting notices in the things themselves would only be feasible with some, still tying the other notices to the relevant part of the page would probably help. Like if when clicking the star to watch something, the bubble appeared pointing to the watchlist, that would make the connection between the star and the list itself better than any block of text explaining it ever could...
https://upload.wikimedia.org/wikipedia/mediawiki/7/7b/Contextual-Notificatio...
Hmmm... that's actually a pretty nice idea. Though we'll need a separate system for that.
On Sep 22, 2012, at 9:31 AM, Daniel Friesen daniel@nadir-seen-fire.com wrote:
On Sat, 22 Sep 2012 00:10:11 -0700, Isarra Yos zhorishna@gmail.com wrote:
On 21/09/2012 11:46, Rob Moen wrote:
On Sep 20, 2012, at 3:48 PM, Krinkle wrote:
If they happened as a direct consequence of a user action, maybe it should appear inside the interface where it was performed?
Agreed, interaction related notifications should be localized in the interface where the action is be performed. This increases visibility and implies a connection to the user action.
Aye, and while putting notices in the things themselves would only be feasible with some, still tying the other notices to the relevant part of the page would probably help. Like if when clicking the star to watch something, the bubble appeared pointing to the watchlist, that would make the connection between the star and the list itself better than any block of text explaining it ever could...
https://upload.wikimedia.org/wikipedia/mediawiki/7/7b/Contextual-Notificatio...
Hmmm... that's actually a pretty nice idea. Though we'll need a separate system for that.
Indeed.
By the way, arguably, in the case of watchlist manipulation it would be pointing to the watchlist (-link) itself, not the watch star.
Similar to how "Install" in the Mac App Store triggers an animation that drops an icon into the Dock. Even if the Dock itself isn't visible, it shows in which general direction it "went".
-- Krinkle
On Tue, Sep 18, 2012 at 5:28 PM, Rob Moen rmoen@wikimedia.org wrote:
Not sure if this is a known issue, but the notification is at the top of the document regardless of where you are on the page. Meaning if I'm at the bottom of a long article, I have to scroll up to the top to see the bubble. Should it not be relative to the scroll position?
I noticed this by firing off a mw.notify('hi james') in the console at the bottom of a long article. This may have gone unnoticed as it seems mw.notify is only triggered by UI components at the top of the page.
I think we need to add this to the bug ( https://bugzilla.wikimedia.org/show_bug.cgi?id=40307) but it's definitely in the requirements from our post-edit notification listed on MediaWiki dot org.
It's necessary to have the 'bubble' follow you if we ever want to give a notification to someone after they edit a section and are returned via an anchor link, as an example.
Steven
On Sep 18, 2012, at 5:07 PM, Gerard Meijssen gerard.meijssen@gmail.com wrote:
On 18 September 2012 00:09, Steven Walling steven.walling@gmail.com wrote:
Following up on what I said previously about wanting to build on top of this, there are some usability enhancements proposed at bug #40307.
On the truncation issue: length is already something of an issue, from my perspective. For example: the default watchlist message, which is 37 words, seems to have been written on the assumption that the notification container would be much wider. I've heard some complaints about it.[1] I'm not sure if truncation is the correct method, but we should do something to keep messages short.
Steven
- "[10:22:25] Fluffernutter: the javascript "flash" for watchlisting is
driving me very slightly nuts - it lasts too long and blocks out text" https://meta.wikimedia.org/wiki/IRC_office_hours/Office_hours_2012-09-08 _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Hoi, The default watchlist is 37 words ... these words are probably en.wikipedia measurements. To what extend have different scripts and different languages been considered ? Thanks. GerardM
Doesn't matter in this case. The point is that the message is oversized. It contains too much redundant information for a simple confirmation that the page was added to the watchlist.
Considering that this message is not wiki-content, it doesn't make sense to truncate it. It simply needs to be shortened at the source. The interface messages in question are (from ApiWatch.php):
* addedwatchtext [1] * removedwatchtext [2]
"removedwatchtext" is short and to the point.
-- Krinkle
[1] https://www.mediawiki.org/wiki/MediaWiki:addedwatchtext/en [2] https://www.mediawiki.org/wiki/MediaWiki:removedwatchtext/en
Great stuff.
I think it should be in mw.util , alongside mw.util.jsMessage() , which I assume it obsoletes.
Is the system documented somewhere already so gadget/script authors can
start using it?
I don't see anything yet in https://www.mediawiki.org/wiki/ResourceLoader/Default_modules
On Sun, 16 Sep 2012 22:44:14 -0700, S Page spage@wikimedia.org wrote:
Great stuff.
I think it should be in mw.util , alongside mw.util.jsMessage() , which I assume it obsoletes.
https://gerrit.wikimedia.org/r/#/c/19199/
Krinkle, Aug 27th
Is the system documented somewhere already so gadget/script authors can
start using it?
I don't see anything yet in https://www.mediawiki.org/wiki/ResourceLoader/Default_modules
wikitech-l@lists.wikimedia.org