caption: only for tabs, shame but the semantics of a caption have been lost as a result
subtitle: my preferred titling method
title: TW’s unique “id”
uuid: my unique id used for most linking I need
I will have to check that, because I do not use “title-links” for my wikis. I did not ever test that case with uni-link. If uni-link interferes with the main title-links I do consider this a bug.
If wikitext [[wiki-links]] are used within the tiddler “subtitle” area the setting should be active. – But as I wrote, I discourage to use the global setting at all. I probably should make that clearer in the docs.
I think using “caption” for long titles is the “second” best way to do it. That’s why I did propose “subtitle” as an alternative for “titles”.
For plugins and eg: System Tags we do have “description” fields, which again are different to “subtitle”. For me a “description” is or can be a whole paragraph, which can be shown together with a modified version of the list-links macro.
This is a fascinating question, because to some degree, converging on a “best practice” is good for the community.
I take your comments to be very helpful in thinking through our “best practice” for how different fields perform title-adjacent functions.
Different projects have different data structures, and different users will have different associations with field-names…
I admit that relying on a subtitle field has not been attractive to me for two reasons:
- subtitle already names a viewtemplate area (where modifier & tiddler date stuff normally show up), so I don’t love using a field with that name — especially when I expect not to be displaying it in the subtitle area of the tiddler
- the subtitle of a book is the part after the colon, and it often functions more like a long subordinate clarification, not like a compact recognition-aid.
Neither of these reasons are likely to matter as much to others as to me, but they do help explain why I haven’t used subtitle in the way you suggest.
Still, I must admit that caption already has a technical role in TiddlyWiki! And indeed, occasionally I’ve realized that I want a tab (say, in the sidebar) to show something super-short, but then that short caption may not belong in the tiddler’s titlebar — it’s not the most helpful string in a place where quite a few words can fit.
So I agree that using caption is probably not the best field for holding what I really want to see in the titlebar (though it may still belong in the cascade of things to look for). Darn, I’ll have some reworking to do, since I’ve been deploying caption-based tweaks across many wikis. 
I wonder whether I might consider a field called heading2 or even h2 — since (after treating heading1 as aligning with the title of the whole site) and heading2 is the html heading applied by default to the tiddler title — or whatever is getting displayed in that role at the top of the tiddler… 
Agreed. But that’s because…
And that titling in TW is “overloaded”. The “problem” compounds.
1 Like
I’m intrigued by Mario’s approach…
I might play around with that at some point. For me, <H1> isn’t a tag I ever use, so that frees it up for title-use.
Certainly there can be some side-effects (to solving the “title field doesn’t contain what I need to see at the top” problem by just starting the tiddler’s text field with a title-ish heading using <h1> tagging):
(1) This takes up space within the tiddler
(2) That internal heading will now show up when that tiddler is transcluded (remember some transclusions are quite short and functional), and
(3) Viewtemplates for the tiddler body that aren’t really based on the text field won’t show this at all.
[EDIT: (4) There are also these questions about heading-levels, which prompt me to start in-tiddler headings with h3…]
Of course, these side-effects may not matter within some projects. For my projects, I want a field to hold the meaningful words that — at least sometimes — belong in the titlebar instead of (or more prominently than) the title field.
2 Likes
Of course. That’s why I said “for me”. I’m in control of how my text field is displayed for viewing. Today, I’d have used cascades, probably, but I use my own code to slide/dice the content to present the view I want/need.
I am, of course, talking about content tiddlers, not every tiddler.
As do I!.. Yet we all are doing so much sharing of solutions, and we’re also thinking about community editions. So I appreciation taking time to reflect together on what might make sense as a path to recommend broadly.
Tough. Not least because, everyone from noobs to veterans are spinkled across the viability line in terms of applicability.
I’ve taken the opposite approach to this issue in my wikis. I display the caption (if present) in place of the title, and also use uni-link’s caption-displayed-by-default feature. (For what it’s worth, @pmario, this was actually one of the major selling points of uni-link for me. I’ve been using the View Template Title cascade mechanism long enough that I’d forgotten about the caption-as-main-title “bug”, but it almost certainly inspired my current system since, like @Springer, I always have title links turned on.)
To handle the rare case in which the caption is not the label I want on a tab, I hacked the tabs macro to use a new field, tab-caption, if available, and then fall back to the normal caption > title behavior. I’m not necessarily recommending this for everyone, but it made the most semantic sense to me.
2 Likes
Bingo. Nice footwork 
Emily, the approach I took seems closest to what you were after. It used alt-title if it exists and displays this instead. It displays it as a link to the real title so the can still be drag and dropped. This leaves title as the unique key and caption as they short title for lists. On hover the tool tip displays the real name.
- I think the trick is to do our best to retain the meaning of existing fields
- at some point can we choose a general order that makes sense eg alt-title or caption else title?
- also we can also makes this;
- configurable wiki wide
- provide a per tiddler config like preferred display title to overide the global setting
One final tip is to include such additional title fields in the standard search.
If we can cristalise the requirements I would be happy to make a solution because I have most of the code and mechanisiums already.
1 Like
Tones, I haven’t yet seriously considered any solution that would require moving away from heavy use of the caption field, mostly because refactoring my existing wikis to work with something other than the caption field is not going to be a simple task (it’s not a simple matter of renaming the caption field with utility plugin; there are tab-related costs to renaming the caption field, but also I’ve got some old overwritten shadows that lean into the caption field (as the human-facing tiddler-name) that won’t be so quick to troubleshoot. (Not all of those modifications were well-documented; I’ve learned a few lessons, over the intervening months and years, about the importance of leaving explanatory breadcrumbs for my future self.)
I’m now persuaded that in principle either caption should be left to do the super-short-form work (for tabs etc.), or — as @etardiff has explained above — I could shift how tabs display by having a cascade look first for a different field, like tab-caption.
I’m torn between following the “high road” (doing what I’d recommend for a newcomer with alt-title or some such field name) and following the “low road” (doing less work by employing a tab-caption field that can hold the super-short string when needed). Or, just standing where I am and following neither of those roads 
, because I have other pressing work to do.
Just remember I, and we, are here, if you want some collaborative assistance.
I have had a hunch for sometime that the captions use in both lists, and for tabs, was a slight design error. Also captions are transcluded rather than simply displayed, allowing icons and other wiki text and references, so they are the only default way to introduce more advanced titles.
- This is a multi-factor set of issues, somewhat data dependant, and I am not sure there is a “right way”, but there are a “Hell of a lot of, quite good ways”
Notes:
- If you do proceed to introduce a tab-caption ensure it is transcluded such that it gets evaluated, thus it is caption equivalent.
- When the “horse has bolted” on your data arrangement, it can be of value introducing a new field, because you can;
- Test it is not in use yet
- For all items you expect need the new field you can clone the existing field eg caption cloned to tab-caption or alt-title so it overrides the current behaviour, and clean up the caption when doing incidental edits, if ever.
- This method allows tiddlers imported who don’t know about your field to still work. You could call it a “selective replacement cascade or stack”.
- Don’t we all, I have being trying to reduce this with a set of de facto “standards” I follow for myself, and this works 90% of the time, however older code, or for less common approaches, it is not always enough.
- I try and embed such standards in what I do, rather than write specific documents, but I do occasionally make the same mistake, more than once, especially for less common standards.
- The truth is they really are often “unwritten standards”.
Best of luck
If you already happen to have an action-button configuration on hand for this — for cloning a field, pulling its contents into the newly named duplicate field, across all tiddlers that meet a filter condition — and don’t mind sharing, that would be lovely.
(In general I’m wary of duplicating info within a project, but I’d feel safer with a cloning process in this case, because I’ve put quite a bit of effort into generating content for this caption field in the “readable-name-of-tiddler” spirit — almost 3000 tiddlers’ worth of short-form citations (with italics and smart quotes as needed) in my biblio project, for example! So it would be great to ensure the content all looks good in the new alt-title field (or whatever) — and that I can get all the GUI elements re-oriented around that field — before selectively clearing out the caption field contents.)
I am used to writing these batch transformation buttons so will write it shortly and update this reply. They are easier than you think.
- remember to backup the whole wiki
- you can also use the same filer to export the tiddlers as a JSON before batch update do your can restore them.
- mohamads commander and other tools may be easy but I prefer a bespoke batch.
- I will look for some prior work if mine to support this.
[Edited]
So here is a solution designed to assist and guide batch updates;
- Place in a tiddler on your wiki
- modify the actions procedure as needed
- modify the widget at the bottom if necessary
- Provide the filter
- Provide the actions as a procedure/macro.
\procedure alt-title-actions()
<$action-setfield $tiddler=<<currentTiddler>> $field="alt-title" $value={{!!caption}} $timestamp=no/>
\end alt-title-actions
\widget $filter.actions(filter actions)
\function tiddler.count() [subfilter<filter>count[]]
<div>
;Filter in use
<pre><$text text=<<filter>>/></pre>
;Actions to be applied
<pre><$text text=<<actions>>/>
</pre>
;List of effected tiddlers <<tiddler.count>>
<$list filter="[subfilter<filter>]">
</$list>
<$button>
<$list filter="[subfilter<filter>]">
<<actions>>
</$list>
Action List of effected tiddlers
</$button>
</div>
\end $filter. Actions
<$filter. Actions filter="[all[tiddlers]!is[system]has[caption]!has[alt-title]!is[shadow]limit[1]]" actions=<<alt-title-actions>>/>
For example this displays as;
- Hitting the button applies the change to all listed tiddlers.
- It forces you to scroll to the bottom to go past the this of tiddlers to change as a result.
Notes;
- The filter determines which tiddlers are listed, then changed.
- I made it re-startable by not listing those items already changed eg
!has[alt-title] - I used
limit[1]to see and action the first only,- I opened the first tiddler to be changed
- Hit the button to apply the change and reviewed it to be sure.
- Now you can change the limit and action all or bigger blocks.
Design/code notes
- I used a widget so it was easier to pass the actions as a procedure/macro reference
- Also we do not need to use the output of this anywhere else, widgets are where coding ends, there result is what we see and interact with in the UI
- This widget also displays the relevant info so you can review it before you hit the button.
- By passing the filter as a parameter, I made sure it need only be given once but used a few times and remain exactly the same.
- It can also be change to reverse the items listed eg those with alt-title
- I suggest setup a new/additional widget call and action procedure
- By passing the actions you can choose other actions you write
- This may include reversing a change (if possible)
When you are ready feel free to ask me for my latest alt-title (you can change the fieldname)
- Remember you may want to retain the caption field where it differs from the title, for lists and tabs etc… but are likely to remove your wiki text additions.
[Edited]
I have being updating my current alt-title package and you can now change the fieldname and indicator using a config tiddler. In this way you can first test using the caption as an alt-title to check its working, before you move caption to any alternate title fieldname, even restore the use of the default title.
[Edit 2]
One thing about using alternate titles, even the caption, is you have to edit the tiddler in question. I am extending my alt-title solution to also make use of another idea I have being developing for some time, the meta tiddler. This allows you to assign the alt-title to the meta tiddler, rather than actual tiddler, to get the same result, there by not modifying the original tiddlers, good for core tiddlers.
1 Like
Ditto.
Although I didn’t see this then, about the same time this thread was resurrected, I realized that while I generally preferred showing caption to title in the most prominent spot, there were some time when I either wanted to reverse that or show a third field altogether. I haven’t gotten around to doing this, but I think I like this notion:
I will probably try to combine these ideas in my own version. But that’s much lower priority than finally getting back to recipes!
As I posted above I have enhanced my alternative title solution to be instantly configurable including changing the field in use eg title, caption, alt-title, yourfield.
I could develop this further to make it;
- check box selectable
- drag and drop order of fields to be used in a title cascade
- individual tiddler override
- add a subtitle option like marios
I have already introduced a way to provide an alternative title with out editing the target tiddler, via the meta tiddler or ghost tiddler idea raise previously.
Main point?
With sufficent options in an alternative titles solution the question raised in this topic becomes somewhat mute because it just become a UI option driven choice.
- let me know enough and perhaps I can incorporate your requirements.
- some preconfigured actions could be developed to set or change behaviour.
I do already use the built-in cascade for tiddler title — the one that relies on the tag $:/tags/ViewTemplateTitleFilter
There’s something still a bit awkward about TiddlyWiki’s built-in cascade mechanism, though — something about how each tweak requires two tiddlers — one (with the tag) to expresses the filter condition, and the other to hold the target template. (I often run into a sense of brittleness when I try to copy cascade-based solutions from one wiki to another — I need both tiddlers but also the proper ordering within the cascade list, which needs reconstruction if (for testing purposes) I called it a day after just dragging up and down within the cascade tag, forgetting to carefully generate a list-before or list-after field for that cascade condition tiddler so that it travels better.)
For some projects (such as my biblio / books edition) different tiddler-categories might have conflicting “top-of-tiddler” display needs (which only that official cascade can do in a sophisticated way — e.g., displaying tiddler title field even if caption exists when a tiddler has such-and-such tag, even though caption “wins” for most tiddlers, etc.).
But a general drag-and-drop cascade among available fields would be a neat and intuitive option for a wide range of cases!