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

Created on 27 February 2016, almost 9 years ago
Updated 8 March 2024, 10 months ago

Problem

The "manage" prefix before several different administrative UI names eg. "manage fields", "manage display", makes these options more similar to one another and harder for the user to scan and quickly disambiguate.

"Manage" adds no additional meaning since everything an administrator does is to some extent about "managing" (ti is, after all a content *management* system).

Addtionally this one extra word often repeats itself four or five times in a row of tabs, lengthening the set of tabs and making it needlessly more complex.

Solution

Remove the word "Manage" from interface text wherever it is part of a UI name/tab. Discuss removing it everywhere.

Impacts

AFAIK in Drupal 8 UI text changes do not impact APIs as the machine names can remain the same. Obviously there would be non-trivial impact on documentation.

πŸ“Œ Task
Status

Postponed

Version

11.0 πŸ”₯

Component
UI textΒ  β†’

Last updated 5 days ago

No maintainer
Created by

πŸ‡ΊπŸ‡ΈUnited States tkoleary

Live updates comments and jobs are added and updated live.
  • Needs usability review

    Used to alert the usability topic maintainer(s) that an issue significantly affects (or has the potential to affect) the usability of Drupal, and their signoff is needed. When adding this tag, make it easy to review the issue. Make sure the issue summary describes the problem and the proposed solution. Screenshots usually help a lot! To get sign-off on issues with the "Needs usability review" tag, post about them in the #ux channel on Drupal Slack, and/or attend a UX meeting to demo the patch and get direct feedback from designers/UX folks/product management on next steps. If an issue represents a significant new feature, UI change, or change to the general "user experience" of Drupal, use Needs product manager review instead. See the scope of responsibilities for product managers.

Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • πŸ‡«πŸ‡·France dqd London | N.Y.C | Paris | Hamburg | Berlin

    Still an interesting issue which I would not consider to close too early. Found this in #16 πŸ“Œ Locate drupalisms that might create confusion among users Active of πŸ“Œ Locate drupalisms that might create confusion among users Active 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 just can see the word "manage..." then only quite soon when the narrow on screen.

    From other UI design issues for software development 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 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. Same goes for folder trees and navigation. So not table > table legs > table leg extensions but table > legs > 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 tabs like: edit | manage display | other settings because - like Gabor already stated - distinguishes by verbs "edit" from "manage" better, 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 would be: Change the tabs under "Manage ":

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

  • Status changed to Needs review 11 months ago
  • πŸ‡«πŸ‡·France dqd London | N.Y.C | Paris | Hamburg | Berlin
  • πŸ‡­πŸ‡ΊHungary GΓ‘bor Hojtsy Hungary

    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?

  • πŸ‡«πŸ‡·France dqd London | N.Y.C | Paris | Hamburg | Berlin

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

    Then, we are 2 already. :-) Not sure if it came thru the back and forth thoughts I hade to made to show all sides of the way it is, 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". 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.

  • πŸ‡ΊπŸ‡ΈUnited States smustgrave

    Wonder if this should be closed for πŸ“Œ Locate drupalisms that might create confusion among users Active 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.

  • πŸ‡«πŸ‡·France dqd London | N.Y.C | Paris | Hamburg | Berlin

    I see your points. 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 πŸ“Œ Word Manage at beginning of multiple admin page names make them hard to distinguish. Needs review , as a somewhat META-alike or parent to this here. But 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.

  • πŸ‡ΊπŸ‡ΈUnited States smustgrave

    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.

  • πŸ‡«πŸ‡·France dqd London | N.Y.C | Paris | Hamburg | Berlin

    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 πŸ“Œ Word Manage at beginning of multiple admin page names make them hard to distinguish. Needs review 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.

  • Status changed to Postponed 10 months ago
  • πŸ‡ΊπŸ‡ΈUnited States smustgrave

    So this seems to have sat for about a month with unfortunately no movement. But looking at πŸ“Œ Locate drupalisms that might create confusion among users Active 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.

Production build 0.71.5 2024