Improving the User Experience by Rearranging the WordPress Post Editor

When the floor was opened up to users for suggestions on what they want to see included in WordPress 4.7, Mark Root-Wiley advocated for Trac ticket #27159. The three-year old ticket was created by Hugo Baeta and suggests that certain buttons in the post editor be removed in order to improve the user experience.

In the initial proposal, Baeta recommends that the Underline, Alignment, and Text color picker buttons be removed. Throughout the last three years, members of the core team and those interested in the ticket have discussed the pros and cons of removing specific buttons. There’s also a suggestion moving the drop-down menu for choosing headings and making it the first item in the top row.

Here is what the kitchen sink version of the post editor looks like on a fresh install of WordPress 4.6.

WP46FreshInstallPostEditor.png
Post Editor of a Fresh Install of WordPress 4.6

The following is a summary of the proposed changes to the editor.

  • 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.
  • Remove underline, other than the keyboard shortcut
  • Consider removing text color that’s currently in the kitchen sink
  • Consider adding a code button and/or a table button.

Nick Halsey questioned if stats could be obtained from WordPress.com that shows which buttons are used the most. Mel Choyce shared statistics from WordPress.com that indicate Bold, Italic, and Links are used the most while Lists and Blockquotes are the second most used buttons. The Center and Left alignment buttons are used often, but the data doesn’t determine if people are using them to align text or images. Information on which headings are used most was not available.

The self-hosted version of WordPress doesn’t collect this type of usage information so it’s difficult to know which buttons in the editor are used most often. Given WordPress’ market share however, it’s not hard to imagine that each button serves an important purpose for a subset of users.

Members of the core team are exercising caution on deciding which buttons to remove as Andrew Ozz notes, “This is one of the most used and perhaps most sensitive places in WordPress and even a small change can cause problems for many users.” Ozz said. “I hope we can use some of the info and experience from making the Calypso editor.”

The team wants to collect more usage data and perform user tests before making any final decisions. To help with testing, Ozz has created a small plugin that can be used to test different button configurations.

What the Competitors Are Doing With Their Editors

WordPress’ competitors which are mostly composed of services don’t have to worry about backwards compatibility or that potentially millions of people rely on a button. I took a tour of their post editors to see what options they make available to content creators.

Medium

MediumPostEditor.png

Medium doesn’t have formatting tools at a glance and the buttons are only shown if you highlight text.

Tumblr

TumblrEditorButtons.png
Tumblr Post Editor

Similar to Medium, the post editor is bare and the formatting icons only display when text is highlighted.

Facebook Notes

FacebookNotes.png
Facebook Notes Editor

Facebook Notes starts off with a bare editor with two buttons on the left. The first opens up links to embed something or add a photo. The hamburger menu icon displays headings and a blockquote button. Like the other two editors mentioned above, a select group of formatting options are displayed when text is highlighted.

Joomla 3.6.2

JoomlaPostEditor.png
Joomla 3.6.2 Post Editor

The post editor in Joomla 3.6.2 has a few more buttons than what the WordPress kitchen sink has.

Drupal 8.1.8

Drupal8TextEditor.png
Drupal 8 Text Editor

Drupal has three different editors users can choose from, Basic HTML, Restricted HTML, and Full HTML. Each editor has its own button configuration.

What Is the Ideal Configuration?

The buttons in the editor serve a multitude of purposes and contexts but not all of them. Whichever items the core team decides to remove from the editor will likely come back in the form of a plugin.

What buttons do you use most and which items would you like to see removed from the editor to make it simpler to use?

