Is it fine? Nice. Stefan Antonelli. As said, I'm from Germany, this is Twitter handle if you want to contact me or ask questions afterwards. I pull the microphone, what do you mean?

I should keep it. Is there anything to see for you? No. I see it on my screen. Not better.

Yeah, better, but okay. Is it my bad?

It's fine on my screen, I don't know.

Any ideas? Really? Any ideas? Maybe you? Connection is there.

Never had this before. Okay. Go for it. So my Twitter handle if you want to contact me afterwards and GitHub repository. What is this talk about? It's an interesting topic, that's why I need to explain a little bit about.

I showed a couple of weeks ago Max Jakob from the University of Munich how we do seaming at the moment or how we think we should do seaming to not waste a lot of time or to get to the end after a while. And he said I have to talk about that, so that's why I'm here. We do seaming based on Barcelona.

I don't follow the idea of introducing all new seam or introducing a completely foreign template. We use Barcelona as the basis. We override some of the templates where we need some changes. It's extendable to use the resource registry if necessary.

And that's in my opinion that what fails mostly the mobile approach is a little bit missing. So we've found solutions for dealing with it. The talk is for guys who are not willing to switch to this new front end development

age, basically. We are not talking about best practices in Plone. So if you want to discuss about that afterwards, feel free to contact me. I'm not talking about this whole REST API thing, Volto, React. I have been to the talks.

Very interesting stuff. Please go there. As soon as you hire a front-end developer, you will be happy. I am. So how to archive this? As I said, our seam is based on Barcelona. Everybody knows how this looks like. My idea or our idea is lots of it is fine, but let's make it nice and shiny somehow.

We make use of existing elements. Lots of the stuff is really useful. Especially for add-ons, for bigger installations like on a university.

If you deal with forms, Barcelona is okay for doing that stuff. So we drop stuff we don't need, or we don't want to seam. And there are some corners around in Plone that you really don't want to touch. In our most layouts, we drop the search box.

We find different solutions for integrating a search for that. We also drop breadcrumbs. They are mostly not necessary. This is maybe really up for discussion. We drop columns at all. In my opinion, columns are not working somehow on a mobile phone.

You always need to find a solution for that. My solution is we drop it. Just don't use it. We only keep the main column. And this indeed makes in Plone everything working on mobile in one go.

Next topic. Toolbar. No more toolbar, please. Who likes the toolbar in here? Please raise your hands. I don't see any hands because of the light over there. I don't like it. I think it's not easy to seam.

It's not easy to understand how it works in the backend. It's not easy at all for me to deal with it somehow. So we drop it. Header, footer, all elements you don't want to use in your seam, just drop it. It's the concept.

One of the concepts. You can use the manage viewlets thing to disable stuff where you want to not render the stuff. If you want to replace it, we have the solution for overwriting it. I want to talk about it a little later. We still have to create a package. This is also not a talk about through the web seaming.

I think everything needs to go into a package. You have full control. You can make use of Plone CLI. Mr. Bob to create the package. It helps you to set it up properly. Keep everything together in a Git repository. That's the way I guess you should go.

What's the package thing? We also have to create a seam inside the package. It's part of the package as everybody knows. Add this as a regular seam. Nothing new to all of you.

We copy over the default index file that we have from Barcelona. We copy it over so we are able to change it easily. That's our idea. Copy also the rules. I'm not a big Diaco fan, so it's difficult to understand how it works. It's also interesting to deal with it. If you follow the concept completely, it's okay.

You can do powerful things with it. For me, we copy it over and we change only a few lines where we need to change things. I'll talk about it later. The most interesting thing is do not register any resources, bundles, whatever. That's the stuff we had the most pain trying to understand how it works.

Trying to understand how it needs to be extended. Especially the early days of Plone 5, we had no clue about where to change it, where to touch it, where to do the actual bundling. Is it a backend thing or a frontend thing? There was no really good documentation.

Now, two years later, I understand mostly the stuff. It's still okay to use it, but my idea is if you want to introduce another person to Plone, don't show it. Before, I said we drop lots of elements. Of course, sometimes you need a header, you need a footer, you need to style that a little bit.

Use overrides. There is a collective Jbot for the lazy ones. It's part of each theme. It's easy to figure out where the origin template is, copy it, and change whatever you need. So here it starts getting interesting.

Seeming means you want to add your own styling, you want to add your own JavaScript. So where and how do we do it? Use a static CSS file and put it into the theme, into the theme folder. And add it as a static resource and just add it to the HTML.

That's what our idea is at the moment. I'm talking later about how to extend this to use inside a bundle, but I tried it and it works. It works quite well. Each time you touch the file, you can reload the page and you don't need to bundle or update stuff.

This snippet is added to the head section of the index HTML. For the JavaScript part, this goes at the end of the body section. As you know from each bootstrap theme, for example. When you do static HTML, that's commonly used.

There are no dependencies. We are not heavily making use of JavaScript in Plone. For the simple things we do, like using a little jQuery or adding another library that's not conflicting with the default Plone things can be used like that.

There is no dependency. We rely on jQuery, which is part of the core. I wait for that.

They're behind me now. We rely on jQuery, which is part of the core. For our project, there was no need to update it. It was good enough to deal with it. With the examples, I said you have to tweak the rules a little. Because all the CSS goes at the end of the head section, which is apparently after your CSS.

When you follow the example. The only thing we need to change is add the JavaScript from Plone. The original JavaScript from Plone before your custom ones to override it simply.

We figured out the easiest way of changing, for example, the footer in Plone is rename IDs and classes. All the existing CSS is not applying anymore.

You can add your own classes. You can add your own CSS to style that class. That's just an idea of how you solve that. In my opinion, it's better to override than existing styling. If there is stuff in the styling you don't like, you can override everything without touching the template.

But I guess the CSS gets complicated after a while. So, what is the result? I show you a screenshot. This is an example I did. I called it PloneSim.Tokio.

It's also available on GitHub, so try it if you like. The same concept like you can see in Pasta Naga is just dropping elements makes it a little clean. Makes it nice. I love it. The whole navigation is hidden behind a burger icon.

I want to talk about it a little later. And I think it looks pretty good. Even on mobile. So, the UI works for mobile as well. And I think you should not separate between desktop and mobile as well for the navigation. Because the user switches between the devices and I don't understand why you should force him to understand different navigation concepts for that.

So, my idea is that mobile navigation should work the same way like the desktop navigation. There is no separation between the seams in this way. And the lucky thing is, as long as you use Plone's main column, it works on mobile.

It works out of the box also for editing. You don't need to change anything. Just try it out. It works quite well. So, quick summary for that.

We still have to use Plone. No yays here. I'm so happy to use Plone anymore because I don't want to switch to another framework. You don't need to know about the other rules. You don't need to deal with the resource registry.

And okay, this is my personal opinion. I don't want to talk about that. The bad things, okay. The frontend guys can talk about that. Of course, this is not one of the modern straightforward fancy framework things that are

that look good or interesting, but are completely different technologies. So, it's more like the old school seaming and I guess it's out there for the next five or ten years. So, whenever you run a bigger site, you can hire a big frontend team to develop the same,

which you did in the past, or the common technique works a little bit longer. With some tweaks pointing to mobile, for example. Yeah, and the solution is, of course, not so sexy. So, carrots are more interesting at the moment.

I've heard a similar quote in the Volto talk before. So, this fits also for me when I started with Plone 5. Also worked with Plone 4 and Plone 3 and also Plone 2. But when I started with Plone 5, I have to say that.

It's really difficult to dive into this frontend thing. I love it. I love what I see for Volto. I love something like Angular, but it's a completely different technology. And it's the decision if you want to learn it or not. And I can see lots of backend guys, Plone guys.

They love the technology, the complexity, the security stack, everything that makes Plone great. But they don't want to deal with curly braces at all. So, next question. To bundle or not to bundle? I guess this is where we can discuss afterwards a little bit.

Since we have a seam package, you are free to create a bundle. You can do the regular seaming stuff. Most of the concept things works together with the bundle. So, I showed an example of just adding static files.

Of course, you can change that to use less files and JavaScript files as resources and bundle them together and make use of all the bundling stuff and put it into your package. That's what we do in the most projects, basically. So, the static example is just for if you don't want to.

You're free to make also use of external tools. In some cases, it's required. When you want to touch some of the Plone features, functionalities, then you need to touch existing JavaScript or you need to touch patterns, for example. Then there is no way out.

You need to create your bundle and overwrite existing resources. But it's extendable. So, for starting without and switching and turn it on, that's a common way. No questions so far. I asked a question.

Did he say no toolbar? Yeah. We tried to avoid it. I was discussing with some guys and we came up with a solution that says why not bringing the editing features of Plone and the navigation story together in one thing.

Lots of projects we have. There is login and editing needed along with the mobile experience. And this is where, in my opinion, the tool bar is great for editing on Plone on a desktop.

When you need to create a mobile site, enable the login for the mobile site and enable the user to do something on your site, it's difficult to archive that somehow. So, we had an idea of creating something that is called sidebar.

And the concept of the sidebar is bringing editing and navigation together. We started a project that is called collective sidebar. Before you analyze the code and talk about it, please be careful. It's very new. We're working on it.

So, it's not really for production use, but we use it in production, of course, but it needs some love. It's under heavy development and we want to use we want to work on it during the sprint. The idea of it is bring toolbar navigation together. It acts as a drop-in replacement for toolbar.

So, it's not a seam. You can add it and it disables the toolbar and shows a sidebar. We had in mind to the mobile first approach. So, as I showed in the screenshot before, we tried to keep it easy for integrators or for other backend guys to seam it or to change it.

So, it's everything in one template. There is only one template you have to overwrite. And then you can drop stuff, extend it, change it, whatever you like. So, I guess I'll show a little demo. Without showing it, it's difficult to understand what I'm talking about.

This is the site you have seen before. We added a handle for that. It's a burger icon. This is part of the Tokyo seam. If you don't use the Tokyo seam or if you use collective sidebar alone, it will add this burger icon

to the regular navigation of Plone to get something where you need something to click on to open the menu. The idea is to add some more handles so you can integrate it to your seam without dealing with it. So, different classes should be answered or should be available for a click handler.

If you open it, at the moment it slides in from the left. We also had a project where we slide the stuff in from the right. We also in a project had lots of features in that are not part of the collective package at the moment.

We're curious about to work on that. We want to extend it. We need some discussion about how to archive the stuff to respect different ideas on how to use it. But that's at the moment the starting point and we are going to extend it. So, everything which you don't see here now is maybe part of it in the future. For example, configuration. My idea is to add lots of configuration settings to configure it for your needs.

Everything you know from the toolbar is part of the sidebar. Workflow things, editing, links, different display options, adding new content as well as the search.

So, let's go to the front page. Looks a little bit different. At the end there is the navigation part. This is, for example, a setting. I get some feedback where they say we have to move the navigation part on top of it.

You know, ideas, there is a collective package. Have a look on it. There is an issue tracker. We add all the issues or the stuff we want to add in the future as an issue for now. There is no roadmap documented, but we work on it and we are happy for ideas and feature requests what we need to add to get this commonly used.

One idea is, for example, put the search in here on a desktop to use the space that is wasted otherwise. Search feature, sitemap, something can go into here. Interesting thing.

Works on mobile as promised. So, if you open it on a phone, it works like that. The code of the theme you have seen is on GitHub.

I added it yesterday evening. There will be some improvements, I guess, but it can be checked out and used. Also, the sidebar code is on GitHub. We have to make some releases in the future. There will be, for now, do the source checkout, tie it together and then you can make use of it.

Questions so far on that? I left some space for questions and discussion because I'm curious about feedback on that and how we can bring this forward.

Very dark outside here.

Not yet. We discussed about that already. I like the idea of the bundling in Plone to add a cache key to the file URL, basically. This is something we need a solution for that. We also discussed the idea of enable it to do offline bundling.

So, the caching is an issue and if you want to use less or sus instead of CSS, of course, you have to use external tools and this needs to go back in. I guess it's possible to work with diazo rules. Somehow, we need any type of cache key to not run into exactly that problem.

Good question so far. Feel free to ping me afterwards. Maybe during the sprint, there is time for discussion. Okay. No more questions?

Yeah. As far as I can remember, we followed the order of the toolbar a little bit.

I'm not sure about that. It's sliced out from a customer project of us where we had a static part on top, static links that can be actions in the future in Plone. Like the site actions, they are already there. We can put them in so that it's extendable and you can add action if you like.

This is basically what you see. The settings is only here because I'm logged in as administrator. So, it respects, of course, permissions. If you're anonymous, I can also show quickly, then you don't see all the stuff, of course. The ordering itself, at the moment, there is no special order. We were discussing that and make it basically configurable to have the different

sections and somehow ordering to the backend where you can order the things. For now, the only feedback we got, navigation needs to go on top. This is something we will change quickly.

Ordering the elements, I guess it could be archived easily somehow. Something for the future. As well as collapsing the different sections by clicking on the headline. This is also a feature we got a request for that. It's also not that difficult. I'm talking a little bit about the future.

If you check the GitHub repository, there is an issue list. There you can see some of the ideas we are willing to work on. We already have some of it working in a local project which is not published. We copy over the stuff step by step and we add functionality.

We make it configurable when we add something. I'm looking forward for some discussions to get different ideas and different feedback on it. This is basically the list. Ordering was one of it you mentioned. Another one is a locking feature.

You should be able to lock the toolbar so it's visible permanently. When you're heavy using the Plone site as an editor, you don't want to open it all the time. So there is a little lock icon you can click and it will stay open. This cover goes away and you can edit on the screen as regular.

At the moment it's planned as overlay. We need to discuss if this is the result of not touching one of the default templates from Plone. This comes out without adding a theme to Plone. When we decide to add it as a viewlet next to the body, somehow we need to touch the HTML and then it may conflict with an existing theme.

At the moment you can use that as a standalone project. I can try to add this quickly to show.

Without the Tokyo theme it would look like that. We added the handle next to the home button. Not the best design idea, but it needs to be changed in a custom theme. And works like the same without touching the existing layout. This is the idea of the add-on.

Okay. Any more questions? No. Kim? There is always because you want to make sure you hide it or unhide it.

So you kind of got that where you're exposing all the actions in a flat way, which is good for usability. But because you're hiding it, it's less good.

So you're kind of doing something that I think is useful for a lot of users. It lists all the things that are possible, which is helpful to editors. I have to agree, but you have to think you're an administrator.

A regular user doesn't have a link to the site's configuration panel. A regular user is not allowed to add the collection, which is one link less. A regular user can maybe not change the layout, which drops a complete section. So anonymous users only see the static actions or the site links, basically, and the navigation.

In my opinion, I would drop the search as well, because it should be a configure option to show the search or not. So when we release the first version, which is something like 1.0, then you can configure should the toolbar be rendered collapsed and only the navigation is open for now?

Or do you want to open everything? Or this is ‑‑ there are some UI decisions you have to make. And I guess the only way we can go is leave some of the decisions to the integrator that uses it for his project or for his website or for his intranet or whatever.

The idea why we use this as an overlay or as a slide in is basically a technical problem. Because show it always means it's not working on mobile. And to me, it's important to have exactly the same experience on mobile and on desktop.

And I have to agree it's maybe not the best idea to use it on a large intranet where people expect some kind of navigation or menu next to the body. But the most projects we did in the past, like two years, this was the perfect solution for it.

And yeah, open for discussion for that. So if we touch ‑‑ as soon as we touch the default HTML or the default templates on Plone to integrate it somehow, then we have more options.

Better than this overlay sync, I like the push version of it. It makes it more part of the website itself when you push the body a little bit and show the sidebar instead of doing an overlay. This 1980s screen here is also a little small. So on my notebook, which renders a fake resolution around like 1200, it's lower than each modern display you can buy at the moment.

There is enough space to render it without changing any of the default layout. So at the end, you have to make some decisions what you want to support or whatnot.

Okay. We want to work on it during the sprint, so feel free to contact me or give me your opinion or support a little bit. We have some questions regarding the navigation inside the sidebar. We have some questions regarding some of the actions, how is the best option to get them into without reinventing the wheel.

So for example, the ‑‑ what you have seen from the workflow is code we copied over from the toolbar. For the navigation, this was not possible. So we didn't find where exactly the navigation renders the add of content types thing.

Okay. Thank you. Thank you. Thank you.