Implement temporary design system for the DrupalCon Barcelona demo

Isn't this a duplicate of #3446052: [later phase] Create components for a default design system? 🤔

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 👍

Ahhhh, of course! Clarified in issue title.

CivicTheme is a design system with 60 components that has a Drupal theme. It has had 8000 hours of work put into it.

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. This conversion is already on the product backlog.

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 🙏

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

Thanks!

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.

Thanks for all the clarifications @lauriii :)

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

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.
• Also our components are not dependent on block entity and can be used with any entity / view using UI pattern module.

We would also add a detailed write up around this in form of a blog post.

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

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: http://space-design-system.qed42.net
Beta Access: https://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 recording numbering)

• CivicTheme design system overview
• CivicTheme color framework

Templates

• Desktop - Light Theme (with notes on UX/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

+1 on the demo strategy.

Just 2c about the future work. 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 at QED42 we challenged SPACE on the demo figma design, present in the issue summary, 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 did the necessary tweaks.
• Updated the branding elements such as colors, fonts, and typography.
• Used our enhanced layout builder to create the page.

Demo link: https://demo.spacedxp.com
Note: Currently our components are built on top of UI patterns, but can easily be converted to SDC.

We welcome your feedback.
Thank you!

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

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 Laurii & Kristen,

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 #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. There are any questions/concerns we should address.
2. Any changes/additions should be made to the CivicTheme samples (other than the image outlines noted above).
3. The CivicTheme Design System team and/or the Space Design System team should move forward with converting components to SDC.

Thanks!

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? (update, looks like you changed the 10.6 so yes ;)

[update] Btw, I'll be traveling 5+ hours today and am not sure I'll have much cell reception until I arrive at my destination.

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.

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 (haven't advertised yet): 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 :)

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

Note that you'll need to do (a subset of) https://www.drupal.org/community-initiatives/starshot-demo-design-system... to get it to work — I only did the npm run build and composer require drupal/components:^3@beta.

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 #953034: [meta] Themes improperly check renderable arrays when determining visibility.

• 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 #3462705: [META] Missing features in SDC needed for XB tracking at #3462705-23: [META] Missing features in SDC needed for XB — 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 😊👍
• … many more problems, but as we work through the ones below, we'll solve those too.

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) -> #3469684: Surface the REASON for an SDC not being made available in XB (i.e. not meeting criteria)
   3. Front-end: make component list in UI scrollable → #3463798: No upward auto-scroll when components are dragged
   4. Back-end: ensure that the ComponentPropsForm route uses the Olivero/Claro theme, rather than the default theme. → #3469686: Changing default theme can break HTML forms generated by XB API routes: always negotiate the Stark 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 (and groups/categories) but one reason we use the module is so we can see the components in storybook (using npm, not the Drupal module).

So… SDC / core will probably 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.

UPDATE: when trying to remove the dependency last week, it was removed from the info dependencies list but I was going to add that back today unless I hear that we have to remove the dependency

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 per-slot tag/category-based restrictions capability we've identified (listed in #3462705: [META] Missing features in SDC needed for XB), 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:

#3470424: New component requirement: obsolete SDCs must not be auto-added, but must be auto-updated

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

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 props with multiple values like multiple buttons or tags on a component. The QED42 generator created array structures for multi-value 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 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 as I couldn't find any. Note that this may not be needed for the new components... there is one section which has multiple "buttons/links" but maybe we should just work around this given the timeframe. Or maybe we handle these with slots :shrug: (which goes back to the item above)

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

#3467959: SDC and code component props should be able to receive HTML, editable in formatted text fields+widgets

Looks like maybe #3467870: Support `{type: array, …}` prop shapes 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 Critical.)
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: #3467959: SDC and code component props should be able to receive HTML, editable in formatted text fields+widgets.
3. @lauriii has indicated he considers this out of scope for the Barcelona demo: lists of things are for later (#3467870: Support `{type: array, …}` prop shapes), as well as support for arbitrary "object shapes" (#3467890: [later phase] Support `{type: object, …}` prop shapes with single level that require *multiple* field types: use `field_union`? — OUT OF SCOPE: nested components/component reuse, Lauri decided that last week).

#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 #3470424: New component requirement: obsolete SDCs must not be auto-added, but must be auto-updated. 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 #3462705: [META] Missing features in SDC needed for XB). 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 (#3469442: Impossible to drop a component into an empty column of the two) 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 #3470424: New component requirement: obsolete SDCs must not be auto-added, but must be auto-updated 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! 😊

• #3470424: New component requirement: obsolete SDCs must not be auto-added, but must be auto-updated
• #3469686: Changing default theme can break HTML forms generated by XB API routes: always negotiate the Stark theme
• #3469442: Impossible to drop a component into an empty column of the two
• #3469895: Retain the space consumed by a component when it's being dragged

Woohoo 🎉 Thanks 🙏

1. Here are the current blockers for SDDS development:

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

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

1. #3469684: Surface the REASON for an SDC not being made available in XB (i.e. not meeting criteria)
2. #3463300: Implement the concept of sections within the client
3. #3469856: The component preview should have a background: include theme's global asset libraries for component preview
4. #3471169: Allow dragging components to top/bottom of page and in between adjacent components with slots
5. #3469855: Emptying a required value through the UI crashes the app (empty <input>, selecting "None" option in <select> …)
6. #3468944: Update XB's `image` SDC to comply with best practices, and document those best practices
7. #3467844: [PP-1] Log client-side errors
8. #3470321: Surface verbose OpenAPI errors in the UI — for better bug reports and faster DX
9. #3467843: Back-end route to allow logging from the UI

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

1. #3454094: Milestone 0.1.0: Experience Builder Demo
2. #3469855: Emptying a required value through the UI crashes the app (empty <input>, selecting "None" option in <select> …)
3. #3463842: [META] Redux sync on ALL prop types, not just ones with a single [value] property
4. #3471154: Allow deleting component instances by pressing "Delete" or "Backspace"
5. #3463798: No upward auto-scroll when components are dragged
6. #3446083: Document supported component modeling approaches
7. #3468112: Document the current component discovery + SDC criteria + `Component` config entity, and describe in an ADR
8. #3470973: Retain the placement of components within the preview when inserting a component
9. #3462705: [META] Missing features in SDC needed for XB
10. #3469822: Highlight slot with a border where component/section is about to be placed
11. #3471108: Unable to scroll component props form
12. #3469850: [PP-1] Occasional PHP warning when refreshing XB

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

1. #3471171: Allow components to use textarea in favor of input

5. Post-Barcelona

• #3446052: [later phase] Create components for a default design system
• #3463188: Support propless SDCs
• #3455036: Clarify "components" vs "elements" vs "patterns"
• #3467954: META: Evolve XB UI's data model to allow non-SDC components' inputs, DynamicPropSource support, etc.
• #3467959: SDC and code component props should be able to receive HTML, editable in formatted text fields+widgets
• #3459088: Every XB `Component` config entity should have a `category` property
• #3467890: [later phase] Support `{type: object, …}` prop shapes with single level that require *multiple* field types: use `field_union`? — OUT OF SCOPE: nested components/component reuse
• #3467870: Support `{type: array, …}` prop shapes

Fixed issues that should help y'all:

• #3471083: Prop select lists don't affect the component is in
• #3470550: Component config entities are incomplete: missing entries for optional props, causing errors in ComponentPropsForm is in (#3469684: Surface the REASON for an SDC not being made available in XB (i.e. not meeting criteria) is being worked on 👍
• #3458503: Improve the page hierarchy display now visualizes the hierarchy better.
• #3471171: Allow components to use textarea in favor of input 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:

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

And adding to other to watch:

#3472179: [PP-1] Can't toggle boolean prop back to true after changing to false

Updated XB blocker issue list

[UPDATE: MOVED ISSUE LIST INTO ISSUE SUMMARY]

Copying the XB issues to issue summary.

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

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

Issue summary updated for you, @kristen pol 👍

#3471085: Adding a component with slots does not register the slots as children has now landed

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

https://youtu.be/j46NzjwEfp8

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.

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

New critical (regression):

#3472634: Component List doesn't scroll

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:

#3472893: SDDS responsive styles don't fit well within XB desktop preview

And this is our number one blocker for testing:

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

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:

#3472900: XBEndpointRenderer & processResponseAssets() do not support `ajaxPageState` ⇒ duplicate CSS/JS loading

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

#3472907: AssertionError: assert($component_config !== NULL)

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 #3428529: Automated Drupal 11 compatibility fixes for components 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

#3468238: Offering to co-maintain Components

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

#3471097: Switch SDDS to D11 components module once it's available

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

Note that:

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

is currently fixed in the MR here:

#3472900: XBEndpointRenderer & processResponseAssets() do not support `ajaxPageState` ⇒ duplicate CSS/JS loading

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:

#3472907: AssertionError: assert($component_config !== NULL)

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

I've changed the top priorities for us as:

#3472900: XBEndpointRenderer & processResponseAssets() do not support `ajaxPageState` ⇒ duplicate CSS/JS loading

and

#3463842: [META] Redux sync on ALL prop types, not just ones with a single [value] property

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

👇

Quoting #53:

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) -> #3469684: Surface the REASON for an SDC not being made available in XB (i.e. not meeting criteria)
   3. Front-end: make component list in UI scrollable → #3463798: No upward auto-scroll when components are dragged
   4. Back-end: ensure that the ComponentPropsForm route uses the Olivero/Claro theme, rather than the default theme. → #3469686: Changing default theme can break HTML forms generated by XB API routes: always negotiate the Stark 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.

Everything under point 1 on the XB side is now finally done. 🏁

@lauriii & @kristen pol: did the two of you ever sync/agree on what the list of SDCs is that we're aiming to have appear in XB for the DrupalCon Barcelona demo?

Based on the messages above, I think that's the case, but I'd rather be safe than sorry 😇

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:

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

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:

#3472900: XBEndpointRenderer & processResponseAssets() do not support `ajaxPageState` ⇒ duplicate CSS/JS loading

so that textareas work and some other things.

Reordered 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 #3472893: SDDS responsive styles don't fit well within XB desktop preview was marked Fixed? :)

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 (#3473155: Redux Sync all single-value types in the SDC test all props form) — 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 #3472900: XBEndpointRenderer & processResponseAssets() do not support `ajaxPageState` ⇒ duplicate CSS/JS loading...

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

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 #3475652: Should we add SDDS to XB's Tugboat? 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.