Plugin Directory v3: Next Steps

The Past

The metaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. team kicked off the new version of the pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party directory at the end of February. Some of the initial desired improvements included: moving to WordPress, open-sourcing the codebase, improving search, feature parity, and making the plugin review process more scalable.

One aspect that was looked at were taxonomies. An outline of the challenges was posted on make/plugins and followed up by a proposal on how these can be met. Another aspect was the design itself, with prototypes published (#1, #2) and feedback gathered, before they were converted into a theme.

Finally, I spoke at WordCamp Europe about the work done so far, providing more details about some of the decisions made, and asking the community for feedback on the prototype during an open beta phase.

The Present (and Feedback)

We’ve received a lot of feedback about the plugin details page and some improvements that could be made. A number of people mentioned that too many “read more” links can make it hard for users to find relevant information, blending the sections together, and that content may not be indexed properly by search engines. Others were concerned about the effects of partially hiding the plugin description, the loss google site links for sections, and how the accordion behavior may not be ideal on smaller touch devices.

Another part of the new directory that received a lot of feedback is the simplified plugin cards on the front-page and search results. Many reported that they missed some of the specific data, present in the old directory; namely, active install count, last updated date, and author. Without this information they’d have to view the details of each plugin to get more information and make an informed decision.

In terms of search, there are a number of improvements that still need to be made. Various queries includes subjectively irrelevant results and often do not surface a plugin despite searching an exact match of its name. One suggestion to mitigate that we’ll explore, is to emphasize matches in tags and matches in a plugin’s description.

A future enhancement we’d like to add that has been discussed quite a bit is showing categories on the front page instead of (or in addition to) curated sections to show the breath and depth of the directory. An additional section could also include “trending” plugins, with an algorithm backing it.

Plugin authors really like the dashboard, but there’s no reason that it can’t be entirely public, instead of housed within wp-admin. If a plugin author is logged in, this view would show options for them. For other visitors, an overview of every plugin from a plugin author could be helpful.

One of the decisions we made early on was to switch from freeform tags to categories. However, this switch limits the ability for plugin authors to change tags at-will and doesn’t allow the same flexibility as freeform tags, requiring editorial decisions on categoryCategory The 'category' taxonomy lets you group posts / content together that share a common bond. Categories are pre-defined and broad ranging. names. Conversely, unlimited freeform tags have been abused and are not helpful to users. One idea is to bring back freeform tags, but limit the number show (and indexed) to five.

In bringing parts of the readme.txt file into the UIUI UI is an acronym for User Interface - the layout of the page the user interacts with. Think ‘how are they doing that’ and less about what they are doing., we attempted to make it easier for developers to manage their plugins without making a commit. However, there are other ways we could solve this. For example, compatibility could be crowdsourced automatically from installed versions of plugins and WordPress. The developer-provided value would become less interesting in this case. Knowing if the user thinks it works is more interesting than knowing if the developer thinks it works. In other cases, we could also allow editing of the readme.txt file within a web UI, automatically committing these changes to SVNSVN Apache Subversion (often abbreviated SVN, after its command name svn) is a software versioning and revision control system. Software developers use Subversion to maintain current and historical versions of files such as source code, web pages, and documentation. Its goal is to be a mostly compatible successor to the widely used Concurrent Versions System (CVS). WordPress core and the wordpress.org released code are all centrally managed through SVN. https://subversion.apache.org/. for the plugin author.

The Future

Going forward we’d like to discuss community feedback and review some of the design decisions, as well as plan how the interfaces for plugin reviews and plugin authors should look like and behave. An important first step will be to reinstate weekly meetings, starting next week, and get back into a rhythm of setting milestones, attaching tickets to them, and complete them in due time. The next Plugin Directory meeting will be August 4, 2016 at 00:00 UTC.

#plugin-directory