How Do You Organize Tiddlers Without Losing Track as They Grow Fast?

The same button can be assigned multiple actions: a click could trigger downloading as JSON, shift+click might delete tiddlers, and drag-and-drop could move them. Including a confirmation step before deleting is a smart way to avoid accidental deletions.

This was something I was trying to make in my own wiki as a little side project but ended up not being able to get it to wok.
If I remember right I wanted to make it look like a bookmark icon, and when clicked, either it would get tagged as a bookmarked tiddler or added to a list field, I don’t recall which, but if it was bookmarked it would have a filled in button icon.
Just felt like sharing, I might attempt it again in the future, if anyone knows of any button templates similar to it, I’d appreciate the recommendation :grin:

This is what I use. It can probably be designed better. I use the above mentioned “plist” plugin to list the starred tiddlers to show previews with this command
<<plist "[has[star]!sort[modified]]">>

title: Star
tags: $:/tags/ViewTemplate
list-before: $:/core/ui/ViewTemplate/title
<div class="star">
<$reveal state=!!star  type="nomatch" text="star">
<$button class="tc-btn-invisible">
  <$action-setfield star=star />
  @@color:beige;font-size:2em; ★@@</$button>
</$reveal>
<$reveal state=!!star  type="match" text="star">
<$button class="tc-btn-invisible">
  <$action-deletefield star />
  @@color:lightgreen;font-size:2em; ★@@</$button>
</$reveal>
</div>

<style>
.star { position:absolute; margin-left:-2.3em;}
</style>

That’s a much better approach to what I was trying. I had tried to repurpose a viewTemplate editor button to take the title of the tiddler and add it to an index, and compare it to have it highlighted, definitely above my skill level :rofl:

I don’t see any links to @Mohammad’s Favorites plugin yet, so I’ll add a plug for it myself.

It’s a little “heavier” than @twMat’s single-tiddler solution: when you add a tiddler to your favorites, it gets stored in a list in a separate config tiddler, so it doesn’t “dirty” the content tiddler in question.

  • This may be less desirable if you’d like to keep the “favorite” status part of the tiddler itself, but on the flip side it means that if you share tiddlers between wikis, you can have a separate list of favorites in each one, and you can save and export these lists.
  • As an added bonus, these config tiddlers act like file folders: you can sort and categorize your favorite tiddlers and reorder them under a heading, just like a tag-pill dropdown.
2 Likes

The best solution depends on your workflow and data structure!

I absolutely have lots of wikis, partly because many of them open out onto particular collaborators or students, and I want them to have a neat window into the content that’s tailored to this or that particular shared project.

For example: I have one master bibliographic wiki, and then I have lots of projects (research projects, classes) that may need access to some books and other references. But copying those tiddlers (even if it’s as easy as dragging a tag pill) is asking for trouble!

So, certain wikis (such as the master biblio wiki) are authoritative for a certain kind of data, and others may “borrow” tiddlers as needed.

For that purpose, I use a “load-external” solution, as modeled here.

It enables me to avoid the predicament of having multiple copies of something — and then perhaps updating in the “child” location but not at the source. Either I don’t save those tiddlers at all at the more specific-purpose wiki, or I remain aware that any such biblio tiddlers may need updating.

Of course, “books and articles” is a very specific and well-structured data domain. I imagine more small-scale versions of this problem might arise if you’ve got one wiki for home tasks, and another for work tasks, and then you realize certain kinds of information need to be accessed from each.

Still, I think reflecting on where the info really “lives” usually tends to point me in one direction rather than the other.

2 Likes

How about tagging your tiddlers with pseudo-file folders? Not system tags with their prefix of: $:/; they will not show up in your “Tags Manager”. I have been using ./ as a prefix. Examples:

./AlfieA/RocketScience/
./AlfieA/RocketScience/NewTechnologies/
./AlfieA/Pets/
./AlfieA/Pets/Rabbits/
./AlfieA/Pets/Rabbits/Benny/
./AlfieA/Ideas/
./AlfieA/Ideas/InstantRamen/CookingTimes/UnderThreeMinutes/
./AlfieA/Ideas/InstantRamen/CookingTimes/UnderThreeMinutes/Results/
./AlfieA/Ideas/InstantRamen/Times/OverUnderThreeMinutes/Results/

As usual: no.coding.neccessary.

1 Like

@AlfieA this seems like a simple and neat way to organize data for my needs, thanks.

1 Like

Use Working flashcard system in tiddlywiki to revisit tiddlers, so you never afraid of lost any of them.

1 Like

You have a good naming convention. Clear titles make it much easier to find and organize tiddlers. One example I use for my code snippets is a rule similar to yours. For simple search, I use a Favorites folder with semantic names and tiddlers titled like this:

simple-search/readme
simple-search/styles
simple-search/ui
simple-search/procedures
simple-search/test01
simple-search/test02

The Favorites folder is quite handy for organizing tiddlers, much like organizing files on a computer disk. It uses a two-level hierarchy, which is straightforward and avoids confusion—humans tend to get overwhelmed with three or four levels!

Favorites Plugin from KPL

1 Like

An exercise I have found helpful in the past is to create a mind map of different topics and how they relate to one another. I also looked at Orphan tiddlers often to see the ones that are not linked anywhere to one another.

1 Like

Thank you. Plugin is polished, appealing and useful.

A little background on the ./. The “.” is one of the characters that’s listed first. The “/” denotes a folder. On my keyboard (I am in Japan and using a Japanese keyboard), the “.” and the “/” are right next to one another. They are also readily available characters on the mobile phone keyboards.
So, your thoughts…

1 Like

I am lately using a similar convention, albeit I prefer the term namespacing to pseudo-file folders and I use : instead of / as separator, so my hierarchically organized tiddlers look like Foo:Bar:Baz. I started to experiment with it after reading the naming chapter in GrokTiddlyWiki.

One can notice that the above convention, when used strictly, contains a lot of redundancy and leads to quite lenghty tiddler names, as they get structured into more nested levels.

My question is if it makes sense to relax the convention a bit to deal with these issues, and I’d like feedback about the danger of missing something important and potentially useful that is not instantly obvious to me, if I add one more rule about shortening the tiddler titles. Full tiddler names are of course useful (for specifying the full path from the root of the hierarchy) when they are the only tiddler piece containing this data. But in TiddlyWiki, for the sake of automatically having a ToC built, the user links tiddlers to their parent via a tag anyway.

I’ll expain my question with an example. In my personal knowledge base I have a chain of tiddlers like “root → OS → OS:Linux → Linux:Boot”. Notice Linux:Boot vs OS:Linux:Boot. Of course it’s just two chars (not too many pixels saved on a small device screen), but the main general idea is that one can cut a much longer multi-level prefix going back to root entirely, as long as a tiddler title somehow implies it all. As in when I think “Linux”, I think “operating system” anyway, so I can just name the tiddler “Linux”, because I have the link back to its parent “OS” anyway, through an “OS” tag.

Perhaps due to my professional experience, and the tools I used before I discovered TiddlyWiki I just want to say this has never being a problem for me, not to boast but to point out some people come to this a different way to others and dont expierence the same problems. I do use many of the tips and techniques mentioned above but the following principals should help guide everyone.

  • Not just for tiddlywiki

Try to never loose information

If you are entering an idea, or a todo item, a book idea or anything. At the time you create a tiddler you know more than you think and may not store this in the content. Each time I create a tiddler I let myself explore this and make sure I include this information. Perhaps once you have three items with a similar subject area you may organise it a little more.

  • Most commonly I add it to an existing project and/or domain (eg Life, Work, Recreation) at a minimum.

TiddlyWiki can evolve / maintain content independantly of the way you view and manipulate it.

It is quite easy to add systems and features to tiddlywiki as you go, start knowing you will let it evolve as you add content. If you see information is destinct and may grow a lot consider a dedicated tiddlywiki.

  • Seperate tiddlers into content only, listing/reports and other views and Code tiddlers. Maintaining these destinctions allows portability of your content tiddlers.
  • There are plenty of ways to batch manipulate tiddlers if you plan to reoganise your content.

Leverage existing solutions

At least to start with, I find it easy to turn things into projects and todo items there in, I also like to have “not to be actioned” notes so I use a heavily modified version of projectify that I evolve over time.

  • Keep in mind to select solutions whos approach means it would be easy to reuse and move content from. Often this is with tiddler based solutions ie one tiddler per piece of info.

Know where to put it so you know where to find it

There are lots of advanced content managment methods you can use, links intentional and automatic, search tools and tricks and tag managment tools to name a few.

However you should always have in your mind where you plan to store something,

and this same approach helps you find and search for it.

Write your own guidence documentation in a central place eg; Detailed research notes for tech evaluations can be found in this wiki, or for items you dont know if your will persue add them to the “Blue Sky” project… each time you deside on a grouping make a note in this tiddler (I personaly tend to remember these).

  • One trick is to have a place to save anything, then deside where to put it, once captured.

In each of my browsers I have a pinned tab containing a tiddlywiki dedicated to that browser and I store links to wikis that I use for different purposes, I know Chrome contains my personal organisation, Firefox my TiddlyWiki work etc…

File searchability

Keep in mind if you use somewhat descriptive words you may even be able to search accross wikis using the file system for both node and single file wikis. I often do a search limited to .json files that contain packages of tiddlers for reusable content. However there are cross wiki search indexing and other solutions available.

  • Encryption may destroy this approach.

Schedule content review and ADD infomation/relationships

TiddlyWiki already knows how to identify missing tiddlers, and you can always list tiddlers with no tags and various other searches that indicates content that may not be as well organised as it could be. Setting a little time asside to explore a wiki and look for ways to add information to your content that will help in the future. Some people have discovered new insights into thier data doing this, and there are plenty of tools to uncover relationships between content.

  • But this is often unnessasary if you followed the above suggestions.
  • I find it easier to do after adding new content. I was saving some ChatGPT answers when I realised it would be better to create a dedicated repository for LLM Q&A even if I point to items from another wiki.

I may return and add more if they come to mind.

One thing to consider when hardcoding the full path into tiddler titles is that it makes restructuring content hard, especially at higher levels in the hierarchy where a lot of downstream tiddlers may be affected. Not only do you have to change a few tags, but also all the titles. As restructuring is an activity that should come up regularly in a large wiki, this might make one wanting to avoid such restructuring even when one really should.

1 Like