GranularAddressability in tank-notes

Markdown Help

On G+ @eekim asks "Curious: Why no granular addressability?" I responded there with the short answer: "Because it is a complicated rabbit hole."

I'll try to write a bit more detail here:

Some of the various conflicting factors, conflicting in various ways are:

* It's never been particular clear that people who don't already want granularity ever will. As such it is a hard UI/UX nut to crack.

* There are multiple competing ways to implement, none of which have proven to be absolutely superior:

* The PurpleWiki way of putting markup for nids in the origin text. The current editor is expected to leave these alone while editing if they are already there and expects to have them added if they are not already on blocks. Some people find this perfectly natural, other people don't care and still others hate it.

* Adding to the rendered text, client side, using hashing of the text of the blocks. This is how I've done it on my space on TiddlySpace and is resilient in the face of blocks moving in the same document but is not in the face of edits nor in the face of content moving between documents. (Note, this method was somewhat inspired by Kragen's notion of queer numbers.)

* Smark, block-based, editors which presents a single document but processes nodes. I've not seen this implemented in a truly granular way but there have been various efforts.

* Some sort of out of band metadata which "knows" how to granularize an associated document.

* There is debate over whether ids should persist across (minor) changes in nodes. That is, does the id belong to the node in the document (at HEAD) or should it be associated with the node at a revision. My feeling is that the latter breaks the synthetic power of the granularity, but there are people who very much disagree.

* There has been some discussion that breaking a tiddler, which is already supposed to be "microcontent", into smaller pieces works against the tiddler concept (which is supposed to encourage composition from parts and decomposition into parts).

* When you have granularity, what do you store? Document? Singular nodes? Graph of nodes? Back in the Purplewiki days I tried much of this without a solid outcome.

* All the usual UI questions.

At the moment my take is that in the absence any clear path to a purple style of granularity the right thing to do is enhance the transclusion and extraclusion features to make it easier to create granularity, and then determine best ways to expose it.

As things stand the Markdown render is set up to put anchors on any header element. The markup for transcluded content could be adjusted to provide the same. Then the UI could make those anchors visible for linking.

This misses out many of the reader-side benefits of content agnostic granularity but still provides some.

Autocomplete tags from:

Global tags Local tags