 So, let's start. Okay, so thanks a lot for attending our session. And welcome to the presentation of UI Suite, which is an initiative that we did with Pierre, and which aims to provide a local teaming experience inside Drupal. So today, you will have two speakers for the price of one, so myself, Michael Fanini. I'm working at Drop Team, which is a French digital agency with a strong Drupal DNA. Here is Pierre. Hello. We didn't test this mic. Is it working too? Okay, nice. So, yeah, I'm not working at the moment, but I'm working on a UI Suite initiative, and it's already a huge work. So today, the talk will be organized into five points. So I will take care of the introduction by presenting the goals, objectives, and motivation of the initiative. And I will conclude the presentation by presenting all the implementations we've done to date, and our future needs. And in between, Pierre will take care of the presentation of the approach, the solution, and some technical examples. So let's start. I'd like to kick open those before starting to present the initiative. And I think I've not wrong by saying that probably everyone here loves Drupal. Drupal is a great software. It's one of the greatest CMS on the market. And we can love it for many, many reasons. And we wanted to outline maybe six of them. So first, Drupal is open source and also completely free. It has a great community, which is inclusive. It has a unique architecture and is very flexible. And last but not least, Drupal is low-code, as you can do so much complex things without producing a line of code. So we love Drupal. And this is even more true when you look at Drupal with an expert eye on the solution. Here, we didn't do so much effort as we reproduced a graph that DRIS presented at a previous Drupal con in Amsterdam 2019. So here, we want deep dive into comparison between other CMS. But what is important to outline is that Drupal adoption is harder for intermediate users and it's even more complicated when you are a beginner. So one of the main objectives of UI Suite is to change that and to ease this adoption for intermediate and these beginners users. So I'm really proud of the animation here. So this is one of the objectives. Make this line more like a flat. So I told you that Drupal is a very good low-code solution. So let's have a look at the low-code capabilities of Drupal regarding three main topics. So the first one is content modeling. The second one is business rules and the third one is design. So regarding content modeling, you can do so much thing in a low-code way with Drupal. You can create unlimited content types with unlimited fields, create taxonomies, blocks, menus, et cetera, et cetera. And when it comes to business rules, it's also the same as you can declare unlimited text formats, create image styles, create workflows, roles and permissions, create listing with views, et cetera, et cetera. But when it comes to design, the limit is reached really fast as there are so much specific things that are related to the design. So our motivation with UI Suite is the conviction, is that when it is simple or it has medium complexity, it has to be said buildable. And then our conviction is to make this part said buildable. So our starting point was the design system. How many of you know what is the design system? I've worked with some design system. So yeah, maybe 15 people on 70 in the room. So design system is a way of seeking the design, not page by page, page mockup by page mockup, but as a system of element which are defined, catalog, structure, which can be shared in an organized way. Drupal is a content management system. So it seems natural where we can make those two systems communicate. This is some part of the design system. So we have three examples, bootstrap, material design from Google and Bulba. In the design system, you will meet a lot of components. This is the most visible part component with variants, like cars, boutons, a slider, highlight, banner. There is also some styles. Sometimes they're called utilities or helpers. It's stuff you can apply on every component of component region. Layout, you know the grid, like the bootstrap grid is very used. And of course some examples, because when you are building a design system, you need to show to the people what they can do with the design system. So implementing a design system in Drupal, it's not something new. Myself, I'm doing this for nearly 10 years, but it's not always convenient. For example, bootstrap, they are providing only static files. There is the CSS, the GS, and there is some markup, but only example markup. So you need to reproduce this markup on Drupal. It's not that easy. And when a design system is providing already existing template, like for example Bolt, but it's a wonderful design system that came already with Twig. The Twig is not fitting with Drupal, because Drupal doesn't know how to read the Twig file of Bolt. So you are doing a lot of glue in preprocesses or templating. And us, this is not what we target. We target to implement the design system the Drupal way. That means making a design system available in the back office for city builders. So we were looking for modules like five years ago, which cover every part of the design system. Mainly the four parts I show you in the previous slide. And where everything can be implemented in a Drupal theme. It's very important for us that every thing of the same is implemented in the same place with a format easy for the front developer. So after looking, we found this workflow when the front dev is implementing the design system in the team, 100%. And the theme is providing plugins, Drupal plugins. And those plugins will be used by the city builder in the config entities when he's building his website. And also can be used by the back developer with the plugin API or with the render API. So this is the four modules. For the component of the design system, we found a wonderful module called UI Pattern. It was a starting point for us because UI Pattern shows us the way to go. And so there was nothing to do. There was just an ecosystem to expand for UI Pattern. For the styles, there was many modules available. We're providing this kind of dynamic class you can apply to markup. But we wanted everything to be defined as the ML file in the team easy for a front developer. So we build our own module, US style. For layout option, we show you later why we pick this module. And for example, we build UI examples. The three first modules, as you see, are plugin provider for Drupal config entities. So UI Pattern and the layout option, as I told you, we didn't make them. First, it was made by Nouvelle, with Fabien Eir, who are one of the members of the team who did this module. Thank you a lot. And the layout option is done by Cigin Monroe. Before going to technical example and to show some demo, you have to understand that this principle is totally reversing how we work with Drupal. This is classic timing. The classic timing you may know, I guess. So the seedbuilder and the back developer are working. They are building and developing the website. The result of this work is providing markup, template naming, template suggestion, CSS selector, everything for the team to work. The front dev has two choices. Maybe he is accepting everything coming to him and is trying to style the markup of Drupal, which is not very easy. I know the community did a great work for Drupal 7 or Drupal 8. And even now, to make it easier, but still, it's not always easy. Or the front dev can fight against this markup. Anyway, it's not what we want. We want to reverse this. We want the front dev to be the owner of the implementation. The front dev has this place, a workplace. It's called the Drupal team. It's working in this workplace and is on everything. Everything is doing. Patterns, styles, layout will provide to the back developer tools to work. So next, we will see how it works. First, yes, workflow. I talked about ownership. Ownership of the design system implementation by the TEMR. And this is very important. This is how I was working with my team until two weeks ago. So there was an initial build team for our project, for our client. He's doing the first implementation of the design system, for example, the design system with the client design. And once it's done, the next project to work with the design system and to use it and to expand it, they will not ask new front developers. They will ask the front developer team to work on the first implementation. Because design systems are not projects. Design systems are products. So once it's done, it's shareable. It's expandable. And you have a front developer as product owner of the design system. So it's very important to have this full ownership of the front dev on this work. This system has many advantages, but you don't see those directly. When you do a project at the beginning, it's kind of the same cost and risk as a classic project. Because to build a design system, you need to do a lot of change management, a lot of workshop. You need to make everybody part of this work. And it can be a bit heavy. But once it's done, it's a game changer. Because the design system implementation, as you will see there, it's usable for all the next projects. And it's very, very easy to maintain and to expand. So let's finish with the theory. Thank you for listening. Let's go to what you expect, the technical example. What I will show you is example taking from bootstrap for implementing with UI suite. And as I told you, everything was implemented inside the same. So you can find on the failure sheet of a Drupal team, everything relating to component with the patterns, style utilities and helpers with the styles, layout and grid with the layout. Let's implement a pattern together with UI pattern. So a pattern is a plugin. So what you see on the right, it's a plugin definition. Alert is a plugin ID. And then everything else are the plugin properties. So of course, you can have a label. You can define the variant. For example, for alert, we have primary, secondary success. We can have warning error, this kind of variant. For card, we can have horizontal, vertical, wide, highlight. We can have some settings and feed. Settings and fields are very similar. The difference is fields, it's free. You can inject anything in a field. Here you see is text and render, but it's the type only just to give a clue. It's not very strong. On settings, it's something, it's a Boolean. And you can inject only a Boolean. So Drupal know how to provide the UI for Boolean. Once you do this, you have a pattern library. Of course, for a component, you also need a template. There is one template by component. But thanks to the template suggestion, you can do also one template by variant if you need to. So this is really a classic twig template. No sick fancy using only the Drupal extension. The first line is just a little tip how to manage variant. We do like that. It's useful, but you can do the way you want. And with this twig and ECML, it's NOS. Of course, you need the CSS, the GS, but it's NOS for Drupal to understand what you are doing. So once you have implemented the component, as you see, there is many examples. On the left, you can imagine way more. Like, for example, the banner is here. Like, for example, the tag or the chip. Every component is going into a proxy plugin. It's a single format of plugin, which is not usable in a confidence it is. It's a bit hidden. But this proxy plugin will be used to generate a lot of more plugins you will use. Thanks to the ecosystem of a module, you see the module column, we can generate from this proxy plugin view styles, and view rows, and view formator, and layout to use with the views config entity. We can generate layout, view formator, entity links, and blocks to use with a layout builder and manage display, except for blocks. You also, it's not shown here, but you can also use to manage flags, for example, for the fact module. And we are planning to extend the coverage. It's very important to understand this shape, you know, because when a front developer is implementing a card, he's not implementing a layout. He's not implementing a block. He's implementing a card. It's a pure UI and UX element definition. When the front developer is implementing this system, he's not doing Drupal stuff. Of course, there is a few Drupal extension in the twig, but he's not providing a Drupal work. He's providing a pure front design system implementation. And then, it's the builder and the back developer who will choose what we will do. Will I use my card as a layout? So every field of my card is a region of the layout. Will I use it as a view rows? That means every field of my card will be a Drupal field, or as a view formator. Every field of my card will be a field property. You see, this mapping between Drupal and the data system is not done on the front side. The front side is agnostic. This mapping is done on the site building side or the back dev side. And this is very powerful. You have a pattern library, so every pattern, you know, it's like storybook and all this stuff. I think you know, but it's included in Drupal. It's optional. So that means you can have a look on every pattern you created and you can test it with your team, with the client, before using it on the Drupal website. So this is an example. So I am on Layout Builder. I choose Layout Builder for two reasons. First, because I love it. But second, because it's very visible. But don't forget, UI Suite is not related to Layout Builder. If you don't like Layout Builder, you can use UI Suite with your tools. UI Suite is only providing classic Drupal plugins. And then you attach them to anything you want. So I choose pattern button, variant primary, and I map. I map the field properties, URI to URL, Label to text. And here I have my field as a button. I go back. I choose another pattern with alert, variant success. Label will go to adding, and text will go to message, and I submit. So this is the local stuff we told to you. There is zero custom PHP code. What is borrowing that? It's only the tweak file and the YAML file I showed you before. But because we moved the mapping, we moved the complex part from the front dev side to the seed builder side, it's a config entity we are editing here. And it's a plugin we are attaching here. So we are using all the powerful API of Drupal to do this complex stuff. On views, let's have a look. So here we have a view with grid. We use the bootstrap grid and cards. Here I'm changing. I think it's a button group with a button. This is the result. So every row of the view, every result is a button. And the view style itself is a button group. I go back here. I choose a grid row, component grid row, and component card. Component card, there is an entity view display using it. It's not direct, but it's the same. And this is my result. Once again, no code, no PHP code, no preprocess, no crazy stuff, only using what was defined in the YAML and tweak file by the front developer. Next, let's talk about styles. Our styles, we tend to forget styles, but styles are very important. For example, if you have a card and you want to center the body of the card, of course, we will not create a new card variant. You need styles. You will apply the centered style on the card body. It's very important in the system to have styles, utilities, and helpers. So here is shadow, the shadow bootstrap. This is a plugin too. Everything is a plugin. It's a kind of proxy plugin too. It's not something you will attach directly, but it works very similar than UI pattern. Shadows is a plugin ID. Label is a plugin label. Options are a different class we can apply. They are exclusive. That means you can't have both shadow none and shadow large, of course. That's how you define a style. A style is a collection of class were exclusive from each other. And you can also have some preview to have a nice preview on the library. Librarie look like that. You know, it's very similar to the pattern library, but for styles. And then you can use styles. So here we are back to our bootstrap banner. And I'm applying the success color to the field. And I'm removing the success color. So applying style like that is not new. I know we have a lot of competition. I know it's not mind blow. There is layout builder style which is very good, for example. But the other module we know, they are not implementing here. This has YAML file and plugins on the same. And this is the important part. No config entity to build, no PHP to code, no content to keep on the database. It's only a file on the same folder. For a layout, this is a Drupal layout, the classic Drupal layout you already know. There is the plugin ID again, label again, the properties again. Nothing special. But if you implement layout like that, maybe you meet an issue. There is a big issue with layout implementation today. Can you show us? If I implement the layout as a class using the annotated class discovery, I can't make it configurable. I have this interface, default configuration and build configuration, who allow me to have configuration on my layout. For example, if I implement a bootstrap layout, I can say what is the gutter size? What is the margin bottom? What is the responsive behavior? But if you implemented as a YAML file, you have no access to those configuration. So it's very limited. And because we don't want the front developer to do the PHP, we need to make the layout YAML file better and hopefully someone did that. Can you show us? It's called layout option. And the option, very simple, allows the front developer to add configuration to the layout is building. So with container, with gutter, anything you can imagine. And of course, those configuration, you need to work with them in the tweak file defining the layout. So let's have a look. This is a good builder again. And we have settings here. And we can decide, we will not use gutter and we will change the responsive behavior. From 6.6 to 8.4, it works. So once again, what is impressive here? It's there was zero line of PHP code. Never. Everything fit in 15 line of YAML. And it's forever like that. So this is the local part. Example page. Example page is not the most used module of UI suite because example page doesn't provide plugins. It's not something we can use in the back dev and in the seed building. But it's important anyway. Example page is only a way of defining render array in a YAML file. It's very simple, but it's very useful because you can show to the people what you can do with your component and your styles and layout. You don't need to wait the back developer to develop with that or the seed builder to build with that to show your implementation is a working way. And of course, we have example page library. So this is a page, it's a huge render array using only component and styles. So we are talking a lot about the front developer but all the back developer can use the component. There is two way of using it, the presenter template. So presenter template, it's simply a template where there is no markup. It's a template who act as a proxy in between what is providing by Drupal and what is providing by this system. Why do we need presenter template? Because not everything on Drupal, not every display on Drupal can be built. For example, if you want to, you can't build the breadcrumb display, not possible. You can't build the status message display or the menu display. I'm not talking about menu item but the menu display. So for menu, breadcrumb, status message, local task, you need to use the template provided by Drupal and instead of putting your markup here, you just call the component you want to use. So this is breadcrumb.html.tweak and it's calling the breadcrumb template. And render array also, if you need, for example, to do a very complicated fee formator, because the fee formator for UI suite is just mapping, mapping, mapping, mapping. If you need a very complicated fee formator with some processing, you do it in your build method. You are free and at the end, when you are finished, you just have to call the pattern and map. Very easy, very straightforward and error-proof. When I say no back-development code, of course I'm not saying we need less back-developer. It's because we love back-developers and we want to reduce that. We are very sad to see on every project, the back-developer spending hours and hours and hours and days sometimes doing the glue, you know, this glue, the glue between the design and the back. Ah, the back has changed. There is a new content type. Let's do the preprocess, let's do the template suggestion. Sometimes I help other projects and I see preprocesses of dozen of lines, hundred of lines, it's totally crazy. So what we want to do is we want the back-developer to stop doing this crazy work and to stop doing this low-value glue. We want to use them for interesting stuff like the configurable plugins, cleaner code, powerful API, consumption and also creation, technical challenges, something very deep and something very, with a lot of value. So this is the overview of a page which is fully built with USWIT. I repeat, zero line of PHP code. Only YAML and refile. Here you have many stuff, you have some block, some nodes, some media and you have a lot of patterns, layout, styles, you have everything and it works. It works. You can build a full website like that and using only the custom PHP code for very technical specific plugins. Thank you Pierre. So now let's finish with all the implementations we've done to date and our needs regarding this initiative. So we started like, I think today is like the third anniversary of the beginning of USWIT. So the first thing we wanted to do is doing a proof of concept of the approach. So the first thing we implemented three years ago was Bootstrap 4 implementation which validated the approach and it was working. And then Pierre started using the whole suite for all his clients. So he started with LVMH. So there is a design system, custom design system implementation. So these are all private ones. It's not like public design system. So the first one was LVMH which is you built a design system and it's used on Drupal factory or website. For internal website, corporate. So you did it also for Sephora. And at that time we were working in the same company and the third guy which is here, Greenripper, started using it mainly on all these projects. And he used it on a studio which is a digital training company. And he also used it on Aircalin which is a, I don't know how to say it in French, it's like an airplane company for public organizations also. And there is a third guy which is not at Prague right now whose nickname is Duel FR who is a strong user of UI patterns and he also started to use the whole suite. So. Yeah, yeah, this is only UI suite implementation because UI pattern is way more successful than only UI suite. And you have a lot of UI pattern projects in the world which is not using the other UI suite. Actually we have like 3,000 installation for these modules, that's right. So, this was private implementation but we also wanted to implement public design system so that we can provide themes to the community to use the UI suite and to be able to build website without producing much code. And it is a way for us also to test all the ecosystem, all the modules, find bugs, et cetera. So, today we have five implementations which are available on Drupal.org. So we did it for Bootstrap 5, Material Design 2, Zelp Foundation, Mozilla Protocol and the DSFR which is the design system for French public organization. Not production ready yet but already very interesting. Tywin is a bit special because as you may know, Tywin is a style only design system. There is no component as far as I know. So, if you want to add Tywin here, it will be zero component, 200 styles. We can do it, it may be interesting but it is not on our scope yet. And so, today we need help. So, you can help us by doing many stuffs. So you can first try all the suite of the modules like the themes implementations. You can join us and contribute to the full ecosystem. We need help also to publish UI suite demo profiles. The goal here is to have a technical solution so that it's easy to test and install the whole suite with Drupal. You can help us also to expand the ecosystem. So, we have many ideas. And also implement new design system. So, that's how you can help us if you want. And you are welcome. You are welcome, more than welcome. And we have a small surprise. So, we did work during these past days. And Florent, Green Ripper here, has done a new release for UI patterns. And we wanted to try it, to try to release it live. Let's try it. Let's try it. Yeah, let's try it. It's very important because it was more than two years without a release. And some member of the community started to worry, saying what's happening with UI pattern module. No, don't worry, we are still here and we have a lot of things to, we want to do soon in the roadmap. I know, you are not logged because I changed. It's okay, I'm sorry, I'm sorry. You can do it, you can do it, yes. So, go back to the slide and at the end we will see the release. F11. So, this is the last slide. We wanted to present all the people who are working on the initiative. So, this is Pierre, me. There is Florent, who is a very active contributor of the suite. There is also Edouard, who is using UI suite like heavily. There is also Théodore, which is a member of the core team. He's following us since the beginning. And also there is a new guide, team deals from Calibrate, who is working on UI patterns with us today. And we have also a Slack channel you can join. We started it like two months ago. There are already 50 people in it. And it's a way for us to... Today we have 50 people more. Maybe, we don't know. And of course you have a page which presents the project, like a placeholder page. There is no bundle to install the whole suite, but it's like a placeholder which explains everything about the UI suite. And of course, we are in Prague. If you want to talk with us, drink beers, you are again more than welcome. We are very available. We are here today and tomorrow. We can answer any question. We can provide any help if you are already user of those modules. Don't hesitate. Thank you everyone. Thanks to the whole organization. It's released, no? I'm sorry. UI, UI. No, it's UI2. Yeah, where is UI2? It's on the top. Released. Thank you, Florian. Thank you a lot. So maybe one of you will be the first user of UI pattern 1.3. Yeah. So the one limitation seems to be from UI patterns that we cannot constrain the type really because it's just more for information and not really a technical constraint. So it means that whenever we use it as a plugin in the UI, there's no limitation which UI pattern we can choose. So we can choose one that doesn't really fit. So we choose a pattern that the parameters have a different type than we would send to it and then we run into a problem and we cannot tell the user that this is not allowed. Yes, but it's not a limitation, it's a feature. No, that's why we have a field and settings. It's something you want to control. You have an enumeration of value, you have a Boolean, you have an integer with limitation with settings. You are controlling it and you can expose a form to ensure your cylinder will use the right value. Field, it's open, you can inject anything and you are just giving a clue, as you know. And for me, it's a feature, I will tell you why, because you never know what people will do with your pattern. I have an example with a client, a real-world example. We did two patterns with him, but we did a 40 pattern, but three are important for the story. Card, accordion, slider. And we use the card on the slider and accordion for whatever you want to use it. And one day he asked us, I want a accordion of sliders. Yeah, it was possible, because you never know what you will need to do and you don't want to constrain what the component or accepting. Yes, but then still it would be wrong to send the wrong parameter types to the pattern. There is no wrong parameter types because there is no parameter check. Well, but then the check is happening when it just breaks. Yeah, because, yeah. Okay, I know what you are referring to. It happens sometimes. When you are defining the variable inside the tweak file, most of the time you are defining renderable stuff. It can be unique value, integer, string, or it can be a renderable object or a render array. If you are injecting only this kind of stuff, you have never issue, because the Drupal will print the integer like it will print the render array. But sometimes you are sending a dictionary of value like a key value array. For example, the menu structure, a menu item with text URL below collapsed on this. A menu structure, you will start to loop on this kind of structure and you start to do different behavior according to the key and the value. And at this moment, it can break. If you have a menu and if you want to inject a card into your menu, there is a risk, I know. And maybe it's what you met. Yeah, so, yeah. If you have a slider, you need a list of items, of values, of content things. If you have a accordion, you need a list where each item has a label and a content. And then if you put this in the wrong place, if you use this as a layout, no, it's just a content. Or if you have just a render element and send this to the slider pattern, and then it will do, for instance, we'll use in a render element, you have element properties and element children. And then it will treat the properties like they are markup or like they are content that they really want to show. Fabian, maybe you want to add something? No, I think there's two aspects to this. And I think you're talking past each other because what you're trying to say is that it would be nice if you could give it a type so that as a backend developer, you can restrict the customer or the site builder that then clicks together the content to only restrict certain patterns. And that's not impossible with what you are. Sorry, maybe for the people who don't see me. Yeah, it's not impossible. And I think it would be a nice addition, actually, so that you could say what kind of type it is. And then on the other side, you restrict the available patterns to the types that you define better. Yeah, but that you already have. Like the fields that are available are the fields from the pattern. So then you saw before in the demo, when you select a different pattern, you have different fields that you can then map. And these depend on the pattern. And so therefore the whole form changes depending on the pattern. And I think what you would like to do, I assume, is that you can restrict on the pattern level where you can use it. And this is what you don't want to do. What I don't want to do, not in a straightforward way. Maybe there is a way of doing that carefully, but limiting is so sad, you know. Because as a front developer, you just do your front and you don't know what will be injected to your front. And that's beautiful. Me, it's more, I'm puzzled about mapping between the data coming from the back and where we plug them in the front, knowing that the different entity that we can meet in Drupal, they have multiple structure of properties. I'm wondering, you need the plugin for any entity. There is a source plugin, a source plugin type pattern who is mapping with defining sources. For example, for a field, the sources are the field properties. It's even more complicated because if you use a field formator, you can use the result of your formator as a one of source. That means you can inject something already formatted. It's very powerful. And you can even inject the field level. But if you use a layout, the sources would be the region of the layout. If you use a view style, the sources would be the part of the views, views rows, the result of the views. So indeed, when we say there is an ecosystem with implementing UI pattern for views, that means we did this source plugin. We did this mapping to make this automatic glue between Drupal API and UI pattern. And that's why once you have this plugin, you can do from back office instead of doing the mapping from code. I think we have an limited time, no? For question, because it's the last... So it's like the last one, unless you're tired. No, I'm not tired. I can stay here all night. Okay, maybe not the same from my end, but I would like to ask a few questions. So really few, but maybe quite important topics. Did you consider the cache topic? And if so, did you expose any way to control cache? We are very lucky with the cache topic because we are using the cache policy, the cache tags, cache context, already provided by the Drupal API we are using. Doing that, it's more efficient in the cache way because you don't need to do all this preprocess and when you are doing preprocess you know, you need to not forget to re-inject the cache tag and cache context related to what you have preprocessed. The only moment when we are doing manually that it's when we are using the render array directly as a return value of a plugin. For example, the view element plugin of the formator or the build, sorry, the view element method of the formator or the build method of a block. At this moment, you need to provide the cache key and cache tag expected because you did the process yourself. But if you do just seed building, automatic mapping, the cache tag and key will be injected automatically and you don't know, by what you used as a source. So second question, did you provide any public documentation for your product? Yeah, you have attempt to provide a very good documentation or on a read the doc, yeah. URI styles and the other option I think not yet, but it will arrive, yeah. So maybe one, yeah, I have a few, but I don't want to take your time much, but do you have any API to extend your product? Like who came to the process? Indeed, URI pattern module is not doing much. There is an ecosystem of 10, 15 module and they are using this API. The first thing you can do is to provide source plugin as I tell you. For example, we have a source plugin for flags. I didn't show, I just talked about that very lightly, but source plugin will understand what is provided by a flag entity and you can map it. And also you can extend with discovery. For example, now every example I told you, it's when Drupal plugins are using the YAML discovery of Drupal, but there is other way of discovery. You can, for example, me, the first year of URI pattern, I was working with Fractal with this competition. It was at the time because it was not as successful, but it was a competition of Storybook and I was using a custom discovery and it was important for Fractal as the patterns. I'm sorry to interrupt. The wrap-up ceremony started, so... Okay, let's go.