WordPress.org

Make WordPress Core

Opened 13 months ago

Last modified 10 days ago

#27159 new enhancement

Removing TinyMCE buttons to improve user experience

Reported by: hugobaeta Owned by:
Milestone: Awaiting Review Priority: low
Severity: normal Version: 3.8
Component: TinyMCE Keywords:
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 (1)

27159.patch (1.6 KB) - added by azaozz 12 months ago.

Download all attachments as: .zip

Change History (31)

comment:1 @hugobaeta13 months 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 13 months ago by hugobaeta (previous) (diff)

comment:2 follow-up: @azaozz13 months 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.

comment:3 in reply to: ↑ 2 @hugobaeta13 months 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.

comment:4 @ircbot12 months ago

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

comment:5 @ubernaut12 months 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.

comment:6 follow-ups: @celloexpressions12 months 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>.

comment:7 in reply to: ↑ 6 ; follow-up: @melchoyce12 months 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.

comment:8 in reply to: ↑ 7 ; follow-up: @iammattthomas12 months 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

comment:9 in reply to: ↑ 8 @melchoyce12 months 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.

comment:10 in reply to: ↑ 6 @hugobaeta12 months 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...

comment:11 follow-up: @nacin12 months 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.

comment:12 follow-up: @iseulde12 months 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

comment:13 @azaozz12 months ago

In 27428:

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

comment:14 in reply to: ↑ 12 @hugobaeta12 months 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.

comment:15 in reply to: ↑ 11 @hugobaeta12 months 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 :)

@azaozz12 months ago

comment:16 follow-up: @azaozz12 months 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.

comment:17 in reply to: ↑ 16 @hugobaeta12 months 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?

comment:18 @celloexpressions12 months 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.

comment:19 @iseulde12 months 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 12 months ago by iseulde (previous) (diff)

comment:20 @johnbillion11 months ago

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

comment:21 follow-up: @nacin8 months ago

#28981 was marked as a duplicate.

comment:22 in reply to: ↑ 21 @jmlapam8 months 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.

comment:23 @slackbot7 weeks ago

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

comment:24 @akibjorklund7 weeks 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.

comment:25 @EmpireOfLight6 weeks 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.

comment:26 @slackbot6 weeks ago

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

comment:27 @melchoyce6 weeks 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?

comment:28 follow-up: @iseulde6 weeks 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.

comment:29 in reply to: ↑ 28 @melchoyce6 weeks 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.

comment:30 @iseulde10 days ago

Related:

#31441
Consider automatically formatting certain patterns inside TinyMCE


Note: See TracTickets for help on using tickets.