Thank you, Jim. So Plun React, or Volto, as... So everybody who didn't get it yet, so Plun React is no more, it's renamed to Volto. I can get this mic, yeah, that's better.

So let's not never name the name Plun React anymore, just call it Volto and we'll be fine. So it's not a new thing, it's exactly the same, just with a different name. Yeah, so Jim already mentioned what I am, who I am, and what stuff that I did. Yeah, looking at all the Volto talks, there's quite a lot of them during this conference.

So Othimo already did the talk about reinventing Plun, and then we have a couple more listed for the conference. And so the Volto one, you're here now. Right after this one, in the same room, Victor and I will talk about the Volto accessibility

story, so that's basically about how can I create my own site using Volto. Then we have some more talks about Volto, one is regarding theming, so that's only about theming, so the whole semantic UI, which I will mention later, and everything

you have to do with styling and theming. And then we'll have a Volto case study talk, which is on Friday, which will mention Timo will be doing it with Victor and Ramon, and there's a lot of people there who already use Volto and use it in production, so we're going to show some websites which were actually

built on Volto and are already live now. And last but definitely not least will be the Create Volto app, which Neil Ash will be giving a talk about, which is his Google Summer of Code project to bootstrap your new Volto project.

All right, so what is Volto? It's a frontend for Plone, but not just for Plone, it also works on other systems, but it means it's a system which just has JavaScript and uses the REST API.

So it runs for Plone, and a small pet project I started with in Japan, I also created a small Node.js server just as a proof of concept, so you actually can run the whole Volto with just JavaScript. Yeah, so as I said, it runs on the Plone REST API, so it uses all the calls there

and any compatible API, as I just mentioned. 100% JavaScript, so it uses JavaScript to create everything, to do the routing, there's no nothing served on another system like we currently have in Plone where we have the

resource registers, for example, and any other templates which are rendered on the server. Everything is done in JavaScript. So as I said, server-side rendering as well. So server-side rendering means normally if you have a single page application in JavaScript,

that means you will load your index.html file, then a bunch of JavaScript gets pulled in and you'll do some data fetching maybe to get some stuff in there, and then the page will load. So there's two problems with that, one is that usually takes a long time before something actually shows up to the user, and another one which is even more important is it doesn't

get indexed by Google, because I think by now they do some indexing on JavaScript, but still they don't, oh, Timo says they don't, okay. They claim to, but it doesn't, okay. So the good thing is that with React you can actually do something which is called server-side

rendering, and that means you can use exactly the same code, so the same JavaScript code you're using to render stuff on the client, you can also render it on the server. So that means that the first hit you actually do will render on the server, it will output the corresponding HTML, and from that on JavaScript will take over and do the calls

after. All right, so it's built with a couple of techniques, the first one is React which we're using to do all the views and all the other view logic.

Next one is Redux which is a state machine basically, so what we use it for is to fetch all the data from the backend, save it in a local store and render the input based on that, and another package we're using is React Router to do all the routing, and React Router is used both on the server and on the client side, so the same routing

and the same routing definitions work for both for the server-side rendered version and for the client-side rendered version. Another thing we're definitely using is Pastenaka UI which is, Albert is not here, no, he

is, is he still sleeping, no, oh he's upstairs, good, yeah Pastenaka UI is the awesome UI created by Albert which has lots of really great improvements of the Plone UI and we try to implement most of the design and definitely not everything is finished yet,

but we're already made quite some steps there. So we actually have a brand new design for Plone and Pastenaka UI is also really well optimised for mobile, since that's, as Timo mentioned yesterday as well, it's used even

more than normal desktop browsing. Semantic UI is a framework which we're using to do all the styling, the theming, and something which also contains a lot of components already in React, so that means

that we don't have to, you can compare it more or less on the same level as I'd say more or less like mock-up, so it's actually just a level of which provides you control, so it provides you with buttons, forms, menus, pull-downs, breadcrumbs, navigation,

all that stuff that's already in Semantic UI, and it provides you with the controls so you don't have to build them and it also provides you with the CSS which is added to Semantic UI, and Semantic UI is built on LES, yes, not on SAS, you heard it correctly, and that is because Semantic UI has a really really good theming story, so what they actually

do is they let you have multiple themes and also override it dynamically in your own website, and SAS doesn't include the conditional imports there, yes, kind of, so actually what

