Removing TinyMCE buttons to improve user experience

[hugobaeta]

WordPress has grown so much in the last 10 years, and it is my opinion that it having a visual editor was a great part in it's success. The user experience is enhanced by the ease of use a visual editor provides. But it can also create situations where it compromises the user experience of the final product - the front-end of the site/blog.

It is my opinion that TinyMCE is a blessing and a curse at the same time!!

As we move into the realm of front-end editing, I find it pertinent to address these concerns and potentially help "clean up" TinyMCE and encourage the editors to make better choices when it comes to the use of the visual editor functionalities.

I'm a big fan of keeping things simple and intuitive - less is more. So I propose we remove a few of the TinyMCE buttons for both safety and simplicity's sake:

Underline - It introduces a potentially bad user experience issue: readers confusing the underline text with a link. Underlined text is broadly interpreted as web links.

Alignment buttons - A great way for a user to break the theme!! Alignment should be left to the care of the person who spend hours crafting a great theme with the correct type settings. WordPress is built on this idea of one being able to switch themes and things looks great no matter what. Well, hardcoded styling in a post won't!

Text Color - same arguments as text alignment. Should an editor really be able to break a theme that was carefully designed with a color palette in mind? Maybe if this came from some kind of theme function (where the theme designer sets a color palette for the editors to use on the visual editor) maybe... but let's not go off topic ;)

---

I know this might encounter some resistance. "Those buttons have always been there", "Users shouldn't loose these options", I can hear some say. Yes, but WordPress at it's core should be a lean user friendly experience, not a bloated one.

Let's discuss! Cheers!

[hugobaeta]

@melchoyce pointed out that I added the indent buttons in the above screenshot about alignment. In my head all they did was add padding to the paragraph, but she pointed out it is used for nesting lists. I just played with it and it's pretty cool - the button actually does different things in different contexts. For the sake of this discussion it's better to ignore them for now then :)

[azaozz]

The alignment buttons also work differently in different context: for images (with or without captions) they add alignleft/aligncenter/alignright classes, for text they add inline style on the parent block.

[hugobaeta]

Replying to azaozz:

The alignment buttons also work differently in different context: for images (with or without captions) they add alignleft/aligncenter/alignright classes, for text they add inline style on the parent block.

In the case of images, we have the alignment options in the image dialog. Also, when we align an image it returns a class that is controlled by the theme. On paragraphs, it returns inline styles in the html.

[ubernaut]

I like this and agree about the cases you bring up. think in fact the basics are right here in the comment box in trac a very mobile friendly looking set as well i would add.

[celloexpressions]

Can we get stats on usage of each TinyMCE button from wp.com? There may be other candidates for removal based on usage.

I agree that we should remove underline, text color, and justify, since they tend to break themes. Not sure about the alignment buttons; most users will want at least the ability too center/uncenter. However, removing those would probably push them to use h1-6, which is probably styled appropriately for what they're doing and is definitely the semantic version of what they're doing.

I wonder if there're any other buttons that we should add to encourage more semantic posts; for example, I see a lot of users do a big row of underscores instead of <hr>.

[melchoyce]

Replying to celloexpressions:

I wonder if there're any other buttons that we should add to encourage more semantic posts; for example, I see a lot of users do a big row of underscores instead of <hr>.

Is <hr> still semantic? I mostly ask because I manually add them to posts/pages all the time, and I always feel a little guilty about it.

[iammattthomas]

Replying to melchoyce:

Is <hr> still semantic? I mostly ask because I manually add them to posts/pages all the time, and I always feel a little guilty about it.

Yep, in HTML5 it's a "paragraph-level thematic break." ​http://dev.w3.org/html5/markup/hr.html

[melchoyce]

Replying to iammattthomas:

Replying to melchoyce:

Is <hr> still semantic? I mostly ask because I manually add them to posts/pages all the time, and I always feel a little guilty about it.

Yep, in HTML5 it's a "paragraph-level thematic break." ​http://dev.w3.org/html5/markup/hr.html

Rad. :) Goodbye, guilt.

[hugobaeta]

Replying to celloexpressions:

Can we get stats on usage of each TinyMCE button from wp.com? There may be other candidates for removal based on usage.

I mentioned this on the skype group chat, but it's good to reiterate here. My whole idea is based on the concept of semantic markup. Stats are good, but just careful with how you use them: they should provide clarity, but not be decisive in this matter.

As I said, I'd rather think in terms of what generates semantic markup lives in the base editor. What extends that (and is supported by a theme - aka anything that adds spans and classes to the markup) should be an extension (probably coming from a theme, like the image alignment classes)

Semantic markup includes:

• bold - <strong>
• italic/emphasis <em>
• strikethrough/delete - <del>
• etc

Non-semantic inlcude:

• Alignment - <p style="text-align: right;">
• Text Color - <span style="color: #ff99cc;">
• Underline - <span style="text-decoration: underline;">

We should help the user avoid having these non-semantic ones in the database entries. It defeats the purpose of our goal of letting users switch themes and still have a beautiful site...

[nacin]

In theory I identify pretty strongly with the various arguments outlined here. In practice, I don't think we should touch these.

In the admin, the main items here are under the "kitchen sink". Along the same vein, I wouldn't want them to appear on the front-end editing toolbar.

I'm all for encouraging good choices. I'd support considering a floating toolbar for editing, and bury even more things in a "kitchen sink"-style location, but I don't think we should outright hide them. An editor that strictly controls WYG is not a very good WYSIWYG experience (​hat-tip).

I don't think anyone choosing a color in their post is doing so in order to align it with their theme, especially to the point where a theme switch suddenly looks weird. Same goes for alignment, or underline. It's about what they want to do with their content. And I don't think any of these are inherently bad, nor do I think they in and of themselves cause a site to look terrible.

[iseulde]

We talked about this in #wordpress-ui, and helen suggested burying the underline button even deeper than the kitchen sink by only keeping the cmd/ctrl + u shortcut. azaozz will remove it from the toolbar, move the strikethrough button to the kitchensink and add the hr plugin to core, with a button on the top bar. [1] Thoughts on this are welcome.

markjaquith suggested disabling the indent/outdent buttons for non list elements [2], but that seems to be difficult without having more options added to TinyMCE. May be worth asking spocke, TinyMCE's lead developer.

Seems like the alignment buttons should either stay where they are or move to the kitchensink. I think it'd be good though to detect the default alignment and disable that button to prevent the user from adding useless markup. The only reason people click on align left, for example, is to undo when it's been centred or aligned right previously.

The colour buttons on the other hand are easier to (re)move to plugin territory. (?)

Just trying to keep everything here. :)

[1] ​https://irclogs.wordpress.org/chanlog.php?channel=wordpress-ui&day=2014-03-05&sort=asc#m163571
[2] ​https://irclogs.wordpress.org/chanlog.php?channel=wordpress-ui&day=2014-03-04&sort=asc#m162952

[azaozz]

In 27428:

TinyMCE: add the <hr> plugin and button, see #27159

[hugobaeta]

Replying to avryl:

Seems like the alignment buttons should either stay where they are or move to the kitchensink. I think it'd be good though to detect the default alignment and disable that button to prevent the user from adding useless markup. The only reason people click on align left, for example, is to undo when it's been centred or aligned right previously.

Yes, moving the alignment buttons to the kitchen sink would be a great first step! I've noticed you commenting on the left align before, but in fact the button does absolutely nothing when the text is already left aligned. So it is, for all intents and purposes, only a "reset" button for other alignments already.

[hugobaeta]

Replying to nacin:

An editor that strictly controls WYG is not a very good WYSIWYG experience (​hat-tip).

Thank you for your comment, I understand what your point is. I know how complicated a change like this might be.

That said, I think this brings up another type of discussion: does WordPress really has a WYSIWYG editor? I don't think it does, unless the theme designers do an excellent job on the editor stylesheet - which mostly doesn't happen. We have a sort of Visual Editor, closer to a WYSIWYM (What you see is what you mean) editor - and I think that is perfectly fine for the backend IMO. The front end editor, on the other hand, needs to be (and is) more literal to a WYSIWYG.

Now the interesting thing about the kitchensink is that is actually hides currently options that, in my opinion, are more important - namely the block formatting (headings, etc), and maybe even the undo, and the pasting options (but pasting issues can be easily fixed and those buttons can be eliminated imo).

