A lesson I learned a long time ago
Years ago I worked on a project that was specifically for the last group of scientists that had direct access to the President of the United States. It was a big deal to be working with these high energy physicists. So not only did we create a site to collect some key data from them, but I also offered to manage support on the project as well. My team would be the ones getting the emails and answering the phones.
I'm sure they didn't love it, but I thought it was a critical enough project that we didn't want anything to go wrong.
Now this was back in the early web days, somewhere around 1995 or 1996. So you can imagine the kinds of calls we got.
“My printer doesn't work…”
But I recall one very clearly. The admin assistant for a high energy physicist on the East Coast called us to tell us that our web application wasn't working. At the end of a multi-step data entry process, users were allowed to print the data they'd just submitted for their own records.
Well, according to her, the print button didn't work. So we started going thru the normal steps.
- Could she print another web page, like yahoo.com? No.
- Could she print from another application, like from Word? Nope.
- Had she ever been able to print? Never.
In fact, that's why she had been calling – because we now had promised (via the “Print this document” button on the page) that her printer would finally work, and it wasn't.
I remember this story because I learned on that day that developers of any product will often get feedback and complaints about things that fall outside the scope of their work. That's the nature of the beast.
But that didn't stop me from trying to help her out. And it doesn't stop plugin developers (the good ones) from trying to help users even if it's not their plugin that's creating the problem.
Misaligned Support Costs
I wonder (often) how much time the developers behind Gravity Forms, Easy Digital Downloads, or MemberPress have to spend to deal with issues that actually aren't their own product?
Don't answer that, if you know, because the answer will just be depressing.
People buy cruddy themes, written poorly but with 23 different sliders embedded in them, and then get mad when a plugin doesn't work. And instead of complaining about their beautiful theme (which looks nothing like it did on the site they bought it from), they head over to WordPress.org and complain about the plugin.
ugh.
Plugin Feedback, The Wrong Way
But it's for that reason that I wanted to highlight a situation I often see on the WordPress.org plugin repository, where we can rate plugins. It turns out some people not only have unreasonable expectations, but don't really understand how to best give plugin feedback.
So here are five ways to do it wrong.
- Rate the plugin poorly even if it does exactly what it says it will do.
- Rate the plugin poorly because it couldn't predict your scenario.
- Rate the plugin poorly because you buy crappy hosting.
- Rate the plugin poorly because it conflicts with your other 74.
- Rate the plugin poorly because additional features cost money.
When you read them, they sound silly don't they? And yet, I see it happen all the time.
That image, at the top of this post, is real. I didn't make that up. A user decided that even though the plugin did exactly what it said it would do, it still deserved only a 3 – because they wanted something else beyond that.
Plugin Feedback the Right Way
Everyone knows that a plugin that works perfectly on a developer's computer may still have an issue in your own environment. When something doesn't work well, here are some simple steps you might follow before a rating entry.
- First, contact the plugin developer directly.
- Try to do this privately (email, ticket). Not on Twitter.
- Give them enough data for them to evaluate things.
- Offer to take screenshots or do a screen sharing session.
- Turn off plugins to eliminate cross-contamination.
- Check things with a simple theme, like TwentyEleven.
- Provide this data back to the developer. Share insights.
- Follow the directions (replies) from the developer.
- If things are fixed, thank them.
- If they're not, and you plan to rate them, contextualize it.
See, if you do all of the above to try to mitigate an issue, you might discover that the issue was your plugin, or your theme, or your host. Then, if you want to give a plugin a rating record on WordPress.org, you can be specific.
“This plugin doesn't work with my theme (xyz) and has a conflict with the infrastructure at my host (abc). The developer was helpful but couldn't get it to work in my scenario. For that reason, this gets a 3 star rating.”
That's a helpful review. Because it warns people with that theme or host, to be careful.
“This plugin does everything it says it does. For that I gave it a four star rating. I really wanted to give it five stars, but for me, a plugin that does xyz really should include abc in the core feature set and this one doesn't do that (which they clearly state on their site).”
Now if someone reads that, they can determine if they agree that abc is needed or not.
More often than not, I'd hope we see high ratings that simply say things like this.
“I spent two hours testing different scenarios to find out that the plugin was right and my cruddy theme was causing the issues. Unfortunately, it wasn't the theme developer who helped me with it, but instead was the plugin developer. I hate that I wasted their time, but five stars for great support and I'm waiting for their paypal email to send them cash.”
I mean, seriously, who wouldn't want to read that review.
All that said, there's a real art to writing a great review. I don't have it. That's why I stuck to the “what not to do” advice. If you want to talk about the master of positive review, Mark Jaquith is a member of the WordPress community and you should see his work.