Come up with better alternatives for groupings on the modules page

Here's a high-level summary of the hour long discussion we just had about this on IRC. :)

I don't actually think we need another means of organizing the modules page. I think we just need to group sub-modules together (so "Page manager" doesn't appear randomly in the list despite you having downloaded "CTools"), and have a search box at the top. #396478: Searchable modules page

Generally speaking, people don't browse things by category when they're not sure where to find it. They will use the search box first and then, failing that, will use Drupal.org's search box. If we do #1355358: Allow searching for modules on Drupal.org from the modules page we can have the best of both worlds. :)

Jen's position is that if we included a tags[] property with multiple keywords, and let the search box search on that as well as title/description, that would help, and not require keyword overloading in a module description which should be kept short. My position is that if I add the keywords to my project page and we can search drupal.org from the modules page, that solves both problems at once without any extra work for me as a module maintainer.

That sounds awesome.
I was never a fan of the current categorization of modules.
Some kind of guidelines for module developers would be necessary, though.
One might see people stuffing their modules with keywords like in ancient SEO times just to be found more often :P

How about allowing not more than 3 or 4 tags?

Yes, please. :D

Also, moving to feature request. This is important, but I'm not sure it's important enough to hold up D8 development, esp. since the parent issue is already a major task.

I *think* it was webchick who suggested something like allowing modules to configure a 'parent' for them. I imagine it like this:
- Commerce Payment has Commerce as its parent
- Commerce Paypal has Commerce as its parent, even though the two are in different projects.
- Commerce is its own parent (whoa, Oedipus complex?)

If we replace packages with this, we can have this (credits to @yoroy in 538904#198):

I had this LONG story written down here and then I accidentally the back button on my mouse.

In short:
**projects (aka downloaded/uploaded together)**
Are useful for downloading stuff and only tell you a certain set of modules was developed together. They imply a relationship between the modules in the project, but modules from project B may belong to those of project A, a use case which sorting by project does not address. This would also require up-to-date project information from drupal.org OR a change to the packaging script.

**tags**
Just like with the current packages, these can make things very unclear for end users. I like @jenlampton's idea of using these for search only. Does not require changes to drupal.org. Can be misused by maintainers adding tons of keywords, but I don't think this is likely.
We probably need to make tags translatable as well, because on a modules page where everything except for those tags is Dutch, no one is going to search using English keywords/tags, unless they only want to filter module names (which are by convention never translated).

**dependencies**
Would add A LOT of clutter, especially for modules that have more than one dependency. Does not require changes to drupal.org.

**predefined categories**
Packages were supposed to be predefined, I think. It speaks for itself this never really worked.

**parent modules**
Would require very little change to info files. Hard to abuse, since it can only have one value which has to match another module's machine name. May not work if parent module is not available (unless this setting uses a module's human-readable name rather than its machine name).

+1 for parent modules & a fallback when parent is not present (dreaded "Other" category - perhaps renamed to "Unsorted" or something).

Well if we use the US English human-readable title to declare a parent module, we wouldn't need a fallback. It's not the best DX, but it would definitely allow us to create a consistent interface with 'parent/child' relationships.

Oh please, no. Please don't make me hand-type the name of the module my sub-module ships with N times in N info files. :( The Update Status report can figure the sub-module concept out from merely looking at the file system without me as a module developer having to do any manual stuff. Less work++

Given the direction we are going (with Git and stuff), we are going to have *more* packages containing a *fewer* number of modules, not the other way around (just an example: the Search API recently split itself into more modules). As a consequence, grouping by packages is soon going to be a synonym for not grouping at all. Do we really want to go there?

Some clarification of the parent project idea:
- Parent modules offer the same flexibility (or lack thereof) as packages do, but offer a lot more valid values.
- In other issues we already decided that dependencies aren't always relevant. The fact that Commerce Payment depends on Commerce is useful, because one can guess it extends Commerce, but it's less relevant that the shopping cart depends on Views, because it only uses it rather than extend/improve it.
- Update status info is not always available, nor does it have information about modules that may not even be available locally. The file system is (unless someone messed up) project based. It's definitely useful, but like I illustrated before, module A from project A may extend module B that comes with project C. You can't see this relationship by looking at update status information or the file system.

I agree with @jenlampton that parents are not as good, as there is the issue of needing more than one of them. @webchick's argument of tediously having to retype the module name for every module in a project is fair too. The above list is not meant to hammer my idea through, just to address some of your concerns.

I just realized that we only have projects on Drupal.org. Custom modules have no project information associated with them.

I can't really tell you why, but I'm more and more thinking we may just want to create a simple long list with modules sorted alphabetically and add kick-ass filtering. @jenlampton's tags would come in handy there.

In terms of reliable relationships, projects is so far the only one that (if we put that information in info files) actually works and may make sense/adds consistency.

Yay! Simple long list with modules sorted alphabetically and add kick-ass filtering++ :D

With the caveat that true sub-modules (meaning /modules/ctools/page_manager.module) should be grouped under the parent project, so that all CTools modules don't get all scattered to the winds when you download it.

I understand that leaving the grouping to be handled by file/folder structure is an easy way, but this provides no way to group a separate project under a certain parent/related one (think entity & entity_translation) ...unless we allow modules to be extracted inside other modules' folders too (instead of only under ../sites/all/ or ../sites/site-name/ that we practice now). If so, how do we do that in a way that is as transparent as possible? Do we package the child project in a .tar that includes its parent project's folder at the top of its structure? What happens with projects that are related to multiple others as Jennifer mentioned back in #10 (think i18nviews for example)?

My experience has been that most related modules in that way are named with similar prefixes. Entity / Entity Translation is a great example. So is Commerce, Commerce Bulk Product Something Something, Commerce PayPal, etc. So this is a non-issue, IMO.. they'll show up next to/near each other in the listing anyway.

And in cases where they're not, I don't think it actually is a usability improvement for something to arbitrarily re-parent itself under "Views" just because it has something to do with Views. The project I downloaded was called "Views Bulk Operations". That's what I'm going to look for in the list, and I'll easily find it between the "Views" and "Wallaby" modules. I don't want to have to guess first whether the module maintainer, in their divine wisdom, decided to locate it under "Views" or "Administration" or "Other".

That's actually a very good point.

Are we still in favor of grouping by project or not?

My thinking has evolved a bit, but much of what I'm about to write I've already posted in #538904: D8UX: Redesign Modules Page. And I posted pictures there. :-)

If a project contains multiple modules, then that project grouping should be provided as one element in the modules list. When I go to enable a module, its typically the project name I'm thinking of...not the sub-module name. This may require an extra click to "open up" the project when I want to enable one of its member modules, but that seems a small price to pay (assuming no page load required).

I suggest requiring that the "base module" in a project have the same machine name as the project itself. All the members of that project would then set a project variable equal to that name. I would then add two new variables to the base modules .info file: project_name and project_description. This allows the project as a whole to have a different human-readable name and description than any of its individual modules. The variables should be optional, however, and should revert to the name and description of the base module if not provided.

To handle the case where one module extends another, I suggest adding an extends[] variable to the .info file. This would be an array of project names, referencing any modules who's functionality the module in question extends, replaces, or somehow augments. When I open up the details of a module package, under the list of member modules, I could then see a list of all the modules that extend this module. This would be in addition to each project being listed on its own, so I wouldn't have to open Views to get find the Views Slideshow module, for instance.

To take one of jenlampton's examples from above, lets consider the Admin VBO Views module. It may be dependent on views and vbo, but it extends user, node and comment. Likewise, the Views default argument from Context module may depend on on context, but it extends views.

This mechanism would handle the grouping of modules into functional sets very well. So if I looked at the details for Views, I would see a list of all the views display modules and such that extend it. If I looked at the details for Fields, I would see a list of all the modules which add new field types. (Note that I am not considering Drupal to be a single package for in this context.)

In addition to functional grouping, I think there is also value to grouping modules into conceptual categories. For this I suggest adding a categories[] variable to the .info files. This array would accept arbitrary strings, much like the package variable does now, but with some differences. First, and most importantly, I propose that we develop a list of generally acceptable categories for developers to use, covering most of the situations one might come across and put this in the documentation. For inspiration I'd look to the menu structure. Something like:

• Administration
• Appearance
• Content authoring
• Core
• Development
• Media
• Other
• People
• Regional and language
• Structure
• System
• Testing and examples
• User interface
• Web services
• Workflow

