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/Wiz…
[2]
https://commons.wikimedia.org/wiki/Help:Watchlist_messages