we did was, so Pastenaka UI is a sketch file, as you would say, and what we did was make it as pixel perfect as we could and implement it as a Semantic UI theme, so it's basically a theme for Semantic UI, yep.

So then a good question is, why did we even build Volto? So this is a quote from someone in the Plunge community, anyone can guess who is it from?

Philip knows, it's from this guy, you probably all know him, yeah, so he's stating that we are solving problems which he never had, and I don't think I agree with him, and I'll tell you why. So the first thing is that the Plunge stack is currently too complex for front-end developers,

I mean most of us sitting here are people who are a long time in the Plunge community already and they know all the different techniques there already, they know Python, they know GCML, generic setup, well the list goes on and on and on with all these technologies

which you have to know to add a simple view to your website for example, and it might seem obvious to us or maybe not even obvious to us as well, but for a front-end dev to jump in and to just add a simple thing like adding a view or doing another customisation, it's a lot of new things to grasp.

So the idea of Volto is that we're actually having, just we're staying with the technologies they already know. So that means that we are currently, we're using front-end build tools as they're used to, so that means at the front-end we're using Webpack, which front-end developers

already know, and we're using all the other tools which front-enders already know and they don't have to know about the resource registry or any other method of registering resources and stuff like that. So this way we're keeping the back-end separated from the front-end and the front-end. The back-end will use the back-end tools as they used to with build out the Python

package et cetera and the front-end will use the build-out tools they're used to like Webpack, NPM, package manager and stuff like that. Another thing is that we're using one stack to build the front-end. If you have a look currently at mockup, for example, that uses a lot of different tools,

so I think there's some React in there as well and uses jQuery and some custom JavaScript and I guess if you want to customize anything there you have to, I guess you have to know about a lot of all the other technologies and not just about one specific one. And another thing which we had in mind was to reuse as much libraries as we could

so we don't have to build stuff ourselves. So that, for example, semantic UI, as I said, is more or less a replacement on the same level as mockup, so that means somebody else is maintaining semantic UI, we can use it, we can contribute to it if we have made any changes, but we don't have to maintain

that whole code base and we get all the stuff for more or less for free. All right. Let's do a demo. All right, so you've probably already seen some of the stuff during the keynote from

Eric, but I will go through, well, I guess most of all the stuff which we implemented in Volto at the moment. So as you can see here, we start with the login screen, which is all styled in the Pasternaga styling.

And when we log in, we are at the home page. So what we see is your default site layout, so you would see your logo in the top left, you would see your navigation, you will see your breadcrumbs, which is empty, I

will go to a page where you can actually see some breadcrumbs. And then on the left, we have the Pasternaga toolbar. So the Pasternaga toolbar is a bit different from the current blown toolbar, so the whole idea about Pasternaga is to have all the actions which you are using often to have

it in view, and everything which you use less often to more or less hide it in the extra menu. So that means we are trying to make the people go through the default setup which they use most, so that means adding content and maybe managing stuff in the Volto contents

and all the stuff like workflow, history, sharing, and all the other stuff which they I guess most people will use less often will be hidden from the user so they don't have to go through all the buttons and just say, oh, I have to only choose three of it and that's the code for this one. Then we have, of course, I skipped this one, the search widget, which you can actually

just search through your site, and we have the footer at the bottom with all the links in there. And on the bottom left, we have the user menu with the current logged in users and all the site setup. All right. So let's go to let's do some adding, right?

So we want to add a page. So we're currently in the news folder. We go to the plus button, and we say, okay, I want to add a page. So when we do, we get a form. This is more or less comparable than with the current Plone UI.

You have a form with different tabs. On the default tab, you have the title, you have the summary, you have the text. So I can just add some text there, add the summary. And there's a rich text editor as well here, although you don't see it, but it's a rich

text editor. I will show you. Markup. And you can actually, when you select some text, then you can the rich editing buttons show up, and you can make something bold, for example, or you can do we can do a

header. So we have the inline styles on the left, and we have the block styles on the right. And we can, of course, as well do lists, for example, and ordered list, unordered list,

and quotes and everything. So all the markup is there. These are the default buttons, but you can, of course, extend and change them, which we'll show in the next talk, where we talk a bit about accessibility.

