[regression] Pages Manage Fields, Manage form, Manage display should include name of content type or entity

This is actually a regression from 7.

The same goes for the other "Manage display" tabs.

I am out of time for this but this patch shows where to put the changes. Remember, modifying this class means that it must work for every field type, such as non-node types like users.

Manage fields and Manage display title includes name of the content type

My previous patch had line dpm($defaults); which probably caused patch to fail.

@martins.kajins your patch has some progress, but please look at the following:

1. please remove the whitespace line from the bottom of the patch (git doesn't want it to be there);
2. that patch does not cover the /admin/config/people/accounts/fields case (user menu items)
(the first 2 test failures show this, one for fields edit, and one for fields display)
3. that patch does not produce the required breadcrumbs for the article content type (should have no additional breadcrumb for the field, field display)
(the second 2 test failures show this.)

I will look into the breadcrumb failures, which might be related to switching from a title value, to a title callback value (but I don't think so.)

Trying to fix all once.

@claudiu.cristea If this is a bug, is it a regression ? .... Oh, I see in the issue title. Carry on!

[Regression] Heading on Manage Fields screen should include name of content type or entity

The same can be said for "Manage form display" and the "Manage display" tabs. Should we not fix those in this issue? Or in follow-ups?

@cilefen, In fact the patch from #13 is fixing all: field list, manage form, manage display.

Added the beta evaluation to IS and fixed title.

Patch from #13 works.

"Manage fields for Content: Article" doesn't work for me. "Content" doesn't make sense capitalized in this context.

It would be better to display "Manage fields for content: Article" or "Manage fields for content type Article".

#13
In "Manage form display" tab, there is no different view modes, so I think it is not necessary in title to show mode Default.

@cilefen,

"Manage fields for Content: Article" doesn't work for me.

It works. After applying the patch you'll need to rebuild the cache.

[...] "Content" doesn't make sense capitalized in this context.

It would be better to display "Manage fields for content: Article" or "Manage fields for content type Article".

"Content" is not a static text but is the label of the entity type. In this case is the human readable name of the "node" entity-type, which is "Content". If you'll visit the manage fields for tags vocabulary, you should see here: "Manage fields for Taxonomy term: Tags". We just cannot have a custom text template for each entity type. The string template is: Manage fields for @label, where @label can be:

• {$entity_type->getLabel()}: {$bundle->label()}: For entity types with bundles, where bundle types are config entities.
• {$entity_type->getLabel()}: {$bundle}: For entity types with bundles, where the bundle types are not config entities.
• {$entity_type->getLabel()}: For entity types without bundles (e.g. User).

Tested with #13 path and everything works just fine. I did cache rebuild as claudiu.cristea told.

"Manage fields for Content: Article" doesn't work for me.

By that I meant "I don't like it". I'm sorry that wasn't clear. Let me think about the rest of #20. I didn't realize the bundle constraints. However, I believe this title should ready "content type", not merely "content".

"Content" is not a static text but is the label of the entity type.

Ok, but this issue was created because of a usability study. The users are managing fields for the content type article but the title as of #13 would be "Manage fields for Content: Article". That is confusing.

1. +++ b/core/modules/field_ui/src/Routing/RouteSubscriber.php
   @@ -96,7 +97,9 @@ protected function alterRoutes(RouteCollection $collection) {
   +            '_title_callback' => array(get_class($this), 'getTitle'),
   
   @@ -107,7 +110,9 @@ protected function alterRoutes(RouteCollection $collection) {
   +            '_title_callback' => array(get_class($this), 'getTitle'),
   
   @@ -118,7 +123,9 @@ protected function alterRoutes(RouteCollection $collection) {
   +            '_title_callback' => array(get_class($this), 'getTitle'),
   
   @@ -130,7 +137,9 @@ protected function alterRoutes(RouteCollection $collection) {
   +            '_title_callback' => array(get_class($this), 'getTitle'),
   
   @@ -141,7 +150,9 @@ protected function alterRoutes(RouteCollection $collection) {
   +            '_title_callback' => array(get_class($this), 'getTitle'),
   
   @@ -153,7 +164,9 @@ protected function alterRoutes(RouteCollection $collection) {
   +            '_title_callback' => array(get_class($this), 'getTitle'),
   

   Making this the same title callback for everything is clever but it adds a lot of complexity into the title callback and having to add the route key. Why not just have a callback per route - it'll have way less logic.

2. +++ b/core/modules/field_ui/src/Routing/RouteSubscriber.php
   @@ -172,4 +185,62 @@ public static function getSubscribedEvents() {
   +      $label .= ': ';
   

   The rules for spaces around : are language dependent. This needs to be in a t().

3. Also instead of using t() in a static method you can use TranslationWrapper (which t() will soon return anyway).

Agree with #24 that "type" should be part of the title, so that it becomes:

"Manage fields for content type: Article" (just like the proposed solution shows in the issue summary)

@yoroy, this route subscriber is handling the general case. We cannot implement particular cases unless we implement this at entity type level. And that would add an unnecessary complexity.

re #24 and subsequent comments... we just need to the get the label of the entity type that is the bundle_of... something like...

        if ($bundle_of = $entity_type->getBundleOf()) {
          // Work out if there are entities with this bundle.
          $bundle_of_entity_type = $this->entityManager->getDefinition($bundle_of);

• Using TranslationWrapper.
• Separate methods for each title callback.
• A common protected method for parsing the TranslationWrapper placeholder arguments.

Green light on #31. That includes #27 and #30. Who's gonna review the patch?

I have a meetup tonight - I'll try to look it over then if nobody else does first.

We were just manually testing at a meetup and we think the new labels are a great improvement to Drupal. #31 reads "Manage display RSS for Content type: Article " and "Manage form display Default for Taxonomy vocabulary: Tags", for example.

These are different from the content type edit tab which reads "Edit Basic page content type" (sic) and I feel that the title pattern difference, one with a colon and one with italics, is inconsistent and could be confusing. A colleague who co-reviewed this with me thinks the new versions are the right way to go and in fact the edit tab should have its title changed similarly.

Thus this issue is tagged "Needs usability review". But as it is now, this is an improvement that could go in.

As we stand in terms of the goals of the issue, this is not simply a regression-fix but also an improvement over Drupal 7. Does that mean a backport is in order?

@cilefen changing the edit page could be spun off into it's own issue, as backporting should be done. Should this be considered reviewed?

@jaxxed We need a volunteer to manually test each path to make sure there are no surprises.

Not manually, eventually make the tests cover all cases (if it's not yet in place)

I can try to get to writing the tests tomorrow, but for the record I think that having tests for this issue are unnecessary (superfluous.)

Tested the recent #31 patch 2514218-31.patch.
Test Cases: Before applying patch
Case 1: Tested for existing content types : Article and Basic Page
Actual Result: The heading for this page does not contain the name of the content type for manage fields,manage form display, manage display.
Screenshot: Manage fields article - before patch.png

Case 2: Created a new content type 'Customer' and tested the same functionality
Actual Result: The heading for this page does not contain the name of the content type for manage fields,manage form display, manage display.

Test Cases : After patch applied
Scenario 1: Immediately after applying the patch the name of the content type was not appearing on the heading of the page.
Case 1: Tested for existing content types: Article, Basic Page & Customer
Actual Result: The heading for this page does not contain the name of the content type for manage fields,manage form display, manage display.
Screenshot: Manage fields customer - After patch.png
Screenshot: Manage fields article - After Patch.png

Scenario 2: When created a new content type, the name of the content type started appearing for header page on manage fields, manage display etc.

Case 1: Created a new content type: "Test" and verified the same functionality
Actual Result: "Manage fields for Content type: Test " the heading for this page showing the name of the content type for manage fields, manage form display, manage display.
Screenshot: Manage fields for content type 'Test - after patch.png

Case 2: Tested for existing content types : Article, Basic Page & Customer
Actual Result: "Manage fields for Content type: Article " the heading for this page showing the name of the content type for manage fields, manage form display, manage display.
Screenshot: Manage fields for content type 'Article' - after patch.png

- After applying the patch the name of the content type is not appearing for Article & Basic page for the header.
Once the user will create a new content type its working fine for all the content types.

Expected Result: It should display the name of the content type on header of the page for both existing & newly created content types after the patch applied successfully.

Please let me know if you need any further clarification.

- After applying the patch the name of the content type is not appearing for Article & Basic page for the header.
Once the user will create a new content type its working fine for all the content types.

Expected Result: It should display the name of the content type on header of the page for both existing & newly created content types after the patch applied successfully.

This only occur because, after applying the patch, you need to clear the cache. The old routes (including static titles) are still in place. After you have created a new content type, the cache has been cleared automatically by Drupal, that's why now also the old content types are OK.

I think we still need a functional test only for this patch in \Drupal\field_ui\Tests\FieldUIRouteTest. Who's gonna write that?

@claudiu.cristea : Thanks, you were right checked again the same scenarios after clearing the drupal cache & its working fine.

1. Changed from TranslationWrapper to TranslatableString
2. Added a test for al pages.

Green light. Who's gonna review it? :)

claudiu.cristea, could you please describe what do I need to test your patch? Because now I got this error:

Class 'Drupal\Core\StringTranslation\TranslatableString' not found

Also tests are failing. My current drupal version is 8.0.0-dev.

@martins.kajins, yes, the patch needs rework now because that class was removed from core in a previous commit. I will come in few minutes with a new patch. Thanks.

@martins.kajins, here is the patch. Ready for reviews :)

Do we really need "For content type" we should be able to go just with with Manage fields: [content type]

@Bojhan, that was the requirement. See also comments #18 to #30.

Not exactly. In #18, I didn't like "Manage fields for Content: Article" . "Manage fields: Article" could be good.

"Manage fields: Article" could be good.

In fact that is very bad. The entity name needs to be displayed somehow. It's possible to have "Article" as node-type and also "Article" as taxonomy term. On which page are you, based on the title? Both will display "Manage fields: Article".

I am not convinced the clutter we are adding, is more beneficial than the lack of having this in the title. You cant reflect the full breadcrumb in the title.

Going with other title design needs redefining this issue in IS and make clear the title(s) pattern that we'll use. This issue was about a regression from D7.

I am just trying to summarize the discussion, please correct if I am wrong:

So in D7, on admin/structure/types/manage/article/fields, the page title is "Article". In 8.0.x HEAD, the title on the same path is "Manage fields".

We have some options for improving this:

• #50 would read "Manage fields for content type: Article"
• #51 suggests "Manage fields: Article", but #54 points out that if you had a taxonomy named "Article", it would produce the same title on its field manage page.

This time #50 patch seems to be ok. Everything works just fine, no errors and both tests are passing.

Nope, this is not going into RC unless we get actual resolution to #55. There are just not enough gains to warrant such clutter.

We need either to change the IS, or accept the fix of regression. Because now we lost the D7 UX.

If no one adds a better title design, I propose to fix de regression and add a followup for something better in 8.1.x. But as is now it can't go in RC

Why not just (e.g.) "Manage basic page field display"?

As a UI/string change, this is a minor version target.

Oh, regarding #54 and an "Article" vocabulary versus content type: There is far less title duplication between these two than there is between "Manage fields" for every single fieldable entity bundle. So I think it would be better off implementing one of @Bojhan's suggestions for a short, clear title and accepting that once in awhile there will be a couple pages that have the same title.

Thanks @claudiu.cristea and @Bojhan.

Another question on the patch itself:

+++ b/core/modules/field_ui/src/Tests/FieldUIRouteTest.php
@@ -43,21 +49,21 @@ public function testFieldUIRoutes() {
-    $this->assertResponse(403);
+    $this->assertResponse(200);

This seems to change what the test is asserting; why is it included in the patch?

Closed two issues as duplicates of this one.

#2634492: Add entity label prefix to field ui pages
#2691013: "Manage display", "Manage form display", "Manage field" pages don't indicate bundle name or mode

And another duplicate... it's a popular request!

#2724055: Page titles for Field UI pages (manage display/fields/form display) should include the entity type and bundle

> I am not convinced the clutter we are adding, is more beneficial than the lack of having this in the title. You cant reflect the full breadcrumb in the title.

I am currently working on a site with multiple entity types and multiple bundles, and configuring view modes for all of them. I don't spot the breadcrumb. All I see is browser tabs that all say 'Manage display' over and over again.

I've changed the wrong entity display at least three times this afternoon.

Another way of approaching this issue is to allow the site admin/author to choose the title. Work in progress of this at https://twitter.com/vijaycs85/status/744641424839282688

> I am not convinced the clutter we are adding, is more beneficial than the lack of having this in the title. You cant reflect the full breadcrumb in the title.

@Bojhan: Please could you try the following:

1. Open 4-5 different tabs for Field UI. For example, suppose you need to change the field display settings for a field on all node types. But you're also working with taxonomy at the moment as well. And you were in the middle of adding fields to articles too.

- admin/structure/types/manage/article/fields
- admin/structure/types/manage/article/display
- admin/structure/types/manage/article/display/teaser
- admin/structure/types/manage/page/display
- admin/structure/types/manage/page/display/teaser
- admin/structure/taxonomy/manage/tags/overview/fields

2. Now switch to something else, like another window. Or make a cup of tea.

3. Switch back to your tabs. Do you know which thing you're editing?
4. Try to find the right tab for managing the teaser view mode on pages.

All the tabs look nearly identical, except for the breadcrumb, which is doesn't stand out at all.

It's maybe worth mentioning that Lightning already implemented something like this, based on feedback from Acquia's internal UX team. Our solution was to simply hijack the title callback of the Field UI routes and set it to the name of the bundle being modified (doesn't include the entity type). It's a bit crude and probably not suitable for direct adoption into core, but I mention it here because it'd be a relatively easy technical change once the bikeshedding is complete, and a win for everyone using Drupal (not to mention a win for Lightning, since it would allow us to remove our hack).

I would suggest something simple that uses the human-readable labels from the entity type metadata. How about something very clear, like "Manage fields on Article content items"?:

t('Manage fields on @bundle @entity_type', [
  '@bundle' => NodeType::load('article')->label(),
  '@entity_type' => \Drupal::entityTypeManager()->getDefinition('node')->getPluralLabel(),
])

Just my opinion, but if we need to choose, I think we should value clarity over brevity.

Lightning's implementation, for those who may be curious:

http://cgit.drupalcode.org/lightning/tree/modules/lightning_features/lig...
http://cgit.drupalcode.org/lightning/tree/modules/lightning_features/lig...

> I would suggest something simple that uses the human-readable labels from the entity type metadata. How about something very clear, like "Manage fields on Article content items"?:

+1 from me for that.

Tagging for usability review. I'm uploading some screenshots to help with understanding the problem.

The zipfile contains various 'Manage fields' pages around a typical site. Open them all in one or more browser windows, one image per tab.

As an example scenario: you are in the middle of building fields on contact forms of several types, when you get a request from a colleague or client to quickly change all instances of the foobar field on all node types.
You then get a phone call or a hangout that interrupts you.
When you return to your work, you have all of these 'Manage fields' pages open: how do you quickly find the right one to continue working on?

Thanks Joachim, I agree it would be useful to have the entity label in the page title. Lets find the most succinct possible format for it though. Mentioning the entity *type* as well might be a bit too much. So something like:

"Manage fields: article"
"Article: manage fields" (maybe this one is better because if follows the page hierarchy as it were).

I'm working on this. Slowly (it's taken me about 3 weeks of meaning to start work on it to actually start), but surely :)

Argh, sorry for sitting on this for so long! I did a fair bit of work on this, then got bogged down on the tests, and then it fell of my radar.

I'm posting a patch of how far I got.

I went with a different approach from patch #50 -- that was adding title callbacks to the routes, whereas here I'm adding page titles within the form classes. It seemed to me that it's better to keep the form page title near to the form itself, especially as there we already have the services we need. Adding lots of title callbacks to field_ui/src/Routing/RouteSubscriber seems to me like putting too much into that class.

IIRC the code is all done, it's just the tests need finishing. Setting to NR for the testbot to take a look.

Oh and unassigning myself!

For my taste we could also just replicate the D7 behavior, where you only see the bundle name, and no further text.
The "Manage display" is already visible from the active tab.

Re-rolled patch #80.

Moved the code over to a MR.

For my taste we could also just replicate the D7 behavior, where you only see the bundle name, and no further text.
The "Manage display" is already visible from the active tab.

Btw I think the title should be different in the page title vs the breadcrumb or other places.

With the latest patch I get this breadcrumb:

Home » Administration » Structure » Content types » Blog post » Manage fields: Blog post

So the "Blog post" is repeated in the breadcrumb.

I think the behavior in Drupal 7 is perfect, we should replicate it.

Ah, the problem with the layout builder test is that some of the routes have neither _title nor _title_callback, and path-based breadcrumb needs those.

It's not enough to just define the page title in the form builder.

Will fix. (Probably my doing I think!)

Oops, didn't mean to change the version!

Rebased on 9.3.x.
Fixed tests -- in particular, breadcrumbs keep their short titles.
Fixed the dynamic titles using the bundle entity -- not all bundles are provided by entities. Using entity bundle info service simplifies things too, as it already knows about what the bundle label is when there's only a single bundle.

This issues was discussed at #3246637 - Drupal Usability Meeting 2021-11-05. During the meeting we came up with a few suggestions for the title but we came to no clear consensus as you can see based on the number of votes appended at the end of each line:

1. Article content type: Manage fields (1)
2. Manage fields: Article content type
3. Manage fields: content type Article
4. Manage Article fields (2)
5. Article: Manage fields (1)
6. Manage fields for content type: Article
7. Manage fields for Article (1)

Before I wanted to post the conclusion and summary of the meeting I re-read the issue again and came across #18, #30, and in particular#54 states it is a requirement to use the entity type name in the title. That hard requirement irons out a few of our suggestions:

1. Article content type: Manage fields (1)
2. Manage fields: Article content type
3. Manage fields: content type Article
4. Manage Article fields (2)
5. Article: Manage fields (1)
6. Manage fields for content type: Article
7. Manage fields for Article (1)

We would recommend to update the issue summary to document that requirement. And in regards of the naming of the title we would ask over at the Drupal Slack #accessibility channel for feedback especially in regards of screenreader users and their experience and possible requirements. We wanted to explore the naming of the titles also in combination with the naming of the labels of the tabs. That is something we discussed in a follow-up Slack discussion . The link to the whole thread is this one: https://drupal.slack.com/archives/C1AFW2ZPD/p1636120216079200.

Since the results in the pasted list of ours, the suggestions in this issue as well as the requirements voiced in the linked comments are so heterogeneous with no clear consensus overall we would wait what kind of insights the feedback from the accessibility channel brings and then revisit the issue. Definitely an important but tricky one. Thanks for all the effort that went into it so far and sorry that we are unable to provide a much more actionable feedback at the moment. But we will post an followup as soon as we have news or come to a conclusion.

p.s. a brief disclaimer that this is my first write up of a ux meeting summary. so not sure if i am doing everything correctly nor articulating it in the correct way. feedback welcome. and i set the status to needs work in regards of the update of the issue summary.

At first apologies for the long overdue follow-up comment. We've ping ponged the discussion between the a11y office hours and the usability meetings for a few weeks and months. The discussion about the issue was continued in the Drupal a11y Office Hours on the 2022-01-20(Attendees if i remember correctly: @mikegifford, @mweiler, @rainbreaw, @shaal and me) , in the Drupal Usability Meeting on the next day(2022-01-21) (Attendees: @aaronmchale,@antoniya, @andregp, @benjifisher, @shaal, @worldbemine and me) and in the Drupal a11y Office Hours on the 2022-03-17 (attendees if i remember correctly: @dww, @mikegifford, @rainbreaw, @shaal and me) . I've then struggled to get sample videos created illustrating how the page is announced to screenreader users we've agreed on. Getting screenreader announcements recorded in Quicktime for a screen recording turned out tricky, extremely time consuming, and a gamble on my old computer. And I then slid into having issues with my eyes that flared up that prevented me from reading and writing for a few weeks. When things got more bearable again I had simply forgotten to get back to this issue the last few weeks - too many things to catch up in parallel while new came in. :( Apologies again. Now to the summary and write up about the reasoning and thinking behind.

Basis for discussion in Januarys a11y office hour was the current state of the issue found in the issue summary where the h1 is named: Manage fields for content type: Article. That way you have a repeating pattern for sighted users starting with Manage fields three times, once in the page title, then in the h1, and again in the active tab. From a sighted users perspective, based on the book "Strategic Writing for UX" by Torrej Podmajersky, the following approach would be the more desirable pattern:

h1: [name] [entity type name] (for example: Article content type)
Primary tab: [action name] (for example: Manage fields)

The goal for titles according to Torrey Podmajersky is to provide immediate clarity of context and actions to be taken. In our case here is an ambiguous tasks title, meaning on the screen are multiple potential actions that the persons can take. Therefore it is helpful to use a title that covers the entire set of ambiguous tasks aka a noun phrase that names the persons context. So there is an immediate reassurance the person is in the right place to accomplish their goal; for example that the person is on the Basic page content type. The available sub context aka the desired actions to take could be directly found in the primary tabs.

But from a screen readers perspective that is problematic for several reasons. Many screen reader users prefer to have one first level heading that contains the document title (60% respondents - https://webaim.org/projects/screenreadersurvey7/#heading). The working memory of the screen reader user might have a limited capacity and due to the design that the primary tabs are no real tabs but represent actual pages it is mandatory that the action name of the primary tabs HAS to be included in the page title as well. But from the accessibility maintainers perspective there would be a way to avoid repetition for sighted users and keep screenreader users informed at the same time. They suggested in the end a pattern to simply using a span hiding the action label:

<h1><span class="visually-hidden>[Action Name]: </span><em class="placeholder">[Name]</em>[Entity Type]</h1>

Their recommendation was to focus the issue entirely onto the h1 and create a follow-up issue for tabs. Those entail changes to the micro copy (the corresponding issue could be found here https://www.drupal.org/project/drupal/issues/2521780 and we had also a discussion in a thread in the ux channel: https://drupal.slack.com/archives/C1AFW2ZPD/p1636120216079200 ) but at the same time it might be worth thinking about the technical architecture of those tabs in general.

I've presented the outcomes to the discussion on next days usability meeting. In summary the attendees of the usability meeting were in general agreement with the suggestion and outcome of the a11y office hour. So about the h1 a consensus was reached. It was then suggested to use a "for" instead of a ":" inside the span. It was also recommended and a consensus was reached to change the title in the head from just the action name to the same string a screen reader user gets announced. Meaning instead of:

Manage fields | Drupal 9

the following gets announced

Manage fields for Article Content Type | Drupal 9

I've then brought the results back to the a11y office hours in march. The attendees were in agreement with the suggested change from : to for as well as the changes to the title in head. @dww just wondered why to display different amounts of information to screenreader and sighted users. Therefore the group agreed to present two options and get feedback from users on d.o in general which pattern to go with in the end:

Pattern A:

Page title:
[Action aka Primary Tab Name] for [Name] [Entity Type] | [Site Name]
Manage fields for Article content type | My Drupal 9 site

h1 for sighted users - () means wrapped in a visually-hidden span:
([Action aka Primary Tab Name] for) [Name - wrapped in em tag] [Entity Type]
Article content type

h1 for screenreader users:
[Action aka Primary Tab Name] for [Name - wrapped in em tag] [Entity Type]
Manage fields for Article content type

the video illustrating how a screenreader user is experiencing the page: https://www.drupal.org/files/issues/2022-09-10/shortForm.mp4

Pattern B:

Page title:
[Action aka Primary Tab Name] for [Name] [Entity Type] | [Site Name ]
Manage fields for Article content type | My Drupal 9 site

h1 for sighted and screenreader users:
[Action aka Primary Tab Name] for [Name - wrapped in em tag] [Entity Type]
Manage fields for Article content type

the video illustrating how a screenreader user is experiencing the page: https://www.drupal.org/files/issues/2022-09-10/longForm.mp4

Please leave a comment which of the two patterns you prefer: A or B. Therefore I set the issue status also to Needs review. I'll post my personal opinion and preference in a separate comment as well.

And for reference I had a follow up conversation with @aaronmchale in a thread in the ux channel on the drupal slack covering several potential follow up issues: https://drupal.slack.com/archives/C1AFW2ZPD/p1644603532025369

I heavily vote for Pattern A. Even-though i am a sighted user and I rely on my vision for navigational queues and information retrieval, as mentioned in #101, I have certain limitations and issues with my eyes. Reading or scanning is causing constant visual stress for me. The longer a sentence or paragraph gets the more the stress, distraction, and pressure rises.
In the context of the page title issue here it means with the suggested page title in Pattern B (Manage fields for Article content type) I would have to scan three words past Manage fields for to finally get to the information of interest - the name of the content type aka the overall context. But in contrast to screen reader users i am able to see the primary tabs and also see what is the active tab - i actually don't even have to read the tab. the active tab is visually highlighted and based on the fixed position for the main tabs (edit, manage fields, manage form display, manage display, manage permissions) i not even have to read or even scan them - i know what is the active tab and where to click if i want to go to one of the other.
going with pattern A would ease and minimize the cognitive load grasping the current overall context and the need of focused reading and comprehension would be minimized. It would help me and people with similar conditions but i suspect it would also help sighted persons without these kind of issues as well. the amount of micro copy is minimized the information of interest is front loaded, so less need for scanning. Therefore again a heavy emphasis on Pattern A from my end.

In talking about this in the A11y Office Hours we talked about the need to have more visual cues between content types. Providing other "tells", like colour, or graphics to highlight different content types.

We could have a range of colors that could be modified in a YAML file, also some simple SVG files could be added for images.

I think this is also a WCAG 1.1.1 issue.

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.

@mgifford

> We could have a range of colors that could be modified in a YAML file, also some simple SVG files could be added for images.

Are you saying we need to rescope this issue to consider that at the same time as the text, or can it be a follow-up?

Discussed this issue earlier with @ckrina. The proposed solution makes the page title pretty long and hard to parse. We started thinking that there might be another solution to this; we think that we should try to approach solving this without adding all of the information to the title.

We believe that the root cause to the problem is that the current page hierarchy isn't entirely correct. The primary tasks are listed under the current page title which means that it's not clear what the tabs are related to. The page title in many cases is more related to the secondary tasks. The current "workspace", or "context" is only described by the breadcrumb.

Github has a similar page structure. Their page structure makes it clear where the user is navigating in, and what each of the tabs are related to.

Here's a mock that sets some direction to what we should explore. I don't think we should implement this as such because this isn't entirely right.

Based on this, it would probably make sense to postpone this issue on #3076820: [META] Layout redesign.

Re-tagging this after talking with @rkoller

Experimenting with ML summaries.

Nixing confusing AI summary. Adding back in 1.1.1 SC.

re #115. Apologies for the late and overdue reply. I was more or less out of the loop for the last few weeks, and trying to catch up slowly.

Discussed this issue earlier with @ckrina. The proposed solution makes the page title pretty long and hard to parse. We started thinking that there might be another solution to this; we think that we should try to approach solving this without adding all of the information to the title.

To which of the proposed solutions are you referring to? The one in the issue summary or the one in #101. I agree that the proposed resolution in the issue summary is too long and too hard to scan. That is what we've tried to improve with the proposed changes in #101, in particular with Pattern A, which visually hides the task aka the active tab's label for sighted users.
Both suggested patterns are meeting the WCAG 2.1 success criterion 2.4.2 (G88 https://www.w3.org/WAI/WCAG21/Techniques/general/G88.html) for sighted as well as screenreader users.
The most important information is front-loaded. First the task, visually hidden for sighted users, then the bundle name and then the bundle type. That way one is able to either stop scanning immediately and jump off or go on in case the person is visiting the content type for the first time or in case of uncertainty and or a small working memory. All necessary information is prominently available in the h1 and there is no need to search any further within the page.

We believe that the root cause to the problem is that the current page hierarchy isn't entirely correct. The primary tasks are listed under the current page title which means that it's not clear what the tabs are related to. The page title in many cases is more related to the secondary tasks. The current "workspace", or "context" is only described by the breadcrumb.

I agree that the current state (see regions_annotated.png) of having the primary tasks as the page title is super confusing. With the suggested Pattern A we went by the Ambiguous Tasks Title approach of Torrey Podmajersky from the Strategic Writing for UX book. Using a noun or a noun phrase that names the person's context that covers the entire set of ambiguous tasks (the primary tasks).
Having that entire context available in the h1 is mandatory due to the inherent nature of horizontal tabs in Drupal in contrast to vertical tabs. Each primary and secondary horizontal tab is a dedicated page with it's own route. For example

Manage display active as primary tab and Default active as secondary tab:
/admin/structure/types/manage/article/display

Manage display active as primary tab and RSS active as secondary tab:
/admin/structure/types/manage/article/display/rss

With the suggested Pattern A in combination with the proposed heading for the secondary tasks in the proposal_mock.png the page hierarchy looks clear and correct to me.

And I have to note while writing this comment that we completely forgot about those secondary tasks on the Manage display page in the two suggested patterns in #101. Those suggested patterns would have to be updated and adjusted.

Github has a similar page structure. Their page structure makes it clear where the user is navigating in, and what each of the tabs are related to.

I agree it is sort of clear but cognitively I still consider Github challenging to visually orient in regards of the overall account (context) and repo (workspace). It is basically a breadcrumb and the list of available tasks as primary tabs.
The page is missing a clear visual anchor/heading what the page is about. You have the breadcrumb with the context and workspace which is placed on top but still not prominently. The most important piece of information is the workspace and for that you have to scan past the context in the breadcrumb. Plus the font size is rather small and subsidiary. And if you take a look into the head and at the title element in Devtools you get the following:

Code tab active:
ckeditor/ckeditor5: Powerful rich text editor framework with a modular architecture, modern integrations, and features like collaborative editing.

Issues tab active:
Issues · ckeditor/ckeditor5

Pull requests tab active:
Pull requests · ckeditor/ckeditor5

The titles used on Github are more or less in line with #101 except for if the code tab is active which adds a wordy description instead of the active tab label like for the other titles. Plus in each case the title hasn't front-loaded the workspace before the context.

Cognitively I consider the prominent header in Drupal way more easy to scan and grasp. And as mentioned in #103 that header might be improved further by providing visual cues aside the improvements to the UX copy for the h1 discussed in this issue. So the user isn't necessarily required to read the entire h1 knowing in which bundle type one currently is in. I still have to write everything up and create that issue. Which would be the appropriate component to file it against? Should that go into Claro, the Node module or the Field_UI module?

Here's a mock that sets some direction to what we should explore. I don't think we should implement this as such because this isn't entirely right.

In regards of the Manage display page I like the idea of adding a heading/label for the View mode-tabs. That provides some sort context, clarity, and title to the secondary action tabs. Because without the permission Add, edit, and delete custom display modes. no regular user except admins would ever be in touch with the term View mode. Something I've realized when testing and commenting on the Same Page Preview module a few weeks ago. Regular users never really run into that term and concept within the admin ui.

In regards of the suggestion of using the bundle name for the h1 like in Drupal 7 (also suggested in #93) I would strongly disagree. Yes the h1 in the proposal_mock.png is shorter, but just using the bundle name has several downsides.

Sighted users can easily scan the bundle name. But you never know if another bundle type has a similar or identical name. Visually after scanning the h1 you have to switch one line up to the breadcrumb, but the bundle type isn't the first item on the right, you have to visually scan RTL (in contrast to LTR on the h1) to get to the bundle type. And then you have to visually jump to the primary tasks underneath the h1 and spot the active tab there. The overall context has to be chopped together from three different places which is visually challenging. For screenreader users the same task is even more cumbersome. In both cases WCAG 2.1 success criterion 2.4.2 isn't met, same as for the current state.

To reiterate and illustrate the thinking that went into Pattern A in #101 (see shortForm.jpg).

Screenreader users have all the necessary information available in the h1/title to grasp what the page at hand is about. First front-loaded the task aka the active tab label, visually hidden to sighted users, then the bundle name and finally the bundle type.

Ideally the h1's shouldn't differ for sighted and screenreader users Corbb O'Connor from the National Federation of the Blind recommended in one of the a11y office hours. Pattern B in #101 follows that advice. The downside with this approach is that the front-loaded task is redundant with the active primary tab, plus the h1 becomes too lengthy and hard to scan for sighted users. I've summarized that from my personal perspective as someone dealing with eye and vision problems in #102.

That is the reason why Pattern A visually hides the task from sighted users in the h1 and they are able to directly scan the front-loaded bundle name. In case they need to know the bundle type they can keep on scanning the current line instead of changing the line to the breadcrumb and scan there in a different direction.
The active primary task could then be easily spotted. Experienced users not even have to read but know based on the consistent tab position if the active tab is Edit, Manage fields, Manage form display, Manage display, or the Manage permissions tab.

In combination with the prominent and clearly structured header it would make the Drupal admin pages way more easy to process cognitively. It is also something I've noticed when comparing different versions of Drupal (OOTB and with all Core modules installed) with other CMSes (OOTB) for the reordering of the Drupal admin menu issue.

https://docs.google.com/spreadsheets/d/1o8JV3Qck92mV3CtoGdiRdqeRiW2L3Jk6...

I've slightly extended the effort and used the h1 or the apparent title in case no h1 was used on the particular page as the cell label. For sighted users many CMS systems were already difficult to navigate, for screenreader users even harder. And going through spreadsheets with just the h1 titles illustrates the necessity of having clear titles well in my opinion.

The only downside for sighted users with Pattern A is in case many pages are open in a browser window in horizontal tabs. The user is only able to see more or less the primary task label for each browser tab, the rest of each title is concatenated.

Overall Pattern A is still so far the most clear and scannable approach for sighted as well as screenreader users imho.

And there was a discussion with @aaronmchale about other related issues on the Drupal Slack. The direct link where the list starts within the thread is: https://drupal.slack.com/archives/C1AFW2ZPD/p1644603714706739?thread_ts=.... A meta issue might be created for those in case there is a wider agreement with the listed points.

Thank you @rkoller, I really like the proposal for Pattern A! My earlier concerns were aimed at the proposal in the issue summary, and I have to admit that somehow I had missed the proposal in #101. We have been working on a very similar proposal in #3370946: Page title should contextualize the local navigation and it has received positive feedback in user testing. I cross referenced your comments and tried to align the solution proposed here, which I believe is able to handle screen reader users in a more graceful way.

I'm going to mark this issue as postponed on #3370946: Page title should contextualize the local navigation because it will likely address 90% of the scope of this issue. Looking forward to your feedback on the solution there. 😊