Problem/Motivation
During the 2015 usability study, users struggled with the process of adding a new content type. After creating a content type, you are redirected to the Manage fields screen; however, the heading for this page does not contain the name of the content type you are managing fields for. It can only be found in the breadcrumb (and even that has issues, see #2513570: Changing name (label) of content type is not reflected in breadcrumb link text).
Consequently, some users thought they failed to create a content type because when they were redirected to the manage fields screen, they said "This page has nothing to do with what I just did."
This is a regression from D7, since that screen uses the content type in the heading.
Proposed resolution
Include the content type name (or entity type name) in the heading of the Manage fields page to orient the user and inform them what they are managing fields for:
Not just for noobies
This will also benefit experienced users because it will help prevent adding fields to the wrong content type.
User interface changes
Manage fields heading will have more text.
API changes
None.
Data model changes
None.
Beta phase evaluation
Issue category | Bug because introduces a regression |
---|---|
Issue priority | Not critical because it breaks no functionality. |
Disruption | No disruption |
AI Summary (Bing: April 22, 2023)
Can you summarize this article and find any outstanding to-do items that should be addressed https://www.drupal.org/project/drupal/issues/2514218#comment-15020959
Not yet good enough. Maybe one day....
Comment | File | Size | Author |
---|---|---|---|
#115 | proposal_mock.png | 146.34 KB | lauriii |
#115 | github_annotated.png | 135.03 KB | lauriii |
#115 | regions_annotated.png | 170.35 KB | lauriii |
#111 | 2514218-111.patch | 21.01 KB | bnjmnm |
#110 | 2514218-110-10x.patch | 18.18 KB | bnjmnm |
Issue fork drupal-2514218
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #1
cilefen CreditAttribution: cilefen commentedThis is actually a regression from 7.
Comment #2
cilefen CreditAttribution: cilefen commentedThe same goes for the other "Manage display" tabs.
Comment #3
cilefen CreditAttribution: cilefen commentedI 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.
Comment #4
lunk rat CreditAttribution: lunk rat commentedComment #6
martins.kajins CreditAttribution: martins.kajins commentedManage fields and Manage display title includes name of the content type
Comment #9
martins.kajins CreditAttribution: martins.kajins commentedMy previous patch had line dpm($defaults); which probably caused patch to fail.
Comment #12
jaxxed CreditAttribution: jaxxed at Wunder commented@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.)
Comment #13
claudiu.cristeaTrying to fix all once.
Comment #14
cilefen CreditAttribution: cilefen commented@claudiu.cristea If this is a bug, is it a regression ? .... Oh, I see in the issue title. Carry on!
Comment #15
cilefen CreditAttribution: cilefen commentedThe 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?
Comment #16
claudiu.cristea@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.
Comment #17
martins.kajins CreditAttribution: martins.kajins commentedPatch from #13 works.
Comment #18
cilefen CreditAttribution: cilefen commented"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".
Comment #19
martins.kajins CreditAttribution: martins.kajins commented#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.
Comment #20
claudiu.cristea@cilefen,
It works. After applying the patch you'll need to rebuild the cache.
"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).Comment #21
maris.abols CreditAttribution: maris.abols commentedComment #22
claudiu.cristeaComment #23
maris.abols CreditAttribution: maris.abols commentedTested with #13 path and everything works just fine. I did cache rebuild as claudiu.cristea told.
Comment #24
cilefen CreditAttribution: cilefen commentedBy 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".
Comment #25
cilefen CreditAttribution: cilefen commentedOk, 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.
Comment #26
cilefen CreditAttribution: cilefen commentedComment #27
alexpottMaking 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.The rules for spaces around
:
are language dependent. This needs to be in a t().Comment #28
yoroy CreditAttribution: yoroy as a volunteer commentedAgree 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)
Comment #29
claudiu.cristea@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.
Comment #30
alexpottre #24 and subsequent comments... we just need to the get the label of the entity type that is the bundle_of... something like...
Comment #31
claudiu.cristeaTranslationWrapper
.TranslationWrapper
placeholder arguments.Comment #34
claudiu.cristeaGreen light on #31. That includes #27 and #30. Who's gonna review the patch?
Comment #35
cilefen CreditAttribution: cilefen commentedI have a meetup tonight - I'll try to look it over then if nobody else does first.
Comment #36
cilefen CreditAttribution: cilefen commentedWe 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.
Comment #37
cilefen CreditAttribution: cilefen commentedAs 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?
Comment #38
jaxxed CreditAttribution: jaxxed at Wunder commented@cilefen changing the edit page could be spun off into it's own issue, as backporting should be done. Should this be considered reviewed?
Comment #39
cilefen CreditAttribution: cilefen commented@jaxxed We need a volunteer to manually test each path to make sure there are no surprises.
Comment #40
claudiu.cristeaNot manually, eventually make the tests cover all cases (if it's not yet in place)
Comment #41
jaxxed CreditAttribution: jaxxed at Wunder commentedI can try to get to writing the tests tomorrow, but for the record I think that having tests for this issue are unnecessary (superfluous.)
Comment #42
NikitaJain CreditAttribution: NikitaJain commentedTested 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.
Comment #43
claudiu.cristeaThis 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?Comment #44
NikitaJain CreditAttribution: NikitaJain commented@claudiu.cristea : Thanks, you were right checked again the same scenarios after clearing the drupal cache & its working fine.
Comment #45
claudiu.cristeaComment #46
claudiu.cristeaGreen light. Who's gonna review it? :)
Comment #47
maris.abols CreditAttribution: maris.abols commentedComment #48
maris.abols CreditAttribution: maris.abols commentedclaudiu.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.
Comment #49
claudiu.cristea@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.
Comment #50
claudiu.cristea@martins.kajins, here is the patch. Ready for reviews :)
Comment #51
Bojhan CreditAttribution: Bojhan as a volunteer and commentedDo we really need "For content type" we should be able to go just with with Manage fields: [content type]
Comment #52
claudiu.cristea@Bojhan, that was the requirement. See also comments #18 to #30.
Comment #53
cilefen CreditAttribution: cilefen commentedNot exactly. In #18, I didn't like "Manage fields for Content: Article" . "Manage fields: Article" could be good.
Comment #54
claudiu.cristeaIn 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".
Comment #55
Bojhan CreditAttribution: Bojhan as a volunteer and commentedI 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.
Comment #56
claudiu.cristeaGoing 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.
Comment #57
cilefen CreditAttribution: cilefen commentedI 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:
Comment #58
maris.abols CreditAttribution: maris.abols commentedThis time #50 patch seems to be ok. Everything works just fine, no errors and both tests are passing.
Comment #59
maris.abols CreditAttribution: maris.abols commentedComment #60
Bojhan CreditAttribution: Bojhan as a volunteer and commentedNope, this is not going into RC unless we get actual resolution to #55. There are just not enough gains to warrant such clutter.
Comment #61
claudiu.cristeaWe 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
Comment #62
xjmWhy not just (e.g.) "Manage basic page field display"?
Comment #63
xjmAs a UI/string change, this is a minor version target.
Comment #64
xjmOh, 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.
Comment #65
xjmAnother question on the patch itself:
This seems to change what the test is asserting; why is it included in the patch?
Comment #67
andrewmacpherson CreditAttribution: andrewmacpherson as a volunteer commentedClosed 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
Comment #68
andrewmacpherson CreditAttribution: andrewmacpherson as a volunteer commentedAnd 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
Comment #69
joachim CreditAttribution: joachim commented> 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.
Comment #70
vijaycs85Another 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
Comment #72
joachim CreditAttribution: joachim commented> 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.
Comment #74
phenaproximaIt'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"?:
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...
Comment #75
joachim CreditAttribution: joachim commented> 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?
Comment #76
yoroy CreditAttribution: yoroy as a volunteer commentedThanks 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).
Comment #77
joachim CreditAttribution: joachim commentedI'm working on this. Slowly (it's taken me about 3 weeks of meaning to start work on it to actually start), but surely :)
Comment #80
joachim CreditAttribution: joachim as a volunteer commentedArgh, 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.
Comment #81
joachim CreditAttribution: joachim as a volunteer commentedOh and unassigning myself!
Comment #88
donquixote CreditAttribution: donquixote commentedFor 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.
Comment #89
nikitagupta CreditAttribution: nikitagupta at Srijan | A Material+ Company for Drupal India Association commentedRe-rolled patch #80.
Comment #92
joachim CreditAttribution: joachim as a volunteer commentedMoved the code over to a MR.
Comment #93
donquixote CreditAttribution: donquixote commentedBtw 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:
So the "Blog post" is repeated in the breadcrumb.
I think the behavior in Drupal 7 is perfect, we should replicate it.
Comment #95
joachim CreditAttribution: joachim as a volunteer commentedAh, 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!)
Comment #96
joachim CreditAttribution: joachim as a volunteer commentedOops, didn't mean to change the version!
Comment #97
joachim CreditAttribution: joachim as a volunteer commentedRebased 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.
Comment #98
rkollerThis 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:
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:
Manage Article fields (2)Article: Manage fields (1)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.
Comment #101
rkollerAt 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 withManage 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
:
tofor
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
Comment #102
rkollerI 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 typ
e) I would have to scan three words pastManage 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.
Comment #103
mgiffordIn 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.
Comment #104
mgiffordComment #106
mgiffordI think this is also a WCAG 1.1.1 issue.
Comment #107
needs-review-queue-bot CreditAttribution: needs-review-queue-bot as a volunteer commentedThe 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.
Comment #108
joachim CreditAttribution: joachim as a volunteer commented@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?
Comment #109
lauriiiComment #110
bnjmnmComment #111
bnjmnmComment #115
lauriiiDiscussed 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.
Comment #116
mgiffordRe-tagging this after talking with @rkoller
Comment #117
mgiffordExperimenting with ML summaries.
Comment #118
mgiffordNixing confusing AI summary. Adding back in 1.1.1 SC.
Comment #120
rkollerre #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.
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.
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 theAmbiguous Tasks Title
approach of Torrey Podmajersky from theStrategic 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 andDefault
active as secondary tab:/admin/structure/types/manage/article/display
Manage display
active as primary tab andRSS
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 theproposal_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.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
, theNode module
or theField_UI module
?In regards of the
Manage display
page I like the idea of adding a heading/label for theView mode
-tabs. That provides some sort context, clarity, and title to the secondary action tabs. Because without the permissionAdd, edit, and delete custom display modes.
no regular user except admins would ever be in touch with the termView mode
. Something I've realized when testing and commenting on theSame 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 (seeshortForm.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 theManage 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.
Comment #121
lauriiiThank 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. 😊