This section goes over my knowledge of Documentum Web Publisher, Oracle FatWire and Adobe AEM/CQ. Although the Documentum product is no longer sold, it was a good starting for my education into CMS systems.
There are a few types of templates I would like to review Page Templates and Design
In my experience, there are differences when working in ADOBE and they list page templates that can only work with certain components/modules. the adobe system is very different from FatWire as it has components that a user can drop into a page anywhere and use multiple components – sections of the page- to make the full page design. For myself managing a site this was hard for the groups to maintain, as we would get requests in to use modules in an order on the page that the Design team never approved. It’s key to make sure when you have a site that has easy to use modules like AEM system does, that there is clear definition on how to use the modules in the pages, and clear documentation on the way those modules should be used.
It was a very easy system to use from a publishing perspective, but very hard at the same time because we had so many options to choose from for the component library. Project managers would come to us with copy docs filled out but no direction on which component views to set, so that in turn, took a longer time for the web team to stage the page, as they were unsure which view or module to use for that content section. This problem would have been avoided if we had had a dedicated editorial or documentation group, that could have kept up with the module deployment and made documentation before new module designs and views were released.
You should always make sure to have someone assigned to hand off documentation for new designs you are creating, because doing follow up on creating this documentation and not having it when starting to layout new content for projects will cause hassles and time delays.
In AEM there are Page Templates, those are just blank templates that are created to use certain module sets, then you have a library of modules that your IT group would build. These modules can have different “views” to choose from, meaning if a module is set that has a Title and text field and image, on a different view it can layout using different styles.
One example to make this easy to understand is below, say a user sets up this text and image in a component in AEM, then chooses the “ABC View”. That would mean it shows like this in the page:
If they choose the “XYZ View”. Then it could change layout to be like this:
It’s all set up depending on how your IT group builds the modules. In some module views you may not have certain fields display as well, so the IT team could build many views in one module, and have say one view only show text, no title field…
In this way you see how needed it is for teams to have the correct documentation and be closely aligned with the Design group, incase the issue is made to create a new recipe for the page to follow.
The FatWire system was built much differently, in that system we had more of a content type approach and then true page templates, which meant we had templates that had fields, in which all the fields were static and used just in the template, no modules. You would have for example an Event template, and it would contain all the fields required for the event page content. there was no easy way to deviate from the design using these fields. this aspect was good from a website consistency point of view. You would want things such as press releases, events and articles to follow one layout and be consistent. Throughout the site. If you give the teams a lot of flexibility here you could end up with a site in which as you are clicking through, you have no idea what design each page follows. Is this a product page, a solution page, a campaign page – the web team can’t tell because everything was created with one off module recipes.
I am not saying having a totally rigid system works, as it will not, but if you have everything opened up, and no review to be consistent, it can turn in to a mess of sorts and be very hard to maintain for the web teams and content owners that have to create content for it.