Dear WordPress Plugin Developer, Please Add Screenshots

Plugin Recommendations Featured Image
photo credit: when i was a birdcc

This year the WordPress plugin directory crossed 35,000 plugin listings and is rapidly approaching one billion total downloads. WordPress 4.0 added custom icons to the plugin installer in the admin, which helps developers to differentiate their plugins in this massive sea of extensions. Plugin branding is useful for standing out in the initial results of a search, but beyond that there is one tab that gives plugins a distinct advantage over others.

How important is the Screenshots tab for plugins hosted on WordPress.org? Feedback from our readers indicates that screenshots are a critical part of a understanding what a plugin does:

There’s nothing more infuriating than an incomplete plugin description with no screenshots. When you’re on the hunt for a specific functionality, it can be time-consuming to install a plugin, only to find out that it doesn’t do what you need it to do. For the plugin developer, there’s always the risk that someone will install your plugin, find out that it doesn’t do what they want, and give it a poor review because of the inconvenience.

Can Screenshots Make or Break a WordPress Plugin?

Many users now hunt for plugins in the admin, as opposed to directly on WordPress.org. If you’re a plugin developer, it’s a good idea to remember that the plugin details page is still available to users searching in the admin via a modal window.

With the exception of plugins that have no visible output, every plugin listed in the directory could benefit from a set of basic screenshots. Some plugins, such as BuddyPress or Jetpack, have their own websites full of images. Even with a separate website, the plugins still include screenshots for users who don’t wish to navigate away from the admin or WordPress.org.

If your plugin does something visual on the frontend, users appreciate a screenshot of an example, even if the output varies depending on the active theme. Frontend and backend screenshots are equally important.

For a simple plugin, with no dedicated website, having screenshots could be the difference between gaining a strong user base or having your plugin stuck at just a handful of downloads.

I’m borderline obsessive when it comes to the WordPress plugin directory. I have scanned through every single plugin that has come through the directory for the past several years, always on the hunt for the cream of the crop. Even with a solid description, if the plugin has no screenshots, it’s tough to find the motivation to take it on a test run. There are many gems hiding in the directory that have been overlooked and undervalued, simply because users cannot visualize how the plugin works.

If you are hosting a plugin on WordPress.org, there are three solid advantages to adding screenshots to your details page:

  • Screenshots help potential users understand what your plugin does: These images are an important part of your communication to the user. If you don’t care about communicating what your plugin does, why host it in a large, public repository where people will demand support?
  • Screenshots can reduce trivial support requests: There will always be people who install a plugin, without being sure of what it does. Having screenshots may help answer easy questions that would otherwise clutter up your support forums.
  • Screenshots may help your plugin gain traction and contributors faster: If a screenshot assists in clarifying what your plugin does, then you may inspire more people to install it, discover how awesome it is, write about it, and recommend it to others.

A plugin developer’s decision to omit screenshots is not necessarily indicative of the plugin’s future, but screenshots can go a long way towards building a solid user base that can make your plugin worth all the hard work you’ve put into it.

If you’re going through the trouble of putting your plugin up on WordPress.org, you might as well spend a couple extra minutes adding a few basic screenshots. Who knows? That plugin could be the key to your next paid gig and a valuable example of your work as an open source developer. Your plugin may even be the next most widely recommended tool for WordPress users, but the world may never know if you don’t bother to add any screenshots.

Would you like to write for WP Tavern? We are always accepting guest posts from the community and are looking for new contributors. Get in touch with us and let's discuss your ideas.