40 Comments


  1. Perhaps they should not remove any at all.

    If the option is to remove and then create a separate plugin that re-adds the exact functionality that was taken out, would that not constitute redundancy at its best??

    Why not just give the user an option field much like the page options where a person can select a checkbox to show/hide any specific options. This could also include a potential for sort order as well.

    This would likely not involve drastic changes to anything that is already there. Users who don’t care one way or the other could just ignore the option, while those users who “must remove” excessive buttons from view could do so.

    Perhaps the best of both worlds??

    Report


    1. Agree with Derek 100%! Why remove something that is already there only to re-add it via a Plugin and potentially make your site more cumbersome?

      Report


  2. I can see now all the users saying, “what the heck happened”? Why did they move these around. I just don’t know….

    The only two that have really bugged me is the full justification, which doesn’t look good on any browser or site, and the underline, only because it’s human nature on the web to think of text underlined as a link. I cannot tell you how many times I had people who used underlines, tell me all those who contacted them “because the link was broken”.

    I’ve also heard the clear formatting seems redundant as you can just push the button of the style to turn it off or clear it.

    Otherwise, I’m good with the others staying as is. Just my .02

    Report


    1. @Bob – Agree on both points. Those 2 make a lot more sense than removing text color.

      Report


  3. I like drupal approach, providing the admin with the options to choose three different editors (Basic, Restricted, and Full HTML), but unlike drupal making the Full HTML the default option.
    And then, giving admin the option to arrange buttons on the each editor.

    Report


    1. Agree! So odd that wordpress.com has obviously already tackled this question and resolved it for their millions of users and this hasn’t been applied to .org at all.

      Report


      1. They’ve been too busy debating over which button should go where for the last 3 YEARS.

        It’s kinda sad actually……

        Report


  4. I think it would be more productive to ask why kitchen sink does not provide access to the full set of HTML5 formatting tags and then fix those conspicuous omissions. Having to bounce in and out of code view ain’t no fun. Those who seek to cripple the post editor should consider that they way they use WordPress is not the same as how others use WordPress and stop trying to dictate to others. Not nice!

    Report


  5. Not sure how feasible this is, but it would sure be nice if the editor could pull in styles from the current theme so people inputting content could see what the various H tags look like, etc., even if it’s not exact — an approximation would even be welcome.

    It’s supremely difficult to instruct clients on how to input content and have to be like, this is super easy! BUT this dropdown, be careful, none of what you create with this is going to look like this exactly, also please don’t use the color button ’cause those will get colored on the front end by the stylesheet (“what’s a stylesheet?”) etc.

    Report


      1. I don’t want my clients touching the customizer, that’s even worse. :) There’s definitely a disparity between self-run sites where the user is customizing a theme they found/bought, and people like myself who build custom themes/sites and hand over the keys to clients who then do all sorts of nonsense on the backend which I’d like to minimize the damage from.

        Report


    1. There is a separate CSS file that controls the display of text in the post editor: editor-style.css located in the current theme directory.

      Report


      1. Hmm, interesting — I guess I wasn’t aware of how that worked. So, I can plug my h1-h6/blockquote/etc whatever CSS into that so content in the editor will more or less look like it’ll look on the front end when published? Does that affect the p/h1/etc dropdown as well? Thanks!

        Report


  6. That is one of the many rediculous discussions inside the WP developer team. Three years of considering, which button should be in and out, measuring how frequent buttons are used, mentioning that small changes could have an impact to the experience of many users and that a removal of buttons will result in plugins which bring them back. The obviest consequence for that problem is not discussed: Implement an easy-to-use interface like in Word, where the edtor buttons can be configured by the user! Everyone wants to keep it simple and that results in such lenghty and dumb discussions. Dont talk, start building interfaces!

    Report


  7. What Pierre said! Unlike the bad old days we’ve got things like AJAX, REST APIs, and jQuery so it’s probably a lot easier to add, remove, and configure toolbars than it was way back when.

    I love the idea of putting the style dropdown on the top line (minus H1.)

    The only button I’d categorically take out would be Underline. I would be extremely grateful if H1 was pulled from the style dropdown.

    I think it would be fine to move left, right, center, and justify to the second row. I think it would be a shame to lose justify, which I agree can look really bad in English but seemed to work nicely on one of my Chinese client’s sites.

    Perhaps I’m the only one who uses erase all formatting but it comes in handy when pasting content from other apps and sites.

    Going back to what Pierre said, just because I have use cases for justify and erase all doesn’t mean everyone should be subjected to it. But I’d be sorry if I couldn’t easily put them back in. Does anyone know if there’s an AJAX button editor for TinyMCE?

    Report


    1. I dont think so, or at least I couldnt find anything (in less than 10 minutes of search). There is TinyMCE Avanced though.
      One could certainly use that plugin as base, and fine-tune it into a per-user solution.

      cu, w0lf.

      Report


  8. I don’t like the idea of removing any because of the impact to those users who actual use them.

    However, an overhaul of the editor would be nice (visually I like the wordpress.com editor) – a drop-down, for instance, for justification would free up real-estate and moving the most used to the top line would mean that most users would be able to keep the second row hidden.

    Report


  9. I think what WP desperately needs now is a proper drag&drop, built-in content editor instead of this. Something similar to Editus (Lasso) plugin (GIF about editing).

    People need columns, call to action sections, buttons. Shortcode is just simply not the solution for this, because it still feels like coding and it can become messy shortly.

    Report


    1. I really did like Editus.

      Report


  10. I think really the ideal would be to have a buttonless editor. I don’t want to ever have to break in the middle of writing something in order to give it the styles that I want. The markdown shortcuts that have been added to the editor in recent versions of WordPress are a step in the right direction, and make many of these buttons entirely redundant. That doesn’t meant that we should actually consider removing the buttons any time soon, because of the backward compatibility concerns for UX. But I’d much rather everything be done with keyboard shortcuts and markdown than having to jump around from the text to buttons all of the time.

    Report


  11. If anything is going to be removed, there must be a way for the user to re-add it. A customizable tool bar would be ideal. I deal with a lot of historic content on our site from old newspaper and magazine articles. Full-justify is something that gets used on a regular basis.

    As far as bouncing back and forth between visual and text views, I do it all of the time. The ‘visual’ view is lacking in many aspects. For example, I use the Columns plugin by Konstantin Kovshenin. Because it’s invoked using a short code, the visual editor doesn’t know what to do with it.

    The visual editor also has a nasty habit of putting media references where it want to, not where I want the item to appear. I am constantly switching to text view to clean up.

    Report


  12. Anyone who really wants to adjust their editor toolbars can always install a plugin like TinyMCE Advanced, which lets you reorganize the default toolbars as well as add in extra tools like a table dropdown editor or anchor links or page breaks.

    I don’t use it terribly often, since I want the sites I manage to have a pretty predictable workflow for training purposes, but when I’m working with someone who has very specific types of content that has been useful.

    Report


  13. What all of the comments and the article here miss is that some of the buttons embed style tags which take precedence over CSS (color choice, for example), making it possible for a naive user to create a mess where things are impossible to override cleanly in the stylesheet.

    The problem with the editor is that it includes both structural tags (heading levels, bold/italic, etc) AND visual formatting (colors). Ideally, the visual styling lives entirely in the CSS with the HTML defining structure. Buttons that enable structure should be left, buttons that override styling should be removed.

    How should buttons be arranged? Eh, I dno’t think that’s the heart of the issue. What is important is that the buttons should a) make sense if in default position and b) it should be FAR more intuitive to rearrange buttons or to add other buttons. Sure, I can install TinyMCE Advanced, but most endusers… aren’t going to do that.

    Report


  14. Think it’s important to start by making a distinction between different groups of users.
    – Someone who installed WordPress at his/her web host and has no coding experience, just wants to have many buttons in the editor, like Word
    – A developer building a website for a client, who wants to maybe restrict the ways his/her client can edit content

    In both cases you might like to put the most-used buttons in front. But for different user groups different kinds of editors and button configurations are optimal.

    Report


    1. I’m a long time solo publisher and I’ve never taken on clients. I don’t fall into either of your groups of users. But, I think the edit features a user needs will depend on what the site is and how it is used. Also, what theme is used. I really think the most useful thing for WP to do would be a drag and drop which lets users pick their own most used options and keep them where they can get to them. Why does anyone need a page builder to add layout and content editing features to WordPress? All the features should be there, whether they get used often or just once in awhile. Each user has different needs but most of us like to dip into the kitchen sink and see what all those shiny buttons do. (I like having shiny buttons rather than hand writing the code myself).

      Report


  15. Just make TinyMCE Advanced a Core component. Or extend it with a “per user” option, and put it up in the “recommended plugins” tab in the WP Plugin install section ;)

    cu, w0lf.

    Report


  16. I’m concerned that WordPress has been caught flat-footed while the world races ahead. MCE buttons, shortcodes, and even the customizer are way behind what others are doing. The post/page editor is one of the most critical part of WordPress. It is the face that WP presents to those publishing with WP on a daily basis. These are the people who ultimately decide if WP is the right solution to meet their needs. It is a serious problem that this part of WP is so primitive. To see what is happening in other places there are good examples to be found in the various “Builder” utilities used to create HTML emails. Virtually every ESP provides its users with such a front end and most are quite powerful. To see an example I suggest you build a page with with this open source project… https://beefree.io

    Report


  17. I had to read this post because it boggles my mind why moving things around is so important when they should be focusing on making a serious content editor that works!

    1. Show full HTML tags in the HTML tab. It’s an HTML view!
    2. Stop adding invisible p tags or breaks
    3. Stop adding p tags in nested shortcodes
    4. Stop removing my own Code!!!! Do Not Touch!!

    I’ve been using Joomla for about 9 years, and there is one editor that is king. It’s called the JCE editor. Puts all other editors to shame. I’ve been trying to convince the developer to make a version for WordPress.

    Overall, rearranging the editor is not important, making it work and usable without inventing swear words as you try to use it is needed. This is supposed to be a “content management system” which means let’s have a pro quality content editor for serious content creation.

    Report


  18. I work with hundreds of regular people whose WP websites I build and maintain, and I have seen only two major problems with the Editor, over and over. I have to explain these two things to every single client. Nothing else is a problem.

    1. The second row of buttons being hidden until someone finds out, somehow, that a button oddly named “Kitchen Sink” reveals the other half of the editing buttons. Can anyone honestly claim that this isn’t completely ridiculous? Or can anyone give me even one reason why it’s like this?

    2. The “Visual” and “Text” tabs — forgetting how they work for now, just their existence. If I didn’t explain this to every single regular (“not particularly technical”) user, not a single person would ever have the slightest idea that they’re there, much less what in the world they are. (“Text”? In other words, the opposite of what it actually is?)

    All the rest of the changes mentioned above are so minor and unimportant in comparison with these two things, which literally trip up every single (ordinary) user.

    Just saying. :-)

    Report


    1. Patty – You really nailed it. We have created a knowledge base article for our clients to explain the 2 exact problems. Unfortunately, many do not read it or do not remember it.

      But, you have given us an idea. Most of our clients just want to run their business, not learn about a confusing system. Because of this, we do significant customization of the admin for them so they can focus on doing what they need to do.

      We are going to just remove the text tab for most of our clients! I just found a few hacks to guide us and will be creating an addition to our already extensive admin customization. Now off to look for another to force kitchen sink open and maybe even get rid of the ridiculous name.

      Thanks for stimulating my grey matter.

      Report


      1. Thanks for the creating the ticket and making us aware of it. If it happens, that will definitely a help. I will probably join the discussion.

        That will not solve the other problem that so many people run into when they switch back and forth and find that WordPress is messing with the code.

        Trying to explain things like wpautop to clients is just a nightmare. It becomes even worse when they get a training bill and realise how much time was spent explaining these quirks and how that cut into the part about actually getting things done.

        Report


    2. I think the kitchen sink (whatever name it is given) is a good idea. It keeps the screen uncluttered. But, why not make the options on the editor screen drag and drop? That way people could choose what they use most often and leave the rest behind the kitchen sink.

      Report


  19. Why would WP remove features when more people are looking to page builder plugins to GET features? This seems backwards.

    Report


  20. I’m coming late to the party, I know. I like to write in HTML and add my own CSS. The “text” tab (why not just call it “html”?) is terrible because it keeps hiding paragraph marks and screwing up the code, especially if you go back and forth between the editing tabs. As a work-around, I just write, proof and add html off-line and upload whem I’m ready to insert the photos.

    Report


  21. I like the Tumblr style as it looks like MS Word style.
    Also, I think the WordPress.org team replaces the editor with WordPress.com editor; it is better than the current post editor.

    Report

Comments are closed.