3.0: [UX] contextual only fields

[myovchev]

The problem to solve

In some cases (maybe a lot of cases in fact) area field type is not meant to be edited in admin modal mode but directly on the page - this is the majority of the cases in my current project and I'm not aware of any 'official' way of doing that via field options. The reasons for that need vary based on the context, but the outcome is the same. It may be an accessibility issue (not enough space for the produced widget output), missing style as it's sandboxed to the main content to no interfere with apos administration styles, combination of both and many more (actually real life cases now).

There are also cases when one wants a contextual only widget (as it was done in apos v2 as far as I know) but I consider this as a very minor UX issue.

Proposed solution

Introduce an area specific field type option to skip rendering the are in modal edit mode. A simple rule would be skipped fields don't have validation (this can not be set as required).

[boutell]

We have been leaning toward always allowing everything to be edited in the modal, for accessibility reasons.

But, we're aware that the experience of editing areas in the modal could be better.

I'm interested to hear about specific cases where it's not working well for you.

On Wed, Jun 2, 2021 at 9:50 AM Miro Yovchev @.***> wrote:

The problem to solve

In some cases (maybe a lot of cases in fact) area field type is not meant to be edited in admin modal mode but directly on the page - this is the majority of the cases in my current project and I'm not aware of any 'official' way of doing that via field options. The reasons for that need vary based on the context, but the outcome is the same. It may be an accessibility issue (not enough space for the produced widget output), missing style as it's sandboxed to the main content to no interfere with apos administration styles, combination of both and many more (actually real life cases now).

There are also cases when one wants a contextual only widget (as it was done in apos v2 as far as I know) but I consider this as a very minor UX issue. Proposed solution

Introduce an area specific field type option to skip rendering the are in modal edit mode. A simple rule would be skipped fields don't have validation (this can not be set as required).

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/apostrophecms/apostrophe/issues/3128, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAH27NKWOF54LXVO3EAMTTTQYZIZANCNFSM456ZCJJA .

--

THOMAS BOUTELL | CHIEF TECHNOLOGY OFFICER APOSTROPHECMS | apostrophecms.com | he/him/his

[myovchev]

The answer of that question is not simple. In order to explain it I need to explain you the architecture I came up in order to have a large project under control and to allow the required future scale.

The way we are building pages is basically vertical frames of a complex set of stateless UI components (organisms) inserted on the page, offering all kind of additional areas, varying from rich-text and media to another level nested widgets (areas). Those are built and composed very carefully so that they control vertical and horizontal space following the design rules we've applied at the start of the project and they need to be visually on the page in order to be

Additionally, they are reusable to the max possible level, so e.g. a piece is building its view (show.html) as combination of hardcoded in the template set of components to reassemble the desired custom for the page design using the piece data, but it also adds areas so that content editors can add any additional free (not belonging to the piece schema) content (which may or may not include widgets of other pieces). The in-page content building is much more intuitive and natural, proven by the feedback of our partners.

A visual example. Here is the dialog editing experience of a piece:

You might even see a glitch when the rich editor toolbar is partially not usable.

And here is the contextual editing experience:

We are aiming a visual page builder editor experience, removing the option to edit some areas in a modal by our choice will greatly increase the UX IMHO. And I'm not saying I want all of the areas to be contextual, I'm just searching the right balance.