3.0: UX of Widget Editor Drawer

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',
    }
  }
}

1. 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!

[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.

[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.