We'll explain how to implement a government design system in problem six, explaining the New South Wales Government Case Study. Thank you. Hello. Do you want to say? No. Okay. So my name's Dylan Jay. I am the CTO founder, one of the founders of PredaGov. This is Jeff Bledsoe, who is a front-end developer, but we're all a bit all around

within our company. And what we're going to do is, Jeff will, he's going to deal with the technical parts, and I'm going to talk about the UX and some of these sort of ideas.

And what this talk is about is, I think we decided last night, it's really about bringing your own HTML. This is the big sort of thing that we're talking about. This is like a theming experience when you are forced to use someone else's HTML. And, okay, so a little bit about PredaGov.

If you don't know, we have been around a long time. I should know the date. I don't know. Sometimes in the 2000s. Oh, there we go. 18 years of experience. There you go. Our markets are mainly UK, Australia, and some European clients.

I forgot. We do have some Thai clients, so I didn't include that. Right, so the first thing I think I wanted to get across is you've heard design systems talked about in a few other slides, and I think it's not something that's been explained kind of well, so I want to go over that a little bit in case you're unfamiliar.

How many people have a good understanding? I think they know what a design system is. Okay. Okay, cool. Not that many. Okay. So I think the best example that most people might know would be material design. If you know anything about mobile development, this is the design system that Google puts out in order that you will make an app that looks like another Android app.

And the things that are in a design system are, this site is really cool, by the way. It's called Component Gallery. So it has lots and lots of design systems. But you have a design system could be Figma, it could be just the design.

It's generally not. Generally it will come with HTML, CSS, often it comes with a dynamic implementation like React or Vue or something, but it's much more than that. It also includes, you can see here they talk about user voice, you know, so how your content should sound. It comes with guidance about how you should and shouldn't use the components.

That is what a design system is. It is much more than just a bunch of components. So Pasta Naga is a design system. That's the design system that is used in Volto to create the Volto editing UI.

Quanta, the future UX for Volto is a design system. But, oh, and, yeah, so components are a very important part of design systems. So this is an example from Component Gallery where you can see what a card is

and then you can see all the examples of the different cards from the different design systems, which is quite cool. So I did look up a definition of a design system. That's not very useful, but generally I think for us as Plone people,

it's a theme in a way, right? But it's a theme normally designed for distributed teams where you have lots of different people within a large organization that need to end up with a consistent user experience. So it makes sense for, you know, you saw Decathlon before and big organizations, but governments especially

because they have lots and lots of websites, lots of people building them, and they should all look the same. The customer experience should look the same. So, yeah, distributed teams and enhancing branding is one thing. The consistent UX I think I talked about

and also that content voice thing about, like, not just looking and feeling the same but also sounding the same. And also the accessibility, particularly with the government stuff. So what we get by inheriting this government design system is that's already been accessibility tested.

So I guess I've already answered why design systems are good. We work with both the UK government and the Australian government. So the UK government I think came out with their design system first.

Both governments are kind of working in a very similar way. And you can see they say exactly that, right? It's all about having this consistent user experience. So I think this is an example from the New Swells design system documentation.

And I think this really highlights what I'm saying here is that it's about guidance, not just, oh, here's a component, right? It's saying you should use this in these things, right? Like, so cards should... When I say, like, you know, it should have one piece of information. If you've got multiple links, if you are trying to say too many things

then use this other component instead. So that introduces, I think, the New Swells design system. And again, they're sort of saying, okay, so who should use it? You know, anyone who wants to make it consistent. And I think in this case it comes with the Figma.

It comes with React components. It does come with a Drupal implementation which is their reference implementation. And there's a few other systems including the Plone 6 one which we created. So this is what it looks like in Volta.

So that's the design system. So who are the users of a design system? If you think about something like material design system, the users of that design system are mostly developers, right?

The components are all meant to be put into an application and the end users who are using that end application don't really care about the design system. They don't have to make decisions about it. They don't have to know about the guidance. So Pasta Naga is another example of a design system that really is only used by developers, I think.

