He’s here to talk about WordPress notifications and how they are managed.
If you’ve been using WordPress for any length of time, then you’ll have seen notifications appear in the admin area of your site. These messages can be useful, they might tell you that something needs to be updated, or that something was successfully saved.
There’s also a chance that you’ve seen notifications for other purposes as well. Perhaps a plugin would like you to notice their upgrade offer, or that they have a sale on.
All these notifications fall into the same place, and when multiple of them arise at the same time, the admin area can become cluttered and confusing, especially for novice users.
It’s possible that you don’t mind these notifications, but it seems that many people do, and feel that they’re being overused. They would prefer not to see so many notifications, and if notifications are to appear, that there are limitations on what they can show, and how large they can be.
In the podcast Jonathan talks about his concerns regarding WordPress notifications, and the fact that there’s no system in place to limit what they can display and for what purpose.
He’s currently working on WP Notify, which is a project aiming to put a notifications area in to your WordPress website. All notifications would appear in this area, and there would be constraints about what could, and could not, be displayed there.
It’s not about removing notifications completely, more about putting them in a defined place, like you might find on your mobile phone.
We talk about how notifications are currently created and how there are few limits on what they can do. How overuse of notifications can be a cause for concern, and how Jonathan’s solution aims to add a unified system to WordPress which would put the user in control of the notifications.
[00:00:00] Nathan Wrigley: Welcome to the Jukebox podcast from WP Tavern. My name is Nathan Wrigley. Jukebox is a podcast which is dedicated to all things WordPress. The people, the events, the plugins, the blocks, the themes, and in this case, the way that we manage announcements in the WordPress admin. If you’d like to subscribe to the podcast, you can do that by searching for WP Tavern in your podcast player of choice, or by going to WP Tavern dot com forward slash feed forward slash podcast. And you can copy that URL into most podcast players.
I’d really like to hear from anyone out there who would like to come on the podcast and talk about whatever it is that you do with WordPress. It might be that you’re a developer, a WordCamp organizer contributor, a designer. Honestly, if it’s about WordPress, I’m keen to hear from you, and hopefully get you on the show. Head over to WP Tavern dot com forward slash contact forward slash jukebox. And you use the contact form there.
So on the podcast today, we have Jonathan Bossenger. He’s here to talk about WordPress notifications and how they are managed. If you’ve been using WordPress for any length of time, then you’ll have seen notifications appear in the admin area of your site. These messages can be useful. They might tell you something needs to be updated. Or that something was successfully saved. There’s also a chance that you’ve seen notifications for other purposes as well. Perhaps a plugin would like you to notice their upgrade offer, or that they have a sale on. All these notifications fall into the same place, and when multiple of them arise at the same time, the admin area can become cluttered and confusing, especially for novice users.
It’s possible that you don’t mind these notifications, but it seems that many people do, and feel that they’re being overused. They would prefer not to see so many notifications. And if notifications are to appear, that there are limitations on what they can show, and how large they can be.
In the podcast, Jonathan talks about his concerns regarding WordPress notifications and the fact that there’s no system in place to limit what they can display, and for what purpose. He’s currently working on WP Notify, which is a project aiming to put a notifications area into your WordPress website. All notifications would appear in this area and there would be constraints about what you could and could not display there. It’s not about removing notifications completely, more about putting them in a defined place. Like you might find on your mobile phone. We talk about how notifications are currently created and how there are a few limits on what they can do. How over use of notifications can be a cause for concern, and how Jonathan’s solution aims to add a unified system to WordPress, which would put the user in control of the notifications.
If you’re interested in finding out more, you can find all the links in the show notes over at WP Tavern dot com forward slash podcast, and look for episode number 16. And so without further delay, I bring you Jonathan Bossenger.
I am joined on the podcast today by Jonathan Bassinger. Hello Jonathan?
[00:04:01] Jonathan Bossenger: Hello, Nathan, how are you?
[00:04:02] Nathan Wrigley: I’m very well. Jonathan is joining us today to talk about WordPress notifications. Now I could introduce this subject and say all sorts of things off the bat. My thoughts on things, but it would probably muddy the water.
So Jonathan, it’s over to you. Tell us about WordPress notifications and the issues that you see, and then we’ll get into the weeds and discuss the finer points.
[00:04:26] Jonathan Bossenger: Sure. No problem. So, before I start, I’d like to mention that my problems with WordPress notifications come from both the point of view of a contributor to WordPress, and also a person who makes money off WordPress.
So some of the first products that I created for WordPress were plugins and part of those plugins required me to give some kind of feedback to the user if they had saved settings, or if there was some change that they had to make or whatever the case may be. And then from there I moved on to building plugins for clients or doing custom work.
And the point that I noticed that there was a problem as it were with notifications was when I used to log into client’s websites, as a new administrator and I was flooded with, and I’m sure we’ve all seen the screenshots of this on social media, but flooded with notifications from this plugin that has just been updated to, this plugin has an upgrade, a paid upgrade to this plugin is just on this over here. This theme has got this, that, and the next thing. And I’m reading half a page, sometimes a full page, of notifications before I can even start working with the dashboard. The, in big inverted air-quotes, problem with notifications is the fact that there is no official centralized way to register and present notifications to the user other than using admin notices.
So if you’re a developer of a plugin or developer of a theme, there is the admin notices hook that you can hook into, but you can pretty much hook any HTML into that hook. So the documentation gives you some guidelines as to status classes that you can use for your div to display it in red or green as a success or an error, but you have full leeway to build anything you want there.
So you could build a full page notification. You could build a tiny notification. They are guidelines in the plugin and theme handbooks that gives you guidelines of what you should do and what you should stick to. But there’s nothing to force you down that path. And with notifications. These admin notices traditionally should be being used to give the user feedback.
So I’ve created a post, I hit save, and I need to see a message that says, yay, my post has been saved. This admin notices functionality is now being, and I don’t want to use the word abused, so I’m not going to, but overused by folks who are trying to give the user some other form of notification, some other piece of messaging, some other piece of information.
[00:07:01] Nathan Wrigley: So the problem is a historical one in that WordPress core has the capacity to pop-up things, which presumably the intention was that anybody who wished to use these would have something legitimate to say. As you say, post has been saved, something has been deleted and so on, and there are no constraints around really what you can put in there.
It could be enormous. It could be very wordy. It could contain images, animated gifts, and so on. And there’s no real constraints about the way that it can be implemented. And I think for the most experienced users of WordPress, that is to say somebody that’s dabbling in there everyday, you kind of become a little bit numb to it and you just log into WordPress and immediately dismiss them all, click whatever option is available to make them go away.
But there they were and clients, people less experienced, I think the problem might reside in the fact that they might cause some sort of alarm, you know, it might be, oh, well, why is that appearing? There’s probably some kind of upgrade that I should have had. Why haven’t I got the upgrade and so on and so forth.
So it’s a historical problem. Do you know, roughly speaking, how far do we need to rewind the clock before the, in inverted commas, over use of these began. When was the first time you saw this being used for ulterior motives?
[00:08:23] Jonathan Bossenger: So it’s difficult for me to say that 100%, because I’ve only been very active in the WordPress space since around 2015.
I use WordPress as a blogging platform from about 2009, but that’s, as far as it went, I had a blog. I had maybe a security plugin installed, maybe a forms plugin, but I was just using it for blogging purposes. So it was only in 2015, 2016 that I started building for WordPress that I started seeing, personally seeing these issues.
I would say that since it’s definitely gotten worse. There was a stage in about 2017, 2018 that I started seeing it more and more and more. The thing that you mentioned earlier about, you know, as an experienced user of WordPress, we see these notifications. We know how to dismiss them. We know how to click. The concern that I always have is never mind somebody who’s a client, nevermind somebody who is a business owner. Let’s just look at somebody who wants to blog with WordPress or build themselves as simple website with WordPress. What is the user story gonna look like? They’re going to either through their hosting company, they’re going to install WordPress through some kind of one-click install.
Maybe they’re using a managed hosting environment, which does it all for you. Maybe they’re technically savvy enough to download the zip file and upload it to a server. They’re going to install it. They’re going to start using it. They’re going to need to have, maybe a contact form. They’re going to need to maybe have some kind of plug-in functionality.
They’re going to start looking for plugins to install things. Then as you say, suddenly, they’re going to see these messages and these messages are going to be jumping out at them. And these messages are different sizes and different shapes, and it just creates this very jagged, jarring experience for the new user.
Now we can’t blame WordPress because WordPress Core itself is using admin notices correctly. We can’t really blame plugin developers and theme developers because, they’re trying to get this information to the user, with a system that’s not designed for it. So the problem is not one single entity’s problem.
The problem is all of our problems. That’s the kind of the way I look at it. We all need to work together with WordPress Core, with plugin developers, with team developers and find a better way to register these, non, I don’t like to call them notifications because to me a notification is… your post has been saved successfully, or you have created a new post.
So let’s call them announcements just for the sake of this podcast. We need to find a way to register these announcements that are outside of the scope of the day-to-day use of WordPress and present them to the user in a way that is clean and nice, and doesn’t, doesn’t disturb them using WordPress on a day to day, but is accessible and they can, and they can see the information that they see in a, in a way that is formalised.
[00:11:23] Nathan Wrigley: Do you think then the notifications that we have at the moment, which can consume any HTML, let’s imagine that nothing additional were to be added into WordPress, and we’ll get on to your project a little bit later, but if we were simply to have it that just text could go in there and that text could be limited, say to a certain string length, I don’t know, 30 characters or something.
Would that potentially solve the problem in your eyes? Or are there situations where anyone may need more than that, because obviously if we just limited it to text, we could still put all sorts of interesting and perhaps unwanted messages in there.
[00:11:58] Jonathan Bossenger: So I speak to you now as a developer. And let me tell you that if you put some kind of limitation down, some clever developer will come along and figure out how to work around this. As it is, you know, the admin, the admin notice the system as it is, is kind of restrictive, but the only way that you could physically restrict it, is if you, every time a new plugin submission comes in, you had somebody physically inspecting every single instance of the notification system and making sure that this person was following the guidelines. And I’m sure we all remember a number of years ago that the theme team was kind of coming under fire because they were taking a long time to review themes.
And that was because everything was still being done manually. The plugging team is a small number of people due to the security that’s involved in getting plugin submitted and what plugins have to deal with. So expecting a team of people to physically inspect every single admin notice that comes through. I mean, sure, you could probably automate it in some way, but we all know that developers are crafty. We all know that developers, I mean, that’s part of what being developed is, finding ways to solve difficult problems. So you put a constraint down in front of a developer on an open source project, you know, code that is publicly available.
And say, right, we’re now stopping you from doing X. They’re going to find a way. So to me it’s a little bit less of the stick and more of the carrot. We need to provide a way that gives developers the ability specifically, and I speak now as somebody who failed dismally to try and start a plugin business.
But one of the biggest things that I struggled with was marketing. How do I market my paid products off of my free ones? You know, WordPress dot org plugin repository and the theme repository is, we all know this, is one of the top places to get yourself known, put out a free product, get customers into the funnel, but then how do you turn them into paying customers?
We know we have a problem with sponsorship of open source products. It’s spoken about all the time. How do we, how do we balance the needs of the open source project and the people that are building plugins for it and how do we balance the need for them to market to their customers, to, to bring, you know, free customers into the paying funnel, in a way that isn’t disruptive to regular users of WordPress?
And in my opinion, the only way that we can do that is by creating something that is well-defined in terms of, this is how you do things, this is how you register things. But it’s not, it’s not being thrown into the user’s face when they want to see that information. To me, that’s the only way that, that we do it in
[00:14:34] Nathan Wrigley: In terms of describing problematic notifications or announcements or whatever term we’d like to use. There must be a point where in your own mind it strays from being, well, that’s totally acceptable. Everybody ought to be seeing that. And then there’s some kind of gray area, no man’s land where that feels a bit shady, I’m not quite sure what to make of that. And then presumably there are examples which you could mention where it’s clearly something that you would strongly urge people not to do.
Do you want to just describe examples of maybe things which you think are totally legitimate and then also some examples, we should probably not use any names, examples where you’ve seen things that you think actually, I think that you’re pushing a little bit too hard then.
[00:15:19] Jonathan Bossenger: Sure. I can definitely give some examples. I won’t give names because that’s just not something I want to start doing right now, but I can give you some personal examples of notifications that I’ve dealt with.
For those of you who don’t know, I used to be a developer for a company called Castos. We managed a podcasting plugin for WordPress. And at that stage, I was very focused on making sure that our notifications were not disruptive to our users or any other user of the WordPress site that happened to have the plugin installed.
So as an example, our one, let’s call it onboarding form to try and get customers to sign up for our podcast hosting service, was only available on the plugin settings page. So only when you went to the plugin settings on the right-hand side, there was a nice little sidebar with a little graphic to say, hey, if you’re enjoying the plugin, but you’re looking for a way to host your files, here’s a form you can fill in. We’ll give you a 10% discount to try it out. To me, that’s not disruptive, because the user can still use their settings. They can still make changes. They’re not seeing this notification at the top of the screen in their face every time, it’s off to the right. It’s there, it’s visible, but it’s not disruptive.
The other thing we were very focused on is when we do update messages. So when the plugin gets updated, if there’s some kind of process that needs to be run, maybe there’s a database upgrade that needs to be run. That to me makes sense as a, let’s call it a site-wide notice, or a more general admin notice, but we kept them very limited. Maybe one sentence. We didn’t use the red color or the green color, we just kept it gray and just said, hey, we noticed you’ve recently updated. Here’s a link to click through to make the changes. But specific things related to the plugin. So if we would, I can actually give you a perfect example. There were some changes in the Apple podcast categories and Apple podcasting was changing how the categories worked.
And so what we did was, if you loaded up the plugin and you updated the plugin, you saw no messages, you saw no notifications, you could carry on doing your things, because it would all just work. When you went to the page that allows you to control your categories, there we showed you a specific message to say, by the way, did you know Apple have recently updated their categories, your old categories are still going to work, but it would be a good idea to change your categories on this page. And then as soon as the person saved that page, that notification goes away. So to me, that’s an example of how, as a developer, you can sort of think of, you know, how do I get free users onto the paid version?
You know, how do I display relevant information to the user? Some of the bad things that I’ve seen, there are a couple of popular page builders that I won’t name. I think I might’ve tweeted about it. So maybe if you go back in my feed, you might find. With the Block Editor coming out. When you load up a new post, you have this option to select, and the only reason I know this is because for various reasons, I have both of these page builders on my site because I’ve done some demo content with them for tutorials in the past. When I create a new post, I get this big, these two big buttons saying, do you want to use this page builder? Do you want to use that page builder? Or do you want to use the default page builder. When I select, and this might’ve changed, cause it’s been a while since I’ve done this, but when I select default page builder, at the very top of the Block Editor, there are now these two big buttons, saying switch back to the other page builders, switch back to the second page builder that you have installed. To me, that’s kind of pushing it, because I’ve already chosen that I want to use the default editor. Now to keep bugging me. And the other thing that I hated about those buttons were, they both had their own colour schemes. So they were very jarring in the block editor. Cause I keep my WordPress on a very clean theme. So now I’ve got these big, bold colors at the top of my editing area. And they were both using separate fonts as well. They weren’t using standard WordPress dashboard fonts.
So to me, that was very much in my face and almost getting to a point where I wanted to stop using their products because they were being so vibrant about that. There was another example recently where somebody had, I can’t remember the details but, I think it was, I think it was The Tavern site, where somebody had added, I think it was a signup or an upgrade or something button as a HTML field in the settings sidebar, which there was quite a bit of conversation around. To me again, that’s the problem, you know, where you are using space that should be used for one purpose, you know, control or settings or whatever. And now you’re taking over that space to put in your notifications or your upgrades or upsells. Those to me are the kind of the problematic areas.
[00:19:53] Nathan Wrigley: It sounds to me as if you’re demarcating in your own head at least, the pages, the places on a website which have legitimate use. So the general admin, if you just click the dashboard link and you’re into WordPress and you’re not in any particular setting for any particular plugin. You feel that those ought to be limited to possibly text and just very informational in nature and something which is more or less critical, something which you must take care of because otherwise. Right. Okay. So that’s what belongs there. But if you were to go into the settings page of any particular plugin, that’s more of a free for all.
Do you feel that there’s any constraints there or are you, you mentioned that for Castos, you have a sidebar. I remember seeing that have actually used that before. And there it was, and it did genuinely feel as if that was the right place for it, because I was already in the settings. I was thinking that I was going to be interacting in some way with Castos, and so the upgrade felt like an appropriate place. Any limitations on that? Are we allowed to go full page in there or should there be some constraints around that?
[00:21:03] Jonathan Bossenger: Well, for me, it’s always about the user experience. So, I feel like a lot of developers, they understand the the balance between creating a good user experience and interacting with your users. The company that I work for now, Delicious Brains, it was about a year ago now released version two of WP Migrate DB Pro with a new user interface, and the notifications that come up when you log into the plugin page and the plugin settings, they’re just so nice and clean and they don’t overwhelm you.
They are useful information, you know. Even if you install the free plugin, there’s a little bit of a thing at the top, but it doesn’t bombard you. So in my opinion, yes, if you’re building a product for WordPress today, and you are forced to use admin notices. You should think about how you’re registering these things.
One of the, one of the things that I spent the most time on when we were releasing updates to the plugin at Castos was triggering certain notifications only at certain points. So, when there was an upgrade from 1.2 to 1.3, then trigger a certain notification. But then when the user dismisses that notification save the fact that they’ve dismissed it and don’t show it again.
So we actually spent time thinking about this, because there’s nothing worse and this actually happened. So the reason we spend the time is because something happened. We launched an update, it included an upgrade step that the user had to action. But we didn’t have any kind of check in place. So every single time a new user installed the plugin, they got this upgrade.
Now that’s fine in the scope of one plugin. Think about let’s say 15 popular plugins do that. Your user comes along and likes those plugins and installs those plugins and suddenly has 15 notifications in their main dashboard they have to deal with. If those were separated, off and in the settings for each plugin, then it would limit that amount of overwhelm. And they would only see that notification when they’re dealing with those settings. So I do believe that putting plugins specific notifications in certain places is a better way. The problem you have with that though, is that the other reason developers use notifications is to push users into that funnel.
And I am not standing here today saying we shouldn’t allow developers to do that. I strongly support people who are working on open source products, being able to be given the ability to earn income, to be able to be given the ability to turn non-paying customers, into paying customers. But we need to do it in such a way that it doesn’t overwhelm the users.
It doesn’t frustrate them. We should be making it a, we should be making the process of signing up for our product as fun and pleasant as it is using WordPress. And if we are bombarding our customers with notifications from day one when, and that’s why I say we, we have to find a better way to do this. We can take what we currently have and try and patch it up because what we currently have has been overused for so long and is already.
So what’s the word I want to use? I don’t want to use broken because it means that it was working before, but it’s been again, I don’t want to say misused because that sounds so negative. Used incorrectly, used for the wrong reasons, because the reasons that exist, the reasons that exist today, for people to use these notifications are ten times more, what they were, you know, five, ten years ago.
[00:24:31] Nathan Wrigley: Some of the examples that I’m going to give here come into my head when I’m thinking about advertising and overwhelm of advertising and misuse. And so a good example would be, if you go to a news site, I can think of an example of a local news site to me. And I go there and I find it incredibly difficult to use that website because they’ve taken the path of advertising and there are adverts, splattered everywhere so much so that it’s almost impossible to find the actual content. The content is split up into small paragraphs and they are punctuated by advertisements. And I feel that’s probably the argument that you’re making is that if we clutter the UI, if we allow the UI to be cluttered by things which people didn’t necessarily wish or need to see, then we are making the experience poorer. And I go to that website. I find it quite difficult to stay there. It may be that I need the content so badly that I’ll persevere, but I’ve got this instinctive reaction to get away. And we don’t wish people to enter WordPress, have an initial experience which is poor and continually frustrated.
However, on the flip side, there’s obviously some sort of commercial need, as you’ve described. People would wish to turn their free projects into paid projects and have some subscribers. And I guess plugin developers would point to the fact that in a normal situation, you would get a product and probably give up your email address in return for that. But on the WordPress side, if they come to the repo and download your free plugin, you have no access to that. You haven’t managed to get them into a funnel in any way, shape or form. They’re just consuming your product, and that’s the end of the road. They may use it forever, and I have no idea who you are or any other product that you may offer.
And in fact, they may well miss out on something which they genuinely, legitimately needed. And so the developers would argue, I guess, that we need some way to do this. We’re going to try to keep it under control, but I suppose the problem is human nature. Is that given the fact that the area is open to any HTML as you described, it just starts to get overused. The boundaries get pushed, things that were acceptable yesterday are going to be pushed further. And then what’s acceptable in a year’s time may get pushed further. And your position, I suppose, is we just want to reign this in a little bit.
Another thing which comes to mind is commercial television. On the TV side of things, probably radio as well, we’ve gotten quite used to the fact that our content will be punctuated with adverts. We’ve walked across the mental bridge that, I cannot watch this program unless it is paid for by advertising. So every 15 minutes or so I will cope. I’ll sit there and I’ll consume the adverts or I’ll go and make a cup of coffee.
I guess making coffee is the equivalent of dismissing something in WordPress, but that’s just part of life. So I do wonder where most people will sit on this. They realize that there’s a commercial need for these things to exist. And so they cope with it, but it may not be ideal.
[00:27:37] Jonathan Bossenger: And that’s one of the reasons why we need something new because I am, I’m not, I’m not saying that we should punish all plugin developers because they want to make a living.
I’m not just saying that. As I said earlier, I failed at building a plugin business because I didn’t know how to market myself properly. I didn’t know how to turn plugins that I built for free into a paid product and how to convert customers. And I kind of think there are others that have done it successfully and there are those that haven’t. So I’m here just saying, you know, developers shouldn’t be paid for their work.
I a hundred percent agree that they should be paid for their work. And I don’t believe, as I said, I don’t believe the problem is the plugin developers. Because if you think about it, let’s go back to the example I had of, you know, Seriously Simple Podcasting. We release an update, so we show that update to the user on the dashboard.
When I’m testing that, I’m just seeing that one notification, but when the user has it on their website, they’re seeing that notification plus however many other useful, important notifications are being pushed out by other plugins. You might be in a situation, and I have seen this before, where you’ve got an admin dashboard with ten important notifications.
Because there’s been a WordPress update. So that means what plugin X had to make a change in how they do something, so you need to run an upgrade. Plugin Y made an upgrade change to their tables, so you need to run that. This plugin did this. And those are all legitimate notifications. Now, first of all, the user doesn’t know what’s more important and what is primary? You know, they’re all just the same color. They’re all just red. So it’s all just a stress factor. So number one, how do we give plugin developers the option to say, hey, this is a minor update, so you should do this, but not the end of the world. Like with the categories, the example I gave earlier.
How do we give another plugin developer the option to say, this is rather important. If you don’t do this, something could go wrong with your site. Then how do we say, okay, this is a really low end thing. This is just, you know, okay, the plugin’s been updated and make a note of this change and you can read it later if you want to. We have no way of doing that right now. We have no way of giving plugin developers, theme developers, an option to create a status level and have a certain type of message that the user can go through.
I mean, we live in a world where our mobile phones have amazing notification systems. And I can control what notifications I want to read. So I have a Facebook account purely to interact with the folks on some of the WordPress groups that I’m in. But I switched those notifications off, because none of those notifications are primarily important to me. But I certainly switched the notifications to the messaging app that I have with my wife, because those notifications that are important to me. I allow my banking notifications to come through.
If my banking app sends me advertising, I’m okay with that because I accept the fact that they’re a business. They need to make money. I’m already giving them some of my money every month with banking fees and all of that, but they want to make more, fine, I accept that. Because the benefits of receiving the SMS to tell me that my credit card has been cloned, do I want to cancel it, overrides my distaste by advertising, but that, that exists as a concept. WordPress doesn’t have that place where I, as a user can choose, even simply which notifications I want to see and which I don’t. So if I say I’m using SEO plugin X, whatever the name is, and I want to see the notifications because my SEO is important.
Then I will probably accept any upsells or upgrade notifications and I will either read them or just mark them as read, but I will be happy to receive them because the rest of the information they’re giving me to keep my SEO on board to make sure my meta tags are right, is my featured image working, is my social media image working? All those things that are important to me, I will accept their messaging. And I believe that in doing something like that, where there is a specific, formalized way of doing things. If I see SEO plugin X is using that system, giving me the user the control to receive the messaging, and SEO plug in Z is not, I personally will have more of a inkling to use X, because X is putting the control of notifications back in my hands, which I respect and anybody who’s bombarding me, I’ll have less of an inkling to want to use their product.
[00:32:02] Nathan Wrigley: I think the mobile phone example is really excellent because we can probably all identify with that. There’s usually some kind of drop down notification held and little icons appear to alert you to the fact that there’s something there to read, if you wish. And then of course you scroll down and you can very quickly dismiss them. But then they are, there in a confined area. And that area is familiar to you as the place where notifications are. It can be totally ignored. You could come back to it in five days time, safe in the knowledge that they will be there still.
And were are they important? Well, that’s on you, you knew they were there and you decided to ignore them. And then further to that, I’ve seen a trend recently within mobile phone apps to have notification settings within the apps. So you can go in and say to the banking app, look, I’m very happy to receive the critical updates about security breaches, but I’d probably rather not have the, I don’t know, here’s our latest mortgage deal kind of notifications.
The premise there must be that the banking app realizes that there is some balance of trust to be gained. And if you keep pushing the relevant to some, but irrelevant to most, notifications out at some point, the trust scale tips, and you become tired of this app and you may uninstall it. Now, in the case of banking, it maybe that’s a step too far, you’te kind of wedded to that, but you can imagine something where there are three or four rivals and you’re trying to weigh up, which one’s better for you. The overwhelm of notifications may just be the thing that tips you against it.
So let’s move into the project that you’ve got, WP Notify, because that feels to me as if you’re trying to replicate the mobile phone model. In other words, everything is tucked away in a particular area. Do you want to describe this enterprise just in broad brush strokes, and then we’ll talk about specifically what it does, and also how you may get involved in where the project’s at right now.
[00:34:00] Jonathan Bossenger: Sure. So, the goal of WP Notify, as we originally defined in the initial post. And before I get into that, I just want to give a shout out to, sorry dude, I can’t pronounce your surname, but he was the guy who came up with a proposal originally. He tweeted that he didn’t have time to try and move it forward. So I contacted him and I picked it up from there. But his original proposal was very simply, we need a better notification system for WordPress. We can’t take what we currently have, which has been overused, which is limited, and it’s limited in its technology, but unlimited in what people can do with it, and that’s the problem. We can’t take that and make that better. We need something brand new. And then once we have something brand new, that works, that makes sense that balances the needs of the user and the open source project. And the developers who are trying to earn money from their project. Once we have something like that, then it’s easier to control, to tame these notifications.
Then it’s easier to put guidelines in place. And then when the developers build their plugins, they are almost forced because when they register a notice, they can only register three fields. Those are the only three fields that are allowed. They can put whatever texts they wanted them, but those are the three fields. They can’t go overboard. They can’t make it bigger. They have a specific format, and the way they look. They’re allowed to add certain things, but not other things. That’s just where we’re at. So that’s what an WP Notify is. It’s a project that we kicked off now in 2019. So it’ll be going on for three years in August.
It’s an open source, what’s known as a feature plugin. So a feature plugin is something that is, I want to say, not sponsored by, has been accepted by WordPress Core in general as a good idea. We have an official GitHub repository on the WordPress organization and we have a Slack channel, and we are slowly trying to build this better notification system for WordPress.
[00:35:57] Nathan Wrigley: So imagine that I’ve enabled this, I’ve downloaded it and activated it. I will, by the way, link to the GitHub repository and various other things.
[00:36:07] Jonathan Bossenger: I wouldn’t install and activate it just yet, because it’s not something that you can actually use yet.
[00:36:12] Nathan Wrigley: So rewind. I haven’t installed it. I haven’t activated it. None of that stuff has happened. What does it look like? What will it present me with? As a user if I’m looking at the screen, what will I be seeing?
[00:36:24] Jonathan Bossenger: Okay. So it’s difficult to obviously, you know, describe this in a podcast environment, but the idea is very similar to what we were chatting about when we spoke about the Android or the iOS, the mobile phone notification system.
The idea is to have some kind of icon, not a jumping blinging one, but some kind of icon, be it a bell or something. I think in the design that is. That shows some kind of user interface messaging to say, you have new notifications. The user is then able to click on that. They’re able to see the notifications come up, they’re able to scan through, see which ones are important to them, see which ones aren’t. Read the ones that are dismissed, the ones that aren’t. The other idea as we spoke about earlier is to give the user the control over who they want to receive notifications from. So if they keep getting a bunch of notifications from plugin X that are never useful to them, they can turn it off if they want to.
If they receive notifications from plugin X that are useful for them, they leave them on. It is up to the user to then choose to either read or dismiss those notifications. We don’t want to go as far as saying, we’re only going to show notifications that are state changes or update changes.
We want the plugin developers to be able to advertise their products. We want the theme developers and the product developers to be able to say, hey, we’ve got a black Friday special on. We’ve got a discount code running, whatever. We want those things, but we want them in a way that the user has the control. So there are some designs, as you can see, if you go through to the GitHub repository on the read me page, we have links to our design documents.
We have links to our requirements documents. We spent about, due to the nature of open source, we spent probably about a year and a half just working on what are the requirements version one? And that went through a lot of process of feedback and revisions. Then we worked on design and that went through feedback and revisions as well.
Now we’re starting at the sort of initial implementation phase and our first goal, our first short term goal right now is to take those designs, and actually implement them purely as HTML so that you, Nathan, or anybody else who is interested, could install the plugin and just see what we’re planning. Just to get a visual idea of what this could look like.
The goal after that is to then get feedback from the community. From the plugin developers, from the theme developers, from the users, from the open source community. And say, does this solve the problem we’re trying to solve? If it does, then we can start looking at how do we implement this?
[00:38:46] Nathan Wrigley: How has the project been received? Have you had a lot of engagement? Has it been a difficult struggle trying to get people involved? What’s your opinion on where you’re at given the time that’s been spent on it?
[00:38:55] Jonathan Bossenger: That’s so here’s where we get into a little bit of personal history on this. For me, it’s been a little bit difficult because I’m not a fully sponsored contributor to opensource. I have a day job. And my day job requires me to do certain things for the business that I work for, be it, when I started it was Castos, now it’s Delicious Brains. I am allowed X amount of time to contribute to open source, but it’s not, I’m not allowed to spend my whole day. So I’ve kind of worked in a bit of a, it’s called a project manager slash wrangler role, just to try and get people interested.
We had, when we launched, we had, if you go to the initial launch post, we had loads and loads of comments and everybody was keen and everybody was excited. The problem was, in my opinion at least, everybody had their own idea of how this should work. And there was actually a stage, and if you go back into the history of the meetings, there was a stage where there was a bit of a of almost people fighting with each other in the meetings. Because one was saying it should be done this way, and one was saying it should be done then the other way. And we hadn’t even, we hadn’t even done requirements gathering yet, but people were already deciding how to build this thing. But we didn’t even know what we were building yet. So that kind of tapered off, and then we got a nice core group of folks. There was maybe ten of us. I can’t remember the exact numbers, but around ten of us that were meeting regularly. We were doing the requirements gathering. And I want to shout out to a bunch of people here Mervin, Hernandez, Ari. I can’t pronounce his surname, but he works at Yoast now, he was the theme team representative. Aaron from who was at Auttomatic, she’s somewhere else. A couple of other folks that I’m forgetting right now. I apologize in advance, but they were really involved and keeping things going. There was another chap who I know he’s a WordPress user name, but I don’t know his first name. His represented prestigious as Ramen. I don’t remember his first name. He was very influential in getting the PHP side going. And what’s happened now is we’ve kind of reached this point where COVID happened, and people’s lives changed. And I noticed that things started going down a bit and we just kind of kept chugging along and chugging along.
And what I’m now seeing is that with all of this conversation, that’s going on, people are coming back into the project. So we had a bit of work done last year on getting that HTML going, which I mentioned earlier. That kind of died down. And then recently somebody joined again and said, hey, I want to help out.
So I think the biggest problem that we have as an open source feature plugin, if you will, is just getting the, and it’s difficult in an source environment because you don’t, you don’t have a lot of easy ways to connect the folks. You have to make blog where you can create posts and I’ll blame myself here. I probably wasn’t keeping up the post as much as I should have. But you don’t really have like an official way to, you know, call to arms and get people involved. So whenever I do see these posts that jump up and down about notifications are a problem, then part of me goes, well, we’re here, we’re over here, come and have a look.
So we have had some people coming in, now, it looks like we’re moving forward again with HTML side of things. So I’m hoping that very soon we’ll be able to actually release this installable plugin that doesn’t do much, but actually just looks like what it’s going to look like. And I’m hoping my, my hope is that when we can do that, when we can physically give people something to install, and see, then they will get excited and start getting involved again.
[00:42:08] Nathan Wrigley: If I were an end user of WordPress and I had things tucked away in a notification panel or whatever that might be, that feels to me like, well, a good repository for notifications. I’m just wondering from the plugin developer side, especially from the perspective of somebody who is, really, as clean as a whistle. They never misstep and misuse notifications. They just keep everything very slim and very lean and they don’t bother us too much. What would the future for them look like? Are they going to be additional hurdles that they would have to jump through? Let’s imagine a scenario in two or three years time. WP Notify has become part of Core and everybody needs to go through the process of registering their notifications in the correct way.
What would the burden be like? Is it very minimal on the plugin developer side? How does that work?
[00:42:57] Jonathan Bossenger: So I’ll say this, I don’t see admin notices going anywhere anytime soon. And one of the reasons for that is because WordPress Core uses it extensively and will probably continue to do so until we move completely towards a JavaScript admin dashboard.
But I don’t see admin notices going anywhere anytime soon. So those developers that are using admin notices in big air quotes correctly, won’t be affected. Those that are using them in different places, but unobtrusively currently it’s a case of, you register a hook. Your write a little bit of HTML, and your notice works. On the WP Notify side, we want to make it as easy as that as well. So they will be a defined structure. You can actually see, I can send you a link. There’s a document where we have the defined structure of a notification. And if I remember correctly, it’s title and description. So very similar to what an admin notice currently looks like. An admin notice just has a description area, if you will. It doesn’t even, it’s not even defined, it generally gets used as a description area. We’ve added a title. And then I seem to recall, can’t remember hundred percent, I’ll have to double check, but I think we’ve also added a possibility to register a URL.
So if the user needs to click on a link to go and trigger some other action or click on a link internally in WordPress to trigger some action. So as a developer, you would have a similar rich user interface where currently you would hook into an admin notice. You would register a callback. Your call back would continue HTML.
In WP Notify you would have a similar hook and then you would register an object, and the object has your title, your description, and if you wanted your URL. So we want to keep it as easy to use as what admin notices is, but as friendly to the user as possible.
[00:44:34] Nathan Wrigley: I think probably Jonathan I’ve asked everything that I wish to ask. The inevitable thing is, is there anything that you wished to describe that I didn’t ask you about?
[00:44:43] Jonathan Bossenger: No. At the end of the day, The only thing that the only thing that I’m, let’s call it keen on, if you want a better word is to move this forward. So right now I’m going to use this opportunity to say if there are any front end developers or any developers out there who are very good at turning design into HTML. You want to find some way to contribute to WordPress, we have an open track ticket, where some work has been done. If we can get that over the line, that will make a huge. Then, if there are any developers who want to make this happen and they’re very good on the PHP side, or they’re very good on the JavaScript side, please come along and take a look.
Everything is linked through on our GitHub Wiki. We have a project Wiki dedicated towards the requirements documents, the design, the requirements analysis we did, the open issues and the pull request. It’s all there. So come along and come and join us, come and help us build a better notification system for WordPress, because once we can put that in place, then we can make amazing things happen.
[00:45:42] Nathan Wrigley: Jonathan, if somebody were interested in reaching out to you personally, because they would like to contribute in some way or just find out more. Do you have any links or websites or social channels that you frequent?
[00:45:54] Jonathan Bossenger: Sure. I am on Twitter. It’s John underscore Bossenger because Jonathan Bossenger was too long for Twitter, back in the day. You’re also welcome to email me. My email address is my full name. Jonathan Bossenger at gmail dot com. I don’t mind sharing that email address because Gmail’s pretty good at handling spam. And I would just say that if you do email me to ask me questions, please give me some time because I am very strict with how I manage my emails.
So I’ll check that mailbox once a day and reply when necessary. Finally, if you want to get involved, go to github dot com slash wordpress slash wp hyphen notify and go through from there. If you are already contributing to WordPress and you’re already in the WordPress Slack, there is a feature notifications channel where we have our meetings every Wednesday.
And I think it’s 2:00 PM UTC, please feel free to come and join. And you’re welcome to DM me in that Slack. Email is the best. I’m a little bit old now, so this whole Twitter DM thing is something I still struggle with. So, if you want to ask me questions, email is . Probably the best. Otherwise get me onto Twitter.
[00:46:49] Nathan Wrigley: Jonathsn Bossenger, thanks for joining us today on the podcast.
[00:46:52] Jonathan Bossenger: No problem. Thank you. .
Listen to 
Follow 
Mentioned in the show:
is a stage for WordPress professionals to exchange ideas and talk about recent topics and trends.
