Proposal: render fieldnames as links, and see what's possible with fieldname nodes!

[Springer]

With a big nod to @TW_Tones for offering some ideas about fields here in this earlier thread, I want to begin with one easy and powerful tweak to TiddlyWiki: render fieldnames (wherever fieldnames are doing their thing) as links, making it easier to access and handle fieldnames as useful nodes in the story river. Then, new vistas open up…

(I’ve previously mentioned fieldname nodes as part of my virtual tiddlers approach. But this post is actually a distinct proposal: you could see fieldnames as powerful tiddlers/nodes without having any magic for “missing-tiddler” nodes, and vice versa. The two work well together, but are logically independent.)

Step 1: Get fieldname nodes into the story river with links

Here’s a screenshot from my working demo, in edit mode. (Note that fieldnames that do not exist as tiddlers render in italics, as per our existing convention.) Hovering over a fieldname such as color will show a tooltip for that field, so long as the fieldname tiddler exists and has a field-description field:

The key edits here are to $:/core/ui/EditTemplate/fields — both to make fieldnames into links, and to offer a tooltip on hover, based on the fieldname tiddler’s field-description field.

Step 2: Make fieldname tiddlers (or virtual nodes) informative

When you click the link for a fieldname, TiddlyWiki of course navigates you to the corresponding node — in this case, a node called color.

In a barebones solution, you’d see the “missing tiddler” notice for a fieldname node where no corresponding tiddler exists.

In this case, however, let’s focus on color. We know there is a tiddler called color, because the link wasn’t italics — and it even displayed a tooltip based on its field-description!

The tiddler called color is the natural place to make substantive notes about your use of this field, and it also might offer a more-or-less automatic “x-ray” of the wiki with attention to the color field, leveraging has<storyTiddler> or similar filter steps. Again from the working demo:

To get such effects, you can approach particular fieldname tiddlers one by one, or just set up a view template. Such a template can be as powerful and detailed as you like (perhaps nested with conditions, like “Ok, but let’s not list all the values for a field here if it’s a textarea field, right?”), or minimalist yet informative.

Step 3: Tweak dynamic tables, etc.

Of course, fieldname tiddlers can exist without shiraz dynamic tables. But dynamic tables are a fantastic help in adding depth to fields.

So I’ve modified the default headers in Shiraz dynamic tables so that there’s an info link next to a column header if it corresponds to a fieldname whose tiddler does exist. Again, hovering on the fieldname info icon displays a tooltip with field-description, if available. See below screenshot:

Analogous solutions can be built for any other solution (such as refnotes) that leverages database-like interaction with fields.

Questions

These are such simple tweaks — maybe good for MyFirstPlugin™ — but there are questions worth answering:

1. Should the fieldname solution be “direct” or “indirect”?

   • I like having plain-old fieldname tiddlers, like bibtex-author; this direct solution makes this whole approach so simple! In a wiki that is friendly to data-entry users/authors, you could search for a fieldname, and there it is right in the regular search results.
   • But the “direct” solution wouldn’t be ideal for wikis with a layer of user-facing content that tries to hide TiddlyWiki guts. There could also be awkward results for novice users, who might naively create a field such as library — a fieldname that the core uses…
   • So… I could build in an option so that the fieldname bibtex-author actually directs us to $:/MyFieldnames/bibtex-author … so that the technical info about fields isn’t distracting from tiddlers that are more relevant to viewer-facing content. (The option would be awkward to toggle “in action” though — a wiki will have to choose a style of wrangling, and stick to it.)
   • Please note this issue has gotten some useful discussion in the thread Tones started, beginning from this post, so maybe I should de-emphasize it in this thread, though it’s obviously important!

