Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Template Part: Improve insertion flow. #23295

Merged
merged 6 commits into from
Jun 29, 2020

Conversation

epiqueras
Copy link
Contributor

Description

This PR improves the template part flow by:

  • Renaming "Template Part" to "Section" in the UI.
  • Implementing a new placeholder design.
  • Providing an input to rename existing template parts.
  • Improving the empty state to match the group block.

We should follow this up with an exploration of moving the renaming input to the toolbar.

@MichaelArestad @shaunandrews Do you think this flow will change frequently enough that it's worth disabling E2E tests for it, for now, to ease iteration?

How to test this?

Play around with inserting "Section" blocks in the FSE experiment.

Screenshots

gif

Checklist:

  • My code is tested.
  • My code follows the WordPress code style.
  • My code follows the accessibility standards.
  • My code has proper inline documentation.
  • I've included developer documentation if appropriate.
  • I've updated all React Native files affected by any refactorings/renamings in this PR.

@github-actions
Copy link

github-actions bot commented Jun 19, 2020

Size Change: -470 B (0%)

Total Size: 1.13 MB

Filename Size Change
build/a11y/index.js 1.14 kB +1 B
build/api-fetch/index.js 3.4 kB -1 B
build/autop/index.js 2.82 kB +1 B
build/block-directory/index.js 7.39 kB +2 B (0%)
build/block-editor/index.js 109 kB +58 B (0%)
build/block-editor/style-rtl.css 10.7 kB -3 B (0%)
build/block-editor/style.css 10.7 kB -3 B (0%)
build/block-library/editor-rtl.css 7.48 kB -113 B (1%)
build/block-library/editor.css 7.49 kB -114 B (1%)
build/block-library/index.js 129 kB -458 B (0%)
build/block-library/style-rtl.css 8.04 kB +5 B (0%)
build/block-library/style.css 8.05 kB +5 B (0%)
build/blocks/index.js 48.2 kB +3 B (0%)
build/components/index.js 198 kB -7 B (0%)
build/components/style-rtl.css 15.9 kB +6 B (0%)
build/components/style.css 15.9 kB +5 B (0%)
build/compose/index.js 9.65 kB -1 B
build/core-data/index.js 11.4 kB -2 B (0%)
build/data-controls/index.js 1.29 kB +1 B
build/data/index.js 8.44 kB +4 B (0%)
build/edit-navigation/index.js 9.87 kB +5 B (0%)
build/edit-post/index.js 303 kB -4 B (0%)
build/edit-site/index.js 16.6 kB +28 B (0%)
build/edit-widgets/index.js 9.32 kB -4 B (0%)
build/editor/index.js 44.8 kB +90 B (0%)
build/editor/style-rtl.css 3.85 kB +9 B (0%)
build/editor/style.css 3.86 kB +10 B (0%)
build/element/index.js 4.65 kB -3 B (0%)
build/format-library/index.js 7.73 kB +1 B
build/keyboard-shortcuts/index.js 2.51 kB -1 B
build/keycodes/index.js 1.94 kB +1 B
build/list-reusable-blocks/index.js 3.12 kB -1 B
build/notices/index.js 1.79 kB -2 B (0%)
build/nux/index.js 3.4 kB -1 B
build/nux/style-rtl.css 671 B +8 B (1%)
build/nux/style.css 668 B +8 B (1%)
build/plugins/index.js 2.56 kB -1 B
build/redux-routine/index.js 2.85 kB -2 B (0%)
build/rich-text/index.js 14 kB +1 B
build/server-side-render/index.js 2.67 kB -2 B (0%)
build/token-list/index.js 1.28 kB +1 B
ℹ️ View Unchanged
Filename Size Change
build/annotations/index.js 3.62 kB 0 B
build/blob/index.js 620 B 0 B
build/block-directory/style-rtl.css 941 B 0 B
build/block-directory/style.css 942 B 0 B
build/block-library/theme-rtl.css 730 B 0 B
build/block-library/theme.css 732 B 0 B
build/block-serialization-default-parser/index.js 1.88 kB 0 B
build/block-serialization-spec-parser/index.js 3.1 kB 0 B
build/date/index.js 5.47 kB 0 B
build/deprecated/index.js 772 B 0 B
build/dom-ready/index.js 569 B 0 B
build/dom/index.js 3.19 kB 0 B
build/edit-navigation/style-rtl.css 1.02 kB 0 B
build/edit-navigation/style.css 1.02 kB 0 B
build/edit-post/style-rtl.css 5.51 kB 0 B
build/edit-post/style.css 5.5 kB 0 B
build/edit-site/style-rtl.css 3.03 kB 0 B
build/edit-site/style.css 3.03 kB 0 B
build/edit-widgets/style-rtl.css 2.42 kB 0 B
build/edit-widgets/style.css 2.42 kB 0 B
build/editor/editor-styles-rtl.css 537 B 0 B
build/editor/editor-styles.css 539 B 0 B
build/escape-html/index.js 733 B 0 B
build/format-library/style-rtl.css 547 B 0 B
build/format-library/style.css 548 B 0 B
build/hooks/index.js 2.13 kB 0 B
build/html-entities/index.js 622 B 0 B
build/i18n/index.js 3.56 kB 0 B
build/is-shallow-equal/index.js 711 B 0 B
build/list-reusable-blocks/style-rtl.css 450 B 0 B
build/list-reusable-blocks/style.css 451 B 0 B
build/media-utils/index.js 5.29 kB 0 B
build/primitives/index.js 1.5 kB 0 B
build/priority-queue/index.js 788 B 0 B
build/shortcode/index.js 1.7 kB 0 B
build/url/index.js 4.06 kB 0 B
build/viewport/index.js 1.85 kB 0 B
build/warning/index.js 1.14 kB 0 B
build/wordcount/index.js 1.17 kB 0 B

