Next Generation ECA - Vision and Progress update

This talk provides an in-depth overview of the Enhanced Configurable Actions (ECA) module for Drupal, focusing on improvements in user experience and accessibility. The speaker discusses how the development process centered around understanding user pain points, especially for non-technical users. Key updates include a new user interface that simplifies model creation and management, as well as the introduction of testing and debugging tools akin to Xdebug, enabling users to visualize the execution of their models step-by-step. The architecture has been decoupled, allowing for greater flexibility and easier integration of other systems. The presentation emphasizes the importance of user-centric design and accessibility standards, underscoring the ambition to make advanced functionality accessible even to those lacking technical expertise.

Yeah, that's awesome. Hey everybody. Hey Aaron. Thanks for being here. It's a great pleasure to give you an insight. Well, the cat is out of the bag already. You saw it some of it in the Driesnote. But I'm still excited to actually show you a little bit more detail on how things happened, what it really does, and how it works, and most importantly, how you can actually

get started using it as of after this presentation. So, a little bit about myself, if you don't know me yet, uh I am the main maintainer, but not the only one of the ECA module and the whole ecosystem around it. Uh I'm coming from Germany. I'm with the Drupal community for almost 19 years by now. I couldn't uh show my hands when Dries was asking for 20

years or more, so I was just honest. Uh and as of very recently, I became a subsystem uh maintainer for Drupal core, responsible for the new admin theme, which used to be called Chin before. Well, it's still called Chin in contrib space, but that goes into Drupal core as of I think 11.4 will be in there, and it in 12, it should become the default for uh

everything, and um Claro will be deprecated by then. Uh my company is a proud Drupal Association certified partner, and I would like to encourage everybody who isn't doing that yet do the same thing, because it's just so important for all of us and the future of Drupal. So, today, uh this is a bit of a journey. We will start with, you know, why and how we've done

all all what we were talking about, and then go through all the components that actually make that work. Uh and I would like to just give you an insight actually on all the steps that we have taken because it is at least for myself, pretty different from how we have done things in the past. So, let's get started, and for us, the most important thing was listening

to the problems that users of ECA actually have. You know, there are more than 16,000 sites out there using ECA, and by the nature of the tool, we have to assume that every single site using it has kind of a very serious reason to do so. So, this is not a fun project. This is actually solving business problems. So, there comes some pretty hefty responsibility, like if

you're doing something like that, you want to get it right, and you don't want to break stuff. Um with all that success in the back of our mind, we still have to be honest and have to admit that getting it to work needs quite of a steep learning curve, right? Uh especially for people who are not that much technical, but more like from the marketing side of

things, or content editors, and you name it. But the the biggest thing that made me start thinking even more about it was when Dries last year in summer started using ECA, playing around with it, and then getting in touch and saying something like, and I'm paraphrasing here, but he said like, "You know, I I I was told that ECA is doing great things, and it's powerful, but

to be honest, I think it's not usable." I said, "Okay, very kind. Thank you." And if you if you know Dries, you know that he didn't say it in these words because he's a very kind person. But he what he was saying is like we all know it's only usable by probably 1% of all the Drupal users. That's exactly those who know exactly how Drupal works and

how complicated it is and you need to know everything about Drupal in the background. And he said that may be fine and getting 16,000 sites on that basis is quite a success. But what if we get the other 99% on ECA as well? And I thought I like that part of the statement, you know? Why shouldn't we do that? So, that's how we get started. And we

collected a document. That document is actually public. If you want to have access, there is a Slack channel with a link to it on Drupal Slack. We collected the pain points that we realized by doing support, talking to users, using it ourselves. We eventually run into those problems as well. Like the empty canvas paradigm. It feels like a little bit like an author of a book. I'm

not one myself, but I've spoken to some of them. They are saying, "I know exactly I would like to publish a book." But getting started is so hard. I have an empty sheet of paper. Writing down the first sentence is the most difficult thing in the world, right? The same thing happens to people in the UI. Then we come to tokens. Tokens are just a nightmare. Should

we even call them tokens? Shouldn't it be variables or something like that? I'm not sure about that one yet. But tokens in itself, which ones are available? What are the properties within the tokens? Going down deep in the tree of each of the tokens, is quite challenging. So, we said, "Okay, those are the pain points, and that's what we have to solve." And how did we go

about that one? So, we didn't just guess. We looked at the real feedback, support requests, issue queues, and community discussions. And then something unexpected happened, and I'm really grateful for it. I got the opportunity to get Emma Hourell. I don't know if she's She's here. She had a great presentation this morning about user experience. She's responsible for UX in Drupal core. And together with uh Christina. And

she's the lead of UX for Drupal CMS. Uh she agreed to work with us on user experience and getting the new UI in good shape. And then there was a second guy who is called Mark Doddsen. Show you the pictures there. Uh Mark works uh with the Canvas team uh with Acquia. He's from Canada, and he's a UX expert as well. And I had days and nights

with the two of them having discussions about, you know, not only well, not at all what's technically possible, but it was all about, you know, we have identified the problems that real users are having. And how are we going about to present technical solutions to them so that the users are happy to use them? And I have to say, you will see that later on, it is

a completely different approach. And I felt really good about it. I have to tell you one of the stories that in a very late stage of the development, uh we built a prototype with all the knowledge that we collected during all those months of discussions. And I showed it to them and they took 2 days and came back and they almost apologized saying like "Oh, we are

so sorry. We have a list which is well, maybe 20 items Mhm. that need to be changed, we think. Um we don't want to say it's bad, but you know, the list is not short." And I said, "Oh, don't worry at all. This is exactly what we were asking for. Uh come on and show what it is." And it was really tiny things, really really tiny things.

We went through discussed them and I said, "Okay, we're going to deal with it." It took just maybe a day until it was implemented. recognizing the effect that it had on the product was amazing. It was little things like we just had too many icons in the toolbar. I thought, "Well, it's great. We have so many features." And Mark said, "Yeah, we don't take them away entirely.

We just make the toolbar smaller, better organized, uh use the right labels, take away stuff where people don't expect it. And the things that are not used very often, we just collect in a in a menu which is uh behind the three dots." And tiny things like that. And to me, as a purely technical person, when I saw the result of those tweaks, it was just impressive

to see how much of a difference that makes. And I've done software development for many many years. This is the first time that we really started from the user perspective and did it that way and not from a technical angle. I wish we would have done that much earlier, to be honest. But the good news is we are seeing a lot of changes today. And you saw

some of them already. ECA itself, if you happen to use it already, it hasn't changed. What we've done is changing stuff in the UI. And I'm saying this is good news because it means you can update to the latest version without taking any risk that something that you already have in place will would actually break. It won't. I feel absolutely confident about that. We have put extra

stuff into ECA because there is debugging, there is logging, and so on and so forth, but that is completely separate, isolated services that are not in touch with anything that was there before. So, that feels really, really great. And what's even better, I think, with the new modeler, there is no migration required. All the existing ECA models that you have, they just work with the new modeler.

And you can go even further, you can edit one of your models with BPMN in the and with the new modeler in the afternoon. You know, it's the format of the config entities has not changed, and it will not change moving forward. So, the only thing that does change is the presentation to the user who is sitting in front of the screen. It's completely isolated from each

other. Talking about that is talking about the architecture of the solution. And I have to start with that actually was kind of invented 12 months ago down in Atlanta last year DrupalCon. Chris, you and I, we had so many discussions about it, and we really dragged it down to the tiny bits on how we going to architect the thing. And the dream was, and we made that

a reality that we now have a modeler API and that happened already last year is a bridge between the back end processing which we call the model owner on the left and we have the modeler which is the UI on the right and those two building blocks don't know each other not at all right It is very hard to get your grips around that and to understand

how to actually do that so that for example the UI for ECA is done by the same piece of but looks different as if there is an AI agent for an agent from AI to be modeled which uses different components to represent a tool or an event or a condition but the software who is doing the job is exactly the same thing Now the fact that we

have done that last year and that was quite a big undertaking to uh decouple things in that way to 100% but that was actually the requirement that we can now build the the new UI without having to change the model owner which is ECA what we do have is uh three layers like three different audiences and in the release note we just left out the developers uh

