- Core contains too much different functionality that is lumped into a single "Core" "category".
- Users are not able to discover field type modules.
- Users are not able to discover multilingual/language-related modules.
- Contributed modules are not discoverable in the "Other" category, so started to introduce custom categories, which ultimately makes modules not discoverable at all anymore.
Note: The page didn't even fit on my screen [not even two], so I had to hack the CSS to produce this screenshot.
- Fix the discoverability of core and contrib and custom modules for users that are searching for particular functionality.
- Design for the user's task, not technical aspects.
- Re-invent to scale and solve the problem for the next 10 years, instead of a stop-gap fix that's tacked onto a design of the past 10 years.
- Clean up and simplify the categorization on the Modules page.
- Instead of "package", we introduce tags.
- A module can be classified into multiple tags/keywords/categories, if it provides related functionality.
- Instead of a single package, there will be multiple tags/categories, meaning that modules like Taxonomy can easily appear in both "entity" and "field". — In which of both would you search it? Doesn't matter, it's there!
- At the same time, the total set of all categories makes more sense, because we stop the "packagitis" problem that is being caused by tons of modules creating their own, new package, because they think they are special (they are not).
- Lastly, to avoid tagitis/categoritis, we automatically strip away all tags that only appear once. Thus, if only one module tags itself as "beavis", and only one other module tags itself as "butthead", then neither of both categories will appear. Each of both modules will have tagged itself with some other terms and can be found within those (hopefully more reasonable) categories.
tagsfor module .info files.
Remove the details elements that are based on package.
Add a select dropdown to filter by a tag, so
admin/modules?tag=fooonly shows a filtered list.
Additionally enhance with JS: Expose the tags to the front-end via
data-tags=",foo,bar,"HTML attributes, and dynamically filter in the front-end.
What exactly constitutes "related functionality"? Let's think ahead of time:
A tag "field" could mean a "field storage", "field type", "field widget", "field formatter" providing module. There will be a lot of field related modules. Just Drupal core alone provides 8+ field type modules out of the box. But what if the user was looking for field storage modules? OTOH, what if the user actually did want to find out about all available field-related modules?
What if tags would additionally be able to be namespaced? E.g., just field, or field/storage, field/type, field/widget, field/formatter (and any combination thereof).
Note that tags do not necessarily refer to module functionality. "mail" would be a tag that refers to E-mail related functionality (for which there is no module in core, only a core subsystem/component).
Likewise, issues likeare seeking for a way to classify certain modules as "pure UI" modules (such as Field UI, Views UI, etc) as well as developer modules, which can be safely disabled on production sites. Such modules could potentially be tagged with just "api/ui" and "dev".
Human-readable categories/keywords vs. internal/machine tags/identifiers
History and experience with human-readable package names essentially eliminates that option for tag values:
Also closely related:
Internal tags/identifiers are more robust, because they refer to identifiers that are usually related to code instead of arbitrary strings that might have a particular meaning today, but not necessarily tomorrow.
Human-readable filter option values will likely become an issue though. We should probably consider to introduce an additional tag-to-label mapping, whereas Drupal core would be expected to provide labels for many tags, not only for the tags it uses itself. This mapping would also have to live in .info files, since the information is needed before a module is enabled.
Tags in a multidimensional, modular system.
The usual drama of 2D vs. 3D. Some contributed modules might use a "thing" tag, while some other contributed modules are using a "things" tag. For example:
To some extent, this problem space could be combated by a simple/naive Porter-Stemmer algorithm when tags are collected and processed.
To some further extent, Drupal core can help to combat it by providing a good, consistent, and extensive set of tag names; i.e., if there is an existing tag in core, then contrib will use it, too.