compressed-size-action

Copy link
Contributor

@Addison-Stavlo Addison-Stavlo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is great so far! I really like it.

A couple questions about the dropdown:

  • Should the Dropdown / preview panel be wider? It seems very thin, but it does behave well and it doesn't necessarily look bad.
  • There are some circumstances where the dropdown has 2 scroll bars. Maybe the height of the preview container should be contained within the dropdown? That is, so the outer scrollbar wouldn't be triggered, the 'search' input would always be at the top of the dropdown, and the 'scroll' would only happen through the preview window itself?

double-scroll-bar

I really like the feel of how the new template part is inserted. Both having the renaming input and getting rid of the default paragraph seem like a big step up.

This name panel also helps with #22064, making it more apparent that you are editing a template part. (I suppose I need to get used to calling them 'Sections' 😆 )


Do you think this flow will change frequently enough that it's worth disabling E2E tests for it, for now, to ease iteration?

After this gets updated for whatever immediate concerns design has, id think it would be worthwhile to update the tests again. If you want to skip them for now, Id be happy to help update the tests as a follow up (if it makes sense and things seem semi-stable for the time being).

We should probably try to keep the safety net in place if there is going to be time between iterations. Id also assume a fair amount of the main concepts of this design will remain in place for a while, in which case 🤞 we are doing 'minor' updates to the tests going forward after this as opposed to re-writing them.

Copy link
Contributor

@Addison-Stavlo Addison-Stavlo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also noting nested template parts will trigger the input for their parents. Im not sure if this is good or bad? Probably good in that it improves the visibility that the selected template part is part of another?

Screen Shot 2020-06-19 at 12 48 49 PM

@MichaelArestad
Copy link
Contributor

This is already a great improvement. I think we'll need to stick to using the term "Template Part" for this PR. Let me know when you're ready for a review.

Do you think this flow will change frequently enough that it's worth disabling E2E tests for it, for now, to ease iteration?

@epiqueras I don't think functionality will change drastically, but perhaps some of the stuff around reusable block UI or the inserter could change. I trust your judgement here.

