Plugin Directory Chat Agenda

Agenda for this week’s meeting on August 18, 2016 at 00:00 UTC:

  • Review Milestone 6.
  • Plan Milestone 7 from existing tickets.
  • Review remaining feedback items from Open BetaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process..
  • Open Floor.

We’ll be meeting in #meta on SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/..

If you have anything to propose to add to the agenda, please leave a comment below.

See you in the chat!

#plugin-directory

#meta

Plugin Directory Meeting Summary (8/11)

This is a summary 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 chat from August 11. (Slack log)

Attendees: @justingreerbbi, @SergeyBiryukov, @mapk, @webdevmattcrom, @kevinwhoffman, @qriouslad, @liljimmi, @dd32, @samuelsidler, @michaelarestad, @afragen, @lunacodes, @gibrown, @clorith, @obenland

Topics:

  • Status of M6
    Five tickets have been closed so far, including one that cropped up this week. Due to a knowledge dependency, #1691 might need to be bumped to M7. Patches in #1579 are commit ready.
  • Review community feedback
    We decided to postpone discussions on the two items with the most feedback, read more links and plugin cards, until @mapk can participate and give his input this week.

    Initially the step back towards everything on one page on single plugin pages was the desire to explore solutions outside of the tabs in general. Designers weren’t sure that tabs were the right solution, especially the way they are currently implemented. Tabs indicate that each section warrants similar importance. In many areas certain sections just aren’t as important as others, so displaying these on a single page helped with creating proper hierarchy. A lot of are used to the tab architecture so they probably expect a central navigation, but if the information is arranged correctly it might not be needed either. Forcing a Read More on every section is not very helpful though, Screenshots and FAQs for example could be handled much differently. There are already two tickets that handle that, #1810 to make FAQs more accordion-like and #1828 to make screenshots a gallery sort of thing. Changelogs could be limited to the last n releases of a plugin to make it more manageable and possibly merged into the Contributors & Developers section. Action items, as a result of the discussion, include completing the aforementioned two tickets and finding a better place for the changelog. With that three out of five read mores would be eliminated and we can take another look and iterate from there.

    Another part of the new directory that received a lot of feedback is the simplified plugin cards on the front-page and search results. @mapk is in favor of including more information, but it needs to be the right information. Ultimately we should be very conscious about why we add more data to a view, to ensure we’re providing the right data for users. Four pieces of data are currently being discussed: Active installs, Last Updated Date, Author, and Compatibility. It’s hard to tell if the data is right because search results aren’t ideal, so we agreed to focus on improving the plugin detail page first, while also improving search, then circle back around to the cards once we have a more accurate search and can run real user tests.

The next meeting is on Thursday August 18, 00:00 UTC.

#plugin-directory

Plugin Directory Chat Agenda

Agenda for this week’s meeting on August 11, 2016 at 00:00 UTC:

  • Status update for Milestone 6, due next week.
  • Review remaining feedback items from Open BetaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process..
  • Open Floor.

We’ll be meeting in #meta on SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/..

If you have anything to propose to add to the agenda, please leave a comment below.

See you in the chat!

#plugin-directory

#meta

Plugin Directory Chat Summary (8/4)

This is a summary 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 chat from August 4. (Slack log)

Attendees: @dd32, @samuelsidler, @Ipstenu, @webdevmattcrom, @obenland

Topics:

  • Plan M6
    Two tickets left over from M5 were moved into M6, #1579 and #1691. To complete the favorite functionality #1811 was added, as well as three bug reports that should be fairly straight forward to fix.
  • Review community feedback
    We decided to postpone discussions on the two items with the most feedback, read more links and plugin cards, until @mapk can participate and give his input next week.
    Search is still in need of iteration. One of the things to do here is to go through the top search terms and compare them to see which results are better and how they can be improved. Another is adjust the algorithm based on user reports, which are being depended on to cover more cases.
    Showing categories on the front page instead of (or in addition to) curated sections was something that was thought about previously and is absolutely something that will happen. There are a lot of possibilities to mix it up, even things like “trending in [categoryCategory The 'category' taxonomy lets you group posts / content together that share a common bond. Categories are pre-defined and broad ranging.]”.
    We didn’t get to discuss “Making plugin author dashboard public and moving it out of `wp-admin`” before the end of the meeting, so that can be picked up in the meeting next week as well.