2. Should users have fine-grained option to enable/disable “missing” fieldname links? (Should this be handled separately from the existing $:/core/ui/ControlPanel/Settings/MissingLinks (Enable links to missing tiddlers), or just governed by that same preference (my inclination)?

   • Also, perhaps there’s a shadow list of fieldnames to avoid linking-up, by default? (Maybe we suppress links to fieldnames for “standard fields” and/or “fields used by the core”?)

3. What do you all think are the essential or most exciting fields about fields? Obviously we don’t all have to be in lockstep, and I want this package to be nimble… Still, some “best practices” would be great to model.

   • Something like field-description is the most important. (I’m not using description as the fieldname, since it’s in the core for a somewhat different purpose. Also naive users may really want to use it in predictable ways.)
   • is_textarea or something like that can nicely trigger better handling of extended text wherever that field is edited or displayed in a dynamic table, etc.
   • is_list could do something similar to facilitate list-handling, while is_date and is_color could trigger relevant custom edit-field and view-mode formatting. One could imagine autocomplete_values:yes as a setting that can be made at the field-tiddler level.
   • We might inch toward all sorts of powerful field-specific handling, once fieldname tiddlers have a “there” there: is_temporary might mark a whole field as to-be-bypassed on save, even while the tiddler gets saved; author_only might trigger css that suppresses all visibility for a certain field, even in edit mode, for those who are not logged in or accessing via file:// protocol (etc.); stealth_modify could (in theory) allow any modifications to a given field to happen as if timestamps are off…

Input welcome!

[TW_Tones]

Great ideas @Springer and a number I too have explored. Like you despite a big conversation over here [Proposal] Updating field handling functionality in TiddlyWiki I am taking it slowly because I want to establish useful, core agreeable solutions not unlike your own.

There are other ways to handle fields, and I am also experimenting with these so any solution does not limit the other methods eg;

• fields whos name matches a filter eg suffix[-link]
• fields whos value has a protocol prefix value that begins http:// And https:// …

A comment on the direct/indirect approach, awkwardly I would say all of the above, including to allow a set of tiddlers to have their own custom set of “field definitions”. There are multiple ways to implement this and although complex to design will make them easy to use.

• Such as a custom cascade for the “file tiddler” naming standard to be applied on a given tiddler or by default.
  • I really do favor a special prefix that is not a system one such as a unicode character. Still in standard search but clearly different.
    • We could do this for user tags as well.
• A cascade for how to view a field in addition to the current how to edit a field.
  • Eg color is a number a swatch or both?

A clear discovery is if we created 100 fields they would possibly only have a dozen types such as short text, current text, text area, color, date/timestamp, title, title list, number etc… so I do favor an additional layer below called a field-type (you would set this in a field tiddler).

[pmario]

@Springer

• Also, perhaps there’s a shadow list of fieldnames to avoid linking-up, by default? (Maybe we suppress links to fieldnames for “standard fields” and/or “fields used by the core” ?)

Currently I did only read your post to exactly this point and I felt I need to respond immediately. I do like the idea, because of the working demos and it seems you already use it.

I think we will definitely need some support from the core, especially because there are default core fields that are hidden by default, like modified and so on. Messing with them, has potential to cause confusion.

For my field-editor plugin I did create a "Warnign … " box, that is similar to the “Existing tiddler title” warning. So users, that want to create field names, that are reserved for the core, or do already exist in a tiddler, get this dialogue.

@jeremyruston – IMO we should implement such a warning dialogue in the core. What do you think. (I’ll create a GH issue soon)

[pmario]

@Springer

Something like field-description is the most important. (I’m not using description as the fieldname, since it’s in the core for a somewhat different purpose. Also naive users may really want to use it in predictable ways.)

The core has a mechanism to define TiddlerFields descriptions. IMO we should try to reuse that mechanism, if possible. “lingo” tiddlers are .multids, translatable shadow tiddlers. They are “unpacked” at wiki startup.

---

Default Search

@jeremyruston – By default the TW does not search in field values. IMO we need to change that in the core, with a configuration option.

[xcazin]

Hi @Springer may this plugin project become reality!

@Springer

Should the fieldname solution be “direct” or “indirect”?

I was about to argue in favour of indirect, but you gave the most convincing arguments in your section on fields about fields. Being able to configure any properties of each field inside its own tiddler would soon prove invaluable. Moreover, it would allow to answer yes to your question about missing fieldname links, and even allow to compute fallback text if necessary.

Regarding display, what about displaying values with a special template rather than just the current value? For instance, the field value template may conditionally add some button to increment or decrement the value, or some link to a more complex editing interface. If the value is a tiddler name, could also display indirect values, like its caption or any relevant attribute. This value template could also be part of the tiddler that holds the field configuration.

[TW_Tones]

please be aware this idea is closely related and a small part of a piece of work I am doing. I am trying to keep the design opportunities open but I have taken this a long way with a lot of research and poc offline. I am concerned the enthusiasm may overwhelm this process especially if we move too fast to core changes.

advanced field handling has being a concern of mine for a very long time. please see my thread in developers.

[Springer]

@pmario

I think we will definitely need some support from the core, especially because there are default core fields that are hidden by default, like modified and so on. Messing with them, has potential to cause confusion.

Since modified and created aren’t shown in the field-editing interface, I don’t see that my proposal/proof-of-concept really does anything to facilitate “messing with” them in any way (though I do think access to modifier and creator — as links to templated field overviews — will be especially useful in multi-user wikis!). My design also doesn’t make any automatic links to type or tags or text, since those also aren’t straightforwardly present in the usual edit-field array.

I should mention: I do in fact often find myself manually specifying a value for modified, using the “add new field” workaround. The “recent” sidebar list is useful for some audiences such as students who need to see what’s been added or changed. So I try to turn timestamps off before doing a cosmetic or technical fix. (Perhaps I’m refactoring some old “stupid” one-off style declarations, to move toward a cleaner css-class approach, but I don’t want students to think there’s really something new to see under “midterm assignment”)…

All that works fine if I’m really paying attention. But maybe I forget to turn timestamps back on before returning to substantive edits (so now I need to “touch” a bunch of tiddlers that I’ve updated during the lapse). Maybe I even tweak creator and created, if I actually made new tiddlers while timestamps were off). Or, I simply forgot to turn timestamps off before certain minor edits, and now want to back-date those tiddlers (to push them away from the top of the recent tiddlers list).

