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:

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(a)gmail.com>

On Wed, Sep 12, 2012 at 11:09 PM, Erik Moeller <erik(a)wikimedia.org> wrote: +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 Sep 14, 2012, at 3:11 AM, Daniel Friesen &lt;daniel(a)nadir-seen-fire.com&gt; 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> -- Krinkle

On Sat, Sep 15, 2012 at 6:11 AM, Krinkle &lt;krinklemail(a)gmail.com&gt; 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 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

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 &lt;gerard.meijssen(a)gmail.com&gt;wrote;wrote: -- Jon Robson http://jonrobson.me.uk @rakugojon

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 &lt;erik(a)wikimedia.org&gt; wrote: -- Jon Robson http://jonrobson.me.uk @rakugojon

On Tue, Sep 18, 2012 at 9:28 PM, Jon Robson &lt;jdlrobson(a)gmail.com&gt; wrote: 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 &lt;rmoen(a)wikimedia.org&gt; wrote: +1. This is bothering me as well. Helder

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 &lt;krinklemail(a)gmail.com&gt; wrote:

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 &lt;massaf(a)wikimedia.org&gt; wrote:

On Wed, Sep 19, 2012 at 11:54 AM, Munaf Assaf &lt;massaf(a)wikimedia.org&gt; wrote: 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 Thu, 20 Sep 2012 15:48:27 -0700, Krinkle &lt;krinklemail(a)gmail.com&gt; wrote: 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. -- ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]

On 21/09/2012 11:46, Rob Moen wrote: 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... -- -— Isarra

On Sep 22, 2012, at 9:31 AM, Daniel Friesen &lt;daniel(a)nadir-seen-fire.com&gt; wrote: 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 Sep 18, 2012, at 5:07 PM, Gerard Meijssen &lt;gerard.meijssen(a)gmail.com&gt; wrote: 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

On Sun, 16 Sep 2012 22:44:14 -0700, S Page &lt;spage(a)wikimedia.org&gt; wrote: https://gerrit.wikimedia.org/r/#/c/19199/ Krinkle, Aug 27th -- ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]