The next meeting is on Thursday August 11, 00:00 UTC.

#plugin-directory

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

Plugin Directory v3 Open Beta

We’ve been working on the new, WordPress-based version of the Plugin Directory and it’s at a point where 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 would like to open it up to the community to foster participation and receive feedback. You can find the latest iteration of it under the temporary URLURL A specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org:

https://wordpress.org/plugins-wp/

If you have commit access to a 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 in the existing directory and are logged in to your WordPress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/ account, you also have access to the provisional developer interface.

Please keep in mind that it is by far not a finished product. There is still a lot of work to be done, mainly around front-end technology, search, and developer facing interfaces. Every decision that has been made so far is up for discussion, which is the purpose of this post. You can find a history of all previous discussions at #plugin-directory.

We’ve already received a good amount of feedback after my WCEU session on meta trac, the summary post of our last chat, and in blog posts throughout the community.

But we’re looking for more! 🙂 Please feel free to leave general feedback as comments on this post, and specific bug reports as new tickets on meta Trac (but make sure it doesn’t exist yet). The meta team will go through all feedback, derive a prioritized list of suggestions from it, and work it into the iteration schedule.

Thank you for your participation!

Plugin Directory v3 Chat Summary (6/1)

This is a summary 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 chat from June 1. (Slack log)

Attendees: @dd32, @samuelsidler@mapk, @pento, @tellyworth, @obenland

Topics:

  • Review M4
    M4 had eight tickets assigned to it, four were fixed by the time of the meeting. #1575 had a patch for the non-open-sourced part that was committed a day later and fixed the ticket. There was some follow-up work that re-instated using the old directory as the data source but largely satisfied the requirements. #1579 was waiting for a commit. #1722 was moved into M5, waiting for a final commit later that week. #1692 was also moved into M5, waiting for more updates.
  • Plan M5
    After our prioritization pow wow the week before, M5 almost planned itself. #1720, #1573, #1578, and #1691 sat atop of the list and need most attention. #1742 was also added to the milestone, as a left-over task from #1575.

The next meeting is on Thursday June 9, 00:00 UTC.

#plugin-directory

Taxonomies in the Plugin Directory

Since my last post, I’ve been doing some thinking and digging into taxonomies on 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. 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.
  • TagTag Tag is one of the pre-defined taxonomies in WordPress. Users can add tags to their WordPress posts along with categories. However, while a category may cover a broad range of topics, tags are smaller in scope and focused to specific topics. Think of them as keywords used for topics discussed in a particular post. 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 sourceOpen Source Open Source denotes software for which the original source code is made freely available and may be redistributed and modified. Open Source **must be** delivered via a licensing model, see GPL. 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 taxonomyTaxonomy A taxonomy is a way to group things together. In WordPress, some common taxonomies are category, link, tag, or post format. https://codex.wordpress.org/Taxonomies#Default_Taxonomies..

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):

  • AccessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/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, CustomizerCustomizer Tool built into WordPress core that hooks into most modern themes. You can use it to preview and modify many of your site’s appearance settings., 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.
  • MultisiteMultisite Multisite is a WordPress feature which allows users to create a network of sites on a single WordPress installation. Available since WordPress version 3.0, Multisite is a continuation of WPMU or WordPress Multiuser project. WordPress MultiUser project was discontinued and its features were included into WordPress core.https://codex.wordpress.org/Create_A_Network. – Plugins which are built to improve and enhance networks.
  • Performance – Cache, monitoring, maintenance.
  • Ratings & Reviews – Including polls, testimonials, and recommendations.
  • Security & Spam Protection – SSLSSL Secure Socket Layer - Encryption from the server to the browser and back. Prevents prying eyes from seeing what you are sending between your browser and the server., HTTPSHTTPS HTTPS is an acronym for Hyper Text Transfer Protocol Secure. HTTPS is the secure version of HTTP, the protocol over which data is sent between your browser and the website that you are connected to. The 'S' at the end of HTTPS stands for 'Secure'. It means all communications between your browser and the website are encrypted. This is especially helpful for protecting sensitive data like banking information., 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 categoryCategory The 'category' taxonomy lets you group posts / content together that share a common bond. Categories are pre-defined and broad ranging.. 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.

#plugin-directory

Plugin Directory Prototypes (Single View)

Yesterday, you saw the mockups and prototypes 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 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.

#design, #plugin-directory