Bug 32283 covers an API method to poll for notification updates, which would be suitable for MobileFrontend to use once things are going into it.

(Nicer long-poll or WebSockets methods are conceivable too but are all enhancements for the future, requiring suitable server-side support.)

philinje wrote:

Helpful suggestion:

http://www.mediawiki.org/wiki/New_Editor_Engagement/Email_notifications

philinje wrote:

Wanted to mention that several proposed new mobile features are referencing this bug, in the hope that a new notification system will apply to all of them. Here are the bug numbers:

Photo upload:
bugzilla:31979 - Android app
bugzilla:32286 - Mobile Web

Watchlists:
bugzilla:32290 - Main

Proofreading annotation:
bugzilla:32329 - Main

Article feedback:
bugzilla:32293 - Main

Moodbar and comments:
bugzilla:32304 - Main

Possibly also:
Share or "e-mail to friends" functionality to MobileFrontend (prefill email), include SMS
bugzilla:24359

Summary here:
http://meta.wikimedia.org/wiki/Mobile_Projects/features#Participatory

philinje wrote:

From John Erling Blad:

You will find the code at
http://no.wikipedia.org/wiki/MediaWiki:Gadget-notifications.js
http://no.wikipedia.org/wiki/MediaWiki:Gadget-notifications.css
(that is http://no.wikipedia.org/wiki/Spesial:Tilleggsfunksjoner/export/notifications)

There is also a page about it at no.wp
http://no.wikipedia.org/wiki/Bruker:Jeblad/notification

Google translate (Really Bad Translation™)
http://translate.google.com/translate?sl=no&tl=en&js=n&prev=_t&hl=no&ie=UTF-8&layout=2&eotf=1&u=http%3A%2F%2Fno.wikipedia.org%2Fwiki%2FBruker%3AJeblad%2Fnotification

I'm not sure if the code as it stands is realy useful for mobile
devices. It maintains state through cookies and it should be done
through session storage. The solution also keeps polling the watchlist
feed, which is kind of stupid. The watch list feed is heavy on the
server while the plain RC feed is more easy to reuse and cachable.
Queries to the server should be given tmestamps, maxage and smaxage.

The general idea is to keep the visited pages in some structure
available for the client browser, and to filter out those entries on
the RC-feed that are interesting to the user. If he has visited the
subject or talk page, then later updates or changes to those are of
interest. In the mobile skin you are probably just interested in
counting the changes, but I posted a descriptive list instead. This
list has some problems right now that I didn't bother fixing as the
present version is more or less dead. The most important problem is
that the list fails to survive a page reload, and the second most
important is double posting of the lista when a poll for the RC-feed
comes right after a poll for the watchlist feed.

A reworked version should initialize by pulling the watch-list (which
is heavy lifting) and them later only pull the RC-feed. Rationale is
that the user usually must visit a page to be able to put it on the
watchlist, so using the visited page as a proxy for the watchlist will
work out. In other words, you will always visit a page before you can
change the watchlist. Weell, sort of, as you can write a gadget that
changes the watchlist.

On some browsers (Google Chrome) it is possible to use a background
page for the pulling av displaying, then the yellow sticker (the
report) can be animated through the page reload. The same is possible
with an iframe trick, but then the page URL will be hidden. I'm not
sure if this is a real problem as there are some ways to get around
that to. That is the page name can be set as a fragment (#title) or as
a subpart (;title). Not as pretty as today, but it works.

Just some additional notes...

The gadget could use a high frequency update cycle on the curent
project the user is visiting (each minute) and a low frequency update
cycle for other projects where the user have pages on the watchlist
(each 5-10 minutes).

The initial pulling of the watchlist could also be done in two phases;
only recent active pages would be loaded in the first phase and then
the raw list of pages would be loaded in the next phase. This would be
done after the page as such would be completed. The watchlist could
also be stored in local storage. This is especially interesting if its
possible to download the raw list as it existed at some previous time.
If so the stored copy would keep a timestamp for last update and would
do a check out of changes to the server version from time to time.

Its important to differentiate between some of the notifications.
There are broadcast notifications like the RC-feed that goes to
several listeners and which is difficult to filter at the server,
those should be pushed to the clients unfiltered. Then there are some
area notifications, those should be something the user register for on
a session basis. Then there are user specific notifications and those
should not be delivered to other than the user, and they should queue
on the server until the user logs in.

I said area notifications but its really a bit more complex, its
category notifications. The area notifications can be reformulated as
category notifications, and the locations for the cellphones could be
used for the registering of interesting categories. This also imply
that there are two modes of registering for notifications, one session
based and one permanent. The watchlist is the permanent one and exists
today but there should also be a session based one, but that could be
driven by the client and it is probably only interesting for a
category. If it is reformulated its simply a watchlist with categories
in addition to pages, and its also the session vs permanent
distinction. But note that categories on the watchlist creates
troubles for the easy scanning of the RC-feed! This could although be
solved by including the categories for the articles on the RC-feed.

Area notifications as category notifications can be done by simply
registering for notifications for a given latitude and longitude and
then doing an intersection between them. It is also possible to
organize the map in other ways, for example like the UTM-tiles. There
are several options, the important thing is to make a fragmentation
that makes the categories manageable.

The important thing is; you want as much reuse of notification feeds
as possible, everything that imply user specific processing at the
servers are bad. Move it out to the client browsers and do as much as
possible there.

Lastly, most (all?) other notifications can be reformulated as a
combination of permanent or session based broadcast, category or user
notifications. Don't invent special notifications, use for example
location categories together with a category "churches without a
photo".

That should be about all I have about notifications.

philinje wrote:

From Brion:

http://www.mediawiki.org/wiki/Requests_for_comment/Notification_framework

From Timo Tijhof:

https://www.mediawiki.org/wiki/Requests_for_comment/Tickets

From Guillaume:

http://usability.wikimedia.org/wiki/Multimedia:Flows

Note that the Ticket system I propose does not (and I don't intend it to) cover notifications. Users would still need a way to get notified of this.

I'm not sure what the bug here is as there is no real concrete call to action.
Yes we want a notification system but let's wait till later when there is a concrete need to drive this.

[Closing as "WONTFIX" to get rid of the deprecated "LATER" resolution]