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 gerard.meijssen@gmail.comwrote:
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
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l