@epiqueras
Copy link
Contributor Author

Should the Dropdown / preview panel be wider? It seems very thin, but it does behave well and it doesn't necessarily look bad.

Yeah, I made it wider.

There are some circumstances where the dropdown has 2 scroll bars. Maybe the height of the preview container should be contained within the dropdown? That is, so the outer scrollbar wouldn't be triggered, the 'search' input would always be at the top of the dropdown, and the 'scroll' would only happen through the preview window itself?

Yes, fixed.

Also noting nested template parts will trigger the input for their parents. Im not sure if this is good or bad? Probably good in that it improves the visibility that the selected template part is part of another?

Yeah, that's good, it'll also look better when we move it to the toolbar.

I think we'll need to stick to using the term "Template Part"

Why?

Let me know when you're ready for a review.

It's ready 😄

@MichaelArestad
Copy link
Contributor

Why?

I'm worried it could hold up the PR, but maybe not? It is still an experimental feature so we can definitely experiment. Maybe add "template part" as search term so it shows up when searching the inserter

@epiqueras
Copy link
Contributor Author

I think the sooner we switch, the better, and it makes it look a lot better.

@Addison-Stavlo
Copy link
Contributor

Addison-Stavlo commented Jun 19, 2020

Maybe add "template part" as search term so it shows up when searching the inserter

🤣 - I was sitting there typing "/template" for the block search multiple times out of habit.

@MichaelArestad
Copy link
Contributor

I think the sooner we switch, the better, and it makes it look a lot better.

Let's do it.

Copy link
Contributor

@Addison-Stavlo Addison-Stavlo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Im noticing a tab accessibility regression with this implementation. I am only able to tab through the first couple sections in the preview list before having the dropdown closed by the 5th 'tab':
accessibility-regression

I'm not quite sure what the deal is, it doesn't correspond with the end of the theme group in the preview or anything else. I can't get past the 4th Section to select any of the further ones. It does seem to be something with this dropdown as the current preview list tabs through to the end. 🤔

@MichaelArestad
Copy link
Contributor

Also noting nested template parts will trigger the input for their parents. Im not sure if this is good or bad? Probably good in that it improves the visibility that the selected template part is part of another?

@Addison-Stavlo This is a good point I hadn't thought of. It does have me thinking the idea to shift to a text input in the block toolbar would be a better approach, but we need more design feedback there first.

@epiqueras
Copy link
Contributor Author

Updated tests 🚀

@epiqueras
Copy link
Contributor Author

Im noticing a tab accessibility regression with this implementation.

@Addison-Stavlo For me, it always closes at the last item. But, the same thing happens for patterns, so this is not a regression of this PR.

@Addison-Stavlo
Copy link
Contributor

For me, it always closes at the last item. But, the same thing happens for patterns, so this is not a regression of this PR.

For me it goes all the way through the entire list with the patterns in the block. With the dropdown it cuts out early. 🤔

@MichaelArestad
Copy link
Contributor

This is coming along nicely. I just took this for a spin and so far there are still a few things to do before this is ready to merge:

  • Make the Section's title edit/save title bar match the Reusable block title bar.

The reusable block title bar looks like this:
image

Right now, this is what I'm seeing for the Section title bar:
image

It looks like it's just an input currently. I would like to see it match the Reusable block UI closely including the Edit/Save button.

  • The section inserter popover has different styling than the block inserter in the master branch.

Here is the latest inserter from the master branch:

image

And here is what I'm seeing for the Section inserter:

image

  • The search input styles differ (including a visible label)
  • There are extra borders visible around the section list

@epiqueras
Copy link
Contributor Author

Make the Section's title edit/save title bar match the Reusable block title bar.

How would that work with the "Review Changes" modal? I thought we were moving away from a specific/local save button.

The section inserter popover has different styling than the block inserter in the master branch.

Yes, these are separate components. I went with what was already being used for template parts. IMO, the current design is not ideal, but it also shouldn't look like the patterns inserter. We have to make it look good for the different heights of template parts and group them by theme and name somehow.

