Implement temporary design system for the DrupalCon Barcelona demo

Isn't this a duplicate of 🌱 [PP-1] Create components for a default design system Postponed ? 🤔

Also, related to this is what @ckrina started 2 weeks ago wrt design tokens (see https://wimleers.com/xb-week-3). Pinged her in Slack 👍

The default design system is the actual design system we'd deliver as a starting point for users with Experience Builder. The design system that we'd build here would be specific for demos. We certainly don't want to ship the Drupal design system as a starting point for new sites 😅

Ahhhh, of course! Clarified in issue title.

CivicTheme is a design system with 60 components that has a Drupal theme. It does need to be switched to SDC but that shouldn’t be too hard.

http://www.drupal.org/project/civictheme

Let me know what you think about converting this for the demo.

I should also note that if CivicTheme was approved as the demo design system, it’s highly likely the original creators (Salsa) would sponsor their team to convert the design system theme to use SDC.

I personally don't have a strong preference over which design system or theme we use as the starting point so long as in the end, we'll achieve the designs linked in the issue summary that matches the new Drupal brand. This could be a great opportunity for an organization like Salsa to be involved in the initiative. There's probably some extra work involved if we used a non-SDC based theme in comparison to using a theme that was already using SDC, but maybe there's value in converting the theme to use SDC outside of this initiative.

I wonder if we should speak to the promote drupal folks or the DA who're working on the D10 version of drupal.org. Whilst we need it as a temporary solution - it feels like there is long-term value in having an actual design system for drupal.org

@lauriii Thanks for the info. I will discuss with the CivicTheme team to see if those designs are feasible in a short timeframe. As they are planning on switching to SDC, this seems like a good time to do it if it would be the demo design system.

@larowlan Sounds good... is that something you are willing to take on? Or do you know who are the right people to discuss this with? I know some of the Promote Drupal team but I don't know what their goals are in terms of a design system.

We have a monthly DA and committers catchup where I can raise it. I don't know anyone in the promote drupal initiative.

Thanks for raising it there 👍 I’ll ping Suzanne to see if she knows anything about plans for a design system.

I’ve been chatting with the CivicTheme team… there is a question of if SDC is required before Barcelona for the demo design system? From above, it sounds like it’s not? I guess any hard requirements you do have beyond the Figma designs would be great. Thanks 🙏

SDCs enable Experience Builder to leverage those components. That's something we'd definitely like to include in the demo. Therefore using SDCs is a hard requirement for the demo.

Thanks for the clarification :)

For full transparency, I'm the Chair of the CivicTheme Steering Committee.

I've been talking with the CivicTheme team as well as other members of the steering committee. We are keen to throw our hat in the ring so to speak. The team is pretty heads down getting a release out the door, but the plan is to have some samples next week so you can see what CivicTheme can do right now so we can identify where the gaps are.

For an example, although not focused on Drupal, we put together samples for an open source grant proposal we did recently that may be interesting for people to peek at:

https://cardano.ideascale.com/c/idea/126352

If you search for "Prototype 1" in the proposal and scroll from that point, you'll see a number of samples/demos that were put together quickly for this grant. Here are some other resources as well:

https://www.civictheme.io/cardano/resources
https://www.figma.com/design/y4onMCtsVLXhuVEbzgGFSe/Cardano%3A-Design-Sy...
https://6661aebbcfd864009fb8f395--civictheme-uikit.netlify.app/?path=/st...

The CivicTheme team plans to put together similar Starshot/Drupal-focused samples over the next week for everyone to review and we can go from there.

Note, we do understand this is for the Barcelona demo and may not be folded into the product longer term and that is fine.

Also, there has been some concern above that perhaps we should start from scratch and build the starting *Drupal design system* rather than go with an existing design system such as CivicTheme and improve upon it. The point being then we aren't "throwing away work" and can use the same code for the demo and beyond. I do understand the concern and think we can work through this, but it would be useful for other people in the community to weigh in on this as well.

We are also open to additional questions and concerns that people may have so we can make sure to address them as well asap.

Thanks!

I've been talking with the CivicTheme team as well as other members of the steering committee. We are keen to throw our hat in the ring so to speak. The team is pretty heads down getting a release out the door, but the plan is to have some samples next week so you can see what CivicTheme can do right now so we can identify where the gaps are.

Thank you for stepping up! 🙏 Building some small proof of concepts sounds like a really good next step! 💯

Note, we do understand this is for the Barcelona demo and may not be folded into the product longer term and that is fine.

Currently this milestone is specifically tied into a demo we're planning to launch around the time of DrupalCon Barcelona but it doesn't mean we couldn't use this going forward. I would imagine that the demo is something we use for marketing Experience Builder going forward, and we might evolve the same design system for future demos.

Also, there has been some concern above that perhaps we should start from scratch and build the starting *Drupal design system* rather than go with an existing design system such as CivicTheme and improve upon it. The point being then we aren't "throwing away work" and can use the same code for the demo and beyond. I do understand the concern and think we can work through this, but it would be useful for other people in the community to weigh in on this as well.

I think it would be totally fine for the team working on this to make a decision to use an open source design system. I personally don't see why we shouldn't leverage an existing design system if we can accelerate our progress by doing so.

Thanks so much for the feedback :) Very exciting stuff, and we hope to get you all something more tangible to look at next week!

I'd vote that whatever the design system to implement the demo is be the basic design system that we then extend into the full design system for launch. I can see the benefits of using something like civic theme as a starting point but it may be good to use it as a starting point but then fork it eventually to ensure the design system for the Experience Builder can make decisions on the directions of the design system without having to coordinate those with the larger design system.

Some questions we should look to ask:

1. What's the basis of the design system? Is is based on Radix, Bootstrap, etc. or is it built entirely unique to this theme? I believe Starshot is looking to use Radix as a base and I'd recommend we coordinate with that effort as well so as to create a cohesive system. Maybe they use CivicTheme?
2. What's the direction of CivicTheme going and how would that impact the inclusion of it in experience builder? Are there differing directions the design system is going that may be different than the project and what would it look like if that did happen?
3. How quickly could we get the components ported to SDC so we can use them in the experience builder demo? Is it going to be more effort to port them to SDC than to create from a different starting point?

Overall this is super promising though and may help prototype out things very quickly!

@lauriii Question about the mockups as we just had a meeting about this and we were in Figma checking stuff out.

There is the XM Content Mockup page but there are some other things in Figma: Mockup - DUPLICATE PLEASE and Unconverted Design Mockups.

For the initial sample/demo we send over soon, should we just focus on the XM Content Mockup or should we also incorporate any of the other pages or sections/components of those pages?

Please note that there is a big CivicTheme release that is scheduled for early next week so we are currently targeting towards the end of the week (Friday Australian time / Thursday US time) to get these samples here. They don't take a lot of time to create, but the release is a blocker to get the right people working on this. We will try to provide more updates early next week as we firm down the exact timing.

Thanks @Cellar Door for you input :) In our meeting just now, we actually mentioned the possibility that Drupal may "fork" or move away from CT and do a more Drupal-product-focused thing post-demo. I don't think this is necessarily a bad thing. This is open source ;)

I can't answer all these questions as I didn't help build the design system, but I can follow up with the team for more clarity:

1. What's the basis of the design system? Is is based on Radix, Bootstrap, etc. or is it built entirely unique to this theme? I believe Starshot is looking to use Radix as a base and I'd recommend we coordinate with that effort as well so as to create a cohesive system. Maybe they use CivicTheme?

I don't think it's either Radix or Bootstrap. I will ask the tech lead for more details on this.

But, as far as I understand, we want Experience Builder to work with any design system that uses SDC, so perhaps this doesn't need to be considered for the demo design system? I defer to @lauriii and team to weigh in on that.

2. What's the direction of CivicTheme going and how would that impact the inclusion of it in experience builder? Are there differing directions the design system is going that may be different than the project and what would it look like if that did happen?

We have formed a steering committee to help with the governance model of the open source project. Although CivicTheme was open-sourced years ago, we are in the early days of the steerco and still recruiting new members. We actually have a steerco meeting today and will be discussing this potential opportunity.

The components thus far are all generic components that you come to expect from any design system. They were born out of years of experience in the government space (thus the "Civic" name) but they are generic and could be used for any website. We use them for non-government sites as well.

Some main things about the inclusion of official components into the design system are that they have user research to ensure they are what users actually want/need, they pass WCAG 2.2 AA standards, etc. That said, you can easily extend the design system to have whatever custom components you want, so you aren't locked into the governance model to get components officially added.

Our goal is to engage open source community members who will want to contribute well-thought out and highly-vetted components back into the system as official components. We have contribution guidelines and are working with several organizations who are working right now to contribute components back to the project.

3. How quickly could we get the components ported to SDC so we can use them in the experience builder demo? Is it going to be more effort to port them to SDC than to create from a different starting point?

This is an excellent question and one we've been discussing. I personally haven't used SDC or even researched it that much. Our tech lead did say awhile ago that it should be too hard to port these. We have an action item to look into this more closely and perhaps port one over as a PoC to see how long it takes so we can estimate the work. If there are other contributors who want to help, then this could be a nice way of getting involved by taking a few components and converting them :)

Thanks again for putting thought into this. We are excited at the prospect of CivicTheme being considered for the demo design system. We understand some people may have hesitations and concerns and we hope we can continue to discuss and sort these out.

I'd vote that whatever the design system to implement the demo is be the basic design system that we then extend into the full design system for launch. I can see the benefits of using something like civic theme as a starting point but it may be good to use it as a starting point but then fork it eventually to ensure the design system for the Experience Builder can make decisions on the directions of the design system without having to coordinate those with the larger design system.

I agree that in an ideal world this would be the case. If the demo works out well with CivicTheme, it may give us confidence to use it as the default design system or as a starting point to build that. However, I've intentionally tried to keep these two somewhat decoupled for now because it doesn't seem realistic for us to make a decision on that right now.

For the initial sample/demo we send over soon, should we just focus on the XM Content Mockup or should we also incorporate any of the other pages or sections/components of those pages?

For the demo, we should focus just on the XB Content Mockup.

But, as far as I understand, we want Experience Builder to work with any design system that uses SDC, so perhaps this doesn't need to be considered for the demo design system? I defer to @lauriii and team to weigh in on that.

The XB admin UI is currently being built with the Radix UI design system. That said, I don't think it needs to have an impact on the decision regarding which design system to build the demo design system because like @Kristen Pol is saying, XB should work with any SDC based design system.

Thanks for all the clarifications @lauriii :)

We have also developed a design system internally, which is built in storybook, http://space-design-system.qed42.net/?path=/story/welcome--page, Component are defined to be compatible with Ui patterns should be easy to convert them and make them work with SDC.

Please let us know further thoughts around it.

Thanks

Thanks @guptahemant. That's a fun coincidence that yours has a space theme :D

What kind of user testing did you do and what compliance standards does your design system comply with (e.g. WCAG AA 2.2)?

What are your open source licensing policies for Figma, UI Kit, etc?

Any background info on the design system's evolution would be helpful too.

Forgot to mention that we were able to schedule work and should have the demo/samples by EOD Thursday (US time zone) but maybe earlier in the day.

One thing that came up yesterday when we were discussing the XB designs was what user testing and accessibility review happened on these and if we have access to that information.

Hi Kristen, I discussed internally and was able to get following information:

What kind of user testing did you do and what compliance standards does your design system comply with (e.g. WCAG AA 2.2)?

SPACE being component based allowed us to look at individual component performance and accessibility, allowing us to have lower time to assemble an accessible & performant web page. We have factored for WCAG 2.0? and have noticed some minor gaps that is easy to fix with nominal effort.

What are your open source licensing policies for Figma, UI Kit, etc?

SPACE started as a Drupal accelerator for QED42's projects, since starshot announcement we see lot of similarities in both objective and approach and are looking into open source licensing of our core architecture.

Any background info on the design system’s evolution would be helpful too.

We started with a Design system that had to be flexible to take branding as configuration, figma tokens & annotations for better interoperability with space drupal theme. Build plan also needed to be in line with Drupal core evolution, hence we went with drupal core blocks as components rather than paragraphs and integrated heavily with layout builder.
We would also add a detailed write up in form of a blog post.

That’s a fun coincidence that yours has a space theme

It’s a pleasant coincidence that our product names are similarly themed.
The naming is a pleasant co-incident, it strengthens our co-relation. We named it SPACE, for the fact that any branding needs can be accommodated on the platform and all 3rd party integrations possible in spirit of OpenDXP

Official links:
Main site: https://spacedxp.com
Design system: https://space-design-system.qed42.net
Beta Access: space-drupalconlille.qed42.net

Feel free to reach out for beta access.

@guptahemant Thank you for these details. I'll post some CivicTheme samples for review shortly. And then I'll review and respond to your comment more thoughtfully.

Here are some samples of the XB home page mockup in the CivicTheme design system along with additional resources.

Screencasts (ignore numbering)

• CivicTheme design system overview
• CivicTheme color framework

Templates

• Desktop - Light Theme (with notes on accessibility/etc)
• Mobile - Light Theme
• Desktop - Dark Theme
• Mobile - Dark Theme

Prototypes

• Desktop - Light Theme
• Tablet - Light Theme
• Mobile - Light Theme
• Desktop - Dark Theme
• Tablet - Dark Theme
• Mobile - Dark Theme

Resources

• UI Kit GitHub repository
• UI Kit Storybook
• Drupal.org project page →
• Drupal Slack channel
• Documentation site
• Marketing site
• Contribution guidelines
• Accessibility compliance (WCAG AA 2.2)
• UX/Design Splash Award
• Government endorsement
• DrupalSouth presentation

Next steps

Get approval from XB team to move forward and, if approved:

1. XB team to review mockup design and
   1. Review the Figma notes provided on UX, accessibility, etc.
   2. Identify any changes needed to the mockup, if any
   3. Determine who will facilitate and execute mockup design changes, if needed
   4. Identify any gaps in the CivicTheme implementation that need addressing
2. Salsa team to review identified design gaps, if any, and
   1. Estimate design work
   2. Create additional information and/or samples
   3. Share updated designs and notes
3. Salsa team to review architecture gaps such as
   1. Single Directory Component (SDC) support and/or migration
   2. Adding new variants and components into CivicTheme or keeping custom

Change a summary heading back to what it was (changed by mistake).

@guptahemant Apologies, but I'm not feeling well, so can't provide a proper response right now to your detailed comment.

For now, I'd lean on @lauriii to see what he thinks should be the next steps for this issue based on:

1. All the comments and samples/prototypes provided above
2. Slack discussions
3. Parallel design system and component work happening in XB/Starshot

Specifically the model i like about civictheme is the UI Kit implementation with Storybook. However since experience builder will use SDC isn't there an SDC native design system technique we would be using?

Hi Everyone

Internally we challenged SPACE on the demo design and were able to build it within a day by following these steps:

• Compared the provided design with our in-house SPACE design system.
• Identified the components to use and the necessary tweaks.
• Updated the branding elements such as colors, fonts, and typography.
• Used our the enhanced layout builder to create the page.

Demo link: https://demo.spacedxp.com

We welcome your feedback. Thank you!
Note: Currently our components are built on top of UI patterns, but can easily be converted to SDC.

@sime we would convert the CivicTheme components to SDC if we were chosen for the demo.

@guptahemant Thanks 👍 do you have the Figma for this as well? I do see you match closer to the mockup designs compared to the CivicTheme sample but please note there are UX/accessibility reasons behind why we did things differently that are explained in the Figma file if you are interested in reading those.

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 https://drupal.widencollective.com/portals/gfvztttq/BrandPortal. 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?

Thanks 🙏 Sorry but Im traveling and have no internet and only occasional partial cell reception for the next couple days so I’m leaving this quick acknowledgment from my phone. I did share your comment with our designer just now while I’m out of SOS mode. I should be able to follow up properly in a couple days.

Hey,

https://www.figma.com/design/bAnd87KYw7YASCry80QOaY/SPACE-DS-%E2%80%93%C...

We aligned our component library with the provided starshot design, updated our design tokens and created the demo.spacedxp.com page.
For your reference have attached the figma file of our design system to have a look.

Would also like you to have a look at the comment " class="!text-blue-400 !no-underline" target="_blank" rel="nofollow" >#26 → as well.

Happy to receive feedback and also would love to hear about the experience you had with SPACE instance.

Thank you!

Big apologies. I was in the countryside/mountains for a few days and didn't realize the Airbnbs wouldn't have internet, and the cell reception was very spotty. Then I had a family emergency on top of that. I'm back in civilization now.

@vidit.anjaria Thanks for the Figma and for pointing out the other resources again. I'll let Lauri comment on those.

On the CivicTheme side, thanks for reviewing the Figma @lauriii and we understand your concerns about the design looking too generic. I was able to talk with the team late last night and the designer will update the Figma file to match the demo designs based on your feedback.

For now, we'll assume that you will keep your demo designs as is and not incorporate any of our UX/accessibility feedback. He's finishing some client work in the next couple of days and then will do the Figma update. I'll post the updated Figma file here by the end of the week.

At that point, once both design systems implementations match the demo designs, we'll need direction from @lauriii on if one or both design systems should move forward to porting to SDC, so they can be tested with XB prior to the Barcelona demo. Or maybe there are other considerations that have surfaced that also need to be factored in to the chosen design system(s)? We are happy to continue on this journey, so just let us know :)

Hello :)

Our designer was able to update the designs yesterday before going on vacation for 2 weeks. There are 2 variants:

1. 1440 desktop width based on the CivicTheme design system grid
2. 2134 desktop width based on Drupal XB Content mockup sample

Templates:

• Figma - 1440 desktop width
• Figma - 2134 desktop width
• Figma - Build Outside The Box with Phosphor icons

Note: I see that the outlines aren't on the "Build Outside The Box" images for the XB landing page. This is simple to update so I'll see if one of our other designers can update this. This is not a limitation of the system and can be easily done.

Icons: The Phosphor icon component was added based on discussions in the #promotedrupal Slack channel over the last week. It is not meant to replace the component in the XB mockup, but we thought it would be nice to add based on those recent discussions.

Prototypes

• Tablet - 1440 desktop width
• Desktop - 1440 desktop width
• Tablet - 2134 desktop width
• Desktop - 2134 desktop width

Exports

• 1440 desktop width →
• 2134 desktop width →
• Build Outside The Box with Phosphor icons →

Next steps

@lauriii to review with the XB+Starshot teams to determine if:

1. Any changes/additions should be made to the CivicTheme samples (other than the image outlines noted above).
2. The CivicTheme Design System team and/or the Space Design System team should move forward with converting components to SDC.

Thanks!

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. 😊

Thanks @lauriii 👍

I’ll check with the team but we are definitely open to collaborating and I can help coordinate that effort. I can add more detail in a day after checking on the other things.

A couple of questions:

1. When would you like the demo ready? You will need time to test so I’m assuming by mid August at the latest?

2. Do you mean 10 July?

Hi @laurii

Regarding #41 Please find our response for each individual item:

When do you expect to start and finish the project (rough timeline)?

We can start working from mid next week and we will be covering below things

• Conversion of current Figma to align with our Design System Figma file, keeping the essence of current figma design intact
• Atoms & Molecules to convert into SDC

We are expecting this to be completed by Mid August.

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?

Initially, we prefer to work internally until the basic setup and cleanup tasks are completed. Once we reach that stage, we are open to collaborating with contributors to advance the project further. We anticipate reaching this point by the last week of July or aim to start collaborating with contributors during the mid-process of cleanup.

Does your team have prior experience working with SDC?

Yes, but not on the actual projects but our SPACE product architecture uses Ui patterns, so it should be easier to convert them on SDC.

How much timezone overlap does your team have with CET office hours (9.00-17.00)?

(9.00-17.00) CET = (12.30-20.30) IST - Considering this, overlap hours can be 6-6.5 hours.

Please let us know your thoughts further.
Thanks

Thanks @guptahemant!

Fyi, I'll post our responses before the end of my night (Pacific time zone) so it's available at the start of @lauriii's day to review and help inform the decision.

Thanks @lauriii for leading this review process.

I will provide somewhat brief responses to your questions below, but I have more complete information in the attached slide deck → . I’ve also recorded an unrehearsed (midnight!) video of me going through these slides if you prefer.

1. When do you expect to start and finish the project (rough timeline)?

Assuming you make your decision tomorrow, we would start planning the work more officially this week. Next week, we’d start architectural review and technical direction. Soon afterwards, with the first component migration, we’ll create an SDC migration guide, so that others can also contribute. The plan is to get components for your team to start testing mid-August and then iterate based on any feedback, so that we are done before September. In September, we would promote DrupalCon Barcelona and the XB demo, and we can also support you in-person in Barcelona if that helps. Here’s a visual breakdown of the 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?

Definitely! CivicTheme has established contribution guidelines, processes and documentation, and we are comfortable working with community members to provide support and mentoring and to collaborate on contributions.

Some ways we would like to engage contributors is by creating an SDC migration guide, setting up dedicated Slack channel, running regular async meetings, etc. Based on the proposed timeline, we would be able to start community engagement in late July. Here is some supporting information:

3. Does your team have prior experience working with SDC?

While we haven’t used SDC on our client projects yet, we’ve used similar structures on many Drupal projects where we’ve implemented or integrated design systems and UI components. We’ve been designing, building and integrating design systems since late 2014.

Salsa also presented on SDC earlier this year for DrupalSouth 2024.

CivicTheme uses atomic design principles and is structured in a similar way as SDC. We’ve had SDC on our CivicTheme technical roadmap since it was added to Drupal core and have had discussions in the CivicTheme Steering Committee about this, so this will be a good opportunity to accelerate the migration.

How much timezone overlap does your team have with CET office hours (9.00-17.00)?

Our team are in Australia, India and the US. Async collaboration is best for worldwide participation, but real-time CET discussions can be supported as needed. I’ve included a worldbuddy image below that shows the time zones. For Pacific time zone, the best overlap is 3pm+ CET. For India, the best overlap is 9am to 1pm CET, but later hours can be supported. Australia business hours don’t align to CET business hours, but we can arrange for night meetings as needed until around 1pm CET. Putting this together, minimal coverage is from 9am to 1pm and 3pm to 5pm but probably can cover the entire time depending on which team member is needed.

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.

