Closed (fixed)
Project:
Drupal core ideas
Component:
Idea
Priority:
Normal
Category:
Plan
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
15 Mar 2021 at 10:46 UTC
Updated:
19 Jan 2025 at 17:24 UTC
Jump to comment: Most recent, Most recent file



Comments
Comment #2
yoroy commentedComment #3
yoroy commentedComment #4
aaronmchale#2377543: Add "Add" item to toolbar. is related in that it would also introduce enhancements for adding content.
Comment #5
aaronmchaleI like this idea.
I have a similar use case, where I'm building a site that we need the toolbar to have different items depending on the role the user has. It's a Commerce site, using Gin as the theme and Gin Toolbar module along with the Toolbar Menu module.
I think my use case and the one this issue identifies bring up a more fundamental need for the core toolbar module to be more contextually adaptive. Maybe that would involve overhauling the Toolbar module's hard dependency on the "administrative" menu and allow configuring what the "primary" or "administrative" menu is on a per-role basis. With the proposed introduction of the Content Editor and Content Manager roles to standard, now is probably a good time to think about this.
Comment #6
dasjoto better understand the proposal, could you add an example menu tree that illustrates the result of the proposed resolution?
Comment #7
yoroy commentedComment #8
yoroy commentedYes :) I added a mockup and a link to a more elaborate description to the issue.
This link opens all diagrams and mockups in the diagrams.net online viewer.
Comment #9
aaronmchaleIf #1869638: Make the menu shown in the administration menu tray configurable lands, that could be a really positive first step to enable this kind of dedicated content-focused menu.
Comment #10
Bojhan commentedGreat idea, like a more opinionated shortcuts menu..
Comment #11
ipwa commentedI really like this, huge +1.
Comment #12
nod_probably a partial duplicate
This is at the idea stage, so +1/-1 from product manager needed before we can build out the plan/team.
Comment #13
nod_I guess since 3 core committers were part of the proposal it's a +1 on that front :)
need next steps though, might be good to look at the related issues from a few years back and close duplicates.
Comment #14
aaronmchaleThis issue I just filed could be quite relevant for the discussion here #3325034: Providing additional methods of navigating the admin interface, basically it exists to look at how we might better handle deep-linking between related areas of the Admin UI.
Comment #15
ckrinaWe've applied and tested this proposal on the new Content Creation menu on the new Toolbar project. Here's a screenshot of the current status of the prototype (not finals designs):

What we've done is we've moved the "content" link from the admin Toolbar to its own section, and we've split it with several first level items + the proposed new "Create" option.
Users with access only to the content-related items will now be able to see only meaningful items thanks to #296693: Restrict access to empty top level administration pages.
Both in #3379160: Toolbar Prototype Usability Testing Phase I and #3385182: Toolbar Prototype Usability Testing Phase 2, we've had really good feedback from all testers. We've only encountered some confusion with the first level item "blocks" (recently moved inside the Content section) where a content user wasn't able to understand what that meant.
Some of the next steps in here should include:
Comment #16
aaronmchale@ckrina that looks really good! It looks like what you've got there also addresses #2377543: Add "Add" item to toolbar..
My feeling is that, in this new "Create" menu, if we had every bundle/type from every content entity type, that could turn into a really big menu really quickly, and become hard to find a specific bundle/type on bigger sites. I also worry that if you have more than one bundle with the same name across different content entity types, it could get confusing. For example, I could see a situation where a site might have a "Blog" taxonomy and a "Blog" content type, just as examples.
What I'm thinking is that, maybe it's better to have one link for each content entity type, so a "Media" link, a "Taxonomy" link, etc; which would then take you to the Add Page which lists each bundle. I think that potentially works better because it mitigates the risk of the menu becoming overwhelming, and still allows for the Descriptions on each bundle to be useful/visible.
I think Node should be the one exception to that though, in a lot of cases we treat Content Types as their own distinct thing. When a user wants to add something, they think about it in terms of what type of page they want to add - an Article, a Blog post, etc - and since Content Types are likely the most common entities which get added, I think it's reasonable to have each one listed. We've never been very good at describing what Nodes are in the UI, we call them Content, but really Media is also content, Taxonomy Terms are also content, so listing those individually I think helps reduce confusion. Constrast that to Media or Taxonomy, it's pretty clear what those are, if a user wants to add an Image, going to the Create menu, then selecting Media, then Image, probably feels quite intuitive. It's probably the same with Taxonomy, you likely know what you're adding if you're adding a Taxonomy Term *.
* That's assuming the user knows what a Taxonomy is, it's a well understood term in specific circles, and not all content editors will understand what those are, but I think that's something which can be worked around with training materials, etc.
Comment #17
ckrina100% agree. IMHO the way to go here is to only enable some bundles, not all of them. This can open the can of worms because for some users/roles some content types might be more useful, and for some others the list could be different. But if we want to get a reasonable MVP we can leave the door/API open for really good contrib improvements.
Really good point, thanks for posting it! As you say, neither Taxonomy nor Vocabulary is something all users would understand, and what about those items with just one child? i.e. just one vocabulary. Then adding this extra step in the flyout might be useless or would mean over-complicating the UI. I'd try to go with an approach that would let site builders choose what to add in there, so maybe we could assume they would be responsible enough to differentiate the names/titles used and avoid this "Blog"(CT) & "Blog"(term) situation.
Comment #18
ckngFirst time using the new Navigation, great works here. I think the main UX feedback is the Create content area is it is rather confusing.
Here are some suggestions for Create content improvement
Comment #19
pameeela commentedI have the same feedback as #18, was thinking about this just yesterday! But I think this feedback is probably better off going into the actual issue queue? Since it's well past the idea phase now.
Comment #20
pameeela commentedI created #3457729: Grouping or prioritisation for items in create menu for the first part of this. The second two items are a separate feature request I think, to allow individual users to customise their own menu. Separate to that could be a feature to allow customisation of it globally. I haven't created issues for those although they may already exist.
Comment #21
pameeela commentedI'm going to mark this fixed since it has been implemented already, as discussed. Further feedback should go into the core queue for consideration or action.
Comment #22
saschaeggi@pameeela can we add an issue credit for lauriii and myself as we have worked on the initial proposal, too
Thanks!
Comment #24
ckrinaComment #25
saschaeggiThank you Cristina 💙