Whereas something like the New Swells digital design system is a little more complicated because half of that guidance is about how users of the CMS are going to actually implement and put things on pages. And I think that's quite a big distinction. So our job, and that's what this is really about,

is how do we implement a system that lets people do that in a way that doesn't violate the rules and the guidance and so on, and make that super easy. So really, in this case, developers are half

the users of the design system. And so logos, footers, things like that that are sort of baked into the design. And then a whole bunch of other things are going to be things that the user picks. And that matches really well with the way Volto works with the components and so on. And you can see this is a whole lot of the components

that the New Swells design system comes from. And you can see there's a whole bunch of things that are going to be, you know, things like dialogues are going to be developer picked, whereas cards and list items, maybe not list items, but, you know, banners, hero banners would be something that would be a CMS-type component.

So who are the users of a CMS? Well, I think CMS is a very interesting, weird software in that you kind of have two sets of users, right? You have editors, the people using the CMS to create content, and you have developers and integrators. Another way to think about it is, really, there is just one user,

because we as an integrator, right, we're taking the tools that we have, which is Plone, we're taking the design system, and we are creating a new system, which is a custom system for our clients. Each client gets a custom system. I think Guido said this really nicely in his talk a little bit earlier.

And the thing is that we definitely want to make it as easy to use for our users, but in doing so, that is also helping us, because we get less support requests, we get happier customers, we get repeat business, et cetera, et cetera. So in some ways,

the integrators are maybe the real users. So what makes a good CMS for an integrator, right? So if, in this example, again, I'm sort of talking about bringing your own HTML, you want something that's quick to theme, that's cheap, because, you know, time is money.

Even if it's you're charging the customers time and materials, you won't win the contract if the thing is very expensive to implement. Easy to maintain, right? There's this hidden cost of, you know, upgrades and things like that. If you want to bring in new features of Alto and stuff, easy to use, less support like I talked about,

and compliant, particularly for the government stuff, like WCAG and so on. So is Plone a good choice for a design system? So it really kind of... Actually, when you think about it, I think we have three choices now.

We have three kinds of Plone. Or if you count Nick and other things, maybe you've got more. But I'm going to talk about three different choices. So, and I'm going to look at it from these different perspectives. So Plone Classic. When I'm talking about Plone Classic here, I'm talking about Diaso, which I think is still the best solution if you're bringing your own HTML.

I know not everyone did that, but we certainly did that, and that it was cheaper to build. I put it as, yeah, I put two ticks, so this is all, like, relative to each other. It's not, I'm not saying this is a, you know, it counts. I'm only comparing them against each other.

So, okay, so Diaso, when you got your own HTML, was cheaper to build. It was slow run. In particular, it was very easy to create rules that would be bad for performance. The upgrade cost, you know, kind of medium. It was, it's very unlikely that the base HTML would change.

And the editor UX in comparison to, say, Volto, was much worse, right? I don't, anyway. So then you've got Plone Volto, right? So Plone Volto is, I think, a really good editing experience.

Absolutely, there are plenty of UX things that can be improved and stuff, but the idea of true WYSIWYG, where you are editing straight and line and just, like, you know, I'm using content, using it to build our websites, like, it's so much quicker and easier to get content out. The build cost is not so good,

and we're gonna go into that, or at least for our case, where you bring your own HTML. And that's what the question mark means. It really does depend a little bit on your use case, and Volto was made to kind of be themed using CSS and the variables and so on like that. That's obviously gonna be a lot cheaper.

The upgrade cost also not so good, and I'll talk about that a bit later. And the speed is kind of medium. It could definitely be faster partly because of the bundle size. Maybe we haven't learned how to cut out some of the stuff in the front end, but it brings a lot of the CMS in the initial page load, which is, what, a megabyte of JavaScript?

Yeah, fair enough. So then the third option, which is something we didn't really consider and probably should have, is a headless option, right? And by headless, what I'm saying is you would have a generic Volto editor. You would use that, and then you would build your front end as a completely separate thing,

and you lose your WYSIWYG editing, but you've got two different implementations. So it means you can build the whole thing in Vue or Svelte or whatever you want as the Vue side, and you just use Volto as an editor with no customization other than perhaps making sure you have the right sort of similarish components, right?

