WordPress.org

Make WordPress Core

Opened 3 years ago

Last modified 3 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 (6)

27159.patch (1.6 KB) - added by azaozz 2 years ago.
Bildschirmfoto 2016-08-27 um 18.42.48.png (27.3 KB) - added by iseulde 4 days ago.
Bildschirmfoto 2016-08-27 um 18.56.29.png (5.2 KB) - added by iseulde 4 days ago.
Bildschirmfoto 2016-08-27 um 18.57.05.png (32.1 KB) - added by iseulde 4 days ago.
image1.PNG (30.3 KB) - added by iseulde 4 days ago.
wp-test-tinymce-toolbars.php (4.9 KB) - added by azaozz 3 days ago.

Download all attachments as: .zip

Change History (52)

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


2 years ago

#5 @ubernaut
2 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
2 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
2 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
2 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
2 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
2 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
2 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
2 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
2 years ago

In 27428:

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

#14 in reply to: ↑ 12 @hugobaeta
2 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
2 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
2 years ago

#16 follow-up: @azaozz
2 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
2 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
2 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
2 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 2 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.


20 months ago

#24 @akibjorklund
20 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
20 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.


19 months ago

#27 @melchoyce
19 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
19 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
19 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
18 months ago

Related:

#31441
Consider automatically formatting certain patterns inside TinyMCE


#31 @afercia
16 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.


16 months ago

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


10 months ago

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


5 months ago

#35 @mrwweb
11 days 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
11 days 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
11 days 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
10 days 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
10 days 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 10 days ago by azaozz (previous) (diff)

#40 @azaozz
10 days ago

  • Keywords needs-research needs-user-testing added

#41 @mrwweb
6 days 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 6 days ago by mrwweb (previous) (diff)

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


6 days ago

#43 @iseulde
4 days 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
4 days 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
4 days ago

#45 @iseulde
4 days 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
3 days 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.

Note: See TracTickets for help on using tickets.