engram-design
commented
5 months ago I'll mention first that there's a setting for "Block Type Picker Behaviour" to be Hover, so that it doesn't require clicking on an empty paragraph in the editor.
As for the cursor showing, that's indeed not supposed to be happening, I'll look into it. It's a tiny bit tricky as we're using Tiptap which is fundamentally a WYSIWYG editor, so we're bending it a little.
I did toy with the concept of an "always on" button, but didn't quite know where to put the add buttons. But I think your mockup isn't too bad, and we could even drop the double add button when there are two blocks together just to simplify it a little. We've also considered adding a button to the "settings" menu item for the block, similar to Matrix/Neo to add blocks there.
Certainly taking this on board, thanks!
gregorydavidjenkins
What are you trying to do?
When using vizy with
editorMode: blocks, it would be great to have an option where the notion of the text cursor is completely removed.In the current implementation, If I have block A and block B and I'd like to add a new block (C) in between them. I need to know (as a user) that I can click the small space between the two blocks to get a cursor, and after that I need to know that to get a new block I need to type "Return".
It isn't intuitive for users, especially those without much familiarity with Vizy to jump in and create content, because it isn't "self-documenting". In other words, there isn't anything that would indicate to someone that they need to do that (click between, then hit return).
Also when I first begin editing a new entry the typical blinking text cursor (that you would normally see on a text field) is there blinking. Of course, typing doesn't do anything (which is exactly what I want, because of
editorMode: blocks). It is confusing for some of my users to see that very well-known bit of UI (blinking cursor) inviting them to type – and then nothing happens when they do.One interesting (and also confusing) exception is if they type "Return" they get a hard line break (the cursor does move down a line).
I understand that
editorMode: blockswas probably a late feature addition, but I think some small UX improvements could really elevate the experience by making it self-evident and obvious for untrained users what their next steps should be. Currently switching back and forth between the mental models of "I am typing into a text input" (which you need to do when you hit return to get a new line) and "I am selecting a node to add to this collection of nodes" creates friction to the content editing process.What's your proposed solution?
In blocks only mode it would be better to have the ( + ) [plus sign in a circle] UI always visible and instead of having just one where the imaginary cursor is, to have one in every position you can add a new node.
I'm attaching a screenshot of a proposed rough sketch of the UX I am envisioning.
While this is a little cluttered, it really clarifies what I can do and when I can do it. I don't have to click little space in between two blocks to get a cursor and then hit return to get a ( + ).