WordPress Notification Center proposal

[hedgefield]

For a long time people have been suggesting / daydreaming / ​wishing for a unified notification center in WordPress. People expect it, the notification center has become a staple of almost all apps/sites that have a lot to keep track of - and WordPress definitely fits in that lineup. So there’s no reason not to add one to WordPress core too.

This ticket aims to explore the details of such an implementation. I think clear limitations, a good backwards compatibility strategy and a strong UX are key to make this work for everyone.

Key features:

• One location for all notifications.
• Easy to hook into, should work out of the box.
• Flexible enough to be useful, limited enough to not get a circus.
• Accessible from anywhere.
• Accessible in the a11y sense.

Here’s my first basic idea for notification properties, feel free to chime in:

• A text field, limited to 280 characters, the length of a tweet. Probably wouldn’t want one notification to get so long that it fills up the whole visible sidebar. Links can be added to the text to trigger actions or visit pages, same as now basically.
• A timestamp.
• An icon. Could be the plugin icon, author avatar, or something like a category/message type, like info, warning, question, error, update, stuff like that, to visually distinguish notifications quickly.
• A status, meaning read or unread basically.
• Persist/show as toast. A suggestion by Joen Asmussen. Shows the notification outside the notification center for a set amount of time in a floating div. Similar to what Android/MacOS/Windows does when a notification comes in. Maybe only WordPress itself can throw notices like that. Probably not for MVP anyway.

I created a quick interactive proof-of-concept in Sketch that you can view here.

Desktop: ​https://sketch.cloud/s/AZz0M/all/notification-center/desktop/play
Mobile: ​https://sketch.cloud/s/AZz0M/all/notification-center/iphone-8-plus/play

Riad Benguella got excited by this idea and built a basic plugin to test it in your own WordPress install. ​https://github.com/youknowriad/newtify, and also a previous exploration at ​https://wordpress.org/plugins/wp-notification-center/. Developing this as a plugin is a great way to explore the best implementation, and any help is more than welcome.

Some discussion points to get this started:

• Can we agree on a set of notification properties that provide a consistent experience and that plugin authors can be happy with?
• Which notification categories can we define, and should it only ever be possible to assign a category, or are plugin authors allowed to supply icons for their own notifications too?
• How best to approach the backwards compatibility so we don’t break (all) existing admin notices? Can some type of conversion be made?
• Is it enough to only show the notifications in the sidebar, or should there be a separate notifications page, maybe with filtering? (Probably not for MVP at least)
• Are there any essential features missing from the list?

[karmatosed]

Cool feature and I am a huge fan of notification systems when useful but not shouty. This seems to be on the useful side :) Thanks for taking the time to work out a mock for this. The current state of messages across most areas of the interface is not optimal and this provides an opportunity to restructure that. I do note, with this we should maybe lock down areas, making this the place to use and encouraging better practices.

What notification systems did you look at when considering the design? What can we learn from what others are doing inside/outside the WordPress space?

There feels like a few things that are super useful to those managing a lot of things missing we could consider:

• Filtering the notifications by that day, week and so on
• A link to adjust settings in header

I wander how useful 'mark all as read' is. My concern is that's quite prominent placing for it. This could easily have a mistaken click and boom all go, not great user experience.

I would also look to the notifications themselves. For example what is the visual hierarchy there:

• Do we need to have bold and what are bold?
• Do we need time and is that too small or right placing?

From a plugin perspective how do they add notifications? I assume this is code?

To answer your direct questions:

Can we agree on a set of notification properties that provide a consistent experience and that plugin authors can be happy with?

We need to really distill down and build up. Maybe we firstly do not have open to plugins. Get it in and have it just for system, then add for plugins. I would advise this route.

Which notification categories can we define, and should it only ever be possible to assign a category, or are plugin authors allowed to supply icons for their own notifications too?

I think we need to limit this.

How best to approach the backwards compatibility so we don’t break (all) existing admin notices? Can some type of conversion be made?

What would break? Could we eventually just move all to this?

Is it enough to only show the notifications in the sidebar, or should there be a separate notifications page, maybe with filtering? (Probably not for MVP at least)

I think we need to test this, it's an assumption I'm not comfortable making. We need a settings page for this and need to link wherever the notifications show.

[danieltj]

I've wanted something like this for ages to unify the notifications within WordPress and to once and for all do away with admin notices if it's possible at all. Something like the WordPress.com notifications centre would be good as it condenses everything down into one side panel and is easy to see.

I can see the following setup for notifications in an API sense:

