I responded on
📌
[PP-2] Add ComponentAuditabilityTest
Active
. I'm concerned that storing this information in the Component config impacts DX negatively. We need to consider how are components authored, and how are they edited during their lifecycle, and how that overall experience looks like. Today, if components or templates are being changed, the changes are reflected immediately to the site. We should strive that same experience. We need to remove as many barriers from the XB from authors; the goal is for it to feel just as if you're editing a regular template or component.
From DX perspective the value of duplicating this information in the config seems questionable. There could be implementation reasons why it's needed but it's hard for me to consider this from that perspective. However, if we do it, we need to somehow allow getting changes to components, as well as the field type + widget settings to the config (if that's what defines what gets used in XB). During development, it seems normal that these values get changed. We have to account for the effort to address that, and the complexity it introduces for us to manage that.
Looks like #11 was already part of the issue summary as "Schema references". Marking it as confirmed.
Marked the "per-slot tag/category-based restrictions" as ✅ since this is needed to implement a design system using the Paragraphs use case.
I believe we can get away without required slots for now because it is possible to compose smaller components into bigger components, which allows defining them as required. This is the purple scenario from 📌 Document supported component modeling approaches Active .
Wim Leers → credited lauriii → .
Wim Leers → credited lauriii → .
+1 for rescoping this to handle #5.
This looks pretty nice! It would be super cool if we could slightly smoothen the transition when zooming. This can be a follow-up but could be worked on here too in case you're interested in this 😊
Great, thank you for pointing that out!
@bnjmnm can you confirm if this meets the requirements or if more work is needed?
Thank you for confirming that @Wim Leers! I was worried that this would be challenging from technical perspective, and felt more confident about designing a UX for this. I would not say that it's a trivial UX task but it should not be insurmountable. I think that's a good sign given that we both feel good about this *high-five* 😊
I don't think it is likely that a {type: string, enum: …} SDC prop schema would be able to be supported by existing structured data (i.e. existing entity fields). IOW: a DynamicPropSource for them seems to be a rather edge case need.
This is indeed a scenario which doesn't work very well with the current DynamicPropSource concept because mapping enum values 1:1 introduces tight coupling between the data model and the components. I'm glad we're getting to the weeds because it helps us discover these scenarios.
For this scenario, we'd need some concept of mapping values. I'm wondering if it would make sense to implement this as an adapter:
Linking ✨ [PP-2] Implement the concept of sections within the client Postponed which is an issue to implement this capability in the UI. This issue would focus on storing this information in the backend.
This is already implemented as part of 📌 Implement component states Fixed .
Confirmed with @hooroomoo that this is no longer needed after ✨ Implement the updated insert menu and layers panel Active .
This is semi hard-blocked on: 📌 Create a component for testing form backend + frontend integration Active .
This will be at least partially solved by ✨ Contextual form values need to be integrated with Redux Active based on @bnjmnm.
Could we add a "debug" prop to the component to show these things? In a future issue, we could consider toggling that based on an environment variable (or something else) but for now it could be something that developers would have to turn on manually within code.
Ah, I didn't realize this was looking the way that it does because the components are implemented in this way. Makes sense! 👍
I filed this issue during our weekly planning with you, based on instructions I received from you. 🤔 I agree that the issue summary could use some more context but I don't have any more information than you to expand on this.
#2: I agree we should not implement a backend API for this because we know it would be replaced by the auto-generated images. This would be only in the scope of the client implementation. FWIW, I created this issue with @jessebaker and he didn't raise concerns over this approach. Maybe he can explicitly confirm if he thinks it's okay to keep both of these issues to be actionable in parallel.
#3: Can you point out what are the remaining questions in regards to sections? To me it seems that it's pretty clear what sections are in comparison to components and elements. My perception is that what's remaining in relation to sections is making sure that section as a term makes sense. If naming is all that's remaining to be clarified, I'm not sure we should make it a blocker to this.
Thank you for working on this @fazilitehreem! 💯
Something I noticed as part of the video you posted was that the top-level components (i.e. section) drag handle was rendered inside the canvas. However, according to the designs, the drag handle should be rendered outside the canvas in this scenario:
It looks like there's some additional spacing inside the canvas which may need to be removed as part of this issue for this to work.
This is blocked on being able to test this with nested components, which would be enabled by:
- 📌 Create validation constraint for ComponentTreeStructure Needs work
- 📌 [PP-1] Create an example set of SDC components Postponed
There's also ✨ Option to change the icon for components on the page hierarchy display Active which is a soft-blocker.
The "Add section" button should be only active when the component is active / selected, meaning that it should not be visible when hovering over a component that is not currently active / selected. Currently the button appears in the hover state, even when the component is not active.
griffynh → credited lauriii → .
🤯
Even better 🤩
This might be something we should give further consideration but I would imagine users would not expect that copying a component also copies the property expressions source data. This means that copying a component to a new host entity could lead into situation where property expression could be pointing to a target which doesn't exist in the new host entity.
An additional consideration for improving performance is to only re-render the parts that were changed. There's a similar improvements in the works for Layout Builder: ✨ Only reload updated part of Layout Builder element Needs work .
Hmm, this doesn't look same as the design?
FYI, I opened ✨ [PP-1] Update preview automatically when component props are updated Postponed which is focused on handling the updates to the preview.
We probably need ✨ Contextual form values need to be integrated with Redux Active before this can be worked on.
Adding a link to the Figma prototype as well.
This is blocked on:
Ah good catch @Wim Leers. I meant to postpone this.
Should we revisit this after: ✨ Implement the updated insert menu and layers panel Active ?
lauriii → created an issue.
lauriii → created an issue.
I agree we didn't discuss this during the discovery. AFAIK there isn't core issue for this yet. Is this something you think we should do directly in core or could we do this first on XB since the icons are specifically needed by XB?
I don't think the DX impact is that large because this doesn't mean that SDCs are required to provide an icon. SDCs that are not exposed to the XB would not benefit from an icon and you'd also want to be able to use SDCs without an icon within the XB. We would provide a default icon for components without an icon.
There could be an alternative approach which is to just not display the original label and expect it would have to be set again in the new language. The reason I'd consider this inferior is because if you see the original language, at least you can put it in a translator and come up with a translation.
It'd mean this metadata (it's not actual content) would have to be translated too.
The complication is that the UX would have to design/signal in some way that a component badge is not yet translated, and should nudge the content creator to translate it.
Why do you think there would have to be a nudge to translate it? I see the label merely an enhancement for content authoring. I wouldn't consider it a big deal if it's not translated to the target language because it's not presented to the end-user. However, they should have the option to do that. If a designer created Figma files for different languages, I doubt that they would translate the layer names unless there was a good reason to do so.
Assigning to @Utkarsh_33! 😊
The components need to be able to specify icons to make the UI work. We're currently using this icon in several places from the layers view to the component list in the insert panel. We could start by allowing components to specify a custom icon but for DX + UX, we should provide an icon library which developers can use for selecting an icon. This ensures that the icons being used are consistent. I know that the UI Suite folks are implementing a new module for icon libraries which might be something we could use for this: https://www.drupal.org/project/ui_icons → .
To be more precise: SDCs have no way to declare that a particular field type or field widget must be installed.
Can we allow them to declare that? It seems that we are regressing the DX in a non-trivial way due to constraints that we have within the system.
A) it's totally reasonable to want to use contrib-provided field types/widgets, B) there are plenty of field types outside "core" core, but by core modules: from images to date range, and much more.
I think the image use case is the single common scenario we've identified. Other than that, this feels quite edge casey for components.
Unless the badges themselves would be translatable too. But if that's translatable, that would complicate the UX?
We could make the label translatable. I would imagine the translation would be added just by editing the label within the translation so I'm not sure how that would complicate the UX?
AFAICT the badge makes sense based on the location in the tree more so than the contents of the components? If so, then the badge should be stored as part of the tree structure (tree → \Drupal\experience_builder\Plugin\DataType\ComponentTreeStructure). Or … if it depends on the contents, then it should be stored as part of the props values for each component in the tree (props → \Drupal\experience_builder\Plugin\DataType\ComponentPropsValues)
I'm not sure I understand what would be the implications of storing this in one or another. Could you elaborate on that? 😇
It is not conceptually that different from Layout Builder; sections are parts of a page. However, what's different from Layout Builder is how users create sections. In Experience Builder, sections can be created out of components, or they can be created using section templates. Section templates are just pre-configured components that constitute a section on a page.
FWIW, the current terminology is our hypothesis on what we believe makes sense based on competitive analysis. Acquia UX is in progress of researching if the proposed terminology and categorization makes sense for our target user: 📌 [needs design] Define built-in components and categorization for components Postponed .
Yes, it changes site-by-site. One site would want to use the Image field type, another would want to use the Media field type restricted to the "Photo", "Screenshot" and "Flickr" media types.
That's what I tried to say in #5 – there are valid use case like selecting where images come from. However, this is different from selecting whether component uses radio vs select, or textfield vs textarea. In these examples, it is not something that would change site by site, so why provide a UI at all for configuring this?
Here's the currently proposed IA which may help get a sense of what the difference is: https://www.figma.com/board/odeJtdvynsTvUIUUpIqO8n/Proposed-component-IA.... How that connects to here is that:
- Patterns are called "Sections". They are pre-defined compositions of components coming from other groups (elements, components, dynamic components, community components)
- Blocks are called dynamic components because as @Wim Leers points out in #10, they are "renderable units powered by logic".
Based on that, we can answer that "sections" are essentially the same as what we are calling "patterns" here.
📌 Add component instance edit form to contextual panel RTBC has landed.
I ran into an error with the new sidebar which ended up crashing the whole client side app. Another data point that we need some improvements in regards to this.
I'm wondering if this is something we would even have to provide as a configuration. Does this change site by site? There could be specific things we'd want users to be able to configure, like which image provider to use. There's probably some other scenarios to account for but does it warrant a whole UI for configuring all of this? Even if we didn't build a whole UI and config system for this, we could allow modules to make more advanced changes programmatically.
I'm also curious if this should act as a default value, or if the change should propagate across the system. Imagine that you had to move from file field to media entity. Why would an user ever want to update every individual component to use media instead of the file field?
How does the default values in PropShapeInput work in relation to default values shipped in components? We want the components to behave consistently when they are moved from one system to another, including their default values.
Based on the recording looks great! 👏 @fazilitehreem if you have a moment, it would be helpful if you could rebase this. 😊
Assigning for @jessebaker to review!
Wim Leers → credited lauriii → .
valthebald → credited lauriii → .
valthebald → credited lauriii → .
griffynh → credited lauriii → .
lauriii → created an issue. See original summary → .
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.
Adding a link to Figma which has a benchmark + a hypothesis to test: https://www.figma.com/board/PtSgs0OuOaU1uwpstivpmM/Benchmark?node-id=0-1....
We are planning to launch a research utilizing unmoderated interviews + tree testing next Monday.
Objectives
- Define what building blocks are most important to the potential users of the Experience Builder (XB).
- Define the ideal menu IA for users to efficiently navigate the tool.
- 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.
Users/Participants
We can target the following groups on PlaybookUX:
Personas
- Designers (Maggie & Amir)
- Front-end developers (Clare & Keith)
Target Markets
- Education/schools & Volunteer orgs (primary)
- Mid-market agencies (primary)
- Enterprise users
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 Drupal.org for Drupal Starshot → as well as work to implement these designs for Drupal.org 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.
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.
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.
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.
Yes, the whole menu should close on drag.