AEM

Adobe Experience Manager (AEM) is an enterprise web content management system that, like many other enterprise applications, is a complex piece of software to set up and configure. We can't eliminate this complexity completely, but we can reduce it for many use-cases. AEM OpenCloud is an open source project being led by Shine Solutions that automates the setup of a complete ready-to-use AEM environment in the cloud within 15 minutes. However, testing and verifying that an AEM installation is working correctly is laborious and time-consuming. Done manually, testing can certainly take longer than the 15 minutes required to actually build the environment in the first place. Fortunately, automated testing was identified early on in the project as an important part of OpenCloud's modular design, as is made clear by this diagram created by Cliff Subagio, one of the project founders: AEM OpenCloud suite However, it's one thing to say that testing is important, it's another thing to actually do it. In this post I'll talk about why and how we used InSpec to implement automated testing in OpenCloud.
Adobe Experience Manager is designed to cater for content authoring of multiple sites by multiple content authors. Naturally, this process needs to be governed by strict Access Control Lists (ACLs) to manage who is allowed to do what at any given time. In this post, I’ll cover various approaches that can be used to manage authorizables and ACLs in AEM that should help you make a more informed decision when picking a permissions management strategy for your next project.

Adobe Experience Manager’s latest release became generally available on the 26th of April 2017 and being Adobe Partners we got the opportunity to try it out hot off the press. It’s a minor release but introduces some new key features that go a long way to make Adobe Experience Manager a more enjoyable product to use. Not only from an authoring standpoint but also for developers. Here’s some of the great things about 6.3 as well as the “not so great”.

As part of the Adobe Partner program, various sessions and events are organized to keep partners updated on the latest features of the Adobe Marketing Cloud platform. Best practices are also talked about in order to deliver high quality solutions to clients that invest in Adobe’s digital experience management solutions.

On February 15th, Shine Solutions was invited to an Adobe Innovation Session with a focus on managing the Customer Journey in a cross-channel marketing environment. This is a summary of what we heard that day.

Your company has decided to migrate their web presence to Adobe Experience Manager and you’re getting to the tail end of the project. This is usually the point when you realise your URLs need to be shortened, because, let’s be frank: who wants to see “/content” in their URL? And, whilst we're at it, you should probably get rid of that “html” extension as well. So the problem we’re trying to solve is how to turn a URL like http://acme.com/content/acme/en/about.html into http://acme.com/about. There are various ways of going about it and naturally there are trade offs with each approach. In this post I'm going to summarise each approach and it's tradeoffs.

Adobe-Marketing-Cloud

There is a push in the industry to code against an external style guide to maintain consistent styling, have a reusable set of components to build applications with and provide a shared vocabulary for teams to communicate. The goal is that any web application built in an organisation can make use of this style guide to re-use existing CSS rules and/or Javascript functions. For example, one of the more well-known and recently-published style guides is the U.S. Web Design Standards, which will enable U.S. government agencies to create a unified user experience throughout their web applications.

When dealing with modern web applications, integrating a style guide is a relatively straightforward process. It often involves leveraging the existing Javascript build tooling to pull assets down via npm, and then having those assets processed as part of the build pipeline along with your application’s styles/scripts. Alternately, you can simply copy-paste a version of your style guide’s artifacts into your application - the quick and dirty way.

However, things are not always this easy. In my experience working with AEM/CQ, integrating a style guide into a project has consistently been a challenge.

To be fair, style guides are not to be blamed for this. AEM’s strict file structure, meta-data (.content.xml files and the like) and reliance on Java technologies can make it challenging to integrate with Javascript-based tooling. Each project generally ends up with a set of custom scripts to achieve this integration, resulting in a solution that is simply not maintainable. If you’ll indulge me for a moment, I’d like to take this opportunity to run through a few solutions I’ve come across to integrate style guides with AEM.

Adobe-Marketing-Cloud

I started using Adobe Experience Manager (CQ 5.6.1) with a focus on component development and building OSGi services and I strongly believe that learning how to leverage AEM's capabilities (as well as it's underlying technologies like Apache Sling) are key to a successful CMS implementation. With that in mind, I’ve been keeping a list of useful tips and tricks that I’d like to share with you. These are mostly about increasing productivity when working with AEM or just general things I wish I knew about earlier. This post is targeted more at developers starting out with AEM but I’m also hoping more seasoned users can benefit from it too.