• A notification ID (completely unique)
• Sender (either via Core, Plugin, Theme or User)
• Sent (YYYY-MM-DD HH-MM-SS)
• To (Array of User IDs)
• Read Status (read/unread)
• Message
• Expiries (a timestamp but if blank, until read)

A key concept here that I really like is a group notification function where a collection of users can receive the same notification such as a new comment or user signup etc.

I think for backwards compatibility, an option to merge admin notices into the notifications section but split into notifications and notices so you still keep the list of notices as is, but split them out to remain less cluttered.

A feature plugin is 100% the best way for this and I think I might be getting carried away with it, but this idea seems to be something that most people want. But as @karmatosed has rightly said, lets make sure that this is simple and too the point with the ability to extend functionality through hooks and plugins.

From what I've seen on other sites, notifications are fairly linear and not usually complex in nature like categorises and priority. I think an approach like that is the best way because we have this problem with admin notices at the moment where you can end up in some instances having 5 that don't dismiss.

Also changing to Users component as this is technically a user facing thing.

[hedgefield]

Thanks for the feedback feedback so far!

For this PoC, I looked at the wordpress.com notification center, Facebook, Google, Meistertask, Instagram and in general my mental modal of expectations for a notification center. Speaking for myself, I generally prefer simplicity, so the filtering and second expanding sidebar on .com are a bit much, and I appreciate being able to clear the badge asap on facebook, which is why I added the Mark As Read. But hopefully for WP the notifications will be a lot more useful and relevant, so I can see that we move that somewhere else, or just remove it for MVP and make it depend on whether you take action on a notification or maybe look at it for 3-5 seconds. A settings icon would be useful too I'm sure, left it out in the PoC as I didn't have any settings in mind yet.

I'll make a more detailed breakdown of pros and cons of other notification centers, so we can have informed discussions about the separate features.

It may indeed be a good call to start off giving just WP itself access to this. This gives plugin authors time to think about how they can integrate without having to scramble right away because their admin notices now look crappy when frankensteined into that sidebar. That's what I mean with backwards compatibility: introducing the notification center once it has been fully thought out also requires an exit strategy for admin notices, since those can be huge and filled with custom styling and whatnot, which wouldn't translate 1-to-1 to the new notification properties per se.

Regarding the more technical side of notifications, Riad said (in relation to his PoC plugin):

As a V1, I built as a client-side API trying to provide a compatibility layer with existing notices. So client-side code could trigger notifications but without any persistence. I think we should make this step work well to catch all the plugins notifications etc. I was thinking of checking the way these notifications are generated right now in PHP and if there’s APIs and common ways to do it, and try to provide some kind of backwards compatibility with this plugin.

Once this work well, I think we can start thinking about a backend API and a persistence layer. Something like “keep the last 100 notifications persisted”, “Provide a way to trigger notification from the backend”, “Client-side code could also create and persist notifications” (REST API?). => this could be the V2.

I know Alain Schlesser and John Billion have ideas about this too. I'd say we first focus on the higher level concepts and architecture here, maybe defer some experimentation and prototyping to the plugin's repository.

[netweb]

Via ​https://make.wordpress.org/core/2016/10/03/feature-project-proposal-notifications-api/

​John Blackbourn writes:

Feature Project Proposal: Notifications API

Most of the situations where WordPress sends an outgoing email can be classified as a notification. X just happened on your website and you should be aware of it.

Back when WordPress was a youngster, the only way to reliably notify a user was via email. In 2016 we have many more options, including push notifications to mobile platforms, desktop notifications to browsers, messages to chat apps, endless services via webhooks, SMS messages, or even notifications in the WordPress admin area. The list goes on. For many users, email is no longer the optimal delivery mechanism for ephemeral notifications.

To that end, let’s think about replacing wp_mail() with a modern API that allows developers to route notifications to services other than email, allow them to better modify notifications and the way in which they’re formatted, and allow them to do so without stepping on each others’ toes.

The current lack of a notifications API (or even an email sending API) can be easily summed up:

Problem: Plugin A wants to provide HTML emails, and Plugin B wants to send emails via an email delivery service such as Mandrill. Plugin C wants to disregard emails and send Slack notifications. It’s very difficult for these to co-exist.

Notification Destinations

There are only two types of destination for a notification in WordPress. Most notifications are actually notifications to a user account that get delivered via email because it’s the only contact information available for every user account. The remaining notifications are explicitly notifications to an email address rather than a user account (or not yet attached to a user account), such as when a user signs up for a blog and needs to click a confirmation link before their user account gets created.

