AEM Q & A: ContextHub, JCR Segment Issues, Touch UI & More

We asked Adobe Experience Manager users to submit their toughest questions to be answered by our AEM experts and the response was overwhelming! Digital Marketers, UX Directors, Engineers, Developers, Architects – were all eager for our team to solve their most pressing AEM challenges. So that’s exactly what we did.

Meet the 3|SHARE experts –

René Ugarte, Managing Partner and Solution Architect

Miguel Ruival, Managing Partner and Solution Architect

David Holt, Director of Client Services, Western US

We’ve highlighted a few of the questions and answers here,. You can also listen to the full recording of the Q&A session in the video below.

Q: How can we personalize our content effectively without Adobe Target (but we do have Adobe Analytics)?

A: If you're on version 6.0 of Adobe Experience Manager (AEM), you can use AEM's Client Context feature, and for 6.1 and beyond, you can use ContextHub if using Touch UI. The AEM documentation has sections on both of these feature frameworks in detail to help personalize your content, albeit not quite as robustly as with Adobe Target, but it could certainly solve a fair amount of use cases. AEM content can then be targeted to specific audiences using the Targeting Mode powered by the Client Context / ContextHub. If you are going for a deeper personalization experience than swapping banners, images and other static content, you want to make sure you develop your components with that in mind to be able to provide those different experiences.

Q: We've taken AEM components and created small templates that we call modules... how can we get even more flexible and agile by being completely component based without overly complicating the builds?

A: Finding that balance is exactly how we like to approach solving requirements for component development. Basically, the wider the boundary for one or more paragraph systems in any given page template, the broader the drag and drop component options become for a larger surface area to achieve greater flexibility. Then you focus your dev cycles on ensuring that the "parsys" is skinned appropriately with as little to no functional dependency on the component objects within and vice versa. This is the component-based ideal that many customers seek and which makes AEM pretty powerful. However, it also opens the avenue for complex solutions that may be tricky to manage and maintain if the functional requirements for the site take you down that path. In short, our suggestion is to simplify your parsys and core component library to be as independent from each other as possible to help achieve that balance. As a side note, try to get as much user/author feedback as possible while you are designing and testing your components. At the end, there is also the question of what is better for your users, and that may collide with your newly designed and perfectly flexible solution.

Here's this sound bite from the live session:

Q: How are internal IT teams that support AEM typically staffed? How much experience do you recommend those developers have to support day-to-day operations and updates to the site (and microsites)?

A: We typically see AEM supported by DevOps teams within IT, but whether you have such a team or not, a typical team would consist of the following roles with a minimum of three years experience accross the board:

• Project manager versed in agile and/or waterfall development practices
• One or more business analysts to collaborate with the business and marketing teams to bring functional requirements and deadlines back to the team
• Solution architect for larger implementation phases who has a few years' experience across various IT systems involving web delivery 
• One or more system engineers for any on-premise and/or cloud hosted instances of AEM if you're not on Adobe Managed Services or 3SHARE's Remote Operations Management service  
• One or more Java software developers working on project phases, bug fixes, and enhancements 
• One or more front-end developers for design changes (HTML/CSS/JS)

Q: How would AEM decouple the application engine and content? That would help scale author instances horizontally

A: MongoDB is the way to go here. Using MongoDB, you can decouple AEM's Node Store making it independent of the Author environments, allowing for horizontal scaling. The improvements in recent versions are significant and we recommend clients go this route as the first solution to scaling the author instances horizontally in an active/active configuration to support higher numbers of simultaneous authors. Just make sure you also plan for the Data Store to live outside of MongoDB and in a NAS available to all AEM instances to make sure you don't overload your MongoDB setup. We've had great collaboration with Adobe Support and Adobe's partner enablement team to ensure that MongoDB and AEM are tuned appropriately for the expected load with room for growth and, with continual improvements happening at a fast pace, we'll definitely continue to engage them on future projects.

Q: How do we take care of our site without onsite developers?

A: With lots of communication to your remote team, whether with vendors like us and/or your internal team: daily standups, solution meetings, weekly statuses with stakeholders, etc. Tools like JIRA, Google Hangouts, conference calls, and Slack should be used extensively to get everyone on the same page. If the site has been developed and neither onsite or offsite developers are available anymore, the implementation team should have provided you with the right documentation to be able to use and maintain your AEM instance and keep it running smoothly. Ask for User Guides, Runbooks and Technical Design documents to understand your new system and be able to take care of it going forward.

Listen to this snippet from the live session:

Q: Storage limits of pages on AEM + JCR segment issues

A: There are a number of useful formulas in the Hardware Sizing Guidelines in the AEM documentation that we often use for new implementations, but beyond that we analyze disk storage sizing across three areas: pages, assets, and dispatcher cache. After that, we account for and plan the frequency and timing of AEM maintenance tools that are built to manage and reclaim disk on a regular basis. These are meant to reduce or eliminate JCR segment issues that you mention, and so sticking to the maintenance plan is critical. Many marketing teams don't like the application downtime needed on the author tier, so it's a careful balance between maintaining the health of the system to avoid larger scale problems down the road versus time to market for content campaigns. Online Revision Cleanup is also a fully supported option in AEM 6.3, and the official recommendation from Adobe.

Q: Where is a truly good source of learning/documentation for Dialog Touch UI. We need a set of how-tos!

A: There isn't a single source to get all this information, and examples are in general even more difficult to get, but the Granite UI Documentation site should be the primary place to get your questions answered when it comes to fields, dialog components and their properties. That coupled with the components shipped out of the box with AEM for examples should provide you with the guidance you are looking for. As part of our implementation projects, we deliver User Guides to help authors understand how to use the authoring interface, including Touch UI, but that documentation is usually tailored to client's specific needs.

We hope you have found this information helpful. We also conduct private Q&A sessions, so if your team would like to pick our team's brains - get in touch!