Adding credits to @griffynh for helping recruit the users.
@griffynh do you know if any of the users have d.o. accounts to attribute credits?
griffynh → credited ckrina → .
benjifisher → credited ckrina → .
Confirming that we reviewed the designs of this in the Top Bar in with Lauri and the XB design team, so this is good to go. Thanks for checking Matt :)
I've just tried this locally and I see this is changing from --admin-toolbar-color-gray-600 to --admin-toolbar-color-gray-800. While this is getting this to even pass WCAG AAA, it's changing the goal assigned by design: to provide an informative but unobtrusive label to a block/menu. Giving such a dark color to it places it almost at the same level as the rest of menu items, which generates more visual overload.
Since AFAIK this doesn't need to comply WCAG AAA, I'd recommend using --admin-toolbar-color-gray-700 since it already passes SC1.4.3.
Using --drupal-admin-color-green-400 (#009952) seems the more reasonable approach in terms of design and it'll keep the same variables so Gin&other can keep any override.
Thant you for working on this! Since this is changing the UI and have some consequences on the design, screenshots to compare the before & after would be needed.
volkswagenchick → credited ckrina → .
Added credits to @joaopauloc.dev and @finnsky and the rest of people who worked there for the worked in 📌 Integrate Navigation with Contextual editing Active .
Thanks both, doing all in one issue will make it easier. I've updated the title&issue summary.
@plopesc just mentioned that it'd be great to get ✨ Display content moderation state in the Navigation Top Bar Active merged in first. Not a blocker, but it's make things easier.
First, thank you all for pushing to solve this and all the work that happened so far.
Agreed with @aaronmchale and @berdir here, which is the main follow-up planned after removing the link from the title+dropdown because of the UX issues it was causing. I can't find the issue so I guess we forgot to open it with all the work happening the months we were sprinting to get Navigation into core.
How to determine what gets a "see all / see the parent/whatever" is what needs to be defined. I don't have a strong opinion on that and I'm sure we can come out with a good strategy if we can research patterns/needs. What I do know for sure is that adding an "Overview" to all sub-menus is not the right strategy because it creates a worst experience: it's adding extra links that in most cases will only get you to a page with the exact same links you already have in the menu (old admin list pages).
So I'm moving this to Needs works to define out the best strategy to print those "Overview" links only when they are really needed.
Some of the first ideas we had was to print anything that wasn't an admin list page, which is what @berdir is already suggesting in #59. I'd be happy to ship only with that (I understand you all need this) and we make incremental improvements later.
PD. @joelpittet the results of the tests for the navigation can be found in 🌱 [PLAN] Usability Testing and Research on the Toolbar Active , the ones specifically about the splitbutton pattern in 🌱 Toolbar Prototype Usability Testing Phase I Fixed .
Removing 📌 Integrate Navigation with Contextual editing Active from stable blcokers.
Switching to Closed (won't fix).
Removing 📌 Integrate Navigation with Contextual editing Active from Stable blocker. For more info read the comment in the issue 📌 Integrate Navigation with Contextual editing Active .
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 ✨ Implement a feature similar to the "Go Back" / escapeAdmin.js Postponed from the list since it is a pattern that needs another implementation rather than just porting what we had.
OK, this is going to come up as a surprise after all the work that has been put in here, but I think this should be closed as won't fix. But let me explain myself before doing a flip table :)
The whole point of this issue was to make sure we don't loose any functionality in core, and that's why we are adding this toggle button into the top bar (as a contextual item). But the real question is: should it be there in the first place? I tried to gather some feedback on the accessibility channel about actually removing it without luck, plus there's
🐛
The toggle that makes Contextual Links visible at all times might not be sufficiently discoverable
Active
that questions the whole reason of having the toolbar in the first place.
The reasonable direction would be to just finish the issue since you've done a lot of work and it's almost there. But we discussed this with @lauriii and we agreed that this is actually creating a new important problem: it's taking a lot of space on the Top Bar without providing much value, since it isn't a good solution even for the users that would actually need it (per 🐛 The toggle that makes Contextual Links visible at all times might not be sufficiently discoverable Active ).
So better strategy here is to not add this toggle into the Navigation itself, which would effectively remove it from core/Navigation by not integrating it. The we can focus on fixing the problems Contextual Links might have in there. So I'm removing Navigation stable blocker and Drupal CMS release target for now, and I'd move this to Closed (won't fix) as it's creating UX problems.
Finally, and most important, @joaopauloc.dev @plopesc @finnsky and @trackleft2 (and the rest of the people that worked on this): I'm really sorry that this work is not getting in. You've done an amazing work and I really want to acknowledge it. But getting this in this might cause more issues in the future that making the call now and getting rid of it. I hope this doesn't discourage you to keep helping on the Navigation, and if it does feel free to DM me and vent!
Making sure 📌 New Toolbar Roadmap: Path to Beta & Stable Active is set as the parent issue.
Add un-tracked issues marked as Navigation blockers. Let's discuss if they are really blocking the release.
Removing fixed issues.
We just discussed it with @plopesc and this still needs some definition in terms of UX for the different situations this would end ups giving a solution to, so it needs to be addressed more holistically and taking into account the changes XB is bringing into the future of the UI. So postponing this as "Needs design" since we'll work on defining it first.
The designs and some functionality still need to be agreed on. Setting this to postponed to be sure implementation doesn't start yet until that's defined.
Some more issues.
OK we discussed in Slack that moving the button outside the dropdown again will make things easier even thoug we moved it in there thinking it'd make it easier.
So the button now should appear on the top Bar, on the left side to be far from the entity actions themselves. Also, instead of having the "Edit" label, it changes to "Editable areas" so it doesn't collide with the entity Edit button. The icon is an eye, which conveys the show&hide action without taking as much horizontal space.
It should change the icon and the aria description or similar based on the state:
I've attached the SVGs too.
Updating issues.
Cleaning up Stable blockers to simplify the review of missing work for stable release.
I haven't checked the code, but seems simple enough to move it to RTBC anyway.
+1 on removing it and simplify this UI. The description "The text to be used for this link in the menu." is not giving any extra context on top of the field label itself "Menu link title", which is self-explanatory already. And the same for the link itself.
Updating IS to try to keep the issue focused.
Thanks both for reviewing this!
It's possible that "skip this step" was only added to ensure it's understood that you don't have to choose anything here
That's exactly the reason. The hypothesis is that making it obvious that they don't have to choose will help in terms of clarity for new users, avoiding them asking themselves "If I click next will I mess it up?". Some might try to interact with the form first or even choose something they don't want because they assume the UI needs it. So its goal is to improve learnability and reduce friction on this step.
That said, we'll test the installer on the user testing round on February and if we see it fails it we'll iterate on the proposal.
We've added this to the admin UI design backlog, but with lower priority since it isn't a Navigation Stable blocker and no core modules need 2nd level items. The first idea was implementing a drop-down, but we are not sure if that's really the best UI pattern based on the problems it should solve. Also in the future we’ll need to evaluate if we want to keep dividing the drop down from the right sidebar on entities as two different things, and if so define clear rules.
Changing the priority to Minor for now.
Closing as duplicated as it turns out there was already an issue for it 📌 Run a set of user interviews to inform Starshot marketing Active . I've moved your updates to the other issue. Thanks @zoocha will!
Updating issue summary with some more info provided by Will on the duplicated issue.
Marking as fixed and adding credits.
The resulting work can bee found here: https://www.drupal.org/node/3469446 → .
Updating a part of the credits. The Acquia work on this still need to be added.
Also marking as fixed since this has been published [#3461868].
Adding latest designs for the Top Bar as a reference.
Adding some screenshots to make it easier for designers to understand the needs and current situation.
Adding 📌 Evaluate if the Top Bar entity title needs to show extra Active as a should to have.
Adding 📌 Evaluate if the Top Bar entity title needs to show extra Active as a nice to have.
> This already sounds like a non-trivial special case.
> My suggestion would be to just focus on regular entity routes here.
If that's going to be complicated, agreed that spinning off another issue is a better approach instead of trying to solve all the things here.
> I guess one question is whether canonical pages and edit/delete pages should both just show the title or something else.
We are now adding helpful info into the Title itself, like prepending the "Edit" to the entity Title. In an ideal world this contextual / extra info should be communicated with UI elements instead of keep pushing things into the only places we had available years back. So this "you are editing" context could be communicated with visual elements assigning to them the appropriate visual relevance. I'd recommend solving as much as we can with new UI elements, even if we have to come up with them. I've created 📌 Evaluate if the Top Bar entity title needs to show extra Active to work on that on a follow-up.
What @amateescu said :)
All the early explorations we did trying to improve the workflow with Workspaces showed that we need to think about several existential interactions and UIs beyond the top dialog. That's why we kept this as "it only triggers the existing dialog" so we can get Navigation to Stable soon and not get into a way longer discussion that will block Navigation.
We just discussed this issue on Slack with @lauriii and @plopesc, and agreed on the following direction about the Title shown:
- If it’s an entity, Top Bar should show the entity’s Title
- If it’s a view, it should show the views's title. But only on the front-end because it needs an edit button (not on the admin People page for example)
I'd try to unblock this issue as much as we can trying to get the title right and then open follow-ups for improvements for the other info like the ones @berdir was suggesting. Since this is still experimental, that can be refactored an improved afterwards.
penyaskito → credited ckrina → .
+1to use experimental if that has an effect. I would assume everything related to XB is experimental until XB is stable
I think it makes sense to hide it given the stability of the Navigation module at this point. Not sure how, though.
Removing old list.
This is ready for implementation.
Adding design issues and prioritize component implementation issues.
Ready for implementation.
Ready for implementation.
Ready for implementation.
Opening again because the designs need to be updated to remove email&phone.
This is ready to implement.
Adding credits and marking as fixed.
I saved without refreshing the issue and lost some data. Adding them back.
I saved without refreshing the issue and lost some data. Adding them back. @balintbrews I can't assign the issue back to you.
I saved without refreshing the issue and lost some data. Adding them back. @boulaffasae I can't assign the issue back to you.
I saved without refreshing the issue and lost some data. Adding them back.
I saved without refreshing the issue and lost some data. @matthieuscarset I can't assign this back to you.
Figma link added.
Figma link added.
Figma link added.
Figma link added.
Adding the first round of issues to create components for Experience Builder.
Adding some more info for the implementation.
Adding credits to @jwitkowski79 and @Alyciamjones for the designs.
ckrina → created an issue. See original summary → .
Adding credits to @jwitkowski79 and @Alyciamjones for the designs.