But change is always risky, so I understand the reservations. I'm all in for helping out with things relating to this :)

[azaozz]

In 27159.patch: remove the "underline" button (Ctrl/Command+U still works) and move the "strikethrough" (insert <del> tag) button to the second row.

The alignment buttons are actually toggles, first click applies the class/style, second click removes it. They are pretty convenient for aligning images (1 click vs. 3 clicks to open the modal, select alignment and close). On the other hand having the "block formats" drop-down in the top toolbar as well as the undo/redo buttons makes sense too.

[hugobaeta]

Replying to azaozz:

The alignment buttons are actually toggles, first click applies the class/style, second click removes it. They are pretty convenient for aligning images (1 click vs. 3 clicks to open the modal, select alignment and close). On the other hand having the "block formats" drop-down in the top toolbar as well as the undo/redo buttons makes sense too.

You are absolutely right. My comment above is wrong! I'm sorry. For some reason I was playing with this the other day and was sure the left align was just a reset, but no, it does apply a damn style property in the <p> tag.

Until I started this ticked and talked to a few people, I had absolutely no idea you could align images with the text alignment buttons. It just never crossed my mind. I'm curious as to how many people actually used them for that effect. But image alignment could be simplified (and clearer) if the overlay that shows up when you click an image in the editor displayed some quick actions, like alignment. Maybe that would be a good iteration?

[celloexpressions]

I like where this discussion is heading. Remaining thing I see that would be a quick improvement would be to move the paragraph/heading selector to the front of the first row - this is arguably the most important option and should be first (as it is in the front-end editor). We could then move the alignment buttons back down for an comparable trade-off of space, and that would allow justify to sit alongside the other alignment buttons.

Quick image-alignment buttons make sense and were discussed at some point if I remember correctly. I don't think many users know that the paragraph alignment buttons also do images.

[iseulde]

Moving the alignment buttons down and the formatselect button up makes sense. But then, should a user really be adding an <h1> in the content? That's for the title. :)

