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(a)gmail.com> wrote:
On Sat, Sep 15, 2012 at 6:11 AM, Krinkle
<krinklemail(a)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
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l