Should caption be displayed as main title?

, ,
#17

I am yet to see your solution in action, but my own was a proof of concept I designed to fill a gap. It was closely related to my masquerade solution.

This was a responce to this topic alone.

  • yes

Previously

I have the same view as you that it was importiant to know when a caption, alt-title, or masquerade tiddler title was in use especialy as a designer or author. I used the unicode letters inside a circle and superscript to indicate this after the title, but have an option to toggle thier display.

#18

Hm, it seems to me that if the setting “treat titles as links” is on, then uni-link does affect even the tiddler title as it displays in titlebar. (And I always do have that setting on, because of my heavy use of linkstyle features.) At any rate, my concern just now was not about uni-link’s effects on the titlebar, but rather its effects on trying to display the real title as a link within the subtitle.

Of course, I understand that you have solutions that work for you and have clear logic. At this point, I’m already highly invested in leveraging the caption field (on a number of projects), so I’m trying to develop a caption-as-title (in titlebar) solution that does add better visual clarity (to recognize title vs caption), and doesn’t depend on other plugins. Still, it will be ideal to avoid actually clashing with uni-link. I’ll explore some more!

#19

Have you looked at my alt-title or masquerade solutions? they may do what you want, or give you a platform to innovate?

  • I will provide more details if asked.

I am reviewing my “alt-title and masquerade solutions” and I intentionally left caption out of it, because captions have their use as “short titles” in lists. That is why I would instead use the alt-title field. I need to add the aforementioned indicator use to show an alt-title is in use.

eg my Masquerading tiddlers optionally look like this;
Snag_1b3833

  • The icon indicates it has an [object-type[page]]
  • The real title is $:/TagManager, but this tiddler means it can be found with a standard search because it is not a system tiddler.
  • Tiddlers that are masqueraded can have their own fields and tags etc… but the text appears like the tiddler they copy.
#20

:100:

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

#21

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.

#22

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:

  1. 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
  2. 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. :grimacing:

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… :thinking:

Accessible Text
#23

Agreed. But that’s because…

And that titling in TW is “overloaded”. The “problem” compounds.

1 Like
#24

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.

#25

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
#26

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.

#27

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.

#28

Tough. Not least because, everyone from noobs to veterans are spinkled across the viability line in terms of applicability.

#29

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
#30

Bingo. Nice footwork :wink:

#31

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
#32

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 :rofl:, because I have other pressing work to do.

#33

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” :nerd_face:

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. :frowning_face:
  • 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

#34

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.)

#35

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;

Snag_a09fbb5
Snag_a09fbb51578×474 25.1 KB

  • 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)
#36

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