Expand my Community achievements bar.

SOLVED

Authoring Multiple Content/Pages From Single UI

Avatar

Level 2

Our business wants to update various content /pages from a single page. This is basically switching the associated jcr path dynamically from the same page.

Attached is the proposed authoring UI. I know it’s premature and can be changed. But the key is to control all the page/content CRUD operations from one or two pages.

  • State dropdown has 50 values.
  • Category dropdown has 5 values.
  • When state or category value changes, other content in the page changed accordingly.
  • Not all state & category combinations have content populated, most of them are not.
  • CRUD can be performed on the related node or page in the UI.

I was thinking a jcr path like

  • /content/…/appName(page)/[state](node)/[category](node)/<component nodes>, or
  • /content/…/appName(page)/[state](page)/[category](page)/<component nodes>,  alternatively

I know this not how AEM works by default, content of each page are authored on a unique corresponding page. But I like to explore the possibilities. How this can be done? What are the alternatives or better solutions?

Thanks! Charlie

UI Drawing.jpg

1 Accepted Solution

Avatar

Correct answer by
Employee Advisor

This sounds for me that you want to create a custom user interface to avoid training the authoring users in AEM...

Your approach sounds reasonable in the first place, in fact I consider it a bad idea. Because you limit your authors only to perform certain activities, and they cannot use the abilities and features of the product at all. For example editable templates and experience fragments. The DAM. If you want to hide behind a custom user interface, you will rewrite a lot of the functionality of the product itself. Don't forget the problems with product upgrades, when the UI can change in subtle ways which is breaking your customization (but has no effect everybody else who has not gone that way).

With AEM you already get a decent user interface and there are many tutorials and videos out there describing how to use and extend it. If you want to customize that, you are totally on your own.

If you want to limit the ways how the users are working in the authoring system: there are ways to achieve that within the boundaries of the AEM UI. But please don't try to build something completely on your own. It doesn't work in the long-run.

Jörg

View solution in original post

4 Replies

Avatar

Level 10

You are correct - this is not how AEM works. The best practice for AEM is to open a page and make changes (as you stated here "each page are authored on a unique corresponding page").

In fact - I am not sure how this can be done. I would recommend that if you really need this functionality or explore if it's possible - you may want to talk with AEM consulting.

Digital Marketing Consulting Services | Adobe

Avatar

Employee Advisor

You are describing how you would switch between the pages fast. I guess, that's still possible if you need your authors guide through a lot of pages in some order to make their changes.

On the other hand: What's the business case? Same changes on multiple pages? Different changes on multiple pages? Is there any order necessary? It would be benefical to understand the workflow better.

Jörg

Avatar

Level 2

The intent was to make the authoring experiences simpler with minimum exposure to AEM internals.  Authors can perform CRUD and update content in the same page. It makes more sense for me to have two pages, master page to do CRUD on pages/nodes, detail page to update content, if this is possible.

thanks, Charlie

Avatar

Correct answer by
Employee Advisor

This sounds for me that you want to create a custom user interface to avoid training the authoring users in AEM...

Your approach sounds reasonable in the first place, in fact I consider it a bad idea. Because you limit your authors only to perform certain activities, and they cannot use the abilities and features of the product at all. For example editable templates and experience fragments. The DAM. If you want to hide behind a custom user interface, you will rewrite a lot of the functionality of the product itself. Don't forget the problems with product upgrades, when the UI can change in subtle ways which is breaking your customization (but has no effect everybody else who has not gone that way).

With AEM you already get a decent user interface and there are many tutorials and videos out there describing how to use and extend it. If you want to customize that, you are totally on your own.

If you want to limit the ways how the users are working in the authoring system: there are ways to achieve that within the boundaries of the AEM UI. But please don't try to build something completely on your own. It doesn't work in the long-run.

Jörg