On Sat, 15 Sep 2012 06:11:31 -0700, Krinkle <krinklemail(a)gmail.com> wrote:
On Sep 14, 2012, at 3:11 AM, Daniel Friesen
<daniel(a)nadir-seen-fire.com>
wrote:
On Thu, 13 Sep 2012 15:03:04 -0700, Steven
Walling
<steven.walling(a)gmail.com> wrote:
On Wed, Sep 12, 2012 at 11:09 PM, Erik Moeller
<erik(a)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
--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [
http://daniel.friesen.name]