Repository: wagtail/wagtail

Issue:
Rich text toolbar is hidden by default making some edits difficult
### Issue Summary

Prior to Wagtail v4, the rich text toolbar was always visible which made it easy to access the full range of options when editing. Now that the toolbar is hidden by default, it's very difficult. I understand the desire to save screen real estate but it's now nearly impossible for normal editors to discover how to make the same edits they could prior to v4.

The simplest example is adding a new `RichTextBlock` and wanting to kick things off with a numbered list. Previously this was just a toolbar button click away. Now one needs to unlearn this and begin to think of lists as a "block" that can be triggered per the "Write something or type '/' to insert a block" prompt.

For a slightly more advanced but documented example, the [Extending the Draftail Editor](https://docs.wagtail.org/en/v4.0.2/extending/extending_draftail.html#creating-new-entities) documentation gives an example of how to add a stock chooser. One has to look closely at the animated GIF to figure out that the only way to even access the toolbar in this scenario is to highlight some empty text:

![draftail_entity_stock_source](https://user-images.githubusercontent.com/24574/193920852-94016da0-1b2d-47ce-90fe-e949d38f75b2.gif)

The only more slightly discoverable way to trigger the toolbar is to highlight text, but of course that will result in the inline content _replacing_ the highlighted text. In short, it seems the assumption behind the hidden-by-default toolbar is that the only buttons available in the toolbar are for formatting selected text.

This issue impacts plugins like [wagtail-footnotes](https://github.com/torchbox/wagtail-footnotes) which expect to be able to insert a footnote inline, anywhere within a sentence. If editors want to insert a footnote mid-sentence, they now have to highlight a space, insert the footnote and then add an additional space so there is still a single space between the footnote link and the following word. (wagtail-footnotes is not fully Wagtail v4 compatible yet but there is work in progress and I noticed this issue when testing)

Ideally the toolbar would always display when the input field is in focus. This keeps the rest of the page that is not being actively edited to a minimum while making it extremely easy to access the full set of rich text "features" on the chunk of text you're actively editing. 

It doesn't really work to add a new line to get the "type '/'" prompt since this would just place the e.g. stock chooser icon or footnote reference on a new line and would have to be manually maneuvered into place. 


Discussion:
I also encountered this problem. Personally I'm fine with using more space around the textfield. So maybe enable it by using an additional classname to the content_panel? 
It has since come to my attention that the `hr` button is missing even though it is specified in `features`:

<img width="1538" alt="Screen Shot 2022-10-14 at 11 44 02 AM" src="https://user-images.githubusercontent.com/24574/195918619-4cd0df72-6ef2-4661-b4e2-1d4b188c313c.png">

Only text formatting options are included (superscript, subscript, strikethrough):

<img width="486" alt="Screen Shot 2022-10-14 at 11 43 18 AM" src="https://user-images.githubusercontent.com/24574/195918717-b65cbfa7-76e0-48a5-8837-32fb0867eb24.png">

It is not available in the "/" block menu either:

<img width="290" alt="Screen Shot 2022-10-14 at 11 45 47 AM" src="https://user-images.githubusercontent.com/24574/195918914-a2f0288d-921f-4797-96dc-b445e3bc1553.png">
We have the same issue and can't update to Wagtail 4 with this editor behaviour.
Users are missing the toolbar and can't figuring out how to enable it...

> I also encountered this problem. Personally I'm fine with using more space around the textfield. So maybe enable it by using an additional classname to the content_panel?

Or enable it on focusing the textfield on the old position of the toolbar?
Since the new editor is very similar to the block editor in wordpress, probably people using wordpress or migrating from it feel more familiar with this.
I don't use wordpress, but on a quick comparison, one thing that would probably help here is, that the toolbar does not occur if you single-click into the text. Without that it is not possible to start writing bold text for example, you always have to write the text, mark it, and convert it to bold.
Implementing this would probably also make it easier to learn the possibilities of the editor.
**edit:** sry, this basically duplicates what the original poster wrote... see my post as +1 :sweat_smile: 
Experiencing the same issue here with `RichTextBlock`, block toolbar does not contain all elements specified in default richtext config, however some of the missing elements are present in the inline toolbar but not all.
The `RichTextField` does use the default configs without issue but the inconsistency between block toolbar and inline is there, not sure if that's intentional though?
 
![Screenshot from 2022-11-03 11-11-19](https://user-images.githubusercontent.com/5871230/199694991-fca20e6d-afea-4b85-b19f-ed094e34219f.png)

![Screenshot from 2022-11-03 11-16-44](https://user-images.githubusercontent.com/5871230/199696105-d43d476b-b8f4-430f-b997-354207f336de.png)

![Screenshot from 2022-11-03 11-18-53](https://user-images.githubusercontent.com/5871230/199696426-189f8010-c77e-42a3-b552-c2b7532b391e.png)




The disappearance of the 'hr' feature does seem to be a genuine bug, and one that I'll raise as a separate issue shortly. (You can insert one by typing `---`, but that isn't really discoverable...)

For the remaining items, there _is_ a logical reasoning to their placement: bold / italic / links are not in the block toolbar because they are formatting to be applied to text within a block, rather than a block in their own right; conversely, headings / lists / images are block-level elements; and headings and lists additionally appear in the inline toolbar because it needs to be possible to change existing text into that block type (which isn't the case for images). However, just because it's logically correct in the context of Wagtail architecture doesn't mean it's the right way to present it to editors :-)
We also like the idea of displaying the toolbar when the input field is in focus.

The problem we are experiencing is when we want to add internal links or documents and keep the original title as the link text. It is possible to add an internal link using the keyboard shortcut but that only works in desktop and there's no shortcut for adding documents.

As it is now we need to enter the title manually, mark the text and then add the link or document.
Thank you all for the feedback so far. Just wanted to follow up to say we’re taking a hard look at this currently, and you can expect to see changes in the next version of Wagtail.

At this stage we still think our reasoning for switching over to a floating toolbar is sound, though we are going to do user testing with different options to confirm, including some options where the toolbar is at the top of the editor.

----

If anyone has further feedback on this, please go for it so we can take it into account. With that in mind, there are specific points I think are worth clarifying:

> For a slightly more advanced but documented example, the [Extending the Draftail Editor](https://docs.wagtail.org/en/v4.0.2/extending/extending_draftail.html#creating-new-entities) documentation gives an example of how to add a stock chooser

Numbered lists are a fundamental feature of all rich text editors, this stock picker is explicitly marked as an "advanced" feature in our documentation. So although we do want this to be possible, bear in mind this is far down the priority list. Footnotes and documents inserted with their title as-is are great examples.

> Users are missing the toolbar and can't figuring out how to enable it...

There shouldn’t be anything to enable, the toolbar just appears upon selecting text, either with the keyboard or mouse. Is there anything else getting in the way here?
We've now produced some visuals based on the issues highlighted above.

These illustrate the introduction of pinnable controls; the controls will default to the unpinned bar, this is very similar to the current setup, however the user has the option of switching to a pinned version. The pinned version will be fixed to the top of the rich text editor and will always be visible.

The pinned version of the controls has had a slight makeover, ensuring it blends into the UI so as to not distract from the actual content, we've also optimised it so that it fills up as little vertical height as possible, this was to address the amount of vertical viewport space that's taken up when multiple rich text areas were stack above each other.

We're also going to update the plus icon. It currently only shows when on a new line, this will now consistently show throughout the rich text editor, ensuring the user can easily add a block, or change formatting options no matter where their cursor is, this will ensure users can always easily access the controls.

Finally, we're also currently trying out making the pinned version sticky, to ensure that when the the rich text area is especially full of content, you'll still be able to easily access the controls, a basic demo of this is avaliable below, whether this gets included within this issue or is a future enhancement is yet to be decided.

The pinnable version has been usability tested, and the results have been very positive, with different users citing they prefered different options, validating the need for the options, and there were mentions of toggling between the two depending on the content that they are writing.

Mockups:

### Unpinned

![page-editor_unpinned](https://user-images.githubusercontent.com/298766/210519432-7ed997be-0365-412d-8e74-5b6cd28b0155.png)

### Unpinned - tooltip

![page-editor_unpinned-tooltip](https://user-images.githubusercontent.com/298766/210519460-33eda534-fe06-492c-9198-95ed0fe205a0.png)

### Pinned

![page-editor_pinned](https://user-images.githubusercontent.com/298766/210519490-53c4cc4c-a37a-4d6b-8e9f-6138a29f8515.png)

### Sticky control demo for use with pinned option*

*Note that this only demos the sticky functionality of the pinned version and nothing more

https://codepen.io/nicklee/pen/xxzaqrX







> the controls will default to the unpinned bar

@nicklee would this be something we could control via a setting so it could be pinned by default? Discoverability is an issue here, especially in the case of _inserting_ inline content (footnotes, etc.), not _formatting_ content. In a situation like this, editors are scanning for something that will let them insert the footnote, but everything is currently hidden by default without selecting some text first. I'm hoping we will arrive at a solution that doesn't require editors to guess their way out of this conundrum.

> We're also going to update the plus icon. It currently only shows when on a new line, this will now consistently show throughout the rich text editor, ensuring the user can easily add a block, or change formatting options no matter where their cursor is, this will ensure users can always easily access the controls.

How will this work exactly? If text is highlighted, will the plus icon always display the formatting options? And if no text is selected, show the insert/split block options? If so, that doesn't really solve this since in the case of inserting inline content (footnotes), selecting text will result in that text being deleted and replaced with the inline content. Apologies if I'm misunderstanding the intent, but the codepen didn't include the pinning functionality nor the plus icon.

Thanks!
@jsma thanks for the feedback, we don't plan on adding a user setting, as this opens the slippery slope to lots of UI items being user customisable, which ultimately ends in something that isn't scalable or flexible. The pinned/unpinned option will be saved to the user (we suspect via a cookie, but it could be server-side), with the unpinned version being the initial default as this is how the UI is currently presented. 

We've usability tested what we have so far, and all of the users understood the functionality, which is encouraging, but as always we'd love to have tested with more people.

The plus symbol that is displayed to the left of the rich text editor will always be visible now, so users will always be able to interact with this, ensuring that when they want to add something in, it's clear how to do this. As you note, the current functionality only shows the plus symbol when on a new line, which can become very confusing. 

We're also reworking the backslash functionality, so that you can enter / at any point to also reveal the same plus menu, this is primarily aimed at power users, allowing them to quickly build content using only their keyboard. 

So to clarify, you'll be able to position your cursor anywhere in a block of text (not highlighting anything) and click the '+'  or type '/' to insert things like footnotes without replacing any text.

The add menu that is displayed via the backslash or plus button adapts to the block it's shown in. For example if it's within a streamfield rich text field the user will see formatting options, followed by blocks, followed by the option to split the field into two blocks (these are all configurable/customisable by the developer). 

If it's within an inline panel rich text field, the user will just be shown formatting options (Embed, Lists, Headings, image etc, and your example of footnotes if the developer has allowed these options in the filed).

The unpinned formatting bar will follow the same rules as currently, it's purpose is to allow you to change the existing content, so when text is highlighted by the user, or double clicked on, the bar will display, and will give the option to make the selection bold, italic, change the heading level, coveret to a list, or a link (all of which can be customised on a field by field basis by the developer, so there maybe more or less options here). The pinned version will work the same, it's just that it's always visible.

I hope that helps, but let me know if you have any further questions.


> So to clarify, you'll be able to position your cursor anywhere in a block of text (not highlighting anything) and click the '+' or type '/' to insert things like footnotes without replacing any text.

Got it.

> The add menu that is displayed via the backslash or plus button adapts to the block it's shown in. For example if it's within a streamfield rich text field the user will see formatting options, followed by blocks, followed by the option to split the field into two blocks (these are all configurable/customisable by the developer).

If I edit a page (no pinned toolbars, nothing sticky) and I click the plus icon, will it display:

1. both the floating formatting toolbar and the existing horizontal insert/split block menu?
2. some sort of combined floating menu?

If the latter, how do you then pin just the formatting bits and dismiss the insert/split block menu?

I'd gladly help test any work in progress. Is there a public branch for this yet?
@jsma here is a link to a refined version of the code prototype we used when usability testing those changes, if you want to take a look: https://demo.draftail.org/storybook/iframe.html?id=docs--floating-toolbars&viewMode=story

Note the interactions are relatively truthful to what we intend to produce but not as refined, and the visual design is very much not what’s intended.
Thanks for sharing this prototype, this is very helpful! 

I may be still misunderstanding what @nicklee described above:

> The add menu that is displayed via the backslash or plus button adapts to the block it's shown in. For example if it's within a streamfield rich text field the user will see formatting options, followed by blocks, followed by the option to split the field into two blocks (these are all configurable/customisable by the developer).

In the preview, clicking the plus icon reveals a menu that does not include any formatting options but does include the standard add/split block options:

<img width="559" alt="Screenshot 2023-01-12 at 4 32 21 PM" src="https://user-images.githubusercontent.com/24574/212209818-c1b08197-5a81-4786-a41d-2bfb63ccab35.png">

Although I do see here the "Data" section which appears to allow inserting content such as emojis, images, and embeds. Is this where the "footnotes" option would land?

The formatting toolbar of course still requires selecting text before it will magically appear:

<img width="673" alt="Screenshot 2023-01-12 at 4 32 33 PM" src="https://user-images.githubusercontent.com/24574/212209850-88d30e3d-91f9-4550-a780-8b65918ec9b4.png">

This version of the formatting toolbar also includes the ability to add emojis, images, embeds, etc. so I'm assuming custom elements would also be available from the formatting toolbar, once it is pinned.

In the final version, the order of "Data" options will match the formatting toolbar, right? The formatting toolbar has the horizontal line button before the newline button, but the newline option is not present in the Data options and the horizontal line is listed last. I totally get this is a prototype, just want to make sure there will be consistency on where the options appear.

Speaking of, will this require changes to `RichTextBlock.features` or to `register_rich_text_features` hooks to distinguish between formatting and block options (with the latter being segmented out to appear in the add/split block menu)?

Thanks for enduring my questions! This preview was helpful and I think I'm starting to see the vision and understand how this might solve this todo. Thanks!

Resolving patch:
diff --git a/wagtail/admin/wagtail_hooks.py b/wagtail/admin/wagtail_hooks.py
--- a/wagtail/admin/wagtail_hooks.py
+++ b/wagtail/admin/wagtail_hooks.py
@@ -1126,6 +1126,7 @@ def register_icons(icons):
         "tag.svg",
         "tasks.svg",
         "thumbtack.svg",
+        "thumbtack-crossed.svg",
         "tick-inverse.svg",
         "tick.svg",
         "time.svg",


Test patch: