On Sat, Sep 15, 2012 at 6:11 AM, Krinkle <[email protected]> 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
_______________________________________________
Wikitech-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
