Experience Builder

With DrupalCon Barcelona 2024 only two weeks later, the focus this week is on tying up loose ends. That already started last week, but of the milestone 0.1.0 priorities that product lead Lauri “lauriii” Timmanee identified, 15 are still left after last week: we need to fix 1.5/day to get to zero.

Major loose ends

I titled last week’s update drag and drop party because there were so many improvements on that front. But one critical piece was still missing: it was painful to drag components into locations that are difficult to visualize: top and bottom of slots, even more so for adjacent slots. Bálint “balintbrews” Kléri brought one additional improvement:

We matched last week’s record: again 26 MRs merged! 🚀

Experience Builder (XB) already had a hierarchy view for a while. Lauri “lauriii” Timmanee worked with the Acquia UX team to change that to match the more common “layers” pattern (used in Photoshop and Figma). Harumi “hooroomoo” Jang made that a reality:

A new record week: 26 MRs merged! :D Too much to cover, so going forward, I will only write about the most notable changes.

The simplified zoom interface landed thanks to Jesse “jessebaker” Baker and Gaurav “gauravvvv” — with not only better controls, but also a much smoother UX:

Bálint “balintbrews” Kléri, Jesse and Ben “bnjmnm” Mullins integrated the existing “undo” functionality with the component props form, resulting in the UX you’d hope:

Monday August 19, 2024 definitely was a milestone:

How does cta1href sound to you? Gibberish, right? :D
Jesse “jessebaker” Baker pointed out that Experience Builder (XB) in its current state was subjecting its users to such nonsense! Fortunately, thanks to every Single Directory Component (SDC) specifying a title for each prop, we were able to automatically generate the much more readable CTA 1 link — thanks to foundations Ben “bnjmnm” Mullins did in #3461422 from 3 weeks prior.

Utkarsh “utkarsh_33” and Omkar “omkar-pd” Deshpande eliminated an extraneous “preview” request from the client, hence improving performance (as well as sanity).

The first prominent leap forward this week was built by Harumi “hooroomoo” Jang: they added the ability to Experience Builder (XB) to first pick the location to add a component to, and then pick the component, rather than only the other way around:

Clearly, it’s important to support both paths towards placing a component!

The back-end heart of Experience Builder (XB) is its two-property field type. Thanks to Ted “tedbow” Bowman, the tree field property is now strictly validated, which is essential to ensure both data integrity and the ability to evolve the codebase rapidly and confidently. Crucially, this validation constraint is used to validate both content and configuration, just like the validation that was added in week 10.

This week started with undoing the horrors that y’all were subjected to last week: TwoTerribleTextAreasWidget featured prominently. The follow-up that I mentioned landed (Ben “bnjmnm” Mullins and I collaborated on it), which with a +110,-245 diff resulted in something that still is nowhere near a final UX, but is starting to look reasonable.

The Cypress front-end testing infrastructure clean-up landed on Monday, so this week we’ve already been seeing increased velocity! Last week, we landed the initial implementation of the primary menu, this week it was improved by Harumi “hooroomoo” Jang:

Experience Builder (XB) allows crafting an experience using components. A tree of components. Except that until now, the XB field type does not yet support storing a tree — we had to start somewhere! Ted “tedbow” Bowman landed #3455728: FieldType: Support storing component trees instead of lists. Next up on this front: before we start actually storing trees, we need thorough validation — Ted’s tackling that next. This will allow us to confidently store trees of components (by putting components in other components’ slots), and then finally put to good use the oldest MR the XB project currently has: Kyle “ctrlADel” Einecker’s MR that adds representative set of Single-Directory Components.