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