WordPress.org

Make WordPress Core

Opened 3 years ago

Last modified 7 days ago

#27159 new enhancement

Removing TinyMCE buttons to improve user experience

Reported by: hugobaeta Owned by:
Milestone: 4.7 Priority: normal
Severity: normal Version: 3.8
Component: TinyMCE Keywords: needs-patch needs-screenshots needs-research needs-user-testing
Focuses: ui, administration Cc:

Description

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:

https://i.cloudup.com/8cPZnesHHH.png
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.

https://i.cloudup.com/nKbmAMizXi.png
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!

https://i.cloudup.com/SBd4LD39lC.png
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!

Attachments (9)

27159.patch (1.6 KB) - added by azaozz 3 years ago.
Bildschirmfoto 2016-08-27 um 18.42.48.png (27.3 KB) - added by iseulde 5 weeks ago.
Bildschirmfoto 2016-08-27 um 18.56.29.png (5.2 KB) - added by iseulde 5 weeks ago.
Bildschirmfoto 2016-08-27 um 18.57.05.png (32.1 KB) - added by iseulde 5 weeks ago.
image1.PNG (30.3 KB) - added by iseulde 5 weeks ago.
wp-test-tinymce-toolbars.php (4.9 KB) - added by azaozz 4 weeks ago.
wp-test-tinymce-toolbars.2.php (4.9 KB) - added by mrahmadawais 3 weeks ago.
Icon arrangement proposal!
wp-test-tinymce-toolbars.3.php (4.8 KB) - added by EusebiuOprinoiu 3 weeks ago.
mrw-wp-test-tinymce-toolbars.php (4.9 KB) - added by mrwweb 2 weeks ago.
hopefully this serves as a milestone for progress

Download all attachments as: .zip

Change History (93)

#1 @hugobaeta
3 years ago

@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 :)

Last edited 3 years ago by hugobaeta (previous) (diff)

#2 follow-up: @azaozz
3 years ago

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.

#3 in reply to: ↑ 2 @hugobaeta
3 years ago

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.

This ticket was mentioned in IRC in #wordpress-ui by hugobaeta. View the logs.


3 years ago

#5 @ubernaut
3 years ago

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.

#6 follow-ups: @celloexpressions
3 years ago

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>.

#7 in reply to: ↑ 6 ; follow-up: @melchoyce
3 years ago

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.

#8 in reply to: ↑ 7 ; follow-up: @iammattthomas
3 years ago

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

#9 in reply to: ↑ 8 @melchoyce
3 years ago

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.

#10 in reply to: ↑ 6 @hugobaeta
3 years ago

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...

#11 follow-up: @nacin
3 years ago

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.

#12 follow-up: @iseulde
3 years ago

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

#13 @azaozz
3 years ago

In 27428:

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

#14 in reply to: ↑ 12 @hugobaeta
3 years ago

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.

#15 in reply to: ↑ 11 @hugobaeta
3 years ago

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
3 years ago

#16 follow-up: @azaozz
3 years ago

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.

#17 in reply to: ↑ 16 @hugobaeta
3 years ago

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?

#18 @celloexpressions
3 years ago

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.

#19 @iseulde
3 years ago

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.

Last edited 3 years ago by iseulde (previous) (diff)

#20 @johnbillion
2 years ago

  • Priority changed from normal to low
  • Version changed from trunk to 3.8

#21 follow-up: @nacin
2 years ago

#28981 was marked as a duplicate.

#22 in reply to: ↑ 21 @jmlapam
2 years ago

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.

This ticket was mentioned in Slack in #design by celloexpressions. View the logs.


21 months ago

#24 @akibjorklund
21 months ago

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.

#25 @EmpireOfLight
21 months ago

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.

This ticket was mentioned in Slack in #core by melchoyce. View the logs.


20 months ago

#27 @melchoyce
20 months ago

@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?

#28 follow-up: @iseulde
20 months ago

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.

#29 in reply to: ↑ 28 @melchoyce
20 months ago

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.

#30 @iseulde
19 months ago

Related:

#31441
Consider automatically formatting certain patterns inside TinyMCE


#31 @afercia
17 months ago

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.

This ticket was mentioned in Slack in #core-editor by hugobaeta. View the logs.


17 months ago

This ticket was mentioned in Slack in #core-editor by iseulde. View the logs.


11 months ago

This ticket was mentioned in Slack in #core-editor by hugobaeta. View the logs.


6 months ago

#35 @mrwweb
6 weeks ago

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.

#36 follow-up: @hugobaeta
6 weeks ago

@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?

#37 in reply to: ↑ 36 @mrwweb
6 weeks ago

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.

#38 follow-up: @celloexpressions
5 weeks ago

  • Keywords needs-patch needs-screenshots added
  • Milestone changed from Awaiting Review to 4.7
  • Priority changed from low to normal

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.

#39 in reply to: ↑ 38 @azaozz
5 weeks ago

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.

