I've done one already to a direct marketing contact, not sharing the recording since it was in Spanish. Please let me know when you come together for the review so we call put together all the findings.
I'm all in with using logical properties everywhere. It makes things way easier to do style with modern CSS.
I haven't looked thought all the code, but I've spotted a a small thing that desn't make a lot of sense:
Being removed: padding: 0 var(--off-canvas-padding) var(--off-canvas-padding);
Being added:
padding-block: 0 var(--off-canvas-padding);
padding-inline: var(--off-canvas-padding);
I'd still prioritize the shorten version of a property on top of the logical one separated because the shorten includes the logical properties too. So I wonder if it's a matter of improving the script?
jjchinquist → credited ckrina → .
Or would you prefer me to revert the commits that move the message?
As mentioned in my message, yes: not merging things that don't follow the designs would be how I would address things. If you want to move quickly I wouldn't do UI changes into this issue that is supposed to focus on "Grant author and editor roles permissions to Navigation module".
If so, it will mean we have tests involving the toolbar even though we don't have toolbar installed any more.
Then, maybe the other issue needs to get in before this one?
Good to see progress on this! But FYI we already have designs for the Umami message integration 📌 Integrate Umami message Active after putting some thoughts to it and following the design system we're working on, and it would be great that this would go with those. The left sidebar is supposed to hold all the site-wide information shown on the admin UI, so it doesn't make sense to throw it into the header of the site. Where would you show it int the front-end?
I'd recommend keeping the permissions and the new designs into 2 separated issues so one doesn't block the other.
Good to see progress on this! But FYI we already have designs for the Umami message integration after putting some thoughts to it and following the design system we're working on, and it would be great that this would go with those. The left sidebar is supposed to hold all the site-wide information shown on the admin UI, so it doesn't make sense to throw it into the header of the site. Where would you show it int the front-end?
I'd recommend keeping the permissions and the new designs into 2 separated issues so one doesn't block the other.
pameeela → credited ckrina → .
pameeela → credited ckrina → .
With tour, if the contrib tour module can provide integration, that might work for 10.x, because sites on 10.x can also install that. Either way I would leave tour to last - navigation can be stable in 11.x, and then we can figure out what to do about 10.x from there.
By @catch in Slack.
Next steps in this issue is figure out how to integrate the Tour module. Ideally, a designer should be the one taking next steps here to propose how to integrate Tour with Navigation.
This is a visual change, please add before and after screenshots so we can compare and see the results.
@Gábor Hojtsy yes, those other icons are used on the internal Workspaces UI we're still working on. :)
I gorgot to mention that I opened some follow-ups for the rest of the modules to focus this issue only on Workspaces on the Navigation itself, so the rest of the modules have their own issues:
Updating with the issues for core modules that need integrations.
I've updated the first round of designs so the implementation of this can start. This will still miss hover states, for example. I've also added the new icon SVG.
I forgot to add the Navigation stable blocker tag.
Not sure if the component needs to be Navigation or Announcements, so leaving into Navigation for now because we need to provide the designs and styles at least.
wow, this is going fast and I haven't been able to comment before. Thanks all!
As mentioned, we're working on a design for this that will have similar styles as Workspaces (as it's a stable blocker to get Navigation into stable). I know the modules are different, but the UI is similar in a lost of ways. We're working on the styles for the "drawer" once opened, but we haven't finished that yet.
I'm sharing the designs here so you can see the direction (not finished designs yet since we still need to change several things, like the buttons), but I'd recommend not merging this until we've been able to finish the designs.
When we finish the designs for Workspaces, it'll be implemented on the Navigation itself and you'll be able to reuse part of the code without implementing it here.
About the screenshots I'm seeing: I'd recommend trimming the text as we're doing for the icons in the Navigation instead of applying a gradient. See https://git.drupalcode.org/project/drupal/-/blob/11.x/core/modules/navig...
jjchinquist → credited ckrina → .
First, thanks all for working on this and finding a place that needs improvement. I agree with you all on this being one of those places.
We have restored the warning icon before the deprecated text on deprecated modules, just like in the Seven theme.
Even if this existed in Seven, it doesn't mean it'll visually work in Claro: it results in a really packed, confusing and un-structured group of elements. The solution proposed here is not the right one on a design/UI perspective. The title/heading is designed to hold the title, not title + parenthesis and its text + icons. We can't add info and elements to places that are not designed for that when there are no designs.
The goal of this issue is to make more obvious that a module is obsolete. +1 to that. The next step here is to find the right UI solution for Claro (applies to any UI), and that needs a designer designing that new part of the UI that don't exists (even if that existed in Seven, that solution doesn't work here). When that design is aproved, then let's jump into the implementation. This is the best workflow to be sure we end up with digestible UIs. :)
valthebald → credited ckrina → .
So the navigation module will allow a color change and the environment indicator will have to interact with this new API?
I have no idea about the implementation, but I bet nobody has thought about it yet. @plopesc and @m4olivei are the right people to answer this. (@m4olivei was who brought this up to my attention so I'm sure he can help)
Hi @dagmar, thanks for your help with ideas to integrate the Navigation with other modules.
On our designs explorations for the Navigation we already designed for the Environment indicator, in a way that can co-exist with Workspaces. Here are the designs we agreed on, where the initials of the environment are also used as an indicator. They are really close to your explorations, which is great :) Changing the logo background was discarded because the logo can be replaced and either take the whole space or not work well with the color chosen for one of the environments. Credits for this designs should go to @jponch and @anabarcelona.
Either way, I've added this issue to the Navigation roadmap. Thanks!
Adding "Needs subsystem maintainer review" to be sure we get a +1 from a SDC subsystem maintainer. This is a very important first step to integrate SDC into the admin UI and we better get it right :)
Adding 🌱 [META] Migrate Navigation to SDC Active and removing completed tasks.
ckrina → changed the visibility of the branch 3458246-add-subsystem-maintainers to hidden.
Claro already has designs for the blue color, so you can you them for the implementation if you want: https://www.figma.com/design/OqWgzAluHtsOd5uwm1lubFeH/%F0%9F%92%A7-Drupa...
The blue one is targeted to "Status" messages, where the system is informing of something beyond the warning/error/"succeed" type of message. That's why the icon is an "i": it's giving information. Using a bell for it seems more as a "notification" that you have to read, tied to other UI patterns we don't use here.
On the other side, why do you want a gray message? What is its purpose? Which kind of information will it try to communicate? If it's just a communication, why can't it be blue? As a Claro maintainer, I'd love to see this backed with a need instead of opening the floor to any kind of color for messages.
Also, to approve any UI work it would be good to see the messages working with the while interface, not a small piece of it.
Thanks!
pameeela → credited ckrina → .
We would need confirmation from each person that they agree and understand the role as explained in https://www.drupal.org/contribute/core/maintainers#subsystem → .
Personally, I understand the role and I'm happy to continue helping here.
I just pushed the work that @e0ipso helped me do for the Toolbar button component during DrupalCon Portland. It's just initial work so feel free to pick it and follow the work from there.
ckrina → changed the visibility of the branch 3458215-sdc-button-component to hidden.
ckrina → changed the visibility of the branch 3458215-migrate-toolbar-button to active.
ckrina → changed the visibility of the branch 3458215-migrate-toolbar-button to hidden.
Note: I haven’t added as components the following items:
- Admin Toolbar. I see this more as a region rather than a component
- Top Bar. Same, I see this more as a a region
- Body Scroll lock: I see this more as an utility
I know @finnsky had ideas to plan Phase 2, so leaving this here so he can work on it.
pameeela → credited ckrina → .
pameeela → credited ckrina → .
pameeela → credited ckrina → .
pameeela → credited ckrina → .
pameeela → credited ckrina → .
pameeela → credited ckrina → .
This look great! Thanks for working on this and improving the UX.
From the Save & Edit description:
saves the newest content edits while keeping the user on the node edit page. This feature allows users to manually save drafts as they work on site content without getting distracted by a redirect to the content page.
This should be the default action for the Save button: the user should be able to decide by themselves if they want to see the front-end of the node or to go to the list of content. And the same should happen for Taxonomies and other entities. We should decouple the action for Saving, the action for Publishing and the action for Redirecting. In here, I would focus on decoupling the Save from the redirect itself.
jjchinquist → credited ckrina → .
pameeela → credited ckrina → .
pameeela → credited ckrina → .
Applied the small changes myself.
2 small design change requests and this is good to go.
jjchinquist → credited ckrina → .
We just defined an strategy to keep titles for the menus and avoid the problems with cache.
Huge +1. Beyond other qualities, his willingness to coordinate with others make him a great maintainer.
Huge +1 to this. His enthusiasm and smart calls make him key for this role.
pameeela → credited ckrina → .
ckrina → changed the visibility of the branch 3424744-on-collapsed-sidebars-off-11.x to hidden.
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 :)
Follow-up ✨ Implement a feature similar to the "Go Back" / escapeAdmin.js Postponed .
Moving to Postponed until we've define how this feature needs to work.
Huge +1 to this. We need to make life easier to FEDs and provide good defaults for the rest.
Thanks for fixing this so quick. Committed ecf4b20 and pushed to 10.3.x. Thanks!
Would it be possible to clean-up&minimize the SVG itself too through a tool like https://jakearchibald.github.io/svgomg/? Sorry I didn't see it sooner :)
ckrina → changed the visibility of the branch 3438046-2nd-level-active to hidden.
Sorry, small detail! The icon megaphone should be pointing to the other direction, so moving this again to Needs work:
Wrong:
It should actually be:
Re to #15 and #16:
We're using a variable font: it means that all weights are built in one file, so it really doesn't matter if we use 1 weight or 4. That's the magic behind variable fonts and why we decided using them. A variable font size might be twice a regular font, but you get way more :)
So there is no need for any redesign/design exploration. But thanks @jponch for being open to it!
However, I have no idea how to split a font by language/glyphs
There are several tools out there. @finnsky 's links have a few of them. But the question still is which languages.
About other languages, then it defaults to the system's font. I've tried it with Arabic and Japanese.