Another difference from package is that we should never have anything like "Views", since that is a package, not a category. If you want to see a list of projects providing views displays, then you should look at the listing for Views. If you want to see a general list of modules that deal with site structure, you can look at the "Structure" category.

I don't quite follow the rationale for project, project_name, and project_description. If my module is part of a parent module, it'll be found in the parent module's folder. Once again, see Update Status. It knows that CTools is the parent module of Page Manager already, without module developers having to put in any extra stuff in their .info files. I guess though that it would be worth investigating that logic further to find out if it's coming from drupal.org or if it's figuring it out from the file system or how that happens.

In terms of extends[], you might want to have a look at #328932: Modules and partial dependencies - enhances[] and enhancedby[] field in modules' .info.yml files where there's a large discussion about that sort of thing. Pulling it into the modules page as a filter is an interesting idea, as long as it doesn't clutter up the page too much.

If we're going to do categories, let's please re-use the list on Drupal.org. No sense in developing two separate taxonomies for modules. If the Drupal.org one needs adjustment, let's handle it in the webmasters queue.

Yay! Simple long list with modules sorted alphabetically and add kick-ass filtering++ :D

This sounds like a nightmare to me. I mean, I think it's great if the module list and kick-ass filtering are available as one approach to this page, as long as alternate modalities are supported as well. The long list with search is fine when I know exactly which module I'm looking for. However, as I've said before, the majority of the time I spend on this page I am in more of an exploratory mode, without a single defined target. So most of the time I hate, hate, hate that humongous list of modules. It is way too overwhelming and makes it impossible for me to get a good overview of what's happening on the site. I like my modules in smaller groupings. And not a long list of groupings, like we have now, but actual smaller lists, like just the core modules, or just administrative modules. That's the kind of filtering I'm looking for.

I don't quite follow the rationale for project, project_name, and project_description.

The base module of a project may be deserving of its own human-readable name and description. These variables let developers give the overall project a name and description, independent of any member modules. For instance, we might have something like:

; info file for imagecache_actions.module
name = Imagecache Actions API
description = Base for imagecache utilities used by the individual imagecache actions.
project = imagecache_actions
project_name = Imagecache Actions
project_description = A collection of utilities providing additional actions when creating image presets.

If we're going to do categories, let's please re-use the list on Drupal.org. No sense in developing two separate taxonomies for modules. If the Drupal.org one needs adjustment, let's handle it in the webmasters queue.

I think we should discuss this in terms of what works on the module page, irrespective of what D.O does. If in the end what we come up with will work there as well, then that's great. I just don't want to constrain/torpedo this category implementation by restricting the categories at this point. Also, the two are somewhat different. I'm proposing a separation between conceptual categories and functional groupings—categories[] vs. extends[]—but D.O puts both in one list. And even then, on D.O you may not want to list every module that has a module which extends it, but just the big ones with significant ecosystems, like Views.

Moving forward, I would suggest considering two things: What do we need to support the implementation of the module page in Core? But also, what can we do to support Contrib development of features that don't make it into Core? For instance, I'm arguing for some form of category tabs in Core, but not everybody agrees with this. If I loose out and the tabs get cut, most likely someone will create a contrib module that brings those tabs back (module_filter-8.x?). However, they can only do so if the underlying framework is there to support it. Same thing with grouping modules by project. So lets build in that framework, even if Core doesn't make full use of it. The Module filter is using the package variable because that's all it has available. So lets build in something better.

#21: Related feature request: #1357662: Collaborative module categorisation and search relevance improvements

Changing the title. I'm not giving up on this one yet. :-)

#1868444: Introduce tags[] in module.info.yml file to categorize modules by provided functionality.
#1323826: Make it easier to identify and discover ecosystem modules

#2064727: Separate Core modules into separate packages on module page

clean up formatting

+1 for Module categorization AND tags

WIth tags you can also say that for example, File entity module as well belongs with Media, together with the Field category provided by module categorization.

TLDR, with both you can have presets from drupal.org + any custom tags the author wants.

I'd like to add a small fix to the module page.

No matter the choice we make about categorization of module in this list, I (and surely other users) would prefer to have all groups closed by default.

The attached patch close all groups by default.