 Merci tout le monde d'avoir été ici. Je suis désolé pour le contraste sur le slide. J'espère que tout le monde peut voir bien. Vous pensez que c'est évidemment un truc pour la question, parce que nous savons que le Drupal peut faire tout. Donc la session est plus sur le problème, pour parfois essayer de faire quelque chose que le Drupal n'est pas vraiment capable de faire, ou comment on peut essayer de bander le Drupal pour ce qu'on veut faire. Je suis Simon George, j'ai été dans le Drupal depuis 15, 16 ans, non. Je suis un développeur du Drupal, et j'ai travaillé pour Mackina Corpus. Si vous savez le nom, c'est parce que nous sponsorons ces belles éco-caps pour le Drupal Con. Mackina Corpus est une compagnie française. Nous faisons exclusivement un projet d'open source, et nous utilisons 3 softwares, donc le Drupal est principalement pour CMS, mais nous faisons aussi Python, et le Django, et nous faisons beaucoup d'open source web mapping. Ce que j'aimerais savoir, c'est combien de gens dans la salle sont développeurs ou project managers qui ont déjà utilisé le Drupal pour créer un site web. Ok, donc beaucoup de gens dans la salle. Combien de gens dans la salle sont plus de clients, donc les gens planent d'utiliser le Drupal pour notre prochaine site web? Ok, donc 1 personne, merci. Donc, si vous êtes un développeur d'Drupal et qu'est-ce qu'il y a d'autres sessions sur Layout Builder, c'est possible que vous n'aurez rien à apprendre dans cette session. Donc, si vous pensez, ou si vous hésitez entre cette session ou d'autres sessions, je vous encourage d'aller d'autre côté parce que c'est possible que, à la fin de la conversation, vous aurez rien à apprendre. Ok, donc je suis content d'avoir tous les gens dans la salle. Parfait. Donc, le premier des titres est de CMS à Page Builder. Donc, j'aimerais commencer par essayer de définir comment j'ai vu un CMS ou j'ai vu un Page Builder et pourquoi je pense qu'il y a une différence. Et donc, à mon avis, un CMS est quelque chose où vous faites quelque chose et vous utilisez le même contenu partout sur le site web. Donc, c'est principalement construit sur un modèle de contenu et comment vous pouvez l'utiliser partout, alors que, évidemment, Drupal est un bon CMS de ce point de vue. Et ce que je pense ou ce que je vois dans un Page Builder c'est quelque chose où vous customisez chaque bout de contenu et où vous essayez d'avoir plus d'approche de design où vous pensez de votre page pas dans le contexte de tout le site ou du modèle de contenu mais vous essayez de designer chaque page le meilleur. Donc, plus d'approche ou quelque chose comme ça. Et dans ma main, à moins de maintenant, Drupal ne peut pas être le meilleur outil pour ça. Vous pouvez voir dans le keynote qu'on essaye de travailler sur ça et nous espérons que dans le futur Drupal peut être meilleur. Mais maintenant, je dirais que c'est totalement possible qu'il y ait des plus belles outils pour créer des pages ou pour essayer de construire des pages avec un approche de design. Donc, je vais commencer de vous donner un petit peu de contexte. Je currently work for a fairly well known airplane manufacturer. On travaille on a web factory so lots of websites et the thing is that we are migrating from Adobe Experience Manager where the content editor in Airbus were used to create pages and to add some components in the pages and to override almost anything. So, with each page they were designing they could override the title, override the picture and so they they have no reflex in thinking as a content model because every piece of content when they reuse it they can override everything. So, we needed to migrate that in Drupal and the the first team that built the website was not from a Drupal background so they have no idea how we can how we could use Drupal the best et basically they were just appressing the website with the idea that Drupal is just another tool and we will just reproduce what we know but in Drupal and so when I when I started to create the session I had in mind something where I would try to illustrate the story and try to give you some advice for your next project so as you are all developers and are used to work with Drupal it's totally possible d'avoir des advices you know them already but I hope if I can change some of your minds it will all be worth it so the first thing I would like to do is say that you need to hire Drupal specialist because Drupal is a product and I work with a lot of good PHP developers that were not Drupal specialist and it's not something you can learn in one month or something like that you need to have work with Drupal work with the community modules learn how to best utilize what Drupal can do and so I guess you all think that since you all are using Drupal to develop but I feel it's really important to communicate to a client that Drupal is not a generic PHP product and you need to work with people that know Drupal and I think another thing that even in big project is sometimes a little bit forgotten is you need to train your clients so obviously that was not done on that project because I came to the project later but what I tried to do on a very big project so I mean this project has been ongoing for 3 years now is to try to train the clients so that they know Drupal and it's easier than to discuss about Drupal issues because they understand a bit how it works how the content type works what's the view what's the taxonomy and I feel then our discussion are better because at least the client has at least a vague idea of why we are doing that or why we are proposing some solution better than others so and I feel even today we are approaching project by thinking we are the experts and we will build the website even if the client doesn't really need to know what Drupal do and I think it's a mistake you need to train your clients so that they understand a little bit better about Drupal so obviously when the project started we just said yes to everything the business wanted so we try to recreate or they try to recreate how the website worked and so basically they try to create a page builder when you were reusing content so when you were using entity reference or things like that you always had the possibility to override the title override the picture override the description override every field and so there also it's built upon some kind of content model when you look at the database basically there are data that is copied everywhere with every content having at least several occurrences with different title different picture all depending on where it is included in the website so basically the when we when we got the website two years ago there were two content types one I would say usual Drupal content type which was the news so you had very structure content type and something that we are all used to work with and then there was a flexible page so basically a layout builder where you could put every block every component on the website and you could build whatever page you were dreaming of and the client was quite happy with that at first so because they were able to create every pages they wanted but the thing is that as we are on a web factory with a lot of website a lot of different clients and a lot of different needs something happened after a few years and so the message here is as a developer you need to say no to your clients sometimes because they don't have sometimes they have good idea about what they want for their business but they don't know like you do about the web quality or what is expected of a website so you're the the guardian of the web quality you're the guardian you're the user experience for your visitors and you need to impress the client that it's really important to think of a website as a a complete entity you are not designing only pages you are designing pages inside a full website otherwise after 2 years it became a complete anarchy where every page of the website was different and it was almost impossible for every user who was coming to the website to understand what was going on there were a lot of similar components that were reused in different context and so when you were browsing the website you didn't really know what the page was about how it was linked between different sections of the website and also the client was happy about how they were bringing the website basically the visitor were not staying on the website they were not browsing the website and they didn't know how to or base to to use the feature of the website so the website was good for the editor but was not working as a way to to interest visitors as a way to get the client for example to sign for the newsletter or to apply for a job at Airbus or thing like that so basic features that they had in mind were just not working at the time a decision was made and the teams that were managing the project changed completely and they decided to rework everything and they went from a company that were not a Drupal specialist to hire specialist for each part of the website so they hired a Drupal specialist for the backend and everything related to Drupal they hired a consultant for the UX as well so a dedicated company that was doing the UX they hired a good front-end developer which was something that was missing at the start of the project and so it was not a small decision because that meant as a project manager they needed to co-organise a lot of teams a lot of people they needed to ensure that they work well together which is something that is sometimes hard to do when different companies are involved that may eventually be competitors and for this project it was a little bit of a success story and it's something that we are all proud today that even as competitor we managed to work together very well to change the way the website was built so we started the new version of the project so that was 2 years ago after the website has been online for 2 years and we started with a UX audit both for back office and front office the UX consultant was doing the audit for the front office and as a Drupal Dev I was doing I've been doing the audit for the back office so basically what I've been doing is ask content editor to create some content while I was seeing how they use the browser and trying with my Drupal background to think how we could do better and how we could transform their content editing experience by trying to just adapt a little bit the back office we didn't want to rebuild the whole back office because we decided from the start that we would completely rebuild the front office and that was enough of a big project so we tried to just at least make their experience better without investing too much money into the back office and another lesson here is as we knew that the front office redesign would take some time when I said some time I mean something like 2 years, 3 years you need to still deliver value to your customer and so immediately after we came on to the redesign we started to make improvement to the back office so the web editor were seeing that we were doing a good thing to build trust inside our client and so they could in return trust us to do a good redesign and so accept to wait a bit for what would be the new Airbus front office I feel Drupal is a really good tool to deliver value early I don't know how many of you are familiar with the Pareto principle or the 80-20 rule how many in a room ok, so a few so basically this principle is that 80% of the value of the project will take something like 20% of the time the rest of the time will be dedicated to the last 20% and Drupal is a really good tool to build the 80% really fast we have a lot of modules like views that allows you to start really some screen really fast and you can then iterate on the screen and add filter little by little or adjust every bit of content for the client needs but you will be able to produce value really fast and it's something that I feel that way that Drupal is especially adapted to agile project where you need to bring value as fast as possible so what did we do for the quick wins in the back office the first thing we did was change the administration team so we went from Clairo which is already good to Jean just to bring some kind of modern back office content editor so it's really fast to do you just need to enable a team and then we started to do a little improvement to the back office as I talked a bit earlier about the flexible page which was so flexible that every component had tons of options which were really hard for the content editor to grasp and so what we did was the field group module to start organizing and prioritizing some fields on the blocks so that the content editor could see the most important fields to fill and then we tried to hide all the little options only for advanced contributor or some people that were maybe more familiar with Drupal so we tried to give them a back office where creating content was fast then tuning and editing the content took a little bit more of time but at least the most of the content editor would do their job a lot faster than before something that is not not really used on Drupal project I feel is the help text that you can fill on the back office form so for those that do not know below each field you can add an help text and on a lot of projects these help text are just never used and in the context that we were meaning having a lot of different websites a lot of different people working on the website sometimes subcontractor filling the content having help text to clarify what image format we wanted or how the text would be used in the front end clearly helped the web editor to produce their content so that it better switch their needs so it's a small feature that is directly built into Drupal core and I feel it's not enough used nowadays on big project you should really think about how you approach your back office and you should always dedicate time to ensure that you make a better back office for your content editors and last thing we did was to use some different widgets for example for the entity reference or for the taxonomy selections there are lots of dynamic widgets on the community so a jacks loading on the taxonomy javascript trees if you have a lot of terms and that in turn contributed to make really the back office better when people were waiting for the new redesign so about the redesign I've been done by the UX consultants and they tried to focus not only on recreating the components that were used on the website with a better design but what they proposed at the time was having different templates so instead of using a big flexible page that could accommodate every content they proposed to have dedicated templates for example for an event content type a service content type things like that where instead of using every component available on the website you could only choose 5 or 6 of these components but in return that would mean that every page of this content type would be similar to the other and also it appears that it limits a bit the possibilities of the web editors infini the website is a lot better because every page content type is similar and so the visitor really better understand how the website is about or how to use the content and the pages and I feel it's a factor that is the most beneficial for the website as a whole because it ensure web quality and less cognitive burden for the visitor in return as you have a lot less components on the website each content type it's easier for the web editor to choose the one that will do the most impact comparing to what they need so basically here what I'm saying is maybe sometimes you need to limit the option of your content editor just to ensure better quality for your website so here to talk a little bit about page building I admit I was not I didn't think there would be so many dev in these sessions that's why the solution is not that technical but feel free to ask a question at the end and I'll be happy to answer what I can say is when the website started only paragraph and layout builder were considered because at the time the Gutenberg initiative was not I would say mature enough it was mainly a decision between using paragraph which was maybe the historic solution or at least something that was coming from Drupal 7 while layout builder was something more recent maybe with less of an ecosystem at the time but as it was in core we choose to go with layout builder at the time just because I feel that most of the time better to use something that is built into core because that ensures the community will be able to standardize into something I don't think going with paragraph would have been an error but it was just a choice at the time to use layout builder again what I would encourage you is to rely on the community so I feel if you are doing your website using almost only Drupal core and doing everything by hand you miss a lot of what the community has to offer because if you have followed the session yesterday, a lot of community is currently standardizing on layout builder and creating a lot of additional community modules that can really enhance the solution and so really I think what makes Drupal great is to have such a big community that is always creating new features and new modules that you can add to your website that's what we did in the redesign so basically we went from only using layout builder to use layout builder with a lot of additional modules so I won't list them entirely here but mainly layout builder restriction, layout builder lock but basically if you want to see what we did or to reproduce what we did there is a core issue currently regarding the layout builder improvement and everything that we did is in the issues that are on this issue so basically I was quite happy to see or happy, I don't know if it's the right word but at least it showed me that the whole community has more or less the same needs that we had in Airbus and the whole community is trying to address so the current UX issues on layout builder but the restriction as well that can be an issue for content editor because sometimes you need to limit their creativity I don't know if it's a specificity of our team but if we give them options they will use them to the fullest of their potential and try to really destroy the website so limiting their creativity was in fact the way to ensure the quality of the website in the end so I really encourage you to see this issue because it makes me really happy for the future of what layout builder will bring to the community Relying upon the community is for me not enough and I think what another thing that made Drupal great is that a lot of people in the community are actually contributing and so I would encourage you as well on your project to not only use the module but be part of the community you are obviously since you are here today it's a great issue when you find bugs sometimes a thing that is mainly underestimated is that project manager can contribute a lot to Drupal because module maintainer don't have much time and so just closing issue by saying this is a duplicate of this one or this one is more major than this one or things like that can really help module maintainer and so module just triaging some of the issue makes the developer able to release something, a new version early or things like that so everybody can contribute something to the community so I would really encourage you to do that I will try not to evangelize too much but basically as the community and especially when using Drupal you can go faster and further use that but the session was about can Drupal do patch builder as well as CMS and I feel that yes we can there are today lots of modules to do that but the thing is I really don't think you should it's not the main function of Drupal Drupal is a CMS before everything else so you can do patch builder but thinking of Drupal as a patch builder and trying to create every page of your website with a patch builder is to me currently still much of a burden you will need to do a lot of custom code you will need to adjust a lot of things and it may not create in the end the developer experience you want in your team so yes it's possible but it's not easy it may be in the future but right now it's still not ready to do that and I hope you have a lot of questions I don't see any Q&A on the live but if you have any question there is a mic in the middle of the room that you can take it can be more dev related than what I've talked about if you have a really precise question about how we build a solution I will do my best to answer it I don't have any question I think the food will be ready soon so yeah it should be on hello ok so how many editors because we often like when we use the layout builder and go from the sign to finish website one of the quest like there's a tendency to always add extra options and no so the first version of the website had something like 20 components but even on these 20 components I feel something like 5 of them almost were the same just with a different frontend rendering so they were only basically teaser to another content but with a different layout or something like that and what we tried to do on the redesign was create only one component when we wanted to have a specific goal in mind so for example advertise another page or something like that we created only one component but by building upon the UI patterns module we tried to create variants so frontend variants of the same components so we had a lot less functional components but with different frontend rendering that allows almost the same flexibility but with a very simpler data model and with a very simple contribution so basically we tried to keep the feature but really have a cleaner UI and better content editing 20 components to nowadays we are more something like between 10 and 12 yeah but only so not functional options but only design options before we had as well functional options or things like that so but you know the clients we will probably have something like 20 components in a year or so the website will never be done but yeah yes so you said that you used to have a different CMS before and they want to Drupal but are they using Drupal like with structured content or is it only page building that they do so currently the structure content is mainly for the news or press release or something really editorial almost every content that is not a fully editorial content is a page building I'm not really happy about that and for each new content we try to ensure or we try to push for a more structured approach for example we recently build the event content type and we try to push for a lot of structured approach but on almost every piece of content there is at least a flexible part so the beginning of the content type there is structured content and there is a little layout builder at the end to accommodate for more options for the page right and you said that Drupal shouldn't be used this way but that's what many people want yeah how do you feel about that I mean it's not that Drupal shouldn't be used this way but when you use Drupal this way you lose the structured part and you lose the reusability you can reuse blocks or sections inside the layout builder but you lose the entity reference, you lose the views you lose what's in my mind makes Drupal more powerful or easier to use than some other product and sometimes when I see people using only the layout builder part I'm wondering if they shouldn't have choose another product to do that so I'm wondering in that case for the version of the website I'm really wondering why they chose Drupal yeah that was my other question ok so I know why they chose Drupal so and I feel it's because Aquaya has a really great commercial so for big client I think it's the main reason but I don't think the client realized the trade off or why they were choosing Drupal from other questions bon appétit