On canvas text tool
We need an on-canvas text tool. Such a tool has advantages (very intuitive to use) and disadvantages (one small UX mistake and it's suddenly not intuitive anymore, not to mention a whole bunch of bugs). The latter is why we've avoided this feature, preferring to use preexisting text-edit components. None of those text-edit components will be able to display the results from the new text shape, on top of themselves having several bugs with non-latin script.
Before we can start on the text-tool itself, we will need a simplified programmatic way to edit the text-shape. This will be tracked in #6 .
After that, we will need to figure out how to handle the usability.
- The most common way how text-tools UX is handled is by having an on canvas cursor that can select stuff, and a sidebar/toolbar/docker that with buttons to change the selected text range to a certain format. I am not confident we can get this to work without leading to focus-problems.
- Focus problems are the most common problem with text handling: If someone clicks a different button, the focus on the canvas will be lost, and thus typing will stop working, as well as stuff like shortcuts. Which leads to workflow interruption and will get old fast.
- We will need to make sure the cursor indicates somehow that the text/canvas has focus, typically this is done by whether it blinks or not. However, most people will not be able to see this, which means a focus keeping solution will be of utmost importance.
- We could put everything in a context-menu like the pop-up palette, but that would make it hard to use on mobile.
- It's getting more common on the web to have an overlay that hovers over or near the text, but we need to be careful that this doesn't interfere with viewing the text in context, or otherwise gets old fast.
- People have asked for favouriting fonts, and while I am unconfident that this can be done (fonts as a resource is something that seems to complicated to me). However, given there's more than 20 possible toggles associated with text-styling, having a preset system for text-styling as a whole might make more sense.
- We will need to consider what to do with shortcuts.
- Stuff like 'bold' and 'italic' don't work in all scripts, so it doesn't make sense to hardcode these.
- If we allow people to favourite styles and have them set to shortcuts, we're inevitably going to get someone who wants 20 shortcuts, and the next 50 shortcuts associated with styles. We cannot dynamically resize the amount of actions, so should we just offer 99 shortcuts for text styles???
- We need some UX for paragraph level style editing. This includes stuff like the type of shape or wraparound or text-path attributes.
- We will need to figure out a way to edit the shapes and text-paths themselves.