With this in mind, you might be able to imagine a notification class in WordPress core that defaults to delivering notifications via email, but which can be extended by a plugin on a per-user and per-notification basis to deliver notifications via any of the means listed above. WordPress core would support delivery via email and provide the API that allows plugins to implement delivery via other means.

With a well-designed API, multiple plugins can co-exist in order to deliver different notifications via different mechanisms, format email notifications as HTML, easily disable notifications, change the delivery mechanism for email notifications, or provide a UI for users to manage their notification preferences and destinations.

Planning a Notifications API

I’d like to begin work on a feature project with the intent of designing and implementing such an API. I’d like to get input from authors of existing plugins that provide functionality such as delivering notifications via a service other than email, that override the default email delivery mechanism, or that implement extra notifications (such as e-commerce sale notifications), in order that the API can be backwards compatible and that we can get some plugin implementations built during the API’s development.

I already have some technical ideas regarding how the API might look, but I’m conscious that such an API needs to be well-designed before anyone jumps into writing code. Maybe we can even try some test-driven development? Who knows.

In addition, consultation and involvement with the team that are working on ​the two-factor authentication feature project is important as it implements several delivery mechanisms for 2FA codes that could potentially be made simpler with a notifications API.

Note: There ​are comments from the above post discussing the proposal further, what's relevant and related should also be bought into the discussion here on this ticket

[danieltj]

I think some wires are being crossed here as I think from what @hedgefield is actually proposing is what we'd consider 'real notifications' whereas what @johnbillion has proposed in the Core post is not so much a notifications API, but a email API instead.

If you were to ask someone about notifications in this modern age, people will without a shadow of a doubt expect notifications like on iPhone/Android or Facebook/Twitter where it's a dismissible message in some kind of notification area. Email is separate and we already have wp_mail doing a lot for us already.

We need to be clear on the expectations here I think because the screenshots added to this ticket already indicate a modern, social media approach whereas I think the original expectation was for notifications of things via email. I don't see why we can't have both working harmoniously but it's something we need to decide on.

[hedgefield]

Yes, thanks for clarifying @danieltj. I didn't read enough into what John had written down to realize his approach was based on email. For this ticket I was indeed shooting for a notification center in the admin with what we might call 'push' notifications. If there is an option to also send an email, no problem, there are sites that do that too (Facebook and Twitter among them), but I see the most gain in focusing on in-admin 'push' notifications first.

[netweb]

By building a Notifications API a new Notification Center can harness all that goodness the API would offer.

For instance, myself personally I don't want any emails nor do I want any notifications within the WordPress dashboard, I'd like all my notifications delivered into Slack, others might want their notifications delivered into HipChat, Discord or via bot into Twitter or Messenger.

By having that flexibility by way of a new Notifications API I can turn off all notifications in the WordPress Dashboard, I could turn off the entire Notification Center even, personally, I've no use for notifications inside of WordPress myself.

The Notifications API feature project is far from an email API it is a new API to facilitate and enable multiple notification types within WordPress, as part of maintaining backward compatibility in the new API it would include a notification route using wp_mail(), any other routes such as a route to the WordPress admin area would be added to core on a case by case basis, which is what would be required for a Notification Center anyway, whereas routes to Slack, HipChat, Twitter, Messenger etc would be plugin territory.

[schlessera]

I too think that there should be an API first, and the visual notification center in the dashboard would then be one specific use case of implementing this API.

In general, a notification API should be a routing system, that allows to receive communication from a source and route it to a recipient.

Valid types of sources are Core, plugins, users, server environment, cron jobs, ...
The recipient can be either a specific user or a role/capability.

The notification should have a type or group, and the user should be able to define where they want to receive the individual types/groups. So, if a plugin reminds me for the 20th time that I should rate it 5 stars, I'd like to only have this shown in the notification center in the dashboard (or even not at all). But if my backup plugin wants to tell me that the backup failed, I want to receive this via email & Slack notification.

So, there would be multiple destinations that a user can have enabled, and the user should be able to configure these individually, with sane defaults applied by default.
Destinations can be dashboard notification center, email, Slack, HipChat, IRC, SMS, ... Basically, we provide an interface, and multiple destination providers can implement that interface.
As a default setup (OOB experience), I could see having both a dashboard UI and an email as destinations, and showing everything in the dashboard UI, and only sending important/urgent notifications to the email.

Regarding the message size, I don't think limiting it to 280 characters is a good idea. It will probably make translations an eternal struggle, with cut off messages all around. The reason why Twittter switched from 140 chars to 280 chars is because some languages couldn't make proper use of it with 140 chars. Now, those languages can use Twitter, but a limited version as compared to the others. There's no "character limit" that makes sense when applied across all languages.

I'd rather prefer the ability to block certain sources, and to adapt the font size/compactness of the notifications instead, and then let the "market" figure out the rest.

Regarding the state of the notification, I think it should also allow for some sort of "snooze" functionality. But that is certainly not something we should implement from the start. Just want to state this to make sure we don't turn the state into a boolean to mean unread/read. Who knows what other states we might need in the future.

I don't think we should allow for an expiry of notifications, as that can only be provided in an "updateable" medium. If you send the notification via email or Slack, for example, you cannot expire it.

The above API would then also have an impact on how the visual design of the dashboard UI works:

• Every notification must clearly show a "source" in a consistent way.
• Every notification may show a type/group in some way (not sure if or how).
• There should be a link within the UI to configure the user's preferences.

Also, notifications should not assume anything about the context in which they are being displayed.

On the server side, the API could look something like this:

<?php
function delete_my_stuff() {
   // $this->stuff->delete();
   wp_notify(
      WP_Notify::SOURCE_CORE,
      get_current_user_id(),
      WP_Notify::TYPE_ALERT,
      __( 'Yikes! All your stuff has been deleted.', 'default' )
   )
}

On the client side, the JS API could mirror this signature, and then use the REST API /notifications controller to execute this.

[Clorith]

I'm a big fan of a notifications area to reduce noise in the admin (I think there was even talk of adding this in the admin bar redesign discussions if I remember correctly).

I will note though, there may still be use cases for admin notices, so just filtering those over into a new area isn't a good solution, they will have to co-exist.

First example that comes to mind: A new WordPress version is available, this is a notification, but "This plugin encountered an error and was deactivated" (from our own sandboxing during activation) can't be hidden away in a notification. It should be an admin notice as it is now or else the discovery of that critical information may go unnoticed for a while.

[johnjamesjacoby]

BuddyPress eventually evolved Notifications into a first class component similar to Groups, Activity, Messaging, and the others.

Like what’s already happened here in 2 days, a simple easy POC immediately turns into a complex application inside an application. Post types and taxonomy terms aren’t a great fit either, because notifications are generally per-user, not per-role or whatever else.

Not being a nay-sayer; only that everything from UX to data storage will require a completely new invention to work the way notifications traditionally are expected to work.

[MikeSchinkel]

This ticket definitely peeks my interest.

I was just recently contemplating the fact that notifications are presented to logged in users who are often not the administrators, and the fact that administrators may not log in often, especially if they are overseeing many different sites. So I have been wanting to find a way to route all notifications that are not specific to user actions to a central log where an administrator can be proactively notified when a new notice it added but that users would not need to be bothered by these notices.

Said another way, I am completely on board for this proposal, especially if it follows the API and classification aspects suggested by @schlessera.

Replying to johnjamesjacoby:

Like what’s already happened here in 2 days, a simple easy POC immediately turns into a complex application inside an application. Post types and taxonomy terms aren’t a great fit either, because notifications are generally per-user, not per-role or whatever else.

I would argue that some notifications are per-role; e.g. "There is a new version of plugin X", "You need to set your account/license key" and "Upgrade to the Pro version!"

Not sure what others want, but those are the ones I would most like to see removed from the admin console and adding into an API that an admin could aggregate across multiple sites.

[folletto]

This is great, I'm glad to see it picking up steam. :)

For now, I just want to cross wires with another discussion that is waiting for developers to happen, which is the global navigation from the WordPress toolbar. It has already a solid design there, and just needs someone to pick up and start the feature plugin. It's here:
https://core.trac.wordpress.org/ticket/32678

Why am I mentioning this that might seem unrelated? Two reasons:

