There are four bits of content there across three lines, and about 75% of the total space is wasted.
I attempted to shrink the title edit to half width (success) and the “Draft of” and controls to be on the right of that, thus reducing a line of space. But while I got it somewhat working, I reverted it because of a forgotten usability bug, and haven’t gotten back to it.
(I think my ideal would be [title edit field] [tag edit field] [controls] all on one line. I don’t think I need the “draft of” displayed, and the rest I’d prefer to be compact)
IMO that’s not true. Your tiddler does not have any tags. Tags are very common, so most tiddlers do have several of them. So the tag space has to be there.
The "Draft of … " text and the toolbar buttons on the other hand really waste vertical space. I did create a GitHub issue for that one.
The default UI also has mobile devices in the view. For mobile devices IMO the tag-input area is way to small. Removing a tag is a nightmare on my phone.
That example didn’t have tags only because I chose one that didn’t have any so as to minimise personal data leakage. The field to add tags is there in the screenshot, and I didn’t suggest removing it, only relocating it with the others on a line (though that may be the one that doesn’t scale well to lots of content. The other two essentials - title edit and controls, either handle overflow data nicely or are a static size). My failed attempt to resolve with CSS only tried to put the title and controls on one line, and I left the tag line alone.
In response to the original post: It’s an interesting idea. I’d love to see a POC/demo where:
Editing is Wysiwyg
Tiddlers are always in edit mode, imagine each tiddler is like a little Google Doc.
Would such a thing be possible? Difficult? I suppose there is a lot of core TiddlyWiki functionality related to the transition between viewing and editing. Perhaps there could be some kind of mouse focus driven transition, so when you click on a Tiddler all other visible tiddlers switch to view mode and the tiddler you clicked on switches to edit mode, but in such a way that there’s no (or at least only minimal) visible change in appearance.
I developed this further since for some editions that I manage but it isn’t a properly implemented WYSIWYG solution, rather a bit of a hack based on converting HTML back into wikitext.
I only wish the stuff I thought was finished worked half as well as the stuff you say is primitive.
This looks serviceable for quickly jotting notes. Then when you’re done, you can just go back to standard wiki mode. Maybe just a button to flip the two modes quickly would be useful.
Well, if you don’t mind modifying core tiddlers, a small change to eventcatcher.js would make this work.
First we need a new parameter to activate this behavior, since it might not be wanted for all double clicks:
Insert the middle line between the other two. This gives a new parameter cancelOnSelection which you set to yes if actions should not execute when text was actually selected by the double click.
Then,
Wrap the already existing middle line into the conditional statement.
Now, if the event was a double click, the actions are only invoked if the parameter cancelOnSelection is either not set or there is no selection.
A couple of questions for anyone with more experience with modern note-taking apps, especially of the WYSIWYG variety:
How do they handle drafts? (Or do they?) I don’t use the standard TW edit mode very much myself, but I do think one of its major strengths is that you don’t have to commit to any changes before you’re ready — and you can even save a wiki, including all your current drafts, without ever leaving edit mode.
I think this can be especially helpful when editing multiple tiddlers at once: if I’m cutting content out of one tiddler and pasting it into another, I don’t necessarily want those changes to affect the “live” tiddlers until both are in a finished state. And I wouldn’t want all my changes to be permanently committed the moment I click into another tiddler.
How do they handle more complex code like widgets? I can see the utility of WYSIWYG if you’re not doing anything beyond basic text formatting… but I’m struggling to see how it would work with a $list widget, for instance, or even a transclusion. Surely you’d want to preserve a visual distinction between transcluded content and content actually present in the tiddler you’re editing. How does this work if you’re always seeing rendered results — especially if there’s no distinction between edit and view mode?
I know there are some keyboard shortcuts that can help, but I generally don’t use them because remembering all of them can be a hassle. Another key issue is that they often conflict with other software on my computer. Furthermore, shortcuts don’t change the fundamental “edit and save” process; they just remove the need to use the mouse to click the buttons.
That’s a good question, but it’s primarily a rendering issue. Imagine you have some Mermaid code. If you change the code, the rendered diagram has to change too. Similarly, when we want to edit a widget like a list, we’re editing the underlying <$list> code, not the rendered output directly.
Of course, the code can be short while the rendered content is long, so keeping the two in sync needs more research. Maybe we could add a delay or a special button for a manual refresh.
In Obsidian, there’s a popular plugin called Dataview, which offers functionality similar to <$list>, and even has a more complex UI. Yet, the rendering issue hasn’t been a problem for users. From what I understand, many people love Obsidian precisely because this plugin allows them to organize their notes more extensively.
I’m not familiar with Obsidian or Dataview, so I looked around and found some screenshots that seem to demonstrate the way it works, courtesy of this blog:
What you’d type:
This is apparently the Dataview syntax for “all files that link to the current file but do not already have a link in the file”. It seems equivalent to {{{ [<currentTiddler>backlinks[]] -[<currentTiddler>links[]] }}} (or perhaps a $list widget version thereof — I’m unclear on whether Dataview allows you to assign display templates to your results.)
What that would give you:
So… this looks more like edit mode than WYSIWYG to me — perhaps with double-click-to-edit? It’s not clear in the screenshots I found, but perhaps Obsidian also supports editing a single section at a time1, rather than editing the entire note (or “file”) at once?
If so, it looks like you’re still clicking to enter/exit editing mode. And you alluded to the division between code and rendered output, too:
I guess my question is, how do you see an improved system differing from the editing methods we already have? Is the “section editing” the most important aspect?
1 For anyone looking for section editing in TW, @Mohammad’s Section plugin is a good starting place. In theory, it might be possible to modify his plugin so that it splits editing “sections” at the paragraph level rather than at headers… but linebreaks can convey parsing information in TW, so I’m not sure whether this would really be a good idea.
Keep in mind if you include items in the view template that appear on selected tiddlers, you can introduce code to edit the current tiddler. Typicaly we would not edit only parts of a tiddler with tiddlywiki script in the text field but edit specific fields on the tiddler. These fields value may then be referenced via the template or in the body such that a change to a field is reflected the output.
There remains three ways (at least) to edit a field, in edit mode, in a temp field/tiddler then one done update the field, or edit the field directly (which may cause issues if only partially edited.
While I’m not a fan of WYSIWYG, I created a liveNotes using just a few lines of wikitext, and it works simply and quickly. The real tiddler are stored under $:/livenotes/data namespace. It can be extended for simple note-taking. On the other hand, the typewriter by @saqimtiaz offers a complete solution with a minimal UI.
I think you’ve misunderstood. I’m not suggesting we port the Dataview plugin from Obsidian to TiddlyWiki. I was simply using it as an example to explain that even with TiddlyWiki’s extensive use of wikitext code, the rendering issue can still be solved. It would just require rethinking how rendering and styling are handled. Of course, this would involve changes to the core design, so I’m just raising it as a potential feature.
I know there are many ways to edit and save content without clicking a button. For short ideas, I also use edit-text to quickly edit and then click a button to automatically save it as a tiddler.
But that’s not what I want to discuss. I want TiddlyWiki to be like other note-taking apps where you can open a tiddler and start editing immediately, with changes being saved by default. This would eliminate the extra steps of clicking an “edit” button and then a “save” button.
I also use TiddlyWiki for more than just note-taking, like for a blog, task management, or as a reader. However, I don’t think this is a reason for TiddlyWiki to not make a change. Obsidian and SiYuan Note, for example, both offer a reading view that can be set up as a website for others to visit.
No, I didn’t think you were suggesting that. Since you offered it/Obsidian as an example, I wanted to establish
How it is rendered in Obsidian — not the technical, behind the scenes details, but what the user experience feels like, and
What aspects of this user experience do you think TiddlyWiki is missing?
As I said, I’ve never used Obsidian, and in my admittedly brief investigation, what I saw of how it handles editing of complex, widget-like features (like Dataview) looked a lot like TiddlyWiki. But you’re certainly more familiar than I am, and I’d gotten the impression that you thought Obsidian offered a better editing experience, so I’d hoped you could expand on the ways in which you think that’s true.
Wouldn’t we then lose the draft system — the ability to work on a tiddler (or multiple tiddlers simultaneously), even across multiple sessions of TW use, without immediately overwriting existing content? I think the ability to test changes (e.g. with the preview window) before committing to them is actually a major strength of TW — especially since a malformed filter can have major consequences for rendering, and may even freeze/break the wiki. I’d hate to think that there was no easy way to roll back a bit of code that had caused a RSoE error.
I believe the existing edit-and-save process for tiddlers in TiddlyWiki is a significant area for improvement. The repeated cycle of editing and saving wastes a considerable amount of the user’s time and attention over thousands of edits. In my opinion, this workflow discourages users who want to quickly capture and input ideas. While long-time TiddlyWiki users may have grown accustomed to it, I think it’s a critical flaw that hinders wider adoption.
To change this, the draft mechanism would likely need to be re-evaluated. An early advantage of TiddlyWiki was the ability to edit multiple tiddlers in the story river at once. I’ve always had a different view on this, as modern word processors and note-taking apps also allow you to edit multiple documents simultaneously, often with easy-to-switch tabs or side-by-side views. The difference in TiddlyWiki is that you have to scroll to a specific location to find and edit a tiddler, which I find to be a time-consuming process, especially when I have many tiddlers open.
I see the draft mechanism as a double-edged sword. While it provides a way to preview changes before saving—acting as a safeguard against errors—many modern note-taking apps also offer a preview function without requiring you to click “edit” and “save” buttons. Furthermore, drafts don’t completely prevent issues. Users will inevitably write incorrect wikitext, and relying solely on a draft mechanism isn’t a sufficient protection. Everyone needs to back up their TiddlyWiki files, and the ability to roll back changes is essential to avoid data loss.
I think we’re broadly in agreement. I’m not very fond of the default tiddler edit mode myself; I use a lot of custom view templates that let me make real-time “inline” edits when I’m adding wikitext content, and in these instances I do bypass the draft-editor completely. But even these custom templates have inline edit/save buttons to toggle between viewing and editing, and I still can’t conceptualize any workable alternative.
In a WYSIWYG envionrment (most word processors, for instance), you’re effectively always in “edit mode”, and this is possible because you’re never writing any complex script: instead, changes are handled by buttons/keybindings. But while we have some examples of WYSIWYG wikitext editors, like Saq’s Typewriter, I’m not sure how they could handle more complex constructions like widgets or procedures. For that, I think you really need an editing mode to work with the unrendered code, and a viewing mode to render it. This is why I asked how programs like Obsidian handle it: I wondered whether they had found some hybrid solution that hadn’t occurred to me. From what you shared (and my brief Googling), it doesn’t look like they have — but I’m very open to correction.
I think the fundamental issue here is that, in TiddlyWiki, everything is a tiddler, and in vanilla TW, all tiddlers can be edited using the same mechanism. This creates a fundamental tension between what’s optimal for editing simple wikitext notes (in which case a WYSIWYG environment would be ideal) and what’s optimal for editing template tiddlers (likely to contain far more wiki “script” than wikitext) or the functions/procedures/widgets which are themselves used as building blocks elsewhere in the wiki — for which it’s helpful to have an “editing” step in which changes are not applied in real-time.
Vanilla edit mode does offer some alternative UIs depending on the type of tiddler; an image tiddler or a data dictionary has different editing options than a standard tiddler. However, these alternate edit modes are applied on a per-tiddler basis; they don’t handle “mixed” cases, which may use wikitext and wikiscript in the same tiddler or even in the same paragraph. I think a system that prioritized WYSIWYG text editing would be less flexible in where and how you can use (and edit) wikiscript.
Addendum:
I agree! But they do reduce issues. I do backup my wiki regularly — every time it saves. But it would still be inconvenient to have to go back to a previous save just to revert a change to a work-in-progress tiddler. I appreciate that the draft system doesn’t overwrite a previous version before I’ve had time to do at least some first-pass scanning for potential problems in my code.
The clever thing about Obsidian is that you edit the current line in plain text, while the rest of the text is rendered. They used this in Dynalist as well. So you get the best of two worlds.
