What's the standard way to not writing Title

#53

Here’s my thoughts on this.

  • Autogenerated titles should have a standard ontology (way to name things)
  • A standard method of displaying emphasizing an alternate field in the “title-area of the tiddler-card”, while deemphasizing the literal title field (it should still appear as a popup, or ?)
  • System Tiddlers are defined as those that match the following prefix $:/. This encapsulates a few concepts that we can re-use. There is a “drive/volume” portion $: and a PathSeperator /. We should re-use these concepts.
  • Streams plugin uses this , i.e. if you start a stream of notes from the Streams tiddler, they come out as Streams/20240609224322659, Streams/20240609224322659/20240609224406918, etc, etc.
  • If you need to declare a “Namespace”, then use the “Drive/Volume” pattern.
    • Example: All charactersheet data for Characters in the Synthetic Dream Machine Role Playing Game System could be held at SDM:/characters/<<GUID>>, and the character name could be held in caption or subtitle, or petname, or ??, etc.
#54

A post was split to a new topic: How to automatically name ChatGPT and Gemini conversations

#55

Hi @joshuafontany you are late! People above was discouraging the use of prefix in title, but rather use a field _prefer_field for this.

I think if you want to reference the tiddler generator that generate the random-title-tiddler, you can add field source: Synthetic Dream Machine.

But adding this kind of a cascaded-title-view-template to the core is a good way to let us “have a standard ontology”, I will do this when this RFC is really sattle down.

#56

Hmm. Completely machine-generated UUIDs, etc, as Titles means that we lose the “human readable” portion of the title field. I honestly think that many tiddlers should actually NOT be expected to be rendered directly in the story river, but rather transcluded into another “main” Story River Tiddler. BUT, we do use title as one of the main fields for search result lists, etc. We wouldn’t want to completely fill those lists with “hard to parse alpha-numeric strings”.

2 Likes
#57

I second this statement. I also think tiddler titles should be human readable, because TWs main UI is created for humans.

If we need a machine readable ID it can be a field.

I think the _prefer_field field is be an option I can live with. If it is there and ignored, we are good. If it is used in story-river templates – it’s good too, if there is a fallback to the title

2 Likes
#58

I don’t agree, your config can work out of the box and the ability to reconfigure it is so you can deal with edge cases or integrate with other plugins.

Keep in mind I am talking about providing a de facto standard for config settings designed to operate across solutions and pluggins rather than embedding it in the core.

I am relying here on a sophisticated understanding of the common factors and an evolutionary design approach to assist interoperability. I think this is within reach and would provide what you are looking for without reducing future choice but expanding it.

#59

The title is the unique key to the data that is a tiddler. Either they are human readable or hidden from view and accessed via smart tiddlers that know how to handle the auto-generated titles.

  • Placing they unique key at eye level is part of tiddlywinks genius.
  • There are plenty of alternatives when this is not optimal without any core change.
#60

What if it were _use_caption: fieldname for still more flexibility?

#61

Extending your idea @Scott_Sauyet the caption as a rule is transcluded, meaning it is wikified. Thus the content, can in effect be a redirect {{!!fieldname}}, a macro or function.

@jeremyruston Rather than a field=yes to display caption we can introduce a more general solution such as "display-title’ which is evaluated if it exists and replaces the title. It can have a value, wiki text, function etc… including to say use the caption field.

I have a preference to set such things programmatically, not by an on tiddler setting. For example testing a field such as object-type which then determines if an alternate title is displayed. In some cases the “type” field is sufficient.

  • It seems to me we could introduce a defacto “logical tiddler type” field that more users and designers would use it to treat subsets of tiddlers differently programmatically.
#62

This is just “Layout” feature. Many of my plugins already use new layout to display tiddlers with random title. For example:

  1. Health tracker plugin (buff & debuff tracker) as a layout (mini fullscreen app)
  2. Calendar and Agenda plugin tw-calendar with Mobile friendly agenda page layout

And when you open it on the standard layout’s story, it will show caption due to a view template cascade.

1 Like
#63

@TW_Tones While my command palette can ignore title field when search tiddlers with _prefer_field field, but to add this to default search, It should be a standard in the core wikitext in empyt edition.

