Adobe Experience Manager Reviews

A decent amount of technical knowledge is needed to set up templates for sites.

The capabilities of the different kind of users don't align very well with the different roles/job functions at some organizations.

The new Touch UI interface could use a lot of improvement. Many of it is smaller detail items/features, but when using the system extensively it can become cumbersome.

There is a bit of a learning curve because of the depth of what Adobe Experience Manager can do. Even basic editing and page creation, while relatively simple at the most basic level, is not as intuitive and easy to use as other systems like WordPress.

Development can be complicated. Although I've not personally done much in terms of dev work, my experience and what I've heard from my colleagues indicates that there are some complexities that make it not as easy to develop in as other systems.

The source edit option within the rich text editor does not include syntax coloring for the code, or even a different serif/monospaced font. It is the same sans serif font as the regular rich text, which makes it hard to read.

There is no easy way to change a template if it has been built a certain way. Sometimes it would be nice to have an option to add an extra item on the spot. Instead, you have to ask your IT team to create for you.

You can set up a staging site and a site to publish... but sometimes the 2 environments doesn't connect correctly, meaning some changes in the staging sites doesn't show of on the live site.

The quick publish button is dangerous and not that helpful: pages can be published with the "quick publish" option even if they are blocked... however, the purpose of a blocked page is to prevent it from publishing until you unblock it. Also, the "quick publish" option will publish your age and every other page connected to it! so be careful!!

Searching for and organizing images can be a clunky experience.

Standard components frequently do not meet our needs. New components must constantly be in production to run what I usually consider pretty standard functionality.

Steep learning curve for people not used to web design or development. Not intuitive at all levels.

It has a learning curve, not everything is straightforward even if you are familiar with other CMS's

Depending how big your site is, it can become a bit slow

The move to the new interface for authoring is drastically different from the previous interface. Moving has been difficult.

Since it is so customizable, a talented web dev team is needed to make all the parts.

It is not easy to tell if the page is live or draft in the new interface.

Integration with non-Adobe marketing automation tools is very difficult.

Adding meta data to batch files would make it much more efficient

You still need to convert any Word or Excel docs to PDFs if this was on auto when you have multiple files, it would also save time

In all honesty, Adobe Experience Manager is not without its glitches, like anything. Some errors have perplexed our internal IT staff.

Likely to require some finessing or customization to work with or port over assets in an existing system.

Check that it supports any ancillary, third-party or custom solutions you might already use.

Check on hardware requirements, to ensure your infrastructure is sufficient to take full advantage of AEM (web server capacity, speeds, etc.).

Components were introduced to reduce the development & authoring time by reusing them. With some clients, it worked very well because they had page structure and content like that. But if you have UI requirements that can not support component re-usability then your life will be difficult. You will end up creating more and more components in the hope that they will be utilized one day some where on some page... Although you can achieve re-usability by creating smaller customizable component but then again it will increase your development time. In a Nutshell, you will not save development time.

Osgi was a great concept. AEM Developer used to write the most of business logic in them but due to adaptation of micro-services, now everybody wants to implement business logic in there instead of AEM internal OSGi. If your architecture had micro services then power of Osgi is useless for you, you will just use 10-20% of it which will bring no big value.

License of AEM is super costly, not every organization can afford it. Once you have implemented AEM, it will be hard to get rid of it. Getting rid will mean another investment.

Like other products, AEM also releases new versions. Upgrades to new versions never happens smoothly. Means organization needs to spend more money to upgrade the servers.

You need a big infrastructure to deploy AEM server setup. Each setup needs at least 3 machines, one for author, one for publisher and one for dispatcher. This means spending more money on maintenance.

TouchUI is confusing sometimes for everyone i.e business, authors, developers.

Upgrading and applying patches can be hit or miss - I recommend backups because of the potential to damage the existing infrastructure

Space management is an issue - every change or request takes up space that can be reclaimed, but only through a complicated procedure done through command prompts. There was no documentation for this on their site and we had to use a third party to create the procedure. It has to be run manually.

There isn't a good backup system, particularly one that can be scheduled to run reliably.

Styling the front-end of the author interface can sometimes be challenging. Built in styles and HTML can be overwhelming until you get used to it. Having a less intrusive author output or defining a standard output per site could speed development.

Documentation is often outdated, keeping docs up to date and readily available is needed.

The local build process is slow and takes a lot of space. Reducing the overhead with local testing would be great!

Widget customization is extremely challenging

Ability to create Custom Dashboard is missing

Portal support is inadequate

In Touch UI interface the authoring dialogue can not be expanded which prompts the user to scroll when authoring and makes it a cumbersome user experience.

Moving the page hierarchy within AEM structure is not intuitive.

Re-sizing of the assets often does not work as expected and the user needs to refresh the page before they see the final outcome.

Allow all vested parties to a project to be notified once any changes occur to a page

Allow for paid media campaign management

I've found that CQ isn't quite as stable as I'd expect an enterprise piece of software to be. There are a few out of the box components that are finnicky/fragile.

Supposedly this has been improved in the latest release (6.0), but up until 5.6.1 there were no true coding standards, so business logic could be found scattered all over in scriptlets and servlets. The scriplets would be part JSTL/Expression Language, part scriplet code. This is kind of a nitpick, but as a developer it definitely has an impact.

A lot of the OOB (Out Of the Box) components are still a little buggy and not fully ready to go without some minor tweaks.

Since the software was acquired not too long ago by Adobe, a lot of Adobe integrated solutions are not fully baked yet. That is getting better with time.

None

Adobe CQ could do a better job at providing more intuitive user and developer documentation

Steep learning curve for both Authors and Developers when it comes to customized components and workflows.

Development community is small and somewhat closed. It keeps growing with the years as CQ becomes more popular, which is a good thing.

Expensive, both to purchase, train and certify. This makes it harder to learn unless companies are willing to spend thousands on official training.

Cost. AEM is expensive.

Touch UI not as intuitive as classic UI.

Migration. We had multiple environments that we were constantly moving content back and forth on. Moving the content over through CQ was a bit of a challenge.

Integration. In some instances, Adobe CQ's built in modules would fight with custom modules. Usually the problems went away on their own.

Forms. Sometimes when adding a form to the page, the TO and CC sections would show up as empty when they had email addresses. Then when you went to change them, you couldn't close the settings window without clicking cancel.

User interface can be buggy at times.

The touch interface can be confusing and/or unintuitive.

Cost. AEM by itself is good, but needs some additional services (Analytics, Target) to really make it more effective.

It is hard to find people with the skill to develop solutions on AEM.

The TouchUI pales in comparison to the features found in the Classic UI. Developers have a hard time implementing solutions in the new Touch UI because the framework is lacking, where as in the Classic UI the framework is more robust. For example there are some out of the box classic UI widgets that allow developers to create key/value pair lists in dialogs. In touch ui that does not exists and developers are forced to implement custom solutions.

It is based on open source, so a lot of the code base is out there (except the proprietary AEM stuff, i.e. WCM). This means that between versions of AEM, there are major changes (they are good at backward compatibility however). This could be a good thing, but may be a bad thing if your company is more sensitive to big changes that come hard and fast. There are people out there developing on AEM 6.2, as if it were still AEM 5.6. They don't even know how to take advantage of the new features.

Can be very difficult to develop for

Adobe takes a very long time to fix bugs, sometimes not fixing them at all

Lack of any consistent documentation

Commerce platform integrations are really hard

Developer documentation is not up to the mark

Certain issues are very hard to detect and there is little log information

Rapidly changing features are compromising the stability of the system