1. The redesigned navigation in that ticket also has an idea for a lightweight notification indicator (just that, it doesn't go in too much detail) so might be nice to review the last design there and see if there's something that can be borrowed and iterated.
2. While working on the API, it would be nice if it would keep in mind the ability to create "multiple" notification streams, as from the design above it could be useful to toggle other kinds of notifications. What I mean with this is that the "default" stream is the one shown in the designs in this thread, but in the future we could have another one that shows dots on specific areas on the admin (think also: multisite) to indicate there's a notification waiting not globally, but in that specific sub-stream.

While this second bit of UI doesn't have to be built right now, it would be nice to include multisite and multi-stream in the API level since the beginning (even just as reserved fields initially with a fixed value, yet standardized) — Having the API driven by iterated designs, but being built first, allows a lean approach to the problem without exploding the scope.

[johnjamesjacoby]

We should start this off by deciding which single notification we want to introduce, and what it should look like inside of wp-admin.

Let’s say we start with something that’s likely to be seen, like a “A new version of WordPress is ready to install.” kind of notification.

• What does it look like?
• How do you acknowledge/dismiss/hide it?
• What types/styles/variations are there at launch?

Thinking about this strategically, there is some overlap between the existing Pointer API and any Notifications API we might build. Maybe we can also unify some styling while also giving pointers some TLC.

Just like pointers (and admin notices) Notification abuse will likely be pretty rampant also, and Users will quickly become annoyed by needing to address an inbox of todo’s each time they login. I’m not suggesting we tackle an entire Notification Center feature from the start, but we should at least define what the ettiquite is for using it amongst plugin and theme authors.

Without trying to play favorites, I feel like @melchoyce or @karmatosed would be a really good visionaries for how to keep this simple for a v1, but there are likely a thousand other qualified folks as well.

I’m adding the needs-design keyword to this, because I think this is the type of user-facing feature that needs a good design first to get others excited about the functionality it could enable.

[ahortin]

WordPress should automatically handle the handle the dismissing of the notice and not leave it up to the plugin/theme developer who creates the notice, like it is now. Too many plugins have non-dismissible notices, or useless notices that show for every single admin user. The latter being incredibly annoying when you're managing client sites. In other words, every single notice should be dismissible, and developers shouldn't even have the option of making a notice non-dismissible.

Also, just in regards to that mockup above, if the notices were shown in that fashion it might be worth considering forcing a word limit on the length of notice that is displayed. If it exceeds that length, have a link that shows the full notice text in a popup or something. The reason I'm saying this is because I've seen numerous notices from highly popular plugins that would literally cause it to display for half the page if it was shown in a narrow column like that.

[karmatosed]

What a great discussion here on this ticket. Really excited to see where this goes design wise.

I do agree with pairing this down and then having a minimal design to scale up. @johnjamesjacoby you are right about that approach. Whilst I would be more than happy to do the design for this I would encourage you @hedgefield if you have the bandwidth to pursue this, you've already done some mocks and would love to support you refining and stripping back to a v1, if you don't let me know and I can start working on this, my preference is for you to own this though.

I think @folletto is right that crossing over with https://core.trac.wordpress.org/ticket/32678 makes sense to draw on inspiration for the lightweight notification and to consider during the API for multiple notification streams.

[MikeSchinkel]

Replying to johnjamesjacoby:

and Users will quickly become annoyed by needing to address an inbox of todo’s each time they login

Point of note, as opposed to the slew of notifications they already address every time they currently login? Just saying that it is already happening....

That said, my guess is that different people most likely envision different things when they see "WordPress Notification Center" and it would probably be a good idea to make sure everyone is explicit about what they are after and that if it is addressed without addressing some of those use-cases that we are explicit about it?

FWIW, my use-cases are I want to turn off most notifications for admin users -- except for the ones that relate to their own actions like "Post saved" -- and then be able to aggregate those into another system so I can manage the notifications of many sites from one location and out of the eyeshot of most users. And I am *mostly* talking about notifications that plugins and themes generate, especially of the "Please pay to update to our Pro version!" kind.

[hedgefield]

Thanks to everyone for their input so far! Good discussion already.

For starters, I think it’s important to remember that while a notification feed in the admin is the first and foremost usecase, we should also make sure to build this in such a way that it can support other forms of delivery in the future, like @schlessera says.

He pointed me to the Slack API for messages, which is very well documented and describes a lot of their considerations for how they built it. I’m not much of a technical expert in this regard, but it seems like a good source of inspiration. If you want to take point on that @schlessera that would be wonderful.

That said, the first and foremost usecase to explore for that API is of course the well-known notification center dropdown. This will be my focus.

I’ve compiled a list of characteristics that the big notification center implementations have, so we can compare and contrast. ​https://docs.google.com/document/d/1q7MhBrTPkpSvnvyCmaf9sd6y27MXYI1QHq-lqsp6Wuc/edit?usp=sharing

Based on all that I drafted a preliminary MoSCoW-style list of features that the API should support. For myself at least I found it a nice way to start framing the features in level of importance for MVP. Doesn't mean at all that this is the full list, it will likely expand as we drill down into this. Do let me know if you already feel something is missing or should be in a different order.

Must have

• ID
• Sender (core, plugin, theme, user)
• Destination (sites, roles, users)
• Timestamp
• Read status (read/unread)
• Message body
• Links in the message body
• Dropdown to contain the feed

Should have

• Notification type/category icon/color
• Settings page
• Multiple channels (email, push, slack etc)
• Email notifications
• Sent status for all different delivery methods
• Multisite support

Could have

• Basic markup (bold, italic etc)
• Expiry date
• Filters for specific topics
• Settings to hide certain notification (types) away from certain user roles (don’t bother clients with upgrade notices and whatnot)
• Ability to group notifications per day
• Dedicated action buttons

Then there are some specific points that I wanted to respond to:

I am strongly in favor of limiting the word count for the messages in the notification center, but I can agree that sometimes you just really need some more space, be it for translations of to get an important message across, like the ServeHappy nag. So instead of limiting the notifications themselves, it makes more sense to limit their display in this usecase. As I saw in the research, most other notification feeds are limited to about 100-150 chars, so 280 chars is a royal amount. Then if there is more text, we hide it behind a collapsible section, similar to what Facebook does for long posts. Alternatively, you could write a small ‘excerpt’ notification and link to a dedicated page where you put the rest of the info you want to convey.

If we are going to restrict admin notices to the notification center this way, I feel like it might be fair to allow bold and italic. We could also semi-restrict it: Facebook for instance bolds the usernames and post/group/event names for extra emphasis.

The simplest version of this thing would be one that only holds WP notifications. But I think before we launch we should make it possible for plugins to hook into this too. I don’t think we can move all of the notices there immediately, there are some that are huge that would need to be redesigned by their authors. But if we don’t give them access to the API from the get-go I think the adoption will be much more troublesome. As long as the WP ones are in there as inspiration we should allow third-party notifications I think. Then we can start drafting a roadmap for eventually disallowing them.

The only admin notices allowed should probably be errors.

Automatically marking messages as read is what I would prefer too, though I can imagine a usecase where you want to come back to something that you don’t have time for right now. But maybe we could solve that in a different way in v2.

For some notifications a timestamp may not be needed, but for granular stuff like changing settings or publishing content you would want to see who did it and when, I’d say, at least so you can hold them up against analytics and spot trends or problems.

Thanks @folletto for pointing me to that other ticket, as I’m now a component maintainer for the toolbar I’ll definitely take a look, though holy hell that’s a long one :D

[hedgefield]

I also like the idea of examining the functionality by zooming in on one specific notification. I made a few quick designs for the one that was mentioned.

[tareq1988]

This is an interesting concept and I didn't know the discussion has already started. I was thinking yesterday about the same thing and I have built something with static HTML/CSS.

As the original Notifications API proposal by @johnbillion solves this by implementing notification Transport, this notification center could be another transport of *push* type notification holder. It's similar to Mac OS notification center where any plugin/core or any other system as mentioned above could send a specific user a notification. A notification has to be dismissable/read and an action could be performed when clicking on the notification itself. It could lead to an url or maybe nothing.

[folletto]

Must have

I think a must have is some sort of configuration panel, even if minimal for the first release, accessible from the dropdown. The reason is that we want to make sure users can CONTROL the notifications. We can discuss what is sensible to have in the first release, but given how easily notifications can be abused (and I don't mean by plugins and themes necessarily, sometimes we are at fault too with overloading users by accident) it's something that is important to have as a statement of the direction this is going.

Sender (core, plugin, theme, user)

Connected to the above: if "sender" includes "which plugin" the settings screen could start with a simple list of on/off switches for each category:

• System and Updates (core)
• Plugins (all, or name of plugin)
• Theme (just the active one)

I'm not sure on "User" as sender. Can you expand on this?

I am strongly in favor of limiting the word count for the messages in the notification center, but I can agree that sometimes you just really need some more space

I'm strongly in favor of limiting this too. And I'd prefer to have a strict character limit. Notifications are meant to be short messages that lead somewhere else. Quick.
Having to "open" a collapsed view, or cutting some text to make it fit, would defeat the primary reason of effectiveness of a Notification, doubling the amount of interactions needed.

While I understand the problem with translations, I think we can find a good number of chars that would work across languages. If something has to be rewritten to fit, it's just the same amount of work that already happens in any primary language to make it work. It's not different, right?

For important notices I think it's the same: if it's something important, lead to a page with the proper page of an extended explanation instead of trying to make fit everything there.

If we are going to restrict admin notices to the notification center this way, I feel like it might be fair to allow bold and italic.

I understand why this can seem a good idea, but I'd reserve any styling to be functional, not stylistic. As you mention, usernames for example can be made bold, but bold shouldn't be available just as a way to highlight the content.

If we zoom out from the individual notification message to the whole stream, not having too much styling going on eases readability on the list as a whole. :)

But if we don’t give them access to the API from the get-go I think the adoption will be much more troublesome.

I agree, a lot.
I'd push this even further – even if I'm aware this might be what you already meant: first the API, and then both Core and Plugins will use the same API. Right? ;)

Automatically marking messages as read is what I would prefer too, though I can imagine a usecase where you want to come back to something that you don’t have time for right now. But maybe we could solve that in a different way in v2.

"Automatic" can be tricky in dropdown situations. What I could suggest here, also mirrored in the mockup above, is to mark something as read with these conditions:

1. If the notification is clicked
2. If the "Mark all as read" is clicked

We can refine this later to make it more automatic, but I feel this could be a good starting point.

I'd also add that we can differentiate "read" from "seen", as some notification systems do. The difference is:

1. A new notification arrive, it's signalled in the toolbar icon with a red dot
2. The user clicks, but then doesn't either click on the notification nor "Mark all as read"

This will leave the individual notifications as "unread", but the toolbar dot will disappear.

Why? In this way we have a two-tier system that allow more flexibility.

That said... we might not want to do this in the first version as it adds a layer of complexity.

For some notifications a timestamp may not be needed, but for granular stuff like changing settings or publishing content you would want to see who did it and when, I’d say, at least so you can hold them up against analytics and spot trends or problems.

This is a good point. I'm neutral on the subject as I see both advantages and disadvantages. I'd say we can start with. ;)

{ Designs }

As far the designs go, I'd go probably for the first. It's the simplest and feels cleaner.

A couple of extra things:

I'd suggest to not show the number of notifications in the toolbar, but just a red dot. The counter adds mental pressure, and the red dot is already enough for most use cases: if one can check notification, will check notifications regardless of how many they are. Remembering the number has just went up from 1 to 2 is... hard. And seeing a larger number can just put off people that will stop caring about it at all "Too many events, I'll just stop looking".

In a way, a dot without a counter is a more "calming" kind of interface, which is something we should strive for in principle, right? :)

As for the icons, we should provide either the ability to use any Dashicons, or, do something like Gutenberg is doing, which is also allowing a plugin to load any SVG inline. This should allow ease of use (I can just type a Dashicon name) but also flexibility (I can inject any icon).

Then again: this is probably a feature to be added in a future release. It's easy enough to detect SVG code and enable the feature later.

[hedgefield]

@folletto Yes, first the API, then the notification center dropdown/feed that can be used both by core and plugins, then other communication channels like email etc ;)

I like the idea of exposing the message senders as toggles in a little configuration panel, that seems very appropriate for an MVP. With 'user' I meant when a user does a thing, like edit/publish/delete a post, but you could make a case that that is a 'system' message too.

I think restricting the message to 280-320 characters is more than enough to get the primary point across, yes. Most notification centers make do with much less. But an interesting point that @schlessera raised was that if we later also enable email as a delivery channel, it feels weird to just send a 280char email, that would be a place for longer copy. I can see how that would be weird, and it's a good reminder to think from the API perspective over the usecase perspective. Though I can also imagine that we provide a higher character limit specifically for email delivery in the API. If none is provided it just sends the short version.

And you've convinced me that we should leave styling out of the MVP, readability is key.

I also like the seen vs read idea, but it might indeed be a bit too complex for MVP. But good idea.

Also on the matter of the notification badge I agree :) just a dot is more generic and calm, and avoids the problem of large numbers.

Lots of agreement!

I'll coordinate with @schlessera to try and set up a first version of this. Anyone who wants to collaborate is more than welcome! We're also looking for someone to do the frontend part of the dropdown usecase, as I'm not versed in coding for the WP admin. Perhaps someone from the toolbar component group wants to jump in?

What would be the process for defining an owner for this ticket?

[hedgefield]

A quick update: we're working on making this a featured project and get its own slack channel, we've just been very busy with recently. We have people wanting to work on the API and on the wp admin code, so I think we can make some good progress on this again soon!

I'm still wondering if its possible to set @schlessera or myself as owner for this project? I can't seem to do that.

[felipeloureirosantos]

I was looking into a way that could be really simple, and easy for new users getting at all.

I believe that we should keep it as simple as possible. Maybe something like that.

[schlessera]

Thanks for your feedback, @ @felipeloureirosantos!

I don't agree, however, that we should keep this as simple as possible. The current "admin notices" system is "as simple as possible", and I think we can agree that this is not satifying when coupled to a plethora of plugins and use cases.

What I want to do is build a robust framework first, add a simplified interface on top and then build one specific use case (with tight scope) that uses these.

We are dealing with a rather complex problem here. With time, simplistic solutions for complex problems tend to produce additional problems more than they solve the initial one.

