Add visual cue for group block in Block List View for tagName selected. #43040
Conversation
|
Size Change: +69 B (0%) Total Size: 1.27 MB
ℹ️ View Unchanged
|
|
|
|
Thanks for the PR! I wonder if there needs to be anything different when there's a tag name and an anchor. Currently it appears as this: It could alternatively look like this: Though maybe this is too developer-y, and I know it was mentioned in the issue that the angled brackets should be shown. Another option is that one overrides the other. Or leave it as it is (though I'd perhaps switch the order). It would be good to get feedback from a designer on this. I like the suggestion of making it a preference in #42610 (comment). Or perhaps it could be a site editor only feature. |
I think this could work. It is developer'y, but these features are inherently technical by nature so perhaps that's ok. |
|
Thank you for the PR! I'm coming back to this from a long break so apologies if my thoughts appear to suddenly go in a different direction. I'm a bit concerned about adding more labels to the list view, not because they aren't useful, but because there's already a great deal of complexity (both code and visual) to manage there:
Rich's original idea, to change the icon to a header icon when the header tag is used, seems interesting. Other options include tooltips or otherwise. |
Makes sense to me. If we can settle upon a set of icons to use instead that works for me, or if it is preferred that a tooltip is used, we can go that direction as well. |
|
Yes indeed, that's the tricky piece. A good argument is made on the original post that we already have unique items for header and footer templates, and that this could confuse the list view. This makes me lean more towards a tooltip approach. Ultimately that might not thread the needle in terms of discoverability, though, which makes the issue a really tough nut to crack 🤔 |
|
If we changed the icon then I think we'd certainly need some visual distinction for template parts (#32163) otherwise the overlap would just be too confusing. We still run into spacing (and some noise) issues, but could another option be to use icons / tooltips?
|
|
The most important part, I would suggest, and honestly what's stumped me as to how to best proceed is: the List View can be such a key affordance for casual flows — post and page building alike — that it's really crucial we don't add noise if we can at all avoid it. In a way, the desire to add more features to this interface, is probably because people love it. We just want to balance that to a point where people don't stop loving it. Rewinding a bit, this interface already exists in the Advanced section, and the reason we put it there originally was because we believed it was just that: an advanced interface you wouldn't need to touch that often. To an extent, putting it in the list view is the exact opposite reaction, and instead of doing this, I wonder: is there a natural place to put this feature, if "Advanced" hides it too much? |
|
I think it's fair to say that assigning a specific tag is an advanced flow, and the UI to do so is in the right place. But once you've assigned a tag, it seems reasonable to have that information available at a glance. It would be frustrating to see a Group that you know should be a header, go to set it, and find that you already did. And then repeat the same process the next time you edit that document 😆 Would it disrupt the visual flow too much if the tag was beneath the name?
A couple of additional thoughts:
|
|
Good instinct to look outside the usual boundary! The balance tips a bit for me. I do see the sense in showing this only when customized. I'm still not convinced it needs to be in the list view, though — yes, potentially the block card, if the UI is just right. |
skorasaurus
added
the
[Feature] List View
|
Warning: Type of PR label mismatch To merge this PR, it requires exactly 1 label indicating the type of PR. Other labels are optional and not being checked here.
Read more about Type labels in Gutenberg. Don't worry if you don't have the required permissions to add labels; the PR reviewer should be able to help with the task. |
|
Hi @BE-Webdesign Do you plan to continue working on this feature? |
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the Unlinked AccountsThe following contributors have not linked their GitHub and WordPress.org accounts: @BE-Webdesign. Contributors, please read how to link your accounts to ensure your work is properly credited in WordPress releases. If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
Fixes #42610.
What?
Adds the tagName to the group block in the List View of blocks.
Why?
Helps bring more clarity to the type of group being used. You will more easily know which group is which by seeing the tagName.
How?
Modifies ListViewBlockSelectButton to add in a tagName if set, which same treatment as an anchor element. Adds tagName to useBlockDisplayInformation return value to have it present in component.
Testing Instructions