Heading: controls for heading type

[jasmussen]

We should consider which controls are necessary for the heading block, and how those can work best. This is the current mockup design:

In general it seems good form to start out minimalist and opinionated, and then add back features as we find them necessary. In that vein, here are some questions we should consider:

• Do we need formatting controls, or is it sufficient that bold, italic and others work via keyboard shortcuts?
• Do we need alignment controls, or is it similarly sufficient that keyboard shortcuts work?
• Is there a better design for picking heading size than H1-H6?
• If you just insert a heading block, which size is default? H2?

As we think about this, here are some older (but amazing) mockups by @shaunandrews that may be worth revisiting:

Here's a quick and dirty mockup of "bigger and smaller" buttons. The icons need more love, but the idea is there:

[rileybrook]

Some ideas on the individual questions above.

{1/2}

• Do we need formatting controls, or is it sufficient that bold, italic and others work via keyboard shortcuts?
• Do we need alignment controls, or is it similarly sufficient that keyboard shortcuts work?

As someone who uses keyboard shortcuts, I would be happy without formatting/alignment controls. That said, I think it's critical that formatting controls be kept in for users who are novice internet/technology users, usually don't know any keyboard shortcuts, and prefer simple controls they can point & click to use.

{3}

Is there a better design for picking heading size than H1-H6?

A recent user test with a first-time Wordpress user showed me that "H0, H1, H2..." might not be as intuitive as representing size changes as shown in @shaunandrews second example of "Abc, Abc...".

Also, see below for example from Github's own editor.

{4}

Here's a quick and dirty mockup of "bigger and smaller" buttons.

Adding on here, I found users strongly correlated up/down arrows with changing the font size of a header/text. Clickable arrow buttons, such as the @jasmussen example of {^aA} would be a good experiment to test.

[afercia]

Ideally, the most important thing here is to convey hierarchy, not size changes. The size actually depends on the theme styling and might be completely different from what's represented in the headings control. Headings are meant to structure a document, it would be great to educate users to a correct usage. See also the discussions on
https://core.trac.wordpress.org/ticket/38049
and (very long ticket):
https://core.trac.wordpress.org/ticket/27159

[jasmussen]

Nice comments, Riley and afercia!

It sounds like to me that there is a middle way, where we embrace the changing up or down of sizes, but in a way that visually, perhaps textually, conveys hierarchy. Is there an idea here we haven't thought of? Could different icons and behaviors of the buttons help? What if aside from the increase/decrease size buttons was an indicator somewhere that showed the current hierarchy level? A number? What should that number be? Also keeping in mind you might insert an H2 by default, if you then scale that up to an H1, the "up" button would be disabled as it can't go larger.

[paaljoachim]

I apologize if I have not grasped the full discussion but I want to share some of my thoughts on this matter.

Having a way to visually signal that H1 is the biggest and H6 is the smallest will help the user understand the difference.

Vertically similar to how Riley shows it is something I have been thinking about as well, but... a dropdown will cover the content and I am not sure if that is a good idea.
Horizontally as Joen's mockup with the letters in different sizes seems like the best way.

As here is gradually shows what happens when going from H1 to H6. It is important to add in visual markers to make it obvious even before adding a heading or anything else for that matter.

[jasmussen]

I like having the headings immediately accessible. But they do take up a lot of space. An alternative could be a dropdown like this:

See also #783 (comment) for the same pattern applied to "block styles".

[BoardJames]

If you to show the structural meaning of a heading then you need to show it in context to the other headings already on the page and don't give them the option of selecting a h4 just because they want it to look smaller than the h2.

For example you could have a heading block that defaulted to the same size as the parent but had a drop down list that showed the heading in context of all the other headings above it in the heirachy, ie:

+-------------------+
| Heading Structure^|
+-----------------------------+
| Heading                     |
| > Sub-heading               |
| >  > ~Your heading~         |
| >  >  > Sub-sub-sub-heading |

[mrwweb]

I've been thinking a lot about this ticket and issue and have a new idea. I've experimented with the indented heading display that @EphoxJames suggests in my Simple TinyMCE plugin and have been happy with the results. I also think renaming the headings is probably a lost cause since it's just too hard when you get past H3 (see the second ticket @afercia links to).

