Over the past few weeks I’ve seen a frustrating trend. Increasingly, WordPress plugins have decided they see fit to add admin notices (those “flash message”-style nags at the top of your dashboard) and about pages (like the ones you see after upgrading WordPress itself)… without making them skippable via code.
You might be asking “why’s that a problem?” And sure, it seems innocuous enough.
The problem is that these messages often make assumptions about user behaviour that just aren’t always true. In the process, they frustrate, confuse, and ultimately hurt user experiences.
The Notice and Pointer Problem
The first is the notice problem. Admin notices and feature pointers are a great way to share information with users.
Unfortunately, they also often contain information that’s irrelevant to certain subsets of users. For example, if you run an WooCommerce store that has a large group of salespeople with account access, so they can manually collect and process orders, you might be surprised to find that all those users get to see WooCommerce’s “out of date template” notice.
Or if you run a large site for a magazine, you may not realise that your editors get to see all the notifications from your SEO plugin, asking you about your information sharing preferences, or offering to guide you through a tutorial.
That these notices exist at all is one thing. That they’re not programatically suppressible? That’s another issue entirely. Often, an easy fix can be provided in a single line of code – adding a simple apply_filters call is usually more than enough for the job. But plugin developers are routinely blind to alternate use-cases, and, when informed, usually ignore them as just a small subset of users who aren’t worth the trouble.
The About Screen Problem
The other issue is with About screens: the screenshot-laden information pages that let you know you’ve updated successfully.
On their own these pages are a nice way to share important information with users. But, again, they ignore the fact that users might be working with plugins in unconventional ways.
For example, let’s assume you use Composer to handle plugin updates, and you’ve just updated the WordPress SEO plugin. You might assume that—having tested your site in dev and staging environments—you can just deploy your site to production, let Composer run the plugin updates, and move on with your life. In fact, you’d be wrong. Not only do you need to run the updates, but then you need to log in and suffer through WordPress SEO’s update screen (and, of course, any post-install notices… see above).
And if you’ve also just updated WooCommerce? Good luck—now you’ve got two about screens to trigger.
But what if you don’t? Well, the good news is that your users might not see the about screens—but they might not see anything else either. One large plugin in particular (which shall remain nameless) sets its “you’ve seen the about screen” variable after displaying the about screen. The problem? On every pageload, if it doesn’t detect that variable is set, it will try redirecting you to the about screen. Fine, except that the About screen itself is only visible to certain user roles. If you’re just an “author” or “contributor” trying to view a page in the dashboard, good luck. Until an admin comes in, visits the About screen, and triggers that variable, you’re sunk. The large plugin I referenced here has fixed the problem — big props to their team for being quick to notice and fix it. I still think the point is valid, and I’m sure there are other plugins with similar bugs!
This problem is more common than you might think. Again, it comes down to this: plugin developers are making assumptions about how their plugins are used (and how plugins are used in general) that aren’t always true. Instead of providing easy fixes, they’re ignoring the problem and making the experience more frustrating for advanced users.
I’m sick of it, and I hope you are too. Next time you see it, politely say something to the plugin author on Twitter, GitHub, the WordPress support forums—wherever you can get their attention—and share this post with them too.
Together, we can reclaim the user experience!