TidGi already do so, it preconfig many things, and with 70+ preinstalled plugins, and it give Chinese Tiddlywiki communtiy 1000% grouth during 2 years. Before it, many people think Tiddlywiki is very hard to use, with many things to learn, and is even worse than Obsidian in difficulty to configue things. But this is the topic for How to stimulate User Growth of TW?

#64

Yu need only modify the fields in $:/core/ui/DefaultSearchResultList to include an additional field in the search [!is[system]search:title<userInput>sort[title]limit[250]] nbecomes [!is[system]search: title<userInput>sort[title]limit[250]]

Have you considered using the existing mechanism Customising search results along with a title cascade? Both can be added without touching the core.

Snag_3f7c6603
Snag_3f7c6603979×575 42.7 KB

Snag_3f7c76dc

My personal view is your proposed change is too much while affording little. I believe we can do without it and use existing mechanisms when needed, or if a change is to be made make a much more versatile change,

  • This is not a personal but a coding/tiddlywiki design opinion.
#65

Maybe you don’t use features that may generate random title. But this is a common feature in the future, Tiddlywiki will become an app platfrom, many of them will use random title to store data, look at how calendar plugin works.

We should aware that, tw core is not about feature, it is about standard. There will be more plugin developers, and they will copy code from tw core to build new features. Tw core is the guidance for developers.

#66

I understand the issue with auto generated titles even machine readable, or random ones and needing to present an alternative title. I have no problem with what you want I have a different view on how to do it and consider the need to alter the core unnessasary.

  • I believe a core change is only justified if it is much more functional and feature rich than what you propose.

I would be happy to build a solution for you to address your requirements, and can, however I have already pointed to these different approaches here and elsewhere.

#67

I believe plugin side will build many new features on this standard. But it won’t introduce much change and feature on core side.

I will wait a month before I start making changes, there will be more ideas coming out.

#69

Hi @linonetwo I think you are asking for us as a community to agree a common way to represent tiddlers that should not have titles that are visible to the end user. I broadly agree, and welcome the initiative.

Firstly, I think it’s important to note that @linonetwo is not proposing a new core feature. This is about the community coming to agreement about how to represent a particular state of affairs in TiddlyWiki.

There are numerous analogous implicit agreements that underpin the TiddlyWiki ecosystem: for example, that the wikified caption field takes precedence over the title in certain situations.

The specific case of representing tiddlers that should not have user visible titles is, I think, a fairly generic need that has cropped up in the work of more than one plugin author.

Secondly, as others have noted, there are two broad approaches:

  • A marker that is intrinsic to the tiddler in question (for example, a special field value or tag)
  • An extrinsic test that can be applied to a tiddler to determine if it is titleless (for example, a global, configurable filter that can be used to identify titleless tiddlers)

In many situations, the flexibility of the second approach is preferred. However, here one of our concern is interoperability. It would be nice to be able to drag tiddlers from Streams to another titleless tool, and have things work.

So, for that reason, I favour an intrinsic marker. I think I prefer the boolean form of an _is_titleless field where a non-blank value indicates true.

2 Likes
#70

Of course, having an intrinsic marker available shouldn’t rule out more custom solutions, if I understand correctly.

For the thousands of bibliographic bibtex-folrmatted tiddlers I already have, I like the idea that the tiddlers remain straight-up bibtex-standard json. No need for extra fields. So my story-river titlebar solution includes a filter-based solution to bypass the title field in favor of a nicely formatted citation (or whatever) — for exactly those tiddlers that have the earmarks of being bibtex tiddlers.

Having a community standard per-tiddler way of deflecting attention from the title — in favor of whatever other field (or cascade) we agree on — would not need to conflict with this kind of “wholesale” approach, right?

#71

Yes, it’s an API for future plugins (for plugin developers), so developers don’t need to think about the naming, don’t need to ask it in the forum again.

It is mostly an API between plugins: A new plugin is going to use this API to call other plugins. (Not calling tw-core’s feature!)
If your note and the plugin that generate your note not using this API, you are just out of the circle of those new plugins. Not other drawback.

I hope this could happened before I start writing my tw plugins, so I don’t have to ask about this in the forum.

#72

Plugin here Any plugin to edit tag on view mode? - #9 by TW_Tones

Now used by several layouts that create tiddler with randomID-title.

#73

Oh, just notice that the link above is incorrect, here is the plugin:

https://tiddly-gittly.github.io/title-caption/

And it is build-in as a core plugin in TidGi.