Indeed, banners are not primarily intended to notify you; their intention is attention-grabbing and this is inappropriate for projects serving to increase knowledge, I believe. So for most applications, using CentralNotice is not legitimate usage of this tool, except Fundraising, which in turn should not distract logged-in users or anonymous editors. What we need is a way to let the user decide which information to obtain and, optionally in which fashion. Our primary question should be “How can we spread notifications to interested people most efficiently” and not “What type of web banner is more effective?” We are not here to annoy people, we are here to help them building educational content.
Let me focus on “the which” first: All kind of different interests are among Wikimedia users, some are interested in GLAM others focus on article work while a third group does administration work. Though CentralNotice can be targeted to specific projects, there is no way letting the user decide which kind of notice they would like to receive at which project. Therefore, I wrote an admittedly non-scalable system for Wikimedia Commons. It hasn’t been used frequently but gives the user the option to disable it completely (without ugly hacks), dismiss single messages (permanently, not using cookies at all) and to filter by topic and for the message creator various additional options. Try authoring a message yourself using the wizard [1] or read the docs [2]!
I’d like to summarize some aspects I would expect from a well-formed notification system: • Seamless integration with “Notifications aka. Echo” (or the watchlist). • Local project administrators should be able to push messages for their project. • The user should be able to decide about: o Where to be notified: I.e. -getting all messages for all projects at the same time -getting a banner or even a sound if there are new notifications o Topics to be notified about. o To not be notified about anything. o The geo-location the message is displayed for as this can’t be determined from IPv6 addresses. • The system supports proper i18n from the beginning on. • The system does not store cookies in the browser as a single solution for dismissing notices; instead it disables messages in server-side storage. Privacy settings, changing browsers or user profiles and virtual instances that are reset after shutting them down lead to the undesired result of getting a previously dismissed notice again. • Everything CentralNotice already has, including geo-targeting. Feel free extending this list.
As far as I know, there is also no analysis-tool for how CentralNotice is used. Imagine a timeline where the “campaigns” are drawn on as bars, optionally filtered by notice setting. This would at least allow us proving statements à la “Yes, CentralNotice and the need for communicating information through it became more important over the last 2 years”.
Since about 1 ½ years, I have blocked the CentralNotice completely using AdBlockPlus in Firefox due to all the annoyance. This allows me to block the nasty messages away on each wiki and also prevents that the “ad-content” is loaded, not just hidden. |https://meta.wikimedia.org/wiki/Special:BannerRandom |https://meta.wikimedia.org/wiki/Special:RecordImpression
The number of discussion- and notification-channels grows but I would personally prefer one well-formed channel. While writing the mailing list post, I know that only a fraction of people who are interested in it will read it and that under those who receive it, only some bother about it and more worse, that collaboration work using e-Mails is quite hard.
Time for a good central notification system for our own communication, I think.
Kind regards Rainer Rillke -------------------- just a Commons user
[1] https://commons.wikimedia.org/w/index.php?title=Help:Watchlist_messages/Wiza... [2] https://commons.wikimedia.org/wiki/Help:Watchlist_messages