As a designer, if you can work with what AEM provides out-of-the-box, you’ll be enabling flexibility for authors down the road. This means using dynamic templates which can be altered (potentially affecting many pages without having to modify them individually), leveraging core components (great for common and basic needs), establishing image profiles (so that an image cropping strategy can be applied and served through dynamic media), and selecting other built-in AEM features.
Through a combination of template strategy and class names, significant custom design implementation can be applied without custom component development. It’s not that custom component development should be avoided; rather, it’s best applied to problems not already solved by core components, templates, and policies.
From the perspective of a design and front-end team, here are some recommendations aimed at optimizing out-of-the-box AEM usage effectively. Note that many of these items benefit from being considered prior to a design being created.
-
Choose fonts early, keep to one or two families, and limit the number of weights used. If your desired fonts are not free, get approval for a license. I mention this not because it’s AEM-specific, but because font choice can have a significant ripple effect on the entire design of a site. It’s also important to test support for languages when used in a multi-lingual site.
-
Use the built-in 12 column grid. This grid is a bit unusual for designers because it has no gutters between the columns. Designing site components to fit within this system will unlock all the layout and responsive testing tools available in AEM author. This is especially important if components are designed to be moved next to each other and not just stacked.
-
Keep in mind that AEM has specific breakpoints in it’s responsive testing tool. They can be changed, or used as a good starting point, for CSS responsive strategy. Ultimately, content and potential content should be the primary driver for responsive layout.
-
Identify areas where the simple 12 column grid is not enough, or, a combination of template areas and default components can’t achieve the desired results. In those cases, a custom component is the best way to go.
-
Create a content image strategy. Define types of images (photo aspect ratios, icons, etc.) and how they crop responsively (smart crops). Ideally, use a defined list of image sizes to inform the design.
-
Create a style guide for standardized treatments across templates. The guide should include headers, text, links, link hovers, lists, colors, image treatments, and any other standardized features. Adding notes about how the entire layout is expected to scale for small/regular/extra-large screens is helpful. Ask yourself: at what point does it max out? Do edge-to-edge photos have a max width as well?
-
Specify hover styles for any block of items that link. A common web design trope is to visually break out highlighted or promoted pieces of content and provide a rich link (image/title/text/button) to those items. These “promos” can be interactive by only the clickable link/button, or by making the whole block linkable. If it’s the whole block, providing a preview of the hover state is helpful there. Otherwise, text/button hovers are usually covered in the style guide.
-
Create at least a smallest mobile, and standard desktop variation for each page layout. Often, mobile is not really required as components tend to have a natural way of breaking down into a single column view for mobile. A mockup is still worth doing because it’s hard to anticipate where it’s useful until it’s actually created. When it’s not provided, a lot of decisions about the aesthetics and user experience will be made by the front-end developers. This is not always a problem, but can sometimes lead to extra revision cycles as expectations haven’t been set.
-
If the site menu system is hidden behind a button in mobile, demonstrate how it looks when activated on mobile. This also applies to any highly interactive component designed for desktop: map interfaces, high-reactivity search results with filtering, animated diagrams, calculators, etc.
-
Any block that has text in it should not have a fixed height; minimum height is ok. A fixed height is created when a design specifies both top and bottom alignment of text with a box or image. Better to keep content areas flexible. There are lots of ways to provide alignments and symmetry without fixed height. Fixed height could be considered “brittle” as responsive sizing, and updated or translated text, could break it or ruin the look.
-
Decide on a template strategy. Identify listing type pages vs. content type pages and any other structural needs, and give the templates names. This often happens naturally as the product of creating site designs, but it never hurts to consider this from a content perspective first, and then decide which parts should be specified in the design.
As you can probably tell, some of these suggestions are not AEM-specific and would apply to any web development project. Many of these tips also may seem strange if you’re coming from a strictly JavaScript (JS)-framework-only coding environment. You can, of course, develop a headless solution in AEM to pipe data into a single-page application (SPA) interface. If you have the opportunity to establish a regular website that takes advantage of actual pages, then I hope you’ll find these tips to be of use in your design process.