Emphasize the most important items on the 'structure' page

My first thought was to disable contact module, and to place display modes as a tab under content types?

not sure it will help, contrib exposes own menus
also it makes sense to add a help page with suggestions for contrib module developers

We do already have this, frankly if a contrib adds its page here it should fit in the "important" category.

@LewisNyman nice idea! so we could end up with same layout that we have for Configuration menu

What about "Essential" and "Advanced"?

#2516902: Introduce a visual hierarchy to the help page. is a similar issue. Perhaps there could be a combined solution.

+1 for #6 if we go for #4.

However, I think much of the confusion is caused because the structure page actually contains a lot of links to things which aren't really structural.

All items listed as "not important" and even "content types" are actually better categorised as "behaviour" or "configuration". In my opinion a "structure" page should only list items which define a site's content structure (Menu, views, taxonomy and (arguably) block layout)

Lots of good initial thinking here but I'm not sold on any of the suggestions yet, not sure they scale well.

As I see it there are three main issues:

1. Alphabetizing lists is only marginally better than no order at all
2. There is too much text on the page
3. There is no hierarchy
4. The nomenclature does not provide enough "link scent"

I would suggest:

1. Don't alphabetize, use weights
2. Make the default weights follow a sane structure that maps to the 80% use case
3. Create a visual hierarchy with nesting
4. Improve the nomenclature and descriptions to illustrate larger concepts, not just discrete tasks
5. Selectively include descriptions (top level only?)
6. And possibly use a two column layout like /configuration

The hierarchy can actually illuminate the meanings by the way things are grouped. Additionally we should consider the categories not just with their current contents, but as sensible buckets for additional items contrib will add.

The result might look something like this (with page layout, galleries and surveys standing in for future module provided links):

Content model

Build a structured content model using content types, display modes and relationships

• Content types
• Comment types
• Display modes

Layout

Build your page layouts using blocks, page regions and visibility settings

• Block layout
• Page layout

Way-finding

Add and edit menus, rename and reorganize links, tag and categorize content.

• Menus
• Taxonomy

Dynamic content

Manage automatically updated content like custom content lists and galleries.

• Views (lists)
• Galleries

Forms

Create and manage the forms used by site visitors

• Contact forms
• Surveys

@tkoleary,

I like your suggestion, but if we implement it, we would also need to find a new name for the page.

Site building?

"Construct" looks better in that case, overall ++ to the idea to make hierarchical!

Changing the name of the 'structure' page would mean changing a lot of URLs. This would be impossible to do before Drupal 8 release, if I understand webchicks explanation correctly.

Changing the urls should not cause a really big change, because we are using routes in stead of hard coded paths. Also, if a change of the title without changing the paths would improve people's understanding of this page, then we should do it. I would consider changing the paths out of scope for this issue and they should be changed in a follow-up. Unless it adds only minor overhead to this patch.

Since this issue is about the structure of the structure page (sorry), not it's name I think we should offload that to another issue.

Yeah let's move this to a follow up. A core committer already told me we can't do this at this stage of the release cycle.

It's a good issue for 8.1 though.

@Lewis just wondering should we introduce a pattern that is similair to /config? I am not sure if making those pages look more identical is ideal though. The core of the issue is simply too many items that shouldn't be here.

How is anybody deciding what's important and what not?

This will be a subjective way of diving the list into two, so instead of looking through one alphabetic list, site builders will look need to scan through two lists. If these lists are not even alphabetic any more then site builders need to spend even more time looking for the items they are looking. This might not be considered a problem with core only but it will get messy fast when more modules are installed.

Also by any contrib module will probably need to go into the important/essential list because if the module would not be important for a site it would not be installed anyway. And if the items are not sorted alphabetically: What stops module maintainers to give their items the weight to be on top of the list, no matter whether anybody else thinks that the item is important?

A more consistent approach would be to organize the Structure page like the Configuration page and group items topically.

I agree a topical grouping makes sense here. That would also allow to extend this further and not be very hard to implement hopefully.

