Empowering Developer Excellence with AEM Core Components

Join Kartik Sharma, Adobe Experience Manager Customer Champion, as he imparts valuable insights and best practices regarding Core Components.

Prepare to dive into,

  • Accelerating website development and reducing maintenance costs with Web Content Management (WCM) Core Components
  • A live demonstration showcasing how to transform a teaser component into a card-style component with multiple design variations
  • Best practices for optimizing your Style Systems
    *A step-by-step demonstration of deploying UI changes efficiently using the front-end pipeline

You can access the presentation slides here.

Transcript

Hello, everyone, and happy Thursday. Welcome to today’s developer webinar. My name is Susan Aziz, and I will be your host today. I’m part of the Adoption and Retention Marketing team here at Adobe, and we have a fantastic guest speaker lined up for you today. Before we jump in, I have a bit of housekeeping. And while I go through that, I invite everyone to say hi to each other, additional information regarding our speaker and a survey. Please be sure to fill that out before you leave today’s session. That survey is really important. That’s how we pick topics and presenters for future sessions, so you can give the presenters a lot of love and make sure to use the reaction button as well. So with that said, we are so excited. You can join us today, and I’m going to hand it over to our wonderful speaker, Kartik Sharma, followed by our customer success manager, Tommy Miller, for introductions. Hello, everyone. My name is Kartik Sharma, and currently I’m working as the director of Solutions Architecture at Wiley. Wiley is a global company and a leader in education and research publishing. I have over 15 years of experience working with Adobe products. Before joining Wiley, I worked with various Adobe partners and implemented Adobe Solutions for some of the Fortune 500 companies. My job is to help people with their business, and I have worked with Adobe for over 500 companies. My journey with Adobe Experience Manager goes back to the days of Day CQ. I have seen and been part of this evolution. I also have some experience with other Adobe products like Adobe Analytics, Target, Campaign, RTCDP, and Workfront. Recently, I am recognized as an Adobe Experience Manager champion. I hold various Adobe certifications, and certifications has always been an integral part of my professional journey. I also had the privilege of contributing to a few of them as a subject matter expert, like AM DevOps Expert Exam, AM Sites Developer Exam, and AM as a Cloud Service Migration Expert Exam. If you are interested in connecting, you can find me on LinkedIn. My profile link is given on this slide. Thank you.

Hi, everybody. My name is Tommy Miller. I’m a customer success architect here at Adobe. I’ve been with Adobe for a few years now, but I’ve been involved with AM for well over a decade. During this time, I’ve managed various AM implementations all the way from helping our technical teams or even just doing general consulting with various clients and partners. I’m really looking forward to today’s presentation as it’s a topic that I really enjoy, and I see that it often generates a lot of questions. So as Karthik is wrapping up this presentation, I’ll be teaming up with him as part of the fireside chat to help with any questions that you may have. I just also wanted to thank all of you ahead of time for being here with us today.

Okay, let’s quickly walk through our agenda. First, we will begin an overview of AM Core components, their features, benefits, and types, and then we’ll take some examples from each category and see how they look and what kind of options they provide using edit dialog or a design dialog. Next, we will explore the AM style system. With the style system, you can create multiple variations of same component without duplicating the components or the code, and it’s a powerful feature that allows for dynamic design and layout changes. Following that, we will see how to customize or extend core components. This will give us insights into the flexibility and adaptability of AM Core components. Lastly, we will discuss how to deploy and test our UI changes using front-end pipelines.

