Rename the drupal.org (json:api) source type

@rkoller
+1 for this, for site builders or non-technical users this label is meaning less. Because this source is listing only modules it is better to rename it to "Modules".

From the usability point of view in the source tabs, I observed a few more things that consider to be improved:

1. Currently the label for source and total results are displayed all together which giving impression that it is a single label. We can consider having the label and results count separated with parenthesis something like Modules(5630 results) or Modules(5630), Recipes(85 results), or Recipes(85), this would make it more user-friendly. "results" word also seems repetitive.
2. Show a short summary about each source for each source label to make it clear what Modules, Recipes will do.

Thanks!

I agree with this, and "Modules" makes sense for the label.

My only concern is that core modules aren't included, and there is a separate "Drupal core" source for those, so the title doesn't make it clear that browsing "Modules" doesn't include core modules (though, personally I think the solution should be to include core modules, as a non-technical user shouldn't need to know they need to look in a separate source for core modules, or even whether a given module is coming from core or contrib, but that's definitely something to discuss under a separate issue).

@lostcarpark Yes, the "Drupal Core" source also needs discussion because I agree with you for a non-technical user it does matter whether it's core or contributed, for them, it's a Module.

honestly speaking the entire drupal core source type could be questioned , which also leads into a discussion i've tried to suggest and initiate several times on the drupal slack bringing together folks from the usability meeting, the recipes group , and project browser and whoever is interested to join. we've repeatedly touched the extend page in 📌 [PP-3] Figure out what to do with the install/uninstall modules page Postponed in the usability meetings and i guess the entire page has to be tackled and discussed holistically. a few personal thoughts.

at the moment on the extend page you have the local items list (list of modules), browse, update and uninstall (uninstall is referring to the uninstall of modules). all the entries shown on the list and uninstall modules page are modules already contained in the file system added by composer require.

within browse there is currently drupal.org json:api, recipes, and drupal core. none of the modules listed in the drupal.org json:api source type is contained in the file system yet, recipes in contrast currently only contains recipes shipping with drupal core which are already contained in the file system BUT sooner or later it will also list recipes on d.o not contained in the file system yet, while drupal core strictly speaking simply mirrors a subset of the modules on the list page, but all of them already contained in the file system.

personally i would vote for a clear separation of concern. the sources shown under browse should only list extensions (modules, recipes, themes) that are NOT in the file system yet and remote. while all the local items aside browse on the extend page have the entities listed on their tabs be already added and available in the file system, either installed or uninstalled. and i would have one local item for modules, one for recipes and one for themes (and the top level item appearance could be deprecated - something you dont use on a daily basis which would be the sole reason to justify having a top level item - something i've realized in one of the drupalism meetings where @cellear made that valid point). but that way concepts would be structured more clearly with a separation of concern. at the moment everything is overlapping and potentially confusing if you dont know about the underlaying concepts and their constraints. just a rough outline and idea but the longer i think about it the more sold i am on it.

but yeah out of the scope for this issue but i really think it would make sense to bring several groups together and having a discussion. cuz in particular if you test the prototype for starshot the problem is further emphasized and amplified. you have an overwhelming modules list page and no direct touchpoint with the list of available recipes nor any way to directly see which of theses recipes got applied setting up starshot /drupal cms. the user is in complete lack of situation awareness.

regarding #2 📌 Rename the drupal.org (json:api) source type Active .1 i disagree on that one. at the moment with for example the drupal.org json:api tab active you have the results count there as well as a second time underneath the filter field set. any redundancy should be avoided. but the general even bigger problem is the search field is within the filter section so the scope of the search field is the drupal.org json:api source type just based on the hierarchy in the DOM as well as the general proximity. but the search query gets applied to all the other active source types as well, each of them has a result as well. to make sense, the search field would have to be placed above the source type tabs. but what is the purpose of searching across modules, recipes (at the moment locally but sooner or later also on d.o) and drupal core(which is also local). that is simply too much complexity and a potential information overload. a clear separation of concerns is probably preferable. the proposed resolution in 🐛 Filter (categories) selection is leaking over into other sources Active suggested to keep the scope of a search to a single source type with each of the sources having their own filter and dropping the results count form the tabs.

regarding #2 📌 Rename the drupal.org (json:api) source type Active .2 not sure if the ui would be overloaded with another description here or popup button. i think a more elegant solution would be to create a tour for project browser (for the search page and the details page) in https://www.drupal.org/project/issues/tour → . something i've suggested over in the discussions in the #tour chanel on the drupal slack. the development speeded up after it got moved into contrib and it is now considered by two tracks (seo and a11y) to be proposed to being added to starshot/drupalcms.

Wait a sec. Is "Modules" really right here? What about themes? I'd imagine d.o is exposing themes and modules both, since they are all just regular projects.

Should this be "Modules & Themes"?

on d.o there are separate paths for the two:

https://www.drupal.org/project/project_module →
https://www.drupal.org/project/project_theme →

so not sure if the json api endpoint entails modules and themes or just modules. i've assumed the latter. and i thought the introduction of themes is planned at a later point? and i've just checked and simply searched for "adminimal" in the drupal.org json:api source type in project browser and there is no match for https://www.drupal.org/project/adminimal_theme → in the search results.

Should this be "Modules & Themes"?

From the site builder's point of view, if we put "Modules & Themes" under one tab, he/she will have to apply some additional filter to filter out the Modules or Themes only.

But because the tabs are for sources and from D.O. if both are being pulled then it makes sense to display both and further filtering of (modules/themes only) needs to be considered.

I definitely don't think themes should be bundled in with modules or even under the "Extend" menu.

When we add Themes, I feel a version of the project browser should appear under the "Appearance" menu item.

Also, I have no idea how we would do it, but I feel our goal should be to show a preview of the front page of your site in the new theme before you install it.

I’ve been reflecting on the points in #10 📌 Rename the drupal.org (json:api) source type Active and wanted to share a few thoughts.

It might be beneficial to have distinct tabs for "Modules," "Themes," and "Recipes." Additionally, the "Browse" option could be placed in the "Appearance" menu or made accessible globally. I recall seeing an issue related to the placement of the "Browse" menu item, although I can’t seem to locate it at the moment.

If we decide to have a "Browse" option under "Appearance," it would make sense for it to take users to the "Themes" tab on the Browse page, while the existing "Browse" menu under "Extend" should take them to the "Modules" tab.

Lastly, it may be worth considering renaming the current "Drupal.org (JSON
)" tab to "Modules," as it lists and searches for modules only.