here's an exemplary hierarchy, i put together based on what drupal core offers + 1 contrib module and my assumptions of how i would categorize them:

Blocks
- Block layout
- Custom block library

Content structure
- Content types
- Taxonomy
- Menus

Listings
- Views

Display modes
- Form modes
- View modes

Other
- Books
- Contact forms
- Comment types
- Paragraph types (contrib)

In the /config space we follow a pattern where every item is also placed in the url folder of its category. So based on the above views would now live under /admin/structure/listings/views

Is that now easier to achieve with routes? Are paths part of our frozen API? https://www.drupal.org/core/d8-allowed-changes#minor does not say that. Neither at https://www.drupal.org/node/2550249 which is linked as further discussion.

Asked at #2550249-83: [meta] Document @internal APIs both explicitly in phpdoc and implicitly in d.o documentation.

I opened #2695771: Re-organise user/account items under admin/ last week without being aware of this issue.

For me when I'm actually site building, I get very confused about what's on admin/structure and what's on admin/config. Part of this is that I still to some extent have 3 versions of IA (plus odd remnants of 5.x and 4.7) in my head and forget which version I'm working on, but also I think where some things are at the moment is arbitrary.

I'd like to consider moving all the 'multiples'/config entities to admin/structure - and possibly renaming it to site building similar to suggestions above.

Multiples means all the config entities so:

blocks/menus/content type all stay.

Image styles, ckeditor profiles, text formats, user fields, contact forms, languages all move.

User account settings (not fields), performance, site configuration, cron all stay on config.

However, that still leaves some grey areas:

- Views UI has its static configuration on a tab, should really be on admin/config, except you might want to get there straight from configuring a view.

- Search combines static configuration and config entities on a single admin page.

- Path aliases don't neatly fit anywhere, although for me they're more site building or even a tab under /content

- Language settings are the only example where everything fits neatly into one place (except for possibly translation settings for individual fields), but this suggestion could end up splitting it between the two pages.

- Users are still split between 2-3 places.

While to actually make the change in core with the current architecture we'll need an upgrade path, none of that matters for new installs - so it ought to be possible to write a prototype patch that's testable locally and on simplytest.me quite easily.

@catch

I think the wholesale IA changes you suggest may be good, but the scope of this issue I am beginning to think should be narrower.

If we make it simply about expressing hierarchy in these admin pages, not about *what* the hierarchy is we can commit a change that enables admin page items to have children, than decide which are the parents and which are the children in further issues.

Yeah, more interesting for now to explore design options for how to create hierarchy on these kinds of pages.

We can vary size, placement, grouping, number of columns…

Hmm I feel like admin/config already has a hierarchy of sorts via the categories. Whereas admin/structure is completely flat with no categorisation. My suggestion was to add the categorisation to admin/structure then move a bunch of items from admin/config over. That would in turn reduce the number of items on admin/config dramatically.

I'm struggling a bit with adding hierarchy to admin/config as to what an actual parent -> child relationship would be between the items on there. For me there are not really many at least with core modules. So examples would help even if this issue is kept entirely about the visual structure and not the IA itself.

So looking at #30, I think admin/config is doing (2) now. That would certainly be the "easiest" to implement, except that paths would need to change for structure pages. That theoretically is not a problem for backwards compatibility as per #2550249-83: [meta] Document @internal APIs both explicitly in phpdoc and implicitly in d.o documentation.

@catch @gaborhojtsy

That's an excellent idea. Especially since "panel__title" is a string so we can use whatever category name we like and are not bound to using an existing link as a category.

Also per roy's sketches, a three, as opposed to two column layout might be better since there's less content and it would shorten line lengths and make them more legible.

@catch @gaborhojtsy @yoroy

Hacked in chrome inspector with no particular order, just to see what the classes produced.

I think it works.

Is that worth opening a side-issue for? In terms of code both getting the page set-up to mimic admin/config and moving things around are both noviceable. Three columns should also be straightforward. That then gives a good basis for trying to actually decide where things might fit (since you're forced to put everything somewhere), while looking at other visual options.

Just wondering, does this solve the issue - or should we really just be removing items from here? Turning everything into a index, is not an IA solution :)