@MichaelArestad
Copy link
Contributor

How would that work with the "Review Changes" modal? I thought we were moving away from a specific/local save button.

I suppose we could do without the edit/save button, but I think they are valuable - particularly for editing the name of the Section. It should still look identical even without the save button which means there's some wrapping container to go around the input.

Yes, these are separate components. I went with what was already being used for template parts. IMO, the current design is not ideal, but it also shouldn't look like the patterns inserter. We have to make it look good for the different heights of template parts and group them by theme and name somehow.

I understand that they are separate components and that won't look exactly like the current inserter. I do expect it to be pretty close to the mockups. Here was the latest mockup from the proposal:

image

  • The search should look identical (including focus/hover/active states) to the block inserter's search.
  • The Section previews should have the same border styling as the block patterns and block previews.
  • The extra border should be removed.
  • Let's keep the Sections single column for now - we can iterate on that later if Sections start getting categories/taxonomies that allow us to optimize space.

@Addison-Stavlo
Copy link
Contributor

Addison-Stavlo commented Jun 25, 2020

How would that work with the "Review Changes" modal?

I would assume if you 'save' on the toolbar, it would no longer appear in the 'review changes'. Similarly, if you edited and did not hit save, it would then be present in the 'review changes' save flow.

For me, it always closes at the last item.

So it tabs through all items in the preview list for you? How many items do you have present in that? I created a handful of different styled template parts so I had about 8 in mine. When I first tested it would get through about the first 4 before breakout, after adding another template part it now closes after the very first item in the list. There definitely seems to be something funky with the tab flow in the dropdown.

@epiqueras
Copy link
Contributor Author

@MichaelArestad

I suppose we could do without the edit/save button, but I think they are valuable - particularly for editing the name of the Section. It should still look identical even without the save button which means there's some wrapping container to go around the input.

I'll update it.

I understand that they are separate components and that won't look exactly like the current inserter. I do expect it to be pretty close to the mockups. Here was the latest mockup from the proposal:

I was planning to work on that in a follow-up PR since this is already improving on what's already in master, and it would have been nice to get it in before the release, but I'll just work on it here now.

@Addison-Stavlo

I would assume if you 'save' on the toolbar, it would no longer appear in the 'review changes'. Similarly, if you edited and did not hit save, it would then be present in the 'review changes' save flow.

That feels a bit redundant. @mtias Have you thought about this before?

So it tabs through all items in the preview list for you? How many items do you have present in that? I created a handful of different styled template parts so I had about 8 in mine. When I first tested it would get through about the first 4 before breakout, after adding another template part it now closes after the very first item in the list. There definitely seems to be something funky with the tab flow in the dropdown.

Yeah, like eight too.

@epiqueras
Copy link
Contributor Author

@youknowriad Any idea what's going on here?

@youknowriad
Copy link
Contributor

@epiqueras I'm not sure what the question is, some context could be helpful. It seems to be about tabbing. The dropdown close itself if it loses focus, so maybe that's what happening here (focus transferred programmatically elsewhere). For example: when a block gets selected it receives the focus automatically, maybe it's related.

@epiqueras
Copy link
Contributor Author

@youknowriad The popover which shows available template parts with almost identical code to what the patterns inserter uses, closes after tabbing through the first non-empty template part.

@youknowriad
Copy link
Contributor

Are you cloning the blocks to preview or not, maybe you're using the same "clientIds" as blocks rendering (which can mean selected too)

@epiqueras
Copy link
Contributor Author

No, the blocks are unique because they are parsed from the template part HTML.

@epiqueras epiqueras force-pushed the update/template-part-insert-flow branch from 8e20287 to e816f68 Compare June 27, 2020 00:52
@epiqueras
Copy link
Contributor Author

@Addison-Stavlo Fixed!

Let's ship this!

gif

Copy link
Contributor