Your card will work like a card in one way. So it's still a medium build because you will have to make sure that you've got the right components and so on, and they will have to work in the same way. Your upgrade cost is better because you're decoupled. Your page speed is gonna be better because when you're rendering the site,

you're only rendering exactly. You're not taking the CMS along with it. But your editor UX is definitely gonna be a bit less. Okay, so now we're gonna go a little bit about some of the things that we built. So the first one is listing variations,

one of the more simpler things. So they had a lot of cards. They had content blocks. There's even some we haven't implemented, like buttons and so on. And what we did was, yeah, we had variations. We used the variations system, and we can then show and hide different aspects of it,

and we'll change all of the different ones in one go. This screenshot's a little bit wrong, because it won't let you have multiple cards in the one block. I think I'll show that next. Okay, so, yeah, we also implemented, you know, had sort of search results and so on.

And there's all these things, like, we can put the data in. We can put the tags in. We can choose whether the image is shown and so on. These are all sort of things that are set in the design system. It has to be there, so... We use Elastic. We have been adding some things to the Elastic integration, like we now do the highlight snippets and stuff.

I think that's a PR we... Is it merged, John? Don't know? Okay, but there's a PR for that, and we will be adding some more things later. We had to do things like, yeah, customizing the no-results message. The...

So this is an example of, you know, patching with the cards and so on. And the settings on the side. Okay. So Jeff's gonna talk a little bit about how that worked. Yeah, so I'll start off by saying the code on the screen is just an overview

of what's going on. If you want the full code, you want to dive into yourselves, we'll have the link at the end of the talk. So, anyway, variations, fields, that kind of thing. We're getting Volto's bread and butter. So here we've got an object with...

An object where the key ID is the ID for the block, and the variation ID is nested within that. So in this example, we've got a listing block and the card listing is a variation here. So we're getting the...

As you can see... Getting all the stalling options that are available for cards and appending that to the schema for the listing. We then pass that down in listing view to the children so they're displayed to the cards that are in there.

And additionally, at the end, we add the number of columns specifically for the card example. So, you know, the only pay is for editors that are using the card listing and the other provides a nice seamless UX for them. That's right. That was what I was supposed to say here, right?

Some of these settings on the side, they only apply to certain variations, so this is about sort of hiding and showing different options for different variations, which is reasonably easy in Volto. So card grids. So, not the best name we came up with, but this is the case of, okay, exactly the same cards,

but we want the users to enter the stuff manually, right? It's no longer an automated listing based on a query. It should be entered directly in there. And we actually implemented this a couple of times because we thought of a better way of doing it that enforced the rules.

So the first idea worked a bit like this, which is we took the grid, which was not released, not in core at that point, but we took the grid, and then you have a card or a teaser, and then you place it in there. But the real problem with that is that what we had, we had so many different variations and options,

and if someone changed their mind about, oh, this looks a little bit better without the image, or it looks a bit, they would have to go through every single card and go and change the options for each one to see how it looks. That's not so nice. So then we changed the implementation. So our final idea was much more about the having,

we had two things. We took the settings, the shared settings about what a variation for a card was, and we put it back into the grid. We overrode that and created our own sort of grid. And then when you ticked on those things, it would change all the cards at once. And then what we wanted to do was avoid the use

of having a setting, having any kind of sidebar for each different item, because we thought that would be kind of confusing for the user. So then all the things that were specific to the card had to be inline edit, WYSIWYG. And that was a little bit tricky.

You've got things like links and so on. And the other thing we did is that, okay, so we want the user to be able to switch backwards and forwards and try different things. So if they turn off the images, then the images are still there in the JSON, and if they turn it back on again, they're still there. So that sort of solved the problem of allowing them to sort of switch styles.

So in the end, actually, it works very similar to how the listing block works, which works the same way. Yeah, so as Deda mentioned, we started work on this before the grid block was in core, so we based it on Volta grid block from Kit Concepts.

It allows you to create a custom block type, essentially, and limit which blocks are available into it. So to get the card grid listing, we had a block which only let you insert cards, a similar story for one of our other grid styles, which is...

