Auto Translation of my latest design, I’m going to try implementing it this weekend if nobody rise an opinion against it…
There are also view it on my wiki and use google translate, there are some screenshots of other WYSIWYG editor from my research this week. Note that this conclusion essay is completely written under Demo of a new WYSIWYG editor: slate-write (unstable alpha stage) - #5 by linonetwo
Warning! Translated with DeepL Translate: The world's most accurate translator (free version)
Requirements Analysis
Based on several of our claims, we will get several product requirements that need to be met.
WYSIWYG priority, default WYSIWYG
I hope that one day the default mode of editing TiddlyWiki will be WYSIWYG mode, so I want to be able to use in Edit mode all the functions of the current read-only mode, some of which are in conflict with Edit mode and need to be separated by additional actions: * special blocks with links, buttons, etc.
- Clicking in special blocks with links, buttons
- Conflicting function 1: Click to edit special blocks (low frequency)
- Conflict function 2: click to use the ability of buttons etc. in the special block (high frequency)
We can make the two-click areas staggered, and the click area of the special block may be the whole special block, so the one-click area has to be moved out of the area occupied by the special block. Based on the premise that the high-frequency function gives way to the low-frequency function, we need to move the click area that triggers the edit mode of this block to the outside of the special block.
Special blocks need to be previewed while editing
There are two possible ways for the user to enter a special block.
- entering a block with some innovation word by word, needing to show the edit box and wanting to see the result rendered in real-time, previewing trial and error
- auto-paste using the text snippet feature or copy and paste from a web page, which does not require much of an edit box and needs to show the rendering results directly
They both need to show the rendering result (and, based on the above, need to show it in the body area), and the difference is whether the edit box is shown by default.
In the case of special blocks that are already known, since they both need to show the edit box, the only relationships between the position of the edit box and the preview box are up, down, left, right, front, and back. Perhaps a right-click/hover menu could be used to allow the user to choose the display method.
Since the block has been converted to a special block and is no longer a paragraph block, it can’t be edited inside the body, it needs to be edited in a popup window separate from the body.
!!! Need to know it is a special block as soon as the special syntax has been entered
To show the edit box means we already know that the current block is a special block, but the default state of the editor is a normal paragraph block, so we need to convert the paragraph block to a special block according to some conditions.
Other products only have a special block for mathematical equations, and also use a syntax structure like paired $$ to indicate the beginning and end of the block, and convert the current block into a special block when the second $$ is typed. But this can’t handle copy-and-paste cases, and because TiddlyWiki supports more complex syntax, we can’t use the “convert when $$ is recognized” scheme.
The block on the WYSIWYG editor is only a temporary state because if you turn off and reopen the rich text editing mode, a paragraph block with special syntax will suddenly become a special block. This is different from products such as Notion, which is based on JSON storage. TiddlyWiki saves the content as text, so whether it is a special block or not will also depend on the content that falls on the text file. So we should parse the text content in time after the text is saved to analyze whether the current block has changed its nature.
- no additional operation program: in the save (did de-jitter, about 2 seconds once) refresh the parsing results, and the paragraph block will be converted to a special block
- Requires one additional keyboard operation: a drop-down menu like the
/ menu pops up at the bottom, suggesting that it can be converted to show special blocks
- Requires one additional mouse action: you need to click the ``Parse Special Block’’ button in the menu that pops up when you click the left grabber to refresh the display of this block
- No development volume but the difficult solution for users: exit and re-enter to refresh it
Interaction options
-
Input word by word (preview while typing)
- First, convert the current block to a specific special block via the
/ menu
- This will create a skeleton content of micro pieces or macros or formulas in the text because the editor creates the special block and then serializes the corresponding text after 2s
- This command tells the editor to enter live preview mode after inserting the text, showing a text input box on the side of the component (default is below)
- Show the result in real-time in the preview, or provide an error message
- Press ⏎ in the text input box to make a soft line break; press ⇧+⏎ for no special effect, also a soft line break; press ⌘+⏎ for a real line break, immediately leave the current block, switch to the paragraph below, close the input box, only the preview remains
-
type verbatim (no immediate preview)
- Directly enter the wiki syntax for the special block, at which point the block stays as a paragraph block
- Soft line feed via ⇧+⏎ to keep entering multiple lines of text in the same block
- eventually pass ⏎ or ⌃/⌘+⏎ for a true line break, which attempts to parse the previous paragraph and convert it to the corresponding special block
- immediately show the rendering result of the corresponding special block, e.g. show the rendering of the widget the user just typed
-
Insert a text snippet
- Insert a text fragment via the
/ menu and convert it to
- Create a special fast when creating a fast that really has to be called a special fast The special is in that he will constantly run a syntax check and then prompt the user below to convert to a really specific fast, For example, the micro-piece block, this fast will also be added in the future to the drag and drop low code editor
- Paste and text snippet paste immediately after a syntax check is performed in normalizing to determine whether to convert to a special block. In the drag button and /menu can choose to identify the wiki syntax, if identified, immediately insert a new ast
-
Open edit mode via arrow keys or menu
- Show the text input box below the preview block
- Place the cursor at the beginning of the text input box
Edit mode Text input box
- Contains the title of the displayed block category, the title area can hold some form elements for quick modification of the parameters in the block.
- no need to close the button, click outside the edit area, the editor loses focus and closes the edit directly, keeping only the preview
- Contains position adjustment buttons to switch the edit area to above or to the left or right of the component, or even turn it into a hover box and then drag it with the title.
- When switching from preview mode to edit mode, cancel the selection in the main editor and create a cursor at the beginning of the newly created text input box
- On mobile, show the preview and input box at the bottom of the screen like Notion; on PC, show the input box directly on the bottom of the preview in the editor.
Block menu
Click on the left gripper to open the block directory, or use the shortcut ⌃/⌘+/ to open the menu of the current block.
Entering edit mode
When opening the table of contents on a special block, the “Edit Mode” menu item is checked by default, while in other blocks the search box is checked by default.
