A very specific kind of outliner

1

Update: Just pointing out that the latest version of this project is always at https://crosseye.github.io/rham-policy, but I’ll point to specific versions here as I create them.

Background

A few times last summer, I discussed my attempt to convert a school Policy Manual from a collection of ~140 PDF files into a single wiki. (The most thorough discussion was at #13430, and it links to the others.) I put that aside but recently came back to it. The reason for the delay was that I was really not sure enough about an outline editing interface for TW novices. I’m trying to address that now, and I’m hoping this group can give me some feedback.

I plan on doing the initial conversion of the files myself, but then I want to turn it over to someone else. I’m assuming that someone would be the Superintendent’s administrative assistant. She has no experience with TiddlyWiki (I assume – I’ve never asked.) So I’m trying to create an editor that would be intuitive enough that I could show it to her in an hour or so and she could be working with it right away.

Request

If you’d be willing to try it out – mostly editing existing Policy documents to see if this is useful, I would appreciate it. It’s live at https://crosseye.github.io/rham-policy/0.7.3/. The first three sections of documents (1000’s, 2000’s, and 3000’s) have been converted; most of the rest are just placeholders. I assume I don’t have to tell you that you won’t harm anything by making changes, saving locally, whatever.

If you open one of these documents, you will see a new view toolbar icon, image 1, that will launch you into my edit mode. Poke around, see how it goes. I’ve spent no time worrying about initial document creation yet. If I can’t get editing existing documents right, I have no hope of that.

Note that this also includes some enablement for a workflow. Documents are not edited willy-nilly. The flow is dictated by our Board’s bylaws, and proposed changes are made generally by our lawyers or the Superintendent, at the Board’s direction. But then they go to the Policy Committee for review, which might introduce further changes. After that, the whole Board discusses them at one meeting, and again might introduce changes, and then votes on them at a subsequent meeting. If there are serious concerns at any level, the process might restart at any step. So the tool allows for a current document and a number of named draft versions, which might branch off one another at different points. Eventually the draft is approved, and there’s a “Promote” button here to archive the current version and make the draft the new version. (Archived versions are just stored in CompoundTiddlers; there’s not yet any mechanism to unarchive them.)

But the main point here is to be able to edit whichever version. So the editor follows the hierarchy defined in the Policy and presents it as editable sections. That’s mostly what I hope you’ll be able to test. Does it work? Is it reasonably intuitive? What suggestions do you have for enhancing it? (Please note the two tabs, Preview shows you a rough rendering of the final document, letting you edit one section at a time. Structure shows you just the hierarchy, still letting you edit sections, but also move things around.

I have also started separating out the workflow and outline handling into a reusable plugin; while it’s going reasonably well, I’m a little stuck and wondering if it’s worth pursuing. So I’d like to know if this is something you imagine ever wanting to reuse?

Wiki design

I have a few design goals for this wiki: most of them familiar to TW users. I want to consolidate this information into a sharable document. I want every policy to have a clear, permanent home. (Right now you have to navigate through an obnoxious SharpSchools-powered early 2000’s paginated web interface to even find the right PDF.) But more than that, I want even small subsections to have their own URLs, so that I can point to, for instance, Policy1410(C)(3). That also involves my obsession with clean URLs.

Note that I am trying to keep the document looking as much like the existing PDFs as possible in a web interface. If this Policy uses I. Roman / II. Numeral / III. Headings, and that one A. Just / B. Uses / C. Letters, and a third one has ALL UPPER CASE TITLES, I want to support them all. That leads to a fair bit of complexity.

The actual tiddler structure is explained in detail in the link above. But briefly, each section in an outline is its own tiddler. It has a display-style property which describes how it lays out its children (inline, bullets, headers, etc.) The parent-child relationship are carried only in the title structure: Policy1410(something) is a direct child of Policy1410 and its children all look like Policy1410(something)(next-level), and so on.

This is not really a wiki. There will only ever be two or three editors at most. The content won’t be edited much more than monthly, usually not even that often. Many policies will remain static for many years.

Instead, it is a use of TW for some of its other features: the easily-sharable single file design, the ability for Policy Committee members to take their own copies and make suggested edits, the searchability (entirely missing from the static PDF version), etc.

Thank you

Thank you for any feedback you can offer, at any level. This has been a one-man show, and I really would love to hear what others think, even if it’s just, “What, are you crazy? That’s a stupid idea!” :slight_smile:




1And if you know of a good icon for a (document) outline, please let me know. Searching for it is hard, because there are few good synonyms for “outline” in this sense, but it’s used in the silhouette sense all the time when discussing icons. Or if anyone has a better design, I’d appreciate hearing about it..

2

Ok, at least one thing was easy enough to fix. This still isn’t wonderful, but it will do for now:

outline-button

3

If this is intended for a general audience, it would be better to use a more widely adopted technology, such as Markdown. Using Markdown also makes it easier to integrate with version control tools.

It seems TiddlyWiki is intended to handle the interactive components. This is indeed one of TiddlyWiki’s strengths.

Using TiddlyWiki as an indexing tool for PDFs also appears to be something it excels at.

It looks like the branches cannot be edited; only the leaves have that editing capability. The “Add Section” button does not respond. I’m not very familiar with the workflow, so I don’t fully understand the purpose of the various buttons. It appears to be a solution tailored to a specific enterprise and lacks value for broader adoption.

4

It might be a good idea to use Markdown syntax for the editing rather than wikitext, so long as macros such as my <<sections>> and <<cgs ... >> still work.. I’ll think about it. If you’re suggesting, though, something like one of note-taking or documentation tools that work with multiple Markdown files, that won’t work for my use-case. I really want the single-file deployment.

It’s more about the fact that this is single-file, but still quite dynamic.

Well, I’m able to edit pretty much any section, so I’m not sure what you mean.

Oops, wonder when that broke!

I suspect you’re right. It’s useful only if all of these are true:

  • You have formatted outlines to maintain
  • The outlines have radically different structures
  • You want each part—large, medium, or small—to be addressable

I don’t think the audience is very large. It’s just not clear to me whether it’s just an audience of one!

Thanks for the feedback!

5

Have you considered developing this software based on Kookma’s section plugin?

The kookma plugin automatically generates heading styles like “1.1.1”.

It seems the heading styles in your app cannot be changed. Doing so will result in an error.

Since there is no user manual, I can only figure out how to use it by trial and error. I gave it another try, and now I have a better idea of how the app works.

The Tiddlers created after clicking “Add Section” are given random names, making it difficult to find the specific Tiddler you’re looking for.

polycy-nbr was not generated automatically.

I don’t know how to add a section under “Overview.”

I don’t know how those policies ended up listed under that section either.

If there is a blank space in the title, it generates multiple tags in children.

I don’t know how to add a preview to Tiddler.

On my end, only the leaves show the outline icon. The branches do not show the outline icon.
->So far, I’ve noticed that if there is a “Policy” tab, an outline icon appears, and you can edit it.

The “Add Section” feature only works in the ‘Structure’ tab. It doesn’t seem to have any effect in the “Preview” tab.

This outline editing feature appears to be designed for general users. The “Draft” feature also seems intended for general users. However, strings like “Return to Policy” and “Add Legal Reference” do not appear to be intended for general users.

6

I would love to, but the constraints are too tight for that. I really must keep the documents structurally identical with what are now our legally adopted polices. For instance, glance over these three PDFs, to see just a few of the structures I need to replicate:

And there are many more. I cannot use a fixed hierarchy. I’m hoping one day to normalize these, to simplify this to just one, or just a few structures. But this won’t happen soon, if ever, and I may be stymied by various legal requirements for the policies.

Could you explain more? I’m not quite sure what you mean.

Hmm, if I only use this as a one-off with at most two or three users, that’s probably not necessary. But if I do make a clean separation of a core plugin and specific policy manual plugins, then that will become important. It’s more work, but essential. It will still be some time before I get to that, though.

When you first add a child to a section, you choose the marker style (I, II, III, ..., A, B, C, ..., 1, 2, 3, ..., etc.). Any subsequent children just use the next marker. As things are saved, the Policy information in the sidebar menu should show you the entire hierarchy, with each section a link to the tiddler.

It absolutely shouldn’t be. There are norms and quasi-standard numbering conventions for policies, at least in Connecticut, USA.

This is only for Policy documents, those tagged Policy. Overview is not a policy. More generally, in the reusable plugin, this would only be for tiddlers tagged Outline, a name which is overridden in this policy manual. (I’ll discuss this more below.)

Hmm, I thought I’d removed all tag generation. Could you explain what you were doing when this happened?

As mentioned above, this is only for those tagged Outline (in the plugin) or Policy (as overridden here), which I think also answers this:

Oh, I didn’t notice that it was showing in the Preview tab. I didn’t mean for it to, but I actually want to eventually combine these two view, with collapse/expand to make the two views show like one another, and have the action buttons appear on either one. I started with the structure view, and only added the preview one later; I think making them two tabs was a mistake, but it did make working through things easier. This dialog is a good sign that I should make that change.

I wrote this entirely in the Policy Manual, but I started extracting it into a reusable plugin, crosseye/outline. You can also look at the overrides that this policy manual adds to the plugin. For instance, the tags Plugin and PluginDraft are overrides of the values of Outline and OutlineDraft in $:/plugins/crosseye/outline/config/tag and $:/plugins/crosseye/outline/config/draft-tag. And there are many display styles included in the policy manual that aren’t (yet?) in the plugin.

The biggest question here is whether it’s worth continuing to build this in a plugin/override fashion. I really want to hear about the usability of the UI I have so far, and hope to use your feedback and that of others to improve it.

However, I do expect to continue this work until I have a workable Policy Manual, with the best UI I can build. What I’m really not sure of is whether I should make this into a reusable plugin as well. Doing so is not terrible, but it does add work to the project. If no one would ever use that, then it’s just overkill.

Again, thank you for the feedback. It’s been very helpful. And I’d love to hear more if you have time.

Everyone else, I’d love to hear from you too!

7

I did post a new version with a few minor fixes. It’s at 0.7.4. And I will update the OP to point out that the latest published version is always at https://crosseye.github.io/rham-policy.

8

And there is another version, which consolidates the Structure and Preview modes into a single view, with collapsible sections. It also adds a PageControl button to create an outline, overridden for this policy view.

I think the UI is improving, but would love your feedback!

9

This time I found the explanation in the plugin.

The error when changing the display style might be because I previously turned translation on and off.

I couldn’t figure out where the parent-child relationship information was stored. Later, I finally discovered that the source of the parent-child relationships and their order is the title.

[bug] “policy-nbr” remains in the plugin.

[bug] Automatically generated tags still exist. However, it appears your system does not rely on tags.

Whitespace in tags

Create a new tiddler titled “new tiddler.” Add an “Outline” tag. 
Edit the outline. Add children. 
At this point, a child like `new tiddler(1)` has two tags: `new` and `tiddler`.

To promote the plugin, the demo needs to be converted to a clean version. The current demo has issues:

It does not use <<section>>; instead, it uses a different macro.

The `Outline` tag does not work. Only the `Policy` tag works.

The plugin’s README is not displayed on the home page.

Regarding <<sections>>

The <<sections>> functionality is quite limited and cannot achieve the nested effects seen in structure or preview. Your intention is to distinguish levels using different methods such as letters or Roman numerals. This is one solution, but it limits the number of levels.


(1)

(a)

(b)

(2)

(a)

Is it necessary to extract a generic plugin?

Your data structure is: the title is a number (t(1)(a)). Node relationships are stored within the numbered title. This is the defining feature of your outline editor. Your outline editor is built on this data structure, with a complete editing system tailored to it. The current editing system is already quite comprehensive.

This approach is common in formal documents. However, I haven’t seen it in computer systems before. It’s actually a pretty good approach.

This differs from the TiddlyWiki philosophy. One manifestation of this is that TiddlyWiki’s search functionality isn’t compatible with this approach. But this can certainly be viewed as a standalone system.

The reason this outline storage method isn’t widely used is that it cannot be separated from the editing system. I’ve developed such an editor myself. The numbering is automatically generated. Just like in wiki software, text-based links ([[SomeWords]]) are more common than numbered links ([[123]]). Numbering has its advantages—it avoids the need for relinking—but it increases cognitive load. People generally prefer automatic heading numbering within the display format, as seen in Markdown.

Strengths of the outline-editor:

  1. Compared to tree macros, headings are more concise.

  2. Compared to streams, headings are more meaningful.

  3. Compared to tags, If we define tags in terms of their hierarchical relationships, they can also be considered outlines. In other words, outlines are a subset of tags.

So, in the end, it was tags that went head-to-head with the outline editor.

We need to hear everyone’s opinions on how to weigh the pros and cons. How many people actually need this data structure?

10

I’m sorry. I guess that was pretty buried. I did mention it in the OP, but only in one sentence pretty far down:

Definitely a bug. I’ll try to look into this tonight.

No, it doesn’t. I’m still having trouble replicating this.

Hmm, I’m still not seeing the multiple tags, but there are definitely bugs in that workflow.. I’ll look more this evening.

Well, remember that this is a wiki I’m working on, and the extraction of a plugin is mostly an afterthought. I’m trying here to judge whether the continued creation of that plugin is worthwhile, whether anyone would use it. So this is still my wiki, not a plugin demo. I do have one that uses the raw plugin, that I’ve been using as I try to separate the plugin from the core. I’ve been reluctant to share it, as it’s rather anemic. But I guess it doesn’t hurt. It’s at http://scott.sauyet.com/Tiddlywiki/Demo/OutlinePlugin/.

You can see there some of the gaps. I haven’t ported the breadcrumbs tools nor the TOC used in the Policy Manual to the plugin. And there are other more minor features as well, plus probably many bugs.

As far as I can tell, I use <<sections>> whenever it’s needed. (That is, for nodes that have children.)

That’s intentional. The Policy Manual overrides that tag. (config/tag), which contains “Policy”. Note that in the plugin itself, (config/tag the value is “Outline”. There are other instances of such overriding of the core

I see it where I expect it, at $:/plugins/crosseye/outline. Are you expecting it somewhere else?

Yes and no. This allows me to match documents which use different structures, such as Doc1(II)(A)(3) or Doc2(D)(iv), or whatever the original PDF had – they are far from consistent. But there’s nothing to prevent me from reusing a marker style at a deeper level, such as Doc3(4)(C)(ii)(a)(7). (here the 4 abd the 7 are the same marker style at different depths.) I hope I never need to go that deep, but it’s available if I need to.

There are two separate notion that work together. One is marker-type (such as I, II, III, A, B, C, 1, 2, 3, etc.) The other is display-style, which handles how the markers, caption, and body are laid out for each of the node’s children. They come together to encompass the difference of layout between these two tiddlers:

  • Policy1340(III), which uses marker-style A, B, C, and display-style definition-quoted
  • Policy1350(s5), which uses marker-stle 1, 2, 3, and display-style definition

The different marker-types should be clear enough. The only difference between those display-styles is the fact that the terms in the former one use quotes around their children’s caption output, and the latter doesn’t.. There are right now eleven different displays-styles in the policy Manual: “definition”, “definition-inline”, “definition-prequoted”, “definition-quoted”, “heading2”, “heading3-underline”, “heading3-upper”, “list”, “outline”, “outline-block”, and “plain”. Right now five of these are included in the plugin: “definition”, “heading”, “list”, “outline”, and “plain”. It’s probably not enough, but I hesitate to add more until I understand the needs better.

Yes, that captures it extremely well!

Can you explain why? I haven’t had any problem searching within this app. A search term just brings up the specific tiddler that contains it. That would be true in a tag hierarchy as well. While they’re not yet in the outline plugin, the breadcrumbs at the top of any policy section let me navigate back up the tree to the Policy or even the Section of Policies. But yes, it would be useful to enhance the search to show not just the detail but the whole containment hierarchy, up to Policy. I’ll have to think that through.

That’s a very insightful comment. I hadn’t thought about it in those ways, but it’s clearly an interesting way to think about it.

This whole design actually grew out of an objection to using tags just to satisfy the current TOC models. I started doing it just with tags, but I really didn’t like the pollution of the tag space implicit in tags like Policy3265(V)(s3). That’s how I came up with the predecessor to this design. But that one used a large number of fields to generate what was a much simpler hierarchy.

You can see this in the live document (CTRL-SHIFT-1 toggles between edit and read-only modes.) If we edit Section230(c)(2), we see:

image
image832×665 29.1 KB

All of those fields were necessary to maintain the hierarchy. The current work is in part simply an attempt to prove out that we can do this with just the title structure.

And that is still my main question. I’m going to continue building this policy page regardless; I have need for it, even if it never gets approved by the Board. But I don’t have to continue with the extraction of a plugin. So I do really want to know, if I do so, would others use it?

As always, @tomzheng, thank you for the invaluable feeback!

11

I found a bug on this forum: the content looks fine in the preview, but the word order gets scrambled after posting. So I’m quoting it here.

Create a new tiddler titled “new tiddler.” Add an “Outline” tag. 
Edit the outline. Add children. 
At this point, a child like `new tiddler(1)` has two tags: `new` and `tiddler`.

What I mean is, if people are opening your TiddlyWiki to learn about and try out the outlining software you’ve developed, it would be better to place the plugin at the top. That way, when people read the README first, they’ll know how to use the software. Also, I didn’t realize you’d turned the software into a plugin until later—I only found out after the fact.

I mean, the official TiddlyWiki search doesn’t search captions.

Once you officially release this plugin, I’ll share my requirements:

  1. Display all nested content within a single tiddler. This should be exportable, similar to the preview, but without indentation.

  2. Building on point 1, use a numbering style like “1.1.1” before headings to indicate nesting. Using only numbers instead of letters or other characters reduces cognitive load and resolves the current issue of being unable to modify the numbering style.

  3. In addition to the macro in point 1 that includes all content, two additional macros are needed: a. A macro containing only the structure; b. A macro containing both the table of contents and the full content (with the table of contents on the left or right). These macros are intended to facilitate document export.

  4. Compatibility with Markdown.

More

Tiddlymap used to assign an identifier to each node, but tw5-graph currently removes these identifiers.

In my opinion, both approaches are necessary. Having identifiers makes it easier to make changes, while not having them eliminates the need for copy-and-paste.

In situations where duplicate content is permitted, a unique identifier is required. In other words, in the context of an outline, tags are not a good solution.

Another advantage of placing the information in the title is that it is compatible with the file system.

12

Are you using this on the Policy page? An Outline tag shouldn’t mean anything there, nor should you be able to open it in the new editing interface. That’s why I’m confused by your instructions.

Well again, that’s not the point of this page. I’m still not even sure I will release this plugin, not until I find that it does something people want. But I will be sure to point people to that README if I ask more questions about it.

Well, again, I’m not sure I will release it. But it sounds like your requirements are very different from mine. I doubt that any version of this will ever get close.

I didn’t get to work on this at all this evening, and the next two are very busy, so I may not get back to this before the weekend.

I don’t know if you’re actively working on a solution for your requirements. I hope so, because I really would enjoy seeing what you’re up to.

13

If you install this plugin on a blank document, these are the steps for creating an outline, right? The only thing I did differently was to keep the default title for a new tiddler—“new tiddler”—without changing it.

My current focus is on exporting. I’ve noticed that no one seems to be paying attention to the end result of the work: the export.

I haven’t put any effort into this aspect yet. I probably don’t have the capability to handle this task either.

The export result I’m hoping for looks like this: Old Release notes | Org mode

I’m still really looking forward to your work. As I mentioned in the “more” section of my previous reply, your outlining software is unique and irreplaceable.

14

I’m very sorry. This explains a lot. I thought I’d made it clear that the plugin was not ready yet. I paused working on it in order to ask the questions here. Clearly that failed. I apologize. The plugin is a broken state, and I’m not sure precisely what does work. The current Policy Manual code, including what’s now in housed in the plugin, is the work I’m looking for people to test. If it turns out to be useful to others, I will continue separating it it into its own plugin. If not, I’ll probably reabsorb the plugin into the main code.

I think that’s probably because most of us view our wikis to be the end result. In some wikis, I do pay attention to how it looks printed. But even that’s rare, and I’ve never gone further than that.

But that explains some interesting questions and comments I’ve seen from you in other threads. If the wiki is just a way station for you, then you certainly have different concerns than I would.

Hmm, I suppose I could see generating an output like that out of the work I’m doing. It wouldn’t be close to the core of what I care about, but it certainly sounds doable.

Well, thank you. If nothing else, it’s been interesting to work on.

15

That’s right. My top priority when choosing software is that it allows me to import and export data.

16

I certainly understand and respect that. And while TW technically makes it easy to export your tiddlers in various formats, its structure is not one you can simply import into other tools.

Unfortunately, I don’t believe there is anything that can reasonably be done about that. We have the static site generation; we could probably extend that to generate Markdown instead of or as well as HTML. But we would lose a lot! TiddlyWiki is designed around tiddlers, not documents. And tiddlers are not static snippets. We have transclusions, macros, procedure, dynamic lists with sophisticated filters. None of that translates over to collections of Markdown documents, not in any way I know of. So while we might be able to arrange tags/fields/titles with some filters and lists to generate the sort of output you mentioned, it would probably not be in a format even close to suitable to regenerating the wiki.

While I understand, and mostly share, your requirement that tools don’t lock up your data, TiddlyWiki is for me something of an exception. The data is always yours. While it doesn’t make it easier to change tools, it also doesn’t ever try to hold on to your data.

17

Actually I think TiddlyWiki really is possibly the easiest tool to move content out of (or into). Of course it all depends on straightforward design of your content and design such as not unnecessarily mixing data and code but even then if the output included a little additional code would not hurt. But even a poorly designed wiki is easy to add a batch process to prepare data for export if not directly via an exporter.

On a per-tiddler basis this is trivial and offers many routes and formats to export.

At a high level when it comes to export;

  • The default exports are good and arguably easy for other systems to ingest
  • It is quite simple and easy to build new exporters to generate almost any output format
  • The node version also gives you multifile batch export opportunities
  • Similarly use the zip plugin to pack a zip with multiple files for multi-file generation, with one download
  • In many cases other apps and tools could interrogate the JSON tiddler store in the wiki file directly, or files directly under the folder wikis.
  • When preparing an export ask yourself if you are happy with the raw data such as the text field or do you need TiddlyWiki to process or render the content first, before export.

I think it is important to recognise it is very easy to leave TiddlyWiki, but very few people seem to.

18

The default web export is a far cry from the rendering results of standard Markdown files. I once suggested on the forum that TiddlyWiki should offer a linear file export above a baseline (Compared to the non-linear TiddlyWiki). After all, only a minority of people are proficient in programming.

19

I think this misses an important point, though. The basic question is about interoperability. Can you export into a format that can be used in other systems; and can those systems write back to a format TW can import with no loss of functionality?

A number of tools can write to a collection of Markdown documents with front-matter, and read back from such a collection. For some, that’s already their internal storage mechanism. There are compatibility questions of course with their equivalents of our macros, and plugin mechanisms make this harder. But there is real possibility.

They are interoperable in a way that TiddlyWiki is not, and probably can never be. The problem is one of sophistication. We could clearly write an output format that could be imported into Obsidian; it would be nearly impossible to write one that could then be reversed: write an Obsidian converter that generates the equivalent of your original wiki.

Perhaps you write wikis of such “straightforward design” that you could do this. I can’t see how even the simplest of my own wikis could ever do this. I have cascades, macros, procedures, transclusions, ViewTemplates, sophisticated filters. If I were to try to turn, say, a sample order from my SQL Playground into something suitable for inclusion in Obsidian1, if I then tried to pull the results back into TW, it would probably not have any of the same interactivity. If I wanted to add a footer that noted that this was Carlos González’s very first purchase of Gumbär Gummibärchen, I would not be able to update a shared ViewTemplate that captures this for every order. I would have to manually change each one.

Or maybe I’m mistaken. Maybe these other systems have a similar flexibility that we would just have to map back and forth. I don’t know them well enough to be sure. But my impression is that they simply couldn’t support much of what makes TW so powerful.



1 I talk about Obsidian, but the same things are true for Roam, Logseq, Joplin, whatever. Or so I assume; I've tested many of these, but never did much more than scratch the surface. They all felt so limiting.
20

Scott, I understand the capacity to import and export content from TiddlyWiki from the systems level. I tend to design content like a database admin and keep the data model separate from the user interface, fortunately this is encouraged although not enforced by TiddlyWiki.

Of course if the content is more like websites including sophisticated user interface components and it is used for generating websites that needs a different approach, but HTML is a good “language” to use.

When it comes to data it is easy to export data as tiddlers or text, csv, JSON, HTML Tables and within text we have multiple options such as tiddlywiki wiki text, markdown etc… In all these cases we have opportunities to choose formats and design solutions.

  • With sophisticated mark ups etc… the markdown plugin can be used to export PANDOC ready formats to convert to almost any other format.

A recent technical change within tiddlywiki stands to assist in additional format options an possibly between tiddlywiki wikitext and other formats in wiki.

I understand perhaps what you are looking for may not be available “out of the box” but in TiddlyWiki it is eminently possible to build it, this is not at all guaranteed in many other platforms. You need a two way solution and need the cooperation of the other apps.

If I were to try to turn, say, a sample order from my SQL Playground into something suitable for inclusion in Obsidian1

I not so sure what it is that you expect in an import export or in the destination solution I would expect to be able to export “complete Orders” not for example expect;

to be exportable components, these are by definition user interface and processing components, although I may use these to generate complete data records, I don’t expect these logic and code layers to be exportable and useable, outside TiddlyWiki.

  • As noted previously html may be one approach, perhaps to transfer a form to view your order.

We could write custom exporters to include such things, however to do what you are implying we would need a common software language we can export/import and it may need to be supported by every solution you want to interchange content with.

Please give more examples or ask questions of clarification so I can understand your expectations because I just don’t see the barriers you see. If I am wrong I will have gaps to fill, if you are mistaken, you have ways to progress.