Content blocks, I think it's called? Yeah, content blocks. So yeah, that block switching works by essentially abusing how Volta stores the type of information for which block is there, and we use the same schema enhancer that I mentioned earlier to add a field with an ID of that type

so that when you switch the value of this field, it essentially changes which block you're currently looking at. But the data for all of those blocks is still stored, and so it essentially changes how it's displayed. Yeah, so to remove the child block cyber-editing,

normally when you create a block in your edit view, you'd have a sidebar portal component within that you'd have the block data form. So by stripping that out, you stop the sidebar displaying any of those settings,

but the form continues to be focused on that side block so you can make all the normal changes and keyboard shortcuts still work, but you're seeing the settings for the parent grid. Obviously without the sidebar, you've then got to implement WYSIWYG for each of the options in there.

So the title fields, it's got to be a single line as we use the textline edit widget at that point. I think Victor had made PR two days prior to us working on this, so it was a bit buggy and took some time to implement, but got there with it eventually.

Description, it's a multi-line field. As you can see here, rich text editing, inserting links, that kind of thing. That's still implemented using draft.js. It'd be great if somebody could change that to Slates. Link editing, again, it was a similar kind of story

of things being inconsistent with Evolto. We didn't have one easy, simple way to say, here's what a link should look like, pop up the link editing experience for it, and so we had to kind of roughly re-implement something. Again, PRs were started after that to solve that story. As we had like the object browser,

but then if you want to enter the thing manually, that's a Slate thing, right? We didn't have that component to use. Similar story for image uploading. We essentially copied the image block and how that works and changed a few things, but I think there's a PR in progress for unifying that story.

And the final bit in magic was just that whenever you change one of the settings in the parent to iterate through all the children and stick those settings onto it too. So when you change, for example, whether to show the highlight or the color of the card on the grid block,

you pass that all down to all the children, it stores it, and then, yeah, box is normal. Okay, so anyone who knows me knows that I have lots of opinions and lots of opinions about UX. So these are my opinions. There's nothing to do with the future of Volto, even though it says the future of Volto.

This is, like, as I imagine it, maybe. So we've got a few of these slides. So one thing that kind of strikes me about this whole thing is that, you know, that grid block, that card block thing where it's changing, it works really nicely. But why have we got two implementations

of the same thing? Why do we have listing blocks? And why do we have editable blocks? It should really be the same implementation. So what I think is that you can take the listing block and you can have manual blocks at the front of it.

And the idea of a repeated block is actually to, instead of making variations on what goes in there, what if we could just pick a block and say we can split the properties between what should go into the sidebar, what's shared, and what is editable in the middle through some kind of configuration or something. So then if you've got, say, a third party,

you know, someone comes out with something that you want to repeat, you know, it's a little bit of configuration to make it repeatable, and then suddenly, boom, it's in your listing, and it's in your manual sort of grid-type setup. So, you know, that could be, you know, cards and teasers and stuff, but it could be, like, tag clouds and could be buttons.

You know, we actually don't have a good button solution at the moment. So... And some people do use buttons and things as sort of very much like teasers. And then you would have, like, yeah, you'd have those shared settings.

You know, whether you show the image similar to what we saw before. You would have a layout, so you could say, okay, is it a grid with how many columns or is it all in the line buttons or is it vertical like a search listing? You would have... I mean, this is the more controversial thing where you actually combine it into the same thing and say, you know, I've got an auto part,

and I want to drag these up, and I want to have manual parts. Do you want to switch between auto and manual? I think... My idea is that I think that it's not always clear to a lot of users how to use listings and introducing it to them in a way that maybe they start with a kind of manual cards

and then kind of go, oh, actually, you know, all these things that are manual, I can actually, like, fill this out, the rest of it, with something that's automatic. So it might be a gentler way to sort of let them know how that works. And then finally, like, we should have more sources for our automatic listings. It could be all sorts of things.

You know, like, we had a requirement the other day to... they wanted to bring LinkedIn feeds into Volto, so we would like to implement that in the listing so that, you know, you can... you don't have to use their embedded thing. You can actually bring the content in and have it appear like news files, digital design system cards.