So let’s start with the overview. To start, it’s essential to understand that AM Core components form the backbone of AM’s modernization project. This modernization is all about bringing contemporary web practices to the forefront, ensuring AM stays ahead of the curve in the ever-evolving digital landscape. One of the significant advantages of using AM Core components is the out-of-the-box functionality they offer. What this means is right after installation, these components are ready to use. They are designed to accelerate the development process, allowing you to launch projects faster and more efficiently. In today’s multi-device world, responsive design is just not an add-on. It’s a necessity, right? So AM Core components inherently support this. They are built to ensure your content looks stunning and functions flawlessly, regardless of whether it’s being viewed on a desktop, tablet, or a mobile device. Last but not least, the easily extensible for custom needs. While we know that out-of-the-box features are plentiful, but we know that every project has a unique requirement, right? So the beauty of the AM Core components is their extensibility. You can tailor them to fit custom needs, ensure your digital experiences are both unique, as well as aligned to your brand’s vision. Okay, so now let’s see some of the benefits that these Core components provide. The main aspect of using AM Core component is its standardization, right? Using a consistent and standardized set of components across various projects ensures uniformity. This uniformity not only makes the development process smoother, but also ensures consistency and flexibility in the development process. It’s smoother, but also ensures consistent brand presence across all your digital platforms. We all know that this is one of the important factors in our projects, where we always want to deliver on time and quicker. So AM Core components are designed to accelerate the development process. With ready-to-use components available, we can drastically reduce the time taken from conceptualization or from design phase to the going time. Reduce maintenance cost. One of the benefits of using Core components is the reduction in maintenance cost. How is that done is because with consistent components, we will face fewer compatibility issues that require less time to fix patches, bugs, and there will be easier upgrades. In the long run, that translates to a significant cost savings for the organization. Lastly, and perhaps most importantly, is improved user experience. AM Core components are optimized for performance, ensuring that your content is delivered quickly and seamlessly. Moreover, the inherent responsive design capabilities mean that your content is accessible and looks fantastic on any device, enhancing the overall user experience. In essence, I can say leveraging AM Core components isn’t just about making the developer’s life easier. It’s about delivering superior, cost-effective, and consistent digital experience for our audiences. And according to me, that is available for everyone.

Now let’s move to the next slide. So these are some of the Core component features. I will not go into each and every one. I will pick a few. We have around 30 plus robust WCM Core components. They are well tested, widely used, and production ready. And they perform well. Cloud ready, I mean, whether you are using Core components in AM as a cloud service or Adobe managed service or on-premise, they work seamlessly.

Next one would be SEO friendly. The HTML output is semantic and provides schema.org micro data annotations. These components are teamable. They are customizable. They have versioning. And the best part is they are open source. That means if something is not there and you want, you can always contribute to that.

Okay, let’s move to the Core component types. So normally the Core components can be grouped based on their primary function into four categories. These categories are template components. An example for these components are like page, navigation, breadcrumb. Then we have page authoring components. Examples are title, image, teaser. Then we have container components. Examples are tabs, accordion, container. And last one is form components. Examples are text and form options. There are other Core components available now like for emails as well as for adaptive forms. We are not going to discuss on those in this.

Next one, let’s go to…

Let’s try to go a little bit in details for each of these categories. So first one is template components. So I will take an example of a few of them like page. So the page is a foundational layer where all our content sits. The page component forms the basis of all pages designed with the Core components as well as editable templates. Second one is navigation. Navigation provides like a list or a tree kind of a view for all the pages. And that helps users easily navigate around the site. Third one is language navigation. This one helps users to view the same page in different languages or locales.

The breadcrumb gives users the exact location where they are currently in their path as well as allow them to navigate across the pages. The last one I’m going to talk about is quick search. The quick search component allows users to search the content and view the results as well as also easily navigate to the results page.

Let’s move to… Next slide. Before going further about these components in detail, I just want to talk about the important aspect of Core components. Those are the design dialog and edit dialog. Edit dialog gives options that the content author can modify during normal page editing for the place components. And it controls the content displayed by the component and how it will ultimately appear on the page. For example, alignment of an image in a teaser component. Like do you want the image to be on the left side or on the right side, text on the right side or text on the left side, CTA on the bottom. So those kind of things you will control using the edit dialog. So design dialog gives options that a template author can modify when configuring a page template. And it controls what options the content author has available when editing the content, for example. Like you want to give options of aligning the image on the left, right, text on the left, right, or CTA on the bottom or on the image. Those kind of options you can provide, for example, in a teaser component using the design dialog.

Okay, let’s move to the next slide.

So this slide basically just shows how a breadcrumb looks like. And I mean, this is the actual HTML of that. And this is the design dialog, how you can configure it on page. And you can use styles tab to have different variations of this breadcrumb based on your brand guidelines.

This slide shows the edit interface where the content authors can choose the options available for them. Like they can start the breadcrumb from position two or they can go further based on your content structure.

