Ella 7:08 pm on September 5, 2016

Contextual inline formatting toolbar

I’m looking into streamlining tools for the editor by moving more buttons to a contextual toolbar.

One flow that more and more people are getting used to, and seems like a pretty solid concept, is having a contextual inline formatting toolbar. This means that the bold, italic, link etc. buttons are (only) available when you select text.

What is your experience with this, positive and negative? Do you have any feedback on this from your users or clients using other software?

In my own experience, some of the positive sides are that:

These tools are hidden by default, which makes the interface lighter. They are not used as long as you don’t select any text, so there’s also no reason to show them.
The tools appear close to your focus area, which makes it easier to find them and which saves you time moving the cursor, or hand, to them. For screen readers it could be announced (I think).

Some of the negative sides are that:

The toolbar may easily become overcrowded when plugins extend it. (This may happen now as well…) For this reason, please think of it as just for inline formatting, no blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. formatting and no insertion. In other words, the action needs to affect the selection the user made, nothing more, nothing less. Headings, for example, do not belong here. More on that soon.
Some people do use these tools when no text is selected, meaning to format the word containing the caret. Similarly keyboard shortcuts also work in this case.

I’m looking forward to read your comments.

Nick Halsey 7:23 pm on September 5, 2016

I like this idea, particularly if the inline tools are specifically intended for non-blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience.-level formatting. More experienced users can leverage this in conjunction with keyboard shortcuts and formatting shortcuts to apply formatting without selecting text. All users would understand that the tools are available when selecting text after first experiencing how it works, although we should run some user tests to investigate the discoverability (ie, ask a user to make something bold, insert a link, etc. and see if they try selecting text to bring up the tools).

My biggest concern is with mobile, where various platforms may not have great interfaces for selecting text. But the inline tools would probably work better than what we have now here anyway. Also of course, making sure that it’s accessible, although I imagine that the experience would be improved there as well.
- Ella Iseulde Van Dorpe 7:40 pm on September 5, 2016
  
  If you can’t easily select text, it would indeed be hard right now as well, unless you just want to format a word. Even then, you still have to scroll a lot.
  
  Regarding screen readers I can imagine we could make it even better than how it is now.
  
  My concern for mobile is that some systems also have a contextual toolbar, but there are some not so ideal ways to work around that. One way is to offset ours, another is to position it at the top (bottom wouldn’t work with virtual keyboards). Yet another is trying to do something with the selection or focus. Suggestions are welcome. 🙂
- FolioVision 8:26 pm on September 5, 2016
  
  Ella Iseulde, this a wonderful idea with one caveat: that it does not affect performance or compatibility. An additional formatting tool is probably not worth doing if it’s not lightweight. My suggestion would be to disable the code for platforms where it would either exert a significant performance penalty or would simply be awkward and out of place.
  
  Like Nick and yourself, I agree that this should only be for non-blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. level formatting.
  
  I especially like it if it means that the buttons which work inline do not appear in the toolbar. Redundancy would just be clutter.
Raul Illana 8:46 pm on September 5, 2016

My humble two cents. An inline editor toolbar feels like the right next choice, because you can always extend it with your favourite toolbar, or hooksHooks In WordPress theme and development, hooks are functions that can be applied to an action or a Filter in WordPress. Actions are functions performed when a certain event occurs in WordPress. Filters allow you to modify certain functions. Arguments used to hook both filters and actions look the same..

Medium uses something like this, and there’s also a vanilla JS clone. https://github.com/yabwe/medium-editor
Morten Rand-Hendriksen 9:11 pm on September 5, 2016

I like this idea, and it’s a big step toward front-end editing. That said, even with this tool inclusion I would keep the functionality in the main toolbar for a couple of reasons:

1. The tools are effectively hidden by default, meaning people will assume they are not there and have to discover them by accident.
2. There are use cases where the toolbar is a better place for the functionality.
3. How will this work with regards to accessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility)?

