3.0: UX of Widget Editor Drawer

[gmarchildon]

Playing around the Widget Editor drawer, I had 2 suggestions to have a better user experience.

1. Allow to possibility to add text bloc and separator For widget with multiple or unclear options, it could be useful to be able to add descriptive text to help the end-user. The integration could be in a standalone bloc of a description option. Separators could also be added to help organize widget with multiple options.

fields: {
  add: {
    complexOption: {
      type: 'boolean',
      label: 'Label',
      description: 'More information related to this field. It could be displayed as muted text under the label or with a "?" icon next to it.'
    },
    complexOptionText: {
      type: 'abstract:text',
      content: 'Adding more flexibility, we could have a bloc by itself.'
    },
    separator: {
      type: 'abstract:separator',
    }
  }
}

2. Add an option to area to not render in the Widget Editor drawer Since some area bloc can be pretty complex, it can become a little awkward to display it in the small drawer.

Really having fun working with V3 so far! I'm really looking forward to it!

Thank you!

[stuartromanek]

Hey @gmarchildon, thanks for the ticket.

An overview description of a widget would be a good enhancement for giving the editor a fuller picture of what they're working with. If you want to open up a more specific enhancement issue for that we would welcome it.

Individual fields do have the ability to include their own help text, just pass a help property with a string and it will be rendered under the field title but above the field UI. You can also pass htmlHelp and provide an HTML string for a more custom help description.

As for not rendering areas in schemas, yes, this is not always ideal and we have a flag for hiding them in A2. We need to port it to A3. The flag was contextual: true in A2, I'm not 100% sure it will be named the same in A3 but be on the look out for something along those lines.

[boutell]

Gabriel, were you looking for a way to shut off the modal dialog box for the widget completely, or a way to use a bigger dialog box?

On Mon, Apr 19, 2021 at 9:30 AM Stuart Romanek @.***> wrote:

Hey @gmarchildon https://github.com/gmarchildon, thanks for the ticket.

An overview description of a widget would be a good enhancement for giving the editor a fuller picture of what they're working with. If you want to open up a more specific enhancement issue for that we would welcome it.

Individual fields do have the ability to include their own help text, just pass a help property with a string and it will be rendered under the field title but above the field UI. You can also pass htmlHelp and provide an HTML string for a more custom help description.

As for not rendering areas in schemas, yes, this is not always ideal and we have a flag for hiding them in A2. We need to port it to A3. The flag was contextual: true in A2, I'm not 100% sure it will be named the same in A3 but be on the look out for something along those lines.

— 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/2920#issuecomment-822468289, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAH27LSR3OSC6MJHZ52NW3TJQWA7ANCNFSM43CIHV4A .

--

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

[gmarchildon]

I think what I was looking for is exactly what @stuartromanek mentioned with the "contextual" flag.

I feel like most of the time, it would just me easier to manage these areas directly in the page instead of the dialog/drawer box. I have the same feeling when I'm editing a page via the "Page Tree".

In my opinion, I don't think having a bigger space would fix the issue, in the end, it does not represent the final result and it's a less pleasant experience than editing directly in the page.

[boutell]

This is good input to have, thanks for sharing it Gabriel.

However we have also been thinking hard about how to achieve accessibility for our editing experience. Some way to edit the content in a less contextual, more schematic way might be part of that.

On Mon, Apr 19, 2021 at 12:54 PM Gabriel Marchildon < @.***> wrote:

I think what I was looking for is exactly what @stuartromanek https://github.com/stuartromanek mentioned with the "contextual" flag.

I feel like most of the time, it would just me easier to manage these areas directly in the page instead of the dialog/drawer box. I have the same feeling when I'm editing a page via the "Page Tree".

In my opinion, I don't think having a bigger space would fix the issue, in the end, it does not represent the final result and it's a less pleasant experience than editing directly in the page.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/apostrophecms/apostrophe/issues/2920#issuecomment-822622589, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAH27LFP7KLBZ4VU4EKURTTJRN5DANCNFSM43CIHV4A .

--

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

[gmarchildon]

That makes me think of an idea I had to manage page's widget in a different way (slightly off topic). In a specific view, instead of rendering the content of the widget, it could simply be blocs with the name (with maybe extra information) and we could move them around and drag new ones in. Double clicking the bloc would display a dialog with all the parameter of the widget.

But that might be more or less useful, I'm not sure, but I could see something like that went editing a page inside the "Page Tree".

[myovchev]

Closely related to my recent feature request about contextual fields option. I think the truth is in the middle, they are scenarios for better experience in both modal and contextual editing. And I think the combination of both works great. The contextual editing needs more work and is a great challenge for the UI engineers, but the efforts would be greatly rewarded if it brings the UX at a new level. And I'm ready to contribute with ideas, prototypes and code in the future.