Last modified: 2014-02-12 23:45:38 UTC
Wether it's watch lists changes, talk page updates, or various calls to actions .. mobile needs a unified interface to know about changes to publish to its users.
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.)
Helpful suggestion: http://www.mediawiki.org/wiki/New_Editor_Engagement/Email_notifications
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
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.
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]