So that's an idea. We would like to implement that. We may try. Okay, sections. Sections are another thing. So sections, obviously, you know what sections are. They're like, you know, often the full page width kind of thing. Sometimes you want an image behind them. They have a whole bunch of different specifications on how... what you can and can't do with sections.

And this was another tricky one to implement. And again, we tried it a couple of different times. Because there is... it kind of feels like there should be something built into Volto to make sections easier. So our first attempt was a container block, like a section as a container.

And the problem with this is that you don't want to have to use this... The default cases, they're just gonna write down the page. They're just gonna deal with that. And it's like, okay, so they don't have to deal with... They shouldn't have to deal with, like, moving things in and out of containers and knowing that there's a section there. It should just be, you know, default section,

not worry about it. And of course, the drag-and-drop story in and out of containers is not really there. And we really wanted it so that, like, again, so you could switch variations and stuff. You can say, okay, I want to easily sort of say, see what this looks like in a different sort of color

or as a different kind of section. So our second idea was, which we didn't implement with section breaks, where it's like, okay, what if we have, like, a thing in between that you just insert and says this is a section break, and now from now on you're in a next section. So the problem with this is it kind of breaks the WYSIWYG idea, right? Like, you've got something that shouldn't be taking up

any space that's invisible and is also quite thin, you know, and hard to click on that's containing your information about what a section is. So what we ended up with is we used variations on all the blocks. So we said, okay, so if you've got a paragraph,

by default it's just gonna be, like, follow the last paragraph. And every time you want to change a section, you'll go into a block and say, okay, this is now a new section of one of these kinds. And then we did a little bit of magic in the background to put this inside divs and wrap it and so on.

So it did help with that sort of no-effort default use case. It's not that WYSIWYG, right, because it's supposed to be full width, but, you know, in this case there is no full width. There's no representation of how that section is gonna work on the screen, and that's not great.

And possibly it's not the most obvious place to look for how do I create a new section. And also all blocks need this variation to work. So how did this get implemented? So, yeah, as Dylan said, this works essentially

by adding an additional field set with a bunch of data to each block. So at the end of our new WYSIWYG add-on, we iterate through all of the blocks we've got and add another schema enhancer for adding sections to it. We shadow the default view component,

which is essentially what normally would render your blocks. It does mean we have some re-implification to do. For example, if you want to add some block support to an event view, you've got to re-shadow that one as well, but we wanted to really ensure we could use blocks

for whatever we want later. So before rendering, we group the blocks based on a number of rules. For example, if we go through every block and we don't find any sections, then don't do any grouping, proceed to normal rendering.

If we're just about to start a new section, and it's a title block or a slate block with headings applied to it, then we start a new section for that one. As Dylan said, we have this same-as-previous option, so we can continue to just build upon

the previous section without using time to think about it. Then we also add other concepts such as full-width blocks like the hero, which don't need to be wrapped in a section, and content blocks such as your slate block, images, that kind of thing. We also, if we were using sections,

we had some other small changes to the page, such as we had to remove some spacing from the top and the bottom because it's already accounted for in the section implementation. Okay, so again, my opinion... Well, this one's a little bit... This is very much sinuous. I still don't know how to solve this well in Volto,

so if anyone has any ideas. But I think, like, better containers. So if you have the container and container story kind of working well, and you've got the drag-and-drop working between the containers and, you know, cut and paste and so on, that would make it definitely possible.

But I think you also, what you'd need is... Yeah, so then you've got your page, your section block, and then your blocks inside that. And then inside that, again, you've got, you know, things like column blocks and so on. So you kind of... The problem there is then you're going up and down this kind of containment hierarchy and so on,

which is maybe not that intuitive. You have to know to go up in order to set the section settings. And, you know, if you create a, you know, like, let's say you've kind of created a whole page of content, and you want to go, like, this bit here, that should be in a separate section. What you want to do, I think what would be nice