At any rate, your point is well-taken that some fields are more-or-less “off limits” for end-user use, and some kind of warning or extra step makes sense before allowing edits to them (even independently of my current experiment in design).

[Springer]

@pmario

The core has a mechanism to define TiddlerFields descriptions. IMO we should try to reuse that mechanism, if possible. “lingo” tiddlers are .multids, translatable shadow tiddlers. They are “unpacked” at wiki startup.

This is interesting and important. To make the breadcrumbs clearer: the mechanism is through language tiddlers such as this one: $:/language/Docs/Fields/stability whose text (in English) is

The development status of a plugin: deprecated, experimental, stable, or legacy

Of course, a tiddler named “stability” or “priority” or “catalog-number” (or named §/stability etc.) could integrate with this approach by creating and/or modifying tiddlers in the $:/language/Docs/Fields/ namespace to hold the explanation of that field’s contents.

If what I’m calling field-description were the only significant meta-data for fields, then I think this would make sense. But if we realize that fields may want to have quite a few attributes, the proliferation of one-off tiddlers (to hold this and that attribute) would seem a very inefficient way to connect all that info (and not all would need the “language” approach). Separate system-space tiddlers for each attribute would also make it more difficult to port a solution. On my biblio site, I can imagine saying: “Here are the plugins and the custom fieldname tiddlers you need” and dragging the fieldname tiddlers would carry along all of the field parameters carefully configured to display (with tooltips etc.) as intended…

On the other hand, the language-tiddler approach is clearly fantastic for plugins or other tools that want to be open to further translation modules.