And now let’s go to the language navigation. So again, this shows the HTML of the language navigation core component, the design dialog. And the next slide shows the edit dialog. I’m not going into too much details because I put these just for an example, like how these core components look from each category. So now let’s move into…

Now let’s go to the second category that is core components, page authoring components. So just take an example, like the title component is intended to be used for like titles or heading of a section or a page. And as a template author, you can define what kind of headings will be available to be selected, like H1, H2, H3, something like those. And then content editor can select while configuring the title component. For image component allows you to use adaptive image selection as well as a responsive behavior with lazy loading for the page visitor, as well as it allows you to place by the content author. And each of these core components have the design dialog, edit dialog, where you can use out of the box options, or you can even extend it or add more based on your requirements. The teaser component allows the content author to easily create a teaser using an image, title, rich text, and then it can even allow you to link to the other content or other pages. In the recent, one of the customers used teaser component as a card component with a gated content. So whenever you try to download something, you will get a form where you have to fill your form. And after that, you will be able to get the PDF. I will talk about one more core component in this category that is embed. The embed component allows the content author to embed external content within the page. It could be like a video from YouTube. It could be a PDF or it could be an HTML form. Other side. Okay, let’s move to this one just showing how a teaser component looks like, what are the options available for template authors in design dialog, and then what are the options available in the edit dialog for content author. If you see, there are variations defined where you can use your teaser component image on the left side, right side, text on top or bottom, all those kind of options. Okay, now let’s move to the next one. This is a download one that is showing the design view and the HTML of how it looks like. And this is the edit dialog. Okay, now let’s move to the next category that is container. So, I mean, container component allows the creation of like a kind of a container where you can combine multiple components on a page and can be used to group and applies like a similar style or layout to those multiple components. For example, like a coding component allows for the creation of a collection of components like that can be viewed as panels arranged on a page and like tabs. You can have tab look and feel. I will show you some examples like how they look. And then using your edit dialog and design dialog, you can set the options that the content authors and template authors can define. So, let’s move. This one is showing the accordion. This is a design dialog. And this is the edit dialog where you can define things like item one, item two, and that will show in the HTML. Okay, next one is carousel design. Same design dialog. Some of the options available in the edit dialog, like how you can define images, how you can put text, links, all those things that will come onto the carousel. Okay, the last category that we’re going to discuss is form components. So, form components has form container which allows you to have all other components as part of your container. And then we’ll talk about button component that allows you to trigger a submission of your form. And then one of your form options allows you to show like a drop down and the hidden one allows you to have some properties that you want to submit with your form that you don’t want to show to the end user. And form button will allow you to submit the form. Some of the examples of this are here showing like text fields and then submit this form button design and this form options. You can see. Okay, now let’s move to the next topic that is style system. So, at like a high level, I just want to say Adobe Experience Manager style system allows visual variations of components without backend development. So, it basically allows reuse of AM components and more versatile and efficient content authoring. The style system allows a template author to define style classes in the content policy of a component so that a content author is able to select them when editing the component on the page. So, let’s take an overview. There are two main flavors or styles that are implemented on the AM style system. One is layout styles. These affects many elements of a component to create a well-defined and identifiable rendition of the component, often aligning to a specific reusable brand concept. For example, a teaser component may be able to be presented to the traditional card based layout, horizontal promotional style or maybe a hero layout or maybe a hero layout overlaying text or images. Display styles are used to affect minor variations to layout styles. However, they do not change the fundamental nature or intent of the layout style. For example, a hero layout style may have display styles that change the color scheme from the primary brand class color scheme to secondary brand color scheme.

Okay, let’s move to the next slide. This shows the style system architecture. So, normally there are multiple steps involved when we start designing any component. So, initially a web designer creates some visual variations of a component. Then the HTML developers create the HTML for those variations. Then HTML developer defines CSS classes that correspond to each visual variation and they are inserted in the HTML wrapping those components. Then the HTML developer also basically creates some CSS code, JSS code for those variations. After all these things are done, then the AM developer comes into picture, he takes that CSS and JS and that put it into a client library and deploys it. Then the template author basically use those styles and using content policies, said that those with a user friendly name because we don’t want to use the same BAM style notations in our application. We want to use our edit dialogues because that will not make any sense to the content authors. And then the last, the content author or page author basically use those styles to have different variations of the component. This is the whole architecture, how it works basically. Okay, now I’m just showing some of the examples here, like how a teaser component can have different variations based on these styles. If you see the selected one, it’s showing a featured style. The look and feel is looking like this. It’s an example from a weekend site. You can also play around with this. If you change the style to a hero, the look and feel changes totally. The image goes on top, text comes and the CTA comes down. This is just an example of how these style systems work.

