Opened 8 years ago
Closed 7 years ago
#38049 closed enhancement (wontfix)
Rename Headings in TinyMCE
Reported by: | mrwweb | Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | |
Component: | Editor | Keywords: | has-patch |
Focuses: | ui, accessibility | Cc: |
Description
Forking a proposal from #27159 where Heading 1 will be removed from TinyMCE in WordPress 4.7:
Multiple people have suggested renaming the Headings in the editor to encourage correct usage (that is the goal of this ticket). I would add that this might be combined with actually removing Headings 5 and 6 which I imagine are barely [properly] ever used. (Theme and plugin authors will always be able to add Headings back via filters.) Only having to name three levels of headings also makes this much more feasible.
A few ideas just to get things started.
Concept 1
- Heading (H2)
- Subheading (H3)
- Subsubheading (H4)
Concept 2
- Section Title (H2)
- Subsection Title (H3)
- Subsubsection Title (H4)
Concept 3 (use indentation to imply hierarchy)
- Heading 2
- – Heading 3
- –– Heading 4
At least at first, I think it would make sense to retain the HTML heading level in parentheses as shown above to help technical editors understand what's going on.
To encourage correct heading usage, the new labels must communicate to all editors that the heading levels are hierarchical and not selected based on perceived importance or (obviously) visual appearance.
One primary problem is "what comes after sub? subsub?" Most rich text editors editors I've looked at while writing this ticket either using "Heading #" OR give only two levels of Heading (which avoids the "subsubsub" problems).
References
- Medium just changed their formatting toolbar to focus users on appearance over heading levels because they were apparently being abused. I think this is pretty obviously the opposite direction this ticket intends to go (giving into visual over hierarchy).
- I honestly can't find other examples of editors doing this beyond the exceptions mentioned above, so examples are highly appreciated.
cc: @hugobaeta
Attachments (1)
Change History (35)
This ticket was mentioned in Slack in #core-editor by mrwweb. View the logs.
8 years ago
This ticket was mentioned in Slack in #design by hugobaeta. View the logs.
8 years ago
#4
follow-up:
↓ 5
@
8 years ago
In a conversation with @azaozz I ended up realizing this idea that what is important here is to convey hierarchy to the user, not imply what code is used. So I'm actually very much ok with using just "Heading 1" to represent what will be an h2, because this is a visual editor, not a code editor.
To that note, I suggest we go with this:
- Heading 1 (this would generate an h2)
- Heading 2 (this would generate an h3)
- Heading 3 (this would generate an h4)
I know this ticket also addresses removing the other levels for h5 and h6, which I have to agree with. The argument here is the vast majority of users are probably using this not to denote hierarchy, but simply to have smaller text sizes, which would be a non-semantic usage of headings. I don't have stats for this, maybe someone from Automattic can grab stats from the Calypso editor on this. Either way, if this ends up being a reason for strong disagreements, I'd ignore it for now and eventually move that to another ticket.
@azaozz I'll leave it to you, but I think at lease using this naming convention for 4.7 beta would be great. Can I get some other designers to also sign off on this? @karmatosed @melchoyce ?
#5
in reply to:
↑ 4
@
8 years ago
- Milestone changed from Awaiting Review to 4.7
Replying to hugobaeta:
Yeah, exactly. Most users have never heard what h1
and h2
are, and are not concerned with what HTML is used in the background. They just want to be able to format their posts and (preferably) have familiar UI for that.
Thinking we should improve this drop-down after removing the h1
, shouldn't leave it as it is at the moment for 4.7. Moving it to that milestone for review.
#6
@
8 years ago
- Focuses ui added
- Keywords has-patch added
38049.patch implements the above:
- Use "Heading 1" for inserting h2, "Heading 2" for h3 and "Heading 3" for h4.
- Remove h5 and h6.
#7
@
8 years ago
- Focuses accessibility added
I'm not sure the mismatch between the visible number and the actual heading level is so ideal. Thinking this has the potential to mislead users.
Also the mismatch between the Heading # and the shortcut hint is a bit confusing:
Instead, I like the proposal with the indentation because it visually represents the concept of hierarchy and would help educating users that headings should be used semantically.
#8
@
8 years ago
- Focuses accessibility removed
Please don't do this. Any of it. Please.
The removal of the Heading 1 will be a HUGE pain for anyone using a page builder plugin. When using a Page Builder, most of them don't automatically output the actual page title. They'll simply start off with a blank page (by default). This means you typically need to manually enter the page title and style it as a H1. Removing the 'Heading 1' option is obviously going to make this extremely difficult.
As much as most people here wont like page builders, there are HUGE communities (Beaver Builder, Divi, Visual Composer, etc.) of people using them and you're going to make life very difficult for them by removing this 'Heading 1' option.
Likewise, I think the idea to change what HTML tags are generated for each Heading is a really, really bad idea. Anyone who's been using WordPress for even a short amount of time, knows that when you use a 'Heading 2', it generates an h2, as an example. Changing this so that an 'Heading 2' now generates an h3 is ridiculously confusing. You don't need to be a developer to know what an h1 or h2 heading is used for. Anyone who knows anything about SEO knows about h1's h2's etc.. Having an 'Heading 2' generate an h3 is just so confusing. At the moment you don't have to think about it, when you select a 'Heading 2', for example. You automatically know that a 'Heading 2' will generate an h2. How is changing this making things easier for the end user? It's certainly not making it any more semantic.
Likewise, changing the names of these titles would be equally confusing. There's no standard naming conventions for anything like Heading (H2), Subheading (H3), Subsubheading (H4) or below. The nearest convention we have is what is specified in the html spec, which is the word 'heading', hence why 'Heading 1', 'Heading 2', 'Heading 3' etc. makes sense.
Again, anyone who has even a mild interest in SEO isn't going to know or understand what a 'Subsubheading' is. Every SEO article out there is going to refer to your page titles as 'Heading 1', 'Heading 2' etc. When Google talks about "Dos & Dont's" for good page SEO, they're not going to use the terms 'Subheading' and 'Subsubheading', they'll use 'Header 2' (or 'h2') and 'Header 3' (or 'h3'). You're not make things easier by changing this convention, you're doing the exact opposite.
I also think it's a huge mistake to remove 'Heading 5' & 'Heading 6'. I agree that these headings aren't used anywhere near as often as the others, but it's not up to you to say that people shouldn't be using them. The fact the they could be added back in using a filter is irrelevant. Why should we have to add another plugin or add a new filter just to get back functionality that should be there in the first place. How does removing these two Headings make WordPress any easier to use? It doesn't, simple as that.
I'm all for simplifying things in the dashboard, but things shouldn't be removed or even renamed at the expense of making things more difficult for end users.
#9
@
8 years ago
- Focuses accessibility added
Please don't remove the accessibility
focus tag since it is used to generate Trac reports and helps us to properly handle tickets.
#10
@
8 years ago
@afercia Apologies for that. It wasn't done on purpose. I must've accidentally clicked on the tag. Sorry about that.
#11
@
8 years ago
Not sure I agree with the change. And I definitely disagree with the statement that "most users have never heard what h1
and h2
are".
First of all, everybody knows what's the difference between H1-H6, it's a common-sense. Titles are used in word processor for a long time. WordPress didn't invented this.
Second of all, the naming changes are not consistent with all the themes. Each theme has it's own title structure. Forcing this change will confuse many users.
And finally, as mentioned above, mismatch between the visible number and the actual heading level is misleading.
I see more disadvantages than advantages in this proposal.
#12
@
8 years ago
My 2 cents:
- About the removal of the H1: We had this discussion before in the Genesis Community. A lot of developers use a Page Builder, as @ahortin mentioned, and removing the H1 removes it from the pages all together, which seems not a good idea.
- Naming the levels of headings different from the actual level in the HTLM seems wrong and confusing to me.
- I like the dashes before the levels to show the structure.
- Adding subsub etc is ugly and I wonder how well that is translatable.
- I like the removal of the H5 and H6 to simplify the dropdown, but that's personal and not accessibility related
Maybe instead of H1 say: main heading, and the rest as they are with dashes?
Like:
Main heading - Heading 2 -- Heading 3 --- Heading 4
This ticket was mentioned in Slack in #accessibility by rianrietveld. View the logs.
8 years ago
#14
follow-up:
↓ 15
@
8 years ago
Like I said a few weeks ago in a #design meeting, I think its better to change the label of "Heading 1" so it discourages usage in the post content. I think the suggestion at the time was "Heading 1 (Title)" or something similar. I like @rianrietveld's suggestion "Main Heading" as well. Mentioning "Title" might connect it better to the post title field though. Maybe "Main Heading (Title)"?
#15
in reply to:
↑ 14
@
8 years ago
Replying to iseulde:
Mentioning "Title" might connect it better to the post title field though. Maybe "Main Heading (Title)"?
Or just plain Title? Like Google Docs does?
This ticket was mentioned in Slack in #core by stevenkword. View the logs.
8 years ago
#17
@
8 years ago
- Milestone changed from 4.7 to Future Release
Punting from 4.7 for needed UX work, further discussion, and testing.
#18
in reply to:
↑ 3
@
8 years ago
Replying to hugobaeta:
Another solution might be to use explicit levels indicators:
- Heading Level 1 (this would generate an h2)
- Heading Level 2 (this would generate an h3)
- Heading Level 3 (this would generate an h4)
That is super confusing and I can't think of any other place in WordPress where the interface is essentially lying about what it's doing. I have personally spent hours drilling into people not to use Heading 1 and I personally know a lot of other who have done the same. This would cause problems and people wouldn't even know it.
Regarding page builders, in previous tickets it's been mentioned that it's quite easy to add H1 back into formatselect
via the tiny_mce_before_init filter settings. I know some page builders (Make theme) insert the title as H1 with screen reader text if users choose to hide it, which seems like a smart decision. Even with page builders, my guess is still that a large majority of themes either output Heading 1 for the Page Title or should be doing that and are doing something weird instead.
Finally, I want to remind people the point of changing this:
To encourage correct heading usage, the new labels must communicate to all editors that the heading levels are hierarchical and not selected based on perceived importance or (obviously) visual appearance.
Any interface that relies only on how headings look will do more harm than good. I have spent hours watching people screw up the use of headings and that is the primary mistake they make. (I've written up a list of common heading mistakes I see users make.)
So with all that said, I think we should either do:
Heading 2
– Heading 3
–– Heading 4
OR
Page Title
– Heading 2
–– Heading 3
––– Heading 4
This may not be as pretty as renaming them but it is technically descriptive and shows hierarchy. Given that, I have a hard time imagining a solution that meets the goal better than that.
This ticket was mentioned in Slack in #core-editor by azaozz. View the logs.
8 years ago
#20
follow-up:
↓ 22
@
8 years ago
- Milestone changed from Future Release to 4.7
- Type changed from enhancement to task (blessed)
Discussed this again at today's editor chat. If not renaming the remaining headers (as suggested in comment 4), the best thing is to bring h1 back and rename it.
That will pretty much stop the users from using it to just set font size, so the goal from #27159 will be met. It also covers the few legitimate user cases mentioned above.
Thinking it should be renamed to "Title" as in the examples above. This is the clearest label that describes what h1 should be used for the best.
Also thinking this should be fixed in 4.7, starting with Heading 2 is pretty confusing.
This ticket was mentioned in Slack in #design by iseulde. View the logs.
8 years ago
#22
in reply to:
↑ 20
@
8 years ago
Replying to azaozz:
Thinking it should be renamed to "Title" as in the examples above. This is the clearest label that describes what h1 should be used for the best.
Also thinking this should be fixed in 4.7, starting with Heading 2 is pretty confusing.
Both good points.
Hopefully you'll include the indentation too! Having looked at @hugobaeta screenshots above and a bit more thinking, I actually think not having a dash before H2 makes the most sense since it's also "top-level" in many senses:
Title
Heading 2
– Heading 3
–– Heading 4
Those are en-dashes by the way. Having experimented with most dashes, I think those are the nicest looking.
That also keeps things shorter and less dashy. I don't know if that will cause any problem with RTL languages.
This ticket was mentioned in Slack in #core by jeffpaul. View the logs.
8 years ago
This ticket was mentioned in Slack in #design by hugobaeta. View the logs.
8 years ago
This ticket was mentioned in Slack in #core-editor by mrwweb. View the logs.
8 years ago
This ticket was mentioned in Slack in #accessibility by afercia. View the logs.
8 years ago
#29
in reply to:
↑ 28
@
8 years ago
Replying to afercia:
Should this ticket be moved out from the 4.7 milestone?
I believe so, but I sure hope we continue discussion on this in 4.8.
#30
@
8 years ago
- Milestone changed from 4.7 to Awaiting Review
- Type changed from task (blessed) to enhancement
This ticket was mentioned in Slack in #core-editor by mrwweb. View the logs.
8 years ago
This ticket was mentioned in Slack in #core-editor by hugobaeta. View the logs.
8 years ago
This ticket was mentioned in Slack in #accessibility by afercia. View the logs.
7 years ago
#34
@
7 years ago
- Milestone Awaiting Review deleted
- Resolution set to wontfix
- Status changed from new to closed
Closing this ticket as per today's bug scrub. With the advent of Gutenberg, many things will change even if the classic editor will probably stay for a while for custom post types. @mrwweb please do feel free to reopen if you think this is still relevant.
Another solution might be to use explicit levels indicators:
Some examples for perspective:
GoogleDocs
Pages