One final note is I’m also attaching our whitepaper: “Designing evidence for a world-class open source design system” → which talks about our evidence-based framework which you may find interesting.

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.

Thanks @lauriii for the thoughtful response.

We are very excited 🎉 and definitely welcome the QED42 team to join our effort. Though their team helping with the d.o redesign work sounds amazing too ❤️

We’ll get cranking on our end and even will likely pull in a CS intern to help which aligns with getting new people involved with Drupal.

More soon!

Thanks @laurii for finalising on this.

We are committed and look forward to contributing here, We will keep following the progress via issue queues and slack, and will jump in to contribute when Migration guide is ready.
@Kristen Pol Please let us know if there are some specific areas where we can help. Overall very excited to see what we can deliver here as community.

Additionally we would definitely check around D.O redesign opportunities and would reach out to @hestenet via slack / Issue Queues

Very exciting to see this happen!

It's been quiet for a week now … I'm curious if there's any news to share? 🤓🤞

Haha... yes... thanks for the prod ;)

Been busy over here:

1. Prototyping some SDC migration work to inform the guide creation for next week
2. Team planning and coordination
3. Created Slack channel (haven't advertised yet): #starshot-demo-design-system
4. Created project and started creating epics and issues: https://www.drupal.org/project/demo_design_system →

We'll be doing more this week to prep for making the guide next week in anticipation for getting more people involved.

Stay tuned!

Progress update: We are working on contribution guides now and are targeting those to be done by the end of next week, so we can do a webinar the following week and welcome new contributors. We are also planning on working on a couple of XB demo components next week as well as a handful of SDC conversions for the existing CivicTheme components to use as examples in the SDC conversion guide. Stay tuned :)

Wim Leers → credited jessebaker → .

Now that 📌 Auto-create/update Component config entities for all discovered SDCs that meet XB's minimum criteria Fixed is in, I just tried https://www.drupal.org/project/demo_design_system → for the first time, together with @lauriii and @jessebaker.

The good news

We got the starshot-card component to render in XB:

🥳

The bad news

There's lots of show-stopping problems:

• Most components provided by the Starshot Demo theme require slots to be populated, otherwise they do not render. This means that upon placing such a component, ZERO markup is present, which means it's impossible to render a preview of them 😅

  Either default content must be present in each slot, or this conditional rendering must be removed.

  I vote the latter, because … conditional rendering actually doesn't work anyway — see 🌱 [meta] Themes improperly check renderable arrays when determining visibility Needs work .

• Lots of SDC metadata is inaccurate. For example, the starshot-card component says:
  

    required:
      - title
      - summary
      - link
      - image
  

  those 3 are required props. But … neither link nor image is even an existing prop! 😅

  (I'll add this upstream SDC bug to 📌 [SPIKE] Comprehensive plan for integrating with SDC Active — SDC's DX should point out such problems!)

• It revealed a bunch of bugs in XB too — which is why we're testing this now, a month before DrupalCon Barcelona 😊👍

Next steps

1. 1. Kristen to indicate which components she expects to appear in XB
   2. Back-end: Wim/Felix to log REASON for component being excluded (i.e. not meeting criteria)
   3. Front-end: make component list in UI scrollable :)
   4. Back-end: ensure that the ComponentPropsForm route uses the Olivero/Claro theme, rather than the default theme.
2. @lauriii to confirm the list of components from 1.1
3. @kristen pol to use the log output added in 1.2 to add/fix SDC metadata to the list of components identified in 2.

I'll create the issues on the XB side for those next steps 👍

Issues now exist for 1.2, 1.3 and 1.4 👍 #53 has been updated to link to them.

Uh… I wasn’t given any heads up here and had no idea this was happening. I only yesterday got to testing XB and looking at the XB components and saw the examples section for example. I already made a ticket yesterday for that and also to clean up the required props so those are happening this week. Maybe popping in our slack channel or a DM on what’s happening would be good so we can coordinate better? Meanwhile I’ll review this more carefully to understand the other gaps

And apologies for my rudeness… it’s been quite a rough week.

Also I’m not sure that you are aware but Suzanne asked me late last week if we can do all new custom components because they completely redid the redesign so our frontend folks are scrambling to do the new components.

Just an acknowledgement that we are working through the various issues and can see config getting created....

Because the components module is not ready for D11 and it's unclear the D11 MR is working, I've switched back to D10. Based on Wim's comment above, it's clear D10 was being used.

For now, required fields have been completely removed until the contributor working on that can go through all the components.

I expect we'll have much better alignment next week :)

kristens-mbp-2:sync kristenpol$ ls experience_builder.component.civictheme+*
experience_builder.component.civictheme+accordion.yml			experience_builder.component.civictheme+message.yml
experience_builder.component.civictheme+alert.yml			experience_builder.component.civictheme+mobile-navigation-close.yml
experience_builder.component.civictheme+attachment.yml			experience_builder.component.civictheme+mobile-navigation-menu.yml
experience_builder.component.civictheme+back-to-top.yml			experience_builder.component.civictheme+mobile-navigation-trigger.yml
experience_builder.component.civictheme+banner.yml			experience_builder.component.civictheme+mobile-navigation.yml
experience_builder.component.civictheme+basic-content.yml		experience_builder.component.civictheme+navigation-card.yml
experience_builder.component.civictheme+breadcrumb.yml			experience_builder.component.civictheme+navigation.yml
experience_builder.component.civictheme+button.yml			experience_builder.component.civictheme+next-step.yml
experience_builder.component.civictheme+callout.yml			experience_builder.component.civictheme+page.yml
experience_builder.component.civictheme+campaign.yml			experience_builder.component.civictheme+pagination.yml
experience_builder.component.civictheme+checkbox.yml			experience_builder.component.civictheme+paragraph.yml
experience_builder.component.civictheme+chip.yml			experience_builder.component.civictheme+popover.yml
experience_builder.component.civictheme+content-link.yml		experience_builder.component.civictheme+promo-card.yml
experience_builder.component.civictheme+datetime.yml			experience_builder.component.civictheme+promo.yml
experience_builder.component.civictheme+event-card.yml			experience_builder.component.civictheme+publication-card.yml
experience_builder.component.civictheme+field-description.yml		experience_builder.component.civictheme+radio.yml
experience_builder.component.civictheme+field-message.yml		experience_builder.component.civictheme+search.yml
experience_builder.component.civictheme+field.yml			experience_builder.component.civictheme+select.yml
experience_builder.component.civictheme+fieldset.yml			experience_builder.component.civictheme+service-card.yml
experience_builder.component.civictheme+figure.yml			experience_builder.component.civictheme+side-navigation.yml
experience_builder.component.civictheme+footer.yml			experience_builder.component.civictheme+single-filter.yml
experience_builder.component.civictheme+grid.yml			experience_builder.component.civictheme+skip-link.yml
experience_builder.component.civictheme+group-filter.yml		experience_builder.component.civictheme+slide.yml
experience_builder.component.civictheme+header.yml			experience_builder.component.civictheme+slider.yml
experience_builder.component.civictheme+heading.yml			experience_builder.component.civictheme+snippet.yml
experience_builder.component.civictheme+icon.yml			experience_builder.component.civictheme+social-links.yml
experience_builder.component.civictheme+iframe.yml			experience_builder.component.civictheme+subject-card.yml
experience_builder.component.civictheme+image.yml			experience_builder.component.civictheme+table.yml
experience_builder.component.civictheme+input.yml			experience_builder.component.civictheme+tabs.yml
experience_builder.component.civictheme+item-list.yml			experience_builder.component.civictheme+tag-list.yml
experience_builder.component.civictheme+label.yml			experience_builder.component.civictheme+tag.yml
experience_builder.component.civictheme+layout.yml			experience_builder.component.civictheme+textarea.yml
experience_builder.component.civictheme+link.yml			experience_builder.component.civictheme+textfield.yml
experience_builder.component.civictheme+list.yml			experience_builder.component.civictheme+tooltip.yml
experience_builder.component.civictheme+logo.yml			experience_builder.component.civictheme+video-player.yml
experience_builder.component.civictheme+map.yml				experience_builder.component.civictheme+video.yml
experience_builder.component.civictheme+menu.yml			experience_builder.component.civictheme+webform.yml

