 Okay, fine. So, hello. Good morning Amsterdam. Thanks for joining my session. It's about using Drupal as a content hub and making a decoupled web application out of it. My name is Jan. I'm a managing partner at Trio Group. We're one of the biggest B2B agencies in Germany. When I'm not here talking about Drupal, you can find me riding my bike in Italy and drinking the best coffee in the world for just one euro. So, yeah, maybe you want to join me. First of all, I want to share a very successful slide. We used, yeah, nearly all of our Drupal pictures. So, that's, yeah, Drupal, Pac-Man is eating Zydecore and Type 03. So, this is what we built out of, built with data. So, we just were creative interpreting those statistics there. And, yeah, obviously, this start was successful. So, we won't be climbed otherwise. We wouldn't talk about this case study I will show you right now. So, what we will hear in the next couple of minutes is a story about a project we developed for our client where we had a successfully coupled project successful from the perspective of the client, not successful from the perspective of the developer. That's important, different. So, in the end, yeah, we had a happy client. That is most important for me, especially. What are our client's challenges? Our client is Harting Technology Group. They are the world market leader for industrial connectors. So, their problem is that their products can't be seen. They are built in big machines or in small machines. So, they are always hidden and there's a challenge for their marketing. Otherwise, you just cannot understand where those products can be applied. They have data in different sources. The two most important is Drupal for all the marketing and contents and the SAP Hyprous Commerce System and the product information management tool in the back where all the product data is stored. And of course, they have multiple marketing channels like, of course, the web, trade fairs as well, other you want. And they have a huge sales representers team. So, our mission was to create a world out of class where we can see all the products that are usually hidden. We wanted to make it available everywhere on any device at any place. And at the same time, it should be easy to maintain. And we wanted to have very quick updates to the contents. And we wanted to have new interactive market graphics. This is the solution we built for the client. So, in the background, you see such a market graphics. It shows where the products can be used. In this case, it's a German IC train. So, other use cases are wind energy generators, factories, or, yeah, cities. In this case, you can find hearting. Yeah, it's the cable, the charging cable for the electric cars. This is where hearting happens here. So, and this was the challenge from the market perspective showing this to the clients. And what you see here is the market graphics. It's integrated into the website. What you see is a real time footage. So, there was no cutting of the video. It's just a record of just a bit of clicking and browsing. And you see, you can dive into this train and explore where all the hearting products can be applied. You see it's only small pieces of contents. And later, you can see that there are also products. You see it now below, products from the SAP system or links to the triple system. So, let's dive deeper. What do we have? We have links to triple nodes that are already present. We have products from SAP that are just linked here. We have original content that was created, especially for those market graphics. Those panels below, this menu is just paragraphs. We're using paragraphs in the back end, the triple back end to control those sections of those market graphics, those images or just images that are uploaded to triple, and also those interactive hotspots are managed within triple. So, everything in one place that was our approach to make a really convenient and easy to use back end for the client. So, when we look at, this is some architecture on a very high level, we have our corporate website using triple, of course, which is at the same time the content hub. This system is connected to a translation management tool. So, they have about 25 different languages in their triple system. And all of them can be translated over this connection to across, they use across as a translation tool. We have a connection to SAP Hypers, where all those 20,000 articles come from, including all the images and so on. So, we store native content in triple. Every product from SAP is native content in triple. So, and this allows us that we only have one connection to the market graphics, where we can use all the stuff behind triple and the content hub. Market graphics are integrated into the website. And the website, of course, is, and market graphics is back linking to the website, as well as driving traffic to the products where, yeah, the sales happens. And one important thing that led us to decide for decoupled architecture was that they want to use the tool in different use cases, for example, trade fairs and the devices like laptops and tablets of the sales representatives. So, basically, the technology behind it is quite simple. We have Drupal, it's the corporate website. And the market graphics app is just a Vue.js application. There's no separated backend. We only have Drupal as backend, and we're just getting all the data from the FBI. And, yeah, at the end, we're just serving one thing, the file from a static asset server to provide this application, which I think could easily be done by a floppy disk, I think. And offline usage was one use case. Since we are in Germany, we do not have the best mobile connection. We always have offline issues. So, yeah, what happened? We just used Electron to make a desktop application out of this Vue.js application, which is installed on the sales representatives devices. And there's no JS crawler in the back, which collects the data from the APIs and just stores them in the local storage for, yeah, first purposes for caching, second purposes for the offline usage. So, once you update the app, you can go offline and use it on using this picture. This is from the HMI trade fair in Hannover last year, where Harding took our application and put it on those, yeah, giant 12-inch touchscreens there. You see this little pixel, single pixel there. This is the market graphics app. The backend, we only have one content type and one market graphics. So, this ISE train, we saw in the video, is just one single note. And this note is just collecting, aggregating all the content that is already present in the system. Yeah, as I said, we have the connection to the cross server for the translation management. The page is quite long. It goes ages below, but it's very simple and it's only one place where the editor has to go. So, first of all, we have the different sections, which are paragraphs. They can also be nested, so we can have hotspots in hotspots. Yeah, and we only have simple plain text for those small pieces of content. More interesting is the other part, the touchpoint management. So, first of all, I need to upload an image. And then we decided to use a separate window. We created an overlay, otherwise usability would be just terrible. And this is what you see in the big picture. There, the hotspots are created and just moved with the mouse and positioned it on the image while they should be located. And we decided also to store them in with relative positions to be able to make this whole application responsive for no devices. And this is where SAP products come from. So, as I said earlier, they are native content in Troupel. So, we are mirroring them in Troupel, which allows us to just use this simple autocomplete field of Troupel. They just need to have product number, type it in, and then that's it. They don't need to worry about translation, about the right image, about product updates, or even products that are removed from the product catalog. That's happening all automatically because of this connection to SAP. So, that's it. And it's really convenient for them. Total difference to the situation before Troupel. They used type of three before. And, yeah, they were really happy with that. And then we have this SAP product on our website. And, out come for our client, three important things. Speed, they can easily update the thing. They are fast to the market. They can quickly roll out the new version of their market up. Convenience and usability, of course. For me, the most important thing is autonomy. They can do it without us. If they have a new industry sector, where they want to have the market graphics for, if they have a new product in the ICE train, they can just add it. Add and remove contents. They don't need us. So, we have free, and the client is also free to develop more and creative ideas instead of doing the same stuff over and over again. De-coupled without pain. Yeah. Why did I say that often we developers do decoupled projects because view is a nice technology or decoupled architecture is nice. And we always want to do such projects, but we forget the clients. And clients often feel that we are experimenting with them. And that makes them unhappy. And, at the same time, decoupled projects make projects often more expensive than they need to be. So my advice to you is think of, is this the right use case for a decoupled project? If it's just a small and simple website presenting some marketing content, don't make it a couple websites out of it. It's just expensive, nothing more. Thank you for contributing. Don't forget to join those workshops. And if you want to, please take the survey, give the Drupalcon team, and also me some feedback if you want. Thanks for joining, and have a nice Drupalcon. Any questions? Hi, good to have you. Can I ask you something? How did you make ElectroDev.app on the Vue.js? Did you use some kind of inverter or how did you do it and do you copy it along ElectroDev? Does it actually work? To be honest, I can't tell you. I was the developer, but I can connect you with our developers about the speed. I can tell you, it was quick. So it took only one day until we had the first version of it. So it was quite easy. That was the easy part of the story. The question is if there was a module for the touch point. So no, this is a custom implementation. There was no system module. And no, unfortunately, we did not contribute it. Probably, yes. We have another use case where we will have this touch point management. So this is maybe the situation where we can contribute. Yes, I asked you to contribute. We should. No questions? Thank you. How did you implement the translation, not inside Drupal? Exactly. So we used TMT as a Drupal module. Then we implemented the API of the across language server. And so the editor just says I want a new translation for this page in language English, for example. Then this is automatically transferred to the across software and then humans translate. This is still done by humans. And once they are done, it's getting back the way to Drupal. And the editors just need to approve the content. So there's no copy and paste, no email attachments, and so on. So did the way from the online editor to the translator and the way back is this is fully automated. Okay. Thanks. Have a nice day.