9 Comments

  1. Joshua Vandercar

    I like the initial proposals by the meta team – fresh, concise, and accessible.

    It is true that there are quite a few Read More links. To better handle these, I would appreciate seeing an easily accessible X to collapse a section after having expanded it (without having to scroll). Or even the ability to expand a section by clicking on its header – that seemed an intuitive action for me.

    Report

  2. Marcelo

    I love the design, but the heavy amount of “Read more” links is annoying. I would prefer the approach of Android Material Design, in which, you simply can click (or touch) anywhere within a collapsed box of content to expand it and again to collapse it.

    Either way, the current tabbed navigation is very useful for those plugins with really long texts. Also, the possibility to point a direct remote link to the FAQ or Changelog or Support page for any given plugin, is a feature that should be preserved.

    Beyond these points, the overall new design looks pretty nice :-)

    Report

  3. Christee

    The new design is certainly more visually appealing, but I also prefer the tabs. They are significantly more efficient than all the scrolling. Hopefully a design both visually appealing and efficient can be found!

    I don’t see one of my pet peeves addressed, which is the ability to search within the support forum of a single plugin. This makes it difficult to determine if my question or issue has already been asked and answered. I usually resort to a Google search to try to achieve this. (If there is currently a way to do this that I’m just too thick to figure out, please let me know!)

    Report

    • Alec

      Thank you Jeff for shining a bright light on alternative ideas about the plugin directory here. Hopefully someone is listening. The plugin directory is a functional tool and visual appeal is only a part of its mandate. Improving form should improve functionality and not detract from it.

      Paal’s ideas about functionality are great. More powerful and more personalisable would be ideal. Not all users are identical, hence the tool (plugin directory) should be powerful enough to serve us all.

      Great idea Christee about improving support search. That would be the just kind of improvement which would make WordPress publishers’ lives better.

      Report

  4. Ashley

    I definitely prefer the old tabs. As Marcelo said, that makes it easier to link to a specific section of the plugin page (Installation, FAQ, etc.).

    Report

  5. Dave

    The new designs are great. I will say that more filters would be amazing! Replacing ‘popular’ with a dropdown I feel is a good call. By being able to select a star rating, I think this places more value on what is popular because honestly, there are some great plugins with 4 star ratings. As well, newer plugins might have gotten some lower ratings at first where active development on the plugin could have changed the outlook across the board.

    In terms of the design, I like the blue bar instead of the white bar that is currently present. It feels more like the WordPress backend :)

    All in all, the direction is great. The meta is already there so I would assume that the implementation would be rather unobtrusive.

    Report

  6. rick

    Mocking things up like this is premature and generally we end up arguing visual issues which, while fun, are the least important of the issues here.

    What we need to really figure out are the UX issues – what are the purposes of the directory? Who are the ‘customers’ and what do they want and need?

    For example, popular. Who CARES about whether a plugin is popular (even assuming we can adequately define that word in the context of plugins)? A site owner shouldn’t install a plugin because a lot of other people are doing it, they should install a plugin because it fills a need.

    So, the first thing is that the interface should be far more conversational. It should assume the visitor is looking for a plugin to do X and encourage them to express that – “I’m looking for a plugin that does _____” where the underline is a select menu of common things that people use plugins for with an Other choice for cases that aren’t common.

    Next, USE FACETED SEARCH. It’s better that the mockup lets people order by various criteria, but I often want to show only plugins rated 3.5 stars and above *and* which have been updated in the last 3 months. Forcing one search mode on me is 1990s thinking.

    Report

  7. Steve Teare

    Choosing a plugin would be easier if WordPress permitted a little more repository information. Author-generated advice is untrustworthy because it’s biased. Popularity (number of installs) is, also, a lame indicator. Newer plugins sometimes are better. We can’t search on freshness.

    We seek indicators of credibility (which is composed of expertise, trustworthiness, and leadership). These cues are sometimes referred to as information scent. These things are inferred in the plugin repository – or are discovered by downloading. They include:

    1. Download file size. This is a potential indicator of plugin efficiency. Not always but frequently. If we have alternatives, we recommend the smallest plugin package to avoid bloat. Why doesn’t WordPress just tell us file size before downloading or having to click? Editorializing download links is considered polite and good web etiquette.

    2. Date of first approval or submission. Longevity in the market is an indicator of credibility. At present, we either must open the download package and examine the readme.txt for a change history – or figure it out in the repository by compatibility to the oldest version of WordPress. Like a reverse-lookup. Do we have to use Wikipedia? That still doesn’t really tell first-release date of the plugin.

    https://en.wikipedia.org/wiki/WordPress#Release_history

    3. Similar or newer plugins should be listed as linked options.
    Popularity doesn’t always mean “best.” It may just mean old or antiquated. Inference from similar plugins (if listed) helps cue us for plugin usage and adaptation (workarounds).

    4. Does the plugin require a signup or registration? In other words, is it bait?

    5. Does the plugin interrogate an offsite database or cloud information? This is an indicator of slower load times (page speed) and HTTP requests.

    This information and more would make for better productivity using the repository. There isn’t enough information when making choices.

    There are a few other things we’d love to see. But we’re being idealistic in our wish list. These include answering plugin questions such as:

    Does the plugin have hidden non-features? For example, some image optimization plugins have limitations of how many image conversion quantity. The repository says nothing about it. Nor does the readme file. You must install first to find this bugaboo out.

    Are there known incompatibilities or conflicts with other plugins or themes? Sometimes authors only reveal this in the readme.txt file. That wastes our time.

    Report

Comments are closed.

%d bloggers like this: