I'm sure this has been discussed a lot already, certainly over here: #1868444: Introduce tags[] in module.info.yml file to categorize modules by provided functionality. and here: #2042443: Move modules related to web services to a separate package on the module listing page
On a default install of drupal 8 you get 2 packages, Core and Multilingual.
When you install Foo module the configuration is not config/core/foo, it's in some sub category like admin/config/development/foo, or admin/structure/foo or whatever.
I would suggest that we separate out the Core packages into similar subcategories on the modules page: (example package taken mostly from the configuration sub menu)
I'm not suggesting that we use those exact names, but something similar to the url subgroup they belong to for continuity.
I am suggesting that they all start with 'Core' so that they are easily differentiated from contrib modules, and they all naturally group together.
I think this would be a big usability improvement, and a quick win.
Comments
Comment #1
sphism commentedThinking about it, you could tag modules as being Core, and then display them slightly differently to contrib modules, rather than having all the package names start with 'Core ...'
Comment #2
sphism commentedI don't really see any reason for contrib modules to list a different package to core modules, if a user wants to see all the Web Services functionality then they should really just look in the Web Services section... which leads me to think that a good solution might be to flag core and contrib within a package, and allow contrib modules to use the same packages as core eg:
....
Web Services:
- Core Web Services
- Core Something Else
- Core blah
--------------------
- Plugin A
- Module B
- Whatever C
....
i imagine those different core / contrib sections to be themed a little differently
I like this because I think it allows for other groups of modules within a package, say if a big distro like atrium makes a ton of modules then you might have
Package
- Core module 1
- Core module 2
----------------
- Atrium module A
- Atrium module B
- Atrium module C
----------------
- Contrib module i
- Contrib module ii
I'm just thinking out loud really.
Comment #3
Crell commentedFTR, this is the sort of bikeshed bait where I believe the correct answer is "Yoroy, Bojhan, tell us what to do and we'll code it." Because it's a 98% personal opinion question, so defer to the UX leads on their expert opinion rather than a dozen amateur and variably-informed opinions.
Let's just cut to the chase.
Comment #4
sphism commented@Crell: sounds like a plan :)
Comment #5
Bojhan commentedI think with the introduction of the Multilingual categorisation we already advised to split up the core package. The original idea of the core category, is that one can easily distinguish that which is installed and that what is part of Drupal Core. However given that the list has gotten incredibly large, this distinction makes it harder and harder to logically group items. We should favor useable organisation over this original idea.
However the key is making logical groups, that might not map 1:1 on the current navigation. I think this is something we really need to spend some time thinking about. I will take it up with the UX meeting of next monday.
Comment #6
johnvSee
#1355292: Come up with better alternatives for groupings on the modules page
#1868444: Introduce tags[] in module.info.yml file to categorize modules by provided functionality.
#1323826: Make it easier to identify and discover ecosystem modules
Comment #7
klonosI agree with @sphism in #1 and #2 that having the addition of "Core " in front of core modules so they can be their own categories would complicate UX. The most prominent example to support my claim is when equivalent categories of contrib modules will be added to that page. Then we'd have duplicate categories of the same "genre" of modules. So "Core Appearance", "Core Development", "Core Content" ...so on + "Appearance", "Development", "Content" ...so on - you get the picture there?
Besides, I don't think that we should expose the terms "core" and "contrib" in the UI at all (mostly for the same reasons we won't expose "bundle" for example).
What would be ideal IMO is a combination of tagging core modules with a "core" tag in their .info/.yml files (contrib modules would not need to add any "contrib" tag - simply omit adding "core") and keeping the current implementation of packages. Adding an instant toggle (drop-down?) at the top of the page for "core modules", "contributed modules" and "both" would suffice to offer filtering between core and contrib. If we can come up with a subtle way to signify the difference between the two categories visually, that would be great too.
Another use case is distros where contributed modules packaged along with core might still be considered "core" internally for a distro.
Bottom line is we shouldn't group core separate from contrib. That wouldn't improve UX (at least end users' UX) IMHO. What would improve it would be consistent grouping of modules depending on functionality. We should have
- a
package: coreorpackage: distro_name(contrib would omit this - used for filtering)- a
category: category_nameorgenre: genre_name(ortags: ...if we go with #1868444: Introduce tags[] in module.info.yml file to categorize modules by provided functionality.) (both core and contrib should use this for grouping)Thoughts?
Comment #8
johnvI agree with Klonos #7. See my post on #1255696-61: Needs docs update: Move field type modules into separate "Field type" package
Comment #9
Crell commentedBojhan, any word from the UX meeting?
Comment #9.0
Crell commented...minor typo ;)
Comment #10
yoroy commentedComment #25
mstrelan commentedAs far as I can see this should have been closed as a duplicate in August 2013 as per #6
#1355292: Come up with better alternatives for groupings on the modules page
#1868444: Introduce tags[] in module.info.yml file to categorize modules by provided functionality.