Last edited 5 weeks ago by azaozz (previous) (diff)

#40 @azaozz
5 weeks ago

  • Keywords needs-research needs-user-testing added

#41 @mrwweb
5 weeks ago

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.

Last edited 5 weeks ago by mrwweb (previous) (diff)

This ticket was mentioned in Slack in #design by hugobaeta. View the logs.


5 weeks ago

#43 @iseulde
5 weeks ago

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.

#44 @iseulde
5 weeks ago

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
5 weeks ago

#45 @iseulde
5 weeks ago

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.

#46 @azaozz
4 weeks ago

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.

#47 follow-ups: @mor10
4 weeks ago

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.

#48 in reply to: ↑ 47 ; follow-ups: @azaozz
4 weeks ago

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.

#49 in reply to: ↑ 48 @mor10
4 weeks ago

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.

#50 in reply to: ↑ 48 @mrahmadawais
3 weeks ago

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.

#51 @mrahmadawais
3 weeks ago

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

Minimal
https://i.imgur.com/Htvo5NO.png

Full
https://i.imgur.com/HEBpWqe.png

FormatSelect has no Heading 1
https://i.imgur.com/a8FLLTZ.png

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.

Last edited 3 weeks ago by mrahmadawais (previous) (diff)

@mrahmadawais
3 weeks ago

Icon arrangement proposal!

#52 @celloexpressions
3 weeks ago

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.).

#53 @EusebiuOprinoiu
3 weeks ago

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.

http://i.imgur.com/6kuMMIk.png

#54 follow-ups: @bfintal
3 weeks ago

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?

Last edited 3 weeks ago by bfintal (previous) (diff)

#55 in reply to: ↑ 54 @mor10
3 weeks ago

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.

#56 in reply to: ↑ 54 @mrahmadawais
3 weeks ago

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.
https://i.imgur.com/QPQdhwn.png

@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.

#57 @bfintal
3 weeks ago

Building upon the idea:

Minimal — same as above
https://i.imgur.com/Htvo5NO.png

Full — center button moves to the other alignment buttons for grouping
http://i.imgur.com/QAZy9TH.jpg

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)
http://i.imgur.com/VqawM7p.jpg

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

#58 @EusebiuOprinoiu
3 weeks ago

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.

#59 @Elhisai
3 weeks ago

+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

#60 @EusebiuOprinoiu
3 weeks ago

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

http://i.imgur.com/FoEgn4s.png

Last edited 3 weeks ago by EusebiuOprinoiu (previous) (diff)

#61 @siriusly
3 weeks ago

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.

#62 in reply to: ↑ 47 @mrwweb
2 weeks ago

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.

  1. 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.

  1. 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...)

  1. @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.

  1. 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.

#63 @mrwweb
2 weeks ago

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:

https://mrwweb.com/files/wp-trac/mrw-mce.png

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
2 weeks ago

hopefully this serves as a milestone for progress

#64 follow-up: @hugobaeta
2 weeks ago

@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?

#65 follow-up: @hugobaeta
2 weeks ago

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.

#66 in reply to: ↑ 64 ; follow-up: @mrwweb
2 weeks ago

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.

#67 in reply to: ↑ 65 @mrwweb
2 weeks ago

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.

#68 in reply to: ↑ 66 ; follow-up: @hugobaeta
2 weeks ago

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?

#69 @EusebiuOprinoiu
2 weeks ago

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.

http://i.imgur.com/FoEgn4s.png

#70 in reply to: ↑ 68 ; follow-up: @melchoyce
2 weeks ago

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.

#71 in reply to: ↑ 70 ; follow-up: @hugobaeta
2 weeks ago

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.

Last edited 2 weeks ago by hugobaeta (previous) (diff)

#72 in reply to: ↑ 71 @melchoyce
2 weeks ago

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.

#73 follow-up: @celloexpressions
2 weeks ago

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.

#74 @mrwweb
2 weeks ago

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.

This ticket was mentioned in Slack in #core-editor by mrwweb. View the logs.


2 weeks ago

This ticket was mentioned in Slack in #design by hugobaeta. View the logs.


13 days ago

#77 @mor10
13 days ago

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.

https://cldup.com/EJpGjrySYK.png

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.

#78 follow-up: @iseulde
13 days ago

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.

Last edited 13 days ago by iseulde (previous) (diff)

#79 in reply to: ↑ 78 ; follow-up: @mor10
12 days ago

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.

#80 in reply to: ↑ 79 ; follow-up: @hugobaeta
12 days ago

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 ?

#81 in reply to: ↑ 80 @mor10
12 days ago

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.

#82 in reply to: ↑ 73 ; follow-up: @melchoyce
12 days ago

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.

#83 in reply to: ↑ 82 @celloexpressions
11 days ago

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.

#84 @mor10
7 days ago

Related: #38115

Note: See TracTickets for help on using tickets.