Since my last post on HL Twitter almost a month ago, I’ve accrued another 3,000 downloads bringing my total to just over 8,000. Now obviously this doesn’t mean 8,000 people are using my plugin, undoubtedly many of them are repeat downloads etc. But it does mean I now have a much larger userbase compared to my initial development, and with that comes “support requests”.

It begins as a trickle. A friend who has installed the plugin can’t get it to perform a certain function; you check the code and invariably find a fault in your logic. You fix it, push the update and everyone’s happy. Until a week later when someone else finds another bug. Then someone asks if it can do Feature X, you add it in for them. The next day it’s Feature Y and you don’t have time so you put it on the end of the “To Do” list.

After a while though, the emails start building up. Many of them are polite, some are hostile and most just want to know why the plugin isn’t working. It’s not just email though; support forums, blog posts, feedback forms and other means of communications begin to clog up your inbox each morning.

Seriously, spending an hour a day just responding to users is not an uncommon occurrence between the collection of plugins and tools I’ve releaed. So why do I do it? These people haven’t paid me for the bits of code I release (excepting donations which always make me smile). I’m under no obligation to support this code. So why do I spend my hard-earned time responding to each and every request I can? Simple; this is my work out there. If it fails, it’s failed because of me. Nobody likes admitting they make mistakes but everyone does. If someone points out a fault I fix it, thank them and carry on.

Over time I have learnt a few things about users however, that makes dealing with support requests much simpler.

• Users don’t read. The FAQ for HL Twitter often answers 90% of questions, but has the user ever looked at it? In these cases, canned responses are the best solution. A nice generic email explaining where the solution can be found.
• Never give a timeframe. When I first released Plex Export I was inundated with really cool feature requests and I’d constantly say it’d be added by the following day. This will come back to bite you in the ass. Miss one deadline and people start asking why. Now you’re dealing with two issues. Instead, make a list, prioritise based on how much demand/time each item has/requires and then work through them when you can.
• Make it easy for people to get in touch, preferably through one channel. During my WordPress dev phase, I built a plugin for plugins that adds a feedback form within the plugin itself. This lets users easily get in touch with me, with minimal hassel. It even sends along diagnostic information! The worst offender for muddying the waters is WordPress itself, their support forums are a nightmare of tags that means I’m forever getting duplicate emails for hl-twitter, hl-twitter-widget, hl-twitter-plugin et al.
• The web is not english. While english may be the lingua franca for development, guess what; most users aren’t developers! i18n support for HL Twitter is coming, but in the meantime using simple english phrases can help immensely, especially when explaining how to fix a problem.
• Respond quickly. While the solution may take a while, let users know you are aware of it, even if all you do is say hang on. All developers know this from their own experiences; emailing the maintainer of a library you’re reliant on, only to wait weeks for a reply. A prompt response means the user will be much more willing to wait, even if the problem will take a while to fix.
• Be thankful, but take no stick. The vast majority of emails are from truly nice people who just want a bit of help, make sure you say thank you for choosing your plugin/library/tool over the myriad others. On the other hand, those outright rude or offensive emails? Ditch them. Nobody likes to wake up and be told their a crummy developer who should stick to VB macros. If someone has already gone to the effort of sending a message like that then no amount of placating or problem solving will fix their troubles. Luckily, only a fraction of emails ever fall into this category.

Needless to say, supporting an application is easily as much work as writing it in the first place. But by being quick, kind and helpful you can help ensure those users that do pick your work over the alternatives have a positive impression. And I will release HL Feedback someday hopefully. See, no timetables.