How to deal with wikitext like widget, macro in WYSIWYG editor?

Tiddlywiki is outstanding in its advanced widget and macro syntax, these are features that Notion and Typora will never have.

But here comes the problem, when writing these syntax in a WYSIWYG editor, how can we handle the edit, preview, and full size render after finishing? I will need some help designing this user experience.

(For information about this editor, see Demo of a new WYSIWYG editor: slate-write (unstable alpha stage),
and Demo is at Slate Write 板书 — A WYSIWYG MD & WikiText editor 一个所见即所得 MD、WikiText 编辑器 )

you can try <<locator-view baseTitle:"TableOfContents">> in the editor, and it won’t render immediately in wysiwyg edit mode, you have to quit and re-enter wysiwyg edit mode to make this macro/widget takes effect. I hope there can be a UI design to make this smoother.

1 Like

The way I have dealt with this in my work with WYWSIWYG is to intentionally not render widgets and macros and render them as plain text. The idea being that the WYSIWYG is for every day writing and widgets and macros are not needed.

The long term plan I had considered was to render all valid macros and widgets as read-only DOM nodes within the WYSWIWYG editor. The next step after that would be allowing clicking these read-only DOM nodes to open a dialog where you can tweak the attributes of the underlying widgets/macros.

One of the things that would help is to extend the parse tree with an optional WYSWIWYG mode in which the rendered HTML has additional attributes that help in mapping it back to wikitext.

Serialize things back to wikitext is trivial, you can just transform your editor state’s ast back to wikiast, then serialize wikiast. Just like mine slate-write/README.md at master · tiddly-gittly/slate-write · GitHub

I think in this low-code-era, more people will find widget and macro handy, and come to tiddlywiki from notion and logseq because of this. So supporting advanced block is needed.

allowing clicking these read-only DOM nodes to open a dialog where you can tweak the attributes of the underlying widgets/macros.

I think this is not possible, because there will be list widget (renders clickable links) and widget with button, so we can’t distinguish click the button from click to editable widget block. Unless we make that widget “read only” (or, preview only, non-functional, I mean). But I hope we can make WYSIWYG mode the default some day.

In practice I find that an always editable WYSIWYG interface offers a poor user experience when reading and interacting with an application outside of editing and can in fact be very prone to unintended changes when scrolling/reading.

Take Notion’s synced blocks as an example. While they have done well to allow the embedded block to be fully editable and moved the affordances for the syncing to a surrounding container, it is a horrible reading experience and confusing for those not familiar with the intricacies of Notion. So you have to choose between fully locking the page to offer a simpler reading experience and unlocking to be able to edit.

I have been thinking along the lines of a toggle that switches the tiddler between WYSIWYG editing and normal modes. The difference between the two modes being that in editing mode, macro and widget generated DOM nodes are disabled and cannot be interacted with. If done right this offers the potential of a UX where there is no large shift in user perception when switching between editing and viewing while avoiding the pitfalls of an always editable interface.

Could overleaf.com’s toggle between latex code and .rtf editing modes be a source of inspiration?
When in rtf It renders simple formatting in a wysiwyg style but falls back to a plain font for code, then pressing the button to render as .pdf. The preview pane is not updated live, only upon pressing the recompile button.
Stop-motion TW :slight_smile:

image

What you see is some of what you get and some of what you want! WYSISOWYGASOWYW editing. It’s the future!

I appreciate the value of WYSIWYG especially for authorship and prose and including simple macros and wiki text to include special elements and formatting in a tiddlers content.

Perhaps almost by definition when using list and other more advanced macros etc… which generate content what you is is not really what you get at all.

As a result if this I see value in the use of a preview along with the tiddler editor although this is desktop oriented.

It seems to me a two pain editor/preview may be the best solution, where the editor can be raw or WYSIWYG with or without macros expanded and an optional preview with or without macros expanded.

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.

2 Likes

But I still want real-time preview!

And overleaf seems don’t has a block-level edit/preview? It can only show full document in edit mode.

I think it’s good to let each type of syntax has its own special edit mode.

The best edit mode for a simple transclusion is what Notion currently has. But It will be hard to implement it in TW, because in TW there maybe transclusion template and maybe transclusion in a list…

But for widget, there can be a form that shows each variables (parameters) of that widget, and user can just edit widget using that form, without editing the real source code. Macro is the same.

I’m going to have block level preview, so we can see both source and preview just like before, but it will be block level. Othre blocks will still be in rendering mode. Only one block will have the source editing editor.

2 Likes

This is an excelent piece of work and wysiwyg a wonderful goal. Please keep in mind that someone using wysiwig is likely to also want to use wiki text and or markup because it is a form of shorthand and easier to do from the keyboard. Please do your best to support this mixed use case.

Oh, currently typing !!! to create a title is supported, like typora supports ### .

These simple elements are easy to support shortcut. For widget and macro, there won’t be such a shortcut, we can only use / menu to create them.