Account created on 20 December 2010, over 13 years ago
  • Staff Software Engineer in the Drupal Acceleration Team at Acquiaย  โ€ฆ

Merge Requests


Recent comments

๐Ÿ‡ซ๐Ÿ‡ฎFinland lauriii Finland

lauriii โ†’ created an issue.

๐Ÿ‡ซ๐Ÿ‡ฎFinland lauriii Finland

The default components & categorization (tree testing) is now at final stages of planning and the research will start next week. Planning on UX for developer created components is starting now.

๐Ÿ‡ซ๐Ÿ‡ฎFinland lauriii Finland

We are planning to launch a research utilizing unmoderated interviews + tree testing next Monday.


  1. Define what building blocks are most important to the potential users of the Experience Builder (XB).
  2. Define the ideal menu IA for users to efficiently navigate the tool.
  3. Understand the limits designs systems are pushed to out in the marketplace and the ideal arrangement for users. (prioritizing mid-market level users, including enterprise data to keep designs scalable for their needs as well.


We can target the following groups on PlaybookUX:


  1. Designers (Maggie & Amir)
  2. Front-end developers (Clare & Keith)

Target Markets

  1. Education/schools & Volunteer orgs (primary)
  2. Mid-market agencies (primary)
  3. Enterprise users
๐Ÿ‡ซ๐Ÿ‡ฎFinland lauriii Finland

Thank you for the prompt responses @guptahemant and @Kristen Pol! It's amazing to see the enthusiasm that both of you have towards contributing to the Experience Builder!

I've reviewed both of the proposals and I believe both of the teams would be well equipped to succeed at this. This makes it really challenging to make a decision between the proposals. Ideally, there's opportunities for both organizations to contribute to the project.

I really like that @Kristen Pol has given a lot of thought for how they could run the project as a community initiative. This is why I'd like @Kristen Pol and the Salsa Digital team to lead this project.

I'm confident that this will give opportunities for @guptahemant and QED42 to participate as well, once the Salsa Digital team has been able to set up some basic structure for the project. Alternatively, there's #3454525: [META] Track 1: Update for Drupal Starshot โ†’ as well as work to implement these designs for which I believe the DA could use help with. In case that this is something you're interested in you should reach out to @hestenet.

We are curious what type of real-time coordination you would like to engage in, so we can better plan and support your contributors in European time zones.

I'm anticipating that there might be some blockers in SDC or Experience Builder that make it hard for the team to progress beyond a certain point without support from the core XB team. If the different teams have timezone overlap, it helps resolve these blockers more real-time, making the overall process more efficient.

๐Ÿ‡ซ๐Ÿ‡ฎFinland lauriii Finland

I'm working with a UX designers and a researcher to define this. We have formed a hypothesis and we're planning to start testing on Monday.

๐Ÿ‡ซ๐Ÿ‡ฎFinland lauriii Finland

Yes, the meta fields is supposed to be referring to fields with no visual representation. We'll need to define how the form is structured and what is the UX for configuring it.

This is assigned to me because I'm working with Acquia UX to define the intended user experience.

๐Ÿ‡ซ๐Ÿ‡ฎFinland lauriii Finland

Reporting another potentially related issue here. Feel free to move to its own issue if it turns out it isn't related.

I have a clean installation of XB with Standard. When I go to /admin/structure/component/add, there's a lot of options presented even before selecting a component. It also looks like that these form options are displayed several times on the same page.

๐Ÿ‡ซ๐Ÿ‡ฎFinland lauriii Finland

Yes, the whole menu should close on drag.

๐Ÿ‡ซ๐Ÿ‡ฎFinland lauriii Finland

Discussed this with @Renee Lund, the UX designer from Acquia UX working on this.

We haven't done research with users on this, so this is based on our hypothesis which is informed by competitive analysis. We would be doing UX testing later which may result in us needing to revisit decisions like this.

There are two possible user flows:

Flow 1:

  1. Add component/element to the page
  2. Modify component/element contents/props
  3. Add another component/element

Flow 2:

  1. Add component/element to the page
  2. Add another component/element
  3. Modify component/element contents/props for component 1
  4. Modify component/element contents/props for component 2

Our hypothesis is that the XB users would be following the flow 1 most of the time, and the UI is currently designed for that. This also seems to be the pattern that majority of different platforms are taking. If we find out that flow 2 is the more common scenario, we'd have to design for that and that may have implications to the design outside of this issue.

๐Ÿ‡ซ๐Ÿ‡ฎFinland lauriii Finland

Thank you @Kristen Pol and @guptahemant! I have following questions before making a decision who leads this track:

  1. When do you expect to start and finish the project (rough timeline)?
  2. Are you open to collaborating with outside contributors or would you prefer to run this internally within your organization? If you are open to collaborating with outside contributors, how would you prefer to engage with outside contributors?
  3. Does your team have prior experience working with SDC?
  4. How much timezone overlap does your team have with CET office hours (9.00-17.00)?

I'm planning to make a decision on 10.6. Let me know if you need more time to answer to these questions. ๐Ÿ˜Š

๐Ÿ‡ซ๐Ÿ‡ฎFinland lauriii Finland

This was improved in subsequent commits. There's now ๐Ÿ› Middle click + drag doesn't work correctly if middle click is inside preview iframe Active to address some specific remaining concerns. Closing this as outdated.

๐Ÿ‡ซ๐Ÿ‡ฎFinland lauriii Finland
๐Ÿ‡ซ๐Ÿ‡ฎFinland lauriii Finland

lauriii โ†’ created an issue.

๐Ÿ‡ซ๐Ÿ‡ฎFinland lauriii Finland

@jessebaker Which of these options would you recommend?

๐Ÿ‡ซ๐Ÿ‡ฎFinland lauriii Finland

This isn't the exact interaction I was thinking for the sidebar. The interaction pattern I was thinking was that we close the component menu after component has been added. This is what Figma and most page builders are doing today. This is because the most likely task after dragging the component in would be for the user to fill in content, and to adjust the styles.

๐Ÿ‡ซ๐Ÿ‡ฎFinland lauriii Finland

Attaching designs for this.

๐Ÿ‡ซ๐Ÿ‡ฎFinland lauriii Finland

I can't reproduce this with the latest HEAD. Closing for now.

๐Ÿ‡ซ๐Ÿ‡ฎFinland lauriii Finland

lauriii โ†’ created an issue.

๐Ÿ‡ซ๐Ÿ‡ฎFinland lauriii Finland

Thanks for the MR! It looks like the MR is modifying the Same Page Preview module which probably shouldn't even be in the code base anymore. For clarity, we need the translation capability for the experience_builder/ui directory.

๐Ÿ‡ซ๐Ÿ‡ฎFinland lauriii Finland

Added following issues to the roadmap:

  1. โœจ Create UI scaffolding for the primary panel (left sidebar) Needs work
  2. ๐Ÿ“Œ Add support for UI translations Needs review
  3. ๐Ÿ“Œ Media Library integration Active
๐Ÿ‡ซ๐Ÿ‡ฎFinland lauriii Finland

Unassigning for now. Feel free to pick this up in case anyone is interested in helping with adding support for PostgreSQL and SQLite.

๐Ÿ‡ซ๐Ÿ‡ฎFinland lauriii Finland

@larowlan could we merge this and open a follow-up for the feedback? @tedbow is currently on PTO and it would be great to merge this if we think it's close enough ๐Ÿ˜‡

๐Ÿ‡ซ๐Ÿ‡ฎFinland lauriii Finland

Thank you @larowlan! Pinged @jessebaker to watch the video.

Moving to needs work since the in-place editing needs work still.

๐Ÿ‡ซ๐Ÿ‡ฎFinland lauriii Finland

Assigning back to @tedbow to address feedback.

๐Ÿ‡ซ๐Ÿ‡ฎFinland lauriii Finland

lauriii โ†’ created an issue.

๐Ÿ‡ซ๐Ÿ‡ฎFinland lauriii Finland

I'm adding an early version of the wireframes to bring more clarity on what is the direction in terms of UI design. There's no need to implement this pixel perfect, or try to derive capabilities from it. It's a mid-fi wireframe that is showcasing many future possibilities and making sure that the UI can sufficiently accommodate those.

๐Ÿ‡ซ๐Ÿ‡ฎFinland lauriii Finland

I've discussed the idea with @daffie and @catch in detail at DrupalCon Lille and Drupal Dev Days and on a high level the proposal is fine. Adding a new database driver is not part of the strategic focus for the team at the moment, which may lead into some delays with reviews in cases where there's higher priority work waiting for feedback from committers.

I'm leaving the tag on because I'd like to be involved in the process again when we have a better sense on what's the impact on UX (such as Views) and the ecosystem.

๐Ÿ‡ซ๐Ÿ‡ฎFinland lauriii Finland

Finally had a chance to review #28. The Figma file makes it really easy to see what the proposed design system would be which is great. It looks like there's quite a few changes proposed, and I'm not really sure I agree with the general direction. The goal is to showcase the new Drupal branding which can be found in The changes make the design look too generic. There's probably some feedback that should be addressed but we need to find a way to balance that better in order to remain original to the brand. I discussed this with @pixelite from Promote Drupal and at least on a high level, she agreed with that.

It looks like the design in #32 is much closer to the original designs. Is there a Storybook page or some other way to see how the design system is built?

๐Ÿ‡ซ๐Ÿ‡ฎFinland lauriii Finland

Elements are low level components that are agnostic to design; e.g. paragraph, container, image, columns, and so on. These are the building blocks for building no-code components. Given that these are design system agnostic, they would be like shipped by modules.

๐Ÿ‡ซ๐Ÿ‡ฎFinland lauriii Finland

Re #16 I'm wondering if we are overestimating the complexity involved with components in relation to modules. Components (at least ones used via XB, with the exception of elements) would generally not be shipped by modules. This is because components must include both markup and CSS because they are self-contained. For this reason, components are usually specific to a design system, and therefore not shipped by modules.

I agree that using categories and tags comes with some downsides because you lose some control. Maintaining components one by one for every slot that exists in the system just sounds like a terrible experience. You could still do it if you want to, but you would not be forced to do it.

The only way I see out of this is to auto-create this "Component" (name TBD) config entity for each discovered SDC, so that the Site Builder doesn't have to do anything to allow advanced Content Creators to use arbitrary components.

But this would still violate the single directory principle. If we break that principle, it makes it harder to maintain components as well as to share them between sites. Ideally we could do something like with SDCs. Requiring additional steps besides copy pasting the directory adds friction to this process.

๐Ÿ‡ซ๐Ÿ‡ฎFinland lauriii Finland

#15: I'm pretty sure that it would be both easier and would make more sense from UX perspective to use fields default value. The fields default value is specific to the current context, meaning that it could have a value that is more specific than what the component has. The components prop would have a PropExpression as a value so at least in my mental model it should just render the default value from the field that is powering it. I'd imagine in this scenario that if there's no default value for the field, that the default value for the prop would not take effect, because otherwise you run into challenges in the scenarios where you want to be able to leave the value empty.

If we were to do wise versa, we would somehow have to bubble up the default value from the component prop to the field. That seems pretty unexpected consequence to me.

This is all just my hypothesis, we'd definitely do user testing on this later once we have a version of this implemented.

๐Ÿ‡ซ๐Ÿ‡ฎFinland lauriii Finland

#13: I'd expect it to be the former.

๐Ÿ‡ซ๐Ÿ‡ฎFinland lauriii Finland

#14 I'd imagine the component becomes unavailable to be added to new content. Existing content remains functional both for display and editing, but after deleting the component, it would not be possible to add it back (other than maybe CTRL+Z while still editing the page).

๐Ÿ‡ซ๐Ÿ‡ฎFinland lauriii Finland

In the video, there's a component in a slot which uses an entity reference. Is this:

1. An entity reference + view mode selection - with the specific layout/component coming from the view mode.

2. An entity reference which is then manually mapped to props on a component selected by the content editor?

And regardless of the answer to #1 or #2, is the intention to support both?

The example of content composition I showed, I'd imagine falling under #1. However, we're aiming XB to support both of these.

With default components in templates (the image in a slot), is the default value always stored with the entity? i.e. if the default was changed from an image to video later, I am assuming that all the existing content that did not customize the slot would still have the image, because it's a default value which then gets saved when the entity is saved. Not sure that's 100% correct interpretation though.

The default value is stored with the entity, so if the default was changed later, it would remain intact on existing content.

๐Ÿ‡ซ๐Ÿ‡ฎFinland lauriii Finland

The current approach for the config entities goes somewhat against the SDC principle which is that everything related to the component should be in a single directory. This way you can move the SDC from a system to another, without having to chase down for additional files outside the SDC. Also, as a frontend developer you know that if you need to make changes to a component, you can always find the underlying code in that directory. It might not be possible to have everything in the *.component.yml, but having a *.experience_builder.yml file there would still be better than storing it in config outside the component.

What comes to opting-in components, I agree with the general sentiment from @larowlan and @catch that there needs to be a way to curate the components exposed to the page builder. What I'm not convinced is that we should require opt-in on component by component basis. I believe an ideal experience would be something in between a fire-hose and opting in on component by component based. In my mind, that ideal DX would allow exposing components directly from code, without requiring a step in the UI. I believe we should try to enable this while avoiding the fire-hose problem.

So what if we introduce a concept of categories and tags? This way builder could select either specific components, tags or categories that they want to expose for the content creators. We probably need the concept of categories anyway, in order to group components in the UI.

By default there would be one category for elements. Rest of the components would be listed as untagged components. Ideally components themselves could specify their category; for no-code components this is in the UI and for code components this is in code. This way sites can choose what is the level on which they want to decide which components can be used by content creators, and you could get rid of the additional step.

This approach does not have to be specific to choosing which components to allow in the page builder. Individual components need to be able to specify restricted slots too, where they define which components are allowed for that slot. The restricted slots may also want to be able to use tags and/or categories for defining the allowed components. This way the slots become more flexible, because for example in the case that a design system has multiple CTA components, you could allow all different CTA components to be used in a certain slot without having to specify them one by one.

I proposed this (without as much detail) in ๐Ÿ“Œ Clarify "components" vs "elements" vs "patterns" Active and @Wim Leers posted some concerns:

The only way around it I see is generating such a config entity automatically for every discovered SDC

I'm curious why we'd require a config entity per SDC? I understand that no-code components require a config entity, but why code components require that too?

A) accept that every SDC ends up in an "untagged" bucket by default and hence we can overwhelm content creators, and allow specifying a tag after the fact