kristens-mbp-2:sync kristenpol$ ls experience_builder.component.starshot_demo+*
experience_builder.component.starshot_demo+button.yml			experience_builder.component.starshot_demo+starshot-one-col.yml
experience_builder.component.starshot_demo+starshot-banner.yml		experience_builder.component.starshot_demo+starshot-paragraph.yml
experience_builder.component.starshot_demo+starshot-card.yml		experience_builder.component.starshot_demo+starshot-three-col.yml
experience_builder.component.starshot_demo+starshot-container.yml	experience_builder.component.starshot_demo+tag.yml
experience_builder.component.starshot_demo+starshot-heading.yml

Just an acknowledgement that we are working through the various issues and can see config getting created....

Yay! 🥳

I expect we'll have much better alignment next week :)

💯

Can you indicate which components you'd expect to see appear in XB? Is it only the experience_builder.component.starshot_demo+* ones or more? (👈 This was our question for you over at #53.1.1.)

Because the components module is not ready for D11 and it's unclear the D11 MR is working, I've switched back to D10. Based on Wim's comment above, it's clear D10 was being used.

How critical is the reliance on the Components module? 🤞 Would it be hard or easy to refactor that away? (I have no idea! It's possible the answer is simply "Are you kidding me? You clearly don't know anything about this or you wouldn't even ask this!" — because I do not know. At the surface level, it seems to "just" be about Twig namespaces?)

I was not in any of the above conversations, so apologies if this was discussed out-of-band. I'm just surprised that module is a dependency — it saw its last release >2 years ago. (Also: why not list it as a dependency of the theme? That has been possible for 2.5 years now → .)

I personally expected this demo design system to come with zero dependencies (on additional modules/themes). But I defer to @lauriii. Assigning to him to get his feedback.

Thanks 🙏 regarding the components module dependency … I’d hoped we might be able to remove this… it’s for twig namespaces… but core doesn’t support that. We are using a UI kit that is tech agnostic so pulled in from outside of drupal and then additional custom components are added with the subtheme. We can hack it to use SDC for the namespace if you want no dependencies.

Given this is an existing design system, it of course has many components but…

As for the components that show for the demo, I would love it if we could have the group in the SDC yaml dictate the organization and then we could label all the custom components as “Starshot” or “Drupal”. or alternatively some sort of tag as has been mentioned

Sorry but on phone so this text is messy

Also… i already put more context in slack last week on the components module stuff but one reason we use it is so we can see the components in storybook (using npm, not the Drupal module).

So… SDC / core will need to allow custom namespaces to allow pulling in components that aren’t just for Drupal

But again… we can get rid of the dependency for Barcelona if you need it.

So… SDC / core will probably need to allow custom namespaces to allow pulling in components that aren’t just for Drupal

I'm not sure how much would this help given that SDC as a format is already Drupal specific. In most scenarios where outside components are being used, I'd imagine that there's either a build step that compiles non-Drupal components into SDCs or a manual step where a developer integrates the components with Drupal (by writing *.component.yml and loading the template + CSS). This might become more valuable if SDC as a standard gets adopted outside of Drupal.

But again… we can get rid of the dependency for Barcelona if you need it.

For the purposes of the demo, I don't have a strong opinion on how it's set up. If we have some known workarounds in there, instead of trying to get rid of them, I think it's fine to just document those so that if someone is looking at the code base, they get a sense of what the end result might look like.

Thanks. We were thinking about having a build step anyway in order to combine the SDC YAML files with the ui kit components. We can revisit next week after we sort out more pressing things like the YAML structure and get the new designs pulled in

would love it if we could have the group in the SDC yaml dictate the organization and then we could label all the custom components as “Starshot” or “Drupal”.

That is the capability we've identified (listed in 📌 [SPIKE] Comprehensive plan for integrating with SDC Active ), which is not yet implemented yet and won't be before DrupalCon — @laurii considered that non-essential for Barcelona. Unless @lauriii is changing his mind based on this? 😊

I’d hoped we might be able to remove this

👍

For the purposes of the demo, I don't have a strong opinion on how it's set up.

Right, the technical underpinnings are not really visible in the demo. I do think it'd be nice if the Starshot demo design system were as close as possible to core's way of using SDCs though (no external dependencies, everything self-contained is a key design/architecture aspect of SDCs) 🤓

Gotcha and understood. When chatting with Lauri yesterday, I suggested a stopgap where we can mark any of our components “obsolete” that shouldn’t be shown in the demo and created this issue:

📌 New component requirement: obsolete SDCs must not be auto-added, but must be auto-updated Active

Note that the SDDS team did build off of the original Figma designs:

https://www.figma.com/design/aADVsc8fdsENnUaKePvVpg/Experience-Builder-D...

but were asked to ditch those (we are renaming those components to old-component-name :) in lieu of the new designs that were sent less than 2 weeks ago:

Target Pages for Barcelona > Kasey’s Homepage

https://www.figma.com/design/tKYim76bnDZAyWubUi3sVv/New-Drupal-Brand---D...

so we should update the link in the summary, but I'm hesitant to update the summary myself :D

Feel free to update the issue summary @kristen pol! You are leading this track so I think it's totally fine for you to update the issue summary based on the input that you received from the marketing team. 😊

Updated summary with latest Figma and how to get involved.

While I will try to be more diligent about adding updates here, the best place for status is in the dedicated Slack channel and weekly meetings which are now noted in the summary.

Assigning to me.

Will try to update this issue more regularly for those who are not following the SDDS project issue queue → or dedicated Slack channel.

We had a great breakthrough yesterday (see screenshot below) with refactoring our SCSS/CSS and getting most of the baseline SDC "examples" in place so we can see components and some are functional enough to see the preview upon hover and then drag into the main area and move around. Although most of those components will likely *not* be part of the demo, it shows a much more clear path forward, so I/we were very happy last night when seeing this 🎉

Things that should land this week include the new design components (getting final touches now) and tweaks to the examples (like placeholder images). Next week, we should be able to have more testing for components that have okay previews (even if they are not in the demo, we'd like people to test these as they may help find issues in XB).

The main "blockers" right now are:

1. It's hard to test due to some known XB critical issues right now, e.g. scrolling, preview background. We are working around them as best we can (by switching to MR branches for testing), but it will be hard to have more people in the community help with testing until these are fixed. I know the XB team is hard at work to squash these, so hopefully they will get done this week.
2. Knowing how best to use slots as this doesn't seem to be fully sorted based on issue discussions I've seen, but I may have missed something as there are many issues! :D
3. Knowing how best to do SDC nested props. The QED42 generator created array structures for some nested props, but these bombed in XB. I commented out these in the YAML files for now. We haven't really had time to take a look at the structure and compare against any XB examples or other SDC examples, but that is on the critical path so it's my highest priority now that the examples and new components are getting in good shape. If you have any good example SDCs for this, let me know.

I didn't list it as a "blocker" but am wondering where this one will land as well since this is obviously a "big deal" :D

📌 [later phase] `StringSemanticsConstraint::MARKUP`: agree how SDC prop JSON schema can convey it should be markup, and allow using CKEditor 5 Needs review

Looks like maybe 📌 [later phase] Support matching `{type: array, …}` prop shapes Postponed is what we need for number 3 in #70. If so, then we will just not focus on those for now and just focus on single value props.

We are adding SDC YAMLs to the new design components in MR right now.

Notes

1. These new components don't have as much configurability as the previous round due to time constraints
2. For now, since we can't scroll and obsolete components aren't hidden, we are moving many of our components YAMLs to have .txt extension for now so they are not in the UI and we can see what we need to see better
3. Related: How will the XB components be hidden? Or will they?
4. Since multivalue props (arrays) can't be defined in the YAML, I assume we need to use props for those
5. Am following a bunch of XB critical issues so hopefully some things will land this week to make testing easier
6. I'm working through what I can by poking around the issues and code and debugging.

Current Blockers

1. Blocker: Hard to test as noted above in #70
2. Blocker: Need to understand how best to use slots as noted above
3. Blocker: Need to understand how best to define images in YAML
4. Blocker: Can't edit props for components due to errors

#70:

so I/we were very happy last night when seeing this 🎉

🥳🚀

1. 💯 — I've asked the people working on XB full-time to prioritize those issues. (You probably saw I marked all of them .)
2. There's no final decisions on that front at all. It's largely a design & product question. @lauriii decides in that sense. The only slot-related thing we're actively discussing is related to rich text editors (think: CKEditor 5) and where/how you could use them. The issue for that indeed has a lively discussion with lots of possible directions: 📌 [later phase] `StringSemanticsConstraint::MARKUP`: agree how SDC prop JSON schema can convey it should be markup, and allow using CKEditor 5 Needs review .
3. @lauriii has indicated he considers this out of scope for the Barcelona demo: lists of things are for later ( 📌 [later phase] Support matching `{type: array, …}` prop shapes Postponed ), as well as support for arbitrary "object shapes" ( 📌 [later phase] Support `{type: object, …}` prop shapes that require *multiple* field types — also: nested components/component reuse Postponed , Lauri decided that last week 📌 [later phase] Support `{type: object, …}` prop shapes that require *multiple* field types — also: nested components/component reuse Postponed ).

#73:

1. IMHO that's fine.
2. ✅ ACK
3. WDYM by "hidden"? As in: SDCs that exist, but do not show up in XB? If that's what you mean: you can "hide" them today by deleting them from /admin/structure/component. We're adding support for disabling them (use case: a SDC was not obsolete and has been adopted; then it was marked obsolete, which means it must not be listed anywhere, but it must continue to work) in 📌 New component requirement: obsolete SDCs must not be auto-added, but must be auto-updated Active . Does that answer this question?
4. XB simply does not support type: array prop shapes yet, and will not before DrupalCon. Anything that we demo would simply exclude SDCs that have type: array.
5. ✅ ACK
6. 🙏 I've noticed: ~50% of new issue triaging I've done this week has been for issues you created 😄

RE: bockers:

1. 💯, I'm well aware and I've impressed this upon the folks working on XB
2. Not clear to me what the exact blocker is: can you point to issues where this has been tricky? 🙏
3. Do you mean example/default images, or component props that must receive images? Default/example image is not supported at this time, because SDC does not support it (this is one of the SDC infra things we're tracking in 📌 [SPIKE] Comprehensive plan for integrating with SDC Active ). If it's component props that receive images: use
   

       my_image:
         type: object
         $ref: json-schema-definitions://experience_builder.module/image
   

Thanks for the lengthy feedback and prioritizing those issues 🙏

It’s 1am here and been working since 730am except for a walk 😱 so I’ll read this more carefully tomorrow.

I think once the slot issue is fixed where you can drag into an empty slot, I’ll be able to refactor the components easier since I can test them. I’ll look at the XB image component tomorrow and compare against ours to see what’s amiss.

As for moving components out of the way, deleting from UI only works until you clear the cache. We have about 80 components in our design system plus the XB ones so I’ve gone through ours to “hide” many that won’t be demoed. I did leave a few simple ones that aren’t the new design to have something easier to play with.

I think once the slot issue is fixed where you can drag into an empty slot,

Yes, I prioritized that ( 🐛 [PP-1] Impossible to drop a component into an empty column of the two Active ) yesterday, and it's working, but it still needs review from @bnjmnm and/or @hooroomoo to land 😬

deleting from UI only works until you clear the cache

Indeed. Which is why @f.mazeikis is prioritizing the adding of more criteria to automatically include only relevant SDCs, and why 📌 New component requirement: obsolete SDCs must not be auto-added, but must be auto-updated Active is extra important (the "disabling" ability would be survive cache clears). 👍

@kristen pol FYI, a number of improvements/fixes have landed that should make things much easier for you fine folks working on https://www.drupal.org/project/demo_design_system → , when testing your SDCs in XB! 😊

• 📌 New component requirement: obsolete SDCs must not be auto-added, but must be auto-updated Active
• 🐛 Changing default theme can break HTML forms generated by XB API routes: always negotiate the Stark theme Fixed
• 🐛 [PP-1] Impossible to drop a component into an empty column of the two Active
• 🐛 Retain the space consumed by a component when it's being dragged Fixed

Woohoo 🎉 Thanks 🙏

1. Here are the current blockers for SDDS development:

1. 🐛 Component config entities are incomplete: missing entries for optional props, causing errors in ComponentPropsForm Fixed
2. 📌 Media Library integration (includes introducing a new main content renderer/`_wrapper_format`) Fixed
3. 📌 Fix the visually broken "image" component instance: use FileUriItem's computed `url` property, not the stored `value` property Active
4. 🐛 Adding a component with slots does not register the slots as children Fixed
5. ? 📌 Component props form: map textarea, bool, and select elements to React components Fixed
6. ? 🐛 `enum` data shapes: error when choosing "- None -" in `` Needs work

2. Maybe not a blocker to development per se but these would be helpful:

1. 📌 Surface the REASON for an SDC not being made available in XB (i.e. not meeting criteria) Fixed
2. ✨ Implement the concept of sections within the client Fixed
3. 🐛 The component preview should have a background: include theme's global asset libraries for component preview Needs work
4. 🐛 Allow dragging components to top/bottom of page and in between adjacent components with slots Fixed
5. 🐛 Emptying a required value through the UI crashes the app Active
6. 📌 Update XB's `image` SDC to comply with best practices, and document those best practices Needs review
7. ✨ [PP-1] Log client-side errors Postponed
8. ✨ Add the ability to surface more helpful error details for display in the UI Active

3. These are not blockers to development but ones we are also tracking:

1. 🌱 Milestone 0.1.0: Experience Builder Demo Active
2. 🐛 Emptying a required value through the UI crashes the app Active
3. 🌱 [META] Redux sync on ALL prop types, not just ones with a single [value] property Active
4. ✨ Allow deleting component instances by pressing "Delete" or "Backspace" Needs review
5. 🐛 No upward auto-scroll when components are dragged Needs review
6. 📌 Document supported component modeling approaches Active
7. 📌 Document the current component discovery + SDC criteria, and describe in an ADR Active
8. 🐛 Retain the placement of components within the preview when inserting a component Active
9. 📌 [SPIKE] Comprehensive plan for integrating with SDC Active
10. 📌 Improve UX of adding new sections Needs review
11. 🐛 Unable to scroll component props form Needs review
12. ✨ Backend route to allow logging from the UI Active
13. 🐛 [PP-1] Occasional PHP warning when refreshing XB Postponed

4. Recently fixed issues that require us to update things:

1. ✨ Allow components to use textarea in favor of input Needs review

5. Post-Barcelona

• 🌱 [PP-1] Create components for a default design system Postponed
• 🐛 Support propless SDCs Needs review
• 📌 Clarify "components" vs "elements" vs "patterns" Active
• 🐛 Some components cannot be used in XB because UI prevents SDC props being named `name` Active
• 📌 [later phase] `StringSemanticsConstraint::MARKUP`: agree how SDC prop JSON schema can convey it should be markup, and allow using CKEditor 5 Needs review
• 📌 Define built-in components and categorization for components Postponed
• 📌 [later phase] Support `{type: object, …}` prop shapes that require *multiple* field types — also: nested components/component reuse Postponed
• 📌 [later phase] Support matching `{type: array, …}` prop shapes Postponed

Fixed issues that should help y'all:

• 🐛 Prop select lists don't affect the component Fixed is in
• 🐛 Component config entities are incomplete: missing entries for optional props, causing errors in ComponentPropsForm Fixed is in ( 📌 Surface the REASON for an SDC not being made available in XB (i.e. not meeting criteria) Fixed is being worked on 👍
• 📌 Improve the page hierarchy display Active now visualizes the hierarchy better.
• ✨ Allow components to use textarea in favor of input Needs review landed, which means you can now express a shape for your SDC's props to cause a <textarea> to show up — but it won't work just yet — see #3463842-6: [META] Redux sync on ALL prop types, not just ones with a single [value] property →

Thanks! It looks like we are unblocked enough to move forward again

https://youtu.be/eW2FcHSx-bY

Adding to blockers:

🐛 Redux support for ImageWidget: `[image] String value found, but an object is required` Postponed

And adding to other to watch:

🐛 [PP-1] Can't toggle boolean prop back to true after changing to false Postponed

Updated list:

1. Here are the current blockers for SDDS development:

1. 🐛 Adding a component with slots does not register the slots as children Fixed
2. 🐛 Redux support for ImageWidget: `[image] String value found, but an object is required` Postponed
3. 📌 Fix the visually broken "image" component instance: use FileUriItem's computed `url` property, not the stored `value` property Active

2. Maybe not a blocker to development per se but these would be helpful:

1. 🐛 [PP-1] Can't toggle boolean prop back to true after changing to false Postponed
2. 🐛 `enum` data shapes: error when choosing "- None -" in `` Needs work
3. 📌 Surface the REASON for an SDC not being made available in XB (i.e. not meeting criteria) Fixed
4. 🐛 The component preview should have a background: include theme's global asset libraries for component preview Needs work
5. 🐛 Allow dragging components to top/bottom of page and in between adjacent components with slots Fixed
6. 🐛 Emptying a required value through the UI crashes the app Active
7. 📌 Update XB's `image` SDC to comply with best practices, and document those best practices Needs review
8. ✨ [PP-1] Log client-side errors Postponed
9. ✨ Add the ability to surface more helpful error details for display in the UI Active
10. ✨ Backend route to allow logging from the UI Active

3. These are not blockers to development but ones we are also tracking:

1. 🌱 Milestone 0.1.0: Experience Builder Demo Active
2. 🐛 Emptying a required value through the UI crashes the app Active
3. 🌱 [META] Redux sync on ALL prop types, not just ones with a single [value] property Active
4. ✨ Allow deleting component instances by pressing "Delete" or "Backspace" Needs review
5. 🐛 No upward auto-scroll when components are dragged Needs review
6. 📌 Document supported component modeling approaches Active
7. 📌 Document the current component discovery + SDC criteria, and describe in an ADR Active
8. 📌 [SPIKE] Comprehensive plan for integrating with SDC Active
9. 📌 Improve UX of adding new sections Needs review
10. 🐛 Unable to scroll component props form Needs review

4. Recently fixed issues that require us to update things:

1. ✨ Allow components to use textarea in favor of input Needs review

5. Fixed or closed

🐛 Component config entities are incomplete: missing entries for optional props, causing errors in ComponentPropsForm Fixed
1. 📌 Media Library integration (includes introducing a new main content renderer/`_wrapper_format`) Fixed
2. 📌 Component props form: map textarea, bool, and select elements to React components Fixed
3. ✨ Implement the concept of sections within the client Fixed
4. 🐛 Retain the placement of components within the preview when inserting a component Active
5. 🐛 [PP-1] Occasional PHP warning when refreshing XB Postponed

6. Post-Barcelona

• 🌱 [PP-1] Create components for a default design system Postponed
• 🐛 Support propless SDCs Needs review
• 📌 Clarify "components" vs "elements" vs "patterns" Active
• 🐛 Some components cannot be used in XB because UI prevents SDC props being named `name` Active
• 📌 [later phase] `StringSemanticsConstraint::MARKUP`: agree how SDC prop JSON schema can convey it should be markup, and allow using CKEditor 5 Needs review
• 📌 Define built-in components and categorization for components Postponed
• 📌 [later phase] Support `{type: object, …}` prop shapes that require *multiple* field types — also: nested components/component reuse Postponed
• 📌 [later phase] Support matching `{type: array, …}` prop shapes Postponed

Copying the XB issues to issue summary.

📌 Fix the visually broken "image" component instance: use FileUriItem's computed `url` property, not the stored `value` property Active was just fixed.

The two other blockers are in progress too: 🐛 Redux support for ImageWidget: `[image] String value found, but an object is required` Postponed is being worked on by @bnjmnm, 🐛 Adding a component with slots does not register the slots as children Fixed is being worked on by @balintbrews & @jessebaker.

Issue summary updated for you, @kristen pol 👍

🐛 Adding a component with slots does not register the slots as children Fixed has now landed

Thanks! From testing a couple hours ago. I still need to play with slots again.

https://youtu.be/j46NzjwEfp8

Responding to #3463300-21: Implement the concept of sections within the client → .

1. Will there be other sections created for Barcelona?
2. Is SDDS supposed to create sections?
3. How do you create sections? Is there documentation?

1. I was planning to create a few sections for demonstration purposes. I haven't defined yet which ones to create though. I was waiting to see more of the components in SDDS to exist before making a decision.
2. I didn't expectat you to have to create sections which is why I never brought it up with you. However, if you have ideas on what you'd like to present as sections, I'd be more than happy to collaborate with you to create these.
3. Sections are currently hard coded in coded in the frontend. This was added to the frontend so that we could demo this. These are located in ui/src/services/sections.ts. It basically just stores JSON which would usually be generated by the XB.

Thanks for the details. I'll plan on looking more at sections early next week. We will be refactoring our new components over the next few days so will keep this in mind while we do.

I'm happy to jump on a call to brainstorm this in case that that would be helpful. Let me know!

Cool... that might be good early next week after we've done more integration work :)

New critical (regression):

🐛 Component List doesn't scroll Needs review

I've been using the component scroll mr branch to continue to test. I'll try to give an update here late tonight or tomorrow but some progress has been shown in the XB Slack channel.

One thing we need direction on ASAP please so I know if our frontend devs need to adjust on our end:

💬 SDDS responsive styles don't fit well within XB desktop preview Active

And this is our number one blocker for testing:

🐛 Redux support for ImageWidget: `[image] String value found, but an object is required` Postponed

though there may be others (maybe related?)... hard to say until that one is squashed.

Essentially, I can't use the prop form in most cases now and there isn't anything in the logs and the JS console isn't helpful. I'll probably just make an issue for your team to try some of the components and see if they can figure out what's going on with the prop form.

Okay... I've created one for the hanging props form:

🐛 XBEndpointRenderer & processResponseAssets() do not support `ajaxPageState` ⇒ duplicate CSS/JS loading Fixed

Add for the assert issue I've been working around:

💬 AssertionError: assert($component_config !== NULL) Closed: outdated

Following up on sections from #88, we are going to see where we are at later this week to determine if it would make sense for us to do anything with those.

Quoting #53:

composer require drupal/components:^3@beta

… that still doesn't work on Drupal 11, because 📌 Automated Drupal 11 compatibility fixes for components Needs review isn't in

@lauriii, are you aware that this means that this is currently not yet on track to be demoable on Drupal 11?

We’ve been trying hard to get that committed. Rob said he’d commit it if RTBC which it is and I’ve pinged his employer but nothing yet. John Albin has responded. I’ll ping Tim H.

I’m trying to fast track

https://www.drupal.org/project/projectownership/issues/3468238 →

Tim has added Adam as co-maintainer so I've pinged Adam and have moved this issue back to active:

📌 Switch SDDS to D11 components module once it's available Postponed

I'm assuming I'll be able to switch us in a couple days.

Note that:

🐛 Redux support for ImageWidget: `[image] String value found, but an object is required` Postponed

is currently fixed in the MR here:

🐛 XBEndpointRenderer & processResponseAssets() do not support `ajaxPageState` ⇒ duplicate CSS/JS loading Fixed

along with textarea so I will use that branch for now even though it hasn't fixed everything yet.

Adam said he'll get the D11 components MR merged today so we should be able to switch to D11 by tomorrow.

We're on D11 now. And I've done some cleanup and can't reproduce:

💬 AssertionError: assert($component_config !== NULL) Closed: outdated

with completely fresh local so hopefully that was just due to cruft of testing many versions.

I've changed the top priority for us as:

🐛 XBEndpointRenderer & processResponseAssets() do not support `ajaxPageState` ⇒ duplicate CSS/JS loading Fixed

and

🌱 [META] Redux sync on ALL prop types, not just ones with a single [value] property Active

📌 Surface the REASON for an SDC not being made available in XB (i.e. not meeting criteria) Fixed is in too, which should help local testing a lot :)

Thanks!

I don't normally have trouble getting components to show up as I understand the limitations of XB very well now and can hack around things.

But, editing in the props form has been a huge bug bear and what I've been mainly working around which probably takes me 2 to 4 times longer to do anything. For example, to test all the props except image, I'll comment out the image, reload components, test the props, and then the image isn't in the preview, so have to switch back to having the image in it again. If I need to retest the props, rinse and repeat.

I've also run into a variety of bugs that probably don't have issues. For example, with integers, it seems where two components using the same prop name and one is an integer and another is a string. But, we are are too down to the wire so we will change on our end to use different prop names or not use integer. At this point, rather than reporting bug after bug, I'm just trying to find ways around the bugs.

I've been working closely with @alan.cole on adding more slots and sub-components so that you build up the sections to make it look like the design.

XB has only been somewhat usable enough for the last few days to work through this better. We've made good progress in the last couple days, but it's still in an MR at the moment. I feel like we have a good way forward for everything except perhaps the slider, but I'm checking with Alan on that when he gets online.

The biggest blocker for me (and what is preventing getting more people in the community to help test) are still the following which are probably all related:

🐛 XBEndpointRenderer & processResponseAssets() do not support `ajaxPageState` ⇒ duplicate CSS/JS loading Fixed
🌱 [META] Redux sync on ALL prop types, not just ones with a single [value] property Active
🐛 Redux support for ImageWidget: `[image] String value found, but an object is required` Postponed

I need the props form to work for all components, so I don't need to waste time commenting out, rebuilding, testing, uncommenting out, rebuilding, etc.

As for the components to show in the demo, we have been building everything from the designs (again, updates are in the MR and not in the main branch yet).

We can easily rename any of these, but here's what I've been testing:

For structure:

• Grid (not fixed width... we can discuss... this is not the same as column components)
• Container
• One Column
• Two Column
• Three Column
• Four Column

Simple things:

• Heading
• Paragraph
• Button
• Image

Cards:

• Card
• Slide Card
• Stats Card

Bigger things:

• Hero
• Testimonial
• Case Study
• CTA
• Slider

I should be able to create a video with building up the page in the next couple days. Again, the slider is still questionable, but we could at least put columns and put the slider card in there to represent the section.

As for other components beyond these, there are some that work fine from the old design and from the base CivicTheme theme, but I don't know what should be demoed beyond the landing page sections.

And, as for "actual Sections", I still haven't had time or energy to look at this. We can revisit at the end of the week.

Note that it will show up fine at 1024 so that's no longer an issue.

Moving issues around in the summary.

p.s. I think I already said before I've been using the MR here:

🐛 XBEndpointRenderer & processResponseAssets() do not support `ajaxPageState` ⇒ duplicate CSS/JS loading Fixed

so that textareas work and some other things.

Reorder blockers.

Some videos using the MR that I'll be merging shortly.

Best to watch in this order:

1. Case study testing
2. Hero testing
3. Cards and testimonial testing
4. CTA testing
5. Stats cards testing
6. Slider testing (part 1, screen share goes away at around 3:45)
7. Slider testing (part 2)

Hard to get a full screenshot but here are some partials...

Managed to zoom out to get a better screenshot

Very nice! 👏

I assume those screenshots are why in your meeting with @lauriii 💬 SDDS responsive styles don't fit well within XB desktop preview Active was marked ? :)

We're very well aware of the component props form functionality being incomplete. There's not enough of us to have it all working already. Just this morning, a big leap forward on that front landed ( 📌 Redux Sync all single-value types in the SDC test all props form Fixed ) — and it came with end-to-end test coverage to ensure that for the tested prop shapes (and hence field types+widgets), it does work correctly 👍

Using MR from 🐛 XBEndpointRenderer & processResponseAssets() do not support `ajaxPageState` ⇒ duplicate CSS/JS loading Fixed ...

It took me a few tries, but I made it through all components except the last one in one go... I had to side step some issues (e.g. dragging certain things, can't upload), but this is SO DEMOABLE if you know what *not* to do :D

https://youtu.be/SAir2OxwMS4

Latest testing details and videos:

https://www.drupal.org/project/demo_design_system/issues/3473641#comment... 📌 Community XB+SDDS integration testing Active

Given we can demo for Barcelona (using MR branch etc as noted above), I don't think we "need" to do anything more on the SDDS side before Barcelona.

@lauriii please let me know if you have any blockers or want any tweaks.

Do folks here think 📌 Should we add SDDS to XB's Tugboat? Needs work is a good idea or bad idea? Please chime in over there with what you see as pros or cons of that.

I think it would be great... I added a quick comment :)

DrupalCon Barcelona happened, https://www.drupal.org/project/experience_builder/releases/0.1.0-alpha1 → shipped, https://dri.es/state-of-drupal-presentation-september-2024 is live … great job, @kristen pol and team! 🙏👏

Woohoo! Let us know if you want/need anything in SDDS for Singapore and/or 15 Jan 2025.

Automatically closed - issue fixed for 2 weeks with no activity.