but in this context I would like to mention them as well so first of all we have something for non-technical users and why we do have that I touch on that in a second but then we have the technical users in mind because they can already use the older UI for ECA, but even for them we wanted to make it easier but because we knew that there

are challenges and learning curves that we can actually cut corners and make that easier for them as But people want to extend or manipulate or alter stuff that we deliver anyway, so you can also have an API to tweak the modeler as it comes out of the box. So, let's go through all three of them uh real quick. And I want to start with the non-technical users.

for a long time, what we had in mind was the UI, like BPMN or now the React Flow should become more intuitive, should become more modern, uh should have more widgets and help users to get the job done. But in our UX discussions, we came to the conclusion that no matter how much effort we put into that exercise, a UI like that will never ever be for

everyone. Like, just take a simple example, there are people on this planet who don't know what a loop might be, right? Well, not in technical terms. But if you want to build workflows in a in a graphically interface, it's pretty helpful to know what a loop is. Now, do we want to teach everybody to learn that? That would be the same as like making everybody a programmer,

to some extent. Uh I remember Randy Fay, I think that was in Barcelona 2 years ago, he said he likes the idea of no code low code, but he asked me to never call that a tool that is non-programming because he said what it is is just another programming language, right? It's not code in the traditional way, but it is coding. And I remember that almost every

day, like when we discussed, how can we bring ECA to more users, ideally 100%? We can't do that with the UI itself, where they build workflows. We have to bring the power of ECA to the front end, where the users already live and breathe. And that's why we came up with the idea to bring it to the place where the user is already using ECA. And that

is the same video that we saw before. So, what we have built is, like, why do we do that with forms? Well, the forms is the most common use case where people want to alter Drupal's behavior. Like, in the past, if you want to change the label of a field, or you want to change the default value, or you want to change the description, or hide the

field, or make it conditional, you had to write code. Not possible for most people, right? Then we came up with ECA, that made it possible for a few more people, and it made it probably a little bit more convenient, and maintenance was easier, and all that kind of stuff. but still, it was not ideal. And now we said, let's bring it to the place, and this is

another example that was not in the trees note this morning, like with a checkbox, you probably probably want to say, if that checkbox is being checked, hide some fields. If it's unchecked, then show those fields again. You can do that, you reload the page, and you can see straight away that that the form is behaving like what the label of the template told you before. What happens

technically at that is the user is just using widgets in place where they already are without leaving that page whatsoever. What's happening in the background is when they hit save in that little widget it creates a ECA config entity in the background for you. Right? So, the result of what comes out of this process is exactly the same as if a developer were using the ECA UI

interface. Like you can't tell the difference afterwards. So, where do those templates come from? Well, those templates are ECA models that everybody here in the room can build. And there's just a property that says, "I'm not a model that should be executed. I'm a model that wants to be a template for scenarios like this." Now, we've implemented that for forms at the moment only. Uh why? Well,

just because it's very easy with forms. Uh just focus on a field. Uh then we know what should which of the templates applies to which field. Uh so, we can make those available that are meaningful for that context where the user currently uh behaves, right? We want to bring that to more areas, if not all areas of Drupal. Like imagine you are navigating your site, you are

configuring your site, you are building a site, you are creating content types, you are defining uh user roles, permissions, and all that stuff. And imagine you find that little blue bold icon almost everywhere like saying, "If somebody comes to this page, I would like to just show a call to action button if there is sunshine out there." Or whatever conditions you want to take into place there.

And all of that happens without ever leaving the context where the user is actually working. They don't even need to know what ECA is or that ECA exists. It's just hidden away from them. The the the perception, the idea is that just find new features in the Drupal UI, whether that's back end or front end, that doesn't make a difference. That should be available just everywhere. But

for technical users, we thought, "Okay, it's time to actually overcome the BPMN era." For some reason that I never really understood, I thought, "Why why should that make a difference, right?" BPMN is so well structured. It's a standard that's used globally by different industries. It's something a lot of people are aware of. They know it, and so on and so forth. Could Could there be anything better

