AEM Core Components & Style Systems

Transcript

Thank you. Hello, my name is Will Brisbane and as previously stated, I am a senior technical architect here at Adobe. I have been with Adobe for one year now, working in the success services, and I have been working in the AEM implementation space for the better part of the past 10 years. Outside of my work activities, I enjoy building demos and working on integrations within the AEM space. And also, I do enjoy learning new platforms and technologies. Outside of work, I enjoy playing board games and to exercise, though I am admittedly a pretty slow runner. I put my LinkedIn profile here on the page. So if you do want to connect, that’s a good way to reach me. I am always happy to make new connections because we do live and work in a very small world. So today for my presentation, I will first be discussing core components, then going into style systems. For both of these, I’m assuming no previous knowledge. So I’ll start with an overview of what AEM core components and style systems are, the benefits of their use, followed by some recommendations to hopefully help drive adoption of these powerful features. I’ll then wrap it up with some closing thoughts before launching into some Q&A. Core components are a library of generic AEM components built to speed up development time. There will be a link in the chat which will lead you to the AEM core components library website, which has a full list of all of the components that are available, along with some documentation and sample code for each one of these components. The cool thing about core components is they are completely customizable and they are versatile enough to work with nearly any design or layout. They’ve been designed to take advantage of style systems, making them even more versatile and customizable, so you can achieve stylistic variations of the same content with less need for development work. And through the content policies for these components, they are configurable to define which features authors can or cannot take advantage of. Some of the other benefits of core components is they are well tested, they are widely used across the AEM customer base, they perform at a level that makes them production ready and cloud ready. You can use them whether you are on AEMs, on-prem or AEM as a cloud service. They do follow SEO best practices, so the HTML output includes SEO friendly data, and they do follow accessibility standards to make them accessibility friendly. Through the integration with the Adobe client side data layer, the core components also provide analytic support, so that you can fully track every stage of the customer experience. They are well documented. There will be another link here in the chat for the experience league documentation, which details additional information about the features, how to implement, tutorials on how to implement, and they are open source. Another link will be dropped in the chat for the GitHub address, so that you can take a look at the code, as well as contribute to the project if you’d like. AEM core components cover many of the common client use cases, and those are actively being expanded and improved upon through that GitHub project. Every implementation project I’ve worked on has included things like teaser components, image components, text, navigation. Core components covers all of those bases, so it reduces the maintenance and development time and cost to allow you to get to market faster. For all of these components, since there is a set of code that’s already been tested for you, you can easily extend the component, so that you’re not starting from scratch. With these upgrades and improvements to the components through GitHub, they are released in version releases. This presents a very clear and concise upgrade pattern, which is very brand refresh and upgrade friendly. So, as we show in this graphic, if you’re extending a component in your app library, and you would include the Slings resource supertype pointing to the core component library, once you’re ready to upgrade to a new version, all you have to do is change the version number within that resource supertype. This allows you to upgrade your components on a component by component, case by case basis, without having to overload your development team and your QA team with regression testing. Style systems allow template authors to define style classes in the content policy of a component or a page within the template. This allows the content author to apply styles to an entire page or the component instance on a page to apply a stylistic variation. This makes components and templates more flexible by empowering authors to render alternative visual variations. And this reduces or eliminates the need to develop custom components or at the very least, not as many custom components, and drastically reduces the need for complex dialogue to present those custom variations. Here on the right, I have a screenshot of an example of a style that has been configured. Under Allowed Styles, we have a category heading. You can have different categories, and each category can have multiple styles. These styles can be combined or exclusive to only one selection. In our example here on the left, we have Heading 1, Heading 2, Heading 3. Those are the user-friendly labels that the content author would see. On the right, we have the CSS class names that would be appended to the HTML, which is then used to achieve the stylistic goals. Setting up style systems is a multi-step process. It typically starts with the business, determining what the content and the objectives are for any given component. From there, it goes to the design team to do what they do and determine what visual and experiential presentation of the content needs to take place. Typically, wireframes or samples are presented to the developer and the architects, who would then develop the CSS and the JavaScript libraries to support that experience. They would then define and provide those class names to be used that we saw on the last slide. Those would then be provided to the template author, or in many organizations, the development team would also handle this portion and configure the template policies for those style components by adding the CSS class name and the associated user-friendly label mapping into the template policy. From there, the content author is then able to apply styles as needed to achieve the desired look and feel when authoring the pages. There are two main styles, or I prefer the term flavors, of style systems. The first are layout styles. These are multi-faceted changes to the design and layout, and they are used for well-defined and identifiable renditions. Here in this example, we have a component with a eyebrow, a heading, a block of text, a call to action, and an image. By selecting the style, the content on the left can change to the content on the right with different background color, a different crop of the image, image orientation, the spacing between the text. This is an example of a layout style because it encompasses many changes and fundamentally changes the look and feel of the component. In the pre-style systems world, doing this would require either multiple components or a very complex implementation of a custom component with a most likely complex dialogue as well. The second flavor or type of style system are display styles. These are more minor variations that do not change the fundamental nature of the style, examples being things like changing the color scheme, changing the font, face, or size, or color, or strength, the image orientation, the image crop, or even showing or conditionally hiding things like the headline, the text, the eyebrow, or the call to action. When developing style systems and implementing them into your code, I typically recommend nailing down the default style first. The default style is going to be the layout and display of a component when it’s first dropped on the page prior to the application of any styles. This should be the most used rendition because it requires the least amount of work. This should be what the component looks like when an author drags and drops it onto a page and puts their content in. So establish the default style first and then develop your style systems to alter that display based on the design needs. Try as much as possible to only show style options that have an effect. As an example, if we have a layout style that dictates the position of the image, the position of the headline, and so forth, if a content author selects that layout style, if they have the option to also change the image position, but it doesn’t actually do anything because it adheres to the layout style, that would be ineffective. So try to avoid that as much as possible just because it can cause confusion. If it is unavoidable, and it can be unavoidable just depending on how many options you want to give your content authors, do ensure that they don’t cause any negative effects. I see this most often with things like alignment of images, alignment of text. If you’re combining styles, sometimes you can achieve things that don’t really look how you want them to look. I typically recommend that layout styles be used over display styles. This has many benefits. It’s more user friendly because the content author only has to usually apply one style versus trying to remember multiple different style options that they have to select to achieve a certain look and feel. It also reduces the number of permutations that must be QA’d. If you have a featured hero and a card and a list, those are three things that need to be tested. If you give the content authors the ability to change image orientation, text colors, then you need to test every possible variation of that and it can quite quickly get out of hand. Layout styles ensure that brand standards are adhered to and helps to create a consistent site brand identity. If you do use combined styles, be conservative with those combined styles. You can combine styles across categories, so padding and font color, or you can have combined styles within categories, top padding, bottom padding. Even still, please be conservative because again, it does create a more complex authoring experience and it does require additional testing. So do allocate proper time to thoroughly test those combined styles. Minimize those number of style options and permutations to avoid the lack of consistency for brand look and feel, to minimize content author confusion, and to not increase QA. I also recommend to use business user friendly style labels and categories. In a lot of corporations and businesses, you may have a primary brand color and a secondary brand color, but using terms like blue and red are a lot more intuitive and not subject to change, whereas things like primary and secondary can change depending on the business or the context in which those primary and secondary colors are being used. So blue and red, they’re always going to be blue and red. Same with layout styles. I recommend using terms like card and hero instead of variation A and variation B. This cuts down on the amount of training that you give your authors and helps to expedite the content velocity of your content authors. To summarize, core components I highly recommend using. They are well tested, widely used, production ready, cloud ready, accessibility friendly, SEO friendly. It helps to jumpstart your development. As a developer, it’s a lot faster and the velocity of development seems to move a lot faster when you are able to actually see things on the pages at an earlier stage. Core components provide you with a code base and a set of tried and true components to start with. Using style systems in conjunction with that just further enhances the benefits of using those core components. It reduces the amount of custom development work you need to do. It decreases the complexity of your implementation within the dialog because the code for style systems is mostly CSS based. However, style systems are not a dialog replacement. Style systems should be integrated into your overall approach to component development using the dialog properties and the style systems. And as I’ve said, it can really just do wonders at streamlining the development and authoring process and cut down on the time to market. And with both of these things, it is very much an art and a science. Everyone’s use cases will differ slightly, so use core components as much as you can. If you need to overlay them, extend them, that capability is there. It still grants you a really good head start on the development process. Same with style systems. Style systems allow you to do that styling and really cut down on the amount of custom development work. But again, it’s an art and a science. It’s a little bit of give and take on where you use them and where it makes more sense in your business or to do custom. Thank you so much for joining. I hope this was good information. Please be sure to check out those links for further reading. But right now, I am excited to take some of your questions to dig a little deeper into some of these topics. I’m so pleased to announce that we have Will with us today for some live Q&A. So Will, thank you so much for joining us. Hey, thanks for having me. I’m super excited to answer some questions. Yeah, we have some great questions that came through from the audience. So thank you everyone for asking them. The first question, Will, comes from Rakesh. And the question is, can a style system be part of the code base? And if so, should that be a client lib or some other resource type? Good question. Actually, it can exist in the code base. And it would actually probably exist in a couple of different places. The configuration that you do at the editable template level is just like a policy. So if you include it in code base, it would be included in with like the conf. So usually like in a content module of your code base. The styles and the CSS and JavaScript that kind of complement and empower the style systems. Those is where I would put those in a in the client libs. Awesome. We’ll keep moving along. Our next question is from Milen, who has asked a few questions. So thank you so much for the active participation. It’s great. Great to see. And the question is, is there a plan for creating a table component? I don’t know, to be honest, I haven’t seen it on the roadmap, but I do know that a lot of our customers do have custom components for tables. But it’s not something I’m aware of or have seen yet. OK, so stay tuned for more updates to come, hopefully. Our next question is from Shay Jad, and it is in case of a layout style, have you faced any accessibility problems, maybe in the order in which the content is read by the device reader? Maybe expand on on that a little bit. Sure. Yeah, there are definitely some factors and considerations that you have to keep in mind when using style systems. From an accessibility standpoint, core components are developed in a way to be accessibility friendly. But when you’re designing your style system options, you do have to keep the accessibility in mind. So if you allow, for instance, if you allow content authors to modify the background color and the text color, those can result in failing to be in compliance with text content contrast. And then as was pointed out in the question with screen readers, when you when you use style systems, they can alter the visual layout of the content. So you can move where things show up, but the DOM structure and the tags aren’t modified. So when you’re adjusting font size or positioning of text, those site visitors that are using screen reader will consume the content in the order in which it appears in the DOM. So to your point, absolutely. If you’re using device reader and style systems are moving content around and changing emphasis, it can lead to confusion or loss of context for those those users. Awesome question. Yeah, excellent. These are these are really great questions. So I’m glad we have you here live. Will to dive into them. Our next question is from Dominic, and it is, are these usable with SBA’s? And if not, do you have plans to support angular slash react in the future? They should be. I’ve never done so myself, but the with. You should be. Yes, you should be able to use core components and and the related style systems within SPA’s. Awesome. OK, so that’s that’s a yes to me. So I love to love to hear that. Our next question for you is is a good one. How do you determine whether to extend a core component versus create a custom component? So in those scenarios, you you first have to look at what the core component does. So if the out of the box core component offers all of the functionality that you need for your business use cases, then you can just use the core component as is. If the functionality is covered, but the look and feel is not, that’s when you would use a proxy component and utilize style systems to to get what you what you need out of it. If those out of the box core functionalities cover almost all the requirements, but you still need to add new features or extend the functionality. That’s when you would extend the core component and modify whichever H.T.L.s or dialog entries you need to. You could also consider the use of composite components where you kind of combine multiple core components into a single one. And if neither of those routes work, that is when I’d say you need to create a custom component. Awesome. Well, it’s good to know there are some things to do prior to creating a custom component. So thank you for that response. Our next question is, can I have different configurations available for the same component in different locations? Absolutely. You can have different component configuration options at a template level. So from page to page, if you happen to have multiple layout containers on a given template, you can have different configurations for each location where that component is used in those layout containers within experience fragments. Since those use editable templates, which again is a requirement, you can have different configurations for those components on experience fragments. The same is also true for style systems. So on one template for text component, you may enable bold and italics and one set of styles. On another, you may have no bold or italics, but a different set. So you can have a different set of allowed styles and component options to achieve whatever level of reuse or customization in those different locations. Awesome. And our next question comes from Timothy. If we are using Adobe Target to export and deploy components built in AEM on a site that doesn’t have any of the styles in the AEM site, is there a way to convert the AEM code as an HTML5 component? I would think you should be able to, but when those experience fragments are being consumed, it should contain all of the HTML and style that you need. So whether you’re exporting it to Target or using those experience fragments in a more headless capacity on other web properties, the style system should still render the way you would see it as if it was on AEM. Excellent. And I see… I’m not sure if I answered that question fully. No problem. And Timothy, if you have a follow up to that, feel free to put it in the chat. We do have some time left for additional questions, so keep them coming. We really appreciate you being here, Will. And our next question is how do Adobe customers typically use page level style systems? So I will say that page level style systems I see used quite a bit less than component level. With component level, you see those a lot more because then you’re able to achieve the look and feel and the different visual presentation of the content in different ways, which effectively reduces the number of components you need. But with page levels, I don’t see it as much, but when I do see them, I see them in a few different ways. The most common use case I see is for brand distinction. So what I mean is if customers that have multiple subsidiary brands under one like corporate, you know, or umbrella, and they’re all on AEM, you can use those page level styles to allow for the reuse of templates and components. And those templates and components can then be organization agnostic while still rendering each page with the brand specific look and feel. This can be really huge for orgs that do have those different brands since in many customers I have seen them developing a text component or a teaser component for each individual brand just to achieve the same functionality but different looks and feels. I’ve also seen customers use them for site redesigns or content refreshes. And by doing this, it allows them to update sections of the site incrementally instead of kind of all at once. And they can do so while maintaining the existing look and feel. I’ve even seen one customer use page level styles as a sort of replacement for multiple editable templates. So using the style system to, you know, drastically shift the layout of the page and all of its contents. So in general, I wouldn’t highly recommend that approach, just because it can be a lot to manage but those page level style systems while not used quite as much can be super powerful. Excellent. And we actually did get a follow up from Timothy’s question so I’m going to ask that to you right now and the reason he’s asking if AEM can convert it to HTML component, because it would solve the issue. When, you know, none of the AEM site has styles that conflict with AEM styles example, AEM defines dot FOO, you know, color red versus non AEM site dot FOO color green. So I know it’s tough to to fully answer without seeing the text there but if that made sense I’d love for you to expand upon that. I would say that should be good. Within HTML component because we are talking about experience fragments. Is that right, Rob, it did say experience fragments in there. Yes, let me go back up, it’s doesn’t say experience fragments, it was actually had to do with Adobe Target to export and deploy components, built in. Yeah. So, I went to the experience fragments just because with exporting from AEM to target. Usually that is done through experience fragments and, and with those style systems and, you know, using core components and the style systems in place there. It’s all kind of wrapped within, you know, higher parent level DOM elements. And when you are writing the styles, the CSS for the styles of your core components and the style systems. You should use a level of specificity to specifically target things within that experience fragment, which then would make it so it doesn’t conflict. As far as converting it to HTML component where you’re basically just, you know, effectively dropping it on the page like you would a iframe. If you use that level specificity with the CSS, I think you should be good to to use those and not have conflicts. Because then it’s not necessarily using the AEM styles, it’s just pulling over through the, you know, through target and all the client lives from there. Excellent. Thank you for expanding on that. That was, that was great. And we do have time for one, maybe two more questions. So our next question again comes from Milan. And is there a way to have a style per component and bundle only when they are placed on the page as opposed to, you know, by default in the client live only use, can you, can you say that one more time? I’m sorry. No problem. Is there a way to have a style per component and bundle only when they’re placed on the page as opposed to by default in the client library client there? So, I mean, at a super, super basic level, I mean, that’s really no different than having, you know, an inline style within the component code. So you could design your client libs so that it, it only loads those styles as part of the component versus, you know, wrapping it all in like the site styles. There, there likely would be implications around that as far as like the, the benefits around like minification of, of your, all of your CSS. But, but yeah, I mean, it’s, it’s, it’s definitely possible to have those styles only be output when you actually have that component on the page. It would just be part of the component code and how you set up your client libs. Excellent. Well, thank you so much everyone for asking Will your questions. That is all the time we have with him today. But Will, I just wanted to thank you for joining us and giving the audience more knowledge about core components and style systems. It was great chatting with you. Thanks. You too. Thanks a lot for having me. It was a lot of fun and thank you all for the questions. Have a good day.