34 Comments

  1. Scott Winterroth

    Amen!

    Report

  2. Ronald Huereca

    One thing to add. If you’re a plugin author who does do screenshots, please include your screenshots in your /assets folder in SVN, rather than in the main plugin folder (i.e., trunk).

    Report

    • Otto

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

      Report

      • Pete

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

        Report

      • Ryan Hellyer

        I wasn’t even aware you could set a mime type in SVN.

        Report

      • Jesin A

        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

        • Otto

          Okay then, please subscribe to our blog. We wrote about this last March. ;-)

          https://make.wordpress.org/plugins/2014/03/20/plugin-screenshots-downloading/

          Report

          • Jesin A

            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

          • Ryan Hellyer

            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

          • Jesin A

            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

          • Ryan Hellyer

            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

          • Samuel "Otto" Wood

            @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

  3. mac2net

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

    Report

  4. Christee

    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

    • Pete

      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

  5. Pete

    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

  6. Joan Boluda

    I couldn’t agree more.

    Report

  7. hueyyeng

    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

  8. Li-An

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

    Report

  9. Peter

    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

  10. Tia

    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

  11. Giorgos Sarigiannidis

    Also, a final touch would be adding an icon for your plugin, as described here: https://make.wordpress.org/core/2014/08/21/introducing-plugin-icons-in-the-plugin-installer/

    Report

  12. Julie @Niackery

    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

    • mac2net

      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

      • Christee

        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

  13. jasonjudge

    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

  14. John

    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

Comments are closed.

%d bloggers like this: