Allow editors to toggle custom views for blocks.

[markadrake]

There are use cases for both view formats.

• We implement custom views for all of the blocks because editors unanimously request WYSIWYG.
• The default view shines in comparison once you begin to manage many blocks, and provides an improved UX when sorting.

What editors want—until they don't.

Good UX is just good UX.

What I think we all need:

• I'd like to propose a method by which editors can control the view.
• The blocks would respond in real-time, so they'd either appear by default as a list and if enabled, their custom view will render instead.
• We could use local storage to store the editor's preferred state. It's a small but impactful improvement when editing large amounts of content.

The following screenshot is one of many ways to solve this issue. This suggests a new contextual menu item to toggle custom views on/off. This was put together in brevity.

[markadrake]

In our discussions, our clients don't care for the term custom view. So of all the things I would propose to put on the contextual menu, please avoid this one. While it makes sense to a Umbraco developer, the end user seems to appreciate list and HTML.

[skttl]

Except if you use a custom view to extend the look of the "list view", then switching back to list could be confusing. I like the idea though, maybe a toggle on the datatype settings for allowing it?

[c9mb]

It's a commonly encountered functionality in WordPress content editors - which are many and varied.
I agree it should the the developers choice whether or not to allow the user to access it (as my experience with WordPress sites is that it can be a support nightmare when low-level content editors switch to such a mode) which suggests it should be a programmatically enabled option possibly based on the user's role membership ?

[markadrake]

I'd be happy to include this in the configuration of the block editor—language along the lines of: "allow editors to toggle the custom view"? So it would be opt-in, controlled, and enabled by the developer still, and won't affect any existing implementations. Would that satisfy the above conditions?

Generally though - do you like the idea of giving them the ability to switch, or see it's usefulness? I'd love to talk more about it before spending time on a PR. Thank you both for your input!

[c9mb]

I can only speak for myself, but yes, I think it a useful feature. My only concern is that the feature be enabled for the user by the developer, using whatever conditions they deem appropriate - I suggest programmatic control available - and not just made a standard editor option that the dev has no control over, but will bear the support calls for. In my case, I might make it available to more advanced content editors based on their group membership.