* Install https://bimlas.gitlab.io/tw5-locator on TW.com, drop the Locator View on it as well
* Save and open
* On the top of HelloThere press the double arrow button to open in the sidebar, switch to Locator sidebar
* Press the gear icon to open context settings and switch the field of tree to LINKS-IN-TEXT
* Use the arrows near the list itens as you would in a regular ToC
This is inspired from my threat on tag picker slowdown and Dave's threat on bi-directional linking. From these discussions on the TW tech and user behaviour with relations, I think it could be useful to have a more fundamental discussion about relations (tags and links).
/*TAG EDITOR AND DROPDOWNS*/
html body.tc-body .tc-block-dropdown-wrapper {width:800px;color:#2200bb;}
html body.tc-body .tc-block-dropdown {width:800px;white-space:normal;color:#2200bb;}
html body.tc-body .tc-block-dropdown a {display: inline-block;color:#2200bb;}
html body.tc-body .tc-block-dropdown svg {height: 1.2em;fill:#ccc;display:inline;color:#2200bb;}
/*TAG LABELS*/
html body.tc-body .tc-tag-label {font-family: 'Arial'; font-size:10pt; color:#2200bb;background-color:#eee;margin-bottom:6px;font-weight: bold;}
html body.tc-body .tc-menu-list-item {font-weight: bold; color:#2200bb;}
This is inspired from my threat on tag picker slowdown and Dave's threat on bi-directional linking. From these discussions on the TW tech and user behaviour with relations, I think it could be useful to have a more fundamental discussion about relations (tags and links).
My understanding is that tags slow TiddlyWiki down faster than links if you want to tag everything and create a giant hierarchy. That would be a good topic for discussion to clarify if that is the case or not. Part of the slowdown, if I am understanding correctly, is the elaborate CSS of tag pills and dropdowns for each one, and the often convoluted list filters we use for listing tiddlers by tag. But then perhaps links slow it down just as much. I don't know, but TiddlyBlink is in part to avoid tagging as much as possible.
Note to Mark: Try the following in your Stylesheet to overcome the vertical list of tags problem:```/*TAG EDITOR AND DROPDOWNS*/ html body.tc-body .tc-block-dropdown-wrapper {width:800px;color:#2200bb;} html body.tc-body .tc-block-dropdown {width:800px;white-space:normal;color:#2200bb;} html body.tc-body .tc-block-dropdown a {display: inline-block;color:#2200bb;} html body.tc-body .tc-block-dropdown svg {height: 1.2em;fill:#ccc;display:inline;color:#2200bb;} /*TAG LABELS*/ html body.tc-body .tc-tag-label {font-family: 'Arial'; font-size:10pt; color:#2200bb;background-color:#eee;margin-bottom:6px;font-weight: bold;} html body.tc-body .tc-menu-list-item {font-weight: bold; color:#2200bb;}
```
On Tuesday, February 11, 2020 at 8:38:47 AM UTC-8, David Gifford wrote:My understanding is that tags slow TiddlyWiki down faster than links if you want to tag everything and create a giant hierarchy. That would be a good topic for discussion to clarify if that is the case or not. Part of the slowdown, if I am understanding correctly, is the elaborate CSS of tag pills and dropdowns for each one,
and the often convoluted list filters we use for listing tiddlers by tag.
But then perhaps links slow it down just as much. I don't know, but TiddlyBlink is in part to avoid tagging as much as possible.
I hadn't heard about CSS slowing tags down.
When I tried to make a TW with 37000 vocabulary entries, it slowed to a standstill because the tag operator apparently isn't optimized for large numbers of tagged tiddlers. It turned out to be faster to do a search in the tag list field, which is surprising.
In terms of relations between tiddlers we have
- tags: can be hierarchies as in the TOC, and more network oriented. It gives us categories
- links: is a stronger relation that tags, it gives us a direct connection to another tiddler.
- backlinks: are also links, but not as intentional as normal links, thus these could bring some emergence and show connection you forgot.
- list
- listed
- searches (and bimlas forward linking thing)
That shouldn't be the case. see info above.When I tried to make a TW with 37000 vocabulary entries, it slowed to a standstill because the tag operator apparently isn't optimized for large numbers of tagged tiddlers. It turned out to be faster to do a search in the tag list field, which is surprising.It would be interesting to know the filter strings you used and how the tiddler / tag structure looked like.Latest TWs have a $tw.perf.log() function, which can give detailed info, in the dev-tools if performance-instrumentation is enabled. ...-mario
On Thursday, February 13, 2020 at 8:08:07 AM UTC-8, PMario wrote:That shouldn't be the case. see info above.When I tried to make a TW with 37000 vocabulary entries, it slowed to a standstill because the tag operator apparently isn't optimized for large numbers of tagged tiddlers. It turned out to be faster to do a search in the tag list field, which is surprising.It would be interesting to know the filter strings you used and how the tiddler / tag structure looked like.Latest TWs have a $tw.perf.log() function, which can give detailed info, in the dev-tools if performance-instrumentation is enabled. ...-marioIt wasn't something convoluted, if that's what you're getting at.
It was a simple tag[xxx] functionality that slowed to a crawl when there were thousands of tiddlers tagged. Replacing the tag operator with a search operator improved performance. There's no real hierarchy -- just a handful of tags to indicate that a tiddler is word, and what kind of functionality it has (adverb, verb, etc.) It was surprising that the tag operator performed so poorly.
It's not something that I want to recreate. I now have 72000 entries, and get reasonable performance on a tablet -- but I don't use the tag operator.
@david
>Links are better for sideways and one-level-up connections. Tags are better for multi-level tables of contents.
Yes that is why i use tags and links as i do. Tags are good for multi-level toc (as alo noted by @tiddlytweeter), but would it not be possible to use links for that also? Isn't that what you are doing David with blink?
If not. Are you maybe no so interested in multi-level toc?
>As Mark noted, long tags are terrible.
Why? Many of my tags have space in them, and some are sentences long but i dont see the problem with that. I just seach for them and select. A d why would a long link be better?
And I hope my poor spelling isn't a threat to the discussion in this thread :)
Yes that is why i use tags and links as i do. Tags are good for multi-level toc (as alo noted by @tiddlytweeter), but would it not be possible to use links for that also? Isn't that what you are doing David with blink?
If not. Are you maybe no so interested in multi-level toc?
>Just a footnote.
>On wider net, "tags" emerged as an alternative to "ranked categories".
>The point was to escape hierarchical placements with a cross-cutting labeling system.
>Its interesting that TW frequently revisits this issue in many forms weekly :).
>A lot of TOC type things are reconstructing via tags what basic naming might do better! Its an issue about "state of knowing" as much as "technique of fulfillment".
How would basic naming be better? Can you give an example?
Please elaborate on the state of knowing" as much as "technique of fulfillment" thing.
>IMO, and my interest, is really HOW to you combine "emergent knowledge" (tags good for that!) with "a nice logical user experience" (TOC good for that IF...)
Yes i agree. I am thinking that tags and links maybe could be collapsed to one thing to make connections and emergent knowledge structures more vissible.