You can actually just customize the buttons you want to use in your rich text editor. All right. Yep. Good question. So after this, there's two other options to edit content.

One of them is called the pasta naga editor, which is a bit different and a bit more intuitive. This one is, I guess, you could call it, it's part of both, I guess.

It's part of Volto. The editor we're using here, so in Plone, we used tinyMC, and now we're using draft.js, which is a visual editor, also created by Facebook, the same people created React, so it integrates really well with the whole React stack, and we include it in both, but

it's not tied to any of the technologies. Yep. I think you... Yeah, you can.

Yeah, you can. Yep. Yep. Yep. Yep. You can. So to be clear, the draft.js is basically a framework to create your own editor, and on top of that, some people build the UI, so actually these buttons, which you show up here, is actually part of the draft plugin editor, which is a layer on top of draft.js,

which actually adds stuff like the keyboard shortcuts, the toolbar, and all sorts of different things which you can add, so you can just extend it with lots of other extra functionality if you want to.

Definitely. Yeah. Yeah. All right. And when we're done, we're pressing the save button, and we actually see our really awesome page with pretty content.

There's... And of course, I can, if I want to, I can edit it again, and the same data will show up. All right. Next up, there's some... Let's go to the folder contents first. So the folder contents is also completely reimplemented, so as you can see here, the screen resolution

is not the best, but the good thing is, I can actually determine which columns I want to see, and that now fits better. All right. Nice hack.

Yeah. So this is the renewed folder contents. So we have all the... We start with a toolbar on top, which has all the actions to do your bulk actions, basically. So if you select any or multiple of these fields, you can rename them, you can add text

to them, you can copy, paste, and all that stuff to them. You can, of course, filter the current listing, so if you only want to see stuff that contains Tokyo, then I can do so, and it will filter that list. Here we will see all the items currently in the folder, obviously. As I said, you can select them.

You can navigate into the folder and to see what items are in there. You can see some of the other properties in there, like must modify, publication date, and as you saw, you can also specify which columns you actually want to see here. So if you see, say, well, the last modify or the publication date is not really important

to me, but I do want to set the ID, for example, which is quite long at this date. Let's not do that. But some other fields, so you can say which fields you want to show in your folder contents. Then we have the actions column, of course, to where we can do something with the content.

So we can edit the content if we want to, we can view the specific item if we want to cut and paste the specific item, and we can do some reordering. So you can do reordering with move this item to top of the bottom of the folder, and you can also do drag and drop using the icons here.

So you can just rearrange them like this. And on the bottom, we have batching, of course, so we can determine if we want to see if it... Yeah, have a question? Yes, you can do that. So that's this tiny icon. You can upload widget and you can just add a bunch of files or images or whatever you

want in there. It's front-end. Yeah. 99% sure it's front-end. I'll check later. Yeah, I could, but that's...

All right. Yeah, and you can obviously also have the breadcrumbs here, so you can navigate back to the root or to any other location you want to. All right.

So this is what the folder contents looks like. Then we have some extra buttons. So if we go, for example, to a specific page, we have some more options here, one of which is the workflow, which is more or less the same as current plans, so you can publish

or submit for publication and all the workflow actions will show up in there. We have the actions menu where we can cut and copy and paste and delete and rename the current item. We have the display menu. Let me show you on the news folder, probably makes more sense there. So we have the different displays here, so currently it's a summary view, but if

we want to have the listing view, for example, or the tabular view, we can all switch to those. Then next we have the history, which is also redesigned a bit, so you can actually

see in the history what happened, who did it and when it was done, and you can also see the change note if people still supplied that. And there's some actions in there as well to view the changes, for example, so if I want to know what happened in this one, I can see the diff to see, okay, this was

some text here and now some header was added. And of course I can also revert to a specific revision and to view that revision or the revision in this case to see what was in that one.

I think it is. Yeah. I'm not sure if the, so yeah, so the revision stuff is and only the working copy thing,

that's an add-on or a setting I think, but I think the revisions is there already. Yeah. And the last thing, you can do sharing, which also works the same as the current

plan with a bit of a facelift in the UI, but you can just for all the users which are there, so if I go to administrators, for example, I can set all the different permissions there. I can show you a bit of the search, fairly simple at this stage, it will just show you

all the different search results with all the items in there. We don't have advanced search yet, but that's something which we could add as a sprint topic for example.

