I think this is a point where it’s helpful to take a step back in scope — instead of looking for LLM tree UI implementations, we should consider the mature field of general text hierarchies. I’m lazy, but I posit there are many, many UIs for visualizing wikilink-esque document repositories, such as obsidian plugins (?), browser extensions, vim/emacs/other plugins, etc.
Personally, I’m a huge fan of a few principles that I hope to impose on the world via book, eventually:
1. Indices over keys.
2. No single set should have more than N elements, where N is usually 10 but could be 2/3/4 if you’re doing decision trees, and could be 16 if you’re insane and want to use hex indices.
3. Each element can be referenced locally with a simple index (`3`), or a full path made by concatenating the indices of its ancestors from the root (`053`).
This would be an example of an “analytic” approach, as opposed to the ad-hoc “synthetic” approach of just visualizing whatever wikilink structure there happens to be. There’s a huge space of solutions “between” these two - such as constraining the ad-hoc visualization to meta-tagged wikilink relations — but I think the dichotomy is useful.
Personally, I prefer to use predesigned structures wherever possible for exactly these reasons. It makes automated visualization possible, in many cases… An example would be reusing the same 3/4 12-element directory template for every SWE project. I hope it’s clear how the same idea could be directly applied to a research project performed with lots of automated LLM queries.
Personally, I’m a huge fan of a few principles that I hope to impose on the world via book, eventually:
1. Indices over keys.
2. No single set should have more than N elements, where N is usually 10 but could be 2/3/4 if you’re doing decision trees, and could be 16 if you’re insane and want to use hex indices.
3. Each element can be referenced locally with a simple index (`3`), or a full path made by concatenating the indices of its ancestors from the root (`053`).
This would be an example of an “analytic” approach, as opposed to the ad-hoc “synthetic” approach of just visualizing whatever wikilink structure there happens to be. There’s a huge space of solutions “between” these two - such as constraining the ad-hoc visualization to meta-tagged wikilink relations — but I think the dichotomy is useful.
Personally, I prefer to use predesigned structures wherever possible for exactly these reasons. It makes automated visualization possible, in many cases… An example would be reusing the same 3/4 12-element directory template for every SWE project. I hope it’s clear how the same idea could be directly applied to a research project performed with lots of automated LLM queries.