Add heading block variations and transforms #55520
Conversation
richtabor
added
[Type] Enhancement
|
Size Change: +1.33 kB (0%) Total Size: 1.69 MB
ℹ️ View Unchanged
|
This reverts commit 52d686dcf94ccf11e8f6ff941a2a0a9abfe64fef.
richtabor
force-pushed
the
try/content-transforms
branch
from
d461855
to
3f4abfc
Compare
|
Flaky tests detected in 3f4abfc. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/6591940427
|
|
I'm a little bit conflicted on this one. There are details that improve the general flow:
However, does the increased level switching prominence make it feel like a design decision, and is that counter-intuitive considering the document outline/structure? As a provocation, I wonder how a Text styles experience (similar to Figma) might work here. IE the ability to say "Make this |
|
Another consideration here is that this becomes a teachable moment, to help you understand the mechanism for transforming blocks into other blocks. If you learn it here, changing between paragraphs -> headings, or heading level to > heading level, you've learned the mechanism that is applied throughout all blocks. The current method for switching levels does not afford that learning.
There's also effort to include the heading level in List View. This PR would resolve that issue as well, without adding extra weight. I lean towards the level heading icons being more helpful, than seeing the more generic heading block icon.
Hm, I don't think so — though I'm not following entirely on the document outline bit. |
The concern is that folks might be more likely to select the 'incorrect' heading level in posts / pages. E.g. multiple H1s, or H4s after H1s or H2s, etc. It almost feels like the heading level should be set automatically so the user doesn't have to think about it, and they just change the appearance as desired. I acknowledge that's a separate discussion though :) Like I said, the changes here feel good to use, so if the outline isn't a concern then I'd be happy to approve. |
|
While not a strong opinion, I can see the heading level selector merging with the transforms selector: it's one less place to look. But I could also see the selector staying where it is, though if we do end up keeping it, it would be nice to balance the three icons a bit, or split the heading selector into its own toolbar group. Right now block align, text align, and heading level, seem a bit arbitrarily grouped and sorted:
Regardless of the direction, I would think it borderline a blocker to add this until we can leverage the nested dropdown menu; the height of the menu with all 6 levels in addition to what's there already becomes a bit much. |
Agreed. Was worth an experiment to feel it out, but nested will help reduce quite a bit. But I also want us to consider removing styles from this transform panel as well. I lean towards providing a clear place to transform blocks, rather than a catch all to change something. But like you mention there, maybe having "Styles" as its own nested dropdown helps there too. |
|
Chiming in here from #56035 (comment) Adding the needs accessibility feedback accordingly. A few first impressions:
I'd agree and that was my first thought. All that stuff in a menu seems too much. Also, that should be tested on small screens where all that height might be a serious problem.
I'm not sure the the nested dropdown menu has been tested for accessibility yet. I'd like to see it tested before we can consider it a viable option.
I'd argue that changing the heading level isn't really changing the heading block to another block type. Those are differenc concept and I'm not sure placing the heading levels into the transform menu is ideal in the first place. Separate concept sshould live into separate places. Also, users are used to have the heading levels menu there, where it is now. It's simple and easy to use. Why we'd want to change things that work well for users? |
As a general note, I'd think that any issue or pull request that changes the UI should ask for accessibility feedback, unless it's a purely 'decorative' change. Thanks. |
I also propose a follow-up to refine available transforms for content blocks to focus on content transforming, and nested dropdown will help reduce as well.
It's one and the same in my opinion, H1 -> P is the same level of change as H1 -> H2. They're not separate concepts; we're just treating them like separate concepts currently.
What I'm proposing is exactly the same as what we have now; just more helpful, and more prominent, which will result in a better experience. Instead of having to look for heading level, the block is the set as the heading level. You click on the "H2" icon to change it to any other level—or to any other type of content. You're not having to go to varying locations in the UI to change content from one type to another; it's consolidated. |
This is a proposed UI/UX—rather than accessibility—enhancement. It does not introduce any new controls, interface elements, etc. So I wouldn't think it needs accessibility input. There are much more clearly a11y-related issues that need attention. 👍 |
We agree we disagree 🙂
On what data are you basing your statement that 'it will result in a better experience'? This seems to me a subjective opinion. In absence of prior research, such changes should be user tested with a fairly large user base that includes users with different abilities. Only after that, based on testing and actual data, we may want to state whether it's an improvement or not.
I'd argue that any change to the UI needs as much feedback as possible from different angles. Accessibility is something that is not separated from design, usability, and user experience. Rather it should be part of any design (using the term design in its broader sense here) singe the beginning. Specifically to this case, this proporal aims to change a very well established pattern where the block transform is separated from the heading levels since WordPress 5.0. I'm stil not sure changing this adds value for users. Also, I'm not sure that continuously changing the UI is ideal. It should be done only for very very good reasons. Regardless, we're still (mostly) on a plan of subjective opinions. I wouldn't be opposed to this change if it gets user tested and proved to provide a better experience. A simple A/B test with a large and diverse base of users would be ideal. |
It's how nearly all editing experiences work today; an expectation we've omitted ourselves from (which we tend to do far too often throughout the experience). Notion, Google Docs, Medium to name a few.
I agree. While in Gutenberg it's easy and quick enough to test. A merge today is not a commit to WordPress tomorrow. Not saying I want to merge this today — I'd like to explore with nested dropdown as well first :) |
|
Note that this would also change the heading icon in list view, which is actually really nice. It handy to know the heading level in list view. Also this is how it used to work in TinyMCE:
Same in Apple Notes: 
|
|
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 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. |
I agree. It makes the heading level clearer without introducing any badges, or additional UI elements, both in the toolbar and in List View. The downside is the length of the transforms panel. Seems like the secondary transforms could be potentially refined into a nested dropdown (perhaps related to #63635). |
|
One of the reasons I created that 😉 |
What?
Part of #55067, to support more intuitive transforming between content—initially between paragraphs and headings of any level.
Wanted to give it a spin and see how it felt live. I do think that more cleaning up will improve the flow a bit more (listed in "Follow-ups" below.
How?
Follow-ups
Testing Instructions
Screenshots or screencast
content-transforms.mp4