Word Manage at beginning of multiple admin page names make them hard to distinguish.

I agree "Manage" makes things much harder to scan. I think we used to have or still have rules in terms of having a verb in a tab to express the act. "Manage" being a higher level task compared to "Edit". Edit would manipulate an object directly while "Manage" would manipulate a group of objects (in most cases). Not sure that distinction needs to be spelled out so well though, and people still need to figure out what is a "Manage form display" vs. a "Manage view display" in the first place.

This issue duplicates part of #2521780: The 'Edit', 'Manage display' and 'Manage form display' tabs were hard to understand and might be better to keep it together in one place.
Based on the outcome of the discussion going on in that issue, we might come to the conclusion that removing "manage" is a good idea, or we might find a different solution there.

Yeah I think the point is "manage" appears many other places :)

Still an interesting issue which I would not consider to close too early. Found this in #16 of #3381734: Locate drupalisms that might create confusion among users to be discussed as close candidates.

While this:

I agree "Manage" makes things much harder to scan. I think we used to have or still have rules in terms of having a verb in a tab to express the act. "Manage" being a higher level task compared to "Edit".

is important to take into account for the reasons it is designed yet as is, more over this:

I think the point is "manage" appears many other places

evaluates this issue to be still relevant.

Apart from that, I would like to put into account the readability of mass open Browser tabs (not Drupal tabs), where you only can see the word "manage..." quite soon in case of a narrowed screen or too much tabs open and makes it hard to distinguish display from form-display and other tabs starting with "manage...".

From UI concept/design issues in other software development projects where I needed to solve this: I would like to consider the "hierarchical/collapsible word composition concept". This is what I have named it just for my own purposes after making it to a thumb of rule for following projects. It describes the concept of making nested lists and hierarchies readable lines from top to bottom without repeating itself. It makes clear what the point in the middle or end is about when reading from top to bottom while saving space and following the DRY principle. Additional advantage: It prevents to change names or labels multiple times if requried.

That goes for folder trees but also for navigation and their respective page names. So this concept prefers table > legs > extensions over table > table legs > table leg extensions.

So we do not create hierarchies and navigations like:

table
-- table legs
-- -- table leg extensions

but rather:

table
-- legs
-- -- extensions

In Drupal we already do that in the respective path disussed here, since it correctly reads already: admin/structure/types/manage/article/display and not admin/structure/types/manage/article/manage-display.

While I see advantages in reading primary/secondary Drupal tab labels and page names like: edit | manage display | other settings because - like Gabor already stated - distinguishes better by verbs "edit" from "manage", it actually feels somewhat inconsequent and therefor rather would need to be edit content | manage display | other setting then instead.

To take all of this into account my suggestion for page names and Drupal manage tabs under "Manage " would be:

From:

-- Edit
 -- Manage display
 -- Manage form display

To:

 -- Content
 -- Display
 -- Form display

Or in case you need to keep it up with the verbs, then consequently to :

 -- Edit Content
 -- Manage display
 -- Manage form display

(I tried to shorten the title a bit.)

Still agree with myself from 6 years ago that Manage makes things hard to scan. I think what was not raised yet is the accessibility question. When navigating with a screen reader I think having the specific call to action well spelled out is super helpful. Maybe we can do that without displaying it though?

Still agree with myself from 6 years ago that Manage makes things hard to scan.

Same here. Then, we are 2 already. :-) Not sure if it shined thru the thoughts I layed out to show all sides of it is in the comment before yours, but that's exactly what I agreed to as well ;-) And made suggestions how to slidely change it. Actually not a big change since all information is already in place.

Can you give me an example regarding screen readers missing some of the respective information? From what I had to consider in such scenarios it turned out to be actually the same. All information is there in the "tree". Especially in case breadcrumbs are in place. Maybe it needs a visual example to see how it negatively affects Accessibility? Because I consider this as very important, like you do. If so, then yes, we can easely make additional text visible only for screen readers. Which is common practise.

Wonder if this should be closed for #3381734: Locate drupalisms that might create confusion among users though or minimum postponed till a decision is made over there. The linked ticket is the one going through ux reviews, imagine child issues will be opened or old issues repurposed when a plan is officially made.

Tagging though as @rkoller mentioned in #ux that this one has not been discussed.

Yeah, I see where you come from. To add my modest opinion: I consider #338173: How to place image as a part of a node/page, which I referred to already in #22, as a somewhat META-alike or parent to this here? This is why I see no further reason to close this here in favour of the other unless it is about to limit open issues at the moment. What I fully understand :-)

My reasons are that I think it needs more attention and opinions here from the community and a closed issue does maybe not encourage for that discussion? But maybe I am mistaken. I mean, at the end, this is not the most imortant issue we have, I agree. :-)

Another reason I'd defer to the other ticket, at least for now, is it seems to get more traffic and is having more discussion. This issue was opened 8+ years ago and never really got going. I'd love that putting in review would generate that discussion but based on how I've seen other issues appear I wouldn't be too hopeful. Joining #ux weekly usability meetings on Friday may help though.

Something I mentioned in the slack post in #ux is that there is currently a number of issues around the same stuff. Think first step is to clean those up before work is duplicated across multiple tickets.

We can leave in review though if others want to chime in but will eventually need to go through usability team, and again before anyone works on this usability review should happen before the work.

Joining #ux weekly usability meetings on Friday may help though.

Yeah, that's what I thougt too. Sadly for my schedule as a 3 times CEO it is hard to keep up with fixed appointments. But I will try my best if it helps.

there is currently a number of issues around the same stuff. Think first step is to clean those up before work is duplicated across multiple tickets.

This! Yep. You are right. I fully agree. Absolutely! +1

before anyone works on this usability review should happen before the work.

This is so important and thanks for you to ring this bell. I so often tried to explain why it is sometimes more important in issues to wait instead of kicking patches in immediately.

Let me bring up my 2 cents from #22 then on #ux if you don't mind, because I think that would be a good solution in the sense of "best of both worlds" alike.

So this seems to have sat for about a month with unfortunately no movement. But looking at #3381734: Locate drupalisms that might create confusion among users there seems to be ongoing meetings being had with the usability team.

I imagine once a plan is made these tickets will be either closed, repurposed, or continued (seems to be a number of them). To avoid potentially duplicate conversations being had lets just postpone this one and follow what goes on over there.