[sanchothefat]

Awesome to see so many ideas and traction here. In the interests of collecting prior art and ideas here's something we're working on at Human Made:

​https://github.com/humanmade/Workflows

It's aimed at becoming a replacement for the things we like about EditFlow in the longer term but it does have a notification system albeit not as feature complete as the suggestions here.

The ideas in it are based on when should a notification be sent - so it uses action hooks. Those actions make certain data available which can be used to provide placeholders for a subject line and message, identify relevant users and to append links for further actions.

It's the action links part that I think would be really useful to incorporate here - a notification is great but it's even more useful when it provides follow up steps.

I implemented those links using a webhook system so that they'd work from anywhere the notification was sent eg. slack, email or the dashboard.

The specific files that may be of interest are:

• ​Dashboard notifications API
• ​Webhook API controller

Definitely keen to help out here.

[afercia]

Awesome explorations here. FWIW, personally I'd totally support the idea of a notification center. I'm going to remove the accessibility focus though, to clean-up the accessibility Trac report. Glad to put it back if this ticket will see some progress.

[karmatosed]

I think I am right this ticket needs design, so for now removing also the feedback keyword.

[johnjamesjacoby]

Additional considerations:

• Multisite
• Using post-types & taxonomies seems like a bad idea
• Notification scope (which users, where, and how)
• Notification type (UI, email, persistent, nag, reminder)
• Notification mute (unsubscribe from noise)
• Notification opt-in or opt-out?
• Notification registration API
• Notification internationalization
• Notification mark-as-read/unread
• Notification attributes (icon, title, subtitle, description, action links, and variables in all of them like user names and site titles and post titles)

Again… broken record guy chiming to say BuddyPress includes all of the above. It will feel like overkill to people who are wanting something simpler, as it requires a not insignificant amount of additional PHP and conditional logic to make it all work.

We all like inventing things, but please, please consider using what we’ve built there as some source of inspiration, even if it’s an example of what y’all decide not to do for WordPress core itself.

​https://buddypress.trac.wordpress.org/browser/trunk/src/bp-notifications

[psykro]

Replying to johnjamesjacoby:

Additional considerations:

• Multisite
• Using post-types & taxonomies seems like a bad idea
• Notification scope (which users, where, and how)
• Notification type (UI, email, persistent, nag, reminder)
• Notification mute (unsubscribe from noise)
• Notification opt-in or opt-out?
• Notification registration API
• Notification internationalization
• Notification mark-as-read/unread
• Notification attributes (icon, title, subtitle, description, action links, and variables in all of them like user names and site titles and post titles)

Again… broken record guy chiming to say BuddyPress includes all of the above. It will feel like overkill to people who are wanting something simpler, as it requires a not insignificant amount of additional PHP and conditional logic to make it all work.

We all like inventing things, but please, please consider using what we’ve built there as some source of inspiration, even if it’s an example of what y’all decide not to do for WordPress core itself.

​https://buddypress.trac.wordpress.org/browser/trunk/src/bp-notifications

Noted, with thanks.

[SergeyBiryukov]

#48827 was marked as a duplicate.

[CodeBard]

I very much think that notifications should not be pushed to a Facebook like dropdown or a separate page as shown in some examples. This would practically render them near invisible for all but the most enthusiastic users.

As far as i see, users dont go around a site and go about 'I wonder what exciting notifications i have" and click out of their way to see notifications - neither in WP ecosystem or outside.

As a user myself, in Facebook etc i expect what i would like to see to appear in my feed. I dont go about clicking the notifications icon and then go through dozens of notifications as if its a task i need to do. I know there are a lot of social media enthusiasts who do exactly that, but it is unlikely to be the norm.

Getting people's attention is hard. Everybody is increasingly busy in our modern times. Even with the current notification system, it takes a lot of repetitive nagging to have people even upgrade their plugins which you supply from your private repo (premium etc). For plugins at WP repo, you cant even do that.

There must be a way to bring notifications to the sight of the user or admin just like now, but they should be presented in a more manageable and neat manner. They definitely should not be out of the way like a notification bar where you have to click that dropdown or hover on something to see any notifications.

Push notification like functionality as some proposed is not bad actually. Its commonly accepted across most of the web, and users are used to it. It seems to work pretty fine as well.

[asadkn]

While we're on it, another related system on the wishlist would be a logging system with categories like errors, warnings and informational notices.

Many plugin error messages that could go in a Logging System rather than a lengthy notification message - there can be a notification about new errors, but notices wouldn't need one.

[swissspidy]

#51935 was marked as a duplicate.