I noticed that Slack's composed includes the heading levels in the block picker.

This makes sense because "Heading" isn't parallel to "Paragraph," "Heading 2" is. That suggests to me that "Heading" is a category of individual heading level block types and should be treated as such in the UI. (I think this is what ephoxjames implies with his ASCII mockup).

I think there have been some UI explorations of block format expanding menus, so those are probably work revisiting in light of this ticket. Some rough mockups to get move things forward and clarify the proposal:

Heading expandable section:

Heading selection:

[jasmussen]

This is really interesting.

Showing them all as individual sizes in the switcher seems like a great way to show the hierarchy. The big problem here, is that there are 6 heading sizes. If we had only three, as Slack limits to, it would make things much easier, but that feels un-WordPress-like.

[mrwweb]

Showing them all as individual sizes in the switcher seems like a great way to show the hierarchy.

And indented with dashes!

The big problem here, is that there are 6 heading sizes.

That is definitely a thorny issue. I'd start by splitting the question into two:

• Do we need Heading 1? (Extensive discussion that ended in a "yes.")
• Do we need Headings 5 and 6?

Headings 5 and 6 are probably the most likely for formatting abuse and are almost never needed. There is also at least some precedent for dropping buttons but maintaining the shortcuts (underline in 4.7). I always tell people that if they really need a Heading 5 or 6, their pages are too long. Providing access to all block and inline elements isn't a requirement for the editor, so I think Heading 5 and 6 should be considered for removal (while maintaining shortcuts).

[jwold]

Just curious. I realize that H1 - H6 is a longtime standard and a basic piece of html. However, in practice how often are all 6 used? I have rarely found the need for anything more than H1, H2, H3 (as indicated in Github's content editor here)

[mrwweb]

This article and the linked studies may prove quite useful for many decisions that are coming up. They are links to massive datasets and conclusions about the most common HTML elements, CSS classes, meta properties, etc.

The relevant highlight for this thread:

There definitely appears to be a large cutoff between 3 and 4 and 4 and 5. I'd still vote to keep 4 and drop 5 and 6.

[jwold]

@mrwweb that would make sense if we were going to get rid of any to remove H5 and H6. Or at least make them hidden somehow?

[jasmussen]

This is one of those situations where it feels like a huge chunk of people, perhaps the majority, just uses the first three sizes, but that a bunch of other not insignificant chunks use the others. SEO concerns have been brought up, and I personally use only h2, h3 and h4 in my designs, relegating h1 to themes.

This suggests a good design should accommodate both groups. But such a design has been discussed for a very long time, with some trac tickets (also linked here #522 (comment)) having tried to crack this nut for a long time.

I like @mrwweb's dropdown idea (which inspired this) because it reduces the use of space, seems predictable to use, and doesn't actually hide any features. Last thing we want is people who otherwise like the visual editor, having to go into text mode to add an H6.

That's not to say I don't endorse efforts in suggesting headlines, and fewer of them. I think that's a noble goal. Just that it's a difficult design nut to crack.

[jwold]

Agreed. The design problem is the big issue here. I was playing around with Gutenberg this morning and trying to get a sense of the best way to approach it. No sudden inspiration so far :). Great discussions on the topic though!

[StaggerLeee]

H tags take much place. They are not used so often. Many developers chose to remove this option and give Users font-size, font colors, or whatever. To not mess with it and be punished by Google.

I like dropdown mockups.

[shaunandrews]

Another +1 for the dropdown solution. Seems the most robust and flexible as a whole pattern.

[afercia]

A11y note: a custom widget that emulates a dropdown can perfectly be built in an accessible way to emulate a native select. That would require some additional ARIA and scripting efforts though.

[jasmussen]

Master is working reasonably well currently, with a decent design. I think it might be worth looking at @paaljoachim's size hierarchy visuals here, to help improve it further.

[mrwweb]

I would just like to echo @afercia's previous comment that matches my experience:

Ideally, the most important thing here is to convey hierarchy, not size changes.

I'd actually say that size differences without any hierarchical indication leads editors to worse choices.

[jasmussen]

I'm going to close this for now as sort of addressed. Although the Heading block isn't perfect, it's much improved since this ticket.

If it feels unadressed still, we can reopen. But ideally we can also open new separate tickets for improvements to the block as it exists today.