Admin notices in WordPress have been what they are today for… how many years? If I recall correctly, the current types of notices were introduced somewhere during the 3.x release cycle, although their legacy versions (anyone remember .update-nag?) have been around for much longer.
Meanwhile, there is a core project looking into improving the API around admin notices (or ‘notifications’, see #feature-notifications, bless you, Jonathan Bossenger!). However, as with the admin menu, I’m going to outline a few ideas of my own here for the fun of it.
No house rules
With admin notices as they are, WordPress provides an open API for plugin and theme developers to message users in the ‘shared apartment’ that is their dashboard, and it has not enforced any house rules whatsoever up to today.
This has lead to the most amazing chaos. Free and paid plugins try to upsell the shit out of what is supposed to be a ‘success’ message; more sophisticated (or well funded) players such as Jetpack, or my favourite Block Lab brand their notices nicely, with a logo and extra CSS – which is great on the one hand, because users can identify which plugin is trying to get their attention, but it also can’t be the end of it.
WordPress must start to take responsibility for the coherence of its own UX, and currently that is still not happening.
Common patterns
A common UI symbol for user notifications is the bell icon. Notably, Dashicons don’t have one but material.io does.
The bell icon would often indicate a count of pending notifications and offer a way to access them, by opening a submenu, or by taking the user to an extra list view.
Recreating this common pattern in the WordPress toolbar seems quite straightforward, and it has been done (with or without the bell icon but otherwise same-ish) by plugins like Yoast SEO, Webcraftic Disable Admin Notices Individually (what’s with the name there?), WP Notification Center, and a bunch of others.
So is that it? Install a plugin, done?
Hardly. An integral component of WordPress’ UX like user notifications definitely can’t be dismissed as plugin territory. And it isn’t, as the core project mentioned above illustrates so well.
So what can we do? What should we be doing?
Ideas
Prioritisation
If we’re going to be conscious about people’s cognitive load, prioritising notifications for them seems low hanging fruit in order to create a smoother admin experience.
If only it were that smooth. I haven’t looked into it yet but I have a hunch that due to the complete absence of any requirements for using one of the admin_notices hooks in WordPress, it could turn out difficult to retrieve any sort of data to base any prioritisation on. (Other than the four CSS classes notice-error, notice-warning, notice-success, and notice-info, but their use is completely arbitrary.)
However, if it was possible to determine who is sending a notice, I’d like to prioritise roughly like the following:
- Errors
- Core updates
- Third-party updates (plugins/themes)
- Everything else
- Warning
- Success
- Info
Access
The aforementioned bell icon in the toolbar, yes, plus a submenu with a shortened excerpt and ‘more’ link for each notice, plus a dedicated dashboard widget (perhaps full-width) where all notices are listed according to their determined priority.
Yoast SEO has it’s own plugin dashboard where it pretty much does exactly that, although there weren’t any notices when I took my screenshot:
Actions
For a long time, I’ve only thought about admin notices in terms of what they do to me – warn, inform, market, annoy – but wouldn’t it be cool if you could actually do something with them?
- ⏰ Like, snooze a notices to show up again after some time?
- 🙈 Or hide it for your eyes but allow it to appear for other users if it wants to?
- 🗑 Or trash it for everyone forever?
I suppose coding these types of actions is a tad above my pay grade (and certainly way beyond my javaScript fluency), but I’d still like to throw the idea out here for feedback.
Ideas?
Your turn! 🔥 How does all of this sound? What ideas do you have to improve admin notices in WordPress?
Comments are open as usual, und wenn du diesen Blog bisher auf Deutsch gelesen hast, fühl’ dich frei, auf Deutsch zu kommentieren!
You are also more than welcome to subscribe to this blog and get access to occasional private lab notes as well as the GitHub repo where I store the code I’m currently working on.
Hi Caspar,
great ideas all around! Can we please have this tomorrow? 😉
One small additional idea: It’d be great to have control regarding what user roles get to see which notifications – maybe along the lines of the prioritization scheme you suggested.
And, venturing further out: What about giving site admins the opportunity to send their own notifications to other users right through that notification center you proposed? Well, this does not have to be in core, I guess…
Cheers
Alex
Thanks for this, Alex! I’m going to explore the user role idea, however, just to be very clear: my aim is to create a better handling of admin notices based on the existing API. The API itself is worked on in the core project mentioned in the post, and as much as I appreciate and applaud that effort, I don’t plan to get involved there.
Can you provide an example for a use case where a site admin would want to send (i.e. display) a notification to other users? It sounds interesting but I’m not sure I’m getting the idea of what problem it would help solving. 🙂 I agree it sounds like plugin territory, however, a plugin is what I’ll be working on. So definitely feel free to throw around all the ideas here, that’s what this post is for! 🚀
You’re very welcome!
Some examples for sending a notification to other users from the top of my head: “Please upload an avatar image and fill in your biographical info (that is going to be displayed below your post and in your author archive)!”
OR
“Just a reminder: The website will be down for a few hours on Monday for maintenance…”
OR
“Please change your password, it’s weak/the site has been compromised/you haven’t changed in five years”
Does that make sense?
Thanks, it does make the use case more clear. I feel like these specific examples would be better off as email notifications and/or as part of a general user onboarding process. Let’s see how it all pans out, though. 🙂
Just FYI: The bell icon is already requested 3 times on the github repo from Dashicons:
https://github.com/WordPress/dashicons/issues?q=is%3Aissue+is%3Aopen+bell
The first one with a link to the core ticket about the notification center:
https://github.com/WordPress/dashicons/issues/281
Not sure when and where I mentioned it first, but besides in the WP backend, such notifications should go by choice also/just to a centralized stream which can be used to be
– captured in a proper logging system (syslog, ELK stack, graylog, …)
– trigger additional actions (mail, SMS, mobile phone notification, …)
Esp. the first would enable to gather such data from multiple instances and help identify patterns (think of security issues).
Just my admin thoughts …
Hmm, interesting… Sounds like REST API support for notifications which obviously would require authentication first. Probably beyond the MVP I’m currently looking at, but deffo worth keeping an eye on for future iterations, or the core project.