than that? And I thought it was just ideal. But I got a lot of pushback from people saying "That looks antiquated, right? I I just It doesn't even come with colors." I thought to myself, "Well, if colors make a difference, then something is wrong." But then I realized what's wrong is my brain. Because this is just how software works, People want to have stuff that looks attractive,

that looks modern. Uh and it took me a while, I have to admit, to understand that this is what we have to do to actually increase the acceptance of that tool. Because this is just what people want. And here is another video of that on how that looks like if you create a new model. And the first thing is we just don't leave you alone. We know

if you start a new model, the first thing you do is give it a name, give it an ID. So, we show the pop-up right away without you having to do that manually. After that, we show you the drop-down of events. Why? Because this is the natural first step to do to select an event with which you want to take want to start your model. Uh and

then, well, the question currently is do we have to zoom in that much or should we just zoom out a bit and show you show you the whole model? That is something we can tweak. We need to learn from the users what they actually prefer. Uh then you can build extra actions, put configurations parameters in it. Um can you see that flow number two? All Everybody who

has used BPMN before, if you have an event and multiple actions following it, you have no idea which one gets executed first. That's a thing of the past. We now have numbers and you can even rearrange things and change the order in which they get executed. And then somebody came along, I think it was Lori. He said, "I don't get the idea why I have to create

an event, then the action, and then go back and apply a condition." I said, "Well, that's just because the condition sits on the edge between the two nodes." And he said, "Yeah, that might be correct technically, but my brain works differently. My brain says, 'If a user logs in, no, a user logs in, that's the event, and if the user has a specific role, then I want

to execute a specific action. So, he says, "For a regular user, it's important that they can define the model in that sequence how their brain works." I said, "Okay, that's a challenge, but I have to accept because, you know, we want to be user-focused. that way we built what you just saw in the video, that you create event, you can then select a condition. And because we

need something where that edge actually is targeting at, we are creating a placeholder action. Um and if you would want to save the model without defining the destination, it would come up with a message saying, "You can't save it. Uh you have to actually fill in that action gap first." But there is more. Like, did you know that you can create a tool with ECA? What's a

tool? Tools are used in the context of AI. Agents are literally nothing else than a colle- Well, there are some prompt templates in there, and there is a collection of tools that an agent can make use of. Uh another context where tools are very useful is MCP, where potentially outside systems can call a Drupal site if it has an MCP uh entrance point. And that MCP can

make use of tools. And tools can be developed as plugins with PHP. But you can now create tools also with Create an event which says, "I'm a tool." And you have to declare, and that's already possible in the previous version of ECA. Um and it's really, really powerful because if we don't have to develop tools in code anymore, that's great. But there is a downside to that.

We have to tell the tools what the input arguments are. What's the name of it? What's the data type? What's the label? Is it required? And so on and so forth. Now, that was a problem. Nobody wanted to use that, not even technical users. What we've done now is creating a widget for that UI, which understands the data structure from the config schema in the And instead

of asking you to write YAML definition on, you know, my first argument needs to be an article node and the second one a user account. Our UI is now taking that schema definition and turns that into a widget, which offers you access to all the data types available on your Drupal site. You get a drop down for that. You can give it a label. You can add

extra arguments. You can give it descriptions. Everything that a tool requires. And when you are done, you can then even go, and I'm not sure if we leave that actually in there, but you can go back to the YAML uh layer. Very much like webform does Like in webform, you have a UI where you can create the sequence of fields that you have with all the widget

selection and the default arguments and everything. But you can switch to a YAML source code mode as well. Actually, I find that very useful because that allows me to copy and paste. I'm much faster using that for certain circumstances. And that's what we have built there. So, I'm emphasizing on that one simply because I think it is a nice showcase on what's possible if we actually own

the UI. With BPMN, we were using a third-party library and the possibilities were fairly limited on what we can tweak. Now we have a UI that we have built from scratch and we can build into that whatever we want. So, you know, the sky is the limit. But, the next one is probably the most wanted and the most useful improvement that everybody who used ECA in the

