[wp-trac] [WordPress Trac] #27159: Removing TinyMCE buttons to improve user experience

[WordPress Trac]

#27159: Removing TinyMCE buttons to improve user experience
-------------------------------------------------+-------------------------
 Reporter:  hugobaeta                            |       Owner:
     Type:  enhancement                          |      Status:  new
 Priority:  normal                               |   Milestone:  4.7
Component:  TinyMCE                              |     Version:  3.8
 Severity:  normal                               |  Resolution:
 Keywords:  needs-patch needs-screenshots        |     Focuses:  ui,
  needs-research needs-user-testing              |  administration
-------------------------------------------------+-------------------------

Comment (by mor10):

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

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

--
Ticket URL: <https://core.trac.wordpress.org/ticket/27159#comment:47>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform