RFC: InnerBlocks for Better UX in Default Blocks #694
Replies: 6 comments 6 replies
-
This is great @ChrisMKindred, you mentioned testing the according block, can you link the before and after so everyone can get a sense of how it changes the workflow both in creating new blocks and also in what one would have to do to modify one of their existing blocks? Thanks |
Beta Was this translation helpful? Give feedback.
-
Oh also, I'm not understanding what the actionable work to be done here is. Is it converting and updating existing SquarOne blocks to use this strategy where appropriate or is it just the media text block to start off with? Does this include documentation updates/additions? Would other already started projects benefit from switching any of their blocks and need assistance with that? Thanks |
Beta Was this translation helpful? Give feedback.
-
This is great, Chris, thanks for putting it together! I totally agree that shifting to inner blocks sooner rather than later is a great next step and will provide a much better experience for content managers/creators. I actually went ahead and implemented the Gravity Forms block as an inner block template just a couple weeks back in SQ1 for the lead form block : ) As part of the upcoming roadmap for SQ1, which Nick, Kyle, and I have started working on and will be able to share in the coming weeks, moving to inner blocks is high on the list. There are some FE things as you have noted that I can think of that will need to be addressed in shifting to this approach, the BE piece is mostly pretty straightforward. I'm planning to tackle this towards the end of April as we spin up our first sprint and will have Kyle and MCR weighing in to guide what blocks we use as inner blocks as part of the greater UI/UX refinement pass on ACF + Core Blocks we will be doing in this first phase of most immediate work. I'll be sure to loop you in and have you review things as I go if that works for you and I'd love to see what you did in testing out the accordion block. |
Beta Was this translation helpful? Give feedback.
-
Here is a quick loom showing the Accordion that is set up to have a parent block with only accordion-item innerblocks. |
Beta Was this translation helpful? Give feedback.
-
These demos look great. I agree with Ryan that this seems like the way to go. We get the benefit of being able to use ACF in a pinch and can leverage existing blocks for our content. From a UX perspective, how do you see the breakdown of responsibility? At first I see it as InnerBlocks=Content, ACF=Settings. Then in a case where neither can solve the problem that's the decision path of custom native block or ACF custom block. Sound right? |
Beta Was this translation helpful? Give feedback.
-
In general, this RFC idea for approach is approved (and is already being used on some projects). Next step is document when we should use an ACF+InnerBlock approach and why, with some working examples added to the repo. |
Beta Was this translation helpful? Give feedback.
-
Timeline
Revisit Date: April 26th
Implementation Time: 8 hrs with additional FE support.
Need
ACF is a great solution for quickly creating Gutenberg blocks with PHP but there are some flaws that come with creating individual fields for each piece of content. Instead of creating fields that are already available via Gutenberg Core blocks (Paragraph, Headings, Lists, etc...), we should be using InnerBlocks to allow users to use the blocks that already exist. InnerBlocks will provide the consistent user experience that is expected when using Gutenberg to create content.
Approach
The Media + Text block is a great example of where we could start utilizing InnerBlocks. The Heading, Paragraph, CTA, and Lead In can all be created using core blocks. We can include the blocks by either defining the allowed blocks or setting a block template that represents the content in the designs. If we use a block template, we can also lock the templates using the templateLock attribute.
I have also tested a solution of implementing InnerBlocks on the current Accordion block allowing us to completely remove the Repeater field. This involves creating 2 blocks. The first block is the Accordion Block which is set to include InnerBlocks with the AllowedBlocks option set to the second block which is the Accordion Item. This Accordion Item block includes a Text Field for the DropDown title and then uses a template with placeholders for the paragraph and allowed blocks set to Heading, Paragraph, Lists, and Button blocks. An example of the implementation can be found in this Loom.
Benefits
The current approach has a fixed set of fields that can be entered for each block. By adding InnerBlocks to the content section, we will provide more flexibility to the user while still being able to limit the type of block that the content editor can use in an area.
Using InnerBlocks will help SquareOne move away from using WYSIWYG fields as the default field type when flexibility is needed for the user. The WYSIWYG field is one of the easiest ways for a user to deviate from the designs and by using InnerBlocks, we can help users keep the designs consistent even when adding multiple types of content in one area.
The current Media + Text block provides no user feedback after the block is selected. The Media + Text block utilizing InnerBlocks with a Template and placeholders allows for the user to know exactly what needs to be right after being entered.
Competition (or Alternatives)
InnerBlocks is not a perfect solution and there will always be reasons to provide ACF text fields for Headings and Paragraphs in the blocks we create. As we move into creating blocks with JS instead of ACF, InnerBlocks will be needed less often.
Beta Was this translation helpful? Give feedback.
All reactions