Other things that have semantic meaning and could be added are the code (#6331) and table (now just one drop down in TinyMCE 4) buttons.

[nacin]

#28981 was marked as a duplicate.

[anonymized_10765487]

Replying to nacin:

#28981 was marked as a duplicate.

I understand it's similar but I do not want WordPress to remove tinymce, I want WordPress to add span with CSS classes.

[akibjorklund]

I wrote ​a blog post today about this issue, without knowing there was this ticket. In short, I proposed practically everything that was mentioned in this post.

Short background story: I've been doing content management for 15 years now. Most of that time I was designing CMSs for major media companies in Finland, but 5 years ago I started my own agency and switched to WordPress. These WordPress customizations are pretty much what I have been doing for clients that have a lot of content and that have a priority of creating content that is reusable decades from now.

I realize the needs of a lonely blogger are different from a corporate with millions of articles, but I do not think at least making formatselect visible by default and simplifying the first row by moving stuff to the second would do any harm to most of the users. On the contrary, it would make the interface a bit more simple and thus help everybody.

[EmpireOfLight]

Just a note on the current tinymce buttons in Dashicons–they were designed to mimic the default set that came with tinymce, so there was a familiarity issue to deal with. If people are using tinymce in other settings, this may be something to consider.

[melchoyce]

@hugobaeta, @azaozz and I chatted about this a bit this week. We decided it makes sense to remove the underline and justify icons from the toolbar, and move both strikethrough and the alignment icons down into the kitchen sink, as previously discussed. Since images now have their own toolbar with unique alignment icons, left/center/right align are now less useful to the average site builder.

We also talked a bit about moving undo/redo up out of the kitchen sink, but didn't make a final decision.

Additionally, l agreed with @iseulde and argued for removing "Heading 1" from the text formatting dropdown, but that also didn't come to a conclusion.

@azaozz — do you want to update 27159.patch​?

[iseulde]

If four buttons move down/go away, I think the headings should move up.
Are there any stats about each button's usage? I remember getting a report about this, but I forgot from whom.
Would be interesting to know how much the headings are used, and the undo and redo buttons.

[melchoyce]

Are there any stats about each button's usage? I remember getting a report about this, but I forgot from whom.
Would be interesting to know how much the headings are used, and the undo and redo buttons.

We have some stats on WordPress.com, but they include all the different editors we have so they're kind of hard to extract... What information are you specifically interested in finding out? Bold, italic, and links are generally highest, with lists and blockquotes next. Center and left alignment are also relatively high, but it's hard to know whether people are using that for text or for images. As far as I can tell, we don't have information on individual headings.

Undo/redo are relatively low, but I also think that the people who need those buttons most — new users, or users unconfident with tech who don't use keyboard shortcuts — are least likely to find them hidden in the kitchen sink.

[iseulde]

Related:

#31441

Consider automatically formatting certain patterns inside TinyMCE

[afercia]

One more argument to discourage the use of strikethrough is that people tend to use it unsemantically. The <del> element is meant to mark deletion of text as you would do in document revisions. Also, the visual and text editors produce a different markup:

TinyMCE:
<del>my text</del>
Quick Tags:
<del datetime="2015-05-01T21:53:25+00:00">my text</del>

notice the datetime attribute should be used only to mark when the document revision was done.

[mrwweb]

I'm really hoping this ticket can get some new love! I'm ​repping for it on the ​4.7 kickoff thread.

While I'm here, one thought on the color picker: I will forever be for just removing it, but if that's not an option, what about removing all colors that would produce insufficient contrast with a white (or near white, #eee?) background. This is hardly foolproof, but it would address my personal primary concern about the color picker for a vast majority of sites.

[hugobaeta]

@mrwweb YES! So glad to see this get attention. I'm game to firm a plan for this.

Regarding your idea for colors, I think it would be hard to predict what the background is for the text in the them - so calculating contrast against white might not be relevant.

I think it might be better to have a strategy for two release cycles:

• 4.7 - We reorganize the toolbar, move things up (heading selector for example) and other down (colors, etc)
• 4.8 - If we can prove the ones we moved down have very little usage, we might have a case for removing them entirely from the editor.

What do you think?

[mrwweb]

I think it might be better to have a strategy for two release cycles:

Yes. Two at a minimum.

• 4.7 - We reorganize the toolbar, move things up (heading selector for example) and other down (colors, etc)
• 4.8 - If we can prove the ones we moved down have very little usage, we might have a case for removing them entirely from the editor.

How do we judge impact sans actual "phone home" data? Forum posts? There is an ​800+ post thread of responses to the new .com editor. That may be a good place to start reading.

[celloexpressions]

I think we have enough of a consensus that there's room for improvement here that we can move forward with substantial changes for 4.7. Re-reading the discussions above, I'm not sure that we would need to spread the changes over two releases, necessarily. Other than text alignment, the ones we're considering removing are already in the kitchen sink. Text color may be harder to justify removing, although I'd certainly like to see it become plugin territory.

Here's a summary of what sounds like the current changes:

• Move the headings selector to the top row, at the front
• Remove heading 1 from the headings selector
• Remove align-left, center, right, and justify (or maybe move them to the kitchen sink and only remove justify? the image alignment toolbar has been around for a while now, so we probably don't need these for that any more)
• Remove underline, other than the keyboard shortcut
• Consider removing text color (currently in the kitchen sink)
• Consider adding a code button and/or a table button, probably best handled in separate tickets after the above changes are made

Can we get a +/- on those changes (maybe in the next design meeting?)? Who would be interested in making an updated patch?

If we remove everything we're considering for removal, we're getting close to a point where we could almost do without a kitchen sink. If undo/redo move up, there would be much less in the kitchen sink than the top line after the changes are made. Something to think about.

[azaozz]

Replying to celloexpressions:

Here's a summary of what sounds like the current changes:

• Move the headings selector to the top row, at the front
• Remove heading 1 from the headings selector
• Remove align-left, center, right, and justify (or maybe move them to the kitchen sink and only remove justify? the image alignment toolbar has been around for a while now, so we probably don't need these for that any more)

From what I've seen, Align Center is usually the third most used button in the editor, after Bold and Add Link, and before Italic.

• Remove underline, other than the keyboard shortcut
• Consider removing text color (currently in the kitchen sink)
• Consider adding a code button and/or a table button, probably best handled in separate tickets after the above changes are made

As per earlier discussions in #6331 a Code button would be helpful only to a small part of the users. For a while now we've had the Ctrl/Cmd + Alt + X shortcut that wraps the selection in <code>.

A Table button will definitely be more useful, but we need to fix how wpautop handles tables first. The ​Formatting component needs maintainers, everybody is welcome.

Can we get a +/- on those changes (maybe in the next design meeting?)? Who would be interested in making an updated patch?

+1 to making any changes after (extensive) user testing and research. This is one of the most used and perhaps most sensitive places in WordPress and even a small change can cause problems for many many users. I hope we can use some of the info and experience from making the Calypso editor.

If we are able to reduce the number of buttons, perhaps we can get rid of the "Toolbar toggle" and show all on the same line. Even just that will be a big improvement imho.

[mrwweb]

I'd love to remove alignments too, but my gut feeling was inline with what @azaozz said: people use these too much to remove (there might also be some l10n issues with rtl languages?). Removing full justification, though, still seems like a good idea!

I agree that code seems too niche to add.

Would adding tables encourage using tables for layout? That's mostly what I see people do with those buttons... It makes me nervous to add them.

Finally, a few other specific potential changes:

• Can we remove the left/right indent buttons for desktop devices? I believe they're only intended for list indentation which is accomplished via TAB / SHIFT + TAB. That's not an option on mobile, but they seem duplicative on desktop.
• I've wondered about moving blockquote into the formatselect since it parallels headings and paragraphs more than the other formatting buttons. That would then be one less button to fit in the editor.
• I would love to see a switch from formatselect to styleselect, since it's easier to extend and might encourage developers to do more with custom CSS classes.

@celloexpressions, I think the idea behind splitting across releases is to hide buttons before removing them altogether. That would make it easier to back out of these changes if people run into issues. That said, given the existing of TinyMCE Advanced and other similar plugins, "plugin territory" seems to be a very viable option for most buttons that get removed.

[iseulde]

Some thoughts...

• I would definitely move the headings up, and maybe remove H1. Something a bit more drastic, but we could shorten this to a select field like H ▾ with long text in the dropdown, and separate preformatted. When this is a normal select element it would also be a lot better on mobile.
• If align centre is used so much, I wouldn't move this down. For LTR, we could move align left down though, as the other two can be visibly toggled to align it left again. The opposite for RTL. If align right is barely used we could move it down too.
• Unlink is something that can now be done inline, but this button remains useful for unlinking selections at the moment. I think this is rare though, so this one could be moved down too.
• How much is the more tag used?

@mrwweb The reason blockquote is not part of formatselect is that you can have headings and preformatted text inside it. But you can't have nested headings and so on.

[iseulde]

The screenshot above only moves buttons.

• Headings go up. Unlink, left align and right align go down.
• Undo, redo and link move more to the left.
• Vertically link, list tools and align tools are grouped.

[iseulde]

Above screenshots: example of shorter heading select, and using a select element. Not so sure about making it shorter though, that could potentially be really confusing. Using a select element is a nicer experience on iOS at least.

[azaozz]

wp-test-tinymce-toolbars.php is a small plugin that can be used to test different toolbars configurations. The buttons are set "manually", by copying and pasting from the list of available buttons.

[mor10]

Just adding my voice here to show support for some ideas:

1. Moving formatselect to the first line of options has been on my request list for as long as I've used WordPress. It may be the most important feature in the editor to ensure proper semantic structure within posts and pages.
2. Removing H1 in formatselect is a good idea except for the few cases where a theme dev does something unusual that requires multiple H1s in a post/page. Also worth considering here are page builders and future things like page and post components. I know the whole "how many H1s can one have on a page" question is a huge war in the a11y and standards communities, but I have seen valid cases for both restricting H1 to a single instance and using it multiple times throughout a view. My proposal would be to disable it by default, and then provide a filter theme / plugin devs can use to reintroduce it where necessary.
3. I oppose removing any of the buttons currently in the editor because a) people (devs and users) rely on them, and b) they all serve a relevant function. We can argue until the cows come home about the value of each of the existing buttons, but in the end what we have is an already heavily pruned list of features that people are used to. Further reduction of the list doesn't seem to improve UX in any significant way in my opinion.
4. Reordering and weighting of the features would provide great UX improvements. Personally I would make the top (always-on) row display as follows: 1. formatselect, 2. bold, 3. italicized, 4. strike through, 5. underline, 6. unordered list, 7. ordered list, 8. blockquote, 9. link, 10. unlink, 11. <hr>, 12, <!-- more -->, 13. kitchen sink toggle.
5. Specifically to the question of Underline: An underline is semantically different from an underlined link, functioning as a further emphasis. You can underline normal, bold, and italicized text as well as text links. Theme developers can and should style a standard underline in a different way from a link underline. They should also ensure a link is not solely signified by an underline.
6. @iseulde, I understand the idea of reducing the width of formselect by only displaying "H", but this field is already somewhat mysterious to the end-user, and I fear such a change would make it ununderstandable. That said, I also think providing some form of context to explain this field would improve UX so...
7. Any removal of a feature, to be provided only as a shortcut, is effectively a full removal of the feature. Very few users ever look up the shortcuts list, and those who rely on these features will not know to look for them in the shortcuts. If a feature is not visible in the UI, the user will assume the feature does not exist. This is why huge applications with hundreds of features allow the user the option of customizing their toolbar to include the features they want.

[azaozz]

Replying to mor10:

Sorry I didn't explain this here but I made the above plugin so changes to the editor buttons can be tested easily. You can modify what buttons are shown and the ordering, then even upload the modified plugin here so other can test it. There is a list of all supported buttons in the plugin source.

Currently the plugin changes the buttons to what iseulde proposed. To modify it, simply rearrange or remove the button names from the two arrays.

[mor10]

Replying to azaozz:

Replying to mor10:

Sorry I didn't explain this here but I made the above plugin so changes to the editor buttons can be tested easily. You can modify what buttons are shown and the ordering, then even upload the modified plugin here so other can test it. There is a list of all supported buttons in the plugin source.

Currently the plugin changes the buttons to what iseulde proposed. To modify it, simply rearrange or remove the button names from the two arrays.

Oh cool! I'll do that. Thank you for the info Andrew.

[mrahmadawais]

Replying to azaozz:

Replying to mor10:

Thanks for the info Andrew! I'd love to participate by contributing via that plugin.

Moreover, Morten I strongly agree with the points you raised I came here to talk about exactly the same arrangement and how removing certain buttons would do more harm than good. But after reading your comment I feel that's all I need to say.

[mrahmadawais]

Well, here's what I propose! The arrangement is shown below and I have added the new plugin file.

Minimal

Full

FormatSelect has no Heading 1

I write/edit about 50K words every single week, and this arrangement would mean I could rely on the Minimal version of the above screenshots. Would really help.

[mrahmadawais]

Icon arrangement proposal!

[celloexpressions]

I would be okay with the proposal from @mrahmadawais if the center-align button were moved down with the other alignment buttons and the indent/outdent buttons were kept on the top level after lists. I would also prefer for underline to stay in the second row, since it's not semantic and it's there now.

We could do surveys and maybe user tests but it's going to be extremely difficult to quantitatively determine what the best approach is. I don't know how much we could pick up from user testing here, since individuals have bias and any test steps will carry bias in the tools that they direct a user to use. We'll likely end up have to make a decision without that information, and as the ticket initially proposed, basing it largely on semantics seems logical (starting with headings, then emphasis, etc.).

[EusebiuOprinoiu]

This is my current and ideal layout for the MCE Editor that I made with TinyMCE Advanced. The first row contains the buttons that I use on a daily basis and the second one those that I rarely use. Everything else was removed.

I believe colors and font sizes don't have a place here because all they do is allow people to ruin even the best-designed themes.

I am also a firm believer the H1 Heading doesn't have a place here as well. I saw many people using it multiple times in their post because "the text was bigger". Only titles should be H1 and this is done by the theme.

[bfintal]

It is possible to have a page (doesn't apply to posts) without a title. In those cases it is left to the user to "design" the title and wouldn't be able to add an H1 anymore with the suggestions. While I agree that H1 shouldn't be used more than once, maybe we could just leverage that and hide the H1 if 1) there is one already in the content and 2) the post being edited is a page (post_type). This suggestion might be a stretch, but I'm just throwing this idea out there in case there are others who find it useful.

@celloexpressions and @mrahmadawais I agree that the center button should be readily accessible there. But what if the center button was moved to be beside the other alignment buttons when in full view?

[mor10]

Replying to bfintal:

It is possible to have a page (doesn't apply to posts) without a title. In those cases it is left to the user to "design" the title and wouldn't be able to add an H1 anymore with the suggestions. While I agree that H1 shouldn't be used more than once, maybe we could just leverage that and hide the H1 if 1) there is one already in the content and 2) the post being edited is a page (post_type).

This is what I was referring to above: If the theme requires an H1 in certain circumstances, there should be an optional filter to activate it when appropriate.

[mrahmadawais]

Replying to bfintal:

It is possible to have a page (doesn't apply to posts) without a title. In those cases it is left to the user to "design" the title and wouldn't be able to add an H1 anymore with the suggestions. While I agree that H1 shouldn't be used more than once, maybe we could just leverage that and hide the H1 if 1) there is one already in the content and 2) the post being edited is a page (post_type). This suggestion might be a stretch, but I'm just throwing this idea out there in case there are others who find it useful.

Something like this? Obviously better designed. Just to make sure users do NOT keep adding h1's.

@celloexpressions and @mrahmadawais I agree that the center button should be readily accessible there. But what if the center button was moved to be beside the other alignment buttons when in full view?

While having the center button with other align button makes all the sense, it's just used a lot and having it in the primary toolbar is important. But putting other align tools there is wasting space since other important elements can be there.

[bfintal]

Building upon the idea:

Minimal — same as above

Full — center button moves to the other alignment buttons for grouping

FormatSelect has no Heading 1 — but it will still have an H1 only if content (in the editor) doesn't yet have an H1 & the post is of post_type page (and maybe a filter too)

A concern would be that the Toggle Toolbar and its neighboring buttons would move once it is toggled.

[EusebiuOprinoiu]

I don't think it's a good idea to separate the alignment buttons. People use them all the time and separating them will only bring confusion and frustration. (Related buttons should be grouped together)

I also don't like the idea of displaying the headings out of order. Either hide de H1 heading and allow developers to bring it back using a filter or leave it as it is.

[Elhisai]

+1 for keeping align buttons together, they're three different variations on the same parameter,

about strike-trough, I know some (most?) users doesn't use it the way html standards say they should, but it doesn't mean they don't have a valid use case so maybe the solution is to translate it in html with a class and not a semantic tag and keep it on the second line

[EusebiuOprinoiu]

I gave it some more thought and I think @mor10 has a point about not removing buttons. Even though I find some of them useless, there is no harm in keeping them on the second row.

However, I still believe allowing users to hardcode colors is a mistake. They might force a color that looks good with their current theme at the time they write their content, but as soon as they do a theme change, everything will be most likely a mess. ( That's why the Text Color button is the only one I removed )

I also believe the H1 Heading should be disabled by default, as mentioned before.

That being said, this is my proposal:
https://core.trac.wordpress.org/attachment/ticket/27159/wp-test-tinymce-toolbars.3.php

[siriusly]

Why not just allow site admins to decide which tinymce buttons should be available for users in settings? I agree that some are "misused," underline being the top example, but removing options like alignment & text color could really hinder functionality for designers. Improving user experience is the responsibility of a site's designer. I already edit the color palette to limit options for editors, for example, and I don't want to have to add another (bloated) tinymce plugin every time I create a site. Disabling h1 by default creates problems when using "administrative" h1 page/post titles that are hidden from search engines (and the SEO friendly h1 resides in the content div). Sites with deep structures often need to do this to keep structures organized. Seems like there's a little too much "hey, we're smarter than you so we're going to limit your options like Microsoft does" in this trac. Thanks for listening.

[mrwweb]

Replying to mor10:

My proposal would be to disable it by default, and then provide a filter theme / plugin devs can use to reintroduce it where necessary.

The formatselect can already be filtered in ​tiny_mce_before_init The theme omitting H1 feels edge-casey enough that this seems sufficient.

3. I oppose removing any of the buttons currently in the editor because a) people (devs and users) rely on them, and b) they all serve a relevant function. We can argue until the cows come home about the value of each of the existing buttons, but in the end what we have is an already heavily pruned list of features that people are used to. Further reduction of the list doesn't seem to improve UX in any significant way in my opinion.

At least in my mind, removing buttons can improve the UX for the editor OR site visitor in cases. The full justification is the easiest example as this undeniably decreases the readability of text.

5. Specifically to the question of Underline: An underline is semantically different from an underlined link, functioning as a further emphasis. You can underline normal, bold, and italicized text as well as text links. Theme developers can and should style a standard underline in a different way from a link underline. They should also ensure a link is not solely signified by an underline.

I don't disagree in theory but I almost never see themes implementing a nice underline style that is visually distinct (I have no doubt yours does! 😜). Further, I most commonly see people underline headings and then I see users frustrated by trying to click them. This is one of those cases where I feel like theory loses out to practice.

And similar to above, the mce_button filters are super easy to use. I think it would be positive to put some pressure on themes to only include an editor button if they provide styles to warrant it. (This probably has some pretty bad theme-switching experience downsides, but then again, so does changing font colors...)

6. @iseulde, I understand the idea of reducing the width of formselect by only displaying "H", but this field is already somewhat mysterious to the end-user, and I fear such a change would make it ununderstandable.

Strongly agree.

7. Any removal of a feature, to be provided only as a shortcut, is effectively a full removal of the feature...If a feature is not visible in the UI, the user will assume the feature does not exist.

...unless they were "Power Users" or previous users. My own experience working with people suggests that removing buttons isn't missed unless they knew they were there before. Given that much of the concern over removing buttons is regarding existing users, this feels like an acceptable alternative that improves the experience for new users.

[mrwweb]

Let's keep up the momentum here! I want to propose a conservative agreement milestone to serve as the new baseline and then offer a few more ambitious changes that I think we should strongly consider.

---

Changeset 1: Apparent Consensus at the Moment

• It seems that everyone agrees to move formatselect to first position and remove Heading 1.
• Nearly everyone seems to agree that removing alignjustify makes sense since it looks bad, has uneven browser implementation, messes with themes, and is bad for readability.
• Alignment buttons likely have high-enough usage that they need to stay in editor.

Using those assumptions and then taking a few cues from the WordPress.com editor (which we're certainly hoping has some testing behind it and there's an argument for consistency), I got to this:

The plugin file is also attached (mrw-wp-test-tinymce-toolbars.php). This isn't as drastic as I'd like, but it does start to make positive changes and I think we can all agree on it.

---

Changeset 2: Additional Possible Changes with a lot of Support

If not too many people disagree, I would propose we also make the following changes to the pictured editor:

• Remove underline
• Remove forecolor (font color)
• Replace formatselect with styleselect. styleselect is way more powerful and provides a CSS-driven way for theme authors to easily register Custom CSS classes for content that can be styled with editor-styles.css. I think adding styleselect while removing forecolor could honestly be described as a replacement and improvement. Rather than people making text red, a theme can now offer a "Warning" style. You can see ​screenshots of `styleselect` in use from a plugin I maintain. This may be worth discussing with the theme team, as they could use it to allow people to style the pull quote design in Twenty Seventeen. Lots of themes come with custom classes (e.g., for link buttons) that could immediately benefit from this addition.

---

Let's Go For It!

We had initially talked about doing this in two phases, but it seems clear now that changing the editor multiple times will cause more confusion rather than less. I also think it's become clear we need to be conservative as there are lots of valid edge-cases with some of theme buttons (alignment and indenting in particular). That said, the point of this is to encourage better (semantic) formatting and reduce the use of problematic formatting (unsemantic, poor readability, poor usability, or bad theme-switching). I don't want to be reckless, but I still want to push for those second set of changes to push formatting forward in WordPress.

(For responses, please make sure you at least address changeset one so we can quickly establish if that can serve as the baseline for remaining work.)

[mrwweb]

hopefully this serves as a milestone for progress

[hugobaeta]

@mrwweb First off, I'm giving you my +1 for Changeset 1, and a partial for Changeset 2. Agreed to removing underline and forecolor, as my original ticket suggests. The only part of the Changeset 2 I don't understand is the formatselect replacement with styleselect. Can you expand on this a bit?

[hugobaeta]

Regarding the conversation around the headings in formatselect, I strongly insist on not including H1 in there. We can even call <h2> "Heading 1" (actually makes a lot more sense for the user), but what is added in the editor is an <h2> tag. Heading 1 is simply a reference to the hierarchy - the first level of heading in the document. Semantically that would be <h2>. Does this make sense to you? This is probably a separate ticket, but I've seen a lot of comments around this and wanted to bring some UX logic into this discussion.

[mrwweb]

Replying to hugobaeta:

I don't understand is the formatselect replacement with styleselect. Can you expand on this a bit?

Documentation for working with styleselect can be found on the Codex: ​TinyMCE Custom Styles

It allows additional styles to be defined and applied by the editor. That can mean applying classes (with the option to specify what elements that class can apply to) or inserting block-level elements like a blockquote (which doesn't always work super well). Real-world examples I use it for all the time:

1. Create a "Pull Quote" style that wraps selected text in a blockquote with the class "pull-quote"
2. Apply a "Button" class to a link when selected

It also has no problems with Headings and pre, so can replace AND extend formatselect. Probably the biggest downside is that the dropdown always says "Format" and not the actual format (e.g. Heading 2, Paragraph) of the text containing the cursor.

[mrwweb]

Replying to hugobaeta:

Regarding the conversation around the headings in formatselect, I strongly insist on not including H1 in there. We can even call <h2> "Heading 1" (actually makes a lot more sense for the user), but what is added in the editor is an <h2> tag. Heading 1 is simply a reference to the hierarchy - the first level of heading in the document. Semantically that would be <h2>. Does this make sense to you? This is probably a separate ticket, but I've seen a lot of comments around this and wanted to bring some UX logic into this discussion.

Funny. I almost suggested that too. I think that's a new ticket, if for no other reason than to keep the wordsmithing thread separate from this ticket. I have ideas that I'll be happy to contribute on a new ticket.

[hugobaeta]

Replying to mrwweb:

Documentation for working with styleselect can be found on the Codex: ​TinyMCE Custom Styles

I'd say this belongs in a separate ticket/scope, as it adds a series of new concepts that need a bit more thinking and cross-team coordination (themes team, for example).

So, I say everything else is a go:

• move formatselect to first position and remove Heading 1.
• remove alignjustify
• move the rest of the alignment buttons to the kitchen sink
• Remove underline
• Remove forecolor (font color)

@mrwweb could you create an updated patch with these?

@melchoyce @helen @iseulde @azaozz @karmatosed - do we all agree with this patch being committed?

[EusebiuOprinoiu]

I don't like the idea of moving the alignment buttons to the kitchen sink. They are used a lot and putting them there is going to cause a lot of clicking on the button that toggles the second row.

Like I said before, this is my ideal order of buttons. At least on the first row. I don't really care what's on the second one.

[melchoyce]

Replying to hugobaeta:

Replying to mrwweb:

Documentation for working with styleselect can be found on the Codex: ​TinyMCE Custom Styles

I'd say this belongs in a separate ticket/scope, as it adds a series of new concepts that need a bit more thinking and cross-team coordination (themes team, for example).

So, I say everything else is a go:

• move formatselect to first position and remove Heading 1.
• remove alignjustify
• move the rest of the alignment buttons to the kitchen sink
• Remove underline
• Remove forecolor (font color)

do we all agree with this patch being committed?

For the most part. I think we should keep the alignment icons grouped together, whichever row they end up. Also against removing font color based on the last time we tried to remove it. From what I remember, we removed it in a major release and then re-introduced it in a subsequent point release because it caused significant confusion and uproar.

[hugobaeta]

Replying to melchoyce:

For the most part. I think we should keep the alignment icons grouped together, whichever row they end up.

I agree. I thought that was implied in my comment and @mrwweb's comment. Remove justifytext and move the other three down to the kitchen sink.

Also against removing font color based on the last time we tried to remove it. From what I remember, we removed it in a major release and then re-introduced it in a subsequent point release because it caused significant confusion and uproar.

I'm still strongly agains this feature, mostly because it adds non-semantic inline styles and markup to the database. If we don't remove it, then at least we should change it to make it better (add css class instead of inline styles, and add css for it to the head of the page). Maybe move this to a separate ticket if so?

Updated list:

• move formatselect to first position and remove Heading 1.
• remove alignjustify
• move the alignleft, aligncenter, and alignright to the kitchen sink
• Remove underline

Trying to get a set of changes we can all agree and have it committed so we can move on to creating other tickets to tackle the remaining features.

[melchoyce]

Replying to hugobaeta:

Replying to melchoyce:

For the most part. I think we should keep the alignment icons grouped together, whichever row they end up.

I agree. I thought that was implied in my comment and @mrwweb's comment. Remove justifytext and move the other three down to the kitchen sink.

Cool :thumbs-up:

Also against removing font color based on the last time we tried to remove it. From what I remember, we removed it in a major release and then re-introduced it in a subsequent point release because it caused significant confusion and uproar.

I'm still strongly agains this feature, mostly because it adds non-semantic inline styles and markup to the database. If we don't remove it, then at least we should change it to make it better (add css class instead of inline styles, and add css for it to the head of the page).

For what it's worth, I totally agree with you.

Maybe move this to a separate ticket if so?

Good idea.

[celloexpressions]

I'm +1 for everything in 68. I don't remember specifics of the previous attempt to remove the text color button, do you have a link to any previous discussions there @melchoyce?

As I had mentioned before, the strongest argument we can make for any changes is semantics. The alignment buttons are not semantic, but are apparently used enough to keep them for now with the exception of justify, but move to the kitchen sink. Underline is not semantic and headings are perhaps the most semantic option in the editor, and thus should be at the top, in front. Color isn't semantic either, but is also hypothetically used enough (do we have any numbers?) that a separate ticket might be justified.

[mrwweb]

As requested, I split some issues into new tickets:

• #38049 - Rename Headings in TinyMCE
• #38050 - Replace formatselect with styleselect in TinyMCE

As I mentioned here, I think #38050 could potentially add to the justifications for removing Color from the editor, so it's quite closely related to these changes.

[mor10]

There have been some questions about valid use cases for the underline functionality in the WordPress editor. For reference I've created this example of a common practice in some circles, in particular academia. I have no numbers to back this up, so the example is anecdotal.

Here, the underline is used in conjunction with emphasized text and links to draw attention to a section within the text without emphasizing it further. Note the link is styled to appear different from the underline.

It appears I am the only one defending this feature, and I am not going to fight it if the feature is removed, I only provide this example to show a legitimate use case that is established and worth taking into consideration.

[iseulde]

Here, the underline is used in conjunction with emphasized text and links to draw attention to a section within the text without emphasizing it further. Note the link is styled to appear different from the underline.

What do you mean by "without emphasizing it further"? It is underlined just to draw attention (to highlight)? If bold or italic don't work, maybe <mark> could work well here? This usually has a background colour, but sometimes underline. Any reason it can't be bold?

I don't remember seeing underlines in academic writing on philosophy in the form of web pages. Could you provide any examples? Thinking about plato.stanford.edu etc.

[mor10]

Replying to iseulde:

What do you mean by "without emphasizing it further"? It is underlined just to draw attention (to highlight)? If bold or italic don't work, maybe <mark> could work well here? This usually has a background colour, but sometimes underline. Any reason it can't be bold?

<mark> may well work, but it's not readily available to the end-user. The example shows a text that is being highlighted by the person quoting it, whereas an emphasis or strong emphasis comes from the original author. Different contexts.

I don't remember seeing underlines in academic writing on philosophy in the form of web pages. Could you provide any examples? Thinking about plato.stanford.edu etc.

I have to go digging.

[hugobaeta]

Replying to mor10:

<mark> may well work, but it's not readily available to the end-user. The example shows a text that is being highlighted by the person quoting it, whereas an emphasis or strong emphasis comes from the original author. Different contexts.

Why do you say it isn't readily available to the end-user? it seems to be well supported... ​https://developer.mozilla.org/en-US/docs/Web/HTML/Element/mark

According to MDN: "The HTML Mark Element (<mark>) represents highlighted text, i.e., a run of text marked for reference purpose, due to its relevance in a particular context." They also note: "Do not confuse the <mark> element with the <strong> element. The <strong> element is used to denote spans of text of importance in context of the text, when the <mark> element is used to denote spans of text of relevance to a different context."

I'm not 100% sure, but seems like the right context for it, right @mor10 ?

[mor10]

Replying to hugobaeta:

Why do you say it isn't readily available to the end-user? it seems to be well supported... ​https://developer.mozilla.org/en-US/docs/Web/HTML/Element/mark

"Not readily available to end-users" as in "there is no button for it in the WordPress toolbar, so unless you know about the element and how to mark it up, you can't use it."

I'm not 100% sure, but seems like the right context for it, right @mor10 ?

Yes, it would serve that purpose. Which makes me wonder if maybe we should be replacing the Underline button with a Highlight button. After all, highlighting has become really popular on Medium etc.

[melchoyce]

Replying to celloexpressions:

I'm +1 for everything in 68. I don't remember specifics of the previous attempt to remove the text color button, do you have a link to any previous discussions there @melchoyce?

Looks like I was thinking of #27359.

[celloexpressions]

Replying to melchoyce:

Replying to celloexpressions:

I'm +1 for everything in 68. I don't remember specifics of the previous attempt to remove the text color button, do you have a link to any previous discussions there @melchoyce?

Looks like I was thinking of #27359.

Oh yeah, that rings a bell. We should definitely expect complaints (potentially a vocal minority) if we remove any buttons. However, if there are solid reasons, such as semantics, we have a good argument for the changes and those that really need those buttons can add them with plugins.

[mor10]

Related: #38115

[mrahmadawais]

Hey, guys! Why is there no keyboard shortcut for Normalizing the text (heading → paragraph) in WPEditor? Any specific reason? There should be one. Something like CTRL + ALT + 0.

[afercia]

Replying to mrahmadawais:

Hey, guys! Why is there no keyboard shortcut for Normalizing the text (heading → paragraph)

CTRL + ALT + 7 does it :)

[celloexpressions]

I think we have consensus on moving things around, at least, and removing the lesser-used unsemantic buttons that are already in the kitchen sink per 71. Can someone make a patch for that so we can finally get this in?

It's time to make a decision here. Otherwise we'll keep talking in circles for years without every making any improvements.

[jorbin]

I am assinging this to @hugobaeta in part due to him being a design team leader and also coming up with the idea that things are going to roll with. This still is in danger of not making 4.7. I would like to see a patch in or ready to go in the next week.

[hugobaeta]

I'd like to see this ticket move along, so circling back to the last round up of proposed changes, this is the list:

1. move formatselect to first position on top row and remove Heading 1. (And consequently allow for #38049 and #38050 to move forward as well) - The importance of this select is too great to be buried in the kitchen sink.
2. move the alignleft, aligncenter, and alignright to the kitchen sink - these buttons generate non-semantic inline styles (<p style="text-align: right;">), but since they seem to be popular, until we can figure out another semantic solution for these, they should at least be moved out of sight for new users.

• remove alignjustify - same justfication as above, yet in this case theres no friction for removal.
• Remove underline - again, like others, the underline button introduces non-semantic inline styles (<span style="text-decoration: underline;">) and introduces potential accessibility issues when comparing with links. The <mark> html tag has the semantic meaning this tried to convey, and should be used instead - I created a separate ticket for that #38315

I'd really really like to push the removal of the text colors button entirely, and leave it to plugin territory (as @mrwweb said, #38050 might help push that too), but we should move that one over to a new ticket. So that list above is what I'd like to see in a patch for 4.7 inclusion.

This is the intended outcome for now:

Does anyone have bandwidth to make a patch for this within the next few days? If we don't get something in before next week's core chat, this likely won't make it into core for 4.7. cc/ @mrwweb @iseulde @azaozz

[celloexpressions]

+1 for 93 although I let someone else patch as I don't have time or know where to look.

[akibjorklund]

27159.diff​ contains the changes suggested in 93.

[EusebiuOprinoiu]

I see the alignment buttons add inline styles only for text. Can't they be modified to add classes, just like they do for images?

[hugobaeta]

Thank you @akibjorklund for making that patch! Can we get a committer to review the patch and merge it to trunk? cc/ @iseulde @azaozz

@EusebiuOprinoiu I believe that should be a discussion for another ticket, since that introduces the issue of theme dependance – like align classes for images already do, so it wouldn't be too bad, except when failing users expectations.

[azaozz]

Replying to hugobaeta:

2. move the alignleft, aligncenter, and alignright to the kitchen sink - these buttons generate non-semantic inline styles (<p style="text-align: right;">), but since they seem to be popular, until we can figure out another semantic solution for these, they should at least be moved out of sight for new users.

As far as I've seen the align-center button is the third most used button in the editor, after bold and link. Even if we had only three buttons in the editor, one of them would have been align center. Don't think it is a good idea to move it to the second row.

For the UX it doesn't matter how it works or what kind of HTML it generates. We can try to come up with a better way for text alignment to work, although not sure what that may be.

So the options are to either keep the alignment buttons where they are or separate the align-center button and move align-right and align-left to the second row. The problem with separating them is that they loose context. I haven't seen that in any editor, anywhere.

• Remove underline - again, like others, the underline button introduces non-semantic inline styles (<span style="text-decoration: underline;">) and introduces potential accessibility issues when comparing with links. The <mark> html tag has the semantic meaning this tried to convey, and should be used instead - I created a separate ticket for that #38315

I'd rather not remove underline but replace it with mark. Think better to use #38315 for that.

Does anyone have bandwidth to make a patch...

Patch is very easy to make. But generally removing things or moving things around doesn't improve UX. We need to clearly prove the UX is better after rearranging the buttons. That's what is missing :)

[EusebiuOprinoiu]

I don't like the idea of moving the alignment buttons either. From my experience they are used a lot and moving them on the second row is going to cause frustration for many users.

On the other hand, the Horizontal Line and Strikethrough buttons are rarely used and they can be placed in the kitchen sink without problems. Besides, they kind of break the visual hierarchy on the first row because of their small height.

My proposal is to arrange the buttons like you see in the mockup below.
The first row contains all the buttons used on a daily basis by the majority of people, managing to keep a visual symmetry at the same time. ( Buttons no longer seem to be randomly placed like they are right now )

PS: For now, I removed the Underline button, but if you plan on replacing it with Mark, even better.

[EusebiuOprinoiu]

Here's the code used to generate the mockup I posted above.

[celloexpressions]

As I've stated several times on this ticket, we can talk in circles for years on this. The reasons behind making changes are to improve semantics, which in turn improves the end-user experience with content, particularly around accessibility. I don't see any reasonable way that we could do user testing here without any bias. WordPress should make the tools that provide the best experience of content for visitors the most prominent. Switching the placement of headings with alignment buttons absolutely works toward that goal.

If the center-align button is the 3rd-most-used, I can only guess that switching the location of the format select and alignment buttons would cause actual headings to be used where center-aligning is currently being used for, again guessing here, either "headings" or "blockquotes." If there were a semantic meaning for the center-align button, what would it be used for? Do we have any information of how it's being used, if it is in fact the 3rd-most-used button? Where are these stats from, is there potentially a bias there? I don't see a clear argument for keeping alignment buttons this prominent.

We need to make a decision here. I'm in favor of encouraging more semantic markup, and based on previous discussion in the design meeting, it sounded like there is generally a consensus around most of what's in 27159.diff​.

[azaozz]

Replying to celloexpressions:

As I've stated several times on this ticket, we can talk in circles for years on this.

Exactly, that's why I made the small plugin in wp-test-tinymce-toolbars.php, to make it really easy to test.

I don't see any reasonable way that we could do user testing here without any bias.

Absolutely disagree. If everybody that commented on this tickets took the time to test the proposed changes on 4-5 people around them, we would have had at least a base to start with.

If the center-align button is the 3rd-most-used, I can only guess that switching the location of the format select and alignment buttons would cause actual headings to be used where center-aligning is currently being used for, again guessing here, either "headings" or "blockquotes."

I can see why moving format-select to be first in the top row is probably a good thing. I don't see any reason to move the alignment buttons. But this is just a guess and guessing is not good enough.

If there were a semantic meaning for the center-align button, what would it be used for?

Sorry but I don't follow. Are you saying that aligning things to the center is not semantic?

Do we have any information of how it's being used, if it is in fact the 3rd-most-used button? Where are these stats from, is there potentially a bias there?

Exactly, this is what is missing here. Don't think we can do a good job without having user data to base a decision on. It will be just (biased) guesswork, and that's not acceptable imho.

We need to make a decision here. I'm in favor of encouraging more semantic markup, and based on previous discussion in the design meeting, it sounded like there is generally a consensus around most of what's in 27159.diff​.

The only changed toolbar layout that is based on actual user data is in the Calypso editor on wordpress.com (see the above screenshots). I don't think we can just "copy" it as it was done with a bit different purpose. One of the high priorities there was to have parity with the "wp-admin" editor. But thinking it can at least be used as a "base".

[mrwweb]

I think we need to approach this like a mini feature project that involves research of other editors, a full inventory of the existing editor buttons (semantic-ness, valid use cases, UX/a11y problems), a clear goal for the project (by which to measure success in tests), and then user testing. I think most of the "talking in circles" (which is definitely happening) is from unclear goals and hitting walls on how to set up a user test that isn't just a survey of user preferences.

For a while, I wondered if making some incremental changes would be valuable, but I'd rather try to push this back and get it done right in one pass. (If we're going to make people mad, let's do it once and not twice.) So I'd vote for punting to 4.8. That would also let us make some progress on #38315, #38049, and maybe #38050.

To keep things moving forward, we have to find this mythical editor data. That will require help from an Automattician or two. @melchoyce? @hugobaeta?

[hugobaeta]

Replying to azaozz:

As far as I've seen the align-center button is the third most used button in the editor, after bold and link. (...)
For the UX it doesn't matter how it works or what kind of HTML it generates. (...)
So the options are to either keep the alignment buttons where they are or separate the align-center button and move align-right and align-left to the second row. (...)

The thing is, the user experience issue here is that we're giving the user rope for them to hang themselves (as we say in Portugal). Why should we encourage something bad? And aside from that, how do you know align-center is the third most used button - and most importantly, if that's true, why?

This decision is not to remove the align buttons, it's to move them out of sight in the hopes that new users don't fall on the same mistakes as seasoned ones.

I'd rather not remove underline but replace it with mark. Think better to use #38315 for that.

Again, we're mixing scopes: this ticket is about removing buttons who generate un-semantic code, that we consider ok to remove. Underline is the perfect example of that. So lets keep the removal on this ticket, and leave <mark> for the other.

Patch is very easy to make. But generally removing things or moving things around doesn't improve UX. We need to clearly prove the UX is better after rearranging the buttons. That's what is missing :)

@celloexpressions said it all in his comment above. There is no specific quantitative measure for UX in this ticket - we're making decisions to help users make better decisions. How you can test that without bias is beyond me. @karmatosed - do you have any thoughts?

I'd REALLY like to see this go in 4.7, and that means we need some consensus by tomorrow, before core chat, at the latest.

I still think there's HUGE value in a lot of what is being discussed here, and I don't mind compromising further if absolutely needed. So, here's another compromise:

Absolutely must for 4.7:

• move formatselect to first position on top row and remove Heading 1.
• remove alignjustify
• remove underline

Would be nice:

• move the alignleft, aligncenter, and alignright to the kitchen sink

Can we please at least commit a patch with the first three?

[azaozz]

Replying to hugobaeta:

I'd REALLY like to see this go in 4.7, and that means we need some consensus by tomorrow, before core chat, at the latest.

No, enhancements can be added prior to beta-1 which is scheduled for ​October 26, 2016.

I'm going to repeat what I said couple of months ago:

+1 to making any changes after (extensive) user testing and research. This is one of the most used and perhaps most sensitive places in WordPress and even a small change can cause problems for many many users.

I made the testing plugin with the hope that at least the people commenting on this ticket will do a little bit of testing. I did some very limited testing with five existing and first-time users. What I found out is pretty interesting: both existing and new users opened the second toolbar row (as soon as they found out it exists) and never ever closed it again. I even asked why they don't close it and the answer was that leaving it open is more convenient and they can see all available buttons.

I know these test results are extremely limited and cannot be used when making a decision, but they are an indication of what "real" testing may reveal. In this case it shows that moving buttons to the bottom row will have no effect on the usage of these buttons as they will still be visible at all times.

This super limited testing also indicated another (much bigger) problem: somebody mentioned this some time ago (think it was @mor10), around 20% of the WordPress users don't even know there is second editor toolbar, and some feel "pretty stupid" after discovering it. Think this is bad UX and something that can be fixed easily by having the second toolbar open by default, and fixing it is more important and will improve the UX for these 20% of users a lot.

In short: moving buttons to the top or bottom toolbar doesn't seem to work in the way many people think it works. It seems it's just going to be annoying for existing users as they are used to the existing locations. If we are going to risk "pissing off" several million people, lets do it after some solid proof that what we are doing is right, please :)

[celloexpressions]

The discoverability of the kitchen sink definitely needs improvement, but I don't think that changes here necessitate exploring that first. The question in this ticket is whether users should be able to easily generate unsemantic markup, which will in turn impact the experience of their visitors and their ability to have a good experience across different themes.

To encourage the most semantic markup possible, the format select should be the top-left, first option in the editor's buttons. Buttons that are semantically meaningless should be given lower priority and, within the current context of the kitchen sink, hidden by default. These buttons should also be removed if at all possible.

Testing doesn't make sense in terms of determining which buttons need to be used. Stats could help, but are difficult to interpret without context on how/why certain buttons are being used. We can't ask users testing to write something with formatting in the editor, because what we ask for would have a direct impact on which buttons they use.

[mrwweb]

@azaozz Can you describe the user testing you've done? (Setup, rough script, what you're specifically trying to learn, any other take-aways besides what you shared) I think getting specific would help us understand what type of testing you have in mind. I'm pro-testing, but have the same reservations as @celloexpressions. It's extremely dangerous to take a "this is for your own good, you just don't know it" approach to these change, but I think there's some truth to that in this case. The editor is a way to provide the appropriate tools to allow unknowledgable users make the best technical formatting decisions possible.

WordCamp Seattle is coming up soon. I'd be willing to try to do a bit of user testing during contributor day if we can all agree on a script/test.

[hugobaeta]

Again, I'm with @celloexpressions here. I think the excuse of testing is being used to avoid making a decision. For the three things I asked for (and I'm compromising greatly here from the initial idea), I don't see how any of those arguments make sense here.

• move formatselect to first position on top row and remove Heading 1.
• remove alignjustify
• remove underline

@azaozz

In short: moving buttons to the top or bottom toolbar doesn't seem to work in the way many people think it works. It seems it's just going to be annoying for existing users as they are used to the existing locations. If we are going to risk "pissing off" several million people, lets do it after some solid proof that what we are doing is right

I understand your intention here, but how is this even testable? You believe most people have the kitchen sink open. But you also contradict that by saying a lot don't even know a second row even exists. Moving formatselect to the top is logical, since it's such an important element that, according to you, a lot of people never even discover (and like @celloexpressions said, maybe explains why aligncenter is used so much). removing alignjustify and underline have been discussed enough, plus, again according to the idea that a lot of people don't even know there's a second row, removing them won't cause much harm anyway (plus we're introducing a potential replacement for underline in #38315).

@azaozz you also mentioned the whole problem of discoverability of the kitchen sink, but that does not belong in this ticket and is making this conversation even more complicated.

I'm all for testing things, but I also believe in decisions for the good of the user. We're definitely going around in circles and even though I understand your intentions, I don't think punting this is in the best interest of the user.

Again, all I'm asking for is three things:

• move formatselect to first position on top row and remove Heading 1.
• remove alignjustify
• remove underline

[azaozz]

Replying to hugobaeta:

I think the excuse of testing is being used to avoid making a decision.

Yeah, this is way I didn't want to post that here. Okay, lets not call it "testing", lets call it "observations" :) I did that for my own benefit only, to be able to justify to myself the proposed changes.

I'm going to repeat that again: I really really hope everybody that posted a comment here or is "watching" this ticket would do something similar.

@azaozz you also mentioned the whole problem of discoverability of the kitchen sink, but that does not belong in this ticket and is making this conversation even more complicated.

Well, technically... This ticket is about "Removing TinyMCE buttons to improve user experience" so lets remove the Toolbar Toggle (a.k.a. kitchen sink) button then! :)

Joking aside, agree that this belongs in a new ticket. Going to make one as soon as we have some means of (really) testing how many users keep the second toolbar row always open. If it turns out that most (more than 80%) of the users that know about that toolbar have it always open, I think the proper action would be to remove that button and have editor with two toolbar rows or merge the rows into one row that wraps around (whichever looks better in most cases). I'm sure there will be some "very vocal" opposition to something like that, but keeping an "almost dead" button in the toolbar doesn't make sense.

Again, all I'm asking for is three things:

• move formatselect to first position on top row and remove Heading 1.
• remove alignjustify
• remove underline

Okay, lets do this. Thinking (hoping) that not so many users will be upset if we leave the alignment buttons alone.