Nope! The portlets is something which is not exposed in the REST API at the moment, and it's a difficult thing, so as most people know, so we used to have, we currently have portlets,

and then this thing called Mosique came around, and some people, so the idea was that we were going to get rid of portlets in general, so we're going to have panels, what they were called, so you can have multiple panels which can all contain layout and contain tiles, but like the full idea of that was never implemented.

We have, I think, in Castle CMS, they also got rid of portlets and they implemented the tiles as the same, more or less the same functionality as portlets. And currently we don't have a solution yet to do portlets, but we are doing an open

space today at 12.30 to talk about layouting in general, so that will also include the whole portlets and that story, and also include the whole idea about how we can do

editing and visual editing and stuff like that, so that will also be part of that.

So to be honest, what we did was implement Pasta Naga UI, so if you want, I'm not a UX designer, I'm a front-end developer, so this is basically implementing all the things

which Albert made in Pasta Naga UI, and if you want to have an answer to why that was chosen, he's much better to answer that question than I am. But yeah, I agree that we are doing, I mean, we did add some, there are some

changes in there, definitely, and there's some things which remained more or less the same, maybe because they're already good enough, or maybe we didn't have any other idea of how to implement it, but there's definitely some steps to be made if we want to, yeah, yeah.

Aside from portlets, which is due to the limited feature subset that the Plone REST API implements, I'm not super familiar with what the Plone REST API

provides versus what it doesn't provide, so can you just expand on like a major things that would, that someone who needs that feature would just say sorry,

if it's not available, I can't really use what you're providing, so that we can make it an informed decision. Sure, so regarding the REST API, what it currently doesn't provide is portlets through the web content types, through the web managing workflow, so not

changing the workflow of an object, but actually managing the workflow, I guess those are the three important ones, yeah, depending if you find any of those three important in your use case, but that's up to you, but those are the main things which are not implemented in the REST API at the moment, it is,

yes, so login and registration is there, yeah, yeah, no worries, alright, I see

I don't have that much time left, so I will, so some stuff I will go to quickly and then I'm gonna do the fun stuff, so we have user preferences, which is also more or less the same, not really that much to show there, you can just set

your own language and your password and your personal information, we have the site set up with the most of the control panels, not all, so all the control panels which are based on the registry, are they already there, and then there's some work in progress control panels like users and groups, which is not completely finished yet, but we did some work on the last

print and it's almost done, add-ons is also being worked on, which should be done relatively soon, yeah, so then regarding the editor story, so as I said, we had the normal form-based editing, and then the next thing

which we have is the Pasternaga editor, as it's, I think it's called, so what we have there is to try to mimic medium, like Timo already mentioned in his talk, to have it as simple as possible, so don't give the users with

the whole everything which is there with the form input and all the fields which they might not even need, so you can just easily type your title, add your description, add some text, and if you want to, you can just add an image, add a video in that place, of course,

you can, and if you type some text, the plus button will disappear and it will be changed to a drag handler, so you can actually just drag your items around, and of course, you can delete an item here, or you can just, with backspace, you can just remove it like that, so it's actually, all these things are tiles, they are saved as tiles,

and when you press enter, it's a new tiles being generated. This editor doesn't do layout, so it's just a list of all the options there, you can of course add new tiles and a tile can contain two columns,

for example, if your markup is like that, so you can do stuff like that, but you can't drag and drop the layout around. Then, it's Ploned.tiles indeed, so it doesn't use Ploned app tiles,

and it also, so we're using Ploned.tiles for defining which tiles are available, and those tiles can have schemas and stuff like that, but the actual data is just stored in a JSON field on the content object,

so it actually doesn't have that much integration into Ploned at the moment, it's just JSON data. Yeah, indeed, yeah. Any tile plugins will work. Any, any! Sorry? Oh, sure, yeah, I could do that.

Yeah, so the question was whether or not we're using Ploned app tiles, but we're not using Ploned app tiles, we're using Ploned.tiles to do the registration. Yeah, and then there's this thing called Mosaic, which was implemented in Plone,

and what I did, even before the Pastenaga editor was created, I tried to recreate the Mosaic editor in React, and that's what you're currently looking at, so this is the Mosaic one completely rewritten in React, it has more or less the same functionality as the current Mosaic one does,

