Komplett Group and Umbraco

Hello? No? Hello! So, hi and welcome and thank you for joining our talk on how we revolutionize the CMS, content handling at Komplet Group. My name is Vidar. I'm a web developer at Komplet. Yeah, and I'm Kenneth Solberg. I'm working as a web developer at Callwise in Norway. Been doing Umbraco work for about a decade or so. So... Yeah, I've been playing with Umbraco for almost three years now. Three years, yeah. In a small scale. So, just let me quickly introduce you to Komplet. We are a group of webshops and it was mainly electronics and computer equipments, but we have grown and added baby equipment and makeup and car parts and insurance. Lately, we started a mobile company as well for providing subscriptions. And, yeah, we have a lot of numbers. So, but it's quite a big company. And... We're not stopping here. We started in 96. This is the first website we had in 97. Luckily, things have changed. So, we now look a bit more like this. And... We started to use Umbraco and I need to tell you some background story. But if I tell you everything and all details, you would probably fall asleep. So, we'll take the short version. So, we have the platform we use. It's self-made for the last 15 or 16 years. So, it has grown to be a long-living monolith now. And its name is Chrome. Got that name way before the browser, but we didn't bother to talk to Google about it. So, one of the main issues that we have had is that there's no CMS data. There's no CMS that runs the platform. So, we just made tools when we needed them to handle content. And... Yeah. Those tools are not great. I'll show you that later. And after a couple of years of searching for a third -party platform and to discuss what way we are going to go, if we would like to replace it with a whole new system, or... Yeah. We decided in early 2014 that we would stay on the platform we had. But this time, we now would grow large and we needed to expand and increase the speed of delivery and increase of the features and delivery capacity. So that we can work with more than one project at a time. In 2014, we were a rock band of five. And... 2015, we were an orchestra of 50 developers. And 50 developers. One code base, one solution. It's really painful. We needed to have a queue system almost to merge to master and it was a lot of conflicts. So, we decided to split up the... The monolith into services. And... We still didn't have a CMS. So, we needed to figure out how to solve this. We wanted to stay on the platform for the rendering part and everything. So... Still... Split it into services. So, the requirements changed for the CMS. So, we needed to have a system that could serve several sites. And also several sites split into multiple projects. And it needed to work as a back-end tool. And perhaps the most important thing that we needed to be able to extend it with our own custom-made tools. So that we can fit the business... How they would work. The users had worked there for 16 years and they knew what they wanted. So, and how they wanted to work. So, we set a strategy to that architectural decision we made. The service architects. And... So, we wanted to pick one tool at a time and replace it with a new tool. With a new CMS. And a clear tool that we needed to do something about was the campaign manager. Who created the campaign pages. The front page. The landing pages for each menu item and so on. So, you have the front page. Department page. Which we call it. It's the menu... Top level menu there. We have category pages which is the left side menu items. And also stand-alone campaign pages. That... Would work for... Selling a product. Typically links from external ads and department pages and front pages would link into a campaign page. And now you get to see the system they used for this. One of my colleagues who has been working there for ages. He asked me, please, Svidar. You need to show them where they came from. So that the revolution would really make sense. So, to create a page. A page like this. They used this system. So, you can see a list of components there. So, you have banner images and you have product boxes and everything. And you would add that one at a time. One box by one box. And to handle all those different components. You use this. This is no CSS. No magic happened. Actually, the most... The most advanced with this page is the character counter of the abstract copy text. To display that you have 160 characters. So, they hard-coded HTML. They hard-coded in links for the banners and everything. So, they needed to know HTML to add campaign pages. So, we said, listen. What if we replace this with a tool where you really can do big changes. And be creative. Automatic product listing and so on and so on. But we hadn't got much trust from the users. Why would you this time give us a good system? Yeah. And also, they had lost the faith. They had lost the faith of ever being prioritized in the internal admin tools. They had never been heard. So, they were asking us, can you move this link up there and so on on the old system. And it was like, that's the most they could ask for, they thought. So, we were very confident that we could solve this problem for them. So, of course, Umbraco came up. We suggested how to solve this problem. And why Umbraco? Well, it's very user-friendly and snappy back-office UI. And the separation between the data and the presentation is very, very good. And it's .NET. We were 50 .NET developers. So, it was kind of easy for us to see that we needed that. And the most important, again, we needed to be able to extend it. Again, we had users that had experience of how they wanted to work. So, finally, we convinced them to have a look at it. So, we contacted Kenneth as an expert so that we can get it right from the start. Okay. So, before Komplet decided to roll with Umbraco or not, Codewise was asked to create a proof of concept or POC that demonstrated how you could manage a campaign page in an Umbraco context. So, based on what we had seen so far and, you know, discussions with Vidar and his team, we had a pretty good idea on how we were going to solve this. Given the kind of grid-like nature of a campaign page, and the grid editor in Umbraco, we had a perfect match that would basically give editors a what you see is what you get experience when creating campaigns. And as you can imagine, that's a tremendous freedom compared to the tools that they were used to. So, and it was basically not that big of a job. It was basically to configure Umbraco in a basic way, but focus on the grid and a couple of custom grid edits. with the product list one as the first one out. And as a central web application or Chrome, as it were called, still would be responsible for rendering the final HTML. We were going to use Umbraco as a headless CMS, only exposing data as structured content, JSON in this case. control application when campaigns were published and unpublished so that it could refresh its local cache. Before we started the implementation, a workshop was arranged with editors from all the different stores, power users, to identify if there were any features from the existing tools that we absolutely must bring with us. Concerns, ideas, and wishes, general wishes for the new one. And then prioritize it all. One exercise during the workshop was to ask all participants to write down everything, their personal thoughts on post-it notes that were organized on the whiteboard afterwards. And In the end, there were top three features that they wanted. The most important one was batch import of products. In the current tool, they had to enter every product by hand, one by one, which was obviously very time consuming and boring. As campaigns frequently sports like hundreds of products, that's easy to understand. So typically, they would get a list of SKUs, that's it, and they would need to look up and create their own selling text, selling product texts, such as titles and the text and so on, manually. Number two was the ability to reuse existing selling product texts that they had written previously, so that they didn't have to type everything from scratch again. Some editors used Excel spreadsheets to ease that burden. But still, it was very time consuming, copying and pasting, probably. And the third one was better scheduling support. As the current tools were a bit error prone, they didn't have enough trust in the scheduling mechanisms, so they would typically sit by their computers to publish and unpublish campaigns on timed events. And on our sales, when you have a batch of products being unpublished at the end of one hour and a new batch of products being published at the beginning of a new one, that was something that locked up resources quite a bit. So based on the knowledge we already had and the feedback from the workshop, we implemented the POC over the two weeks period that we were given. So I'll show you a short demo of the end result. And as we finished this back in September last year, it's not the most current version of Abrako, which got the updated grid layout editor, but still pretty close. So now that... Okay, there. See the correct one? Yeah. Yes. So, next one there. Let's see. Yeah. There, yeah? Okay. Okay, so I log in. Okay, so... Hey, that's my user. Yeah, cool. So, the first thing you'll notice is that it's a pretty basic structure. It's easily organized. We've got two main structures, one with campaigns organized by store, and another one for product texts that I'll get back to later. And to demonstrate the new campaigns management functionality, let's create a campaign with 100 products. So, I'll just go in here, create a piece of content as we're used to. Did you say that we were given two weeks to create this? Yeah, two weeks. And I'll add our products list, which is our custom grid editor. We also enabled a couple of extra existing standard grid editors to give them a better idea of the possibilities. So, I'll create a product list, and I can add products by pasting a list of SKUs that we typically get from the sales department. So, there we go. There we go. So, here's a list of 100 products, approximately. And I'll hit add. And that's it. There we go. And when we showed them this after two weeks, they were like, because they had done this one by one for all years. Yeah, so now they could just continue working on it, and work in line like this. Oops. Careful now. We're using the content editable director, a custom one. And they can also sort. And... And delete, and so on. And they also tried to keep the look and feel of Embraco as of 7.3. It's been updated now to be more in line with 7.4. And... They could also reuse, for the second wish, they could reuse selling texts by hitting the settings button here. And they could choose from previous campaigns. Previous campaigns. Text to reuse, basically. And these texts... Where do they come from? Well, whenever a campaign is published, we just pull out all products. And we store them if they're not already existing under the products area. I'll just discard this one. Under here. They don't typically go in here, but this is where we persist them. So, it could be a start of a product information system. Somewhere they can go and edit in a user-friendly way. So... So here we have the text they wrote for that product. The author. Which campaign it was published under. And so on. So, that's basically it. So... As for better scheduling support, we just used the standard publishing mechanisms in Umbraco. But we also added publish dates. And unpublished dates on a grid row and control level. And also on byproducts. So it was really easy to turn on and off during our sales and stuff like that. So... From this POC, they were able to demonstrate all the top three features that they requested and wanted. But also loads of relevant... features from the Umbraco goodie bag. That we get for free. You know, things that we kind of take for granted. But that really played a huge role for these guys. You had content management features in general. Like copying, moving stuff, audit trails. User management and access control. Asset management from the media library, which we later switched to. Powerful content and media search. You can just continue, but... You get the idea. So it's a pretty big deal. And... Yeah. So... Over to you. And as I said, when we showed off this after two weeks, they were like, wow, they got a new hope. Suddenly, they had a... They believed in the system we were providing them. So we did it. They really... They really liked it. So we got... We got go on the project. We just needed to do some estimation arguments and so on before we could start. Total different story. But we promised them that... This was September. Yeah, I think so. If we can start in the beginning of October, we can have a production-ready system. Not complete... Finished system, but a production-ready system to create some campaign pages before Christmas. And... So we could start developing. And the platform then was kind of given how to do this, the process and everything. But I'll show you quickly how we solve it. So the Embraer files and the using files, obviously, into Git. And then Jenkins create a package whenever master is updated. Then provide this package to Octopus deploy. And Octopus deploy will then deploy to the two servers we have in dev. So the QA department will test everything and go through it. And they will push the button and it will be deployed to test. And so on onto production. So we have two servers in every environment. One is active and one is passive. So if the active one is active, the passive one goes down, the passive takes over. So this... As we said, the... Umbraco provides everything on the campaign pages as JSON to the Chrome rendering. We still render it in Chrome. It will be that way for a bit more because of the product catalog hasn't been a service yet. But as soon as that is a service, I think we will have a separate render engine for the campaign pages. And also to have the media storage, since the CMS is a backend service for this kind of pages, we needed to be able to have images for both systems. So we have a shared folder kind of solution that is set up in the IIS, both on Umbraco and on the Chrome side. And the files provided from Umbraco to the rendering will be the same so that you just swap the domain and the image will be there. And it works like a charm. So after a couple of months, Christmas was getting close. And I was kind of excited to see that we... We launched a production as promised. And that was really a great experience for us. So if we should start a season, we would have never done that in two months. So yay, Umbraco. That's awesome. So that was right before Christmas. And we have developed every since, actually. So every second week or a month, we have added new features. So they started out with only text and product list. And now they have a lot more editors. So let's go and see how it looks. So this actually is our test environment. So you can see the structure has changed a bit from the POC. And yes, this is how it looks in production. Almost. We can have a look. So we have this list going on with all the campaign pages. Because when this system will live for a while, this list will be very huge. And you don't want that in the node tree on the left. So we have list view. And this is what I talked to Warren about yesterday. We had some issues about the list. We would like to modify it a bit more than we can right now. But that's so far the only obstacle we actually met. So let's just create one quick campaign page. We've added a set of rows so that we can fit the needs they have. And... Um... As you can see here, very few of the standard editors are present. I think it's only the rich text editor. So we created a banner image component to say that we can have one picture on the cell phone and one picture on the other devices. And note that I automatically got the alt text. So we set that to required. And we reused that from the images. So if... If this was the first time I added this image, it would be blank. And I couldn't insert it before I put it in. And another cool feature that they use is countdown clock. Often they have a campaign page to release a product or a countdown for Black Friday or so. And then they simply set it to when... Yeah. We have a countdown for tomorrow. And then we could add some products. So we tweet a lot and use... Use our sellers very much these days on conferences. So we need some power banks. And those product numbers will typically be provided from product managers or... Or perhaps also the marketing guys for which products will be on the campaign. And as Kenneth mentioned earlier, they added texts from Excel sheets. Did I now... I didn't save the correct item numbers. So these are product numbers that are from production. Good job, Vidar. Okay, but you saw Kenneth's version earlier. So it's the same part. So I can change this to... We'll delete this one and we can add a search box instead. So sometimes they would like to have a... Do you see the product search? Product search. Right. Thank you. And we can say... We can say... Okay, so I'll just put in power bank. So typically they would do a search on the search page, do the facets and everything, and they would copy the URL and paste it in here. So I'll get a live preview of how it will look as well. And now you can see I get a preview with the price and so on. And I'll go save and publish it. No, I can't because I need a name. What's happening? Oh, I'm sorry. I won't do that again. So call God. I ruined it. Okay, so this is an important part these days. We have set the meta description to be required. So you can't save and publish a campaign page without providing text. So now it's published. And we've added a URL provider so that since the campaign pages and the rendering and so on is two different places, we've manipulated this. So we now can see that we have a blank campaign page. Great job, Vidar. And you can see several tabs here. So you've seen the content editors here. And we've added analytics so that instead of forcing them to use Google Analytics to see how a campaign page did, we've added the analytics into Brokos. So this is the power of open source. We used the... We're in Brokos. We worked with Analytics Package that we... So we got inspired from that one and added it to the page. So this will query Google Analytics and give them data for this given campaign page. And they are really happy about that. We've added a settings tab so that you can add a seamless tab. So if they put in a lot of banner images, the paddings and margins on the grid system will disappear. So it will just fit together. And we also added so that the product list and product search, I think, will be affected by this setting so that you can hide every product that is not in stock or different stock status. We can hide the left menu. Earlier, this was actually a store feature. It's a name we call in the system that you can say that this store should not have left menu. And that meant for the whole store. Now they suddenly could choose if a campaign page should have or not. So this also works for the department pages and front pages. I'll show you later. And you can also hook up a campaign page to a category so that it will reflect in the breadcrumbs and top menu and so on. And also you can say, because we have B2B webshops, that it requires you to log in to get the correct prices and so on. So you can say that this page is hidden for anonymous users. So they are really happy about that compared to what they had. They are in a totally different world. And we have added most of the same functions for front pages. What you mentioned that we didn't look at now, we have added a time scheduling on the row level. So that they can have our sales. They can put a chunk of products that will be on the campaign page from six to seven. And they will have a new chunk from seven to eight. And that's when they are going to schedule these on front pages. It will be kind of awkward to do that and plan weeks ahead. So what we did, we said that, okay, we need front pages. We need front pages collection to this store. And we say that we need to have an active page on the front pages. So then you can schedule several front pages. So you can create a front page. It looks the same as the campaign page. So this is an editor we made for Rich Relevance. So they could add strategy names and things in the Rich Relevance admin panel. And then we can put in the same ID here. And you will get what you want on the front page or a campaign page. Okay. We note we do not have a SEO tab here. So we will remove them. I can't remember the... Why is it... Okay. Let's just... Oh. Sorry, guys. The thing is now I have published a new front page. And if we would say that now we have a new front page, we would literally have new front pages every day if they work with front pages every day. So we need to schedule it to be active. So we have hidden the unpublished page. And we have a public chat because we don't want a blank front page ever. So we only have set to publish the front page. And you can set it like this. And this way you will be told that it's not published yet. But then you can see upcoming pages. You will get a list. And we have a scheduled job that will then change the front page to be what you have set. And that way you can plan ahead during summer and so on. You can plan ahead weeks to get front pages. You have something to add? No. Cool. The same goes for the department pages and category pages. No, not the category pages. It's the department pages. So we've added that to a department, a folder called department pages. And you will have the same way of working here. I think there is one more thing. The SEO tab. And eventually we will add analytics tab to this as well. Because we could provide the Umbraco ID for the page to Google Analytics. That way, because of the URL, will always be the same. That way we can track which landing page did well when it was active. Cool. Yeah. I think that's about it. Are we missing something? Nope. So, the road ahead. This was the marketing CMS we watch now. So it was the campaign pages and so on. So it's a system providing JSON for Chrome. We have created, started to create a store. So we're going to create a store CMS. This will be responsible for the top menu. We will change the top menu soon to be slightly different. It will later, it will have the footer content and other static content. This system provides both JSON and HTML fragments. So the views actually renders some HTML that Chrome or other projects actually render in styles. And this week started on the info center, which is the customer care center. And by now, after six months, Umbraco has gained that much trust in the organization. So this will now be a standalone. Umbraco will be responsible for rendering and everything. So we will use our common style guide that we have created. It would look the same. But it will be different. It will be responsible for everything. And later we will start a product CMS that will be responsible for the product info section on the product page. And it's in planning. Perhaps it will be responsible for the layout of the product page as well. We don't know yet. This has been postponed a bit. Mostly because of the project we have in parallel called the PIM project. So it will be integrating with the, I can't remember the system, what it's called. But it will be an implementation. And also this will be implemented with some content delivery companies. So that we see it or I can't remember which one we use. And the response has been great. We have had one store that told us that we won't be responsive. We will be responsive before every page on the platform is responsive. And we're not there yet. As I said, we are picking one feature at a time and rewrite it. So, but when they heard about the fuss of the new system that the other stores had started to use, they were like, oh, we want to go responsive now. We need umbraco. So that is a great response to get. So they are all very responsive. So, yeah. They are all very, very happy. And it's going, yeah, they now can be creative and, yeah, do what every day wants. So, yeah. So basically instead of replacing the whole thing, we are just taking pieces. And each piece is basically an umbraco installation. Very focused and really easy to have quick iterations on adding new features and putting it in production instead of having it. Everything inside this huge monolith and having to deploy that together in one go. So that's the whole idea. So just big pieces. And in the end, you will basically just be Chrome left. And at some point maybe then use umbraco for that as well. Maybe. We'll see. And if by some reason they see that umbraco didn't work on that tool you implemented, it's not a problem to replace it. Maybe if they say that that's more efficient. And it won't affect the other umbraco installations we have. So, yeah. Yeah. Any questions? Yeah. There's a microphone coming. Thank you. Have you considered using only one umbraco instance for all of these installations? Yes. That was my first thought. That was my initial plan. And why did you change it? Because of the decision of the service architecture. So that one of the first things they said that what if we need to replace it again and then it will affect all the other parts of the system. And also, it's kind of a complex code we've added in there. And it's really nice to separate it actually. And also, it's a lot of different users. And the marketing guys only touch the marketing CMS and the product content guys is only touching that. So, it kind of makes sense to have it differently. But, of course, it's more to take care of. But, again, we are 50 developers. And, yeah, I can't imagine how that will feel like. And do you have some shared code base? No. We haven't got to create internal packages yet. So, by now, we have, yeah, Info Center was the third CMS we started. And now we can see that we should start thinking about pulling the code out and share them. So, we have a system on styling and JavaScript used across the different front-end services, which is component-based and shared. So, we need to look into how to share on Raku. And we can share on Raku parts as well. Thanks. Anyone else? Hi. Is there any reason why you manually copy-pasting the SKUs? Why don't you just provide like an API? How do you mean? I mean you can maybe add a plug-in that when you right-click on the node and say import products. So, you don't need to copy-paste the SKUs. I guess that's more like how the different departments communicate. That's their way of working. So, but it wouldn't be too hard to expose some sort of way for them to enter this directly into the system some way. So, instead of copy-pasting, it would be ready for the marketing department to actually then just put it into action. Yeah. We have added on the product ads. So, that's... Was that a product ad? Yeah. No, product list. I can't see that far. On the product ad, which is just one product fit to one column or two columns or so on, then you just put in one SKU and you will get it right away. We have not put in any type ahead or anything on that. Again, as Kenneth says, it's kind of feeding the workflow of the departments. Is there... Like, can a product be inactive? Sorry? When you add the product to the list, can it go inactive so it's rendered on the page even though it shouldn't be? The product? Yeah. Okay. So, that's the responsibility of the render part. So, the rendering will not render products that is end of life or out of our... Product... What is it called? The product is... Yeah. It's not the responsibility. It's not possible to order it anymore. It won't be written out. Okay. So, then the styling will be responsible for making it pretty. Thanks. Thank you. Yeah. What... I can't remember what... Yeah. What's the product ad? Yeah. Okay. Thank you. Thanks. Thank you very much. Thanks. You're welcome. Great. Thank you. Thank you.