What do you think about moving the "Strikethrough" button to the bottom row for now, same as in the Calypso editor?

At the same time as this change I'd also like to commit #38315 (adds the <mark> element and a "Highlight" button, and #37278 (removes the "Unlink" button and changes to the same icon in the inline link toolbar). Thinking these three tickets compliment one another.

[melchoyce]

Well, technically... This ticket is about "Removing TinyMCE buttons to improve user experience" so lets remove the Toolbar Toggle (a.k.a. kitchen sink) button then! :)

Maybe we should. Want to drop your observations & feedback in #31132?

[mrwweb]

Replying to azaozz:

Again, all I'm asking for is three things:

• move formatselect to first position on top row and remove Heading 1.
• remove alignjustify
• remove underline

Yes yes yes. +1000.

What do you think about moving the "Strikethrough" button to the bottom row for now, same as in the Calypso editor?

At the same time as this change I'd also like to commit #38315 (adds the <mark> element and a "Highlight" button, and #37278 (removes the "Unlink" button and changes to the same icon in the inline link toolbar). Thinking these three tickets compliment one another.

I think that makes sense. Further, I'd urge keeping strikethrough and highlight together. They feel like a cohesive pair (de-emphasize/call out) similar to indent/outdent and link/unlink.

[mor10]

This talk about user testing being unnecessary concerns me greatly. We have sparse data on any of this, and we need to be cognizant that decisions here are being made mainly based on opinion. I say all this as someone who wants to see pretty much all the proposed changes.

