 Good morning everyone. Thank you to be here on the day 3 of Drupalcon and you're all party survivors. I can see it on your face. The one that survived the party from yesterday. So thank you for being here and today we want to share with you a use case about the UNESCO. UNESCO built and now runs a web factory and how we managed to do this technically and methodically and we'll talk about the future of this web factory. First of all let's introduce ourselves. Denis from UNESCO with web architect from UNESCO was supposed to be there but he has Covid so he didn't come to Lila so we're gonna do our best to make the things shine like UNESCO. Je suis Sylvain Moreau from ACCESS, I'm the CSO, I'm the founder of agency in 2001 and today is my 10th anniversary as a Drupalcon speaker. I was speaking in Prague in 2013 so I'm very glad to be here to speak again. It's really an honour and maybe John wants to introduce himself. Yes, so I'm John Fenouy, I'm the technical manager and the tech lead on UNESCO. So what will be covered in this session, first we will introduce ourselves. Then we will talk about what was there before the redesign and we talk about the risk and the challenge, how we made it, see some insights about how we made it technically in terms of design. We talk about KPIs, about results, what is there since the new UNESCO.org launched and talked about the future, how we are going to endow the production of new websites within UNESCO. So let's introduce ourselves. First of all, what is UNESCO? UNESCO, we can now hear talking in these times of conflicts. UNESCO was built after the second war to prevent wars by bringing education and culture to everyone. So I won't be long on this one. And if you want to remember some key figures, you have 194 members, it was 193 but there was this thing with the United States, they were out and now they are in again because they paid. More than 2,000 members from 168 nationalities, so it's like the Babel Tower but a good one. You have 600 million dollars BNL budget. What is really nice is that UNESCO is protecting 10 millions of square kilometers. You have biosphere reserves, geoparks and 250 million people are living there so it's really an impact on the planet that does UNESCO. And there's also all this half a million people, children benefiting from educational programs. So it's really a nice action all over the world. And you also have more than 10,000 associated schools and it's the educational part of UNESCO. So I'm sorry, Dennis from UNESCO was supposed to be doing that. He's doing that better but I hope that you, everyone here knows UNESCO and knows how it brings education and culture to the people around the world. And I'll talk briefly about access and I founded this agency in 2001. We've been doing Drupal since 2006 version 4.6. The first one who was introducing CCK, I think. Who did CCK in this? Nice. And we are a sponsor and we are proud to be a sponsor for Drupal Conlin. Come and stop at booth 2. We have lots of goodies, a lot of swag. And we have 15 wonderful people being able to talk to you, to share experiences. So don't hesitate to come and see us. And we are 26 developers, we are 42. And we take care from our customers, from D0. We have a UX, UI design people. We work with maintenance, SEO, SCA analytics. We all do this in-house because we are part of a bigger group. And our customers are public institutions, cultural institutions, museums, big NGOs like WWF. And we are part of a big private companies. So let's talk about the challenge. We have to remember that there was nothing in terms of web factory and in terms of Drupal in 2019. So what was there was diversity and complexity. It has been 15 years since UNESCO take people started building websites. And there were all these kind of technologies. Drupal 7, 8, but type of free, ACP, there was cold fusion sites. There were Django and Python sites, custom PHP, custom Java. It was really a mess. So you are also the diversity of the audience. Because every website had to address some targets. And it was really diverse. So how could we change this? The idea that was set up was to create a multi-site platform. In order to prevent technical debt and obsolescence. We had to update the technology stack to be up to date in terms of security. But also to simplify updates. Because updates on all this previous ecosystem would take days. You had dozens of technologies to maintain. And most of all, you had to know that when you were on a UNESCO website, you can feel the graphic coherence and the algorithmic one. So this was really a challenge. We also had to enable the data cross-reference. Because as you will see there are millions and millions of contents that had to be shared between sites. Reduce the number of websites. 200 is too much, even for UNESCO. And after that, build some migrate energy strategies. We have these 200 websites. We need to reduce the number of them. But how can we migrate them and how can we cut them? And another risk and challenge was to train and help site contributors. They are all over the world and we need to train them. And for that, you don't need one partner. But you need to rely on multiple partners. And how can you onboard these partners on a reliable base? So to remind you of the figures, 200 websites, almost 200 websites. 23 million contents. That means a lot, a lot content to share, to publish and to migrate. 12 languages including some special ones. And only 15 months, 20 months to do that. So the challenges was to design this multi-site technical design. We needed at least 8 site profiles to migrate everything. Every site for UNESCO. We needed to design multi-language sites. Because you have 6 official languages at UNESCO. Including other languages like Arabic. Or non-enduro-European languages like Chinese or Russian. So this was really a state for technical states. And design states. The pace was really important. How can we handle millions of contents and migrate them to new sites? There was also this take and challenge to have a single back office. For contributors to contribute only in one place. And then after that content they need to be shared between websites. So there has to be a lot of communication between websites. Lots of volume of data, 23 millions. And also the real challenge was to communicate with every part of the web ecosystem of UNESCO. That means term-store, which stores every single term for documentation. The EDM, UNESCO, Enterprise Data Management. We have to interface with open data, transparency portal. The SSO, Azure Active Directory. We have to handle all the structured data stuff with Strapi. All the events. Events managing, which is a custom development named GMIT. And we have also to index and search on every content with a password. And all that being part of a design system. And to be hosted in the UNESCO data center, which also was a challenge. So how we made it? Now we talk about the risk and challenge. We need to know how we made it. In terms of planning of schedule, it started in June 2019. UNESCO did a consulting mission with Smile. I think you know Smile, they are here, also a sponsor. And this consulting mission led to the production of RFP. The main document of RFP was a big backlog with 200 lines with every single functionality needed for this web factory. The requirements of RFP were listed. And then after that we answered that RFP. There was negotiation for 3 or 4 months because it was a really big RFP. And then in August 2020, we launched a project. And we were able to launch the first site on 2021. So that's like 8 months. It's really short for that kind of stuff. Because you will see that behind the web factory there is a lot of work. And then on September we launched 2 more websites. And the real number one goal of this project was to launch the UNESCO.org website. And we did it in May 2022. So I will hand it to Jean. He will talk more about the team and the technical challenge. All right. So for the team on the project, there was one project director, one UX designer, one UI designer, one technical project manager. One technical architect, full-time backend developers and two full-time front-end developers. A special dedicate to the architect that you know. It was Franck de Roche. And on the UNESCO team, there was one project director, one web architect and developer. One project coordinator, one editor coordinator and one project from SMITE. So the first requirement, it was to have UNESCO.org out of the 75th anniversary. So it was 9 November 2021. For that, we had one big backlog and we had to adopt a semi agile methodology. So the methodology was to have one design phase about 5 months to review and refine the backlog. And produce some specification and produce the design system. After that, there was a development phase for 15 months with 5 sprints and milestone for each sprint to have a review. Until UNESCO.org release. And after that, there was 6 sprints for other websites based on other profiles. So all along the project, in conception and after on development phase and to the end there was 20 technical workshops during all phase to refine and produce technical specification and review some specification. So for that, there was a single design system needed for the UNESCO website. But it's not only for new external websites. It's also for all the websites like WHE. We work with our long term partner, thanks to Dacharajif, who has made a great design and led the WXUI phase within UNESCO. For this, they produce 2 or 3 tools. So 2 separate Figma, one for the components and one for the template. Because it was needed to have a bootstrap based theme. So there was 2 Figma, one for the component and one for the assembly to produce the final page. And after that, a big documentation, about 100 pages to define the behaviors on the page. So yes, you have a bootstrap-like website that you can see by clicking on the link after the presentation when you download it. And it's online, so in UNESCO.org. And there is also code example when you click on each port. And to zoom on how we did it, metodo Gilek Kali. Let's say this word. There was an initial audit because for the RFP, the UNESCO, they already did produce wireframes. So this was audited by Dacharajif. And then they did 3 UX workshops. The first one being the audit presentation. And then I did against this audit presentation. There was the second workshop, which was a cart sorting one on site map, user journeys and navigation. And this led to the third workshop presenting the new wireframes and refining them. After that, then we could go through the UI design phase with a creation of a general design matrix. That led to design sprints, many design sprints. And then they iterate on design and they built up the design system. And finally, after that, there was a long verification phase to see the design phase matched all the user journeys. This was very important because the user on the UNESCO website, they don't have to get lost. They immediately know where they are. And there was also this verification against the site creation scenario. Because remember that this is a web factory project. So you have to think about how we will create the site and how we will pick up all the design elements before creating the site. And finally, this was finalized in the document which is a design system that you can see. So you can see the results and the iterations against that. Every single component, every single element is designed in every place and every color and it handles all the fonts. And you see this atomic design system and the bootstrap-like system that you can test. And you will see that on each element, like Jean said, if you click on it, you have a bootstrap-cob that can be used in Drupal but in any place. And now let's talk about technical specs. No, we are in Drupal 10. So you have the choice to have a multi-site installation. And we are using it on development environment. But in production, it's a lot of single websites. And you have eight installation profiles. So not all profiles are designed to have multiple instances. For example, you have Unesco, so you have only one Unesco.org. But you have the article platform, which is used to contribute articles and to share to other websites. So there is only one. But you have many reports because there is a lot of documentation and websites to talk about documentation. Multi-initiative, multi-institutes, multi-campaign websites. And only one Unesco-Media library, so that's why you do that. And only one web form provides that embed of the form that will be embedded in all the websites through iFrames. So we had a versionist strategy with one main GitLab repository. And for each website, it was one fork repository. But everything is synchronized, so when we push on the main repository, if there is no big divergence, so the modification will be applied to other fork repository. For that, we're working on continuous integration with GitApp CI. And to optimize it, and to optimize the speed of the deployment. So we have shared artifacts from the build that are fit to all other fork repositories that have many divergences. And also for the server configuration, you have Ansible. And we are using GitLab CI pipelines for the deployments. So the hosting infrastructure is mainly composed with three backend servers sharing a file system with NFS. One load balancer in front of that. And three various rivets for C. For the database, we have two Galler-RAMIS clusters with master and slave. And because there is a lot of functionality of such, I will detail about it later. You have a three solar shards from solar cloud. And obviously for the memory cache, you need to have a solid one ready. And as we said before, it is hosted in the UNESCO data center. So the UNESCO does all the hosting and maintaining of that. But if you zoom on this infrastructure, you can see on the left the big picture with the FC. On the right side, five load balancer, which is in front of that. And then you have this zone A and zone B, which under all the web servers. They are zoomed over there, so you can see the load balancing, various proxies, the SQL servers that are master slaves. And then you have this zone C, which under the solar cloud. This is solar load balancing and we've shared solar servers. You can see the details of one server here. And you have all this zone D, which is managed to design to host the Strapi because there are a lot of structured data. And Strapi is the LSMS that is used to handle structured data. So it has its own infrastructure inside the data center of UNESCO. So I will detail a bit about the architecture. So here you have two blue parts. So here you have UNESCO.org with many content types. And some satellite websites with different profiles. But some single profiles like Arctic and taxonomy, sharing, major library and web form library. So are interacting with other websites. In the yellow part, you have all external services. So for SSO, the CRM to get a document from UNESCO to get the event. So there is many, many connections to automatically create the country page with many information. In the purple part, you have a chart and graphics for complex graphics that can be handled by clicking on the interface of Drupal. So because there is a big need for data, so they're using Metabas. And after that, we embed through our frame the graphics. But in some case, we have interaction with filters on page and filtered data on the iframe. And here you have a specific part for structured data. So I will detail later what is structured data for UNESCO. But you have to imagine that you have different data that doesn't fit the content type previously anticipated. And they need custom design. They need custom filtering process. So here you have a part for structured data consolidation. And after, they are send and synchronized with the websites that need it. Here you have a special part for all websites. So like World Heritage, Intangible Heritage. That are not part of the new platform. But are using the theme. Green part, so you have a sunshine. Useful for every website. And all structured data sites. Here, that will be migrated. So no, not everything is migrated, but a lot of data. And it will continue to have a new website. And the architecture to be more and more complex. I will let you share with you Azuma and the article sharing. So article sharing is not only article, because it's also some media embedded with article. The same taxonomies that have been used everywhere on UNESCO. Because the taxonomy terms that we are using on this website are also used for external tools like CRAM, you know the technology. So for that, they are using the Microsoft Timestore. The article, website and profile is pulling from the Timestore and sharing all the taxonomy to the website. We can also contribute information for the website like the main navigation and the alert. There is a special announcement for every website. For this, we use the anti-toucher module, and since to Grim Reaper, that is the main contributor of this module. And this module is using the JSON API. It's a very, very useful module that we are using in many projects. And we continue to participate in it. We have the ability to share to multiple destination. But we are careful to have only one main destination for two reasons. So it's for SEO, because if you have the same content on multiple websites, you have duplicating content in the search engine. And to target which of the websites will index the content, because if everyone indexes the content, you will have some problem. And many duplicating the search. So I already sent the Microsoft Timestore. And to optimize the synchronization, because there is many, many content in different language. So we only check the last test modified content since the last synchronization. It's very raw, but it can happen very sometimes that we have to synchronize everything because it's a very, very, very long time process. And to avoid fight duplication, so it's a good interesting part. The cluster of servers share the files and in a server you have all the websites. So we decided to create a new stream wrapper. So you know the stream wrapper as a public or private. So we made a new stream wrapper to target the location of the files only on the article website. And to share it after to the other website. So only the metadata is shared and the file doesn't move. It avoids a lot of hardware space occupation. And we represent the fly with the JITAN API field announcer to replace the current location with the stream wrapper. Another interesting part was to respond to a very big need to have dynamic content list that share content from all websites. The main goal of the UNESCO is to have connected websites. So that's why the search is so important for this website because it's only the command point for all websites. And so that was the fact. I appreciate every content. And contributors are trained to use paragraph in the back office. So they can place many dynamic contents before inside two, three of this block in the second page. We wanted to have an easy-to-use system for contributors. So they're going to the search page, they're filtering, they're sorting the results they want to have. So there is many filters to do so. And they only copy past the URL to the paragraph. And after that, the content, the content displayed is exactly the same as the search. But they can custom the display so they can have a great display, list display or for geolocated content, have a map display. And so they can limit the number of results that they want on the page. A third part, that is a big need. So I introduced you the structure data. So structure data, imagine you have some paints to display on the page. And after that you have the number of generalized skills and the inventory of each card of each journal. So you will not have the same template to show. But all these templates are custom. And there is many, many, many, many. So we can have previously prepared it in Figma. But first, true to data, so we will need to create a custom template, a custom CSS, a custom JavaScript. The first part, at the left, is the data source. So there is many, because some data from JSON, some from Excel, or maybe some from Webformer. The main things to do is to consolidate them to have the same structure or a part of the structure that will be common to the other content of the ecosystem. So that's why we need migration script. And we are using Strapi. Two, so it's a small CMS with JSON exposure, JSON API exposure. Two stores of the data and maybe review it if it's okay, if we have consolidated it. After that, all the websites that need the true to data they want will grab it from Strapi. So a true to data is a content type that will display each item. But there is maybe in a true to data 100, 1000 of data. So they will need to be aggregated from one parent content type. So this is a true to data hub. The hub will display the list, have a main page and have a custom menu. And the configuration to communicate with Strapi. So we say, what is the machine name from Strapi? For more, I need to grab the data. And you have some custom display for each data that will be listed. So if you want to add a tag or remove it. But also in the list and grid display there is a big functionality is to have dynamic filters. Because some of the data needs filters that it's only for this data. So when you have a painting, so you need to know maybe who painted, which country is from the painter. But if you have a journalist skill in the world so you want to know whether a journalist is born or where he's died. So you need different filters. But that have to be dynamic. So you can't use such API to say, okay, I want to declare this filter. So for that, we made a taxonomy with three levels. So the first level is to declare, okay, this is the name of my studio data. The second filter is, this is the filter I want. And which fields are mapped in Strapi for this filter? After that, we are using migrate to import the data and the values of the filters are imported automatically. And the content are indexed in solar. This part is for a small problematic. But when you have multiple profiles that share common features so you don't want to connect to each website to do the configuration to export it and after to apply it. So we have Unesco.org that contains a module of functionalities. For many other providers, it's the same content type from others or from Unesco.org. But sometimes there is a content type that is different or will be removed. So for that, we are going to Unesco.org. We are, not the website, but the profile on a local instance. And we are making the configuration, exporting it. And here you have the script that you can write it after the presentation. So maybe there is a top or the bottom that is cropped. The main of the script is here to apply the diff of the exported configuration to other profiles because for each profile, you have all the configuration, there is only small functionality that we have split with config split. Many of functionalities are directly put in each profile and it's a complete profile. Ok, thank you for listening. Before going through the results of that, we wanted to say that it was really hard to pick some aspects to show you because as you can imagine, this is only a few features that we did for Unesco. It's a 20 month project and it's still going on. So I hope that this editorial choices taught something to you. To talk about the results, you can see that there are 34 new websites since the launch of the first website two years ago. We have a new design that is adopted worldwide all over the Unesco website and all over the Unesco web ecosystem. And the main thing is that they have increased the visits by 25% in terms of SEO which means that when you add performance, quality and you have a UXUI that is tailor made to your users, you immediately see the results. 25% is huge for Unesco and your design. We have trained, not we, but Unesco. They have trained more than 100 editors worldwide. So more and more people are getting used to the back office and we only have positive returns because it's Drupal 10 and it's Gene or the back office. I think it's Gene so it's really huge improvements for editors. And the time to market for a new website is less than two weeks and if you take the technical time to market it's 30 minutes. You only need 30 minutes to create a new website but the time to market is made of content editing, content reporting, migration and configuration on the servers but now they can produce a site in two weeks. And to talk about the feature the good thing is that we have now only one single base to maintain. So there is strong code base with eight installation profiles and that guarantees security because as you've seen yesterday in Anne-Sophie presentation in Francis we have everything we need about continuous integration to guarantee security. We have a powerful design system that is used by every website and everything is maintained by a single team. We have a maintainer of a core of the system. There is also one single base to rely on but this base has to be extended. So in 2022 UNESCO issued a new RFP to get more people in the web factory so there are deaf people from back mobile and also UX, UI, SEO, analytics people and the target of that is to be able to scale. So now we have this web factory which is stable and reliable and we can work with multiple actors that has to be documented and they need a strong code base but they can rely on that. And the main goal of that is that we have a flexible model so the priority is to work inside the factory so the new contractors they are pushed to use the installation profiles to extend them and to develop that but you can also only use the design system if you want to do a WordPress site you can do it inside and only use the design system so that's a possibility and there's also third possibility for major websites you can fork one of the installation profile and you can build a new project up on that I will show you some free examples of that right now free sites are in that some use cases word heritage site is called fusion site which was existing previously and now it has already been redesigned to use the new design system so it's really practical the same thing for intangible heritage only it's PHP code custom PHP but it uses the new design system and then you have the core data portal which is really a huge website for UNESCO it's a code fork from the web factory we have regular things when we update the factory the core data portal is also updated and it also respects the design system so you have these new possibilities you don't have a strict frame you have a strong base it's not a strict frame where you are inside you can evolve from that and all this has to be documented and managed and that's where we guarantee the code base so thank you for listening I think we have 5 minutes left for the question thanks a lot for the presentation it was really interesting could you eventually elaborate on the choice of Strapi for the content model is it something you've used before or is it something that was used at UNESCO ? Strapi wasn't used before by UNESCO it was the advice of the person who was considering for UNESCO and it was a good choice maybe a bit too much but I would try to have a small place when you can create something or some sort to put in data with an API and after you can consult it maybe change some information that you want to normalise and after that it's a pure API so it was a very very small solution to quick edit and aggregate the data there was an interesting figure on one of the first slide something we don't see all that often there was mention 3 10 days but what was that in practice you mentioned 6 full time developers from 10 back that's 2 and a half even just using the 310 days that's 2 and a half months of development and you worked on this for 15 months 20 months so we are an agency so all developers are not working full time on each project so that's why what was the the thing is we only put senior and expert developer and architect on this project and they are not available full time and if you put too much resources in a short period of time it only leads to dissipation and we decided to it's like you cannot make a baby in one month you need 9 months of thinking so we decided to have this space because it also respected the internal schedule of the UNESCO so it's not a big a big mandate ratio but when you put all the expertise of senior profiles it's worth it any more question so I think that the video and the slides will be available in a few days so if you want to take some information about the infrastructure about the config, split scripts that Jean shared with you will be able to and will be happy to share them with you so thank you very much for listening share any question