Skill Exchange Event Aug 2023 - AEM Developer Track - Unlocking the Power of Style: Building an Effective & Scalable Style System

Transcript

Hello, everyone. Thanks for joining Experience Makers, the Skilled Exchange event virtually with me. Today, I’m going to talk about unlocking the power of style, which is building an effective and scalable style system. This is Rakesh Paswelati. I’m a technical lead at Amazon Alexa. A little about me. So I do have about eight years of experience with the Adobe Experience Manager, and I’m one of the 2020 Adobe Experience Manager champions. And I always like to think big, simplify and innovate. You can connect with me on LinkedIn, and here is the link for you that you can see on the screen. Here is the agenda for today’s session. We are going to talk about style system and why it is important for us and how can we set up a style system. Right. So first of all, how can we build a scalable style system? And probably we can cover a few questions from you if you have any. Here are the key takeaways. Developers will be able to understand how can they build a scalable and efficient style system. And for template authors, they can understand how can one define classes or styles for the component policies. And for content authors, they will be able to understand how can they use the style system which was defined by either template authors or developers. On this deck, we are going to talk about how can we set up a style system. Right. Firstly, we need to understand a bit about style system. So what is a style system? Style system is similar to design system where you can define styles for the components. Basically if you wanted to change the visual alternatives based on the branding or the styles, so you can define a style system without creating a new component from the scratch. Just because you have a new requirements from the UX. So style system really helps in changing the visual for a component based on the new requirements that you may receive. Secondly, we need to first have an editable template to create policies for a component for the style system. Next, you need to define policies in that editable template. It can be done either through code or it can be done directly through editable template in AEM. So either developer or template author can define a style system, meaning can create a policy for a style system in the component. Next we in the sense developers need to add the required CSS styles to the component presentation layer. Right. Why we need to add CSS classes to the component? Because whenever we are changing something, whenever we are changing or switching to a new style, then automatically the CSS class that the developer will add will be applicable, will be applied when there is a change to the CSS style or the style system. So there are some prerequisites to enable a style system to a component. Firstly, you need to enable style tab that you can find in the design dialogue of a component. So by default it is not enabled. So you need to enable this by giving some references in the design dialogue. Secondly, you need to make sure that the mapping that you are going to have for this policy enable in the global WCM policies of the file. So firstly, you need to create policies in the WCM policies file. And once you have that created, you can certainly use the same policy and refer the same policy in your policies of editable templates. So we need to make sure that you have this information available in your code packages to create a scalable style system for a component. You can always use your template policies as well to define style systems for that template exclusively. But make sure that you are not overriding these styles that you have defined in the code package with your policies that you just defined in the template directly. So you can always use filters as well in order to prevent any overwrite situation. Just because if you have overridden the styles that your template author had created using the template, then there is no way to revert it or something like that unless you do one more code deployment with the same changes which your template author had added directly to the template using the code packages. So these are some of the steps to create a style system, to get an efficient and scalable style system in AEM for either a component or at the page level. So we have two options. So you can either create a style system for a component or you can create a style system for a base template as well. So here we are going to talk about building a scalable style system. So think about you have a requirement to change the layout, right? So when you have a requirement to change the layout, then you have two options to do. One is you can directly add these styles or the categories or style groups directly in the template, or you can probably define these style groups in the code as well. So here in this example, particularly, we are going to talk about how can we build a scalable style system, right? So if you wanted to build a scalable style system, then you need to add a component to an existing editable template, right? So you might have a few editable templates and probably like five or six editable templates, and you wanted to add the style system in all those six or five editable templates that you may have. Once you have added this policy to all those editable templates, then you will be able to automatically apply this specific style system for the component that you are looking for to all the editable templates that you have already, right? So in this way, you can easily apply or use the component in multiple variations for all these editable templates if you have added a policy in all these editable templates. Secondly, if you have a global font style or if you have a global typography that you wanted to change, so you can do that in respect to dealing with a component. So your component is helpful when you wanted to change the visual for that component specifically, but if you have something that you wanted to change at very global level, like for example, typography or something like that, then you should be able to do that by using the policies of the editable template itself so that whenever you change a policy, if you change the style from A to B at the template level, then the B style will be applicable to the whole page, right? Think about how you wanted to change the typography from A to B, right? So then it comes handy for you if you have any requirements to change the policies at the template page level. And you can also define or create style groups for a component and you can always refer the same style groups at the global level first so that you can refer the same policy in multiple editable templates. So for example, in this example, we are looking at a grid layout or a block layout, right? So you will define this block and grid layouts at the global level under WCM policies file of your project so that once you have defined that, you will just refer this policy that you have created in all the editable templates that you wanted to use this specific feature. And here in this example, we are going to understand how a template author will be able to add styles in the template level. So think about like you wanted to now add some date to each thumbnail of these images in the grid, right? So then you’ll get a style for that at the template level. It can be done by a developer, it can be done by a template author. So you have multiple options to perform this task. Secondly, you can create these style systems at the template level so that whenever you were changing or whenever you’re trying to apply styles for the specific component, then you will be able to do that easily, right? And secondly, if you wanted to combine two styles, for example, in this specific example, I wanted to add a date as well as I wanted to display an image, right? So I wanted to do both these activities. So you should be able to group these two subcategories of styles, right? And then you can apply different variations. So for example, you can do this either at the code level, right? Under con folder in your project specific WGCN policies file, or you can even configure this at the template level as well. If you wanted to group two styles, if you want to select two styles into the same component, and then if you want to just change the layout from probably like a grid to block or something like that, you should certainly do that by creating one more style system. So these are the variations that we have. So once you have defined all these styles, either at the template level or at the code level, your template author will now make sure that the changes that you have either deployed to the code or whatever they have added at the template level are going to work fine for the content authors. Now content authors will come into the picture to use this variation that you have created, right? So basically what they would do is they would use this component to make sure that it meets the UX requirements basically, right? So for example, here the UX requirements is to change from grid to block layout, then they would be able to validate the same by just focusing only on the component part. So they do not need to necessarily focus on how the policies can be defined and how the styles can be added to the component, but they can just … So that information can be abstracted from the content author and the content author can only focus on using the component more, right? So like changing from one variation to a different variation. So think about like you have a requirement where you have multiple tenants running on the same AM instance and each tenant will have their own set of guidelines in terms of UI. And this specific feature of AM will definitely help them in meeting their requirements. So for example, the branding could be different between these two tenants. So for example, one tenant will have a different theme and one other tenant can have a different theme in terms of how these components can be used, right? So in that specific scenario, they should be able to leverage this feature to meet the requirements. So it definitely helps everybody like developers, template authors, and content authors to save their time and achieve what they need to quickly. So overall, it will help the business to create content quickly without any additional development cycles, I would say. So this is all about building an efficient and scalable style system. And if you have any questions, please post those questions. This concludes my presentation. Thanks for watching. Excellent. Hi, Rakesh. Thank you so much for joining us live today. Hi, Robert. Thanks for having me today. Yeah, absolutely. Enjoyed the presentation and we had some questions come through in the chat, which is great. So we’ll dive right into those questions, but feel free to keep them coming, audience. The first question is from Aruna and it is how to use the style system for SPA React app, which is using the AEM and React components mapping on the React side. Yeah. I mean, that’s an interesting question too. So personally I have never done it, but I believe we should be able to use style system even for React-based components. So I believe you would have the same CSS styles and everything, right? So maybe you can use that page template to create the style groups within the editable page template. And then you can even probably have a couple of style groups or even one style group. Since we have two differentiated styles, one is design and the other is layout. And you can use either one of them at the page template level if we cannot use it through the code base. But if you want to use through the code base, I would suggest to visit Experience Leak for more details about committing the changes to the code base. Excellent. Love that you’re pointing folks to Experience Leak. I’ll be talking more about that towards the end of the program today. But our next question for you, Rakesh, is from Alexander and it is, are we required to add the design dialogue below the component node, even if we add the style classes slash groups for each style to be used by the author in the template level? Yes, that is correct. So it is required to enable. So it is sort of like in a configuration, right? So even you have the style groups defined in your policy section. So in order to get your component activated, you need to use or you need to enable it by making some configuration changes at the design dialogue level. So yes, it is required to make your component use that style system. So for example, if you don’t use them, then you wouldn’t be able to see the style names or the style groups at the component edit bar. So if you don’t see them, then you wouldn’t be able to use them. So it is required to enable it by making some changes at the design dialogue level. Excellent. I love when questions are answered in a yes or no format, because that is rarely the case with AEM. Usually it depends. So great that you were able to answer that right away, Rakesh. Thank you. Our next question is how do you scale the style system of a component? Interesting. So, yeah, I mean, let’s assume that you have a requirement to scale the style groups across multiple components. So as I said before, we have two differentiated style groups or style systems. One is design and the other is layout. So let’s try to take an example of layout for this question. So the layout, it could be a list layout or a block layout. So you might have different components. For example, you may have a component like a container that would accommodate different images and you would have a container that would accommodate just the videos. So either ways, if you wanted to design or enable a style system that can change the layout of these containers, then you can use the same policy across these two components or maybe more than these two components where you wanted to use this specific style system. So in that way, you do not need to recode the same thing again and again for each and every component. So in this way, what I would do is I would probably create two layouts. One is list layout, other is block layout. And then I would use either list, I would add this to that, I would map this to the components where you have defined those components. And it can be multiple templates as well. So we never know. So you might have different templates and each template may have different components. So yes, it is possible to scale a style system or a style group to more than one component. Excellent. Thank you. Our next question is, is it possible to use a style system at template page level? Yeah, yeah, absolutely. So let’s assume that you have two tenants running on the same AEM instance, like tenant A and tenant B. When I say tenant, let’s assume that you have two teams working on, they might have different themes, branding styles. So they might have different, because there are two entities within the same company. And if they’re using the same instance, yes, you can help them by defining all the common styles at one level, so that you can probably use this global style system at the page template level so that if you change the style system of a page template level, then we would render all the common branding themes and styles using that CSS style class or something like that. So it is definitely possible, and it is also widely used functionality. So I would definitely recommend to use this in order to save some time and for easy maintenance as well. That’s a great recommendation, Rakesh. Thank you for providing those insights. Our next question, is it possible to create multiple groups of styles within the same style system? Yeah. So definitely, it is definitely possible to have more than one style group within the same style system. So it is mainly used when you want to apply multiple styles to the same component. So for example, in my previous example, if I’m using the image container, so image container can be rendered in different ways, like a list layout or block layout. So layout would be one example. And now let’s talk about design, which is the changing the color themes. So your button in that container may be sometimes blue, sometimes red, or something like that. So let’s assume that you wanted to combine these two groups, layout group and display options. So you can use the same style system to combine these two together so that you don’t need to have multiple components to achieve the same functionality. So simply, you would combine these two style groups and you can let your content authors to change or apply these style groups accordingly. So if they wanted to use red color, they can simply use that red color. And if they wanted to combine that red color with a list layout, then they can use that as an asset. But make sure that you always name them appropriately so that your content authors can easily understand and then they can use it accordingly. Yes, absolutely. That relationship between developers and content authors is crucial for efficiency. So great insight there. Our next question, Rakesh, is from Tanmayi. And it is, in case there are two or more sites using the same template policy, do we have any option to disable or enable style classes based on the site? I don’t know. I never used it, actually. I mean, maybe I would not even refer to that in the templates level. If you’re not going to use it, maybe I’ll just come up with some custom CSS to hide it for the template exclusively if you do not want to use it. So that’s how I would go about it. Thank you. Our next question is from Karan. Is it possible to create core style system which can be used within multiple sites and not specific to one site’s templates? Possible to create a code style system which can be used within multiple sites and not specific to site system? Yeah, I mean, so I believe that is one of the advantages of scaling the style system. So you can create all the policies at the parent policy level, and then you can inherit those policies into the templates that you have. So you build all the policies at one file at one level, and then you will inherit them wherever you wanted to. So for example, in my case, if I have like 10 policies and if I do not want to use those 10 policies in all the templates, then what I would do is I would just inherit only five into one template and other five into other template. So in that way, you maintain those policies at one place, but use them in multiple places. So in that way, it would also help with the development and maintenance purposes in the long run. So we can also reduce them and take data as well. Excellent. Thank you. We have time for two or three more questions. So if you as a member of the audience have one, put it in the chat and we will do our best to get to it. But the next question for you, Rakesh, is can template authors manage style systems? Yeah, for sure. So it all depends actually. Though it is possible to manage style system by template authors, but in some companies, I don’t know if there will be a role of template authors. So I believe the one who is managing these style systems would be interchangeable as per the entity. So in some companies, they have template authors, in other companies, they have developers who are managing. So both these are good. So template authors can define or manage style system at the page template level. In that way, you can quickly promote or create these style systems to the inner life systems. Other way would be to define those policies at the conf directory, meaning in the code base. You always make sure that each and every change that is related to a style system will be going through the code package and the pipeline and deployment is required. So in some places, I see that they use both template authors and developers who manage style systems. So I think it all depends on the team. So how they want to manage these style systems. Excellent. Thank you, Rakesh. We actually only have time for one more question, but it’s so awesome to have you here today, Rakesh. We’ll go ahead and answer this last question for the audience. Should content authors need to know about CSS to change visuals? No, it is not required. Actually, we are not supposed to name the style names using CSS classes because CSS classes, class names may not be more meaningful. So for that reason, we would always insist developers or template authors who are managing these style systems to name them accordingly, which can be easily understandable. So if you’re defining a style system for changing the colors, then I would do maybe a mode or theme or something very simple to understand. We are seeing these days light themes, dark themes sort of thing on the web pages. So in order to name them, we would simply use mode or something like that so that they can easily understand and they can easily use them accordingly. Even the options in that style system should be named accordingly and they can easily understand so that they can easily understand. Excellent. Well, thank you so much, Rakesh, for being here with us. I appreciate all the audience questions. So thank you for keeping them coming. And Rakesh, it was great to see you. So thank you again for your insights. Thanks again, Dabur.