Also, a question: The toolbar is often used to unstyle content (unbold text for example). This is typically done by placing the caret in a word, not highlighting the word. How will this work?
- Ella Iseulde Van Dorpe 1:25 pm on September 6, 2016
  
  Yeah, a good strategy would be to keep the main toolbar and maybe have it more out of the way in small steps. For example, we could hide it on scroll down and show it on scroll up, instead of leaving it at the top at all times. If there’s a system to get data, we can see how many people use which for bold etc. And sure I don’t expect the main toolbar to go away entirely.
  
  For screen readers I think you could announce the toolbar which would be even better than it currently is (I think). Moving the focus to the toolbar in an intuitive way is more difficult, but it would certainly not be harder. Maybe @afercia has some insights.
  
  Not sure about removing styles. If it’s used so much in that way it can be left in the main toolbar. Otherwise it can be added in the contextual one if the selection contains such styles.
- FolioVision 4:16 pm on September 6, 2016
  
  If we really need to duplicate the menu bar functionality, Morten and Iseulde, it seems to me we should not create triplicate functionality. Keyboard shortcuts are already duplicate (and the desirable additional interface as the keyboard shortcuts promote efficiency). If we move the bold italic, strikeout and link functionality into a contextual menu, wouldn’t it be better to free up that menu bar space for other blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. functionality?
Weston Ruter 4:57 am on September 6, 2016

Some people do use these tools when no text is selected, meaning to format the word containing the caret. Similarly keyboard shortcuts also work in this case.

I think I often hit one of these formatting buttons to start/stop formatting. Well, actually, I use the keyboard shortcuts to do this. I think I select text to format less frequently.
- Omaar Osmaan 6:08 am on September 6, 2016
  
  Same here. Mostly keyboard shortcuts to start/stop formatting, rarely the buttons, when I’m writing. While editing/revision, I use the buttons instead of shortcuts.
- Ahmad Awais 9:54 pm on September 9, 2016
  
  Pretty much same here. Keyboard shortcuts FTW. But I like this idea.
Andrea Fercia 3:28 pm on September 6, 2016

Re: Moving the focus to the toolbar in an intuitive way
I’ve seen other applications that just insert the toolbar in the tab order, not sure if it’s the best option but sounds like the more intuitive thing maybe. For sure it would require some research and user testing.
- Ahmad Awais 9:55 pm on September 9, 2016
  
  How do you think something like this can be made more accessible? Through keyboard shortcuts or with tab indexes to filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. through the options available.
Mark Root-Wiley 7:55 pm on September 9, 2016
I thought long and hard before responding to try to get all my thoughts together. I spent quite a long time searching for existing user research but barely found any.

My first question: Particularly given the mobile concerns that probably prevent removing the B / i / link buttons from the toolbar, what’s the goal of adding this feature? Is it primarily about the distance required to move the mouse? Without understanding the driving problem this solves, this first struck me as a solution looking for a problem.

I also have a few concerns, none of which are all that original:
- I wonder about how distracting the continual pop in / pop out will be. If the goal of the editing experience has generally been to remove distractions, does this support that goal? I was able to find one very brief source suggesting this didn’t happen when tested with users, but I remain skeptical. If user testing is done, I wonder if testers should perform the same tasks twice, one using the feature and once not in a random order to try to judge preference.
- Relatedly, besides distraction, the pop up blocks text that’s near the words being formatted. Does this interrupt people’s thoughts more than previously? (I believe Jen Mylo raised this concern regarding the Front End Editor pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party but I can’t find her comment.)
- In that same vein: Generally speaking, hidden controls don’t just reduce findability to new users, but they also increase cognitive load for all users (both thinking about the hidden controls that are there and remembering the words hidden behind it).
- The potential for abuse seems very real. I’d honestly recommend not making this extensibleExtensible This is the ability to add additional functionality to the code. Plugins extend the WordPress core software. if it’s added. Even one or two buttons in it that I didn’t want and never used would make editing a site much less pleasant.
- This objectively has one downside which is that users can’t select certain words near their selection without clicking out of the current selection. (Example, bolding two words and then italicizing the entire containing sentence.)
## Other thoughts

After the formatting shortcuts for bold and italic were dropped, is this seen as a new alternative to those? Will it be in addition? (i.e. we’ll have at least 4 ways to bold!)

——————-

I AM NOT A SCREEN READER USER but the idea of these being announced every time I select text sounds super annoying. I imagine most screen reader users use CTRL / CMD + B, etc. and so I’m not sure reading buttons aloud will help. But that’s my uninformed gut reaction.

——————-

re: @iseulde
we could hide it on scroll down and show it on scroll up

See concerns about cognitive load above. See Also: “Maximize the Content-to-Chrome Ratio, Not the Amount of Content on Screen”