past has been waiting for. And that's about testing and debugging. Imagine you have a model which responds to a user login and does certain things. And you have built it and it almost works, but something doesn't. Now you can click the test button. ECA in the background waits until that event gets dispatched. A user may log in and ECA was just waiting for it, loading all the

data that it collected during that event. It shows you a step-by-step uh replay list and it automatically goes through each of those steps, highlights the elements in your uh canvas. And it also shows you the step data, which is there in the middle where the mouse is currently navigating, and shows you all the tokens with all the trees, so with all the levels of properties underneath, at

every single step during processing that model. Which means, I call that an for the PHP programmers uh in the room, that's what I call the Xdebug in our UI, You can see everything that's going on and you have access to it. And if you didn't know how the token is really called that you need in one of your config fields, go through the steps, find the right

token, and drag it into your config field. You don't even have to remember the token syntax anymore. We are not showing the token syntax at all. It's just there. There is a layer where you can get access to it. You can edit it. You can tweak it. You can do whatever you like. But for the normal use case, this is just happening for you. Talking of tokens,

that's actually what I um just mentioned. But there is an extra thing. I have showed you now how the recording works in a test environment. But imagine in this scenario, it was easy to simulate that situation to get the recorded data. Like you have a second window, you do the login. Uh you can wait for that to happen, and then it loads the data, and you can

see what was going on. But there are scenarios where you have to debug something where you don't definitely know when something is happening, and you still want to go back into your model and do a debugging session. That is possible as well. You can turn on debugging mode, and by then, ECA is recording everything it does for every event that is configured for your Drupal site. This

is, for example, useful. Imagine you have an e-commerce and you have defined a lot of rules that if payment for an order comes in, you want to probably assign a role to a user who purchased something. And it works, but not completely correct, right? Now, that recording feature allows you to go back and say, "Look, there was a purchase. It was completed, but the role wasn't assigned.

Open your model, load all the history data, go to that one that you want to debug. You It shows you like it happened last week Sunday. It was the user account XYZ. You load that data, walk through, find the find the bug, solve it, save it, and you are done. I recommend turning off that debug mode in production whenever possible because you can imagine there is quite

a lot of data collection going on in the background. But we have optimized that to an extent where it's almost not noticeable. But still your database can grow grow very quickly. So just a few highlights to mention. We have flow filtering. Like for example, imagine you have five events all doing certain stuff. That can become overwhelming a bit. You can just filter out and say, "I want

to work on that flow now and just hide all the others." There is export functionality. We always had things like export as a recipe or as an archive. You can now export as a JSON or as an SVG as well just right out of Why you want to export as JSON, I come back to that in a minute. But I would like to emphasize that we now

also have things like context and dependencies. What is it? Context a new plugin which allows us and you to define things form context means we can identify all the events, all the actions, and all the conditions that have to do with forms. If then the user is saying, "I want to work in the form context, they only get drop-downs containing those elements and nothing else. Much less

confusing and much easier to navigate through the UI. And we want to define more contexts like that. That's not an easy task, you know, it means like we have to go through over a thousand plugins and make collections and define where do they belong. And I can I want to invite everybody who just wants to go through that with us. Um this is an exercise that is

probably never finished, but we should get started at some point. It's a bit like documentation. This is a moving target. Um but it's really really helpful. And dependencies is related to Like if you start with a build form why should we then show the action plugin that creates uh output data for a tool, for example? That's just not usable in that context. Now we have a mechanism

to define such dependencies, which allows us then to reduce friction for the user again by only showing them stuff that is currently useful where they uh currently are. What we also have is a fine-grained permission system, so almost every feature in the UI is driven by a uh permission itself. So you can define user roles that should be able to define models, but you probably don't want

to give them access to all the features and by that can you can simplify the uh UI and look and feel yet again. But let's go back to the in-context scenario that we saw before, because that was the one for the non-technical users, but it brings something for the technical users as well. and when I showed what we have there to my colleagues, and they have built

enormous models in the past. And immediately they said, "You know what? Even for us, the in-context usage of templates would have been so helpful because very often it took us quite some time to find out what is the form ID, what's the name of the field that we want to tweak, and so on and so forth. Getting started with templates probably only delivers 80% of the way

