Lessons from creating WordPress plugins

Posted on 24/09/2014 under Web Development, WordPress

Ever since I created Auction Nudge in 2008, customer support has been a top priority. People would email me their questions, problems and feature requests and I would go out of my way to help or accommodate them. It was important to me to keep my users happy and it made business sense to surpass expectations, even though the tool is completely free to use. While creating Auction Affiliate earlier this year, part of my strategy was to create a WordPress plugin which gave users a friendly interface for setting up the content they wanted Auction Affiliate to display on their site. I was happy with how the plugin turned out and with the lessons I took away from the building it, so I decided to create a fully-featured WordPress plugin for Auction Nudge too. If someone wants to use Auction Nudge, they go to the site, configure how they want it to work and copy and paste a simple code snippet on to their web pages. At the time I had already created a plugin for WordPress, but it was pretty ‘dumb’ and still required manually copying and pasting code into the plugin. Although this is straight forward for the tech savvy, I wanted to eliminate the requirement to even see any code in WordPress. I completely re-wrote the plugin, set it live and sat back to see what happened. I now had two plugins in the WordPress plugin directory which were gaining users. Mission accomplished right? Well yes and no, I quickly learned that running and supporting a WordPress plugin was quite different from running a service through your own site. Here are some of my take-home lessons.

Lower barrier to entry

It seems silly now that I was surprised by this, but by making things easier, I was now catering with users of a lower technical ability. Before I created the Auction Nudge WordPress plugin, if users wanted to use the tool then they had to be comfortable with pasting some code onto their site. This doesn’t sound like much, but it is a barrier. Because of this, when users contacted me for help I could assume at least some level of technical ability. By eliminating this barrier, I found that I was now supporting users of all abilities – right down to those who hadn’t seen HTML before. To begin with, I treated this new class of user the same (“You want to know how to do X? … Well just paste Y code on to your site!”) I quickly learned however that I couldn’t assume that these new users would know what to do with blocks of JavaScript or CSS I provided them with. I had to take a step back in my support role and learn to cater for these users. I had to find a way to gauge their ability level and respond appropriately. I am still learning the best way to handle this, but so far I have:

Put a lot of effort into improving the online help documentation to try and catch commonly asked questions early on
On the Auction Nudge contact form I now ask users to tell me how they are using the tools (i.e. through the WordPress plugin or copying and pasting code snippets)
If I think I will need to provide code to a user, before writing anything bespoke I ask if they are able to add code to their site

You can’t fix what you can’t see

Before the plugins, any user with an issue could provide their web address, and as Auction Nudge was executed by JavaScript in the browser, I could immediately start digging in to their site’s code using a web inspector. Now, using the plugin, users create feeds from within their WordPress admin back-end. This adds a layer which I do not have access to, and can make issues difficult to debug. So far I have been responding to users with a breakdown of debugging steps (“if you do X, what happens?” … “Does doing Y fix it?”) I have also been asking users to provide screenshots of the relevant option screens so I can replicate their setups. None of which is ideal. Some users, without me asking have provided me with their WordPress admin logins. This isn’t something I was expecting to happen, and makes me shudder a little to think of any dishonest plugin authors that might be out there.

Code responsibly

Errors and exceptions in your plugins needs to be dealt with responsibly, otherwise standard PHP error messages may be output within page content, or may even stop the page from loading all together. This is a lot of responsibly and means plugins need to be tested thoroughly before release. Not a trivial task considering all of the possible server setups (just catering for different versions of PHP is a task in itself) However poor coding can be avoided… In an early version of the Auction Affiliate plugin, I mistakenly left in some debugging code which would call the PHP’s die() function to output a message in the event of some error. Unfortunately, after the error message was output the function then instructs PHP to stop executing. So in the even of this error, the users’ site would not load. Luckily this was a very rare situation, and I was quick to fix the issue once alerted, but it did happen. Errors should be handled gracefully. Lesson learned.

Reviews matter

Generally very few people leave reviews. So far I have received approximately one review for every 400 downloads. This means that for every person that reviews there are 399 people that have downloaded the plugin but did not leave a review. Almost all of the reviews I have received have been from people that I have had some interaction with, and have been a direct result of exceeding users’ expectations. If I have built up some rapport with a user via email I have no problem explicitly asking them for a review, linking them to the review page. This strategy has a fairly high success rate. Reviews are very easy to leave, but as they are displayed prominently on the plugin directory (an already competitive marketplace) they can have a huge impact on whether a user decides to try out your plugin or not. Supporting plugin users and getting these reviews is therefore especially important to me. On the plugin page I ask people to get in touch if they have any problems. Early on I had someone leave a one star review and then contact me to tell me why they had done so. I eventually worked with the user in question to clear up the issue and asked them to update their review to reflect this, which they did. Knowing that people are more likely to go to the effort of creating reviews to share bad experiences, this is something I have kept an especially keen eye on (see below) Since then, I believe because I have had a few more positive reviews (a lot of which positively mention my customer support) I think people are more likely to get in touch before leaving negative reviews.

Getting notified

Although hard to find, you can set up search string notifications in your WordPress account so you are notified when a search term you are interested in get’s mentioned in a post on on the forum. You can use this feature to be notified when someone mentions you, or one of your plugins:

Log in to WordPress.org
View your profile
Click the small “Notifications” link at the top of the page
Enter a Notification Search String to be notified about
Provide a Notification Name
Click Add new notification

Each plugin also has a RSS feed which you can subscribe to, so you can be informed of any new support posts. The RSS feed is accessed from https://wordpress.org/support/rss/plugin/[your-plugin-slug] As far as I can tell there does not seem to be a way to get notified whenever someone leaves a new review for your plugin. In the event of a bad review I want to act straight away in order to resolve it quickly, so my solution was to set up alerts with ChangeDetection.com for my plugin reviews pages (i.e. https://wordpress.org/support/view/plugin-reviews/[your-plugin-slug]) so I am notified when the content of these pages change.

Downloads don’t mean users

Because WordPress makes it very easy for users to download and install plugins, it is easy for them to test drive different plugins to find the one they are looking for. This means that the number of downloads you receive doesn’t reflect the number of new users you will receive. Also, as plugin updates add to number of downloads, you can’t read too much in to this number. Unless users contact me, or submit a support ticket, it is difficult to gauge their response to the plugin and the reasons why a user may decide to not use the plugin beyond a test drive. It’s hard to know if you are heading in the right direction without this feedback and I have considered adding some sort of feedback functionality right from within the plugin. For now I am focusing on rolling out incremental improvements to grow the user base.

People do update

WordPress has some great mechanisms for informing users of updates for both it’s core platform and for third party plugins. Updates are also very fast and painless to perform. I have noticed download spikes during the days following after a plugin update, even for minor improvements, so users are fast to update. This is great news for plugin developers eager to improve their plugins! However because users are prompted to update, I try to bundle improvements into periodic updates, instead of users being constantly pestered to install updates. – All in all I have enjoyed these new challenges and will continue to develop these, and hopefully other plugins in the future.

Posts