The next slide shows the design dialogue, like how you can set what options will be available to the content authors. If you see here, we have listed, featured, list. These are the options that are visible to the content author in the edit dialogue using the style options. These are defined here. You can give an option, like you can allow them to be combined or they can only act individually. You have both layout as well as design styles. Okay, now let’s go to… Some of the best practices for using styles, you just have to make sure you name styles using a vocabulary that is understood by the authors. For example, when you are using a card component, you can simply say that card component with left alignment or right alignment instead of saying it as a variation one, variation two. Because variation one, variation two may not be known to the author and if you onboard a new author, it would be difficult to train them. So it’s better to always use meaningful names when putting those styles. Always minimize the number of style options. So when you are designing, just make sure you don’t create too many combinations and you have to see, does it make sense to give… Just take an example, like in a teaser component, you have a text, you have an image, you have a CTA. So do you want to give the options individually, like text can be left aligned, right aligned, image can be left aligned, right aligned, and CTA can be on left or right. Or do you want to create nine different variations where you want to… You don’t want author to select them individually, but you want based on the combination of these. So you have to come up with these options when you are designing and you just have to make sure you restrict and you will only make them visible, which is required for that particular template or a brand. Okay, only expose style options and combinations that are allowed by brand standards, as I mentioned earlier. Also, make sure when you expose a multiple style combination, there should be no negative effect. So that also we have to keep in mind. Another important factor that I want to mention is when we are creating so many possible combinations of style, it always gives flexibility to authors, but it also increases the permutations, combinations of doing those variations. So we have to be very careful while giving those options. Too many options can also confuse authors as it may become unclear which option or combination is required to produce the design effect.

Okay, let’s go to next one. So this is… I’m just going to walk about like how we can customize a core component.

Let me just give you one second. So let’s move to the… Susan, is slide moving? I think I’m having some issues here. Okay, yeah, thank you. The core component are designed to be flexible and extensible. The core component architecture, this is an architecture diagram that shows what all options are customizable and can be leveraged by developers. So as I mentioned earlier, design dialogue defines what authors can or cannot do in the edit dialogue. The edit dialogue shows authors only the options they are allowed to use. The Sling model verifies and prepare the content for the view, the HTML template. The result of the Sling model can be serialized to either a JSON output or like for SPAR pages or an HTML output using the HTML template. And all core components implement the style system. Can somebody… Yep. This is an overview of the entire resource type binding structure showing an example of title core component. This shows how a site specific proxy component allows to resolve component versioning to avoid that the content resource contains any version numbers. It also shows how the components title or HTML file uses to the model interface while the implementation binds to the specific version of the component to Sling model annotations. This is another overview of the previous slide which shows how they look. I just want to mention about an important property called allowed template that basically can be used for sites. Every template is made of normally three parts, structure, initial and policies. So structure contains the resource that will be forced on each page to be present and the authors won’t be able to delete it initially. You can set what kind of content will be available when you use that template and then the policies on each component allowed on the template. Okay, let’s move to the next slide. How to succeed with core components. First thing you have to keep in mind that you start early. When we are in a design phase, we can always use an option like we can give the designers the Adobe UI XT that is available as a part of core component. We can also map them to the design and then you can use the out of the box core components that the HTML they provide instead of recreating it. It’s very important that we start early and always map your designs to the core components, reference the component library so that you know what are the variations available, how you can customize it and always try to use core components as much as possible. If there is a customization required, we can do that but try to avoid creating custom components because sometimes multiple core components can be combined to achieve similar functionality. So I think we should spend as an architect or developer, we should spend some time during the initial design phase. Okay, now move to the next section that is our front end pipeline. So the front end pipeline can quickly deploy just the front end code for your AM sites based on site themes and site templates. So normally like this is mainly applicable for AM as a cloud service instead of deploying the full stack, only front end code can be deployed using this pipeline. So this pipeline can be enabled in two ways. One is if you are using the AM sites based on a site template, it’s enabled by default or if you’re creating a new project using latest archetype, what you can do is you can just use a front end module flag and pass the option called decoupled. So that basically make your project suitable for AM front end pipeline.

