[meta] UX refresh

Getting closer to Core's HTMX and simplifying oru logic? Sounds exciting.

Is it related to or overlapping with those existing ticket: #3536288: HTMX array rationalization & #3568143: Refactor and check our HTMX calls ?

Hello Jean,

I will wait the issue to be in "Needs review" before a proper review, but the work you are doing here is exciting and here are my first feedback.

It seems the branch is getting ambitious and mixing 3 kinds of work:

UX refactor

More or less the established scope of the ticket:

Current UX, css, js and HTMX implementation is old and rely on HTMX before it was in core.
We have now helper class and better routing for HTMX, like _wrapper_format=drupal_htmx/

In the meantime we can refactor the js logic, make it more simple and merge the HTMX commands.

"we can refactor the js logic, make it more simple" sharing common means and goals with #3563943: UI toolbar sticky and right drawer

With those works already pushed in branch:

• sidebars harmonization: looks great
• library_tabs_icon & contextual_tabs_icon: looks great, but maybe an enum instead of a boolean? so we can have "icon only", "icon & label", "label only" like in other parts the UI. Maybe a shared PPH Enum would help.
• Changes in highlight.js : Which is a first, temporary, step toward #3573538: Make some islands parts sensitive to current tab

In #3563943: UI toolbar sticky and right drawer, you also proposed "Toolbar should always be sticky at the top (This allow full view on all buttons) A bit like fullscreen": is it still a goal?

I don' see anything related to HTMX simplification in the branch yet, it was the main goal of the ticket. Is it still planned or will it be addressed in #3536288: HTMX array rationalization & #3568143: Refactor and check our HTMX calls ?

A big part of the UX decisions will reside in the default profile default configuration, because the first impression is the most important and because most of the users will stick with the default. We can ask an UX designer later to build this config, because we are all too deeply into the product to think like a "normal" user.

Brand new features

It is cool to propose so much new ideas, but some may deserve their own tickets to allow us to discuss them in the best conditions.

Some are pretty straightforward:

• flat in Components & Blocks list: great idea. Instead of an option alongside grouped, variant & mosaic, would it better to make it orthogonal with the combination of 2 options [default, variant, mosaic] & [flat, grouped]? i am not sure, just saying...
• library_flat profile setting: I see how practical it can be for people like us, power users, maintainers of the project, but I am afraid it will be confusing for users. Yesterday, you told me it is to reduce the confusion between Components VS Blocks, but this split is important (what comes from Design VS what come from CMS) and must remains. We can discuss a better wording here: #3569409: Improve UX by restructuring "Libraries" and "Blocks" island. Also, I am afraid the mechanism is a bit hacky and will be tricky to maintain.
• menu_styles Island: cool idea

However, some of them are adding a lot of javascript code in a project phase when it would be better to target a drastic reduction of the front-end complexity:

• ui_controls Island with zoom.js new file (151 LOC):  maybe we can move it to server side logic, with a setting in Profile entity or, better, follow the new settings in Drupal 11.4 admin theme (when available):
• form_reset.js new file (92 LOC). Would it be possible to use HTML directly https://www.w3.org/TR/2011/WD-html-markup-20110113/button.reset.html ?

UI changes

This was not expected in a ticket about UX, and I guess your proposal will keep evolving until the ticket will be available for review.

But let's remember than looking "Drupal native" is a big part of the trust and the comfort users will experience when using Display Builder. They need to feel at home, they need to not get the feeling they are opening a distinct, alien, app.

The less custom JS and CSS we have, the less in-house design we add, the better ;) Let's consume the already available design by mapping the Drupal CSS variables to the Shoelace ones like:

--sl-font-sans: var(--admin-toolbar-font-family);

#3529095: Adopt navigation module's top bar and #3562060: Render UI with admin theme are also going in this direction by moving design decision and implementation out of our scope, so we can keep our mind free and our front-end code light.

This topic deserves its own ticket, doesn't it?

Tested with a fresh install:

• Drupal 11.4
• Front theme: UI Suite DaisyUI
• Admin theme: Default Admin with Navigation module activated
• Browser: Firefox on Fedora

UX work

✅ New "Floating control" island type with "Highlight" and "Viewport"

It will solve #3573538: Make some islands parts sensitive to current tab in a powerful, clean and future proof way 👍

Thanks for the documentation update. It would be great to also update islands-regions.png shown in profiles config page. I can help.

⚠️ However, even with a fresh install, I got those islands only after I saved the config entity from admin UI. So, they were activated by default but not really.

