The Growth of AEM’s Front End Landscape
Adobe Experience Manager (AEM) is in the middle of a paradigm shift. A shift away from what has, historically, been a backend heavy ecosystem. The overall goal for customers is the ease of use. If designed right, the style/look/feel of a component can be dictated by the author rather than the developer through the use of AEM’s style policies.
Adding/Changing/Deleting a style would no longer require a backend developer. It should mean a lower cost to the customer in the long run. Traditionally, backend developers have carried a lot of the burden around creating new pages and/or components. They built the models, the dialogs, and any associated clientlibs. Then, they would hand it off to frontend developers to style and add user-driven functionality.
Since AEM 6.2 introduced the concept of Editable Templates, the amount of server-side development has been reduced, and it makes sense. Every time a backend change is made, be it in the Java model or the XML driving the component’s dialog, a new build is required. This can introduce unnecessary risks at deployment time.
The Style System, as it is called, was actually released as a feature pack in 6.3 but will be shipped out-of-the-box starting with 6.4. This new feature is the first of many that will start to have AEM shops thinking “Do we have enough frontend developers?” And, “Why is this a big deal?” Well, let’s look at the ‘old way’ of doing styles.
The Old Way of Styling Components
The traditional way a style is made available to an author is through the component’s authoring dialog. That dialog is presented to them before the component, or page, is rendered in the DOM. So, any changes/additions/deletions to the options in that dialog require modifying the underlying XML that builds the dialog. And, that requires a new backend build.
With the new Style System that burden is removed. It is now housed in the Editable Template’s policy for that component. This means that the author can actually change the look-and-feel of the component after it has already been rendered. This is huge. Now, if we want to add/change/delete a style we just amend that policy. A new build is not required. This approach does, however, mean more work for the frontend developer. Let’s discuss that more below.
Download Blue Acorn iCi’s “Amplify the Customer Experience with Analytics” whitepaper to learn how you can use analytics to enhance the entire customer journey.
What Is the New “Style System?”
New components created within Editable Templates can now have policies applied to them that are defined in their respective templates. Components with these policies and a _cq_design_dialog node will now have a new tool available when selecting a component – a paintbrush. This paintbrush is a drop-down that contains the various styles available to your component. The option selected adds a user-defined class name to the component. The frontend developers will hook into this class to create the desired style changes. This is a lot different than before, where you had to use an Expression variable to read the class from the dialog, or model.
Frontend developers will now need to create these underlying style policies as well as the associated classes and styles. The shift is complete. This lowers the risk associated with changing the backend code. It lowers the risk of a missed deployment. And, it increases the flexibility of styling components as the author can see the changes immediately without having to re-author the component and wait for it to re-render.
What Are the Use Cases for Using Style System?
The Style System is a great advantage for any author. However, it can actually make styling much more complicated depending on the use case. When using the Style System, it’s important to make sure the component is well defined in terms of its usage. For example, components that stretch across many templates would not be good candidates. The reason – every style policy that is added to a component must also be added to the template(s) it is used on. This can create some issues downstream when the project scales up. Adding a style policy to a ubiquitous CTA (call-to-action) component could create more headaches if you’re embedding the CTA into other components or dropping the CTA into a component’s parsys.
The best use case for the Style System is a component that has a very well defined location and style set. A good example of this is the home page hero. Since this component will always reside on the home page — and ideally just under the header — the risk of creating a complex stylesheet to handle all possible combinations is mitigated.
What’s Next?
Well, The SPA Editor will be huge in AEM 6.5 and continue to push the aforementioned paradigm even closer to the frontend side of AEM. It’s inevitable. If AEM companies aren’t ramping up on frontend developers now or teaching Java devs Javascript, they could soon find themselves too far behind the curve.
If you need help optimizing or implementing your AEM solution, contact our team today.