there. But it's a fantastic starting point, and I can focus on the remaining 20%, and that is what we have done as well. So, uh our well-known form. We click on the uh widget, we see all the templates that are applied to that field. But now we go to the name uh of the user in that form, and instead of applying a template, we are saying for

that field in that form, we want to build something in the model. So, we are opening the UI. It realized that it comes from a form context, automatically selected that. Only very limited numbers of events are available. It places the event, and it auto-fills because it carried that forward from the context where it came from. And it does the same thing with uh the name of the

field. But there is more. I call it like ECA is smart enough to know that it was involved in building that site, and it now exposes that with an icon at the bottom right corner. And that means you can just from that page, you know, I see that form, and I know it's tweaked, but I can't remember which model was it. It just shows a list of

events that it just used when processing that page request. You can go into that and not only does it load the right model, it hides all the other events in that model, that is that filtering of flows. And it also loads the data that has been processed during processing that page and you can immediately start debugging that. And this is such a powerful tool that I think

just for that it would be reason enough to actually switch over from the old UI. But then there was another thing called accessibility. And that was quite a limitation for us in the past because the BPMN Modeler and we spoke to the developers and they know that they need to do something about it, but they just didn't know exactly how to go about it. And we said

this time round we want to make it a requirement from day one, right from the beginning. So all of it is WCAG AA compliant. We are testing that in light mode and dark mode, so that delivers the message that there is a dark mode as well. I'm a huge fan of that. It's fully keyboard controllable, so the whole navigation through the UI can be done with the

keyboard. It works together with screen readers. There is high contrast and everything. We use Xcode to test that with every merge request. Maybe looking into the budget of the D8, they may want to call us to reduce the number of pipelines that we're going to run. Could well be that not for every commit that we're going to do that, but we will do that for at least

before we're going to release a new version. Um this is really, really very important. And if I say it's compliant, I'm basing that statement on the results of the tests, knowing quite well that this is not enough to call it accessible. So, is it perfect? Most likely not. But I believe we are very close. And if there is anything that needs to be improved, let us know

and we're going to fix that. It will be possible very, very quickly. It's not a big deal. So, what's in it for developers? Well, talking about uh plugin APIs, we already are aware of the plugins in ECA, which are for events, conditions, and actions. Um the modeler API has five plugin managers itself. Uh it used to have last year uh plugin manager for model owners, i.e. ECA.

And it has a plugin manager for modelers like BPMN or now the workflow modeler on React Flow. But it comes with uh three more, which is about context, dependency, and template tokens. So, there are special tokens for templates so that uh we can determine which template applies to what Uh and the whole test replay and debug framework is driven by the modeler API as well. So, we

have abstracted all of those tools away from ECA, put it into modeler API, which means if other frameworks came along, uh they can just plug into modeler API and make use of all those API APIs themselves as But there is also an API on the modeler side of things. Like imagine you want to extend the functionality of the UI, uh you can add uh icons to the

toolbar. You can even add your own panel into the And the question is, why would somebody want to do that? Well, I have three use cases with one piece of technology, and that leads me to the statement that for everything we saw so far, there is no AI functionality involved whatsoever to this point. However, there is great use cases where we want to leverage AI functionality, and

that is where we need an extra panel in the modeler. But that comes with a separate module. Meaning that it's totally optional. If you just want to use the modeler, that's fine. If you want to use AI within the modeler as well, install the extra What What are the use cases where we could use uh AI? Imagine you are sitting in front of a model, and you

just don't know who built it, and you don't know what it does. How about asking the agent in the UI, "Can you explain what the model does?" That's an easy task for any agent. You know, we already have one. We've just not integrated it yet, but it will be very, very easy. The second use case is like, you are sitting in front of your model again, and

you have something already, but you want to go one step further. But you just don't know which is the right component to use. Asking the agent, saying like, "This is what I want to do. Can you help me find the right event for that one?" Easy one for for an agent. And the third use case is like, you could even go further and tell the agent, "Look,

