[PLAN] Top contextual bar

Updated with a list of the remaining issues.

I'd also like to see what that top bar might look like in the context of viewing the published version (if one exists) or viewing the current draft. I'm not a big fan of hiding things under "more options"; can that be an individual user's preference setting? Some users probably prefer less clutter, others like me prefer my options to be in sight.

Thinking about it though, if we were going to not have a preference setting:

• The "more options" would make sense, when in edit draft mode, to only show things that you can when do while editing a draft, and hiding things like Revisions.
• However, when viewing the rendered saved draft or the published version, I would want to see all options and not have any of them hidden under More options.

Adding reference to #3442059: Create feature flag module to control navigation top bar visibility

More layout use please! (:

from: https://www.drupal.org/project/navigation/issues/3425081#comment-15568869

We need to keep in mind that other modules 'opt-in' to using toolbar via hook_toolbar:

• Workspaces (core): add a 'tab' (only) and attaches js/css via library api (which opens the top fixed off-canvus drawer that is the Workspaces UI)
• Announcements (core) : add a tab (only) opens to external hosting tools dashboard.
• Acquia Connector: add a tab (only) opens to external hosting tools dashboard (is highly styled. library).
• Devel: adds 'tab' and 'tray' of child menu item [see: \Drupal\devel\ToolbarHandler]
• Env Indicator: general use cases, add a'tab' - label and color changes.
• demo_umami: (core profile) adds 'tab' item to say This site is intended for demonstration purposes.

For example: local tasks, navigations own 'user' plugin' should both be locked.
- umami doesn't need to lock itself, maybe user want to use it! (:
- workspaces would prefer to ensure is (generally) placed, and locked.

Also: currently we place 'help link' as part of our 'user plugin' -- but Help Module should provide this!

It could use to provide help topics for the module

We're missing a breadcrumb more that a return link which then fills the space we need (sm->mid breakpoint ranges)

noting:
- right most icon is meant to be Node Forms vertical tabs
- actions include old style tab items (ie: revision, also normal for developers 'devel' would follow)

I realize this is a mixed issue conversation point:
In this respect, you would want the vertical tabs 'pill' to always be the rightmost among other pills placed in the zone.

Replacing the screenshot posted to avoid confusion and discussions about unrelated elements on the page. Please take into account that this is still on the definition phase where we are actively defining (and testing) which features to provide.
Yes, the plan is to provide an plugable system for contribs and custom modules. But we still need to define where goes what and why, and after that provide the necessary documentation to help everybody make the best call. But as today we're not there yet :)

We started using layout builder in mega menu's awhile ago with great success, and seeing layout builder implemented in the new navigation builder successfully is awesome. I'd love to see it used here. We could have blocks for 'Entity Operations', 'Form Actions', etc. With the left toolbar acting more global, and the top bar holding more contextual info, we could take advantage of the existing Context system for some of the block visibility handling. This approach makes it far easier for other modules to extend and override the top bar without having to override templates everywhere.

I'd be happy to build that in similar fashion to the left hand toolbar if it would be helpful.

Changing the image with updated designs and some explanation of the areas.

Thank you @ckrina for the new updated design and explanation of the areas.

Below you can find an implementation proposal based on the feedback collected so far:

Given that top_bar is not intended to be configurable for end users, we agreed that it should be handled using a code only approach, not providing a UI for it.

Navigation Top Bar module will provide a hook, hook_navigation_top_bar(), where modules will be capable to add items to the 3 different top bar regions (tool, contextual & actions). A similar alter hook will allow to modify the items added beforehand.

Navigation Top Bar will provide a render element where modules will declare their Top Bar elements, the section they belong to and their weight, in a similar way as toolbar_item element does.

Contrib module developers will need to be careful adding new elements to this section, given that space is limited and adding more items than necessary could cause negative effects in the site UI.

I'd like to suggest an improvement.

The empty space alongside the logo in the navigation seems to be a "lost" space.

We should place the logo in the top bar and make it a full width component.

It will 1) improve the navigation sidebar design and 2) provide more space to add more items in the topbar.

Example in the capture attached.

@matthieuscarset thank you for the suggestion.

We already evaluated the solution you're proposing internally and with the XB team (together with several other ones) and agreed to go with the one defined in comment #19 .

Edit: To clarify: the goal is to get Navigation into stable asap. Revisions might happen in the future, but since we've evaluated other options already we'll launch with this for now in a way that doesn't have major implications on the scope of work needed to reach stable.

Adding the issue to define those 3 regions: #3484564: Define the 3 areas the Top Bar will provide.

Thanks @finnsky for the proof of concept! Could you move the work into #3484601: Proof of concept for the components that will render the top bar so we can focus the discussions in this issue to higher level / less detailed topics and the implementation ones in the other? I added it into the summary so it is taken into account too and can be used as reference.

Added also the next steps for the content that can be placed already:

• #3484575: Move the Edit button outside the more actions drop down
• #3484600: Show entity information on the Top Bar

Other things from the designs (like removing the more actions and replacing it by 3 dots) will need issues created too, but they are not stable blockers.

Updating the issue summary to make it clear what are the next steps and blockers to get to Stable.

Also, @finnsky closing the MR because we don't want code on META issues. If you think it's still useful to keep it could you please move it to #3484601: Proof of concept for the components that will render the top bar? Otherwise that issue can be closed.

Added parent #3421969: [PLAN] New Navigation and Top Bar to replace Toolbar Roadmap: Path to Stable.

Updated what Stable release means.

Adding #3499783: Evaluate if the Top Bar entity title needs to show extra info as a nice to have.

Adding #3501465: Navigation Top Bar Page Actions dropdown should not include link to the current page and order should respect local tasks weight

Updating issues.

Some more issues.

Removing #3465295: Integrate Top Bar Navigation with Contextual editing from Stable blocker. For more info read the comment in the issue.

Also cleaning up the rest of the closed issues from the list, so we can start working towards getting the Navigation to Stable. 🎉

I've also removed #3446699: Implement a feature similar to the "Go Back" / escapeAdmin.js from the list since it is a pattern that needs another implementation rather than just porting what we had.

Added #3508199: Navigation Top Bar accessibility issues found by Nightwatch tests

Added #3511612: Local task name expectation in getFeaturedPageActions is fragile for determining Top Bar featured actions as 'Must have'.

Added #3507866: Enable the Navigation Top Bar when Navigation is enabled as 'Must have'.

Added a couple of bugs to 'Nice to have':

#3501662: navigation top bar edit button has strange active (?) colors
#3501507: Navigation top bar overlaps with Olivero menu

Moving #3511612: Local task name expectation in getFeaturedPageActions is fragile for determining Top Bar featured actions to nice to have, per the discussion on the issue, see #3511612-12: Local task name expectation in getFeaturedPageActions is fragile for determining Top Bar featured actions and above.

I think it would be a good idea at this point to merge this issue back into #3421969: [PLAN] New Navigation and Top Bar to replace Toolbar Roadmap: Path to Stable so that all the must/should have etc. issues for the navigation module are tracked in one place - it's only one module that provides two bars, we can have subsections on the main issue, but it's hard to follow with it split like this - and the other issue has some top bar issues already.