except for one big thing is that it doesn't do any saving yet, so there's no integration with the backend at the moment, so because at the time we didn't have any clue about how to do that, but at this stage with the Pastenaga editor, we do have an idea of how we can store tiles and save data,

so that's probably the next step we can actually do to implement, and to actually store this data, and this is exactly one of the topics which we want to discuss during the open space, to see what use cases people have for layouts, and how complex should they be, or how simple should they be, and what are the current users,

especially people using Mosaic would be really good to have in the open space, but anyone who's interested in it, please join us so you can give some input. And then the last thing I want to show is the, we have a schema editor basically,

so what I built was a schema editor, so what's that, that's actually, if you have a schema field, which can contain a full scope sub-schema, you can edit that as well, just as a normal widget, so why would you use that?

For instance, if you want to create your own form, so if you want to build something like, I think Easyform is now the cool thing at the moment, or Ploneform, I don't know, any of those, if you want to do something like that, you can actually, as you can see here, this is just a widget on top of a schema, so you can edit your schema, and it will save as a JSON schema,

which can be saved on the backend, although, yeah, the backend story is not implemented yet. This can also be used for, through the web content types, for example, but as I mentioned, there's also not, but I think we have some volunteers who wanted to work on that during the sprint,

so let's see how that goes. Would be really nice to have that. All right, so don't have that much time left, I see. So this was everything about the demo. Let's quickly continue. Yes, as I said, there will be up space regarding the whole layout stuff.

So the time is fixed, and the location might not be fixed, depending on if the, because we haven't checked with the organization, if we can use the exhibition hall, if it's open or not, and if it's not, then we'll probably find some other location somewhere in the hall or something. All right. I'll do a really quick code walkthrough,

because I only have five minutes left, but then you have a global idea of all the things. We'll cover some of the stuff as well in the extensibility one, and if you really want to know everything about what Volto is and how you can build it, then maybe a good idea to do the Volto training or to have a look at that. We did it two days ago,

but if there's more people interested, we can definitely do it again during sprint or doing, well, next conference, maybe a long way ahead, but somewhere in between, we can probably fit it in somewhere. So this is really a lot of code, so people are not familiar with all the backend stuff. Yeah, it's a lot of stuff in there, so I'll go through it rather quickly.

So this is the actual Volto setup, what it's used for. I will go through, so we have a public Volto which contains all the public files, like the favicon and the robot.txt. We have Volto with the locales, so yeah, something I didn't mention

was that Volto is fully i18n, so we're using all the different languages, and we're using, as you can see, the same translation system as current and Plone does, so we're using get text, so we have PO files which can be changed, and eventually it will be rendered to JSON, so the frontend can actually use it, but the whole step of translation

is completely the same as current Plone. Then we have the source folder which contains most of the code, so we have the Redux parts in there which is managing the state, so those are the actions, and the reducers, the middleware

which is used to fetch some data, so it's the API middleware, and some constants, and then the big thing is, of course, all the different components. Components are in React, really just small or large depending on how you build it, components which make up your whole UI,

so if we're gonna look, they're split up into manage, meaning all the other things stuff, a theme for the end user, and there's most of the components also, because there's quite a lot of code in there, a separate folder in there, and as you can see, there's quite a lot of components in there, so everything is like a really small component, so anonymous tools which is comparable to a few,

let's say app is like the big one, that's the one covering overall, and that will include, for example, the header, and the header will include the breadcrumbs, and there's a text component, and so everything is more or less there, so even from the small ones to the larger pages,

and they will be composited smaller components. Then we have some configuration options, which we'll definitely go through in the extensibility talk right after this one, where you can actually define what views are there, what widgets there are,

what styles you have available, and what settings all the rich text editor field, for example, has, and you can set them here, and overwrite them in your own theme, and then we have some end-to-end testing, of course.

Yeah, so we have unit testing in all the different components, so as you can see here, for the search, we have the search file itself, and then the unit tests are on the same level, and then on the global level, we have the end-to-end tests, where we're using robot framework to test all the functionality, and the last part is our theme,

so as I said, we're using semantic UI, so these are the semantic UI themes, and we have a default theme, which is the one provided by semantic UI, then we have the Pasta Naga theme, and it consists of a lot of folders, which we'll go through in the extensibility story, and then we have the config, where you actually specify what you want to use,

so that's like a really quick overview of what the code looks like. Yeah, so what's next? So we don't have any add-on plugins supported yet, I mean, you can do it, but you have to manually import some of the stuff, that definitely works,

but we're trying to make it even easier, so you can only define which add-ons and plugins you want, and then everything will be imported automatically, we have some ideas about it, we did a brainstorm with Guido and Raul last week, and we think we have a really good idea of how to implement that. Some of the control panels were missing, as I said, through our content types,

which is not supported in the REST API yet, and the form add-on, same there, workflow editor would also be really nice to have it through the web, and Mosaic, depending on if we want to go for the full layout, I guess that's gonna be at the end of the open space, we'll know which direction we want to take,

and the visual editor, the Pastanaga one, is also part of that. Yeah, so join the sprints, I would say we're gonna be sprinting on Saturday and Sunday on Volto, and my idea is to, sorry, there's a lot of tasks still open in Volto, and there's a lot of relatively simple tasks where beginners can also hook in,

so we have, for example, like the old contents view and an album view, which is also part of the training, that's not in Volto yet, so that's stuff people can work on, and we have all the way from really simple to really hard problems to tackle in Volto, so if anybody's on to, I'll be happy to help them out and to get them started.

Yeah, we already did a lot of questions, and I think I'm running out of time, but if you have any, then please continue, yeah. I wonder how other CMSs do the whole add-on thing.

I think WordPress has a lot of add-ons that you can install. Are you doing a new build then, or? So, as far as I know, there are no CMSs which do have this approach at all. If you know any other, then please say so,

but I think most CMSs, or I think all CMSs at the moment, still use server-side rendering, and I mean, there's some, like Gutenberg, for example, with WordPress, but that's just the admin interface. As far as I know, the whole, everything which is rendered to the end user is still done on the server side,

so I guess we're just the first, again, with something. So how separated is the front-end theming part from the back-end? Like, basically, you gotta take all of this, or can I implement, say, I grab another Angular site?

Like, one of the cool things you can do with Plone at the moment is this lift and shift where you can just grab a theme from somewhere else, keep the back-end separate. Can you do that? Yeah, so the only coupling with Plone is the REST API, so that we don't use any theming from Plone itself. We don't use any resource registries from Plone.

The only thing we're using is the REST API, so that means that any content which is in your Plone site will be available in Volto as well, and it can be any version of your site, but we're not using any of the theming part there.

So again, within the REST API, is there any feature within authentication or authorization that is not supported in the REST API that is supported in plain old Plone? No, not that I know of.

No, so you can do a login, and that works, and the whole permission system and the workflow and everything is implemented, yeah. Timo has something to add. Yeah, just one to add about the question of add-ons,

right, and like past plugins and everything. The thing is that all existing add-ons are supposed to work at least like the back-end parts, right, and what all add-ons need to do is implement a REST endpoint on top of Plone.rest, right, and then you of course have to manage that in Volto, right, or write your add-on product, but using Volto doesn't mean

that you can't use any existing add-on products. You can basically use all of them. You might have to implement the REST API endpoint, and you have to take care of the front-end, but that's it, right, and it highly depends on your add-on product, how much work it is, but it's not that if you use Volto, you're like cut off, like all add-on products, right,

they still exist. Definitely, and if your add-on products just uses content types, for example, if it's just like an FAQ module which has content types, then it will just work because the content types, like the custom ones, are exposed in the REST API, so it'll just work. Yeah, just to clarify that that really works

with the add-ons, you can just install it, and if it's a add-on, content type is exposed, but in many cases, you'd have to make a conscious decision if that's actually the right approach. For example, you can install Easyform

and add a Easyform instance through Volto, but that makes very little sense because there are maybe NPM React components that are better at creating forms through the web, and then you'd have to, then your problem is the backend again.

The other, if you go from the Plone side, pull in a Plone add-on, your problem is the front end and maybe an endpoint. If you come from the React side, your problem is the backend. Definitely, yeah. It is gonna be a decision wherever you,

that you have to make. Yeah, for sure, and you can choose which you prefer if you want to change something on the backend or in the front end. I guess it depends on where you feel most comfortable or what you want from your users. We're out of time. Yep. Thank you very much. Thank you.