is if you had a split-after command. So let's say you're in the middle of a page. You can say, split the section here, and you can go in and change the settings for the next part, split it again. Maybe you also need a merge. Maybe that might be a nice solution.

Okay, guidance. So the thing that I talked about before is that guidance is what you can... We've done things, like, by design, right, with the way the car grids work, right? There's a rule that says all the car grids in a row or in a module, whatever they say, have to be all the same type, right? So we enforce that via the CMS, by design.

And that's great. And as much as possible, we tried to do that. But there's other times where it's like, you can't do that. So what we did is we implemented an advice system that looked at the content and looked at the arrangement of the blocks and things like that, and popped up little messages to help the user.

Just gonna talk about that. Yeah, so we are still kind of experimenting with this, so we kept it simple and easy to work on. We essentially defined a bunch of regex and rule mappings and passing various fields from the data to that.

So, for example, if there's a new line and you're on the car block, then it will display the warning message. If you've got a paragraph tag and you're in the description, then maybe you want to be using the content block instead, and so it will recommend these things to you. It'd be nice if we could make these a bit more configurable in Volto,

maybe even through the web later. It'd be, yeah, who knows? So, yeah, my future idea, you know, trademark is that we make it configurable through the web. So I think what would be nice, if you extended the concept of content rules, at the moment we have this idea of content rules, and they act only after save on the whole content.

What if you had a mid-edit content rule, right, that said, if you're in the middle of editing and these conditions exist about where the blocks are or regular expressions and so on, then show this warning to help guide the users on creating that. And the really nice thing about that is that, you know,

you can implement these things from the design system, but an organization may evolve and grow and have their own rules and their own things that they want to add as well, or they want to hide rules and say, oh, this is no longer relevant, this is just annoying. So I think that could work. Yeah, that's basically that idea.

So the next idea, slots, like, this is the one we were working on last, I think, so we can't call it slots because slots is still coming, I guess. I don't know. But what we needed was an editable footer, and it was, like, we started out just, you know, creating a footer editing block, and then we realized, well,

actually, we can extend this a little bit. So what it does is it takes a... Yeah, we want it for these different things. Like, we also want it for global alerts and some other things. So you define a slot in the Volto config, and that... So that's done by the designer at implementation time.

They give a name and description to a slot. Then they... You insert a little bit of code at the right place of where it's gonna appear. The control panel then appears. That lets you put in blocks. So... Right, we haven't got a plug-in for this. We'd like to, if we will.

So here's an example, right? So it looks a little bit weird because that's the control panel, that's the actual footer, and, you know, arguably, the header and footer is the editing control panel experience. We... You know, the future for this is someone implements slots properly.

It would be nice if we could inline edit this, right? So you can just switch between, oh, I'm editing the footer on this page, I'm editing the content on this page, I'm editing the, I don't know, alert or something like that. I think we've discussed that. I think it's possible. Okay, forms. I'm gonna rush through this a little bit.

I mean, the forms was a little bit hard, right? Like, we had a few different options. We've done a lot of Plomino stuff. We could have made Plomino easier and upgraded that. That's a big job. We could have upgraded Easyform. It's a shame that there is no Easyform upgrade path because it's quite powerful.

So in the end, we used vaulted form block, which is nice, and it works. We didn't quite realize how many things are missing from it and how many of those things our customers actually wanted. So I think we've got nine PRs and counting for extra features we've added to it. So here's a few of them. So acknowledgment emails, like a kind of a thank-you thing.

We, our particular customer needed XML because it goes through the case management system, so XML data in the email, some different formatting options to display the values and tables instead of as a bullet list or something. The metadata stuff that's in Easyform, like, you know, time and IP address and stuff like that.

Conditional field rendering, which is not in Easyform, but, you know, basically it will hide a field, it will show a field if you pick a different option in a previous thing. This internal value so that you can rename things. So in particular, you can say instead of a yes-no field, you can have yes, I agree, and no, I don't,

and it keeps the same internal value so that your data doesn't get mapped up. Hidden fields, validation rules, we're working on that. Yeah, so future Volto, it's like, maybe we should have just upgraded Easyform.