Okay, now AM, there are a few things that we need to do in order to enable it. First of them is, can we go back to the previous slide? So what we have to do is like normally how we enable it, we basically log into AM and then we navigate to the site console and then we basically select from the left side and then we simply say enable front end pipeline. And once we click on this button, we will get the confirmation. So the confirmation tells about what it’s going to do. And once you click on confirm, this front end pipeline is enabled. And once front end pipeline is enabled, you will be able to download. Just one second. So you will see an option to download the theme sources that you can use to push your front end stuff here. Okay, and then let me go back to slide.

Yep, so this is a step showing how you can configure pipeline using the cloud manager. So basically you just click on create new pipeline and you will get an option. You just have to select front end code, you define your environment, you define your repository, you put the option like is it going to be manual or on grid changes. And then these are the options that you define. Like this is for my sandbox dev environment. This is the org. And you can, even if you have like separate branches of like say dev branch, qu branch, you can specify the branch and if you have a different location instead of the root, you can define that as well. And then not this one. And then you can just run it and you will be able to immediately see your UI changes. Thank you. Okay, we have plenty of time for Q&A. So feel free to ask some questions in the Ask presenter chat. I have a couple here that came in. I’ll go ahead and read these out loud. Okay, first question. How are core form components, not adaptive form core components, connected to data sources and destinations? So it depends, like you can have a like a sublet, you can use a sublet, sling sublet, or you can use some kind of Ajax calls to post your data to the REST API endpoint. Or if you are just storing the data in AEM, you can expose that as using sublet.

Great. Tommy, anything to add? Yeah, the only thing I would reference is take a look at the form container component. There’s dialogue options associated with that in addition to that configuring the endpoints associated with it. Yep. And I could put some upload link to that into general chat.

Awesome. Next question. Could you please describe OOTB functionality in very simple terms? OOTB is out of the box functionality. I mean, for which component they’re talking. I need specifics. This might be more general. Yeah. So I think we can provide the link to the AEM core component library where each component has a like an HTML that it outputs what all options available in edit and design. So I think that would be helpful to go through. Yeah, and I think I would just say overall with the core components, what we’re trying to do is create something that is incredibly versatile that covers a lot of common use cases. And these use cases, you know, they can consist of just modifying the front end, right? The dialogues are already built out very, very well. There’s a lot of accessibility options that are built into the functionality as well as integrations with some of the other tools like the analytics.

So high level, all these components are built that way. And they’re easily extendable as Karthik’s kind of demonstrated this with me going through the slide deck.

Great. Next question. Is it better to create a custom component or extend a core component? If you create custom, you won’t have any dependencies. If you extend a core component and the original core component gets updated, then you need to do extra effort to update your component that you extended. With custom, you don’t have extra work. With extended, you have extra work. What are the benefits of doing extend of WCM in this case? It’s not right. I mean, there’s an option called versioning. So versioning allows you to still remain with the old version. And so when you extend a component, right, you can still leverage all the functionality. You can still remain on the old version. And for some sites, you can go to the higher version, right? So it’s not that you have to like, upgrade immediately. It’s up to you. Like if you want to upgrade, you can upgrade. If you don’t want to upgrade, you can still remain with the old version. That’s the benefit of versioning. When you go with custom component, basically you are creating something from scratch, right? And you will not get the benefits that are available with the core components because these are production ready tested. They have a better performance. They are tested against so many devices and all those. So it’s always recommended to extend a component if you can only create a custom component if you are not able to even achieve the functionality that business is asking for, by even combining multiple core components.

Yeah. And then the one thing I would also put emphasis on is that these tools are open source so that we’re constantly, they’re constantly evolving. Additionally, from a support perspective, these are supported by Adobe. So if you are building custom components out, ultimately that responsibility, if there is an issue, relies on the development team that’s implemented it to resolve those specific issues.

