Under Community Review

This idea makes a lot of sense.  As a matter of fact, we already had this idea ourselves too. We refer to this feature as "User-defined Regions"  (whereas the currently released feature is called "Predefined Regions"). 

During Sites 9 development, we have conducted several interviews with customers and partners to get an impression of the importance and usability of Regions-related features called "Predefined Regions", "User-defined Regions" and "Stand-alone Regions".  From these interviews, it was already clear that "User-defined Regions" add a significant value on top of "Predefined Regions".

However, we also concluded that "User-defined Regions" shine in particular in XPM use cases. This was one of the reasons why we decided to not include it in Sites 9.0 yet (we're working on an overhaul of XPM and didn't want to invest a lot in adding features to the old XPM architecture).

Note: an excellent DXA Module has been created which implements "User-defined Regions" functionality in XPM, using a mix of DXA Regions and "Container Components": the DXA Container Framework. 

Regardless, having this submitted as an Idea is a good thing. This allows us to gauge the popularity through votes.

So: your votes please and please also comment on use cases (do you think that "User-defined Regions" has a lot of value if it is a CME-only feature?).

Allow editors to insert regions into a page

Currently, a page region, with all its nested regions and subregions and sub-subregions, is defined by an implementer. If editors were allowed to pick one of a number of subregions, the system would be much more powerful and easier to maintain. This picture makes that clear:

Illustration showing a confused editor looking at a complex page layout with nested regions labeled A and B, indicating the need for a simpler system.

This solution would limit the number of page templates that editor need to choose from, while still keeping the benefits of 'guiding the editor' using constrained regions.

Quirijn Slings
Parents

  • I think this idea is very useful for the CME also. The point is that many customers don't think of a page as a static 'mold' in which to pour their content. Rather, they think in terms of groups of content items that behave in a certain way, e.g. a list of links, a set of banners presented in columns, a sidebar, a hero item, etc. User-defined regions would allow implementers to define these groups of items, while still allowing the editor to decide which groups to use.

    One thing that is important: we need to be able to constrain which child regions to use, otherwise we are back in the wild west of the days before the regions were introduced. Also note that the editor should be able to determine the order in which child regions occur (e.g. first a list of banners, then a number of news articles, then another list of banners, then a set of calls to action in 3 columns, etc).

Comment

  • I think this idea is very useful for the CME also. The point is that many customers don't think of a page as a static 'mold' in which to pour their content. Rather, they think in terms of groups of content items that behave in a certain way, e.g. a list of links, a set of banners presented in columns, a sidebar, a hero item, etc. User-defined regions would allow implementers to define these groups of items, while still allowing the editor to decide which groups to use.

    One thing that is important: we need to be able to constrain which child regions to use, otherwise we are back in the wild west of the days before the regions were introduced. Also note that the editor should be able to determine the order in which child regions occur (e.g. first a list of banners, then a number of news articles, then another list of banners, then a set of calls to action in 3 columns, etc).

Children
No Data