The untagged bucket might be displayed by default, but most sites would end up disabling it after they've decided how they'd like to restrict components that are available in the page builder.

B) accept that some SDCs may fail to generate a reasonable preview and can hence confuse content creators, and allow specifying a default value after the fact

We can probably accept the lack of default values especially given that we can control the starting point ourselves. We can also either come up with ways to generate the default values ourself (i.e. static default values), or by defining some ways to nudge component authors to define them e.g. within development tooling.

C) accept the field type + widget suggested by #3452497: [MR Only] Edit any component prop, powered by a new FieldForComponentSuggester service, which will power the JS UI as the default, and allow editing after the fact

I'm not entirely convinced that requiring manual widget selection makes sense for components. Maybe there should be a way to manually override the widget when the one automatically selected doesn't make sense, but I'd imagine this is something that we can automate to large extent for components by setting sensible defaults.

๐Ÿ‡ซ๐Ÿ‡ฎFinland lauriii Finland

I recorded a video with my thinking around this, approaching it from a slightly different angle: I'm walking through two diagrams on that video; one for data sources + design system and one for breaking down a content type.

On the note of CC freedom, I think one thing that would be ideal (and I'm pretty sure is covered but there is a bit of nuance) is having the ability to be able to configure the amount of freedom per region per layout per bundle. As in at level in bold, as a site builder, I want to be able to configure the "freedom" of the CC.

If I understand this correctly, instead of configuring which components are available for a bundle, you'd like to configure slot restrictions for a specific component within a specific bundle. Do you have specific example scenarios where this is needed that you could walk us through?

๐Ÿ‡ซ๐Ÿ‡ฎFinland lauriii Finland

Thank you for posting the manual steps to reproduce this! A test case that consistently reproduces this would be really helpful as a potential next step.

๐Ÿ‡ซ๐Ÿ‡ฎFinland lauriii Finland

I'd be interested to understand more about the motivation here. Field formatters as we know them in Drupal(ones that output html) go against the concept of components only being passed structured values that they then place in their html.

I'm on the same page with you โ€“ conceptually they don't make a lot of sense in a component based system. The reason we'd be bringing in the field blocks is because it helps us avoid having to move all existing formatters to components. This is critical especially for sites using LB currently.

This warrants more discussion. IMO components composed of other components should definitely be able to compose their forms by passing thru props and customizing what props are available on the authoring form otherwise we end up in the same situation various Drupal approaches and Acquia Site Studio have where every usage of a component in another component requires redefining fields on the parent form so they can be mapped from the parent to the child.

I was referring to something else in my comment. I was mainly trying to explain the key characteristic of a component which is that you can only interact with it through props and slots, unlike with patterns where you can actually start changing the internals of the pattern once you've placed it. I agree we should try to design the system so that we can avoid this problem.

I've seen 3 main types of components that authors want to place

I agree with the 3 main types of components you listed here. I'm referring to the reusable components as "Global blocks" in this content type breakdown. It's definitely not the best term. ๐Ÿ˜…

not a huge fan of the patterns name btw

Me neither! I think our design team is calling them just "sections" right now since that seems to be a term that is used broadly within the industry. That's a little unfortunate given that Layout Builder is using that term for something slightly different.

๐Ÿ‡ซ๐Ÿ‡ฎFinland lauriii Finland

What if there's a prop that you don't want content creators to be able to modify?

I would imagine in that scenario you would wrap the component with another component which sets a static value for the prop, and exposes rest of the props for the content creators. Then they would choose to only expose the wrapper component for the content creators.

If this config entity is something you disagree with, we urgently need more clarity on the product requirements, because I currently don't see any other way to meet the requirements โ€” it seems that there's a conflict then.

Should we move the discussion to ๐ŸŒฑ [META] Configuration management: define needed config entity types Active or maybe even open a dedicated issue for this? I'd be happy to open that if you think it's a good idea.

๐Ÿ‡ซ๐Ÿ‡ฎFinland lauriii Finland

Updating the title to make documentation the ultimate goal.

๐Ÿ‡ซ๐Ÿ‡ฎFinland lauriii Finland

Thank you @ctrlADel! I updated the issue summary to be a bit more authoritative because the current drawing would serve at least as a really good starting point. We may consider adding more cases if we discover more later, but we could already use this as the basis of validating decisions we're making. Ultimately, it's likely that we'd like all of these ways to combine components to exist in Experience Builder at least eventually. We may not have all of them in the beginning, but we should at least keep them in mind.

๐Ÿ‡ซ๐Ÿ‡ฎFinland lauriii Finland

I've always viewed elements as a type of component. The reason they must be separate from components is because most of the time, you'd want your content creators using components instead of elements. When that's the case, it needs to be possible to disable elements from the page builder.

I created a Figma design to show case the different concepts and their relationship:


these are โ€œopted inโ€ from the list of installed SDCs using a config entity

Especially for elements, it seems that this is something you'd probably control in code instead of UI. It doesn't seem necessary to be able to control the available elements on a site level. It could be that elements is just one category.

THIS is where โ€œlockingโ€ starts to become relevant, not in โ€œelementsโ€

I'm not sure what are you referring to by locking in this context? The internals of the component should not be editable when the component is being used. When the component is being used, it's only possible to modify props of the component, and insert components to the slots of the component. There could be a way to set up a component with a slot that has a default value, which allows editing the contents of the slot.

these MUST have a default value for each prop to ensure they always have a visual representation

This is the current hypothesis for ideal UX. This is something we need to work to confirm with UX.

1 pattern = 1 or more elements, similar to 1 component, but then in the Page Builder territory, and each time a pattern is used, itโ€™s โ€œcopy by valueโ€ instead of โ€œcopy by referenceโ€ โ€” meaning changing the pattern wonโ€™t update it everywhere.

This is somewhat correct. They are indeed โ€œcopy by valueโ€ instead of โ€œcopy by referenceโ€ . However, patterns would be created using the same building blocks that are available for the content creator. This means that if elements are not available for content creator, then patterns that may only use components too. These are usually created to define pre-configured configurations of the components that look good. For example, you could have a pattern that adds 3 card components side by side, because having one card component on its own doesn't look great.

I actually cannot find anything in the Requirents spreadsheet nor past discussions about โ€œcomponent variantsโ€

I'll craft a user story to the requirements spreadsheet. I could also file an issue with some more information.

In our past discussions, we said that field formatters must be available early. If so, we must be able to express them. If so, exposing them as field blocks probably makes sense? Itโ€™d make the upgrade path easy too. OTOH, doesnโ€™t that inherit all scalability problems? We could also make field formatters a distinct โ€œcomponent typeโ€ or โ€œrenderableโ€

The discussion so far has been that we'd expose fields through a single field block. This avoids the problem of creating a ton of derivatives. It's probably possible to convert the existing uses to something like that without too much disruption. I did a PoC on that last fall: #3365551-18: Add the notion of a 'configured layout builder block' to solve a number of content-editor and performance pain points โ†’ .

Can you confirm the misnaming of the already-committed config entity?

To me, it still seems like we shouldn't have a config entity per component. I personally think that the ideal DX would allow exposing components directly from code, without requiring a step in the UI. There was some concerns around components automatically appearing in the UI and becoming available for content creators. I'm wondering if we should approach that with tagging or categories? This way builder could select either specific components, tags or categories that they want to expose for the content creators. This way you could get rid of the additional step without having arbitrary SDC appearing in the UI.

๐Ÿ‡ซ๐Ÿ‡ฎFinland lauriii Finland

I believe we should be keeping this as close to the real thing as possible โ€“ we want to showcase a realistic experience. My impression from what I've heard is that if we wanted to do this with mock data, we would have to re-implement lots of things from Drupal in order to provide a realistic experience on top of the mock data model. Based on that, I said that we probably should then just use a Drupal site to back the demo. This doesn't mean that we couldn't host a separate static demo in the meanwhile, we just shouldn't use it for the demo.

Production build 0.69.0 2024