✅ UI toolbar sticky and right drawer

The scope of #3563943: UI toolbar sticky and right drawer:

• Toolbar should always be sticky at the top
• Drawers must always have a padding to be behind toolbar (like in fullscreen)
• Second drawer (right) should displace like left one

Very cool. I like the fact the title is not shown in the first drawer because of the proximity of the button 👍

⚠️ i just have a little visual quirk when i drag, my handler is not at the excepted position:

✅ Tabs icons for Library and Contextual

It looks great. However, I will not die on this hill but:

• ⚠️ I believe "label" must stay the default because it is self descriptive, so more welcoming the first time users which care about usability more than space saving. "Try to avoid designing icon-alone tabs since only a small number of icons have universal meaning."
• ⚠️ You already explained to me why it is a boolean instead of {"icon only", "icon & label", "label only"} PHP Enum shared with the buttons island configuration: to save space. But I am still afraid it is a missed opportunity to make this future proof (and, again, not everybody will focus on space saving)

✅ Styles menu island

A great opt-in power feature 👍

✅ "flat list" display in components library and blocks library

Great addition 👍

❌ Flatten library panels

A great idea but I still believe the implementation is too hacky and the results weird, for example:

• when block and component libraries have different settings (grouped VS flat, mosaic VS grouped...)
• the empty preset library is visually messy:
  

And I guess this is the reason the configuration is marked as experimental in profile config page. Anyway, it will cause confusion and may be a burden to maintain. So I would advise to remove it from the scope to take the time to properly implement this later.

✅ Preview on hover disabled by default

OK, I don't have strong opinion and I don't see what was wrong with those previews but it is great to have such a setting so why not?

UI work

The changes altering the UI (color, spacing, sizing, borders...) instead of the UX (controls, layout, usability...). Most of them are sharing the goal of reducing of making the UI more compact.

❌ "UI controls" button

By default, with this MR, there are already 17 font sizes (not counting the front theme):

It is already a lot and it would be better to reduce their inconsistencies:

However, even if technically no sizes are added (because we use CSS zoom), this feature visually adds new font sizes and makes a weird impression.

Moreover, this feature is:

• making the UX busy with 2 new buttons in the toolbar
• overlapping with the native browser zoom feature, which may be confusing
• adding complexity to maintain (an island PHP plugin, a big JS file)
• is causing a bug with the toolbar hovering the panel instead of pushing it (it is OK on default zoom level):

❌ "Density" floating control

Similar issue as previous:

• add unexpected font sizes
• making the UX busy with 2 new buttons in the floating controls
• overlapping with the native browser zoom feature, which may be confusing
• adding complexity to maintain (an island PHP plugin, a big JS file)

✅ Libraries draggables as labels

It is OK to replace the mini draggable cards by simple labels in the libraries panel, but:

• Text alignment is weird label shifts to right on hover and vertical spacing is too even:
  
• ⚠️it would better to sort the list naturally instead of putting parenthesis before
  

  (Avatar group)
  (Table Cell)
  (Table Row)
  (Timeline item)
  Accordion
  Avatar

• ⚠️ it looks a bit weird when we drop a source in Layers:
  

❌ Form spacing

To save space, I guess, some margin & padding have been removed and the forms now look uneven:

As previously stated, looking "Drupal native" is a big part of the trust and the comfort users will experience when using Display Builder. They need to feel at home, they need to not get the feeling they are opening a distinct, alien, app.

Forms UI is a big part of this. The less custom JS and CSS we have, the less in-house design we add, the better ;)

Conclusion

I believe we can merge soon (late beta6 or early beta7) the following features (after addressing/discussing the feedback):

• ⚠️New "Floating control" island type with "Highlight" and "Viewport"
• ⚠️UI toolbar sticky and right drawer
• ⚠️ Tabs icons
• ✅ Styles menu Island
• ✅ flat list" display in components library and blocks library
• ✅ Preview on hover disabled by default
• ⚠️ Libraries draggables as labels

And I propose to move the other proposals to follow-up tickets:

• ❌ Experimental flatten library panels
• ❌ "UI controls" button
• ❌ "Density" floating control
• ❌ Form spacing

I am discovering 11 new commits since the ticket has been assigned to me for review. Do I need to review again?

Why did you remove LayoutBuilderConfigMigrationTest, LayoutBuilderOverrideMigrationTest and DisplayBuilderSubscriberTest::testOnRevertNonOverrideInstanceIsNoop()? It seems risky and unrelated to the scope of this issue.

