Inherited marginal boxes, user experience best practice

Using Neos & Flow Frontend & Integration
1

A Neos backend usability question, maybe a “best practice” of what you have been doing in your real live projects:

Consider the fairly common use-case that we have a marginal column with “content boxes”. Those are placed on the Homepage, but inherited in the tree to all sub-pages, so that the same box appear on all pages.

At some point in the tree you want different boxes, “breaking” the inheritance, and starting a new one.

I TYPO3 I would solve that in TypoScript using “slide:-1”. For the editor, in the Web>Page module they can only see the boxes in the grid on the pages they are placed.

Solving the CR part and the rendering in TS2 in Neos is not the problem.

But: What is the best practice to “visualize” this inheritance and editing experience in Neos for the editor?

In the FE the box is shown on every page. Letting her edit it on every page can be dangerous, because she might not be aware on which pages this box is also being used. And how to let the editor “break out” of the inheritance?

Kind regards,
Ernesto

2

I’d suggest to adapt the rendering for the content module (backend) and the frontend. So in the backend you could use TypoScript without inheritance and instead show something like a non-editable placeholder. So the editor would know where “real” content is placed.

With Neos 2.0 there will be some new helpers to check for backend or frontend but until then it’s mostly safe to check for ${node.context.workspace != 'live'} to switch the rendering in the backend.

3

For one project we used quite a lot of inherited fields on each page, as @hlubek suggests we change it so in the backend it renders the content on the page and for text properties (as opposed to content collections) we used a placeholder text like “This field is inherited”, which would be shown if the field was empty.