Mailing List Archive

Notification bubble system
A little while ago Trevor Parscal changed our jsMessage setup to be a
floating auto-hiding notification bubble.
https://gerrit.wikimedia.org/r/#/c/17605/

The end implementation felt half-baked to me. Since it just swapped text
for notification replacement. And didn't support multiple notifications.
It even reused the same id as the previous message which was pretty much a
completely different concept.

So I spent a night implementing a fully featured notification bubble
system. Something that should work for watchlists, VisualEditor, and
perhaps some other things like LQT, and perhaps anything we want to start
making more dynamic. Same goes for anyone with a good Gadget idea that
could use better notifications.

Here's a demo video of the new notification system:
https://www.mediawiki.org/wiki/File:Mw-notification.ogv


The changeset is https://gerrit.wikimedia.org/r/#/c/19199/

--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Notification bubble system [ In reply to ]
I support this change, it's a great next step on the design work I put into
https://gerrit.wikimedia.org/**r/#/c/17605/<https://gerrit.wikimedia.org/r/#/c/17605/>
and
seems to be very clever in the way it handles multiple messages.

That said, it's a pretty big change to an area of code that Timo (Krinkle)
has been working on a lot, and he's just left on vacation for a week, so I
am hesitant to merge it without some more scrutiny.

So, if you feel up to scrutinizing, please do.

- Trevor

On Mon, Aug 13, 2012 at 10:18 AM, Daniel Friesen
<lists@nadir-seen-fire.com>wrote:

> A little while ago Trevor Parscal changed our jsMessage setup to be a
> floating auto-hiding notification bubble.
> https://gerrit.wikimedia.org/**r/#/c/17605/<https://gerrit.wikimedia.org/r/#/c/17605/>
>
> The end implementation felt half-baked to me. Since it just swapped text
> for notification replacement. And didn't support multiple notifications. It
> even reused the same id as the previous message which was pretty much a
> completely different concept.
>
> So I spent a night implementing a fully featured notification bubble
> system. Something that should work for watchlists, VisualEditor, and
> perhaps some other things like LQT, and perhaps anything we want to start
> making more dynamic. Same goes for anyone with a good Gadget idea that
> could use better notifications.
>
> Here's a demo video of the new notification system:
> https://www.mediawiki.org/**wiki/File:Mw-notification.ogv<https://www.mediawiki.org/wiki/File:Mw-notification.ogv>
>
>
> The changeset is https://gerrit.wikimedia.org/**r/#/c/19199/<https://gerrit.wikimedia.org/r/#/c/19199/>
>
> --
> ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
>
> ______________________________**_________________
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/**mailman/listinfo/wikitech-l<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
Re: Notification bubble system [ In reply to ]
Daniel Friesen wrote:
> Here's a demo video of the new notification system:
> https://www.mediawiki.org/wiki/File:Mw-notification.ogv
>
> The changeset is https://gerrit.wikimedia.org/r/#/c/19199/

Thank you very much for putting that video together. It was very helpful to
understand what you were referring to by "notification bubble." (Reminiscent
of Mac OS X's Growl alerts, I think.) And thanks, of course, for submitting
the patch set. Hopefully it'll be reviewed and merged in short order. :-)

MZMcBride



_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Notification bubble system [ In reply to ]
This looks like it would work brilliantly for Echo real time notifications.
Does it accept arbitrary HTML as a payload?

On Mon, Aug 13, 2012 at 6:18 PM, Daniel Friesen
<lists@nadir-seen-fire.com>wrote:

> A little while ago Trevor Parscal changed our jsMessage setup to be a
> floating auto-hiding notification bubble.
> https://gerrit.wikimedia.org/**r/#/c/17605/<https://gerrit.wikimedia.org/r/#/c/17605/>
>
> The end implementation felt half-baked to me. Since it just swapped text
> for notification replacement. And didn't support multiple notifications. It
> even reused the same id as the previous message which was pretty much a
> completely different concept.
>
> So I spent a night implementing a fully featured notification bubble
> system. Something that should work for watchlists, VisualEditor, and
> perhaps some other things like LQT, and perhaps anything we want to start
> making more dynamic. Same goes for anyone with a good Gadget idea that
> could use better notifications.
>
> Here's a demo video of the new notification system:
> https://www.mediawiki.org/**wiki/File:Mw-notification.ogv<https://www.mediawiki.org/wiki/File:Mw-notification.ogv>
>
>
> The changeset is https://gerrit.wikimedia.org/**r/#/c/19199/<https://gerrit.wikimedia.org/r/#/c/19199/>
>
> --
> ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
>
> ______________________________**_________________
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/**mailman/listinfo/wikitech-l<https://lists.wikimedia.org/mailman/listinfo/wikitech-l>
>



--
Andrew Garrett
Wikimedia Foundation
agarrett@wikimedia.org
_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Notification bubble system [ In reply to ]
I didn't like jsMessage's behaviour of mw.util.jsMessage( 'Foo' );
treating 'Foo' as html, so any string you pass will be treated as plaintext.
But it does accept arbitrary DOM nodes and jQuery objects just like
jsMessage did. And as a bonus it will also accept a mw.message instance
and automatically call .parse() on it to get the html.
If you have a raw html string just use jQuery's $.parseHTML.

~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]

On 12-08-16 3:01 AM, Andrew Garrett wrote:
> This looks like it would work brilliantly for Echo real time
> notifications. Does it accept arbitrary HTML as a payload?
>
> On Mon, Aug 13, 2012 at 6:18 PM, Daniel Friesen
> <lists@nadir-seen-fire.com <mailto:lists@nadir-seen-fire.com>> wrote:
>
> A little while ago Trevor Parscal changed our jsMessage setup to
> be a floating auto-hiding notification bubble.
> https://gerrit.wikimedia.org/r/#/c/17605/
>
> The end implementation felt half-baked to me. Since it just
> swapped text for notification replacement. And didn't support
> multiple notifications. It even reused the same id as the previous
> message which was pretty much a completely different concept.
>
> So I spent a night implementing a fully featured notification
> bubble system. Something that should work for watchlists,
> VisualEditor, and perhaps some other things like LQT, and perhaps
> anything we want to start making more dynamic. Same goes for
> anyone with a good Gadget idea that could use better notifications.
>
> Here's a demo video of the new notification system:
> https://www.mediawiki.org/wiki/File:Mw-notification.ogv
>
>
> The changeset is https://gerrit.wikimedia.org/r/#/c/19199/
>
> --
> ~Daniel Friesen (Dantman, Nadir-Seen-Fire)
> [http://daniel.friesen.name]
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org <mailto:Wikitech-l@lists.wikimedia.org>
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
>
>
>
> --
> Andrew Garrett
> Wikimedia Foundation
> agarrett@wikimedia.org <mailto:agarrett@wikimedia.org>


_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Notification bubble system [ In reply to ]
Le 13/08/12 19:18, Daniel Friesen a écrit :
>
> So I spent a night implementing a fully featured notification bubble
> system. Something that should work for watchlists, VisualEditor, and
> perhaps some other things like LQT, and perhaps anything we want to
> start making more dynamic. Same goes for anyone with a good Gadget idea
> that could use better notifications.
>
> Here's a demo video of the new notification system:
> https://www.mediawiki.org/wiki/File:Mw-notification.ogv

Well done :)


--
Antoine "hashar" Musso


_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Notification bubble system [ In reply to ]
On August 13, Daniel Friesen wrote:
> A little while ago Trevor Parscal changed our jsMessage setup to be a
> floating auto-hiding notification bubble.
> https://gerrit.wikimedia.org/r/#/c/17605/

That page, created on August 3, reads:
"By being designed as a floating bubble instead of a static positioned
element in regular document flow it also prevents the page flow
from being interrupted and moved down a bit."

What if I spot a spelling error in a notification, can I copy the text
and paste it to somebody's talk page? Or will the bubble hide as soon
as I try to click on it? The auto-hide might be smooth for experienced
computer users, but perhaps not for the elderly people that we
try to recruit as new editors. How are they supposed to know that they
should hover the mouse over the bubble in order to stop it from
disappearing? Maybe it needs a pin symbol that hints at a way to make
it stick?


--
Lars Aronsson (lars@aronsson.se)
Aronsson Datateknik - http://aronsson.se


_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Notification bubble system [ In reply to ]
On Tue, Aug 28, 2012 at 10:01 PM, Lars Aronsson <lars@aronsson.se> wrote:
> The auto-hide might be smooth for experienced
> computer users, but perhaps not for the elderly people that we
> try to recruit as new editors.
That is one more use case for this:
https://bugzilla.wikimedia.org/show_bug.cgi?id=30401

Helder

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Notification bubble system [ In reply to ]
It looks like "NotifyOSD[1]" and think it will work very well with
"echo[2]".

I think an interesting thing would be the ability to position it on the
screen through the preferences[3]

[1]https://wiki.ubuntu.com/NotifyOSD
[2]https://www.mediawiki.org/wiki/Echo_(Notifications)
[3]https://www.mediawiki.org/wiki/Special:Preferences

2012/8/28 Helder . <helder.wiki@gmail.com>

> On Tue, Aug 28, 2012 at 10:01 PM, Lars Aronsson <lars@aronsson.se> wrote:
> > The auto-hide might be smooth for experienced
> > computer users, but perhaps not for the elderly people that we
> > try to recruit as new editors.
> That is one more use case for this:
> https://bugzilla.wikimedia.org/show_bug.cgi?id=30401
>
> Helder
>
> _______________________________________________
> 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
Re: Notification bubble system [ In reply to ]
On Mon, Aug 13, 2012 at 10:18 AM, Daniel Friesen
<lists@nadir-seen-fire.com> wrote:
> So I spent a night implementing a fully featured notification bubble system.
> Something that should work for watchlists, VisualEditor, and perhaps some
> other things like LQT, and perhaps anything we want to start making more
> dynamic. Same goes for anyone with a good Gadget idea that could use better
> notifications.

Thanks for your work on this, Daniel. As an update, this has now been
merged and deployed to all wikis (it's part of 1.20wmf11).

It's easy to play with - in e.g. Chrome, open the dev tools on any
Wikipedia page (F12), and then enter on the console:

mw.notify( 'The Wikipedia Signpost app is out!' );

This creates a notification with no parameters/options. Running it
repeatedly will stack the notifications.

As a second parameter, you can specify several options:

autoHide: true/false - should the notification time out after 5
seconds - if not, click to hide
title: if specified, shown in bold text above the notification itself
tag: if specified, a message with the same tag will replace the most
recently displayed message with this tag

e.g.

mw.notify( 'The Wikipedia Signpost app is out!', { autoHide: false,
title: 'Mobile updates', tag: 'mobile' } );

This example shows a notification that has to be clicked to be hidden,
and that's tagged, so any other 'mobile' notifications will replace
it.

Is the system documented somewhere already so gadget/script authors
can start using it?

Erik

--
Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation

Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Notification bubble system [ In reply to ]
On Wed, Sep 12, 2012 at 11:09 PM, Erik Moeller <erik@wikimedia.org> wrote:

> Is the system documented somewhere already so gadget/script authors
> can start using it?
>

+1 to docs for this, please. :)

My other question is similar to what Andrew asked earlier: what potential
is there for including something more than just strings?

My team just finished up a test where simple "your edit was saved"
confirmation messages lead to a significant bump in the editing activity of
newbies on English Wikipedia.[1] The only core differences between the
custom notification we built and bubble notifications are that it was
center-aligned and that it included a checkmark icon. I would prefer to
build on top of this if we're going to try and make an edit confirmation
message a part of MediaWiki.

Steven

1. https://meta.wikimedia.org/wiki/Research:Post-edit_feedback
_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Notification bubble system [ In reply to ]
On Thu, 13 Sep 2012 15:03:04 -0700, Steven Walling
<steven.walling@gmail.com> wrote:

> On Wed, Sep 12, 2012 at 11:09 PM, Erik Moeller <erik@wikimedia.org>
> wrote:
>
>> Is the system documented somewhere already so gadget/script authors
>> can start using it?
>>
>
> +1 to docs for this, please. :)
>
> My other question is similar to what Andrew asked earlier: what potential
> is there for including something more than just strings?
>
> My team just finished up a test where simple "your edit was saved"
> confirmation messages lead to a significant bump in the editing activity
> of
> newbies on English Wikipedia.[1] The only core differences between the
> custom notification we built and bubble notifications are that it was
> center-aligned and that it included a checkmark icon. I would prefer to
> build on top of this if we're going to try and make an edit confirmation
> message a part of MediaWiki.

mw.notify accepts DOM nodes and jQuery objects. So you can add in whatever
html you want by parsing it into dom.
mw.notify also accepts mw.Message objects so you can use `mw.notify(
mw.message( 'foo' ) );` and it'll be parsed.

> Steven
>
> 1. https://meta.wikimedia.org/wiki/Research:Post-edit_feedback


--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]


_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Notification bubble system [ In reply to ]
On Sep 14, 2012, at 3:11 AM, Daniel Friesen <daniel@nadir-seen-fire.com> wrote:

> On Thu, 13 Sep 2012 15:03:04 -0700, Steven Walling <steven.walling@gmail.com> wrote:
>
>> On Wed, Sep 12, 2012 at 11:09 PM, Erik Moeller <erik@wikimedia.org> wrote:
>>
>>> Is the system documented somewhere already so gadget/script authors
>>> can start using it?
>>>
>>
>> +1 to docs for this, please. :)
>>
>> My other question is similar to what Andrew asked earlier: what potential
>> is there for including something more than just strings?
>>
>> My team just finished up a test where simple "your edit was saved"
>> confirmation messages lead to a significant bump in the editing activity of
>> newbies on English Wikipedia.[1] The only core differences between the
>> custom notification we built and bubble notifications are that it was
>> center-aligned and that it included a checkmark icon. I would prefer to
>> build on top of this if we're going to try and make an edit confirmation
>> message a part of MediaWiki.
>
> mw.notify accepts DOM nodes and jQuery objects. So you can add in whatever html you want by parsing it into dom.
> mw.notify also accepts mw.Message objects so you can use `mw.notify( mw.message( 'foo' ) );` and it'll be parsed.
>

... 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>

-- Krinkle


_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Notification bubble system [ In reply to ]
On Sat, 15 Sep 2012 06:11:31 -0700, Krinkle <krinklemail@gmail.com> wrote:

> On Sep 14, 2012, at 3:11 AM, Daniel Friesen <daniel@nadir-seen-fire.com>
> wrote:
>
>> On Thu, 13 Sep 2012 15:03:04 -0700, Steven Walling
>> <steven.walling@gmail.com> wrote:
>>
>>> On Wed, Sep 12, 2012 at 11:09 PM, Erik Moeller <erik@wikimedia.org>
>>> wrote:
>>>
>>>> Is the system documented somewhere already so gadget/script authors
>>>> can start using it?
>>>>
>>>
>>> +1 to docs for this, please. :)
>>>
>>> My other question is similar to what Andrew asked earlier: what
>>> potential
>>> is there for including something more than just strings?
>>>
>>> My team just finished up a test where simple "your edit was saved"
>>> confirmation messages lead to a significant bump in the editing
>>> activity of
>>> newbies on English Wikipedia.[1] The only core differences between the
>>> custom notification we built and bubble notifications are that it was
>>> center-aligned and that it included a checkmark icon. I would prefer to
>>> build on top of this if we're going to try and make an edit
>>> confirmation
>>> message a part of MediaWiki.
>>
>> mw.notify accepts DOM nodes and jQuery objects. So you can add in
>> whatever html you want by parsing it into dom.
>> mw.notify also accepts mw.Message objects so you can use `mw.notify(
>> mw.message( 'foo' ) );` and it'll be parsed.
>>
>
> ... 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).
w3-notifications uses iconUrl, but yeah we could shorten it to icon.

> * title (optional)
> Title of the message. If too long, will be auto-ellipsis-ified.
Already in the options.

> * 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).
The body/content of the message is the most important part of the
notification. Displaying it is the whole purpose of the notification. Why
should it be truncated?

Also we already have the mw.notify(body, options) form, we don't need to
go putting body into the options.

> * 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>
>
> -- Krinkle


--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Notification bubble system [ In reply to ]
Great stuff.

I think it should be in mw.util , alongside mw.util.jsMessage() , which I
assume it obsoletes.

Is the system documented somewhere already so gadget/script authors can
> start using it?
>
I don't see anything yet in
https://www.mediawiki.org/wiki/ResourceLoader/Default_modules

--
=S Page
_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Notification bubble system [ In reply to ]
On Sun, 16 Sep 2012 22:44:14 -0700, S Page <spage@wikimedia.org> wrote:

> Great stuff.
>
> I think it should be in mw.util , alongside mw.util.jsMessage() , which I
> assume it obsoletes.

https://gerrit.wikimedia.org/r/#/c/19199/

Krinkle, Aug 27th

> Is the system documented somewhere already so gadget/script authors can
>> start using it?
>>
> I don't see anything yet in
> https://www.mediawiki.org/wiki/ResourceLoader/Default_modules
>


--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]


_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Notification bubble system [ In reply to ]
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

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@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Notification bubble system [ In reply to ]
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
>
> 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@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
Re: Notification bubble system [ In reply to ]
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.com>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 <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
> >
> > 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@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
>



--
Jon Robson
http://jonrobson.me.uk
@rakugojon
_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Notification bubble system [ In reply to ]
On Tue, Sep 18, 2012 at 5:11 PM, Jon Robson <jdlrobson@gmail.com> 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.

The notifications time out after a few seconds, but the timeout
doesn't trigger if you're mousing over them (so you're not
accidentally losing a notification just as you're about to click in a
link on it or whatever). Perhaps mousing over the down arrow could
automatically dismiss any open notifications.

--
Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation

Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Notification bubble system [ In reply to ]
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
> <gerard.meijssen@gmail.com>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 <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
>>>
>>> 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@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
>>
>
>
>
> --
> Jon Robson
> http://jonrobson.me.uk
> @rakugojon
> _______________________________________________
> 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
Re: Notification bubble system [ In reply to ]
On Commons it seems to take 5 seconds to disappear which is too long as at
this point I'm wondering how to dismiss it.
A good ui pattern would be for it to fade out over those 5 seconds to show
me what is happening and when I hover over it go back to no transparency to
signal that it will fade automatically and I need to move my mouse over it
to stop this.

FWIW I think clicking anywhere outside the box should make it disappear.

On Tue, Sep 18, 2012 at 5:14 PM, Erik Moeller <erik@wikimedia.org> wrote:

> On Tue, Sep 18, 2012 at 5:11 PM, Jon Robson <jdlrobson@gmail.com> 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.
>
> The notifications time out after a few seconds, but the timeout
> doesn't trigger if you're mousing over them (so you're not
> accidentally losing a notification just as you're about to click in a
> link on it or whatever). Perhaps mousing over the down arrow could
> automatically dismiss any open notifications.
>
> --
> Erik Möller
> VP of Engineering and Product Development, Wikimedia Foundation
>
> Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>



--
Jon Robson
http://jonrobson.me.uk
@rakugojon
_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Notification bubble system [ In reply to ]
On Tue, Sep 18, 2012 at 9:28 PM, Jon Robson <jdlrobson@gmail.com> wrote:
> On Commons it seems to take 5 seconds to disappear which is too long as at
> this point I'm wondering how to dismiss it.
I think the time should depend on the length of the message.
The watchlist notification in Portuguese has ~46 words,
and if I didn't know what it was saying, that information would be lost.
Maybe it should allow us to see previous notifications by clicking somewhere.

On Tue, Sep 18, 2012 at 9:28 PM, Rob Moen <rmoen@wikimedia.org> wrote:
> 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.

+1. This is bothering me as well.

Helder

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Notification bubble system [ In reply to ]
On Tue, Sep 18, 2012 at 5:28 PM, Rob Moen <rmoen@wikimedia.org> wrote:

> 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.
>

I think we need to add this to the bug (
https://bugzilla.wikimedia.org/show_bug.cgi?id=40307) but it's definitely
in the requirements from our post-edit notification listed on MediaWiki dot
org.

It's necessary to have the 'bubble' follow you if we ever want to give a
notification to someone after they edit a section and are returned via an
anchor link, as an example.

Steven
_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Notification bubble system [ In reply to ]
On Sep 18, 2012, at 5:07 PM, Gerard Meijssen <gerard.meijssen@gmail.com> wrote:

> On 18 September 2012 00:09, Steven Walling <steven.walling@gmail.com> wrote:
>
>> 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@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>>
>
> 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
>

Doesn't matter in this case. The point is that the message is oversized. It
contains too much redundant information for a simple confirmation that the page
was added to the watchlist.

Considering that this message is not wiki-content, it doesn't make sense to
truncate it. It simply needs to be shortened at the source. The interface
messages in question are (from ApiWatch.php):

* addedwatchtext [1]
* removedwatchtext [2]

"removedwatchtext" is short and to the point.

-- Krinkle

[1] https://www.mediawiki.org/wiki/MediaWiki:addedwatchtext/en
[2] https://www.mediawiki.org/wiki/MediaWiki:removedwatchtext/en
_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

1 2  View All