Not sure if this is a known issue, but the notification is at the top of the
document regardless of where you are on the page. Meaning if I'm at the bottom
of a long article, I have to scroll up to the top to see the bubble. Should it
not be relative to the scroll position?
I noticed this by firing off a mw.notify('hi james') in the console at the
bottom of a long article. This may have gone unnoticed as it seems mw.notify
is only triggered by UI components at the top of the page.
On Sep 18, 2012, at 5:11 PM, Jon Robson wrote:
> 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
> <[email protected]>wrote:
>
>> 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 <[email protected]>
>> wrote:
>>
>>> 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
>>>
>> _______________________________________________
>> Wikitech-l mailing list
>> [email protected]
>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>>
>
>
>
> --
> Jon Robson
> http://jonrobson.me.uk
> @rakugojon
> _______________________________________________
> Wikitech-l mailing list
> [email protected]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
_______________________________________________
Wikitech-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
