New “content creation” menu proposal

We'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 🐛 Restrict access to empty top level administration pages Fixed .

Both in 🌱 Toolbar Prototype Usability Testing Phase I Fixed and 🌱 Toolbar Prototype Usability Testing Phase 2 Fixed , 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:

• Define which entities will be available by default on the Create menu
• Define which content-related items should be available in the first level
• Define how this proposal should be added to core: should it be a new menu or a change on the existing Administration menu? To note here that removing the content link from the Administration menu would imply a change in there already.

@ckrina that looks really good! It looks like what you've got there also addresses 📌 Add "Add" item to toolbar. Needs work .

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.

if we had every bundle/type from every content entity type, that could turn into a really big menu really quickly

100% 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.

I also worry that if you have more than one bundle with the same name across different content entity types, it could get confusing.

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.

First 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

• Grouping content by type: This is a fantastic way to reduce clutter and make it easier for users to find what they need. By grouping similar entity types together (e.g., Content type, Media, User, Other), users can quickly scan the menu and identify the right option. This also helps address the potential name clashing, for example a "Video" content type and media type, as options within a group are less likely to have conflicting names.
• Turning off items: Providing the ability to disable unused features is a great way to personalize the experience. Users can choose to see only the create content types they use regularly, further simplifying the menu and reducing decision fatigue. For example, disabling "Media" if they are entered via content creation.
• Adding items: Offering options to extend the menu with additional items is powerful. This caters to users with specific needs. They can leverage functionalities from contributed modules or custom modules. This flexibility allows the menu to adapt to different workflows and user requirements.

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

I created ✨ Grouping or prioritisation for items in create menu Active 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.