This is the kind of change that could have benefitted from a wider community consultation, maybe in the form of a before/after screenshot being shared on a Make blog and social media to gather interest and prepare users for the upcoming change. Even with the best intentions and a better UI experience this will be a pretty jarring change for end-users and we will hear a lot of complaining from both users and trainers.

[karmatosed]

I mentioned this in Slack but feel worth adding to the ticket. In most cases I am the first to suggest user testing. This however is a complicated issue that easily has bias. I'm not saying it shouldn't have testing, I think the general feeling is yes we need feedback from this. However, user testing isn't the only form we can get that. If we have this in beta and as has been suggested, in a post, then the feedback there is our testing.

[EmpireOfLight]

Just spitballing, but what about an inline toolbar

[azaozz]

After today's discussion, the consensus is to go with:

• move formatselect to first position on top row and remove Heading 1.
• remove alignjustify
• remove underline

That makes the top toolbar quite longer. Also there is a LTR button added there when in RTL mode. Perhaps we can "copy" from the Calypso editor toolbars and move strikethrough and hr down too?

[azaozz]

Replying to karmatosed:

I mentioned this in Slack but feel worth adding to the ticket. In most cases I am the first to suggest user testing. This however is a complicated issue that easily has bias. I'm not saying it shouldn't have testing, I think the general feeling is yes we need feedback from this. However, user testing isn't the only form we can get that. If we have this in beta and as has been suggested, in a post, then the feedback there is our testing.

