That is the question. Whether ’tis nobler in the author instance to suffer the slings and arrows of a messy authoring dialogue… Alright, enough of that Hammy intro (pun intended).
We were recently consulting for another agency that was working on their first AEM implementation. They came to us with a few questions around some general Adobe Experience Manager best practices. One of them stood out to me because I have had to answer it multiple times. Question: When is it best/appropriate to use scaffolding to build a page? As many of you know, the typical method talked about in the AEM marketing is the ability to do “drag-and-drop” content authoring. This is a great feature to tout as it really does put the power in the author’s hands to create their own content without the necessity of calling up their IT department. But AEM does have a feature called Scaffolding, which shifts some or all of the authoring of a page away from the drag-and-drop method.
Adobe’s documentation on scaffolding explains it pretty well: “Sometimes you may need to create a large set of pages that share the same structure but have differing content. Through the standard AEM interface, you would need to create each page, drag the appropriate components onto the page and fill each of them in individually.”
“With scaffolding you can create a form (a scaffold) with fields that reflect the structure you want for your pages and then use this form to easily create pages based on this structure.” On that same page they also talk about how to create a scaffolded page in that same link, in case you are interested. There is also a pretty good write-up about how to do it over here at this blog: http://experience-aem.blogspot.com/2014/04/aem-cq-561-working-with-scaffolding.html. I won’t be dealing with the “How” of scaffolding, only the “Why”. Here are some reasons to do it and some reasons not to do it.
To Sleep, Perchance to Dream… – Reasons to use Scaffolding in AEM
1. Brand considerations – Brand is everything. Authoring a website absolutely affects the brand, and most likely there are numerous rules around how a corporate website should look. Inconsistency of content is just as damning as using the wrong red color in a Coke ad. If an author were to just come along and randomly put any component on any part of the page, then it might break those rules. Allow an author to pull any component, at will, from the sidekick (classic UI) or sidebar (touch UI), and suddenly you have a spastically arranged page that doesn’t follow along with how the company wants to present itself. But if everything for the page is in one specific place, then the author can’t forget a particular component. And if you don’t have a parsys on the page, then an author can’t add components out of place.
2. Constant/Consistent authoring – If you have authors that are putting out a lot of content every day, then they might get tired of dragging the same components out every single time. It would get monotonous. Plus there is the concern of authoring fatigue. And if an author happens to forget a component, then you could end up having an inconsistent page that doesn’t follow brand standards. Also, If you are expecting a specific component, such as a title, to be at a particular location in the JCR relative to the parent node of the page and an author forgets to add it, a news teaser list or some similar component would fail to find the title.
3. Same components used over and over – Structured content is probably the biggest reason to use scaffolding. If your content follows the same format on most of your pages, you can use the scaffolding tool to easily and quickly fill out those sections. An author can fill data into each section within the scaffolding form and know that it will appear consistently across all pages, without the risk of user error from dragging and dropping individual components.
All of these reasons came together in the case of CMO.com, a website developed by Axis41. They are a marketing news aggregator website and produce 30–40 new pages (articles) a day, and they use only two page types for these articles. With CMO being the thought leadership website on marketing for Adobe, it is critical that they follow the appropriate brand strategy to keep content consistent. Also, as a news website it is good to keep the content consistent as well, so everything is in the same place regardless of what type of article that someone is reading. Because we enforced the structure of the content in the JCR (since there is only one component, you know where all of the properties are stored in the JCR), it became easier to grab the data from the page to display in the various teasers, lists, and carousels on other pages of the site. The benefit of scaffolding is that all properties can be edited in one place, making authoring potentially faster.
Ay, there’s the rub… – Reasons not to use Scaffolding in AEM
1. Wanting to give authors complete control – I have known groups that have said, “Hey, we know how to do stuff, just give us the tools.” They were tired of having to wait for other groups to get their content pushed live or being dictated by a developer. Some people have the skills and ability to author correctly. Trust that. Don’t put up a barrier to their authoring just because you have an inherent mistrust in people’s abilities (I’m the biggest offender of this). At some point you have to let people go out on their own. If they make a mistake, it is not the end of the world and it can be corrected.
2. In-Context Authoring – As I mentioned at the top of the article, the drag-and-drop functionality is a big selling point to people considering AEM. Content authors feel like the control is being put back into their hands. The author can also see the content of their page being built as they drag each component out, which is empowering. This in-context authoring allows them to see the page without having to go back and forth for each component or tool when they update content. They see it immediately. Scaffolding, on the other hand, forces them to effectively switch back and forth. It’s not hard, but it can be annoying. In the past, I’ve suggested that authors have two browser tabs open: one for the scaffolding and the other for the actual page. I never liked telling people to do that.
3. It isn’t an option in Touch UI for AEM 5.6 or AEM 6.0 – If you are running AEM 5.6 or AEM 6.0 then you will have to use the Classic UI for your scaffolding. This isn’t a problem unless you are planning to use the Touch UI for the rest of your authoring. The authoring experience of switching back and forth between Classic and Touch is very bad and we strongly encourage avoiding it if possible. Choose one and stick to it.
A possible alternative
One idea that we have done for a few clients is to utilize what we call enhanced templating. This method allows you to use the the AEM system to create a page template with all the relevant or necessary components already on the page. Adding the components to the template saves the author from having to create the structure of each new page manually. Keep in mind, though, this does not prevent the author from deleting or rearranging components that the template initially created and can cause branding or JCR problems, as mentioned previously.
Cudgel thy brains no more about it – Conclusion
When Adobe announced their Touch UI in AEM 5.6, we found it odd that they did not include scaffolding as part of it. Indeed, David Nuescheler, one of the main creative forces behind CQ, indicated that it was a method he did not prefer in AEM development, when we interviewed him on our podcast. But with the release of AEM 6.1 they have included scaffolding back as an option. My assertion as to why they decided to do this is because there really is a place for the use of scaffolding in a good AEM implementation.
As with most things in life, there are good and bad reasons to use scaffolding, and there is not a definitive right or wrong time to use it. It’s all about weighing what controls your authors need against the risks of giving them those controls. Sometimes it really is best to put a fence around something in order to protect both the product and its users. Other times it is best to let them go hog wild.
We don’t need to be quite so fatalistic as Hamlet in our decision to choose whether to scaffold. No one is going to die, see specters, or have horrible nightmares. But you might be able to help your authors avoid some heartburn if you make the right choice. Use these guides to help know when it is the right time to use scaffolding. And remember, scaffolding is a part of AEM and we shouldn’t be afraid to use it or not use it. Reach out to us through email if you have some additional questions about scaffolding in AEM: firstname.lastname@example.org.