this is what I want to do. Build that part of the model for me." Lay it out, show it me in the canvas, and then you can go through step-by-step, tweak it, understand it, learn from it, and so on and so forth. So, that's why we have built uh the APIs that it can be extended. And we thought, "Well, why not using the same piece of JavaScript,

which is this It is essentially uh and create a standalone viewer out of it." And that's what we've done. There is a bundle that you can embed in a website. And we've done that for the ECA guide already. So, where you saw BPMN uh diagrams in the documentation, you can now find the uh React Flow Modeler. It doesn't require Drupal site in the background. It just loads

the JSON data that I explained previously, which is one of the new export formats. So, you can build models, you can export them as JSON, and then take it together with the standalone modeler, and embed that in any HTML page that you like. Why would you want to do that? Documentation, presentation to clients, and other stuff, right? Training material, for example, could be a use case as

well. And it's not just a viewer, it even allows interaction with it. It even comes with replay data, so you can show the flow, what's happening, and show the tokens that are available. That means the JSON data that was exported is a little bit larger. That could easily be four to five megabytes in some scenarios, but who cares? It is very, very quick nowadays. So, how did

we do all that? Well, as I mentioned in the DriesNote, that took us about 3 years of thinking. proposed that solution 3 years ago. Um we haven't been selected to be funded for that idea. And today I have to say I have to be grateful for that because the 3 years of thinking have been very helpful to get it right this time. I'm pretty sure about that.

talking about the numbers, yes, it really only took 6 weeks to build that. I originally started with the ambition to build a prototype and realizing within a few hours that this is getting us really, really far. So, we started over, throw away the prototype, did the proper architecture, proper instructions, proper breakdown, refactoring three or four times, and we have built an enterprise-ready product. At least that is

what all the code reviews are telling us. Uh there are different scoring systems, and there is a score 97 out of 100. Uh so, every tool that we used is coming up with the same kind of feedback. So, yeah, go ahead, use it. It is ready, and it doesn't break your site. And there is a lot of documentation as There has been the ECA guide already before.

Um I think that was a good thing already, but there have been gaps. There have been huge gaps. Like it was listing all the events that are available. It was listing all the uh parameters that were available with each of the events and the actions, but nothing more than that. What What done now is we collected all the information that we could find from Drupal core's API

declarations, extracted that, and put that into the ECA guide as well. So, if you now open up the documentation, and by the way, you can do that from within the new UI, so you don't have to go to ECA guide.org anymore. The documentation loads in the UI, so you don't get distracted there, either. its own documentation page for Modeler API, which in itself is 25-30 pages. This

is very developer focused, because this is API but there is an end-user documentation for the Modeler as well, which is pretty comprehensive as well, including mouse gestures, key keyboard shortcuts, and everything. You know, it tells you everything how to use that thing. But for me, as an engineer, as an architect for software, code quality matters a lot, because it's on us to maintain that thing, and that's

only possible if the foundation is right. there are a lot of tests. We are using Jest for unit tests. There are more than 3,600 with 5 and 1/2 thousand assertions. There is zero tolerance on 15 pipeline tasks, so we don't accept errors anywhere, but we don't even accept warnings. All the code is green everywhere, and we can't actually merge if that's not the case. What's interesting, as

well, I think, is we were talking about 90,000 lines of code, which is a lot, but there is a relation between test and production code, which is 1.9 to 1. So, 2/3 of the code is tests, right? So, real executable code is just 30,000. That's not so impressive anymore. but I'm really happy with the test environment that we have built for all of this. We also do

have end-to-end tests. So, we use Playwright a lot for almost everything. So, we have scenarios where the test goes through and behaves like a user. Check it uses all the drop-downs, all the buttons, all the widgets that are available in the UI, plays with them, knows what should be displayed if doing this and that, and it tests all of that as well as accessibility tests, as I

mentioned Uh and we are using Storybook for that. So, all the components that we have in are defined in Storybooks. That's nice to just look at them, but it's even better to to use them for XCode tests automatically as well. PHP stand for the PHP part, and the whole TypeScript is defined in strict. and I said before as I said before, this is production ready. It's tested.

It's documented. but it's open for contributions. It's not done, right? What are the areas where we are looking for help? First, defining context. I mentioned that before. This is an intellectual task where we have to go through all the stuff and everything we know about Drupal and just make the right definitions. Uh this can be a boring task, but it's very rewarding as well. So, if you

feel uh qualified for that, just let me know and we can find ways to get you involved in in that stuff. The same applies to uh dependencies. And then the in-place customization feature, uh what we have seen is just the tip of the iceberg. I believe there is huge potential in that in turning things around. I would like to put it that way that when we started

this development, we had no idea that something like that would come up. And I believe we have built something that most of us have never thought about ever before, like bringing feature templates or widgets into everything Drupal for users just to pick and choose, and off you go. Now, knowing that something like that is possible with technology that we already have at at our fingertips should make

us go back and think hard, what are the next steps on how we want to leverage these possibilities. Let's think together out of the box. You know, we don't want to repeat everything that's already there somewhere. We want to come up with new ways of making powerful technology available to everybody without having to make them experts first because that's never going to happen. great places like the

Drupal Slack channel, we have issue queues. We are here in person. I'm here, just grab me anywhere I'm country space. But, the fact that I'm saying this thing is production ready, I actually want to prove that. And how am I going to do We're going to tag 1.0 just now, right? So, I've written release notes for that And I've already created the tag on a GitLab. And

here is the project page. And we can scroll through and you can see we even wrote some meaningful project pages for this as well and for the other modules as well too. And now I have to find my mouse. Yeah, there you go. Now we add a new release. Thank God the Wi-Fi is working. AND THERE WE GO. I HOPE YOU WITNESSED SOMETHING of real significance for

Drupal and all of our businesses going forward. So, as we are running out of time, I just quickly want to finish off by showing you the links. There is a lot you can refer to. You don't have to remember them. Just remember the first one, go lakedrops.com ECA-Chicago-2026. That gives you access to this presentation, that's HTML file. And that gives you access to all the links that

uh you have seen throughout the presentation. Just waiting a second for all the pictures to be taken. And now it's time for Q&A if there is time left. I don't know what you are planning for the next one, but there is a QR code. Please provide feedback for the session. That's very helpful, especially for the organizers of the next conference to learn about, you know, what is

what you want to hear on conferences like this. Thank you very much. And if you have time, I do I stay Chris. how easy is it to create a new node in the modeler, something completely different than the condition, action, event? You mean a different type of node? Yeah. Uh very easy, actually. How do I explain that now? Don't need to explain in detail. Very easy, great

answer. Okay. Yeah, we go into detail offline. Next question. How did you have this much better where where are some places that BPMN or other modeler other inferior modelers have been used that you think the new modeler could be used? Uh you mean other use cases than ECA? Correct. Uh I still want to believe that migration is a great use case for that, and Chris is very

interested in that, There is something missing with migration, which would be very helpful if each of the migration tools were actually plugins, which they aren't. They look like plugins, and if you use migration plus, it actually puts some kind of a wrapper around them, and they are plugins, uh but not if you are just using uh Drupal core with migration. Another use case might be uh AI

agents, but there have been other developments uh like flow drop UI for example developed by Shibin and Factorial in We have great discussions together. We almost have weekly meetings with them. And the ambition is to bring the efforts together what they have learned and developed with what we have done over here. And just join forces and build something that can be used in many places. There are

more opportunities like canvas will be extended to become a form builder in the future. So Acquia is currently working on that. Embedding the modeler with ECA into that is something they are very interested in. And we are also talking about think about data modeling in Drupal like defining entities, defining fields, field types and so on and so forth. It's something that can be done with that framework

as well. And we are talking with Christina and Emma who are responsible for the whole UX around To see if that makes sense and how we should approach that. How far are we from the front modeling? Wow. I don't know. I haven't thought about But let's do that. Good idea. More questions? I have one. Yeah. And this there is somewhat of a contrib space around ECA something

like the ECA flag module which I know you worked on. Is that still compatible with the new modeler or It is 100% yeah. Nothing changed there. There are almost 100 contrib modules that are extending the ecosystem of ECA. Okay. Yeah. All right. Thank you. All right. Thank you everybody. Have a good trip back home.