So we also did a bunch of stuff with kind of, like, these themes when we built a color picker and so on and did logos and stuff like that. Okay, so upgrades, I think this is, it goes back to what I was saying originally about the cost, right? So how many shadows do we do?

We did 16 theme, do you want, maybe you should talk about this one. Yeah, so there's the 16 theme components, you know, the usual header, footer, logo, that kind of thing. We also had 25 magic components. Pretty much every block that was in Volto we needed to adjust the HTML for

to meet the needs of the design system. And then on top of that, all the blocks that were in Volto, Simba, Zorui. Yeah, so, I mean, this is a key thing, is that you have to, in order to get your HTML in there, you have to shutter, there's no question. That's the only option for that, there's no sort of separation between, you know,

functionality of a component versus the theme of a component or the HTML of a component, because of the way React works. So we have to track the news files, their upgrades, they will upgrade it, and we will then have to take that HTML and re-put it into Volto, which is,

you said it's not too bad, right? Depends on the page, yeah, it's not too bad. Okay. We are going to, like, they've changed the way the search works, so we're going to have to re-do that. And, yeah, the big kind of cost here is that, like, every time Volto upgrades, we have to go and do these diffs and work out what they've added,

whether we want to bring it into the shadow or not, right? So I think you said one day, but that doesn't include testing, you've got to make sure you haven't broken anything and so on. So plus the add-ons, that doesn't include add-ons. So one thing we definitely learned is that there's more moving parts, right? You've got front-end containers,

and we've discovered a bunch of bugs along the way. I fixed a bug in Waitress the other day that was incredibly obscure, that has never been found before, because it was going to 100% CPU. And, actually, that's nothing to do with Volto, is it? We would have got that anyway. We've gone to Plone 6. But we've discovered different bugs like that along the way, and it's cost us more than we thought.

ReaderX being broken, we've got some PRs for that, right? ReaderX are broken only if you do VHM in a different way. That's why no one else is fixable for this. The multi-tenanted thing. So, you know, we do have another system where we've got this file-sharing collaboration suite,

and we want to run multiple, multiple sites. And, currently, you can't run the same Volto front-end with the same theme for many, many sites. Seamless mode doesn't work like that yet, but we have a PR that we're working on. More scalable. Ah. So we ran the numbers yesterday.

I was like, we didn't work out. Like, when we converted these sites from what was Plone 5 to Volto, it was like, it should be less, and the numbers we ran kind of came out the same. So, I don't know. I think maybe we're using less memory overall, which is good, but I think if you count the total request time

for each different, you know, this kind of measure of how much CP is used for the site, it sort of came out the same. But I think we need to redo that, so I'm not sure. So, to summarize, the UX is definitely better. The UX is gonna get even better, I think, as some of these bugs and as Quanta comes along.

It is expensive if you bring your own HTML. I think one thing I haven't talked about yet is that one of the big differences is that when you want to do some custom stuff, like, it's React, man. It is much, much easier to get much better UI,

much quicker, and that saves you a lot. And React developers cost less as well from a business point of view. You know, you don't have to train people on, you know, dexterity and all the ways of implementing classic stuff. So, I think, in hindsight, exploring the headless option might have been good.

I don't know. We didn't try it, so, you know, my little measurements here of what it might have been like, that's purely speculative. There are, obviously, some costs. I mean, you have to... You've still got to build a front end, right, with the routing and all the rest of it.

But other people have done it, right? I didn't mention it before. Like, Plone Gatsby is, you know, a good example of using Volto and a headless-type arrangement. And this is the thing. I think the UX doesn't have to be too bad, right?

This is an example of a story block, which is a headless CMS. And they advertise themselves as an inline editing, WYSIWYG, and what they're doing, I think, is kind of clever. So you notice this looks a lot like Volto, right? This bit in the middle is a completely different architecture. It can be built in whatever,

and all you're doing is adding a tiny little bit of JavaScript that allows the selection of the blocks to happen, right? So you can't edit inline, right? These components in the middle, they won't change. But if you edit on that side, save it, this will reload in the iframe and reselect the same block, and you get half the editing experience. It's not as good, but it's not bad.

