I currently have experiences with our customers where the teaser component has so many features that its overloaded with too many features, causing confusion for content authors, it’s often referred to as “feature creep” or “overcomplication”.
In this case, moving forward during component development, if there's a bug or a new feature that is done on that same component... it may break other features. But from your requirements of teaser component with card layout and hero layout, it seems like these components are quiet small, and the functionalities are much the same... I would prefer you create a single component and have these two cases covered, but either option works... However, you should speak to your product owner and have him speak to the authors to see what they think is better for them... after all, as AEM engineers, we try our best to ease the lives of the authors.
Note: As your components get more complicated, your author's would need complicated training... if a teaser component has like 5 layout options and 15 style system options, this to lead to the fact that only power authors can author on your website.
Adobe recommends several best practices for creating components to ensure they are effective and user-friendly. One key aspect is indeed to avoid overcomplicating components. Here are some best practices to consider:
- Keep Components Simple and Focused: Each component should have a clear and singular purpose.
- Avoid bundling too many features into one component. This helps prevent complexity and makes it easier for content authors to use and manage.
- Reuse Components: Design components with reusability in mind. Create components that can be used across different pages or sections, and ensure they are modular and flexible. This reduces redundancy and makes maintenance easier.
- Optimize Authoring Experience: Ensure the component authoring interface is intuitive. Use clear labels, provide helpful tooltips, and organize fields logically. Aim for a clean, uncluttered design to minimize cognitive load on content authors.
- Reduce the amount of components: Reducing the number of components can be a key strategy in AEM development to simplify the system and improve the user experience for content authors.
=====
- if we go that route, would future AEM upgrades that affect the teaser component be reflected in these additional components that leverage the same code?
Going into the future, as AEMaaCS improves the AEM Core Components, any new feature enhancements should be less risk. Say you target the Teaser2 core component. If there was an upgrade to this component, it wouldn't be severe. Severe upgrades would introduce a new version like Teaser3, which you would need to change the resourceSuperType and also re-test your Proxied Teaser Component.
Regards,
Brian
