Problem/Motivation

During the usability sessions, some participants struggled to find the expected link when visiting the "structure" page. They expected structure to present a hierarchy, instead of presenting a list of equal choices.

Larger categories should not be equal to smaller categories."

When using a tool like Drupal, there are certain concepts that are key. But
when looking at links and structure, everything appears equal.

Proposed resolution

Order the structure navigation items by importance, so the most important appear at the top.
Consider removing some not important items from structure
Consider designing a new visual hierarchy for the structure page, potentially using styling from the configuration page.

Remaining tasks

Implement the change recommended changes
Test
Assess whether we need to take further action

User interface changes

A change to the structure page

API changes

None

Data model changes

None

Comments

Bojhan’s picture

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

andypost’s picture

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

Bojhan’s picture

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

LewisNyman’s picture

Issue summary: View changes
FileSize
431.37 KB

@andypost I agree, this should scale with contrib.

I think we already have guidance on which menu item to use for module developers, right? I think the term 'structure' is a guiding factor, it's more about describing the role of the menu item rather than how important it is.

What if we break structure into two sections? I can't think of the correct wording but this is what I mean:

andypost’s picture

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

cilefen’s picture

What about "Essential" and "Advanced"?

cilefen’s picture

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

legolasbo’s picture

+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)

tkoleary’s picture

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’s picture

legolasbo’s picture

@tkoleary,

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

tkoleary’s picture

Site building?

andypost’s picture

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

LewisNyman’s picture

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.

If we can avoid changing the page title here and move it to another issue that would be great.

Considering how this scales with contrib is great. It would be nice to see how it would look with just standard modules installed and with all of core+popular contrib installed.

legolasbo’s picture

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.

tkoleary’s picture

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.

LewisNyman’s picture

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.

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.

tkoleary’s picture

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.

Bojhan’s picture

@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.

LewisNyman’s picture

@Bojhan I was unsure because I think the config page has it's own issues with ordering and heirachy on mobile. The items that are top of the page in the right column on desktop end up halfway down the page on mobile. If we keep everything in one column then we don't add the same heirachy problems here.

On the other hand, it would be really nice if /config wasn't it's own special snowflake. I'll leave the decision to you :P

yoroy’s picture

Issue tags: +Needs design, +styleguide
ifrik’s picture

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.

Gábor Hojtsy’s picture

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

dasjo’s picture

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

Gábor Hojtsy’s picture

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.

catch’s picture

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.

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

tkoleary’s picture

@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.

yoroy’s picture

FileSize
265.01 KB

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…

catch’s picture

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.

Gábor Hojtsy’s picture

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: [policy, then meta] Document @internal APIs both explicitly in phpdoc and implicitly in d.o documentation.

tkoleary’s picture

@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.

tkoleary’s picture

@catch @gaborhojtsy @yoroy

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

screenshot

I think it works.

catch’s picture

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.

Bojhan’s picture

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 :)

tkoleary’s picture

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

It is if you are Jared Spool. :)

Secret lives of links

Bojhan’s picture

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

yoroy’s picture

Issue tags: +ux-hierarchy
jhodgdon’s picture

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?

Bojhan’s picture

@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.

yoroy’s picture

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

#2721727: Move the Display modes link from Structure to inside Field UI

ifrik’s picture

Issue tags: +DevDaysMilan

Can we discuss this at DevDays in Milan?

Gábor Hojtsy’s picture

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.

yoroy’s picture

That is a correct assessment :-)

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

tkoleary’s picture

Priority: Normal » Major
Issue tags: -DevDaysMilan +sprint
Bojhan’s picture

Version: 8.2.x-dev » 8.3.x-dev

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

yoroy’s picture

FileSize
102.21 KB

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.

ifrik’s picture

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.

catch’s picture

For me I think this ought to be postponed on #2755613: Restructure the Admin interface. 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.

Bojhan’s picture

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.