I think that's it. Thank you. Questions? Questions? Come on.

Too much. Everyone's shell-shocked. While you think of a question, I'm going to show you my socks. These are the coolest swag.

Which version? Of Python? Left version? Right version? 3.12? So what you presented is very cool. I mean, you're showing the whole frustration

when theory comes to practice, and you really need to build and implement a design system. And I mean, we've had our quarrels in GitHub and in meetings this year where you see that the blown integrator is trying to actually use Volto for larger sites with design systems, and then you really run into this challenge of having...

I mean, it's not only, oh, we have a nice block editor, and we'll just throw some nice block variations in them, but as soon as those blocks start to integrate and you want to work with them together, then you run into these really difficult challenges where you want to make things simple for an editor, have a developer experience, right,

for the developers, for the themers, and the combinations explode exponentially. And I think what we see here, so it's a really great effort. It's really a good explanation and implementation. But we're not there yet. I mean, if you look at how Plone got before Plone 6, the efforts we tried, the landing page

or the composite page editors that we've had, Philipp and I did it. We regretted it as soon as we started planning for it, the TPN issue last year of composite page editor rethinks. We're only at the beginning, I think, of finding a solution here. So thank you so much for trying this also for our government

and then hitting the issues, coming back with issues. But this is something... We need to discuss this so much more. We need to have more implementation, see where we bump our heads. And if we can come up with something, because I think this is one of the most complex things that we'll have to solve in the next one to two years,

bringing Volto further forward, looking at different implementations. I mean, KitConcept has Volto Lite team. The web has set up an ecosystem of blocks that work together that has another group. So, yeah, thank you so much.

Thank you. I just want to emphasize a little bit that, you know, maybe in a little bit negative... And I really want to emphasize this is about bringing your own HTML, which is a unique case that a lot of people don't necessarily have, right? If you are theming Volto using Semantic and everything like that, I guarantee you that is a very different experience

than bringing your own HTML. So, like, awesome work that you guys did. And for sure, we're waiting for those pull requests to come. And one... Actually, two comments. I had the same problem in a website

that I did with the sections, and we've solved it with the section divider, which we made it, like, really, really obvious. And we said... In the section divider, we said everything about this line acts like this, everything below this line acts like this. Okay, so it's a variation.

But I really like the idea of having the block component template, block UI, so really, really dump component separately, and then maybe you can even take that and use it in a headless CMS type of scenario. So that even though you...

Okay, we completely separate the HTML production of the block from its management interface and so on, so that we can continue to use Volto, but allow rendering the block, you know,

to just override it or reuse it in the headless CMS scenario. I think if anyone didn't see my lightning talk yesterday, I go into that, you know, there is this whole Mac architecture thing where they're proposing this and all the things about headless CMS, and these are different cases, right?

Like, if you... Again, you want less of a theme if you're not bringing your own HTML. Headless is one case that's good for... It has pros and cons, right? But I do think that we could create something like this with Volto that, you know, you can have two modes of Volto, right, without changing Volto terribly much, right?

That's definitely possible. And then you could, yeah, then we would have a true headless CMS, or an editing environment that had side-by-side preview, essentially, as well as the other way of doing Volto, which is true inline WYSIWYG. And another comment about slots. Yeah, I'd really like for both slots to be finally finished,

except that we, like, bogged down into the UX talks and experience and kind of still waiting for that Quanta toolbars to happen, just so that we finally have, you know, the building blocks to make that vision happen.

Maybe we change the vision. Maybe we simplify the whole thing. So definitely I think that the toolbar thing is now just like this stopping block to all these other things, right? And in discussion with Victor, he said, like, essentially there's no way to do it with the current API. You have to kind of break the API so it's going to be further down the track.

We've been working on a way to see if we can do it without doing that, so we've been playing around with that. And Jeff... I can't definitively say we can do it. We are trying to do it, because we need it. It's the right solution for so many things. So, yeah. And another...

I think Victor has a proof-of-concept PR, which was actually pretty advanced about making possible drag-and-drop between containers. So, yeah. I can put my shoes back on?

Thank you very much. Okay, thank you.