@Addison-Stavlo Addison-Stavlo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This works considerably better. Do you know what this issue was? I tried testing / undoing the changes from that last commit but it seems to work better regardless of that (was there a fix elsewhere in the rebase?).

I did notice another issue in a preview containing links (footer from 2019-blocks). On tabbing, the links steal focus and subsequently close the dropdown again before I can get to the next pattern in the list:

footer-closes

Also - An unrelated note / question regarding how we should handle the namebar for inserting theme supplied template parts. Currently after inserting the name is blank:

Screen Shot 2020-06-29 at 4 59 56 PM

@epiqueras
Copy link
Contributor Author

This works considerably better. Do you know what this issue was? I tried testing / undoing the changes from that last commit but it seems to work better regardless of that (was there a fix elsewhere in the rebase?).

The popover was fixed in master, I think.

I did notice another issue in a preview containing links (footer from 2019-blocks). On tabbing, the links steal focus and subsequently close the dropdown again before I can get to the next pattern in the list:

This is a limitation with the block preview that is also present in master. It should not block this PR.

Also - An unrelated note / question regarding how we should handle the namebar for inserting theme supplied template parts. Currently after inserting the name is blank:

It should display correctly now.

@Addison-Stavlo
Copy link
Contributor

This is a limitation with the block preview that is also present in master. It should not block this PR.

Im a bit conflicted on this point. While it is a limitation with previews, there doesn't seem to be any other implementation of them where this limitation breaks a11y? So while the limitation with previews itself shouldn't block the PR, the fact that implementing this design forces us to introduce that limitation in an area that creates further concerns with a11y is what makes me feel uneasy. Does that make sense?

If this is a limitation we can fix, then it seems all will be good. But if we cannot fix this limitation in previews, then this dropdown preview design itself is further limited and cannot be fully accessible. Thoughts?

@epiqueras
Copy link
Contributor Author

Patterns with links also break, right?

It shouldn't be difficult to enhance the preview to block tabbing into it.

@Addison-Stavlo
Copy link
Contributor

Addison-Stavlo commented Jun 29, 2020

Patterns with links also break, right?

Im not finding any with links to test, but presumable they would if they existed (in the dropdown / new quick-inserter).

Since we are still under the experimental flag with FSE, I suppose it is safe to move forward with this despite the limitation. But we should look to be aware of this, try to fix the underlying problem, and if all else fails and this is causing issues we can figure out some alternative.

Copy link
Contributor

@Addison-Stavlo Addison-Stavlo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great job here, thank you for all these updates!

The code looks great and everything tests well from my end, minus the noted underlying limitation with some previews stealing focus (#23295 (comment)). Since FSE is still 'experimental', it seems ok to move forward with this despite the limitation (the majority of cases seem to work quite well). But we should look to be aware of this, try to fix the underlying problem, and if all else fails and this is causing issues we may need to figure out some alternative to the dropdown down the road.

@epiqueras epiqueras merged commit 12a5977 into master Jun 29, 2020
@epiqueras epiqueras deleted the update/template-part-insert-flow branch June 29, 2020 23:26
@github-actions github-actions bot added this to the Gutenberg 8.5 milestone Jun 29, 2020
@ZebulanStanphill
Copy link
Member

I think it's worth noting that the name "Section" may be confusing for some users who are expecting an HTML <section>. It's worth noting that one of the things discussed for the Group block was to add block variations in the future (using different HTML elements), including a Section variation. That would be rather confusing combined with this block also being called "Section". It's less of a problem if the HTML element selector is only provided in the Inspector, but I still question whether "Section" was really the right term to use here.

The naming may also be confusing for people expecting something more like the Group block. In a lot of page builders, "section" refers to a container element, not a global template part.

noahtallen added a commit that referenced this pull request Jul 7, 2020
noahtallen added a commit that referenced this pull request Jul 7, 2020
Renames the "section" block back to "template part"

Reverts some changes from #23295

See #23657 for reasoning
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Type] Enhancement A suggestion for improvement.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants