WordPress.org

Make WordPress.org

Recent Updates Toggle Comment Threads | Keyboard Shortcuts

  • Samuel Sidler 9:56 pm on May 20, 2016 Permalink |
    Tags:   

    Taxonomies in the Plugin Directory 

    Since my last post, I’ve been doing some thinking and digging into taxonomies on the plugin directory. There were a few common complaints about rethinking “tags” in the plugin directory. They boiled down to a few specific points:

    • I need to mark my plugin as built for [plugin name].
    • I need to note which WordPress features my plugin supports.
    • Tag pages are currently well-placed in search engine results and changing or removing them could lower my ranking.
    • As a result of the above, among other things, three is not enough.

    This post will walk through a bit more detail on our thinking and address those points.


    The plugin directory was created to showcase free and open source plugins from all over, bringing them together to make it easier for WordPress users to customize their WordPress installations. As its grown to over 40,000 plugins, it’s gotten harder and harder for users to find the Right Plugin. While initially helpful, tags have become a free-for-all to indicate an assortment of things. Going forward, we’d like to re-focus our taxonomies to make it easier for users to find quality plugins.

    In an ideal world, a plugin’s readme would detail all of its features and the plugin directory search would parse the readme well. We’re moving toward that ideal world. Our current search, powered by Sphinx, is being replaced by ElasticSearch, which will yield far better results.

    However, parsing readme files is not the only method for classifying things. We have a wonderful feature in WordPress called “taxonomies” that can both assist search and make it easier for users to find specific plugins. So, let’s use them!

    I’d like to propose three separate taxonomies (more on each below):

    1. Categories
    2. Built For
    3. Business model

    Here’s a bit more detail on each taxonomy.

    Categories

    Categories are the new tags. In fact, we’ll automatically map most tags to categories so plugin authors don’t have to.

    With great help, I went through the top 1000 terms currently in use in the plugin directory and attempted to categorize them. Many of them are not useful and should not be categorized (here’s looking at you “post” and “plugin“). But most of them categorize quite well into these 26 categories (an initial attempt):

    • Accessibility – Plugins that improve accessibility.
    • Advertising – Including affiliates.
    • Analytics – Including statistics, counters, and the like.
    • Arts & Entertainment – Sports, games, movies.
    • Authentication – Login, registration, OAuth, OpenID.
    • Business – Real estate, travel, restaurants.
    • Calendar & Events – Including scheduling, booking, clocks, and appointments.
    • Communication – Email, chat, newsletters, subscriptions.
    • Contact Forms – ‘Nuff said.
    • Customization – Templates, sidebars, Customizer, widgets.
    • Discussion & Community – Comments, forums, BuddyPress.
    • eCommerce – Shopping, payments, billing, invoicing.
    • Editor & Writing – Writing, editing, TinyMCE.
    • Education & Support – Including help desk, wiki, and dictionary.
    • Language Tools – Multilingual tools.
    • Maps & Location – Plugins that geolocate or map.
    • Media – Galleries, carousels, sliders, etc.
    • Multisite – Plugins which are built to improve and enhance networks.
    • Performance – Cache, monitoring, maintenance.
    • Ratings & Reviews – Including polls, testimonials, and recommendations.
    • Security & Spam Protection – SSL, HTTPS, firewalls.
    • SEO & Marketing – Including sitemaps and OpenGraph.
    • Social & Sharing – All the sharing plugins for all the social networks, including OEmbed.
    • Taxonomy – Custom taxonomies, tag clouds.
    • User Management – Membership, profiles, CRMs.
    • Utilities – Import, export, calculators, debugging, offline.

    We can – and should – debate the specific naming of these categories. However, for this post, consider the general “buckets” created by each category. We have plenty of time to paint the bike shed. 😉

    Why move from free-form tags to categories? Moving to categories allows us to feature specific categories on the plugin directory home page. For example, in the future, we’ll be able to update the homepage on a regular basis to show “Trending [Category] Plugins.”

    Categories are also considerably more familiar to users today. This is well-evidenced by mobile app stores like Google Play and iTunes, where users find it easy to explore and find new apps for their devices.

    What about tag pages? These will no longer exist, but they can be forwarded to the relevant searches.

    Wait! Don’t comment yet. Keep reading. 🙂

    Built For

    Plugins often need a way to indicate they’re built for another plugin. WordPress does not have a dependency system and this blog post is not the right place to lobby for one. However, the plugin directory currently allows plugins, through the use of tags, to indicate that they are built for another plugin.

    For example, all plugins that are built for Contact Form 7, currently indicate so with the contact-form-7 tag. This can get messy, as seen in the search results.

    The new directory will, instead, introduce a new taxonomy that allows the plugin author to select a plugin they’re “built for” in the plugin admin. This will not be a free form area. Instead, it will allow you to choose a specific plugin that is already in the directory.

    Business Model

    Finally, Matt forwarded some user feedback and challenged the team to come up with a way for authors to indicate what business model their plugin operates under.

    As you can see from the prototypes, we’ve been experimenting with how this will look like, with the likely addition of an explanatory tooltip and/or page. Terminology-wise, I propose we adopt the following terms:

    • Service – Utilizes external services to operate. Some functionality may be available without sign up.
    • Lite – A premium version (or add-on) is available for purchase from the developer.

    Plugins with neither of these restrictions would not need to add either term. This new taxonomy would be opt-in and plugin authors will be responsible for adding the relevant term.

    Adding these two terms will go a long to helping users understand a plugin’s requirements.


    Your Input Matters

    Please take a moment and consider everything in this post. If you’re a plugin author, consider how your plugin(s) fits into the above categories, as well as if and how it uses the other two taxonomies. Then… leave your comments and questions! Your feedback is what helps makes the plugin directory great. 🙂

    A big, big thank you to both @ipstenu and @aaroncampbell for their input, help, and support on coming up with the proposals above.

     
    • David Anderson 10:10 pm on May 20, 2016 Permalink | Log in to Reply

      One thing that springs to mind: “Lite” – I’m not keen on that. Many plugins that have paid versions are more fully-featured than some that don’t (because the funds on paid versions have been used to beef up the free version more than another plugin without an income stream as been able to). “Lite” may give users the impression that it’s a lower on features than other plugins in the same category.

      • David Anderson 10:12 pm on May 20, 2016 Permalink | Log in to Reply

        And – which category would a backup plugin go in? Utilities? (Seems a bit of a catch-all category – lots of the other things are ‘utilities’).

        • Ipstenu (Mika Epstein) 11:51 pm on May 20, 2016 Permalink | Log in to Reply

          Utilities. And yes, we know it’s a catchall for ‘well, stuff’ but we want to start out with less than 30 buckets. Actually I was arguing we should have 20 or less, but reality is what it is. Surprisingly there aren’t as many ‘backup’ tagged as I thought. It may be something to move into a ‘Maintenance’ kind of section.

          • Jon Brown 1:18 am on May 21, 2016 Permalink | Log in to Reply

            I like the idea of Utilities and Tools being synonymous with the definition of: Things you run manually in the back end only, such as importers, S&R, flush rewrite rules, bulk delete spam, regenerate thumbnails, etc…

            • Samuel Sidler 1:58 am on May 21, 2016 Permalink

              The category names are definitely up for discussion and I think renaming Utilities to Utilities & Tools is a pretty good idea.

      • emanweb 10:16 pm on May 20, 2016 Permalink | Log in to Reply

        I also don’t think “lite” is the right term there. It may implicate that it’s a faster/quicker (lightweight) way to do the same thing as the premium/paid version. Perhaps “Free Version” instead of lite?

      • daverod 10:26 pm on May 20, 2016 Permalink | Log in to Reply

        Another NO vote for “Lite”. It implies “lesser functionality” and if you have an add-on model, it’s simply not accurate. I propose that you add a category for “Add On”, which implies the plugin itself it stand-alone. Lite is better for paid upgrades to a FULL version of a plugin. Totally different models.

        To sum up, I’d prefer:

        • Lite (for plugins with a paid upgrade to “Pro”)
        • Add on (for plugins with add-on model)
        • Service (for plugins requiring an external service of some sort, e.g. MailChimp or Infusionsoft)

        As for the categories–I have a Classified and Directory plugin. Do they go under “Business”? Or Discussion and Community? Or Maps & Location? Or do I get to choose more than one?

        Because if I’m stuck with ONE, my users will be hosed–the plugins have multiple uses and restricting me to a single category is death to my installs.

      • webaware 10:43 pm on May 20, 2016 Permalink | Log in to Reply

        Totally agree with others here, “lite” doesn’t clearly say what is intended. Why not something really clear like “has premium version” for plugins that actually are cut-down versions of premium products, and “has premium add-ons” for plugins that are extended by premium products? This recognises the two different realities that “lite” is attempting to capture.

    • Rhys Wynne 10:27 pm on May 20, 2016 Permalink | Log in to Reply

      I also don’t like the term “Lite”. It gives off an air of being lacking in features where in fact as mentioned above these plugins could be more feature packed than others. Would – for example – WooCommerce be considered “Lite”?

      Another question about the “built for” area. I understand it not being a free for all but could there be some implementation of non-WordPress services? It seems like an idea place that – should your plugin integrate with Facebook – you can put “Facebook” in the Built for Area.

      • Ipstenu (Mika Epstein) 11:55 pm on May 20, 2016 Permalink | Log in to Reply

        Woo would not be ‘lite’ since it has add-ons.

        Think more like … “Foobar plugin” and “Foobar plugin PRO”, where PRO is the same plugin with more features .

        Built-for would be for Plugins only right now. Maybe we’d need to list ‘common services’ though since built-for is an indication “If you install EDD blahblah without EDD, you’re kind of silly, aren’t you?” 🙂

        • Ionut Neagu 6:23 pm on May 24, 2016 Permalink | Log in to Reply

          Good point @Rhys!

          @Mika Woo offer add-ons because the niche is quite big, why Foobar plugin PRO is not an add-on of Foobar plugin as well ? At least this is what we did with one of our plugins, released just 1 PRO add-on, which require the free plugin installed.

          Lite isn’t the best term neither, some ‘lite’ plugins can be much better than full-featured ones, I think something like : “in-app purchase” that Apple have is a fair wording and should be applied to everybody who sell something on top of the plugin ( addons, pro etc ). Maybe something around “Paid Upgrades” can work .

      • Samuel Sidler 2:00 am on May 21, 2016 Permalink | Log in to Reply

        Ideally, plugins list the services they support – like Facebook, Twitter, Google, etc – in the plugin’s description. Built For is mostly about “do I need a plugin for this plugin” over anything else.

    • Samuel Wood (Otto) 10:29 pm on May 20, 2016 Permalink | Log in to Reply

      My only concern with choices for the Lite/Service things come down to the translations of those terms into other languages, rather than any specific connotation they might have in English.

      Perhaps we should ask the translation teams how they would translate those general concepts before deciding on what the actual terms should be, to avoid confusion all around. A better understanding of the concepts themselves and how they translate could give us better ideas on what terms to use.

      • emanweb 10:55 pm on May 20, 2016 Permalink | Log in to Reply

        Great point. Lite in Portuguese means “lightweight”.

      • Ipstenu (Mika Epstein) 11:53 pm on May 20, 2016 Permalink | Log in to Reply

        TBH, I didn’t like them either, but “Upgradable” and “Add-onable” sounded incredibly daft.

        We’re hoping with the explanations that it helps translations. And @samuelsidler said the descriptions of the tax’s would be on the page 🙂

        • Samuel Wood (Otto) 12:35 am on May 21, 2016 Permalink | Log in to Reply

          I know, but I’d like to find out how those would be translated before deciding on what they actually are. Because that would better inform the decision and maybe we could learn something interesting. Just a thought.

          I find that translation is often more about ideas than actual words, and honestly, I want to know how the concepts translate. Maybe we’re missing a beat there. Maybe not. Uncertain.

        • George Florea Banus 1:16 am on May 22, 2016 Permalink | Log in to Reply

          How about “Basic”?

          • Ionut Neagu 6:25 pm on May 24, 2016 Permalink | Log in to Reply

            How something like : “Paid upgrades available” sounds? I think the best example is Apple who says : “in-app purchase”, no lite or anything like that.

      • Samuel Sidler 2:01 am on May 21, 2016 Permalink | Log in to Reply

        To be honest, I don’t really like them either. 🙂 But hopefully something better emerges in the comments.

      • Rene Hermenau 8:22 am on May 21, 2016 Permalink | Log in to Reply

        That would fix the concern about translations into other languages at least makes it more clear in any translation:

        • Pay for Add-Ons / Pro
        • Pay for Support

        or

        • Pay for further Services

        The term “Add-Ons / Pro” includes all possible business models.
        There is no need to differentiate and categorize all available business models like Freemium, Lite, Pro, Saas etc. I think its ok to show if there is a business model behind a plugin or not so 1-2 terms are enough.

        That also makes it easier for a author if he/she is switching from a add-on model to a pro version or a SASS service.

        • Mark Root-Wiley 10:27 pm on May 21, 2016 Permalink | Log in to Reply

          +1 for “Freemium” being a boolean for all plugins. This also might make it possible to identify it in the directory with a simple icon (maybe an i18n-appropriate money symbol!).

      • Mayeenul Islam 8:53 am on May 21, 2016 Permalink | Log in to Reply

        +1. Yes, Lite in Bengali also means ‘lightweight’ (হালকা).

    • webaware 10:46 pm on May 20, 2016 Permalink | Log in to Reply

      “built for” — how will we suggest what a plugin is built for? Recognise that not all add-on targets are free plugins in the w.org repo, e.g. I have some add-ons for Gravity Forms.

    • Piet Bos 11:04 pm on May 20, 2016 Permalink | Log in to Reply

      Let me start by saying that it is great that you have put so much thought in it and I think that in general the proposal is great!

      I agree with others that Lite is not ideal. If you want to target the Business Model of the plugin, then it might be an idea to call it what it is, for example:

      • freemium
      • paid for support
      • paid for addons
      • requires a SaaS

      Anyways, great to see the changes in the Plugins Directory moving forward!

    • Jon Brown 11:56 pm on May 20, 2016 Permalink | Log in to Reply

      Categories overall look good. Certainly need a little refinement and probably the ability to evolve a little over time.

      Love “Built For” – an important question though is can a plugin be built for multiple other plugins? and must they be repo plugins? Let’s say I have a CATPCHA plugin that integrates seamlessly with both Contact Form 7, JetPack Feedback and Gravity Forms. Can I list all three? especially considering GF isn’t in the repo? Also, I really think we need to be able to say if a plugin is built for a specific theme, the biggest example is all the repo plugins built for Genesis that don’t work without Genesis.

      Personally, I’d vote for multiple built-for tags and the ability to get tags added for non-repo assets (ie. Gravity Forms, Genesis) through some kind of request system. That way it’s not free for all, even if it does mean some moderation headache.

      • Samuel Sidler 2:05 am on May 21, 2016 Permalink | Log in to Reply

        Certainly need a little refinement and probably the ability to evolve a little over time.

        Category names – which are just an initial attempt right now – will definitely evolve over time. New ones will be added, unused ones will be removed. Totally.

        Love “Built For” – an important question though is can a plugin be built for multiple other plugins? and must they be repo plugins?

        Initially, I think it only makes sense to allow a plugin to be “built for” one other plugin. There are logistical reasons, but it also doesn’t make sense to open the doors to unlimited “built for” plugins. That will certainly lead to spam. Eventually, however, it might make sense to grow that limit from one to three or five. We can play around with it and see how popular it is.

        That said, all “built for” options must be in the plugin directory. We could expand that to include the theme directory eventually, but they all must be on WordPress.org. If a plugin wants to support something outside of WordPress.org, they’ll need to mention it in their readme.

        • Marcel Pol 9:19 am on May 21, 2016 Permalink | Log in to Reply

          There are quite a lot of ‘glue’ plugins, like Yoast SEO – Qtranslate-X.

          Another issue would be all the WPML add-ons. Will popular commercial plugins be available as built-for, even if they are not in the repo?

        • ccprog 4:07 pm on May 21, 2016 Permalink | Log in to Reply

          Somehow the wording is not clear enough yet. “Built for” might be a lot of things on the scale between “needs to work”, “interacts with” and “is compatible to”.

          Your proposal seems to be much nearer to the “needs” side, but plugin authors may interpret that differently. Maybe the word “Addon” catches more the logistical aspect you want to convey? Or a friendly “Please also install”?

    • Jon Brown 12:02 am on May 21, 2016 Permalink | Log in to Reply

      I strongly dislike the Business Model taxonomy idea… especially when it’s termed “business model”. I’d like it better if it was a functional classifications like “3rd Party Service” vs. “Widget” vs “Developer Framework”.

      The one exception would be the simple term “Freemium”, that could cover any/all plugins that have a commercial upgrade path and it’s doesn’t cast a judgement over the free versions capabilities that terms like “lite” and “pro” would.

      Preference: drop “Bussiness Model” in favor of functional classifications.
      Secondary choice: drop judgement based terms in favor of _one_ and only one term “Freemium”

      I like Piet Bos’s suggestions above though… might even encourage users to think of paying for support instead of expecting it for free. Just to be “Paid addons” and “Freemium” are the same thing.

    • Jon Brown 1:24 am on May 21, 2016 Permalink | Log in to Reply

      On category names. Most of these seem like general functional categories. ie. Ecommerce, Contact Forms, User Management…

      I’m confused by: “Arts & Entertainment” and “Business”. What exactly would go in those categories?

      My assumption is most things in those two could be categorized better as:
      Directories – Portfolios, CRMs, Indexes of things like movies, recipes or stamps.

      • Samuel Sidler 2:11 am on May 21, 2016 Permalink | Log in to Reply

        I’m confused by: “Arts & Entertainment” and “Business”. What exactly would go in those categories?

        There’s some examples listed. Here’s some links.

        So, to answer your question, not really all or even mostly “directories” but there are a few results that are “directory”-like.

        Those two categories are especially prone to evolution (term-wise) over time.

        • Mark Root-Wiley 10:26 pm on May 21, 2016 Permalink | Log in to Reply

          I think Arts & Entertainment and Business pop out because they are content-related categories rather than functionality-related categories (and the 2-to-24 breakdown feels odd). If it makes sense to have such categories, then I [hate to say that] it may likely make sense to split them out more specifically.

          However, I would argue that they should both just go. I suspect that searching for “sports” (or more likely “soccer” or “cricket” or whatever) is much more likely a use-case than browsing Arts & Entertainment (I doubt many people think “sports” there). Browsing through these plugins, they would be easily searchable, almost always including the exact target niche in the plugin name.

          Categories based on content may also be counter-productive as many of these plugins intended for one niche can work well for plenty of others too (a common issue with themes too).

          *If* these categories stay, I would then shift my concern to confusion over the “Education & Support” Category

          ———

          Separately, in looking at the list, I think I see a few categories that may be too broad. Customization and Utilities jump out for this reason. For instance, I could imagine that nearly every “User Management” plugin might also get tagged as “Utilities”. If that’s the case, then either they should be further distinguished OR setup as a hierarchical taxonomy so things tagged “User Management” automatically are also Utilities.

          ———

          Looking at customization, I kind of want to split it somehow into “Design” and then something like “Featured Content” or “Content Management” (neither of those is quite right).

    • Bas Schuiling 3:07 am on May 21, 2016 Permalink | Log in to Reply

      On the lite discussion. There are quite some plugins that have a full feature set where the developer sells an advanced version with even more features that most people might not need. Lite also gives the wrong impression there, so does freemium and it doesn’t have to come in the form of addons. Paid support can also give the wrong idea if the WP support is still attended to.

      Main question will also be if vendors will volunteerly supply these tags. Let’s say a competitor doesn’t use those, why would anybody be willing to clearly supply limitations in the sake of honesty when it might hurt their business?

      • Marcel Pol 9:29 am on May 21, 2016 Permalink | Log in to Reply

        For the Paid Support, I can imagine Premium Support to be a better description. It will suggest that your support request will be in front of the queue.

      • Marcel Pol 9:34 am on May 21, 2016 Permalink | Log in to Reply

        Another thing, it would be great if these three taxonomies could be cross-searched, like you are on a page with all plugins that are Add-on, Calendar, and built-for WooCommerce, if that would be even possible :).

    • jeffmcneill 4:58 am on May 21, 2016 Permalink | Log in to Reply

      For business/money aspect, the idea of “freemium” makes sense to people, same with lite/pro, the idea is there is also a paid version. In addition, there is the paid-plugins-available option (note how this is made clear when one downloads an app from an app store for mobile devices, e.g., offers in-app purchases). Also, if an app requires a service to function, that should be declared, whether paid or free. This is important for security/privacy as well as reliability. There should be a clear way, which may require a few extra words, to point out these dependencies and options:

      • Paid version also available
      • Paid plugin extensions also available
      • Requires 3rd party service to function
      • Paid 3rd party service available for additional functionality

      On other notes, the generic “Arts and Entertainment” and “Business” are too general, should break these out into things like scheduling/calendar, media, content management, etc.

    • Syed Balkhi 8:09 am on May 21, 2016 Permalink | Log in to Reply

      Don’t like the Lite label because line is blurry. Does any plugin that has addons become Lite? WooCommerce, ACF, EDD, etc aren’t Lite plugins.

      I think we should encourage authors to name their Lite plugins as Lite if it’s a Lite plugin (such as WPForms Lite) – https://wordpress.org/plugins/wpforms-lite/

      As for the actual tag for business model – I think we should have:

      Free
      Freemium
      Service

      Each are fairly self-explanatory.

      As for Categories, that’s a good start. There’s no one solution that will fix everything. Some plugins will fall in multiple categories which is why I suggested a Category / pre-defined Tags option in the earlier discussions.

      That would also allow you to narrow down top level categories.

      Example:

      Marketing

      • SEO
      • Analytics
      • Advertising
      • Lead Generation
      • Affiliates
      • Social Sharing

      eCommerce

      • Billing & Invoices
      • Donations
      • Membership & Subscriptions
      • Payment Gateways

      Site Administration

      • Performance
      • Monitoring
      • Security
      • Maintenance
      • Utilities

      Media

      • Galleries
      • Sliders
      • Maps
      • Videos

      Communication

      • Contact Forms
      • Polls / Surveys
      • Email Newsletters
      • Forums
      • Comments

      That’s just to get the ball rolling.

    • Mayeenul Islam 9:01 am on May 21, 2016 Permalink | Log in to Reply

      A business model can change anytime for a plugin. A plugin comes up with Premium version in mind can set mind for several Add ons later. But SVN repo and plugin URL cannot be changed later.
      Yoast SEO, by URL, still a WordPress SEO https://wordpress.org/plugins/wordpress-seo/
      WP Smush, by URL, still a WP Smushit! https://wordpress.org/plugins/wp-smushit/

      May not the issue here, but things to consider IMHO.

    • Marcel Pol 9:26 am on May 21, 2016 Permalink | Log in to Reply

      The Business model is opt-in. But if my plugin has a Premium version, commercial Add-ons and a service based thingie, what would be my incentive to advertise that :).
      Would it not be too easy to give a false sense of free by not tagging it with any term and seem 100% free?

      I can imagine a term like ‘100% Free’ so it gives the plugins that do neither of this a way to stand out, and a way to be searched/listed.
      I think the 100% Free plugins are a good thing on their own, and sometimes you really are searching for that.

      • Andrew Ozz 2:23 pm on May 21, 2016 Permalink | Log in to Reply

        I can imagine a term like ‘100% Free’…

        All WordPress plugins are already 100% free (like in freedom) because of the GPL. Plugins with PRO versions still have to publish their PRO source freely or they will be breaking the GPL, right?

      • Joy 2:54 pm on May 23, 2016 Permalink | Log in to Reply

        I agree and wonder why this taxonomy is needed at all on a directory where all the code is free. It’s not a directory of the Pro versions, so why are we talking about it?

    • abrain 4:06 pm on May 21, 2016 Permalink | Log in to Reply

      I struggle to find a suitable category for my plugin. It provides a custom post type with custom taxonomies so that fire fighters or rescue services have a standardized way to present their latest missions/operations. It’s basically still a regular WordPress post, but spiced up with additional information.

      Since they are organized by date, this could be something for the “Calendar & Events” category, but I would expect this category to be about plugins for future events. “Customization” seems to be layout-focused and in my eyes it doesn’t even fit the catch-all “Utilities”.

      Maybe the category “Taxonomy” could be enhanced to include this kind of post type?

      • Marcel Pol 5:48 pm on May 21, 2016 Permalink | Log in to Reply

        Sounds like a Portfolio. It sounds like the Business category might fit, like Real Estate portfolio. It’s just that this is a non-profit, and Business has the sound of being more commercial.

      • Samuel Sidler 6:37 pm on May 21, 2016 Permalink | Log in to Reply

        Interesting! Thanks for commenting! 🙂

        There are a couple of things we can do with the categories that might help. First, your plugin can use more than one category. I’d definitely recommend using Taxonomy as one. I also think renaming “Business” to something more like “Business & Non-profit” would help. “Calendar & Events” was supposed to cover scheduling, which has some overlap here, but the name “Calendar & Events” doesn’t sound right. We might need to tweak it a bit more. /cc @ipstenu

        (For those following along, this is the plugin.)

    • J.D. Grimes 7:18 pm on May 21, 2016 Permalink | Log in to Reply

      As for the categories, how would one place a plugin that adds badges, points, awards, ranks, etc. to a site? I’m not sure that that would fit in the Arts and Entertainment category. It might be related to Discussion and Community as well, but I’m not sure that is the right fit either.

    • Aaron Jorbin 3:58 am on May 22, 2016 Permalink | Log in to Reply

      An idea for the Business Model taxonomy: Have a larger number of options, and have them voted on by the end user for each individual plugin. Only the top vote receiver would generally be highlighted in the UI. These terms could range from “Free as in Beer” to the generally positive such as “Serviceware” and “Add-ons available” down to things like “Advertising that is annoying AF” and “Crippleware”.

    • Maeve Lander 6:25 am on May 22, 2016 Permalink | Log in to Reply

      Love the idea of more taxonomies to help users filter plugins.

      Categories look like a great starting point IMO.

      I agree that ‘lite’ is an unsuitable descriptor. I also think that providing specific labels for describing other people’s business models is potentially limiting… Ok, yes, there are a handful of very commonly used plugin business models but one of the most important and attractive things about WordPress is the variety of the ecosystem. Would specific labels limit innovation?

      Idea: How about a “Support Offered” taxonomy?

      • Free Support
      • Paid Support Available
      • Unsupported

      I think a Support taxonomy would be helpful quite separate to the business model taxonomy… but potentially if you drop the business model taxonomy idea then the Support taxonomy would give users a pretty good clue as to the nature of the business model… without explicitly saying so?

    • Joy 7:04 pm on May 22, 2016 Permalink | Log in to Reply

      I can understand where this list of categories came from since we only had tags to start with, but using those tags as the base going forward is perhaps misguided.

      Since plugins are all about functionality being added to the core, what if the categories were about how/where the functionality is added? So the two most basic categories would be Front-end and Back-end, but you could just skip those and use all the core elements as categories, with the addition of one or more categories for custom extensions.
      Each core menu item in the back-end would be a category, or maybe since those are nouns, finding all the corresponding verbs would be a better match to plugin functionality types. The front-end is a bit more difficult to describe, but I’m thinking that a separation between front-end functionality and back-end functionality could be a very good thing.

    • Joy 7:24 pm on May 22, 2016 Permalink | Log in to Reply

      I don’t like the “Built For” taxonomy. It sounds like what you are after is “Dependency”. Given that it is optional (I assume), it could encompass depending on other plugins or 3rd party services or even versions of PHP or WordPress.

      I wrote a plugin that merges two settings files from a theme. So it’s not dependent on any plugin, but it is dependent on a theme. (not that it won’t work without it running, but you have no input without having used that theme)
      With the proposed categories, my plugin would go under Utilities, and show nothing under Built For.

    • Darren Ethier (nerrad) 2:31 pm on May 23, 2016 Permalink | Log in to Reply

      Another classification type I’d like to see is something to indicate “complexity of use” or “how easy/hard it is to setup”. This could help end users get some idea of what they can expect in terms of ease of using the plugin.

      For instance, some plugins may just be a drop-in plugin where there is no setup involved, other plugins might have some setup involved but its all via options in the WP dashboard, other plugins might require some theme customization, and yet others might require access to and ability to configure the server.

      Admittedly, this classification could be subjective, but if there is a small subset of descriptive words used, along with a somewhat clear definition of what those words represent, it might work (and be useful to end users).

      To kick things off, something like:

      • Drop In: This plugin has no options panel or customization, just activate and go.
      • Easy: This plugin can be just activated and used as-is but there are some options that can be used to tweak behaviour.
      • Moderate: This plugin has settings that must be completed before the plugin will work.
      • Hard: This plugin requires a specific server configuration/editing of files in order to function as expected (i.e. hyperdb).
    • Ahmad Awais 7:13 am on May 24, 2016 Permalink | Log in to Reply

      I like both the idea of categories and “built-for” plugins but the lite plugin’s idea is a bit unclear. Where do we draw the line?

    • Remkus de Vries 7:16 am on May 24, 2016 Permalink | Log in to Reply

      With regards to the built-for taxonomy. You propose to limit it to just one term. So how do you propose to handle a plugin that for instance provides integration with WooCommerce, EDD, BuddyPress and/or bbPress specifically for the Genesis Framework?

      • Joy 1:54 pm on May 25, 2016 Permalink | Log in to Reply

        You might have hit on something here. Integration is not the same as compatibility, yet it evokes an interesting way to categorize plugins. What if there was a way to indicate whether the plugin does things the WordPress way or not? It’s easier to integrate by using filters and actions and the core database tables. It’s much more difficult when those are ignored, and the plugin does its job its own way.
        I have spent a lot of time evaluating plugins from the standpoint of creating a complex functionality by writing only a little glue to hold together the several plugins that already do most of what I want. It is very time consuming to install and try, or read the code to figure out what I need.

        One of the criteria I use when a client wants a shopping cart is “where is the data stored?”, because it could be posts, custom post types, separate tables, files. This is important because of how the products are displayed, searched, categorized: like every other post, like a custom post, totally up to the plugin. Imagine trying to put a star rating on each product: every post gets it(not just products), only posts get it(not custom post type), products in separate tables unaffected without fragile glue code.

        The Built For taxonomy doesn’t go far enough, as it only shows a relationship between 2 plugins, and it’s optional. What is needed is a way to get the author to document the key parts of how to integrate with the plugin (or how it integrates with WordPress). A list of tables modified (or created), filters, actions could really help. I think there are tools already that can supply some of this.

    • Guido 1:50 pm on May 25, 2016 Permalink | Log in to Reply

      Great idea, searching for the right plugin will be easier with this feature. And this keeps a plugin author from giving a plugin all kinds of non-relevant tags.

  • Mark Uraine 9:41 pm on May 20, 2016 Permalink |
    Tags: ,   

    Plugin Directory Prototypes (Single View) 

    Yesterday, you saw the mockups and prototypes of the Plugin Directory homepage and search results. Today, I’d like to share the “single view” plugin page mockup. The single view is the primary page for all plugins.

    Like the earlier mockups, the content is not accurate and the entire page is still undergoing changes.

    Prototypes

    You can play around with the prototype here: http://codepen.io/mapk/full/YqJezm/

    Screenshot

    Single View

    Single View

    Notes

    1. Many details are still being worked out.
    2. Some views still need to be created, like the ‘Reviews’ and ‘Support’ views.
    3. The ability to ‘favorite’ a plugin still needs to be designed.
    4. The ‘Ratings’ section is far from complete.
     
    • Ipstenu (Mika Epstein) 11:47 pm on May 20, 2016 Permalink | Log in to Reply

      Screenshots … any chance of that being a lightbox gallery? Since some plugins have a few, it would be nice to click and scroll through.

      • Samuel Wood (Otto) 12:45 am on May 21, 2016 Permalink | Log in to Reply

        I like a lightbox there for technical reasons, but we have to consider it on mobile as well. Yes, but needs testing.

      • Samuel Sidler 1:48 am on May 21, 2016 Permalink | Log in to Reply

        Like Otto says, yes, but needs testing. The “Screenshots” section was meant to show an initial screenshot with an indication that there’s more if you click. We’ll have to play around with that section a bit to get it right, for sure.

    • webaware 12:12 am on May 21, 2016 Permalink | Log in to Reply

      “This plugin is also available in…” — what’s that going to be like for plugins like WooCommerce with 34 language translations (so far)?

      • Samuel Sidler 1:35 am on May 21, 2016 Permalink | Log in to Reply

        The locale message only shows languages relevant to you. It’s based on a GeoIP lookup and your accept-lang header from your browser. It does not show all languages a plugin is in.

        • Alin Marcu 6:21 am on May 21, 2016 Permalink | Log in to Reply

          I wonder if we could have a Translations section in the sidebar. A simple section with a CTA similar to Theme Directory.

    • Jon Brown 12:51 am on May 21, 2016 Permalink | Log in to Reply

      I like the overall aesthetic, just not the rearranging of layout and info.

      I find the tabbed desc/screenshots much easier to navigate between then jumping up and down the page.

      I do notice and appreciate the idea here of bringing the screenshots up the page in this design by hiding the description behind a read more.

      FAQ and Changelog. When I need to see those most often I’m going to that plugin’s page to find those specifically and having to find them via scrolling is going to suck. At the very least this needs TOC navigation.

      So, while I’d be cool with combining Description and Screenshots onto the same page (in most cases), I think throwing it ALL on one page is a mistake that hurts usability even with a TOC.

      Actually… considering the screenshots on the page a bit more… some plugins have 1 screenshot, some have a dozens of images. That fact makes the “everything on one page” even less workable. I guess maybe the screenshots could be in a light boxed gallery. Then however, you’d need a way to add useful longer form descriptions to each image visible inside the gallery… questionable if that’s really better usability than a dedicated screenshots page.

    • Jon Brown 1:06 am on May 21, 2016 Permalink | Log in to Reply

      (see screenshot) https://cloudup.com/cwJV2I0Kte1

      1. I think “Built For” should be much more prominent in the title header, not the sidebar
      2. Notice banners for languages seems unwieldy. Could it just be language flags, or 2 letter language codes/icons in the header? De, Zh, En…
      3. In the home/search results thread @NateWr had an interesting idea to add a progress bar style indicator.
      http://codepen.io/anon/pen/xVoWQW
      I think that poses a really interesting way to present support threads responded to.

      • Jon Brown 1:09 am on May 21, 2016 Permalink | Log in to Reply

        In the screenshot I suggsted only showing the developer tab to logged in users. I forgot that for most (I still use the Chrome Extension “WordPress.org Plugins SVN Link”) that the svn/trac links are only accessible behind that tab… people shouldn’t need to login/have accounts to find the link to the source code on trac.

        Beta on the other hand… probably could be hidden from unauthenticated users.

      • Samuel Sidler 1:44 am on May 21, 2016 Permalink | Log in to Reply

        1. It’s worth exploring making Built For more prominent.
        2. There’s no such thing as “language flags.” Flags do not indicate languages, they indicate countries (or other specific governmental locations). Languages (more specifically, locales) very often exist across borders. Further, two letter language codes – which are sometimes three letter language codes, or five character language codes like en_UK – are not helpful for users. The directory is built for users. I don’t think the size of them is unreasonable as it’s important to send users to the best possible plugin directory and plugin. Further, see my comment above about how we don’t show every language.
        3. I think this is worth exploring, yeah. I’m not sure a progress bar is the best indicator, but the concept of simplifying support “activity” is a pretty good one.

        To respond to the subnav comment in the screenshot, I think it’s important to show Developers, regardless of if a user is logged in or not. How will a new developer know they need an account?

        On beta testing… I think it’s an important tab too. We want people to test our beta plugins (feature projects) as much as possible. Making them more visible has helped with that in the current plugin directory.

    • jeffmcneill 1:40 am on May 21, 2016 Permalink | Log in to Reply

      I like what I see with three caveats:

      • Screenshots on the same page slows down everything, and is not needed, as hopefully people click through to see such things
      • A lightbox display and even more images again would slow things down, anything requiring seeing more images on a landing page is problematic
      • Mostly screenshots are either not present or not helpful for evaluating the plugin, so that should not be pushed above other information
      • I agree with the screenshots on another tab approach.
      • I agree with dispensing with the installation information as that is usually the same for every, single, plugin
      • jeffmcneill 1:42 am on May 21, 2016 Permalink | Log in to Reply

        Can’t edit comment, so I’ll just add that I also think that FAQs and reviews should also be in separate tabbed dialog as well.

      • Samuel Sidler 1:47 am on May 21, 2016 Permalink | Log in to Reply

        When they exist, screenshots are a primary way that users evaluate plugins. We can use JS to only load the first screenshot and load the rest in a lightbox or in a gallery mode, in which case we’d only load thumbnails by default. One of the goals of this page is to present users with the most important information up front, and less important information further down, or even hidden, so they can make an informed decision.

    • Ulrich 5:34 am on May 21, 2016 Permalink | Log in to Reply

      This is a nice redesign. I agree a lightbox would be good for the screenshots as now some times the screenshot is too small to see and you could see more once it is full screen.

      What I did not expect was to find the developer links under contributors. Maybe move it to its own section separate from the contributors. There is also a small bug clicking the “show more” button to see to rest of the version it gets cut off after a few version and you don’t see all of them.

      Related to the contributors section have you thought about plugins that have multiple developers working on it and it may not be fair just to mention one person in the header and the rest lower down.

      • Mark Uraine 7:14 pm on May 25, 2016 Permalink | Log in to Reply

        We’re exploring taxonomy between ‘Developers’ and ‘Contributors’. For now ‘Developers’ wouldn’t be good because there’s also a ‘Developers’ in the sub navigation in the blue bar at the top. We don’t want to have things named the same but go to different sections.

    • Joy 6:15 am on May 21, 2016 Permalink | Log in to Reply

      I do not like this prototype. All of the important information is below the fold.
      The banner on the mockup is huge, and the plugin name is below that. The rating should not be before the details such as version and update date, etc.
      I agree that having it all on one page makes it a hassle. The tabs work much better since you can click on the info you want without scrolling. (And I currently hesitate to click on Screenshots because it loads so slowly.)
      I don’t like having the authors at the bottom. I prefer seeing them near the link for support.
      I don’t think the blue stripe at the top is useful on the plugin detail page. It is wasted space. The current design is better, with that stuff in the left sidebar.
      Does the sign-in box live in a section that’s not shown here?

    • dartiss 9:22 am on May 21, 2016 Permalink | Log in to Reply

      I like it 🙂 However, will there still be the donation link in the final version?

      One other thing, above what we’ve had before (and I suspect this will provoke comment) but any chance of some way of indicating revision dates (without relying on the author to hand type them into the changelog)? Also, does anybody think there’s mileage in a PHP compatibility version?

      • Samuel Sidler 12:00 pm on May 21, 2016 Permalink | Log in to Reply

        However, will there still be the donation link in the final version?

        Yes! We’re still iterating, but we definitely want to display the donation link. 🙂

    • Rene Hermenau 9:49 am on May 21, 2016 Permalink | Log in to Reply

      The banner should have the same size or at least the same ratio than the current banners have. Otherwise all plugin authors have to recreate their banners which results in a endless numbers of broken and very ugly appearing plugin pages.

      The toggle read more links lead to problems for plugins with very large plugin description. If you click on such a read more link, you have to scroll a very long way until you are able to use the other tabs.

      Having the tab navigation sticking on top of the plugin page seems to be the better way as it allows us to jump more quickly between the tabs.

    • ccprog 4:35 pm on May 21, 2016 Permalink | Log in to Reply

      Until now, I tried to give configuration/usage instructions on the plugin page. With the streamlined accordion folds, this comes definitely to an end. (That’s okay, the current tabs are not very user-friendly as they are.) So, why don’t you include a standard place to link to an external manual? A lot of plugins have them, anyway.

      Another fold that may be interesting is a privacy policy.

    • webdevmattcrom 9:58 pm on May 21, 2016 Permalink | Log in to Reply

      I like the overall idea, but having ALL that information on one page feels like overkill. I’d much prefer that the less important information was available as an AJAX tab (rather than the current page refresh tabs).

      Also, “Plugin Details” is the most important information. It should not have the “Read More” expander at all. Having that for other sections is fine.

      Agree with others that a lightbox for screenshots with captions would be excellent.

      Agree with Jon Brown that “Built With” needs to have more prominence.

      Also love Jon’s suggestion regarding a Progress Bar for the resolved Support tickets.

      In terms of importance of sections, I’d order them like this:

      • Plugin Details (no “Read More”)
      • Screenshots
      • Reviews
      • FAQs
      • Contributors
      • Changelog (singular I believe, not plural, right?)
    • Mark Root-Wiley 10:00 pm on May 21, 2016 Permalink | Log in to Reply

      Overall I like this a lot. Unlike some other commenters, I think the ability to highlight one FAQ, for instance, will help draw people to that section. However, I think there may be a big SEO/UX problem with the hidden content. Google’s current webmaster guidelines include the following:

      Make your site’s important content visible by default. Google is able to crawl HTML content hidden inside navigational elements such as tabs or expanding sections, however we consider this content less accessible to users, and believe that you should make your most important information visible in the default page view.

      Ref: https://support.google.com/webmasters/answer/35769?hl=en (Ironically hidden in an accordion…)

      Worse, if users do see search snippets that include hidden text, they’ll have a heck of a time finding it (even in-page search wouldn’t work without expanding all the sections first). I like the summaries of each section, but I would really recommend keeping the individual FAQ and Other Notes page. Just generally speaking, accordions and hidden content in general have some serious UX issues (https://www.nngroup.com/articles/accordions-complex-content/).

      Other than that:

      +1 on lightbox

      I’ve always found the Support link hard to find in the Theme directory so moving it here makes me nervous. Maybe it’s just a consistency issue, but I never hesitate when going to the Plugin Support forum for a plugin.

    • ccprog 1:34 am on May 22, 2016 Permalink | Log in to Reply

      Just encountered a bug: expand “Contributors” (the developer links are really a suprise at this place). Then, click “Show more” under “Other Versions” – the extra content disappears inivisibly below the “Close” and cannot be brought into view.

      • Mark Uraine 8:56 pm on May 25, 2016 Permalink | Log in to Reply

        Yes, thanks… as mentioned this is still in development and preliminary design stages. We’re aware of this bug. 🙂

    • Aaron Jorbin 4:02 am on May 22, 2016 Permalink | Log in to Reply

      👍

    • Joy 8:03 pm on May 22, 2016 Permalink | Log in to Reply

      Currently, when you are in the WordPress back-end and you search for a plugin to add, this page comes up in a lightbox (View details). Will that be changing, or do we need to keep in mind that it is accessed from there as well as a stand-alone page?

    • NateWr 5:23 pm on May 23, 2016 Permalink | Log in to Reply

      I really like the direction this is going in by moving away from the tabbed approach. Bringing screenshots onto the main page is great.

      And I am very grateful you’ve raised the profile of the FAQ! Maybe we can even add a button next to the Support button on the right which says “Read FAQ”.

      I’d like to make a suggestion building on @mrwweb‘s concerns regarding the Read More links and SEO/usability.

      • Use the expandable Read More for the Plugin Details section, but double the height shown by default. This provides sufficient room for a lot of the key information that can be pretty important for a plugin (usage, instructions, key feature list). But it won’t bury other things miles down on a page for plugins that dump a ton of info here.
      • For the other sections, show one or two items for each section (FAQ, Reviews, Changelogs, Contributors) and turn the existing read more expander into a link that jumps to a separate page with more information.

      On a different note, just want to +1 the suggestion to raise the prominent of the Built For info.

      But I really like the direction here.

      • NateWr 8:55 am on May 24, 2016 Permalink | Log in to Reply

        Here is a CodePen showing some of the suggested changes:

        http://codepen.io/anon/pen/wGVQEb

        • Double’s default height of visible plugin description
        • Uses actual links instead of read more links for other content sections
        • Moves Built For into the plugin header to increase prominence
        • Changes display of “Lite” tag card to make it seem slightly less like a positive “badge”
        • Adds “View FAQ” button to the support section
        • Joy 2:32 pm on May 25, 2016 Permalink | Log in to Reply

          I hope you realize that the least useful thing (banner) is most prominent and the most useful thing (version number, support, update date, active installs) is at the bottom or below the fold (depending on screen size).

    • Greg Ichneumon Brown 4:07 pm on May 25, 2016 Permalink | Log in to Reply

      Assuming the “built for” taxonomy is added, it may be nice to include a list of plugins that are related to the current plugin. Probably sorted similarly to how search gets sorted. Encourage plugins to build on each other and help users find plugins that build off of ones they are already using.

  • Mark Uraine 6:57 pm on May 19, 2016 Permalink |
    Tags: ,   

    Plugin Directory Prototypes 

    When we created the design for the ‘Get WordPress’ page, it was meant to set a new design standard for WordPress.org sites. As a result, here are here are some new designs for the home page and search results page of the Plugin Directory.

    Keep in mind that these are still preliminary and the content is not accurate.

    Prototypes

    You can play around with the prototypes here:

    Screenshots

    Homepage

    Homepage

    Search Results

    Search Results

     

    Notes

    1. Homepage
      1. Again, individual plugin information is not accurate.
      2. The terminology for “pro” and “light” are explorations for design purposes. (Look for a taxonomy post on this blog in the near future.)
      3. The three sections at the bottom will have links to their respective subpages.
    2. Search Results
      1. Typing a keyword in the search field will replace the content area with search results.
      2. Pagination still needs some work.

    We continue to iterate quickly and a second post on the design of the plugin detail page is forthcoming.

    If you have any feedback on the design, please comment below. We’d love to know what you think! 🙂

     
    • Pippin Williamson 7:00 pm on May 19, 2016 Permalink | Log in to Reply

      I really like these.

    • Ulrich 7:07 pm on May 19, 2016 Permalink | Log in to Reply

      This are really nice. I don’t think we need the slider.

    • Jon Brown 7:12 pm on May 19, 2016 Permalink | Log in to Reply

      I really don’t like these. At first look I don’t and I’m not just playing devil’s advocate here, let me explain.

      First, I’m assuming the homepage design for each plugin carries over to the search results, yes?

      The lack of any kind of border around each plugin on the homepage makes it really hard for me to find the data I care about when visually scanning results. I find the current “card” style layout a lot easier to scan visually.

      I’ve never liked the idea of a “featured” category, I’d be curious if the bulk of users find it help though. Still, don’t like the idea at all of putting that in a slider. Ironically if there _is_ a slider shown on plugin per slide, I’d be onboard with THAT content not having a card/frame/border since it’s not butted up against other plugins the way the grid does.

      I did however like the quick link menu to features/popular/favorites/beta. Is that going away?

      • Jon Brown 7:32 pm on May 19, 2016 Permalink | Log in to Reply

        Ok, so now I’m not sure about my assumption on the search results page. If it’s actually cards on off color background like this: https://cloudup.com/c6pazw4BMxR that seems a batter design language then the borderless design shown on the homepage mockup above.

        If not… much more white space is needed between things IMHO.

      • Tom J Nowell 7:40 am on May 20, 2016 Permalink | Log in to Reply

        +1 sliders and carousels are great at solving political problems and internal squabbles, and terrible for everything else

        We’d be better off with something like the top section of the verge with a handful of large tiles or blocks rather than a slider

      • Mark Uraine 5:49 pm on May 23, 2016 Permalink | Log in to Reply

        The ‘quick’ links exist now in context rather than in a sidebar.

    • Zach Tirrell 8:03 pm on May 19, 2016 Permalink | Log in to Reply

      Certainly the goal here appears to be simplification, which is appreciated, but I wonder if too much has been stripped away. The current site presents the following additional information:

      • author (this may only be useful for insiders)
      • last updated date
      • approximate active installs
      • compatible up to version

      Personally, I find the “approximate active installs” to be really helpful in picking the right plugin out of search results.

      • Samuel Sidler 10:40 pm on May 19, 2016 Permalink | Log in to Reply

        In thinking through IA for users, I can’t think of how the author, last updated date, or compatible version are useful.

        Author, as you said, is only really useful for insiders. The latter two, meanwhile, are already taken into account in the search results. If a plugin doesn’t have a recent compatible version, it will move down the list. If it’s too old, it won’t get shown at all (which is the case today).

        Active installs is more interesting, but we account for it weighting search results as-is. I actually find it refreshing to not show the active installs as it allows for less-popular plugins to get more downloads. Users will be less likely to click the popular plugins (outside of familiar names) and more likely to find the plugin they actually need.

        Does that make sense?

        • Jon Brown 12:49 am on May 20, 2016 Permalink | Log in to Reply

          Insiders use the directory too and Author is certainly important to me. Given 7 plugins for something if I recognize one of the authors from another plugin I trust, it’s a very important data point. Plus I also often forget the name of a plugin I like but remember “Oh that Avatar ordering plugin by Jake”.

          Compatible is a different story. Reporting of compatibility is so poor for most plugins that it’s meaningless.

          Download count was meaningless, but I find active installs a useful metric. I’d certainly weight ratings (in spite of their issues) and search term relevance much higher than the install number, but I like seeing it and in spite of also wishing it was less important in search result weighting. I’m still blown away when I accidentally stumble upon a plugin with < 1,000 installs that does what I need way better than those with 100,000's of installs. That's always been a great frustration point of the directory, discoverability of anything new.

          Updated date only becomes important when active installs is low… I could care less if a plugin with 100,000s installs hasn't been updated in 18 months. If a plugin only has 100 installs _and_ hasn't been updated in 18 months I'd be much more concerned.

          • Samuel Sidler 2:44 am on May 20, 2016 Permalink | Log in to Reply

            Plus I also often forget the name of a plugin I like but remember “Oh that Avatar ordering plugin by Jake”.

            Aren’t you describing a situation where you search for an author and “avatar” and see the author’s “avatar” plugins first? Search should support this use case, absolutely.

            I’m still blown away when I accidentally stumble upon a plugin with < 1,000 installs that does what I need way better than those with 100,000's of installs.

            This is exactly the situation I think it’s important to create! And one reason I don’t think we should visibly prioritize active installs. 🙂 This information will still be available, just not in the search results where they’re less interesting and useful. To download, users will still have to visit the plugin detail page (where the download button is) and hopefully do more research at that time as well.

            • Jon Brown 12:13 am on May 21, 2016 Permalink

              Author Search – Actually the user story is more like this:

              1. I need that Avatar/Page Ordering plugin I used before… can’t remember the name of it, but it was by someone whose name I recall

              2. Search for “Avatar”

              3. Visually scan results and notice that there is a popular one written by Author X which jogs my memory…

              Sometimes, yes, I recall the author name up front, but more often I don’t it’s memory that needs the visual indicator in the search results to jog.

              Search Results – I’m hopeful the new search result (Elasticsearch) will be more on target, but again I still would rather have much _more_ info directly on the search result page without clicking through. Behavior for me tends to go one of two ways:

              1. Review search results, pick one, click through and install it. Once I’ve clicked through I don’t really read much/anything on that single page. Decision already made, based on active installs, ratings, author name. On the search results page currently the most _meaningless_ bit of info is the description excerpt. That’s WAY to short to be helpful.

              2. Review search results, option click 5 of them and then go about reading the description page, jumping between browser tabs and trying to make a decision… comparing description with screenshots.

              Having longer form descriptions on the search results that were actually meaningful, would be a huge help IMHO. If not, eliminating the excerpt in favor of active installs and author name would make sense to me…

            • Joy 2:57 pm on May 22, 2016 Permalink

              To download, users will still have to visit the plugin detail page (where the download button is) and hopefully do more research at that time as well.

              You bring up a good point — is this page the same page that users see in the admin, in a lightbox? or are these being designed at the same time? — because from within the Add New Plugin admin panel, you can install without going to the plugin detail page.

        • jeffmcneill 2:37 am on May 20, 2016 Permalink | Log in to Reply

          When trying to find a particular plugin (that I know exists or existed) or looking for candidate plugins for a particular use, I use all of these criteria: author, last updated, active installs. Last updated and compatible up to are approximately the same, and last updated is more helpful to me.

          I agree that active installs is problematic, just as is the star rating. For example, plugins go bad, either through not being updated, or bad updates, and a previous history of downloads and stars does not necessarily help with assessing the current version.

      • webaware 1:50 am on May 20, 2016 Permalink | Log in to Reply

        Agree that author, last updated, and approximate active installs are useful information. I use all three in selecting plugins. Compatible up to version is next to meaningless.

      • Jme 9:14 pm on May 20, 2016 Permalink | Log in to Reply

        Agree 100%. I look to the author, last updated, compatible and active installs EVERY TIME, I search the repo. This is important information that needs to be there.

        • Jme 9:16 pm on May 20, 2016 Permalink | Log in to Reply

          Just to add – I don’t think I should have to click the plugin’s link to find that information that is very useful. I can scan the information that is important to me (and certainly many others) quickly the way it is now.

    • Awaken Solutions Inc. 12:20 am on May 20, 2016 Permalink | Log in to Reply

      I like the sharp clean look, thank you!

      I would like to be able to see active installs (your point is well taken Samuel, but I personally still like to see it).

      Plugin author(s) is sometimes useful to differentiate plugins with common names (e.g. Maintenance Mode) and to quickly see their profile. But I am not as attached to it as active installs.

      Keep up the good work.

      • Awaken Solutions Inc. 1:59 am on May 20, 2016 Permalink | Log in to Reply

        Perhaps you could have a toggle for Simple/Advanced view. Simple could be the default view, allowing you to achieve the minimalist design you’re striving for, while Advanced view could show an extra div for each plugin with the extra info (and the choice could be remembered so that users who prefer this always see it).

        • Samuel Sidler 4:18 am on May 20, 2016 Permalink | Log in to Reply

          Just like WordPress core, we strive to design for the majority and build features for the 80%. An “advanced” view doesn’t meet that requirement, in my eyes.

          • FolioVision 2:46 am on May 23, 2016 Permalink | Log in to Reply

            Great idea, Awaken.

            Samuel, plugin search is a work tool for most of us. If you want to cripple default, put an advanced view in for those of us at work and not “playing around with a cool blogging tool”. If WordPress.org won’t do reasonable search, I can tell you that the plugin directory will be partially replaced by third party tools (which seems extremely wasteful of everyone’s time when we have a working tool which just needs slightly better search and the design elements brought up to date).

            As Mark Root-Wiley notes carefully below WordPress professionals really need this information:

            1. last updated
            2. active installs

            Personally I very much like to see author name as I know whose work to see and whose work I like to avoid (for either bad code or poor commercial ethics). Authors and brands should get some credit. Author unlike the two above is not make or break.

            Where you are right, we could care less about compatibility notices (they are wrong 90% of the time even if Foliovision’s are usually up to date now in what is really a makework project for those of us with more than two or three plugins).

            Alec

    • Joy 1:34 am on May 20, 2016 Permalink | Log in to Reply

      I don’t see any improvement over the current Plugin Directory page. In fact, the current one needs more data points, not fewer. I always want to see the current version number in the list instead of having to click through to the plugin page to see the version.
      I agree that the “Compatible up to” field is worthless.

      I personally do not like the thumbnails ever since they were added. It makes the list harder to read. If they must be there, move them to the right so that the title is leftmost and easier to find.

      One update that is needed is how the search works. Right now, I can type the full name of an old plugin and it does not come up in the search. But lots of unrelated plugins are shown. Just because a plugin is old or has not been updated lately does not mean is not well-written and useful.

      I can’t tell if the mockup page is showing where the slider goes and then below is what is in the slider, or if those sections would always be visible. Either way, it is a waste of bandwidth to always show a list of featured, trending, or popular plugins. A slider is overhead for very little use it would get. (See http://wpthemetutorial.com/2014/06/19/online-store-need-slider/ )
      The three little paragraphs at the bottom makes it seem that the page is changing focus. Is it the Plugin Directory or just Plugins? (meaning there is more on the developer side to point to)

      I also can’t tell if there is a WordPress header or menu above the blue Plugins header. If not, there’s a problem.

      For the search results, I like how the current page says “Showing 1-30 of 1,000+ plugins” instead of the proposed “Search results for: xxx”. It would be nice if we could choose how many to see, and sort them different ways, or even highlight the words that matched.

      • Joy 1:55 am on May 20, 2016 Permalink | Log in to Reply

        I forgot to mention that a Plugin Directory should show all the plugins. If the search is weighted against older plugins, how can you ever see them? I think assumptions are made about how the directory is used. Yes, the majority of searches is by site owners needing some functionality. But there are also students learning how to code things in WordPress, plugin authors researching ideas (coverage and competition), and others just poking around to see what has been done.

        I think more taxonomy should be used to present the default view of the plugins, and the search should match more closely what is searched for. The tag page ( https://wordpress.org/plugins/tags/ ) might not be best but it does give an interesting overall view of the total. If you are adding more taxonomy, please use it so that someone can drill down and see everything that is there.

      • Mark Uraine 6:05 pm on May 23, 2016 Permalink | Log in to Reply

        The section that says “slider” is where the slider would exist. Tom had some great feedback regarding an alternative to the slider above.
        While this is the Plugin Directory, it will provide access to other Plugin related content similarly to how it works now.
        Yes, there exists a WordPress.org header and footer outside of the content of the mockups.
        I agree, showing more info about how many search results exist is important. We’ll include that as well.

    • jeffmcneill 2:45 am on May 20, 2016 Permalink | Log in to Reply

      I would also like to add to the voices that ask for more data, not less. A basic sorting/filtering ability would help a lot. Every time I run into a dead end, I have to search again. Some suggestions:

      • Have categories and have plugins put into categories (machine and human sorting). Things like “mailing list plugins,” “contact form plugins,” would help a lot. Of course plugins can be in multiple categories, but the hit-or-miss with tags just doesn’t do it. Being able to search within categories would help a lot.
      • Have lists rather than cards as a display option. A list with 100 items would be way more useful to scan than cards, when people are looking for one particular piece of info (such as author or title). Being able to sort on the main columns such as last updated, author, active installs, plugin name. Also, in many cases I am looking for older plugins, the initial commit date would be extremely useful.
      • In sum, more information in the interface, a higher level of data-to-ink ratio, and more ability to interact with that data. Display in cards and such is nice, but as currently presented there is less, not more. And in some cases, less is less.
    • Maeve Lander 2:49 am on May 20, 2016 Permalink | Log in to Reply

      I really like these design aesthetic wise. The overall look and feel is clean, spacious and very user friendly.

      Constructive critism:

      On plugin listing tiles I feel the following fields are essential:
      + author
      + last updated
      + approximate active installs

      The homepage slider seems unnessary and not in line with current design trends

      On Search Results page I think it needs a search button or icon. Enter key works for those in the know but WordPress UI needs to cater to all levels.

      I would like to see some more advanced filters for search. Perhaps start with an ‘order by’ dropdown?

      • Samuel Sidler 3:56 am on May 20, 2016 Permalink | Log in to Reply

        On plugin listing tiles I feel the following fields are essential:

        What makes you feel these are necessary? What information is conveyed that’s important when determining the quality of a plugin?

        On Search Results page I think it needs a search button or icon. Enter key works for those in the know but WordPress UI needs to cater to all levels.

        Noted. 🙂

        I would like to see some more advanced filters for search. Perhaps start with an ‘order by’ dropdown?

        Personally, I’m not a fan of filters. It’s more useful if you can search for specific things and the search knows what you’re looking for.

        One thing that’s great about us redoing the plugin directory – and it being open source – is we can keep iterating and anyone can help add features, if it’s determined they’re right for the 80/20 case. 🙂

        • Adam W. Warner 1:53 pm on May 20, 2016 Permalink | Log in to Reply

          Reading through and wanted to offer my reply why I think the following are necessary.

          + author
          + last updated
          + approximate active installs

          These all play into the trust factor for me.

          Author – If I’ve seen the same Author several times when searching for or using plugins in the admin, when I see that same Author listed on something new I’m considering, I would be more likely to give it a go.

          Last Updated – is it actively developed? = trust

          Active Installs = follow the masses = trust

        • Maeve Lander 6:56 am on May 22, 2016 Permalink | Log in to Reply

          What makes you feel these are necessary? What information is conveyed that’s important when determining the quality of a plugin?

          *Author – helps me recognise a trustworthy author (maybe I’m familiar with their work, or their community contributions, or reputation etc) and helps me recall / differentiate plugins with similar names at a glance.

          • Last Updated – gives me a clue if the plugin is under active development
          • Approx Active Installs – gives me a clue as to how popular / well used the plugin is.

          I accept that none of these things are definitive proof of a good quality plugin… but taken together all these small signs ARE meaningful when searching and filtering the plugin directory.

          Personally, I’m not a fan of filters. It’s more useful if you can search for specific things and the search knows what you’re looking for.

          I think the new taxonomies you’re proposing in another thread serve the same aim as filters – a way for users to cross-reference search keyword with other criteria.

          I’m a definite +1 for the taxonomies but I do also still think that users should have the control to list by last updated date, active installs, rating etc

      • Paal Joachim Romdahl 8:40 pm on May 22, 2016 Permalink | Log in to Reply

        +1

    • jeffmcneill 2:58 am on May 20, 2016 Permalink | Log in to Reply

      I’ve got to say that the Light and Pro (and normal) are unclear. Pro usually means paid in the world of plugins, so I think it may be misleading. Saying Contact Form 7 is light also is not quite clear, as there is no Pro version (or is there?).

      Also, I vote against the slider. Sliders don’t work https://www.google.co.th/search?q=sliders+dont+work

    • Thomas Townsend 4:33 am on May 20, 2016 Permalink | Log in to Reply

      I do like the clean design aesthetics – but I also would rather have more information, not less. Don’t delete any of the current data that’s being provided. Make it indexable and searchable by keywords,categories install numbers and rating. Those are all important to users and developers alike.

    • Milap 5:52 am on May 20, 2016 Permalink | Log in to Reply

      Wow, neat and clean interface. Loved it.

    • Golam Samdani 6:26 am on May 20, 2016 Permalink | Log in to Reply

      Nice.. Liked it …

    • Robin W 7:38 am on May 20, 2016 Permalink | Log in to Reply

      Like the general design. I Have to add votes for plugin author, last updated, and active installs- if I like a plugin by an author, I am far more likely to choose another by them, and their thought processes will be like mine. Users of my 7 plugins have said that they look for me as an author when choosing further plugins. Last updated tells me that this plugin is active, and whilst it may be that WP sorts plugins by some populatiry criteria I didn’t know this – you don’t publish the search sort order criteria so how am I siupposed to know why the results appear as they do???? 🙂 I also don’t know for a group of plugin results whether the first is 10,000 active installs and the second 3 active installs, or the first 10,000 and the second 9,999. I would also say that ‘featured’ has always put me off – it smacks of some sort of paid advertising which whilst I know it isn’t, I suspect many ‘ordinary’ users think is a paid area.

    • Rene Hermenau 8:31 am on May 20, 2016 Permalink | Log in to Reply

      @mapk From a developer perspective there are too many points missing: Author, Active Installs, Compatible, and Last Update are very important fields to find best suitable plugins.

      We need these fields as long as we have no advanced search functionality that allows us to filter the search results for these properties. So these ones should not be removed!

      No one wants to click on a search result only to see on the plugins page that the plugin was updated 1 year ago or does not support the current WP version.

      The WordPress plugin search is not popular for the power of showing very relevant search results so the 30 results per page should be kept.

      I like the prominent search field but can not see a reason for a slider. That thing is from the last decade:)

      Anyway, good to see the continuous progress, i better like to see progress than standstill so i welcome a new design at all. Thanks for sharing the mockups and letting us participate on the development.

      • Mark Uraine 6:23 pm on May 23, 2016 Permalink | Log in to Reply

        Thanks! Your voice is being echoed through many of the replies. I will note that the search functionality is being upgraded to resolve this.

    • NateWr 9:19 am on May 20, 2016 Permalink | Log in to Reply

      Great work on the aesthetic. I think you’re moving in a great direction.

      I share a number of the concerns that have been voiced here around clarity and usefulness of the data that is presented (or not presented). But having been through a these kinds of redesigns myself, I know there’s a lot that goes into the decision-making process and it’s not always easy to see that from the outside.

      Has there been any document generated that outlines the goals of the redesign, or contains personas specifying target audiences and needs? I’d be really interested to see who and what this redesign is targeting, as I feel like most of my concerns stem from there rather than the particularities of what you’ve presented (which looks great).

      One specific point I would raise, though, is that the plugins without badges look like they’re lacking something. This may be the wrong message to send if what is really meant is “this is totally free and without any extra payment requirements or dependencies”.

    • NateWr 10:03 am on May 20, 2016 Permalink | Log in to Reply

      A couple of ideas on the aesthestic side of things.

      I find filled/un-filled stars to be difficult to parse when they’re all a bright color on a light background. At a glance it all looks like 5-star ratings, even if it’s a 2-star rating, because the orange on white lines are not very crisp on un-filled stars.

      The following CodePen mocks up a couple of ideas for dealing with that.

      http://codepen.io/anon/pen/xVoWQW

      • ACF uses light grey for un-filled stars, so that there’s one more point of distinction between filled and un-filled stars.
      • Really Simple CATPCHA offers an alternate approach that uses bars instead of stars. It also proposes a way to get active installs in there in a bit more of an at-a-glance presentation.

      On a separate note, I felt the badges (light/pro) had a really heavy visual weight. The CodePen above shows a possible alternate presentation that’s a bit lighter (Really Simple CAPTCHA).

      • Samuel Sidler 4:19 pm on May 20, 2016 Permalink | Log in to Reply

        Thanks for the mockup!

        ACF uses light grey for un-filled stars, so that there’s one more point of distinction between filled and un-filled stars.

        I don’t think this is necessarily a bad idea, but it’s inconsistent with how core does it… Which doesn’t mean it can’t change! But we have to consider both contexts in the medium term. It certainly doesn’t look bad. 🙂

        Really Simple CATPCHA offers an alternate approach that uses bars instead of stars. It also proposes a way to get active installs in there in a bit more of an at-a-glance presentation.

        It’s an interesting approach. It reminds me of a progress bar, fwiw, which isn’t really the information we’re trying to convey.

        For example, plugin authors aren’t necessarily trying to have millions of users (think of multisite-only plugins), and conveying the active installs like that almost makes it seem bad that they haven’t reached that level. The active install metric also doesn’t speak at all to the quality of a plugin.

        On ratings, I think the above is also true, though arguably less so. Once a plugin author gets a 1-star review, they can never get fill that bar, which would kind of suck.

        On a separate note, I felt the badges (light/pro) had a really heavy visual weight. The CodePen above shows a possible alternate presentation that’s a bit lighter (Really Simple CAPTCHA.

        Interesting concept and I think it’s worth exploring in another iteration. I’m glad you noticed that those terms aren’t final and played around with your own. 🙂 Look for a post on taxonomy here on make/meta in the not-too-distant future.

        • NateWr 4:40 pm on May 23, 2016 Permalink | Log in to Reply

          > it’s inconsistent with how core does it

          Ah of course. The directory should mimic core wherever possible.

          > It reminds me of a progress bar, fwiw,

          It does! Good thinking. Here’s a mockup showing an alternate presentation which reduces the visual echoes of a progress bar by removing the grey background bar.

          http://codepen.io/anon/pen/YqmYdK

          > For example, plugin authors aren’t necessarily trying to have millions of users (think of multisite-only plugins), and conveying the active installs like that almost makes it seem bad that they haven’t reached that level.

          My assumption is that in a large number of cases people are going to be comparing like for like plugins. On the upper end they’re going to be looking for one of a set of well-established plugin types (eCommerce, SEO, security, contact forms, etc). On the lower end they’re going to be looking for more of a niche plugin (reviews, bookings, mailchimp integrations, etc).

          In each case, an active installs bar acts as a useful _relative_ metric. All search results could be in the 5-20k range and it would still provide a useful at-a-glance indication of a plugin’s popularity. This assumes the bar used the active install stages (100+, 1k+ 10k+) as meaningful segments, rather than just using 10k = 1% width.

          > The active install metric also doesn’t speak at all to the quality of a plugin.

          This is why a clear document outlining the goals and assumptions behind the redesign would be really useful. I think a lot of the feedback so far would take issue with this statement, but it’s hard when such assertions are buried in one-off comments like this rather than made explicitly in a document alongside other goals and assertions regarding user behaviour, preferences and information.

          I believe active installs deserve a place alongside ratings as the _most useful_ metrics we have and the most difficult metrics to game. I’ve outlined the problems that I think star ratings have as an at-a-glance metric (they cluster near the top so the user is often looking at a dozen plugins with 4-4.5 ratings).

          You’re right that active installs grant a certain power of incumbency. And we can dispute whether this incumbency is deserved on a plugin-by-plugin basis. But this incumbency is often hard won over many years. It may not be perfect, but it’s the closest thing we have to long-term validation of a plugin’s continuing usefulness and maintenance record.

          It speaks of a plugin’s presence, which is a really meaningful metric in a sea of fire-and-forget offerings in the directory.

          (I don’t know if I’ve used the right in-line markup techniques so apologies if the quotes don’t come out as quotes.)

    • Nathan Johnson 3:55 pm on May 20, 2016 Permalink | Log in to Reply

      Please don’t use a slider. They don’t work.

    • Jon Brown 4:24 pm on May 20, 2016 Permalink | Log in to Reply

      Thinking about the search results page mockup which shows 10 results. I think this should show fewer and larger cards, maybe 5 results where the top result is full width, or 6 at most even they stay equal sized. I think the goal on this page should be giving the searcher all the information they need to make a choice right there without needing to click through each for more detailed info. Further, we should avoid giving them more results then they want or need. Frankly If the best/most relevant result is in the 9th slot, the search algo has failed (hoping the project to improve that succeds)

      • Jon Brown 12:34 am on May 21, 2016 Permalink | Log in to Reply

      • Joy 5:30 am on May 21, 2016 Permalink | Log in to Reply

        With 40,000 plugins, it would be a rare search that only 5 are good results.
        Using the current search, I often search and find lots of matches on page 2 or 3 or 5. And usually, I end up installing several before finding the one for my client’s situation. Or I download several to look at the code.

    • Greg Ichneumon Brown 9:22 pm on May 20, 2016 Permalink | Log in to Reply

      A couple of ideas on the search page:

      • How about instant search results? Search as the user types. The backend should be able to support it. That also gets rid of the need for a search button.
      • Rather than paging through search results, let’s just do infinite scroll. Good way to enable smaller/newer plugins that won’t rank very high to be found. That would also necessitate an easy way to get back to the top of the search box if the user hasn’t found what they want.
      • I assume that the “see all” links for Popular, Trending, Beta will all just go to a search results page? Does that imply that those other pages are sorted differently than the main search page? Can you search within that page?

      We probably can’t allow paging all the way to the end of the search results. Tends to cause performance problems. The only things that ever do this are bots anyways. Usually good to limit to 200 results.

      An additional idea beyond the Popular, Trending (I’m not sure the current data I’ve seen can do this ranking, btw), and Beta categories is to have a list of popular plugin authors. This would be a ranking of plugin authors based on the sum of their installed counts across all their plugins. If you are browsing this seems like a good way to surface quality plugins from people who have already built and maintain high quality plugins.

      • Mark Uraine 7:00 pm on May 23, 2016 Permalink | Log in to Reply

        The ‘instant search’ is definitely something we’re exploring as well. I’m not entirely sure this will be ready for the MVP launch, but it is in our sites.

        Infinite scroll is a possibility as well.

        Yes, ideally you should be able to search within targeted/filtered pages like “trending”.

    • apsolut 9:33 pm on May 20, 2016 Permalink | Log in to Reply

      I love bootstrap but masterhead as new WP standars isnt going to work in long term…

      Slider = If we are talking about usable thing only slider thing that can work is Card etc like google play and others…

      Also why less informations and is there any document (brainstorm,thunderthings) on paper what you want, what is new look and objectives for this new bootstrap thing?

      Important: Author, Rating, Version, Last change…

      New eCommerce category?

      Search results?

      • In boxes is there more informations or bigger image
      • Mark Uraine 7:03 pm on May 23, 2016 Permalink | Log in to Reply

        Just to clarify, we’re not using Bootstrap.

        Search results page will be displayed the same way the plugins are displayed on the homepage.

        • Joy 2:40 pm on May 24, 2016 Permalink | Log in to Reply

          I think the assumption that the Plugins landing page shows any plugins is the biggest problem with the redesign. The landing page should show the overview in the form of the new taxonomies, maybe even with counts for each section. You should be able to choose a section to browse or search. The landing page should look totally different than the search results.
          I think it should be approached as if it were a really big store, who wants to show off *all* of its inventory (not just a few).

          • Joy 8:24 pm on May 26, 2016 Permalink | Log in to Reply

            Here is a mockup of what I think the Plugins Directory should look like, using the tentative list of categories suggested in the Taxonomy post.
            http://codepen.io/anon/pen/PzYWwQ
            As I said in the other post, I think it would make more sense if it showed the part of WordPress being extended, starting with Front-End and Back-End. But that is for the other discussion.
            The Plugins landing page should give an overview of the total and make it easy to drill down.

        • apsolut 8:37 am on May 26, 2016 Permalink | Log in to Reply

          Didn’t say that you are using BT, but I would be crazy to say it don’t look like it (just another big hero BT thing).
          I expected more, deep thinking of Usability, long term improvements for all users, what if this, what if that….

          • Mark Uraine 4:09 pm on May 26, 2016 Permalink | Log in to Reply

            That’s great to expect that because that’s the whole point of this post actually. We’re trying to gather EVERYONE’s opinions and thoughts. Do you have some alternative solutions you’d like to share like some of the others?

    • Ross Wintle 10:00 pm on May 20, 2016 Permalink | Log in to Reply

      Regarding the author, active installs, and last updated data, the question “What information is conveyed that’s important when determining the quality of a plugin?” has been asked.

      The answer here is “trust”. Plugins are a very weak point of security for WordPress and trusting a plugin is key.

      If a plugin is low quality, few people will use it (the inverse is not necessarily true). So active installs is a good measure of trustworthiness.

      If I know the community well, I know certain people who care a lot about code quality and security. So if I’m an “insider” then yes, author is a good measure of trustworthiness too.

      If I want a plugin to be bug-fixed, secure, compatible with the latest version of core, and sustainable going forward then yes, last-updates is a good measure of trustworthiness too.

      I use these data points all the time. Though, actually, what’s more likely is I’ll use a plugin based on a trusted recommendation rather than what I see in the directory.

      I applaud the goal of trying to elimate the self-reinforcing active-installs measure and surface new and less-well-used plugins. But less-well-used could equate to poor quality, insecure, and out-of-date. So while I don’t think removing the data is helpful, I equally don’t know what a good solution to meeting this goal is.

      • Joy 5:41 am on May 21, 2016 Permalink | Log in to Reply

        These data points don’t show if you can trust a plugin, although I agree that trust is very important.
        Recent updates can mean poor coding (lots of small fixes) or no change (just update to change the compatible version number).
        Low number of installs can mean that the plugin is new or does something nobody wants.
        It helps me to see the version number itself. If it is very low, I will hesitate to install it on a client site. A lot of times, I have to read the change log to see how often the plugin is updated and if the fixes are major or minor.

      • Samuel Sidler 12:20 pm on May 21, 2016 Permalink | Log in to Reply

        If a plugin is low quality, few people will use it (the inverse is not necessarily true). So active installs is a good measure of trustworthiness.

        If the inverse is not necessarily true – and I agree that it’s not – then how is showing active installs a good measure of trustworthiness?

        If I know the community well, I know certain people who care a lot about code quality and security. So if I’m an “insider” then yes, author is a good measure of trustworthiness too.

        Those are two big “if” statements that can’t possibly be true for the majority of users. Let’s consider some numbers.

        How many WordPress users are there? We know there’s millions of sites (26.4% of the internet!) but we have no way of getting an exact number of individual WordPress users. Let’s guess and say there’s a million people in the world that use a WordPress installation and are able to install plugins (so, discounting WordPress.com, “author” roles, etc).

        How many people know the community well, aka, are an “insider”? Well, we can guess a bit better by saying that a large majority of insiders attended a WordCamp or Meetup. We have WordCamp ticket stats from 2015, and meetup stats from 2014. Without even accounting for duplicates – some people attend both meetups and WordCamps, some people attend multiple meetups and/or multiple WordCamps – we’re only at ~40,000.

        The plugin directory wasn’t created for 40,000 insiders, it was created for the million WordPress users who manage sites. I think that’s important to consider when considering designs. (See also, the WordPress core philosophy of “design for the majority” and the “80% principe.”)

        If I want a plugin to be bug-fixed, secure, compatible with the latest version of core, and sustainable going forward then yes, last-updates is a good measure of trustworthiness too.

        But… why does that make it worth displaying? If a plugin is recently updated, that’s a useful metric. But what is “recent” in that context? The specific date doesn’t seem important, rather that it was within a range. Shouldn’t search account for this when displaying results so users don’t have to think about it? Currently we hide plugins from search if they haven’t been updated within the last 2 years. One way we could improve that is by slowly lowering a plugin’s ranking in the search result the older it gets, until, ultimately, it disappears after some set time limit (again, currently that’s 2 years, but could be any 1 or 5 years or any other interval). Doing that would make it much less important to display.

        • Joy 3:22 pm on May 22, 2016 Permalink | Log in to Reply

          If the inverse is not necessarily true – and I agree that it’s not – then how is showing active installs a good measure of trustworthiness?

          I think the active installs number indicates that a plugin is fulfilling its stated objective for a certain number of its users. The number of downloads would be way larger. Maybe a more useful number is a ratio of downloads to active installs, but then a plugin with a lot of updates has more downloads, and more updates does not equate to better plugin. I have a site that I use at least two plugins that are not the most recent version, because the recent versions broke my site. Problems were reported and not addressed, so I use the older versions.

          If a plugin is recently updated, that’s a useful metric.

          Really, it’s not as useful as everyone here seems to think.

          Shouldn’t search account for this when displaying results so users don’t have to think about it?

          NO! it shouldn’t. That assumes you know what 80% of your users want, and you just described how you can’t even know how many people that is. A directory of information should provide a way to display that information in an unbiased way and let the humans decide how they want to use it. If that means reducing the number of plugins stored, then that is better than misrepresenting what is there, some of which can’t be found anyway(with the current search). This is the basic premise of why the Google search algorithm is better than the ones that came before it. The first ones let factors like money and influence determine what was shown first on the search.

    • edanzer 10:00 pm on May 20, 2016 Permalink | Log in to Reply

      Overall I like the design. I’m not sure I like it a LOT more than the current design, but I like it.

      That said, I strongly agree with the thrust of the feedback here that the interface strips out too much data about individual plugins. While you may weigh certain things in the search results, the bigger question is whether users themselves want to use that same data to make their own decisions.

      In many cases they do. I know I specifically give weight to active installs and author and last updated date every time I look for a plugin in a space where I don’t already have a favorite.

      In a sense, you’re trying to make choices for me/for others, and suggesting I don’t need to see certain data because it’s in the algorithm. But honestly, I often find the results that come from the plugin search algorithm very poor. The choices I end up wanting are often buried further down. And those choices are often dictated by things like author, active installs, and last updated date.

      You asked further up what it is specifically that people are trying to get from those data points. The answer, I think, is that it’s all about trust and comparisons. All of us triangulate trust by combining and comparing ratings, reviews, size/active installs, author, last updated date, etc.

      And this is the crux of the problem: There’s basically zero way to gage trust and compare plugins in the new interface. Well, not zero – you have reviews. But that’s an extremely partial indicator. A plugin with 300 installs that hasn’t been updated in 18 months but has two 5 start reviews left a year ago (probably by the plugin authors) would look great in this interface, but I’d never trust/choose that plugin if I could see and compare more data across plugins.

      With this interface, my selection of plugins would be come very cumbersome. The only way to do even a basic comparison would be to open up an individual plugin page and find the data; and then open up another plugin, find the data; and then another and another; and then flip back and forth between plugin pages to compare.

      For me the whole point of providing that data in the search results has been to make it more efficient to compare plugins. Indeed, like many others, I’d want to see more data available for scanning in the results, not less.

      My sense is you are giving a lot of weight to design and discoverability of new plugins, which are both great, but letting that overrule the way most users actually want to select their plugins.

      • edanzer 10:11 pm on May 20, 2016 Permalink | Log in to Reply

        One other thought – if one of the goals is discoverability of new plugins, I’d think a great way to do that would be to add a ‘trending’ component to plugin statistics. Then show that stat in search results, and use it in the algorithm.

        There are a lot of ways to calculate trending or growth statistics. Imagine two plugins with trending/growth statistics like this:

        Plugin A: This plugin’s active install base has grown by 835% in the last 6 months.

        Plugin B: This plugin’s active install base has declined by 20% in the last 6 months.

        It’s worth noting that a % based stat like the above is strongly predisposed to favor new plugins since adding 10,000 users is a big deal if you’re starting at 10,000, and must less big deal if you are starting at 300,000.

        In short: I think the way to encourage growth of great new plugins is to find stats that capture their new greatness and add those stats to the search result pages so they influence plugin selection (vs just removing all data so no one can tell, which makes plugin selection almost random).

      • Mark Uraine 7:20 pm on May 23, 2016 Permalink | Log in to Reply

        But honestly, I often find the results that come from the plugin search algorithm very poor.

        This is being resolved with the new Plugin Directory.

    • Mark Root-Wiley 10:14 pm on May 20, 2016 Permalink | Log in to Reply

      GOALS?

      There’s some nice stuff going on here with these designs. As a few others have mentioned, I feel like I’m having a hard time evaluating these designs because I’m not really sure what the goal is (beyond “new”). Some constructive feedback.

      SLIDER

      This feels particularly acute with the slider. I am 100% against sliders (https://mrwweb.com/do-not-use-slideshow-for-nonprofit-websites/) in nearly every instance and am especially suspicious when there’s no purpose stated for its inclusion. Sliders don’t work and weigh down pages, so I’d just strip it.

      In place of the slider, what about a dismissable “Welcome to WordPress, Here’s What Plugins Are” panel, similar to the Dashboard’s “About” panel on new installs. That could even lead visitors through some of the popular and trending plugin pages while also imbuing some good best practices while they’re at it.

      LISTING PAGE COMPARISON USABILITY

      If the goal is to make it easier to scan and find plugins, then I think some usability research should be done first. I’d start with these two Nielsen-Norman articles about how users use search/listing/comparison pages on desktop and mobile:
      https://www.nngroup.com/articles/list-entries/
      https://www.nngroup.com/articles/image-vs-list-mobile-navigation/

      From those, I’m not sure that the “card” approach best facilitates plugin comparison which I assume is the primary goal of these pages.

      ADDITIONAL META

      If I had to order the new missing meta in order of what I’d bring back first:

      1. last updated
      2. active installs
      ——————————— big drop off in usefulness
      3. author
      4. compatible up to version

      I rely on author a lot, but realize that I’m firmly in the 20% of the 80/20 rule @samuelsidler rightly points to. What if the meta wasn’t displayed but users could sort by installs and last updated?

      “BADGES”
      As others have mentioned, I feel like the weight of these is too much. As at least one other pointed out, this would seem to benefit stripped-down plugins with paid options over full-featured entirely free plugins.

      HOME PAGE
      I would *never* guess you could click on those three boxes at the bottom of the page. How about some color and underlining!?

    • Syed Balkhi 7:56 am on May 21, 2016 Permalink | Log in to Reply

      First, Thank you Sam and Mark for leading this initiative. Absolutely love the new style.

      Tons of great feedback here already and I wanted to drop my 2 cents.

      I feel that two items are missing from the results that in my opinion are extremely valuable for beginner users.

      1. Author Name – If there’s a SendGrid plugin by SendGrid Inc., then I want to use that instead of third-party plugin. Now I understand that sometimes these “official” companies may not keep their plugin up to date (i.e Facebook) or third-party developers who do a much better job than official plugin (i.e Danny Van Kooten MC4WP) — but nonetheless, this is an important use case.

      Second, it helps users learn more about the author – I thought that’s why we added those badges to the profile pages to highlight authors that contribute, speak at WordCamps, giveback to the community, etc.

      Lastly intermediate / DIY / power users, prefer picking plugins from trusted / familiar authors. Perhaps I already have a plugin that Pippin built so now his name will be familiar when I look up another tool.

      2. Active Installs – as a user, I would rather start with something that has more active installs and then work my way down (if the popular one isn’t good enough). But it’s better than aimlessly going through dozens of plugins. I absolutely don’t buy the rich get richer argument here because if the popular plugin isn’t good enough – people will switch. W3TC is a good example of that right now. Yoast SEO is another (when AIOSEO was dominant). Ninja Forms is another good example – despite CF7 being around.

      Maybe this information was removed because the border-less layout didn’t allow for additional information like that to be displayed while still looking pretty?? In that case, I’d much rather pick a card style layout with borders that has the important info rather than not. Usability > Pretty.

      As for the slider, I don’t think it’s needed when you already have popular / trending / beta plugins. Instead I’d suggest adding another section called New plugins.

      Lastly on the badges, I suggest Free / Freemium / Service (leaving this as a comment on the other post).

      • Mark Uraine 7:39 pm on May 23, 2016 Permalink | Log in to Reply

        1. Author Name – If there’s a SendGrid plugin by SendGrid Inc., then I want to use that instead of third-party plugin.

        Excellent argument that definitely pertains to the 80%. Thanks!

        Maybe this information was removed because the border-less layout didn’t allow for additional information like that to be displayed while still looking pretty??

        Definitely not the reason information was removed. Information is easy to add back, but a lot more difficult to remove once it’s there. I want to make sure that the information we display is valuable, and not there just because it’s always been there. This involves posts like this where we start minimally with the bare essentials and make sure there’s some really strong reasons before adding more.

        Thanks for the feedback!

    • Juan Hernando 9:37 am on May 21, 2016 Permalink | Log in to Reply

      Hi! I really like the direction the new design is getting 🙂

      About the slider, I’m not sure about what info will go there and why it should be in a slider (best places to hide something in the Internet, second page of Google results and inside a slider). If it’s going to be just info about the plugins section, I’ll just show it at once, if it’s going to be some featured plugins or so, I’ll just make a distinction in its section. For example, make the most popular one or the two most with a different background in its ‘card’, just to show more importance.

      About the info missing that’s been talked a lot in the comments, I agree that we (that 20%) tend to use that info a lot. I understand that it’s good to clean everything and make the plugin section easier for the 80%, so we don’t need to make posts about ‘How to choose the correct plugin depending on X factors’, because we have a search/listing good enough so they get the best results atop of the page.

      But maybe we can have a little icon (bar/chart icon) next to the star rating, and when we go on hover, it shows a tooltip with the info about number of installs, last update, or even the author. So, it doesn’t mess the cleaner interface, but it’s for the 100% of the people (more or less).

    • myatu 7:08 pm on May 21, 2016 Permalink | Log in to Reply

      Just a few quick notes:

      • It doesn’t make very good use of the screen real estate
      • I agree with another comment, to ensure the author name (lead author) is shown (or at least search by).
      • Add a section for “New and updated plugins”, as that may give a plugin a better chance of becoming a “rising star” (discovery). Of course have counter measures for those who’ll abuse that by auto-publishing every day or so,
      • Make better use of tags / taxonomies on the home page — this is where switching to the taxonomies described by Samuel would work excellent. The current system hides potentially very good plugins (and may also be leading to quite a few similar plugins being developed).
    • David Anderson 9:29 am on May 23, 2016 Permalink | Log in to Reply

      I agree with those who’d like to see the “number of active installs” metric immediately visible. This tells me how many sites are relying on a plugin – which helps to indicate whether I might want to rely on it too. Of course, it’s not an infallible indicator of that – but, that isn’t really relevant, because *nothing* infallibly indicates that. But it is one of the most useful signals in this area, and hence I find it useful to have it as one of the most prominent indicators.

    • illusiodesign 10:35 am on May 23, 2016 Permalink | Log in to Reply

      We generally only install plugins that have been updated within three to five months. Please include the “last updated date” as its highly usable information.

      “Pro” and “light” doesn’t seem very helpful so consider replacing with the updated date.

    • KevinLycett 2:00 pm on May 23, 2016 Permalink | Log in to Reply

      last updated date
      approximate active installs
      compatible up to version
      These are all *extremely* useful in quickly finding a plugin. There are so many plugins and it takes so long to check out every one on offer that these are essential tools to help filter out the noise. They save me a *lot* of time.

    • Scott Wyden Kivowitz 2:29 pm on May 23, 2016 Permalink | Log in to Reply

      I agree with many of the points here. I will add that I feel strongly that the star ratings and review count shouldn’t be included when no other data is there. Because reviews are not always honest, and people are more likely to leave bad reviews than good reviews. So it does more harm than good in most cases. Active count would be much better when only showing 1 data point.

    • NateWr 5:06 pm on May 23, 2016 Permalink | Log in to Reply

      I’d like to make one more case for reconsidering the approach to the 80/20 rule here.

      I am a big fan of the 80/20 rule in design and strongly believe in getting irrelevant or confusing data out of the way. But I’m a little nervous about how it’s being applied here, as well as the lack of information we have about who the 80% are.

      When placing under-used information out of the way, the goal is usually to reduce cognitive load and therefore increase focus on the information that remains. In this case, by stripping away so many details, we’ve left the user with only marketing material (title, description and plugin icon) and a star rating. Is that the right material for a user to find and select a plugin?

      There are two parts to answering the question of what’s right for the 80%. The first is what will the user be able to understand and use? What matters to them and which pieces of data do they value?

      The second is more subtle but also more powerful: what are we telling the user is important? The new design of the plugin directory will signal to novice users what information they should value. If we’re showing a star rating as the only social metric, and giving it a very prominent visual presentation, then we’re training the 80% to believe it’s the most important metric for judging a plugin.

      This is where the 80/20 distinction needs a little bit more nuance when using it to make design decisions. There’s a strong component of stewardship here and the plugin directory redesign is an opportunity to redesign how we communicate priorities.

      In this sense, only the top 5% of experienced users may care about a metric. But that shouldn’t immediately disqualify it from presentation. The question that should be asked isn’t “what does the 80% do” but “what do we want to encourage the 80% to do”.

    • nosilver4u 9:06 pm on May 23, 2016 Permalink | Log in to Reply

      Seems I’m a bit in the minority, but I’m a plugin author, and I rarely ever look at who the author of a plugin is, much less make decisions based on that. The one exception would be as Syed Balkhi indicated: sometimes you’re looking for the official plugin released by a particular company, and the author field can be helpful there, but otherwise I almost never use it.
      Active installs and last updated definitely ARE fields that I check every time before I install a plugin, as well as the average rating.
      I’ve seen a couple places (including some comments at WP Tavern) where there seems to be an emphasis on trying to promote new plugins. We used to have a “newest plugins” listing, perhaps the search results could indicate “new” plugins, or have some sort of sidebar featuring new plugins that wouldn’t otherwise make it into the results weighted for ratings, active installs, etc.

    • Graham Armfield 11:15 am on May 25, 2016 Permalink | Log in to Reply

      I know these are just designs at the moment, but at some point someone is going to code these for real, So I just wanted to mention the accessibility word, and provide some comments from that angle:

      1) Like many commenters above I dislike sliders (carousels), but if you intend to use one, they can be tricky to get right from an accessibility perspective. There is a fairly new guide to doing them right here: https://www.w3.org/WAI/tutorials/carousels/

      2) Headings: Good to have a hierarchical heading structure for the page. Ideally H1 Plugins – H2 Popular Plugins – H3 Plugin #1 – H3 Plugin #2 – H2 Trending Plugins – H3 Plugin #1 – etc

      3) Alternate text for the images that go with plugins.

      4) The star rating needs to be accessible to those using screen readers – use alternate text on an image or maybe some screen reader text to say “3 stars out of 5”.

      5) Review count – grey on white – colour contrast is insufficient.

      6) Review count – need to use screen reader text to give context for the number – eg [screen-reader-text]Review count [/screen-reader-text]348

      7) Media breakpoints – consider setting in ems rather than pixels – helps those who need text to be very big.

      8) Search box – having just a placeholder is not enough, needs to have a explicitly linked label, although that may be rendered as screen reader text.

      9) Search box – Need some kind of button to trigger the search, otherwise triggering search can be tricky with some AT.

      10) Please don’t do infinite scrolling – can cause accessibility and usability headaches: http://www.ssbbartgroup.com/blog/infinite-scrolling-impact-on-assistive-technologies-series-1/

    • mkassowitz 3:07 pm on May 25, 2016 Permalink | Log in to Reply

      I consider the removal of statistical information to be counter productive to how I evaluate plugins. WP version compatibility, timeliness of updates, popularity as shown by the number of installs are actually quite important. I would burn down a lot of additional time by having to dig deeper than the search listing to see these factors. The description of a plugin is validated, or not, by the presence of these other pieces of information.

    • shackep 7:26 pm on May 28, 2016 Permalink | Log in to Reply

      At our local WordPress meetup I run a ‘evaluating plugins’ session about three times a year. We go through how Author, Last Updated,
      Requires WordPress Version,Compatible up to and Active Installs can be key in evaluating w.org plugin options. Being able to see this information makes it easy to ignore plugins that haven’t been updated in 8 years and plugins that have low ratings. Having this information available without needing to click on a plugin makes evaluating plugins harder.

      Having reviews be the primary indicator of quality is also problematic as users can give a single star because a feature they want isn’t in the plugin. Having reviews being so central can lead to more people gaming their reviews by blatant self promotion and requests for friends to review the plugin, even if they have never used it.

      As a local community organizer, my goal is to help casual users to level up and become ‘insiders’. Teaching people how to get the most out of WordPress and make decisions that will save them frustration is a key part of that.

      As NateWr said:

      The question that should be asked isn’t “what does the 80% do” but “what do we want to encourage the 80% to do”.

      Active installs is something that helps users know if others have found the plugin too frustrating to use. If you combine active installs with reviews you get a quick litmus test to see if people’s expectations are being bet.

  • Jennifer M. Dodd 3:24 pm on May 19, 2016 Permalink |
    Tags: ,   

    WordPress.org Forums Upgrade 

    The WordPress.org support forums are currently powered by a very outdated version of bbPress 1.x. Per the 2015 WordPress Community Summit, the forums need to be upgraded to bbPress 2.x so that they can easily be maintained by the community. Part of the delay has been that the forums rely on many custom plugins to make them manageable; some of these plugins have already been ported to bbPress 2.x; the rest will be ported as part of Milestone 2 during the testing period on volunteer upgraded forums.

    Scope

    • Upgrade the support forums and international forums from bbPress 1.x to bbPress 2.x.
    • Port any remaining plugins from bbPress 1.x to bbPress 2.x and release them under the GPL.
    • Integrate the support forums with the theme and plugin directories via custom taxonomies.

    Below is a general overview of the steps necessary to upgrade all of the forums on WordPress.org to bbPress 2.x from bbPress 1.x. Much of the work will be involve exporting and updating large quantities of information in bbPress 1.x tables to the WordPress-compatible bbPress 2.x schema — in one case, more than ten million rows of topics and replies. For these steps, I will look at the existing bbPress upgrade converter available but may fall back to a clone and rewrite via the command-line, since the new forum tables will not be in use and can be locked for writes. The goal is to perform upgrades with a minimum of downtime by backfilling most of the forum data and then performing an incremental import to bring it up to date with the existing forum.

    Proposal

    Milestone 0: Due 2016/05/25

    Create a forum provisioning plugin to allow quick creation of forum sites in the WordPress.org multisite environment.

    Milestone 1: Due 2016/06/03

    Migrate three existing bbPress 1.x forums to bbPress 2.x. The migration process will need to scale to eventually handle the support forum (including plugins and themes). During the migration, verify that user capabilities, moderator capabilities, metadata, and encoding are preserved. Create any user metadata filters necessary to avoid overloading the master usermeta table with default values.

    • I’m looking for volunteer bbPress 1.x forums who would like to upgrade to bbPress 2. Qualifications include moderator consensus and having fewer than 10k combined topics and posts. Extended characters sets welcome (and encouraged) as part of this test group. Forums will be available for testing by moderators prior to being turned live, but this will be definitely be a beta test environment.

    Milestone 2: Due 2016/07/01

    Port remaining plugins to bbPress 2.x while testing performance on upgraded 2.x forums.

    Milestone 3: Due 2016/07/15

    Migrate remaining international forums to bbPress 2.x.

    Milestone 4: Due 2016/07/22

    Create theme/plugin taxonomy handling for the support forum.

    Milestone 5: Due 2016/08/05

    Migrate sample data for support/plugins/themes forum. Test and iterate on plugin and theme integration.

    Milestone 6: Due 2016/08/19

    Migrate support forums.

    Stretch Goal

    There are many open Trac tickets for the forums that have been waiting on the upgrade to bbPress 2.x.

    I’ll be available on Slack in the #meta channel. Progress on each milestone will be documented in Trac and in an accompanying P2 post. If you have any questions or concerns, just reach out here in the comments or in #meta on Slack.

     
    • M Asif Rahman 8:22 pm on May 19, 2016 Permalink | Log in to Reply

      Wow! Huge plan and precise milestone. Thank you a lot.

    • Daedalon 9:29 pm on May 19, 2016 Permalink | Log in to Reply

      Excellent news! The clear timeline is much appreciated.

    • Ryan Cowles 12:11 am on May 20, 2016 Permalink | Log in to Reply

      Exciting news! Looking forward to this 🙂

    • Torsten Landsiedel 1:29 pm on May 20, 2016 Permalink | Log in to Reply

      Whoop!

    • FolioVision 3:42 pm on May 24, 2016 Permalink | Log in to Reply

      Hi Jennifer,

      Great that you have a good solid long term roadmap. The migration will not be an easy process (as you know). We’ve recently migrated about three good sized bbPress v1 forums to bbPress v2 including our own heavily customised support forum (all kinds of moderation and custom URL tools, something similar to what WordPress.org has no doubt coded for internal use.

      We’ve just published a guide to help you specifically (and others generally) with sophisticated bbPress migrations. Our own migration script is also linked in the article. We’ve also made public our working version of FV bbPress Tweaks plugin which helps with moderation and URLs which you may want to improve for WordPress.org’s bbPress v2.

      We’re under heavy load with client projects so it would be difficult for us to take on the enormous migration and intense testing ourselves but we’d be happy to help with any tough questions or to improve FV bbPress Tweaks to suit your use.

    • Torsten Landsiedel 4:32 pm on May 29, 2016 Permalink | Log in to Reply

      The German community has been waiting for the upgrade desperately for a very long time. Moderator concensus is there, but I think we have to much posts to be qualified. Special character set is there too 😉
      (At least a few: “üöäÜÖÄß”). Just ping the German community if you are interested to migrate us.

  • Konstantin Obenland 6:32 pm on May 5, 2016 Permalink |
    Tags:   

    Plugin Directory Chat Summary (5/4) 

    This is a summary of the Plugin Directory chat from May 4. (Slack log)

    Attendees: @dd32, @hardeepasrani, @matheuswd, @smartcat, @samuelsidler@mapk, @pento, @obenland

    Topics:

    • Tagging system
      Te revamp the current system it needs to be replaced with a set list of tags from which plugins can choose, and the various taxonomies that might be needed independently of those tags should be listed.
      One such taxonomy would be for the free/light/pro classification, another one could be along the lines of “Built for: [Plugin name]” which takes into consideration plugins that require or are “built for” other plugins (like WooCommerce). These all would be defined in wp-admin, just like tags. @samuelsidler will work up another post for make/plugins to propose and communicate that.
    • Review M2
      Major efforts on the Reviewer Admin (#1570) have come to a close. Any bugs or missing features should be tackled in new tickets. Work on the Plugins API unit test (#1614) will continue in M3, in parallel with the new Plugins API (#1579) itself.
    • Plan M3
      In addition to the tickets mentioned above, #1686, #1688, #1689, and #1690 were added to the milestone. These are all smaller tickets for issues discovered by @ipstenu during her testing. This will be a short milestone as most folks who work on the project will be doing a support week next week. The plugin review team was invited to test the new directory. Tickets resulting from that might be pulled into the milestone as they are filed, depending on severity and size of the fix.

    The next meeting is on Thursday May 12, 00:00 UTC.

     
  • Konstantin Obenland 8:04 pm on April 29, 2016 Permalink |
    Tags:   

    Plugin Directory v3 Chat Summary 

    This is a summary of the Plugin Directory chat from April 27. (Slack log)

    Attendees: @ipstenu, @matt, @obenland, @clorith, @dd32, @pento, @tellyworth

    Topics:

    • Tagging system
      @matt encouraged the participants to figure out a tagging system that gives people a better understanding what’s behind the installation of a plugin. Something along the lines of a Free/Light/Pro classification, that illustrates the difference between (for example) Vaultpress (have to pay), Akismet (should pay if large), and Jetpack (no pay). This could be separate from the proposed 3-tag-limit and be based on an honor system starting out.
    • Determine what it means if a plugin is truly published
      After a detailed discussion about possible solutions and their repercussions around this topic, participants came to the conclusion that plugins should be approved, which triggers approval email and the creation of the SVN repo, but need an initial commit, to be switched to publish and actually show up in the directory. The goal is to ensure plugin authors are at least familiar enough with SVN to make a commit, to reduce support burden after mass emails to plugin authors that ask them to update in preparation of a major release.
    • Tickets for M2
      After committing the updates to reflect the changes decided on above, #1570 should be ready to go and considered fixed. @dd32 already fixed #1575, and @tellywoth and @pento anticipate #1574 and #1614 respecitvely to be finished by next week. Dion has started thinking about #1579 and has a shortlist of items containing Favorites, Contributors, Zips, Screenshots, and Stats pages. @obenland will look at the remaining ticket #1572. @mapk will be working on design mockups for the new front-end, and @ocean90 offered post-meeting to be available for any translation-related questions @tellyworth might have.

    The next meeting is on Thursday May 5, 00:00 UTC.

     
    • Ionut Neagu 5:18 pm on April 30, 2016 Permalink | Log in to Reply

      A tagging system it would be awesome, however I would find helpful to filter the free plugin where you are the product vs the free plugins which are just, free.

      For example I would prefer a lite/pro plugin over a free plugin which show me lots of ads, ask mandatory for my email, or add promotional stuff in the dashboard. Otherwise we may end up with the same issue that we have now :).

    • dartiss 6:53 am on May 1, 2016 Permalink | Log in to Reply

      I love the tag idea. Could I also suggest maybe having some way of indicating minimum PHP level? Of course, this may be a slippery slope as to what other software levels we should be highlighting but I, at least, think this would be a sensible addition.

  • Konstantin Obenland 8:52 pm on April 27, 2016 Permalink |
    Tags:   

    Weekly Plugin Directory v3 Chat 

    I’ve not been very good in making sure there’s a weekly chat for the work on the new Plugin Directory. No more! With a new and improved meeting time of Thursday, 00:00 UTC I think we should be set for regular updates going forward.

    Today’s agenda:

     
  • Mark Uraine 7:52 pm on April 18, 2016 Permalink |
    Tags: ,   

    Final Mockups for ‘Get WordPress’ 

    Working on this project has been a fun and creative journey and both @hugobaeta and I have made some great breakthroughs on the design direction for WordPress.org. Below are the final round of mockups (text still subject to change).

    (Want background on this post? Check out the IA post, followed by the initial mockups.)

    ‘Get WordPress’ landing page (located at /get/)

    Get WordPress - Mobile View

    Mobile

    Get WordPress - Desktop

    Desktop

    ‘Get WordPress’ subpage
    Mobile - Closed Nav

    Mobile – Closed Nav

    Mobile - Open Nav

    Mobile – Open Nav

    Desktop

    Desktop

     
    • Scott Winterroth 7:58 pm on April 18, 2016 Permalink | Log in to Reply

      These look awesome! Great work! One little thing, most of my students don’t realize at the beginning that WordPress is something that is installed on a web server, not to be installed on a personal computer. I might suggest putting a simple line of text indicating this.

    • Pippin Williamson 7:59 pm on April 18, 2016 Permalink | Log in to Reply

      I love these.

    • Thomas Townsend 8:06 pm on April 18, 2016 Permalink | Log in to Reply

      Wow these look fantastic, sure hope the copy for “WordPress Hosting” is expanded…

    • Aaron Jorbin 9:06 pm on April 18, 2016 Permalink | Log in to Reply

      Love the direction this going. A couple of things I initially notice:

      On mobile, Downloading seems like an odd Call To Action along with the decision to eliminate the requirements. My assumption is people looking at that page are in an explanatory phase. Maybe a CTA of “Remind yourself” with the ability to email themselves information?

      We should likely scrub all references to SVN as WordPress as core has been version control agnostic for the vast majority of people for a while now.

      I absolutely ❤️ that the mobile apps are at the top on the mobile view.

      For the requirements, do you think it might make sense to make it clear that these are things for a server and not for installing WordPress on your local computer?

      I’m not sure I love the idea of highlighting specific hosts on the download page rather than leading them to a dedicated hosting page.

      • Caspar Hübinger 9:35 am on May 3, 2016 Permalink | Log in to Reply

        [on mobile] Maybe a CTA of “Remind yourself” with the ability to email themselves information?

        +💯

        For the requirements, do you think it might make sense to make it clear that these are things for a server and not for installing WordPress on your local computer?

        From a support point of view: absolutely!

    • Rene Hermenau 9:06 am on April 19, 2016 Permalink | Log in to Reply

      Beautiful, clean and modern – Love it!

      I suggest a slightly changed text for RECOMMENDED SECURITY: http://take.ms/tO18x
      The average user has no clue what that means and has no permission to do it.

      (The pro user who is installing php and server applications on his own is likely already aware of this and acts on his own responsibility)

      When we assume that most hacked sites are the ones running on cheap and less secure webspace we have to use our 25% market position to make sure that providers take more care about security standards.

      The easiest way to “force” hosting agencies for better security implementations is to make user more aware of choosing a hosting service of better quality.

      1. Remove “NOT REQUIRED”. That makes the statement less powerful.
      If we emphasize that security tasks are not required, people will less care about it.
      RECOMMEND already includes that it is not required.

      I suggest something like:

      RECOMMENDED FOR BETTER SECURITY

      or

      HIGHLY RECOMMENDED

      Use only reliable and well rated hosting providers
      who are promising to take care about your site’s security.

      We have summarized a collection of higly recommended security standards:
      https://codex.wordpress.org/Hardening_WordPress

      Ask your potential host if they ensure the security of your account
      following these standards or check out our recommended hosts.

      Btw. (Dont want to be a smart ass but that typo catched my eyes: http://take.ms/x5Ws7)

    • Julien 9:18 am on April 19, 2016 Permalink | Log in to Reply

      These looks really nice but I find that add some pictures of the software will tease it more. For me, there is too much text and for new comers, they can’t see how the software looks like and what it does exactly. Meaning they have to go through a full installation to see what WordPress is and do.
      Also I find the word “software” too large and perhaps not appropriate. Like Scott Winterroth mentioned above, it’s not clear it is a web “software”, and not “native” OS software.
      Finally I found the content to be mostly oriented to people who generally already know WordPress and that this page will not convince newcomers to start working and develop with WordPress. Perhaps add some features normally only showed in the wordpress.com website.

    • chrishoward 12:26 pm on April 19, 2016 Permalink | Log in to Reply

      Look great!

      As noted by Aaron, download link on mobile is pointless. However, you could have an “Email download link”.

      Also, I think the app store buttons should be in a row, not a column. Reduces a smidge of unnecessary scrolling.

      And, on mobile and desktop, I feel like the hosting should have centred headings and links, and justify the body. It just looks a little out of whack because of the centering of the elements above and below.

    • Gary Jones 11:25 am on May 4, 2016 Permalink | Log in to Reply

      The top text makes reference to WP powering over 25% of the internet. It doesn’t. It powers over 25% of the *web*.

      • Kimb Jones 11:13 pm on May 4, 2016 Permalink | Log in to Reply

        Came here to say this. Also once ‘web’ has replaced ‘Internet’ I’d love to see that portion of the strapline as a subtle underlined link off to a stats page showing the evidence for this.

        So:

        ..software that [url]powers 25% of the web[/url]

        Brilliant work overall BTW 🙂

    • webdevmattcrom 9:40 pm on May 9, 2016 Permalink | Log in to Reply

      Very excited about the overall direction this is going. Well done!

      I’m just curious about the App Store/Google Play placement. I assume those would direct here eventually: https://apps.wordpress.com/

      Is it really the place of .org to provide marketing for .com? Maybe that’s too big of a question for this issue, but it seems pertinent.

  • Mark Uraine 12:24 am on April 2, 2016 Permalink |
    Tags: , ,   

    Plugin Directory Design Direction 

    Earlier this week, a few of us met to discuss the design direction of the Plugin Directory. Myself, @michael-arestad, @hugobaeta, @melchoyce, @helen, and @samuelsidler looked at the current directory and challenged ourselves to look at it from a fresh perspective, exploring flows, UI, and content. The overall goal was to set a direction for the design.

    After a couple days of whiteboard drawings, we’re a lot closer and I wanted to share some explorations with you.

    Please note that the below explorations are wireframes and heavily subject to change. They’re only meant to give you an idea of the direction we’re looking at.

    We discussed three views:

    1. The landing page (wordpress.org/plugins/)
    2. The Search results view
    3. The Single Plugin View
    Plugin Landingpage

    Plugins Landing page

    Plugins Search Results

    Plugins Search Results

    Plugins Single View

    Plugins Single View

    Some pictures of our whiteboards

    On each view, here are some thoughts on the direction.

    Plugins Landing page (/plugins/)

    • The title block is much longer, with a more prominent search field at the top. Search is the primary action in the directory and we’re working to improve it.
    • The addition of a slider for featured plugins… yes that’s not misspelled, I wrote “slider”. 😉
    • Sectioned plugin blocks around various “filters” of plugins. As a sample, we used popular, trending, and beta, but these could be anything in the future.
    • The “Developer Center” that currently exists becomes a small “Plugin Authors” callout at the bottom of the page since it’s not frequently used. We’d add other blocks (like the ones show) where relevant.

    Plugins Search Results

    • Search results maintain a similar style as the landing page.
    • Search field remains prominent in the title block.
    • In fact, when searching from the landing page, everything under the search box is replaced with results.

    Plugins Single View

    • Maintain a large plugin banner at top of the view.
    • The plugin name will no longer be over the banner.
    • Below the banner, we show the name of the plugin, author, and a Download button.
    • The Translation Information displayed will note if a plugin is available in your language or, if not, allow you to click and see it on your localized site with a callout to begin a translation.
    • Tabs are removed. Instead, content blocks act as accordions on the page, revealing information when a visitor clicks to know more. The main column holds the following information:
      • Description
      • Changelog
      • Screenshots in the form of a gallery/slider (to be explored).
      • FAQs – We debated this section a bit, but FAQs are still quite important, when they exist. Ideally, these could be added in the plugin author dashboard instead of the readme so the format is more consistent. If that happened, we could show a list of questions with accordion-like answers when clicked.
      • Reviews – Becomes a section on this view where you can click to see more reviews.
      • “Contribute” is the new “Developers” section. Here we’d show relevant developer information, contributors, a donate button, and all available translations. As we experiment, this may become another view similar to Reviews where you click to see more detailed information.
    • Meanwhile, the sidebar remains, but becomes more condensed. In it, we show:
      • Ratings – a break down by rating.
      • Support – a “widget” that shows relevant support information and allows the visitor to click to enter the support forum.
      • Active Installs
      • Last Updated
      • Category
      • “Designed to work with” option, if relevant.

    Overall, we worked hard to keep the most relevant information for visitors as information that’s important to plugin authors moves to the plugin admin dashboard.

    Thoughts?

    As a reminder these are wireframes to give you a general idea of the direction we’re heading.

    What do you think about the direction? Are there things you think should be removed? Things that should be added to the main views? Leave your feedback in the comments.

     
    • Konstantin Obenland 3:29 am on April 2, 2016 Permalink | Log in to Reply

      A slider? Gasp!

      I’m not a big fan of the centered title/tagline honestly. I also wonder if the search field will be overshadowed by the visually prominent slider below. For the single view I was hoping you’d been more daring in terms of the information that is shown there. Did you talk about the banner size and how it relates to the content width there?

      Imagine a list of everything else that makes up these wireframes, which I really like! 🙂 Especially the homepage looks neat. Good job everyone!

      • Mark Uraine 5:55 pm on April 4, 2016 Permalink | Log in to Reply

        The centered title/tagline is a design pattern we’re going to be using across the site. We’ll definitely have to make sure the search stands out and isn’t overshadowed by the slider.

        We didn’t talk about banner size. I know there’s probably a concern there b/c it will be displayed probably larger than how it is now.

    • M Asif Rahman 3:57 am on April 2, 2016 Permalink | Log in to Reply

      In Plugin Single View we are going to hide more content from description?
      What if we have video in description? Could we add video in screenshot or somewhere dedicately?

      • Mark Uraine 5:56 pm on April 4, 2016 Permalink | Log in to Reply

        I imagine the video would be included with the screenshots section. We didn’t discuss video much, and I’m not sure about the limitations (if there are any), so I’ll have to look into that.

    • George Florea Banus 6:07 am on April 2, 2016 Permalink | Log in to Reply

      What ever design you go for I want to be able to order plugins by installs, latest, last updated, rating etc.
      Also add a lightbox for the screenshots, many don’t even open in the browser but are downloaded.

    • Ulrich 9:07 am on April 2, 2016 Permalink | Log in to Reply

      This sounds good. I wonder if the order of the information on a single plugin is correct. I feel changelogs are not so important to people searching a new plugin to use. Screenshots and reviews would be more useful.

      It may be good to have some links link the content sections as landing on the page the user may not realize that there is more content lower down. It is a bit early but the section titles should be linkable so that it easier to point users to the correct section.

      The available translations would be more useful in the sidebar as I can check is the plugin supports my language in one glance.

      Have you thought about what happens when a plugin does not have a banner or icon? Some plugins have randomly generated icons which do not look that pretty and do not provide any use. Normally the banner does not contain useful information but gives a bit of colour to the page and helps with brand recognition. What if we made the banner to full width taking away a bit of the focus? Here is an example. https://wpzoo.ch/en/2016/02/hello-world/

      I am not sure if this is in the scope of the project. “Featured” plugins have not been updated in quite some time. For me featured plugins are only worthwhile when it is a curated list that is updated regularly with new plugins. The featured themes are random themes that have been updated in the last two year. If we do something like that for the plugins then we may just rename the section to random plugins.

      • Mark Uraine 6:02 pm on April 4, 2016 Permalink | Log in to Reply

        Good point about the Changelogs – prolly not that beneficial to new users searching for plugins.
        Links to specific sections is do-able.
        The translations bar at the top is a design pattern we’re exploring with some new site designs.
        We spent some time talking about banners/icons and the absence of them. Still working through ideas.
        Featured plugins would be good to curate, I agree.

    • Marius (Clorith) 11:22 am on April 2, 2016 Permalink | Log in to Reply

      If we’re moving featured ones into a slider, we may as well do away with the featured ones altogether or just show “feature of the day” and a single plugin. Most people won’t stick around to watch it slide through options, and it hides anything not in the first slide more than shows them off.

      @grapplerulrich makes a very valid point about the list having been stagnant for a (to me) unknown period of time, but I don’t remember the last time it didn’t look like it does now, which plays well into my comment about “maybe just remove it” 🙂

      Little bit worried that the single view is information overload, sure you hide a lot of content behind read more expanders, but it’s still a lot of different contents in a single view for many users and may be information overload all at once.

      Other than that I do like the direction this is going!

    • Anton Timmermans 12:53 pm on April 2, 2016 Permalink | Log in to Reply

      I think this is a great way to go, not a big fan of the slider.

    • J.D. Grimes 1:06 pm on April 2, 2016 Permalink | Log in to Reply

      In regard to the single plugin view:

      I don’t think displaying the changelog prominently has any real benefit for most users. I would either move it lower in the page, or else maybe better to leave it where it is but hide the content entirely so the user has to click the “read more” (or maybe “show”, in that case) link to see it.

      I’m also not sure about displaying the plugin icon in addition to the banner, it will probably be redundant, or as @grapplerulrich says, will just be auto-generated.

      I also think that jump-links to each of the sections as @grapplerulrich suggested might be a good idea.

      And one more note, though you are likely aware of this, plugins can add their own custom sections to the readme, and these are currently displayed as custom tabs. I don’t think you’ve addressed what will happen to them?

      All in all I like the direction you are taking this.

      • Mark Uraine 6:05 pm on April 4, 2016 Permalink | Log in to Reply

        In regards to the custom sections on the README, I’m not sure this is completely resolved. They most likely will either become their own section on the page toward the bottom, or be eliminated altogether. Do you have some thoughts?

    • Samuel Wood (Otto) 2:44 pm on April 2, 2016 Permalink | Log in to Reply

      “The plugin name will no longer be over the banner.”

      People have designed their banners around the plugin name being positioned over it like that. If we change this, then those banners will need to be altered as well, and people will start doing dumb things like including the plugin name in the image themselves. This is thus a bad choice for internationalization and non-English languages.

      • Mark Uraine 6:08 pm on April 4, 2016 Permalink | Log in to Reply

        By removing the name from overlapping the image, it will require people to edit their witty designs, but I’m not so sure it will encourage them to add the name themselves. I believe we’ll have a design guide for banners and icons where we’ll be explicit about best practices.

    • Achin 3:39 pm on April 2, 2016 Permalink | Log in to Reply

      A quick thought. How about having Accordions for the sections “Popular” , “Trending” etc? This would help save time scrolling through these categories.

    • David Gewirtz 4:39 pm on April 2, 2016 Permalink | Log in to Reply

      I would strongly recommend moving away from screenshots and, instead, highlighting videos. The screenshots are often difficult to see on long dashboard pages, but video tutorials are active and engaging. Also, support is probably considerably more important than translations and should be very visible and very easy to get to.

      I use the w.org support forums as my primary mechanism of support and they are VERY active. But I’d love a way to have more control of posts (like when someone posts in a thread that’s unconnected to its purpose) and a way of reaching out to my users to warn them when something big is about to happen (like PayPal’s change to a new format coming in September).

      It would also be great if there were a way to externally access and aggregate the forums in a support tool, or see all my new support requests across all my plugins at one place.

      Basically, please think about this not only from the plugin consumer’s point of view in choosing new plugins, but also from the plugin user’s and developer’s for ongoing use and flow. I’ve found that the w.org support section for my plugins becomes the community hub for my users, and I’d like to be able to optimize it more to involve and support that community. Otherwise, I’ve been thinking strongly of redirecting all support questions to a forum on my site, but that kind of defeats the purpose of keeping everyone involved on w.org.

      In any case, thanks for your great work.
      –David

    • Mark Howells-Mead 9:16 pm on April 2, 2016 Permalink | Log in to Reply

      This does sound good! I would query what role the re-design and improved UX will bring to those browsing the plugin directory via the backend, as this is probably the point from which a lot of people will access it.

      I agree with other comments, that consideration should be made for plugins without icons and without banner images. Many plugins don’t provide functionality which can be shown visually and a large area dedicated to visual decoration for every plugin is superfluous in many instances.

      As to a slider, I also agree with other comments: it’s a well-known but outdated means of showing information in a clear and simple overview. A small cascade of teasers in three rows with 1, then 2, then 3 plugins would be more quickly scanned; also proving immediate visibility to plugins in latter positions and making the view much more easily digestible.

      And for the individual sections on the single view: I agree that an accordion would be useful. A view showing the summary information, with the option for the additional sections to be expanded. (Remembering the open/closed state of each section between page requests, so that people comparing functionality or change history between various plugins don’t have to keep opening each section anew on every page request.)

    • Mark Howells-Mead 9:19 pm on April 2, 2016 Permalink | Log in to Reply

      An additional note from a usability point of view: an improved filter and the ability to sort search results would be a long-overdue improvement. For example, to run a search like https://wordpress.org/plugins/search.php?q=honeypot and then sort the results to show the most recently updated plugins first.

      • Mark Uraine 6:14 pm on April 4, 2016 Permalink | Log in to Reply

        Yes, yes and yes. I’m definitely pushing for a more filter-able search ability. We will be updating the search field for sure.

    • Ahmad Awais 12:49 pm on April 4, 2016 Permalink | Log in to Reply

      While I like the wireframes there are certain concerns.

      Sliders? Ehm… ermm…

      Reviews on plugin landing page? Means if someone writes a wrong bad review (E.g. Last time someone gave my plugin 1 star and a very bad review just coz my plugin ain’t compatible with VisualComposer, turns out it was the issue with VisualComposer as its code is a big mess with no standard whatsoever, and I never claimed my plugin to be compatible with that plugin) that would drive plugin downloads and SEO down.

    • Brad Touesnard 5:44 pm on April 9, 2016 Permalink | Log in to Reply

      Would getting rid of the tabs also mean losing the individual pages for each tab? If so, that could have a serious impact on each plugin’s footprint in Google search results.

    • Mickey Kay 5:12 pm on April 12, 2016 Permalink | Log in to Reply

      First of all, fantastic work. Not only are y’all taking on a large task that’s going to make things better for many people, you’re making it look good! Woot!

      Secondly, a few thoughts/suggestions. . .

      1. Support search
      If at all possible, I would love to see the new individual plugin screen include the ability to search support threads. This will make it easier for authors to parse their tickets, but more importantly, it will make it easier for end-users to check to see if their question/issue has already been addressed before filing a new ticket.

      2. Use of space
      Right now, there’s a ton of content in the single plugin view’s main content area, and almost nothing in the sidebar. This means that 1/5 of our precious horizontal space isn’t used at all for the vast majority of page, once users have scrolled down a couple hundred pixels. Consider this alongside the fact that you’re already looking at consolidating what used to be tabbed content into one long single content area, and I think we should do everything we can to use space/scroll as economically as possible. My suggestion would be to either a) move some content into the sidebar, or b) (oh boy. . .) ditch the sidebar entirely. Other related ideas in #3 below.

      3. Read more links
      I’m not fundamentally opposed to this user experience choice, however it’s definitely not my favorite. For one, it causes a somewhat jarring experience. These accordion style links cause what feels to me like a pretty jarring scroll, making it pretty easy to lose track of where one was originally reading (especially so when collapsing the accordions). In my mind, if you’re choosing between tabs and read more accordion expanders to consolidate text, tabs would always be my top choice – perhaps just switching from a full page reload when a new tab is clicked to a simple jQuery tab toggle instead.

      4. Order priority
      Folks have spoken as to what is top priority for them, and I would really like to see the ordering of content match this feedback. As mentioned, change logs are pretty irrelevant to most end users, and as such I would relegate them as lower priority. Another thought is to try to group content into end-user vs developer groups as much as possible. Change logs, svn links, etc all matter to developers, but probably not at all to end users. Additionally, I would love to see us use our sidebar (aka secondary) area for content that is indeed “secondary”. Translation info, contributors, etc all belong here in my mind.

      Keep up the great work! Thanks y’all!!!

  • Hugo Baeta 6:58 pm on March 30, 2016 Permalink |
    Tags: , research, UX   

    WordPress.org UX Research 

    Over the years, with a lot of resources being put into core, the WordPress.org network of sites has been interated upon without much structural or art direction. As we take on efforts of documenting and creating more polished and art directed design foundations for the WordPress project as a whole, the .org sites need to get some love as well.

    The first step is understanding what can be improved, what the real pain points are. So I conducted a survey a few months ago to better understand how contributors and other community members interact with WordPress.org sites. The survey was sent to a select group of people – project leads, team reps, highly active community members, etc. The sampling was small (32 participants) and so the survey had a lot of open-ended questions, allowing the participants to write their thoughts freely, revealing the biggest pain-points. The survey was divided into sections for better understanding of the usage of the several parts of the website.

    This survey will help us get a better idea of the direction we need to go on a long-term plan to make improvements to WordPress.org, building a more solid and thought-out foundation so the community can grow and thrive for years to come.

    The survey was anonymous (which I personally found important in order to encourage more honest feedback), so I’m including here some of the most constructive feedback provided.

    This is quite a large post, with the survey results and relevant comments – 15 sections with a total of 55 questions. So brace yourself and continue at your own risk 😛

    (More …)

     
    • Mark Uraine 7:16 pm on March 30, 2016 Permalink | Log in to Reply

      This is my new favorite post! Excellent work and very telling. Thanks @hugobaeta.

    • Ulrich 7:43 pm on March 30, 2016 Permalink | Log in to Reply

      It is nice to see steps being taken to improve 🙂

    • KirsiD 9:33 pm on March 30, 2016 Permalink | Log in to Reply

      Thank you for sharing this! As a UXD wanting to get more into front end dev, I’d love to contribute. I put it off recently because my experiences mirror this research, I just don’t know where to start. I’ve gotten lost in the whirlwind of information. Great research!

    • Eusebiu Oprinoiu 11:16 pm on March 31, 2016 Permalink | Log in to Reply

      I am so glad to see a redesign is coming and that the UX is given the priority it deserves.
      As I read the answers I felt the struggles of each respondent and I really hope at least some of the highlighted issues will be solved in the near future.

c
compose new post
j
next post/next comment
k
previous post/previous comment
r
reply
e
edit
o
show/hide comments
t
go to top
l
go to login
h
show/hide help
shift + esc
cancel
Skip to toolbar