Reuploading the screenshots of comment #12 which have mysteriously disappeared

And reuplaoding the screncast

For now functional test is failing and I didn't have time to lookt at it, will require it's own issue.

If those specific tests are now failing because of changes which loos unrelated, it may be worth to investigate before merging, it may told us something important about the proposal.

Also, the .db-node-contextual-open:not([data-slot-id]) style (purple dotted border) is now sometimes applied on contextual menu:

Thanks for the impressive work. A lot of UX improvements bringing value to the project:

• Toolbar position at the top
• Unified sidebars behaviors
• New Floating buttons island type
• HTMX "defer" behaviour
• SortabeJS fix
• ...

We are getting very close to land this.

Blocking

Default profile

It is not only my humble opinion, but also conclusions from the UX audit made by Smile late 2025:

• "Clear logs" button is now activated by default, which is considered a bad practice because it is a definitive, not revertable, action with data deletion put aside the buttons where users are enjoying this data. A misclick of someone wanting to redo but losing the logs instead will be a disappointment. It must be reserved to power users, so not activated by default.
• "State" buttons are now positioned at the end of the toolbar, because they appear and disappear according to the current state (published/not published), they frequently push the other buttons left and right, adding confusion (and they also increase the risk of mis-clicking the "Clear logs" button)

Broken/Disappeared layers panel

After update, I get PluginException: Plugin (layers) instance class "LayersPanel" does not exist. it disappeared after a cache rebuild but Layer panel is now missing from the profiles without being replaced by Scaffold.

The solution may be easy: ScaffoldPanel is not a new panel but a better LayersPanel with new features and look.
We already have some rewording while keeping existing plugin ID and classes

• builder / BuilderPanel / Canvas
• tree / TreePanel / Navigator
• ...

So, we can have layers / LayersPanel / Scaffold.

Not blocking

If you can fix this in the MR, it is great. If not, we will do follow-up tickets.

Highlight floating button

Components and Blocks do nothing on  Layers. I guess it make sense but it looks like a bug.

To be discussed in follow-ups tickets

Wording/Renaming

• "Builder" > "Canvas": it is a relevant name, found in many tools users can be familiar with, but it may be confusing in the Drupal world
• "Layers" > "Scaffold": ✅
• "Tree" > "Navigator": ✅
• "Viewport" > "Responsive width": OK as a temporary name until #3542003: Responsive viewports with iframes is fixed
• "Contextual form" > "Config": "Contextual form" was not good, but maybe "Config" is a bit too generic.
• They are others?

We will also need to talk about how to conciliate plugins ID, PHP classes and labels. #3615493: Renaming cleanup

UX

• It is good to have an unified behavior for both sidebars, but is pushing the content always the best behavior? Just asking...
• It is great to have Builder and Preview with the page around as context, but not necessary for Scaffold

UI

Some change feels a bit off sometimes, tiny things here and there (color, typography, sizing, spacing, alignments...) giving an overall impression. But I know this ticket is not about UI but UX, so let's discuss this in August.

Also, as you proposed, let's challenge Shoelace.

Default profile

Some unexpected changes:

• Logs panel not activated anymore by default. Let's discuss again later.
• VisibilityPanel is activated by default. Is it not a advanced feature?
• system_breadcrumb_block has been hidden. This block is expected to be available out-of-the-box at least in a PageLayout context. #3615464: Allow system_breadcrumb_block by default

New "TextArea" source

OK as a workaround until Core fix the HTMX situation with WYSIWYG. How can we avoid hardcoding the call to a specific text format (which may not fit or be deleted)?

New "Save status" island

The idea is great, but it is only a start and the execution needs work.

Flatten library settings

Still looks a bit weird when:

• block and component libraries have different settings (grouped VS flat, mosaic VS grouped...)
• the preset library is empty

Under the hood

• Icon / Label / Icon & Label may be an PHP Enum
• ApiContextualMenuController : it would be better to not have controllers dedicated to specific islands and/or specific third party settings
• "flat library" settings may be better located in the LibraryPanel plugin instead of the Profile config entity. See #3542866: Move some logic from DisplayBuilderViewBuilder::buildSlots() to LibrariesPanel::build()
• HtmxEvent::onClickDelete() has been changed from HTTP DELETE to HTTP POST

docs/islands.md is still mentioning Density floating control.

The state of the MR at commit 6f7a8621f0067e7c25471b6a4644375d397e35ae is OK for RTBC.

Congratulations for the impressive work