Agreed. I was trying to see any reactions when asking people to edit one post with the current toolbars layout, and another post with the changed one.

What surprised me in my super limited "observation" was that all five users didn't close the bottom row after using it. I also had to tell two of the three new users that there is a bottom row...

If this is the case for most users the buttons in the bottom row would actually be "higher priority" as they would be slightly closer when moving the mouse from the editor body to the toolbars.

[helen]

Replying to azaozz:

move strikethrough and hr down too?

I'm always surprised to see both of those up top, even as a person who uses hr from time to time. I say go for it.

[azaozz]

In 27159.2.diff:

• Remove alignjustify and underline.
• Remove H1 from formatselect.
• Move formatselect to the beginning of the top row.
• Move strikethrough and hr to the beginning of the bottom row.

(Screenshot above.)

[hugobaeta]

Thank you @azaozz! That's perfect! Please commit into trunk and I'll try to conduct a few tests! So happy to see this reach a resolution!!!!!

[azaozz]

In 38932:

TinyMCE: remove and rearrange some of the editor buttons to improve user experience.

Props hugobaeta, melchoyce, celloexpressions, mor10, iseulde, mrwweb.
See #27159.

[azaozz]

Left the ticket open so we can add any adjustments after beta.

Also, how about we remove the numbers from the heading drop-down? Starting with "Heading 2" looks quite strange and TinyMCE does a good job of applying the right styles to make previews in the drop-down. See the screenshots.

[azaozz]

Going to commit this so it gets in beta-1. Can always revert it if the numbers there are mandatory.

[azaozz]

In 38939:

TinyMCE: remove the numbers (2-6) after the headings in the drop-down. These are previews for the actual styling of headings in the editor.

See #27159.

[johnbillion]

[38939] reduces the clarity of the heading levels. Yes starting at 2 is weird, but having a clear heading hierarchy is important. This needs user testing if it's to stay in.

In addition, the removal of the heading numbers looks like it'll only work for English text, due to the hard-coding of Header in plugin.js.

[GaryJ]

Replying to azaozz:

In 38939:

TinyMCE: remove the numbers (2-6) after the headings in the drop-down. These are previews for the actual styling of headings in the editor.

And these visual previews are completely missed by screen reader users. How do they distinguish between heading levels now?

[azaozz]

Replying to johnbillion:

[38939] reduces the clarity of the heading levels. Yes starting at 2 is weird, but having a clear heading hierarchy is important.

Yeah, I agree. This is a compromise. I've seen few editors that don't show "heading levels". One is the GitHub editor. I've never ever seen any editor that has a hierarchical listing that starts with 2 or any other number but 1.

There are three choices:

• Start with Heading 2. This is bad UI imho. Haven't seen anything like it, ever. For "people in the know" it may be acceptable but what about for all the other people?
• Hack it a bit to make "Heading 1" insert h2. This is a bit hacky and slightly deceiving. The "people in the know" will probably be (unpleasantly) surprised to see the h2.
• Don't show numbers, rely on the font size and styles. The previews in TinyMCE are accurate there and show the headings as styled by the theme.

I've seen the third one used, and it seems to make most sense, but am not particularly attached to it.

This needs user testing if it's to stay in.

Sure, all needs user testing and depends on the feedback we get after beta-1. I know it will be quite biased but it is really hard to test any of this and eliminate bias.

In addition, the removal of the heading numbers looks like it'll only work for English text, due to the hard-coding of Header in plugin.js.

No, that replacement happens before the text is translated (testes that of course :) ). See the above screenshot. It uses the plural "Überschriften" as there is no translation for the string "Header" yet.

[azaozz]

Replying to GaryJ:

And these visual previews are completely missed by screen reader users. How do they distinguish between heading levels now?

Yeah, that's bad. How are the headings announced now by screen readers? Are the keyboard shortcuts read too?

Also wondering how that works in the GitHub editor. Don't think we can add any more aria attributes there in a non-hacky way.

[hugobaeta]

For what it's worth, I think removing explicit indicators of hierarchy is not the best solution and this is, again, broadening the scope of this ticket to something that needs more conversation - there's a ticket trying to solve this problem already, #38049. Can we have this conversation over there instead, and keep this commit to what we had already reached a consensus on?

[celloexpressions]

I think keeping it at "Heading 2", "heading 3", ... is the best solution for now until we replace this with something more like "title", "subtitle", "section heading", "subheading", ... as in #38049.

Especially if the editor styles don't have distinct styling all the way to H6, it's pretty confusing without numbers. Starting at 2 is a bit odd, but calling h2 "Heading 1" is misleading and no numbers is worse.

[azaozz]

In 38946:

TinyMCE: revert removing the numbers (2-6) after the headings in the drop-down. Seems it causes more confusion.

See #27159.

[azaozz]

My bad, lets handle this in #38049.

[azaozz]

This should be fixed for 4.7. Heading 1 will be handled in #38049.

[desrosj]

Adding a link to the published dev note for reference: ​https://make.wordpress.org/core/2016/10/28/editor-changes-in-4-7/