34 Comments


    1. And set their mime type correctly in svn. Helps a lot. :-)

      Report


      1. Yes please nothing more frustrating than having to download a screenshot onto my local computer just to see it.

        Report


      2. And I thought it was a bug in repo :P because a lot of popular plugins with >1M downloads have this problem

        I wrote an article on this.

        TL;DR
        svn propset svn:mime-type image/jpeg assets/*.jpg
        svn propset svn:mime-type image/png assets/*.png

        Report


      3. My bad for not noticing it, but ipstenu’s plugin screenshots have the same problem too.

        Surprising to see WordPress superstars like Joost and Pippin not setting the mime-type of their plugin screenshots.

        Maybe these instructions should be added to the “Using Subversion” page and stressed wherever possible.

        Report


      4. That’s probably because they didn’t realise it was a problem. I think I saw that blog post but ignored it as it seemed irrelevant since my screenshots work just fine on WordPress.org.

        This only seems to be a problem when trying to view the screenshots on their own. Or perhaps this is a problem in some browsers which don’t handle the correct mime-type?

        At any rate, I’ll eventually fix those mime-types on my own plugins, but I’m not in a hurry to do that since I can’t see any real practical problem with them the way they are now.

        Report


      5. This only seems to be a problem when trying to view the screenshots on their own.

        Exactly, and if the screenshot covers a lot of screen area people click on it to see it clearly in its original size.

        IE11 opens it correctly while Firefox and Chrome open the download dialog. It happens because the “Content-Type” HTTP response header is set to “application/octet-stream” instead of “image/png” or “image/jpeg”.

        If I’m viewing this plugin on a laptop screen I’d want to view the enlarged screenshot and if I have to deal with the download box each time it is irritating.

        Report


      6. Oh SOB! They’re clickable!

        Thanks for letting me know Jesin. I’ll try to get all my screenshots fixed tonight. We should let plugin developers know about this so that they can fix them.

        Report


      7. @Ryan Hellyer: Really, it’s a problem with the default settings in various SVN clients. The SVN client sets the mime type, and a lot of them don’t come preconfigured to set the mime type correctly for images. We’re looking into other solutions in the long run, but if you want to not have to worry about it anymore, look at your SVN client’s config settings for enable-auto-props.

        If you use Windows and TortoiseSVN, look in your C:\Users\yourname\.subversion\config file. Uncomment out the line enable-auto-props=yes and the lines for *.png and *.jpg in the [auto-props] section.

        Report


  1. Worse than no screenshot – a screenshot tab with no content!

    Report


    1. Absolutely, or a link to their website with no screenshots.

      Report


  2. If there are no screenshots or the description is scanty or poor, I tend to assume that is reflective of the type of attention given to the plugin (i.e., it’s probably not top quality).

    Report


    1. I agree, if a plugin author can’t put up some decent screenshots then to me it flags a warning bell about it’s potential future updates.

      Report


  3. I’m on a mini quest to post on the plugin’s wp support page a message asking them to include one. About half are happy to oblige.

    Report


  4. I couldn’t agree more.

    Report


  5. One of the first thing that I look for when checking out a new plugin.

    Even when writing tutorials on my site, I try to provide as many screenshots as possible as picture worth a thousand words.

    Report


  6. Well, I like authors who forget to put screenshots or description: I don’t need to test their plugin !

    Report


  7. What bugs me even more than not having screenshots is those plugin devs that don’t include a changelog or, even worse, only includes a link back to their site to view it. A built-in change log should be a compulsory requirement for the repository! Yes, BuddyPress, I’m looking at you!

    Report


      1. I’m neutral, but take this use-case: you’re updating plugins on a client site, you see one you’re not sure of, pop up the modal, and you browse the changelog to see what’s changed or if there needs to be an update. If the changelog is empty and leading to a dev site, it’s an extra step in this case.

        Report


      2. I’ve never done that before. Perhaps others do though.

        I’ve included a changelog for a very long time now, as plugin users complained when I didn’t have one. But I didn’t think it mattered too much where it was, just that it existed.

        Report


      3. FYI, I do always stick them in the readme. But that’s just because that’s the official place to put them, not because I thought there was a practical reason for putting it there.

        Report


  8. I agree. Screenshots of the backend admin panel and of the frontend of the site make all the difference. There have been so many times where I am not even sure exactly where to access the plugin because it can show up in several different locations on the backend.

    Report


  9. Thanks very much for this article. Agreed that screenshots and up-to-date changelogs are a must! So are detailed descriptions and FAQs. Plugin developers should be doing everything possible to communicate how their plugins work.

    To me, the worst is coming across a description with some variation of, “If you want to know more about this plugin, install it and test it out for yourself.” It’s so insulting to be asked to waste my time because a plugin dev was too lazy to write a few paragraphs explaining the plugin. If a plugin author can’t do that, it’s hard to believe that the person a) fully understands their own plugin; b) cares enough to maintain/update it. Theoretically, the plugin author should be in the best position to describe the plugin, and the inability or unwillingness to do so reflects strongly on the quality of the plugin and the kind of support that can be expected.

    It also conveys attitude towards free plugin users — it seems to say, “I’ve already done all this work for you to use for free so I don’t have to do anything else. If you want to use this, be my guest, but leave me alone.” It doesn’t exactly send the message that the plugin author cares to build relationships/business opportunities/etc.

    I guess where I’m going with this is that when plugin authors omit things like screenshots, detailed changelogs, and accurate descriptions, they seem to be showing disdain to potential users. I’m sure some of them do it because they’ve seen it done elsewhere and think it’s acceptable practice, or because they’re burned out from all the hours they spent developing the plugin in the first place and don’t have the energy left to explain what it does. Either way, the result is the same as if they truly were disdainful, and that’s a shame.

    Here’s to hoping this article will have an impact :) Thanks again!

    Report


    1. I want to come to the defence of “wayward developers”.
      A lot of stuff goes into the plugin repository.
      Some plugins certainly merit a well thought out submission.
      Folks want to do all the aforementioned practices.

      But other plugins are outliers for many different reasons. Many require actual code investigation.
      Those plugins should have unique standards and when researching them one should take this into account when evaluating a plugin page.

      Report


      1. I could almost buy that for certain niche utility plugins. But I still think quality is reflected and confidence instilled via the plugin documentation. For example, I recently came across the Delete Expired Transients plugin. Definitely niche and clearly an admin utility. One could easily say the name says it all – what more should be documented? Yet the developer includes screenshots and an explanation not only of what the plugin does, but why it is useful. (In fact, the writeup provides more background on expired transients than I could find on the codex.)

        Again, this reflects the quality of the plugin, and I could use it with more confidence than I would have otherwise (and, BTW, it happened to help me find another plugin I’m using has a transient leak).

        Report


  10. All very nice, until you try to find out how to do it. All Google searches result in people asking why their screenshots are not working. Trying to navigate to the *one* page that actually tells you how to add a screenshot is not easy.

    This article is a case in point – it says “just do it”, then provides no link to show how it is done.

    Even many other high-ranking articles that say “do add a screenshot, and here are some nice plugins that do”, then also fail to tell you how. And they all complain that developers are just not bothering. Why is it so hard?

    Report


  11. Just wanted to say thanks to Samuel “Otto” Wood for the Tortoise SVN config tip – that worked and I’ve fixed my plugin screenshots. BTW why are there reply links on some comments and not others? Odd.

    Report


    1. Reply links disappear when a specific part of the comments reaches the maximum thread limit.

      Report

Comments are closed.