Great. Next question. Where is the actual CSS edited? So, I mean, if you have seen the latest archetypes, I mean, there’s a UI front end where you put all your CSS and all those, and how it works is like, if you are extending or creating the variations of these core components, you always just use the base and put a kind of a proxy component. And then you have your CSS there that will automatically combine and goes into client-lib. But if you are using the approach of like going with a separate UI option that I showed in the last deploying through front end pipeline, then it will be a separate project structure that can be combined and goes to, instead of going to client-libs, you can directly push it to the CDN. Great. Next question. So decoupling of front end module to build with the front end pipeline details. I guess more details on that. Yes, I think that can be done with cloud. Oh, go ahead. Yeah, it’s only available for cloud. It’s not available for on-prem or AMS. So that is only available for AMS as a cloud service. Tommy, anything there? There is documentation on experience league that goes through a lot of the cloud manager related configurations that can be done to set up those pipelines. So I would check that out. Yep, I can share that link later. Reach out to me. I also showed how it can be done on a sandbox environment or a production program environment. Like you just test simple pipeline, but before enabling that pipeline, you have to make sure that you have enabled that for your site and you have the source code in your client-led environment. Great. Next question regarding deployments. So is purging the catch the only solution for deployment issues or is there other issues that come up with the deployment? Cache can play an important role. So when you are creating your rules for your dispatcher in CDN, you have to make sure, especially you will not have issues with the CSS and JS because if you’re using the front end pipeline, every time it generates a hash and appends to the resource. So you will always get the latest CSS and JS. Great. Next question. Decoupling. So we would like to make the front end changes without having deployments on the back end override any tips. Yeah. I mean, if you’re using AM as a cloud service, that’s what this AM front end pipeline does. So you, I mean, you don’t even need a team that has a knowledge of AM. They can work independently and they can make those changes and you can test those changes without doing the full stack deployment pipeline. You can just simply deploy your front end changes.

Tell me anything that. No, I think that pretty much covers it. Perfect. Where can I find the AM dispatcher catch policies in AM? I mean, it’s all like there’s nothing out of the box available. You just have to put, and you can get some samples available on GitHub and as well as experience. But all, all of those are basically the Apache rules that you have to put in your dispatcher confile. And same. I mean, recently there is another option. I mean, that’s still not widely used that you can, you can just put in a file. I mean, recently there is another option. I mean, that’s still not widely used that you can even use the, if you’re using AM as a cloud service, you can use a fastly CDN rules now, but using, and that you can deploy through a pipeline, but that’s still not widely used. Great. Okay. We’ll take a couple more questions. The next one, can you explain more Adobe XD usage? Does it need a separate license? Can it generate a skeleton AM component code from design? I think what he might be asking is the one that comes out of the box will give you the design of the core component that can be leveraged to create any, like when you are, you’re designing your sites, your designers can use that as a reference so that they, they know what, how the core component looks, what are, what is the wireframe? And based on that, they can create your components. But actually always comes with a license. I’m not the right person to answer that. But, uh, it’s a slightly bigger conversation.

Awesome. Okay. Next question. How easy slash tough to extend tab component with image SVG option. Currently, we can only give texts there. Oh, that’s a good question. Uh, I mean, I have not seen a use case, but it should be, I mean, it’s, it depends upon like how much we are making change on the HTL and what all needs to be done. Or we can even combine tab component with a image component. So based on the design, I can answer it without that. It would be difficult. Yeah. There’s a, there’s a little bit of an architectural decision that needs to be made as to how it’s going to be implemented. Um, so, uh, to cardiac’s point, right? It’s like, well, the first thing you’re probably gonna need to do something dialogue and you’re going to need to look at the HTL and depending on how you’re approaching it, you might have to, uh, extend those slight models as well.

Great. So with that, that puts us at time. Thank you everyone for submitting questions. Again, we will follow up with the on demand recording. Keep an eye out for these AM webinars. Um, we’re planning to host throughout the year. So, Oh, and a friendly reminder to please register for this year’s developer live. Thank you all so much and enjoy the rest of your Thursday. Thank you everyone for joining.

Thank you.

recommendation-more-help
76e7e5df-e11d-4879-957b-210b1656662e