Jetpack: Block: Contact Form Improvements

[apeatling]

Current visual state:

Improvements to make for this block via @mtias

• [x] Update to support the block variations API so that we don't need to offer a generic "Form" block and provide a number of more specific uses in the inserter.
• [x] We should make the owner’s email address and the subject line for the messages received part of the toolbar.
• [x] Provide a default fallback email address as the site admin email address.
• [x] The input fields for the labels look to jump a bit on selection.
• [x] There are some “field settings” in the sidebar inspector for the child blocks but with no context or helpful text to guide you.
• [x] Adding text to the “default value” field doesn’t seem to do anything on the block render either.
• [x] We should avoid the “required” toggle in the block canvas. It can be placed in the toolbar instead, and upon toggling it can render the red “required” immediately.
• [x] The “submit” button cannot be aligned differently than the default (to the left) and is not a separate child block. See: https://github.com/Automattic/jetpack/pull/15370
• [ ] Build some nice block patterns for it and ensure we have enough customization options to handle visual variety.

@iamtakashi @pablohoneyhoney I think we have a few examples of patterns for the contact form, if we can drop those here that would be 👍👍, thanks.

[mtias]

Update to support the block variations API so that we don't need to offer a generic "Form" block and provide a number of more specific uses in the inserter.

For this I was thinking we could explore keeping the base block as "Form" but we hide it form the inserter (inserter: false) and then register the different forms we want to expose as variations: Contact Form, Feedback, etc.

Alternatively, we keep Form exposed but we use the variations system to ensure Contact Form etc employ the _scope_ mechanism scope: [ 'block', 'inserter' ] to ensure it can be selected when inserter the generic "Form".

[apeatling]

I think the first one is best, but I don't think we can hide the generic form in the inserter until variations show up in the / inserter https://github.com/WordPress/gutenberg/issues/20583. Until then we could expose them in the regular inserter, and also via the block when selecting the generic Form base block?

[apeatling]

I've added support for variations to #15362 that includes a variation selection screen when the base Form block is selected, but also includes the variations in the picker.

[apeatling]

We should avoid the “required” toggle in the block canvas. It can be placed in the toolbar instead, and upon toggling it can render the red “required” immediately.

@mtias Do you see this as a toggle embedded within the toolbar, or a button that shows a dropdown with the toggle option?

[apeatling]

As a bonus, I've also added support for padding and space between fields from single controls in the parent block.

[apeatling]

We should avoid the “required” toggle in the block canvas. It can be placed in the toolbar instead, and upon toggling it can render the red “required” immediately.

I've removed this from the canvas and added it to the sidebar. I'm happy to add it to the toolbar, but having a dropdown with a single toggle seems odd to me. If the toggle can be embedded within the actual toolbar that seems better, but I don't think there is any precedent for this?

[mtias]

Yes, I meant a toggle embedded in the toolbar directly. If there was a clear enough icon with a tooltip, it could be just a regular toolbar button action, as most icon-buttons already work as toggles (like bold) in the toolbar.

[mtias]

Wonder how you think we could make something like this possible (or if we should) as well:

(With labels instead of placeholder text.)

[apeatling]

Yes, I meant a toggle embedded in the toolbar directly. If there was a clear enough icon with a tooltip, it could be just a regular toolbar button action, as most icon-buttons already work as toggles (like bold) in the toolbar.

Added this to the toolbar. It's hard to find the right icon, but I'd like all the icons I've added in the PR to get a review and update once everything is working.

[apeatling]

Wonder how you think we could make something like this possible (or if we should) as well:

@mtias I think this could be useful for design patterns and be a toggle option in the parent block that applies to all fields? "Include labels in fields?" or something like this?

Edit -- just noticed your comment right at the bottom. You mean the multi-columns and not the labels?

[iamtakashi]

I dislike the default width of the input fields set by the block for the front of the site. I find it odd :)

For a stack layout like the screenshot above, I'd prefer 100% width.

cc @ianstewart @alaczek (Since this came up in our chat before.)

[apeatling]

@iamtakashi Already done 😀

[pablohoneyhoney]

It'd be good to update the block icon, and find a different icon for _required_ if this is the preferred interaction (curious if you think this is more of a sidebar function).

[apeatling]

It'd be good to update the block icon, and find a different icon for required if this is the preferred interaction (curious if you think this is more of a sidebar function).

I agree, the icons in this block in general are not good so I'd like to review those as a whole. I think the preferred interaction is via the sidebar and that will stay as it is, the toolbar icon was added because I believe the pattern is now for primary interactions on a block to be in the block toolbar. @pablohoneyhoney Would you be willing to come up with a better icon here?

[mtias]

just noticed your comment right at the bottom. You mean the multi-columns and not the labels?

Yes, the multi column. Like @iamtakashi mentions, I think by default it should be full-width, but it should be possible to say you want 50% on a field and they would stack in columns.

(This should not be a blocker for a first pass, just something to consider later.)

[alaczek]

The multi-column option would open up some cool design possibilities! I saw something similar done, can't remember where exactly, for the Name field specifically. This was done with a radio toggle setting to split up the Name field into first and last name, and those two fields would be then displayed side-by-side.

[apeatling]

@alaczek This is how CoBlocks handles it. It's a simple way to handle splitting the name field into two columns inside of a single block using flexbox.

I think we'd want to go much further than this. My first thought was to use flexbox in the same way and auto arrange field blocks into columns with a simple column count slider. It would be the most straightforward for the user, just slide the toggle to adjust column count and you're done. I think this would break down quickly though -- you would not be able to move fields, block UI would be affected, and inserting new fields in a specific location almost impossible. I think it's a non starter.

I do like the idea of having a column count slider to auto arrange fields, from a UX perspective it's incredibly simple. If this could be combined with intelligently arranging blocks inside and outside of columns blocks then you could retain a simple interaction backed by the power of columns. That would allow users the ability to add, remove, and rearrange field blocks after selecting their column count.

/cc @mtias

[apeatling]

Tried the above using the columns block and confirmed it works. This is a basic example with two standard input fields being placed in a two column block leaving the textarea field spanning both columns:

I'll expand on this and see how I can handle more columns and more fields.

[mtias]

I am not sure a column attribute would be the best — would you expect "message" to be a allocated to a column? What happens with other fields? My thinking was more like this: flex would be set by default, with the fields set to 100%; changing two subsequent ones to 50% (name and email) would yield the result above.

It could use the following component from the Image block:

[apeatling]

I am not sure a column attribute would be the best — would you expect "message" to be a allocated to a column? What happens with other fields?

My thought would be to provide an option for textarea fields to span columns (or not). Let me try working with flex using the component you mentioned. I think this is more fiddly but does give you greater control.

[mtias]

I think it might also be something people access mainly through patterns rather than setting them up themselves.

[apeatling]

Yes agreed. I was thinking end users and simplicity, but this is about pattern building so that finer grained control makes sense here.

[mtias]

If you think you can get to something that feels pretty intuitive, flexible, and easy to control, it might still be worth to explore!

[apeatling]

The flexbox approach works well, I think this is actually simple enough. Here's a preview of this working, I'll push a PR up soon for it.

[apeatling]

Opened a draft PR with these changes here: https://github.com/Automattic/jetpack/pull/15674. Will keep this separate to not block the other contact form updates from merging first.