Turning everything into a index, is not an IA solution :)

It is if you are Jared Spool. :)

Secret lives of links

I dont understand, thats not at all what Jared Spool says?

Question: Are users confused about what Structure is vs. Configuration anyway? Maybe we should combine them, and put the items currently into Structure into either existing Configuration categories, or a few new ones?

@jhogdon That's not the scope of this issue. There have been several tests and 350+ comment threads on this. The tests confirmed though there is no confusion over the two - people expect more "site building" like tools layout, content types in structure and this is correct. We have bloated up Structure, in D8. I am still keen on finding a way to remove or relabel some of these - without needing to make an index.

Ok, here's an issue for moving Display modes into Field UI:

#2721727: Allow user to add display modes from respective field UI's.

Can we discuss this at DevDays in Milan?

So we looked at this yesterday with @ifrik and agreed the suggestions are so wildly divergent that this is not anywhere close to doing a proposed implementation or even a prototype :( Would be nice to figure out how to distill and pick where we want to go.

That is a correct assessment :-)

It would indeed be a subjective call to decide what is more important than others, and we should also look at which items should live here in the first place. It would still be helpful if we would have a way to introduce visual hierarchy here.

I'm pretty sure that this will be hijacked by contrib modules in no time at all.
So at least you will need to give some information on how you decided what is important and what isn't.

For me I think this ought to be postponed on #2755613: Restructure the admin interface Information Architecture. The biggest problem we have is that admin items aren't logically grouped at the moment, emphasising within those groupings is going to run into immediate trouble when some items just shouldn't be there or are missing even in core.

Yes, and no. We do need to look carefully at the IA. But we also need a way to distinguish items on a page into groups, no matter what IA we choose. I think as a intermediate solution, yoroy's suggestion here still stands and could be implemented.

Agreed that #50 is the "simplest thing that could possibly work" for a pretty critical UX issue, and would love to see a patch in that direction.

+1 for the simplest-doable-thing approach :) We can always improve with a complete overhaul of the admin interface when concepts are clearer.

First shot of a patch, to spark the discussion about the code.

Here, the idea is to provide a mechanism for modules to define their links as "Promoted". In order to do so, a promoted property can be added to the menu link yaml file. For example:

menu_ui.links.menu.yml:

entity.menu.collection:
  title: Menus
  description: 'Manage menus and menu links.'
  route_name: entity.menu.collection
  parent: system.admin_structure
  promoted: 1

On the UI users can always edit this menu link and override that setting, un-promoting the item, or promoting other items:

With that in place, then the /admin/structure page can use that information to group links together and style the promoted ones differently.

Patch applied to current 8.5.x HEAD:

Next steps:
- Collect feedback if this approach sounds reasonable or if it's a terrible hack
- Review the code
- Decide which items should be "promoted" by default on this first iteration.
- Figure out how to promote the views link (couldn't do it now and ran out time to dig further)
- Write tests

Good idea, btw he can use a kind of approach we have for tables (adaptive columns) to help frontend in BC way

sorting on
1. Tracking of most visits to admin pages.
2. Shortcut created(take it as bookmark).

If it is for long running, another approach is to expose admin links to admins to add tags to each link and build views menu on them and set that views as admin menu source.Taxonomy menu will do that out of the box but with views we can have icons/images too.
I have done that with with taxonomy menu to build and expose menus to sub-admin/editors but by creating links manually.

The Needs Review Queue Bot tested this issue. It either no longer applies to Drupal core, or fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

Apart from a re-roll or rebase, this issue may need more work to address feedback in the issue or MR comments. To progress an issue, incorporate this feedback as part of the process of updating the issue. This helps other contributors to know what is outstanding.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

Not sure if this helps or not, but I thing keeping 2 column(with grouped) is better for smaller screen devices like(14 inch devices).

#75 Also feels more in line with the /admin/config pages