[UX] Project Browser: Merge the pages in the UI where one can **INSTALL** a module, theme or layout into a single primary tab, under a single top-level menu item.

[klonos]

@maxmeno's comment here:

...you pointed to a page that talks about modules - the corresponding page about layouts, https://backdropcms.org/guide/layouts does not mention installation through the UI at all.

...brought this issue here to life. It is also related to #1291 (might make that one moot depending on the decision made here)

So, we currently have:

• Appearance -> Install theme /admin/appearance/install
• Functionality -> Install module /admin/modules/install
• Structure -> Layouts -> Install layout /admin/structure/layouts/install

1. The menu item for installing layouts is 2 levels deep. Might be confusing to users or less discoverable. I still think that organizationally it is in the right place though. Thoughts?
2. The URL for themes is /appearance/install while for modules is /modules/install. Thought that we should perhaps change it to /functionality/install, but then for layouts we have /layouts/install. So, if we were to change something, it would be the theme installation URL to /themes/install. Bothers me and OCD starts kicking in again 😜
3. The Install theme, Install module and Install layout menu items all lead to a page with "Install a project" as title. Do we actually have any check or validation in place that disallows for example installing a theme from the Install module or Install layout page? I think not, but then... should we? IMO it is not a bad thing - just funny UX. Thoughts again?
4. If we implement [UX] Convert the "Install from a URL" text field to a text area to allow installing multiple projects in one go. #1561 and [UX][D8] Allow multiple file/image uploads #1380 and then take advantage of these two features for all project installation pages, we'll allow installing multiple projects from a single page/form and if no check on their type is made, then this will allow installing a mix of modules, themes and layouts. Again not a bad thing, just funny UX having separate pages for the same thing.

So, why not figure a way to consolidate all these in a single "Install projects" page, under a single /admin/projects/install or /admin/install/projects or even plain /admin/extend URL (with redirects in place if we need to)?

...or is this whole thing sort of moot because we're getting Project Browser into core soon(ish)? But then again, once PB is in, why not simply redirect all these pages to it? We could perhaps pass on URL tokens that filter the PB results by project type depending on whether the user clicked Appearance -> Install theme or Functionality -> Install module or Structure -> Layouts - Install layout.

For people that need the old way of installing projects (browsing their local filesystem for custom-coded modules not uploaded on backdrop-contrib or manually entering URLs for use cases where projects are hosted elsewhere), we could have an "Advanced" tab in the PB UI that offers the URL text area and the multi-upload widget (already mentioned in #1288).

Thoughts?

[klonos]

I think that now we have issues filed for all the points above:

• points 1 & 2 can be covered in [UX] Project Browser: Move the pages where one can **MANAGE** installed modules/themes/layouts as separate primary tabs under a single top-level menu item. #1780
• points 3 & 4 can be covered in [UX] Project Browser: Merge the module/theme/layout **UPDATE** pages into a single primary tab of a single top-level menu item. #1781

Also all the other ideas like consolidating the separate installation and "Update" pages for modules, themes and layouts under a single page have been mentioned over in those issues. Sooo... closing this one.

[klonos]

The other two issues are about merging the "manage" pages for each project type (module/them/layout) under the same top-menu level and merging the "update" pages for them under a single tab that also resides under the same top-level menu item. This one is about merging all the installation pages for these content types under a single tab.

Re-opening.

[klonos]

...sorry for the noise.

[Dinornis]

I understand that the term Project has a meaning to developers. Just wondering if Project, Project Browser, Project Installer have any meaning to new Backdrop users and non-developer Backdrop users in general.

Could Layouts, Modules and Themes be described as Extensions?

I think the current top-menu structure is pretty good, not sure what the merge would accomplish. What would it solve?

To new users (especially those familiar with WP) Appearance > Themes and Functionality > Modules is probably intuitive. Not so sure about Structure > Layouts.

What would you do with the Structure menu if you merged the Layouts, Modules and Themes menu items into the a single top-level Projects menu and removed the Appearance and Functionality top-menu items? The Structure menu would sort of loose it's meaning without the Appearance and Functionality menus.

[klonos]

I understand that the term Project has a meaning to developers. Just wondering if Project, Project Browser, Project Installer have any meaning to new Backdrop users and non-developer Backdrop users in general.

Could Layouts, Modules and Themes be described as Extensions?

Oh, this is a pain that we've inherited from Drupal because that's what these things are called: "projects". Here's the history of things...

In D6 "Modules" and "Themes" were under "Administer" (a word that I believe should be banished from our UI) -> "Site building". The same menu was home for the "Menus" and "Blocks" items:

In D7, the two "Modules" and "Themes" menu items were moved to the top level (better discoverability, less clicks 👍 ) with themes under "Appearance", and the "Menus" and "Blocks" items were moved under a new "Structure" top-level menu item:

D8 has kept the "Structure" and "Appearance" top-level items but renamed "Modules" to "Extend":

The reason why we went with "Functionality" in Backdrop was because "Extend" would make it the only top-level item that used a verb instead of a noun. Why not "Extensions" then you ask? ...because people (Drupal people) called these modules if I recall correctly. Anyways, I see you have been commenting in #2118 and I' sure you have read @jenlampton's comments where she states that the D6 menu structure made more sense for a lot of things:

I've been spending a lot of time in Drupal 6 (working on upgrading to Backdrop, of course) and what made that top-level menu more intuitive than Drupal 7's was the mystery menu named "Site building". Yes, that name didn't really mean anything to anyone, but all the important things you needed to build for your site lived in there: Blocks, Menus, Image styles, URL aliases, Panels, Views. ... Why do I find D6 more intuitive than what we have in D7/BD? ... I also really like the idea of grouping modules, themes, and layouts together under some kind of name like "Add-ons" or "Plugins", especially now that we have project browser in core. I'm guessing this is what "Site building" was for initially in D6

I'm with @jenlampton on this one, but unfortunately, this cannot happen in 1.x.