Pondering the implementation of TAGs

#1

I have spent the last few days pondering the implementation of the TAG facility.

As you may be aware, my TW displays documents from an archive, one document per tiddler. I then extract the names of people, places, organisations and exhibitions from each document and record each as a tag on the source tiddler(s). That way, if someone wants to know who else discusses, for example Paris, they click the Paris tag and TW then displays a list of tiddlers also having that tag. So far so good.

Now, I have been wondering if, in addition to the above, we should also create a tiddler for each tag and have a list function to produce a list of other tiddlers having the same tag. This would seem to me to just duplicate the above functionality, unless, like in my case for details of persons, you might want to have additional info, as in my case, links to external web sites with details about that person.

What are the group’s opinion of this, should we have such extra tiddlers and if so, what advantages does that offer to the user, the developer or whomever?

I suspect, runtime efficiency is little affected as the initial click on the tag requires TW to extract all tiddler details with the same tag whilst the extra tiddler requires the LIST operator to be actioned every time to tiddler is displayed. I assume, runtime cycles must be similar.

Is there an opportunity to implement a template for the popup window on the initial click, say something that would allow me to produce a different popup for my persons, places, organisations and exhibitions tags?

All input appreciated.

bobj

#2

tiddlywiki.com uses a lot of such tiddler-lists. See https://tiddlywiki.com/#About and every other tag, that is part of the “table of content”

They use some custom text like

Information about the making of TiddlyWiki:

<<list-links "[tag[About]]">>

For easy copy pasting you could also use eg:

<<list-links "[tag<currentTiddler>]">>

For a multi-columns view you can use the following code, which will create 4 columns. With you own class CSS you can do whatever you want.

<<list-links "[tag<currentTiddler>]" class:"multi-columns">>
#3

@Bob_Jansen I like this idea of harvesting names, places, etc, but I’m not a fan of using tags this way. My goal, which I’m not always successful, is to use tags to identify the entity of tiddler, not to identify relationships to other tiddlers.

This keeps my tag usage to a minimum. My tiddlers are tagged document, person, place, event, and organization. I may further tag a document to identify the type of document, or place with the type of place.

I use fields to associate relationships to tiddlers. E.g. a person field in a document tiddler would act as a list field to all people found in the document.

Then in a person view template, used for person tiddlers, has a document tab where users can view a list of documents associated to that person. And, in my document view template, used for document tiddlers, shows a list of people in the document, cross referencing all my entities. These lists are typically pagination tables and not only list entities but show other key fields too.

Craig

1 Like
#4

That’s a different approach and for sure is very effective too.

It depends a bit on the users preference and unfortunately the way you started project. Changing the entire base concept after a lot of “helper tools” are in place is a lot of work

2 Likes
#5

Totally agree. Without a doubt.

#6

Thanks all for your thoughts so far. I wonder though which of the two approaches espoused above is more efficient, in terms of development (coding functionality, support, etc) and/or machine cycles at run time?

Also, my thoughts are that the approach of tagging, as I do at present, makes the associated tiddler redundant, unless there is more information as it the case with my person tiddlers/tags.

bobj

#7

@clsturgen, some interesting ideas described here. Any chance of a peek at what you have done, maybe a small subset of your TW?

my TW is accessible at http://cultconv.neocities.org/CentralStreetArchive/index.html. It is still work in progress though :slight_smile:

From your description, I assume then that at runtime, as the user selects any of your tabs, you have a filter run to populate the content of the selected tab? I wonder what the advantage of your approach over TAGs is?

bobj

#8

@Bob_Jansen Bob,

My approach takes more time to develop and in the end will take more cycles.

In my solution I use the Projectify plugin. This plugin does not follow my approach when associating a task to a project. It uses tags.

Large project names make for huge tags.

Using tags for multiple reasons causes confusion. When is a tag used to identify the tiddler type and when is used for relationships.

A solution with multiple relationships is problematic with tags. My source tiddler, which can be a document, needs to be associated to all people in a document, all places referenced in the document, all events in the document, and there are others.

Out of the box TW does not provide a nice way of selecting tiddlers to populate a list field. So that was the first thing I needed to do. Having a large set of entities TW did not provide an out of the box solution to help user pick fields based on the tiddler type. So, I added that too.

I have an online demo. Do not use a small screen to review it, ie do not use your phone.

This demo is a start to tracking the history of the telephone. Here is link directly to a source record. Review it. Edit it. Add people, places, etc.

https://clsturgeon.github.io/MemoryKeeper/AlexanderGrahamBell/AlexanderGrahamBell.html#1876-03-10%20-%20Notebook%20by%20Alexander%20Graham%20Bell%2C%20from%201875%20to%201876

#9

I list the tagged tiddlers in the tag tiddler because, yes it’s the same info, but it’s easier to read if there are a lot of them (my equations) and, I suspect, most people who look at my site don’t know to click the tag pill.

#10

My recommendation: DON’T make a tiddler for each tag!

Just make a view template that shows the related info at that “node” (if the tag title is opened in the story river), so any tag just automatically shows off its children at its home location. This is leveraging virtual tiddlers.

#11

@Springer, why do you make that recommendation not to make a tag for each tag? In my case, once built the TW is unlikely to change so it is not an issue of ever increasing tag numbers (the source document set is fixed).

I have not conquered view templates as yet. Will spend some time doing so from now before I go any further.

#12

Interesting. I usually do so, at least for every important tag. Yes I use a virtual tiddler for those I haven’t yet defined: a <<list-links>> showing all the items tagged with this tiddler, but I almost always want to customize those presentation of these, and end up with a custom tag tiddler.

#13

@Scott_Sauyet so how is your approach different from just clicking on a tag pill and seeing the list popup beneath it for those tags with no defined tiddler?

And where is your <<link-list>> statement defined?

bobj

#14

I think the argument is to make a general solution for all tags, and only code specific solutions when you must.

I personally do this too, with additions to the tag pill, using my “reimagine tags solution” however the drop down is best for shorter lists, or ones who’s sort order is not so important, or bespoke (using drag and drop, list-before and list-after), or the title is sufficiently informative.

However “custom tag tiddler” allows much more sophisticated lists, selectable order, multiple columns and fields etc…

  • Although I still try and build a generic (view template) every tiddler solution I can add more bespoke content.

Tiddler with $:/tags/ViewTemplate tag.

<$list filter="[all[current]is[tag]]" variable=~>

Every tiddler content

</$list>

Edit the “tag tiddler” if you want “all about this specific tiddler” view.

#15

For me the <<list-links approach works best, because I almost always want to write some extra “intro-text” that can not be standardized. So most of the time I do use “real” tag-tiddlers

1 Like
#16

Yes, I tend to keep the text field for notes about a specific tiddler, its meaning or usage. Best to keep code out of it via view templates, cascades etc…

1 Like
#17

This is exactly what I’m talking about — having a default template for tags even if they’re “missing” as tiddlers.

In my case, that template is a dynamic table that includes rows for every child of the tag, and a column for each field that exists across any of the child tiddlers gathered under that tag (subtracting out some boring fields). I can’t say enough good stuff about Shiraz dynamic tables — many people don’t realize that the list of columns is just as dynamic as the list of rows! (EDIT: Here’s what it looks like in practice, when there’s a cascade condition that checks to see if tiddler is “missing” AND has tag-children, and then offers rows and columns as I’ve described: https://quick-demo.tiddlyhost.com/#img-human-lifeways)

Essentially, my default (“missing”) tag node provides a expandable spreadsheet view of all content under that tag, without ever needing to create a tiddler for the tag… until/unless I want some kind of reader-facing summary or explanation of the tag (along with a somewhat prettier or simpler way of summarizing the tag children).

My “missing tag node” view template is (in most of my wikis) set not to display once the tag node has been converting into a real tiddler. If I turn it into a tiddler, it’s usually in order to replace that utility table with something that makes the utility table redundant (or TMI for viewers, etc.)

So, to be clear, it’s not that I recommend against making actual tiddlers for this or that tag once there’s something very specific to that tag that you want to put there. (I followed that path myself for many months…) But now I recommend that you at least first build some default viewtemplate that generally proves useful for most [empty] tag nodes, so that the virtual tiddler for a tag node always helps in a “view from here” way.

(“Node” is what I call a “missing” tiddler’s connective function in the wiki, if it still displays a useful viewtemplate when it’s brought into focus within the story river).

2 Likes
Sharing a solution: Dynamic table for tag nodes (even if virtual / missing)