Quick Site Creation

Transcript

Welcome, everybody, to this session about Quick Site Creation. My name is Gabriel Wolt. I’m one of the product managers for AMSites. I’m here together with Hyman. Hi, everyone. My name is Hyman. I’m a product manager on AMSites as well. It’s a pleasure to be with you here today. Hey. Yeah, we will have a great session today. Even if you maybe have watched such a presentation already about Quick Site Creation, there are always new things that are very exciting. So stay tuned. All right, so yeah, creating a site used to be a very lengthy process. And it’s really not easy to get all the steps in a picture. This is really high level view of what is usually happening. It actually already starts with having to install the local SDK to be able to start everything, to create the project. You need to be a back end developer for that. There is the AM project archetype that greatly helps you in that step. But it is a big step that you need to take then creating all the templates in there, the components that you want to customize, implementing them, and extend basically all the components so that, or at least style them so that they match the designs. Then you start to implement the theme. That’s more of a front end developer task there. And do the CSS and the JavaScript. But you see that task is really actually only the third block here. And you are actually blocked by the first two steps to be able to start doing that. And then actually to deploy the front end theme, you need again to have a full stack or back end developer so that this gets live. And only once all of that has been gone through, you can actually start as a site author to create content. So it is expensive and time consuming. And it’s heavily actually depending on the back end developer who has a very central task here. And authors cannot really get started once until everything is completed. So you see very much how this is a waterfall, actually. You need to do every step in a certain sequence. And what we are doing here with Quick Sites creation is a very different approach. It’s an approach that radically will change. We believe sites development in AM. Because it tries to untangle these ends to make it more like swim lanes that are parallel and that can start in a certain order, but can also actually start in different order. But the logical way to start here is to kind of first, as a site admin, you can create a site in AM. So you don’t even need a developer to get started. And maybe that site is good enough because maybe the site template you use is something that is already suited to your needs. Or maybe it is because you’re just wanting to create a small microsite and you’re OK with something that looks maybe not as branded and kind of corporate branded. Or you can start creating content immediately then. And actually, if you do need some corporate branding on that site, you then just get to the second swim lane with the front end developer who can start to customize the theme of that website and easily deploy that in a self-service manner. And if you actually need to do some customizations, these can be done as well on top of that. And you can add some custom components to the mix and build, deploy them before the author can then start using them. So as you see, there are actually three swim lanes here. And the first one is really kind of no code. The first one allows a non-technical author to self-sufficiently create a site. The second one is kind of low code. It allows a developer that doesn’t need to be very used to AM and doesn’t have very deep AM expertise at all to do something. And the third one is where the AM expert comes to the table and starts to customize things. So really, this parallelization of these three tracks really allows to make things much faster. The way this is possible is actually possible thanks to three different parts. The first part allows to simplify how the new sites are created. So we’ll dive into that part right after. It’s basically how you can create a site self-sufficiently. The second block here is that you need something to bootstrap your site. You need to have some best practice experience template that allows you to quickly create your website or your experience here. And the third one is then how the front end developers can add their own work to the mix without having to have a full deployment going on and requiring AM expertise. So let’s quickly look at each of those. Firstly, there is the Site Creation Wizard that allows to create this website in just a few clicks. And we’ll have a demo with Hyman just after where you’ll see it is really just a matter of minutes to create your website. And the only thing you have to provide here is really what is the title, the name of your website. And it will set up everything from the site template. So then site template that you choose will be very important in the content that will be set up. So yeah, that’s the site template that you’re using. So that’s the second very important piece. And it does really bootstrap, get you a very long far way long. So it’s bootstrapping all the templates. It’s bootstrapping a few pages for you. The whole internalization or the localization structure with multi-site management can be set up that way. Sets up if you need the whole structure for content fragments, experience fragments, and such. And these experience templates are actually customizable. You can also create your own ones. So we just provide this one as a starter. But you can actually also build your own. And you maybe also can create experience templates that are specific to a given brand. So if a given brand has to repeatedly create new sites, maybe small sites for some marketing activities or such, then that can be provided with a special site template that is tailored to that need. And a site template is actually composed of a number of things. Let me quickly dive into that while we are at it. So as such, an experience template is actually a zip file. And it contains some metadata in the form of a package JSON. It contains a seed content package in a site.zip file. So this is really a standard content package that will be initialized or copied for every site that you create from this template. And then there is a theme, which is basically the CSS and the JavaScript required to make these pages look as you wish them to be. And this theme comes in two parts. There are the sources of this theme that is also part of the experience template. So if you want to later modify that, you can. And there is also the compiled theme as well, because the site needs to immediately be able to use the compiled CSS and JavaScript of this theme to look like something. So the theme comes in these two variations. And then there is a number of files that can also be attached to the experience template, like wireframe design files that allows to easily customize these site templates if you want for a designer, because you don’t want to reinvent in the design file for each time you use this template the different components that are needed so that you can design that and maybe adjust just a few colors in the design file before the front end developer starts to really do that. Then there is also previews folder, which allows to actually in the UI when you choose the experience template to preview how it will look. And then the front end developer can download this theme and start to modify the websites, the look and feel of the website very easily. This doesn’t rely on any Java or AM technology. It is really standard NPM built thing. So you can really build the whole project without any Java or AM. And then there is the pipeline to deploy this code, because you don’t want to deploy this code with a full stack pipeline that needs to actually recompile all of Java and takes a long time to verify to run all the checks to make sure that the website will be OK. It’s just some CSS and JavaScript. So we have created there a new front end pipeline that you can use to easily deploy that. It’s taking a few minutes to deploy. And then the files are served from a static immutable URL that will be unique to each deployment so that it’s efficiently carrying all the caches that might be and updating the link from AM to point to these files once the deployment is successful. All right. So let’s jump into a demo, because Hyman can show you all of that. And I think it’s really exciting to see. Great. Thanks for that intro, Gabriel. All right. Let’s take a quick spin around quick site creation. So I am in a cloud service instance of AM. Going to go to Sites. And now with quick site creation, there’s a new option in the Create menu for creating a site from a template. And here is the Create Site Wizard that Gabriel had mentioned. So over time, you’ll see, of course, more templates populated here. There’s also the ability to import your own template, as Gabriel mentioned. You can certainly create your own site template. We have partners that have built their own, customers that have built their own. And we have tooling and documentation to support that as well. So if for your specific design or use case or verticals, if a customized site template makes sense for you, certainly it would be very helpful to create your own. So I’m going to start with our standard site template. And put in the name here, so it’ll be live. And if this site template includes all of the components, page templates, component styles that meet your requirements, that is all that’s required now to initialize the site. So a content author can come in here and start making edits to their site that they’ve deployed in this environment. So we can see that all the components are initialized and ready for use. The initial content is here. It certainly can be edited. So let’s just do. Add another teaser. And the site templates also include any styling that you want to have persisted and available in this way as well. So again, if the site template meets all the requirements for the site in terms of design and structure, no other development required. So that’s the no-code approach. And as Gabriel mentioned, the more likely scenario is that there’s going to be at least some branding that’s needed to customize the look and feel of the site. And that’s where this new front-end theming workflow comes in. So by selecting the site and then going into this site sidereel, you can download this theme source package. And that will package up the presentation layer for the front-end developer to style. Now, the other component is the front-end pipeline. And you can now create a separate front-end pipeline that just deploys this themes package back into the cloud service environment. You can clone the Git repo here. I’ve done that already. Let’s see here. So the theme source package, you download, unzip it, unpack it here so that it’s part of your local repo. You can drag it into your IDE to an NPM install and then NPM run live. And that essentially brings up the theming environment for the front-end developer. And as Gabriel mentioned, so no AM installation required, no Java requirements. This is now going to be the theming environment for the front-end developer. So they can come in here, make changes to the CSS and JavaScript. One thing we also wanted to share is that in that site template, there is the wireframe XD file or the XD file that is the design equivalent for the site template. So the designer now has an equivalent starting point to the developers in terms of the site that’s initialized with the site template. Includes all the colors, character styles, components, component styles, and page templates for the site that gets initialized. So the developer can then or the designer can just identify what should be changed to customize this site to the brand’s needs. So let’s say we want to change this accent color from blue to this red here. And then they would give this artifact to the front-end developer to make the equivalent change in their theming workflow. So let’s go in here. Change. And we’ll be able to see that change reflected very quickly in their local theming environment. So all the CSS and JavaScript to customize this site to their needs are available in this package. And once they’re ready, they can use this new front-end pipeline to deploy the changes back. So you just stage your changes. Let’s add a name for this change. Let’s say, changed accent to red. The changes. Push it back into the Cloud Manager repo. And then come back here and kick off the pipeline. And that will deploy the front-end changes back into the Cloud Manager environment for the content authors so that they can see their changes as they’re authoring the content. So now I won’t do that. I’ll hand it back over to you, Gabriel. All right. Thank you very much, Hyman. So let’s take a few additional look at a few additional details. And then we can maybe also open up for your Q&A. I mean, you will certainly have some questions. So don’t hesitate to ask those in the chat. If there is anything that you’re curious about, we can then take questions that you are putting on the chat. Also, check out on the chat, I’ve added actually a link to a package that you can install on your environments if you want to try it out with a local Quick Start. OK. OK. So first, how do you create your own template? And how do you create a site from a template that’s basically the relationship between an existing website and a template? So as I told you before, the site template is actually containing a content package of a website. So this is the first thing that the site creation wizard will do. It will take that content package that is in the site template and create a site from that content package. And then it will rename that site that has been created to the name you have chosen in the site creation wizard. And actually, if you want to create a site template, it’s the opposite process. So if you want to create a site template, you can take the standard site template that Hyman has been using to create a website. You can remove the content package from that and put your own content package in there. Just make sure to rename the path of the content folders to the name that corresponds to the site template. And the other thing that needs to happen when you create a site is that the CSS and the JavaScript of that site template need to be deployed. So in the site template that we provide, there is a CSS theme that is provided. And this one will basically be deployed. And that site that has been created will be configured to use that theme. So there is actually a configuration that is very important in that step. But you don’t really need to mind about it because it’s done for you. But that’s basically how the website is embedding that theme. So there is a context-aware configuration in slash conf that tells for this website where the CSS or which CSS files and which JavaScript files need to be included on the page. So this is the site configuration, context-aware configuration that has HTML page items that can be configured in there or that are configured in there. And each time you actually deploy an update through the front-end deployment pipeline, this configuration will be updated so that it points to the new files that have been deployed. And the activation of these files actually happens through author, publish, and preview. For now, all of those get updated automatically. In the future, we’ll have more control over whether you want the deployment to go just through maybe the author instance of your environment so that you can preview there if it looks good. And if it does, you can actually publish that change then to the publish environment. So on dev and stage, automatically all three environments get updated when you do a deployment. Author, publish, and preview all three get updated when you do a new front-end deployment. On production, however, you get only the updates to the author environment and then you need to publish the change, replicate the change to publish basically so that you get the change also on publish. So there is slight difference in how this behaves between dev stage and prod, how the pipeline gets to. But as I told you, as we will continue with this feature, there will probably be much more options around how this gets deployed, more so publish and preview, especially for production use cases that maybe would like to have more control. That’s it. So Karthik has already shared actually the link to the sites templates that we have. That’s the second link that we have here as well. So I don’t know, maybe for those watching the recording of this later, if you don’t have access to the chat pod, you can take the link, the second link here. The first link is actually a tutorial that walks you through that as well. It’s not yet using the new cloud managed pipeline that Hyman has showed you. This tutorial will be updated very soon to show that as well. And then finally, there is also a partner, Headwire who has created another site template that is quite extensive, that has a lot of options that can be also maybe helpful in some situations. So that’s it. I don’t know if you have more questions that we can take, if there are anything, otherwise that maybe Hyman you want to add on top of that. Yes. It does look like we have some questions. So why don’t we go over to the questions first. See cloud manager, the AM and front end are different Git repos. Are they different? No, it’s the same Git repo for the backend. It can be different, it can be the same. By default, it will be the same so that you keep everything together. Now cloud manager also have possibility to use multiple Git repos, I think. So that is also possible. But yeah, by default, it’s all on the same repo. So it’s actually a folder, it’s just a folder in there. You don’t need to mind about Maven and everything else that is in the other folders. Just place your front end folder in there and configure the front end pipeline to use just what’s in that folder. So it’s very detached from the rest so that the front end developers can be independent there. Next question I see is current use case is meant for small organizations that can build the website and hire freelancers to modify the UI and push it back. That’s certainly a use case that we see would be activated with QuickSight creation, but not the only one. Certainly we are currently working with large organizations that have the need to build many microsites very quickly that are structurally very similar or the same. And this would certainly activate what we call these sites factory use cases. But in general, the vision for this is how AMSights would get initialized going forward. So regardless of small organizations or large organizations, I think there’s a lot of value that we’d be unlocking with QuickSight creation because it does take a lot of the dependencies on expensive engineering resources out of the process from an initialization perspective. And we’re focusing those resources on the things that they do best, which is developing new experiences and customizing them, delivering exceptional experiences. Also, I can imagine that maybe for partners and implementers, it can be useful to use that in the future so that you can have your own site templates that might rely even on your custom components that you might want to use, or because on top of the core components, you can actually add your own custom components. However, those components cannot be embedded in the site templates. So you would have to previously or prior to using these site templates, first deploy the custom components, and then you can start to use the site templates that to depend on these components or use these additional components. And I think that might be a way for easily building websites for implementers because it allows to kind of detach the maybe the set of components that would be probably also then reused across different customers and the initialization or the kind of bootstrapping then a website that uses those components. So it’s attaching that and you can then have different site templates that customers can be using and that you or that you can use for your customers as well. And allowing then also the front end developers to work more independently. So it’s probably also in the future, allowing a better separation of concerns for implementers as well. Third question, any future plans to include this structure in the archetype? Yes, absolutely. So there are two things that we’re thinking at. First, we want to have even when you use the standard archetype as it is now, that the front end module can use this new front end pipeline. So that’s one thing, even if you don’t use a site template, the front end pipeline still is valuable. And the two features really can work independently from each other as well. So this front end pipeline is something certainly want to quickly add to the archetype. I think it will become actually, if it works well, the de facto way in the future to create front end modules. And we will therefore probably more walk away from using client libraries for published site use cases. Client libraries will still be used for when our own UI is needing some CSS and JavaScript, but for your websites, I think will more and more work toward this front end module. And then there’s the other use case where you want from what you created in the archetype, create a new site template. So there will be a script that will allow to generate site templates or experience templates from an existing site or from what the archetype generated. And so that will be a way how we can also include it into the archetype. And we’re at the end of the time, I think, but I can quickly answer the last one, which is about MSM. And MSM is actually very well supported because it’s just about how you configure your content. So your site template can very well use or set up the content structure that is fully set up with MSM. That is not a problem. All right. I think that’s it. Thank you very much. Thanks everyone. Thank you, Raymond. Okay, perfect. Have a great rest of your day. Okay, bye bye. Bye bye.