Attaching link-sets to editable tags, rather than to filenames?

[RobTrew]

The point of Hook is to have a set of links immediately at hand in a given context.

A document turns out in practice (at least in my experience) to be a weak or even dysfunctional proxy for a mental context or project. The file name of that document is an even weaker proxy.

For example, if I collect some notes around draft-001.txt (assuming that file to be pivotal in a current project) Hook inevitably fails me when:

1. The focus of a project shifts to a different document within it, and
2. when I increment the filename to draft-002.txt

• Where have all my links gone ?
• How do I transfer them now to a newly focal document in the same project ?
• How even do I transfer them to a different version of the same file, if the filename is adjusted in any way ?

Such questions obviously trip the user over – distracting and frustrating – ramping up unrewarded cognitive costs, just when Hook should be making it easier to holding a train of thought and focus on a project.

These sudden costs, sudden disappearances of sets of links (in whose collection significant effort has been invested), are hard-baked into the current design, which is structured by what looks to me like a category error.

The understandable initial hypothesis of Hook has been that a filename might prove to be a workable proxy for a mental context.

A perfectly respectable hypothesis, and worth testing.

But it doesn’t survive experiment.

Summary

The universal (and user-scriptable) url scheme is a value.

The idea of document ⇄ document links turns out to be a liability and real cost. A failed experiment, I think.

1. The group of links accumulated for a project needs to be immediately available to a set of documents.
2. The totality of links needs to be viewable and editable to the user.
3. In particular links need to be transferable from one (project/context) to another

I don’t use tags myself for other purposes, but in this context I probably would.

The Hook graph/network of links needs nodes which are editable named projects, between which links can be copied and pasted. Tags are one already well-supported and well-understood route to that, and seem worth considering.

If several links are attached to a tag, that tag could be applied to a folder or to a subset of files.

The set of links attached to a tag could also be edited.

Essentially the links for a project need to be:

• available from more than one document,
• transferable between documents, and between projects
• visible to the user as a named set, and editable.

Universal (possibly tag-based ?) bookmark management for projects.

‘Hooks’ ? Not really. Something closer to artist’s palettes. Each daub of paint a tag.

[stevelw]

This doesn’t deny your other points, but Hook links (with the exception of some apps which break their own links) remain when files are renamed.

It is also possible to copy links between contexts.

[quorm]

I’m not sure how this would all be implemented, but I’d mention that I think Hook is not so much document-oriented as it is oriented to linking “data objects” in however way such objects are exposed (via scripting) to the user. E.g., we can (or, at least some people can) link to “sheets” in Ulysses, which are not really “documents” and are not locatable in the file system. Contacts in Contacts, tasks in OmniFocus, etc. Personally, when I use Hook it is not so much to connect file A to file B, but tasks in OF to items in Agenda, and similar.

So, I would be curious how that case is accounted for in your concept @RobTrew

[RobTrew]

@stevelw

with the exception of some apps which …

Perhaps I am unlucky in my main working apps

[RobTrew]

@quorm

tasks in OF to items in Agenda

I see that as a subset of the general case, which is [a] -> a

(a list of entities to a single entity)

There is a subset of that in which the context list, on the left hand side, is a list containing a single entity.

My reading of the current glitch in the design is that the architecture is built around an a -> a pattern.

In fact, the mental context → target resource relationship turns out to be asymmetrical in its underlying data-type. A potentially compound context to the left, and an atomic resource to the right.

[RobTrew]

@stevelw

possible to copy links between contexts.

We can use Copy All Links with one document, and then Link to Copied addresses in another.

BUT three points:

• In terms of operational and cognitive load on the user – easier to add an atom to a multiple context than to repeatedly carry the set of targets over to each document or entity in the context.
• In terms of adding new targets to a context, if the context is multiply defined, then every entity in the context immediately gets access to each new target that is added. (Otherwise, for each new link, we have to repeat the copy paste for every entity in the context. Cognitively and operationally very expensive, almost to the point of absurdity, certainly well beyond the points of practicality and cognitive efficiency )
• In terms of database bloat, multiply copying target sets one by one to each element in the context set inflates the database in proportion to the size of the cartesian product of the context set and the target set. At any scale, it will soon begin to slow retrieval in a related proportion.

One way or another, the a -> a architecture is a defective model of what is really going on.

The reality is much better modelled by [a] -> a, which immediately:

• lowers the operational and cognitive costs for the user,
• reduces the database size, and
• protects against slowing of database retrieval over time.

[RobTrew]

@stevelw

when files are renamed.

Are we talking about the same thing ?

I’m speaking of the case in which I move from draft-001.txt to draft-002.txt, not via a mutative ‘rename’, but via an incremental Save As so that I can retain the earlier draft.

In Atom and TaskPaper at least (central instruments of my work), Hook sheds all accumulated links from my working context every time I do that.

Are there applications in which the picture would be any different ?

[stevelw]

@RobTrew

not via a mutative ‘rename’, but via an incremental Save As so that I can retain the earlier draft.

Ah, I had misunderstood that. Any app which implements macOS versioning would work without a new version, but presumably you want to easily access specific older versions.

How I would handle that is use Save As to make an archived version, use Hook to link that archived version to the current working version, then continue working from that.

[RobTrew]

@stevelw

use Save As to make an archived version, use Hook to link that archived version to the current working version, then continue working from that.

OK. Sounds a bit complex and distracting, operationally …

In the meanwhile, I think I might personally be more inclined to put the Hook database aside, and write myself a KM macro which:

• Attaches all new Hook links to an enclosing folder (rather than active file)
• and offers a menu of accumulated links when I’m working with any file enclosed by the folder.

[LucB]

I’m very grateful that we’re having this interesting discussion about personal information management, and that needs for future development of Hook are being discussed. Some quick replies.

@stevelw

How I would handle that is use Save As to make an archived version, use Hook to link that archived version to the current working version, then continue working from that.

I tend to do something like this for substantial documents that I write. I continue working on the “main branch” of my documents, and I sometimes create archived copies along the way (often using Finder > File > Duplicate, or Archive). The links remain attached to the “main branch” of my document. I rarely bother relinking the archived copies because it’s unlikely that I would resume working directly from the archive. And if I did, I could easily merge the content from the archived copy to the “main branch”. (For substantial writing, I also tend to maintain many ancillary files.) With this approach, although I maintain revisions (copies), I rarely need to manually manage links.

(In earlier iterations of Hook, before its public beta release, links would remain associated with copies of documents. But that had several disadvantages. In particular one would end up with irrelevant links.)

IMO, Hook handles the archiving scenario as described quite well.

@RobTrew

• Where have all my links gone ?

With this workflow that question does not arise.

@RobTrew

• How do I transfer them now to a newly focal document in the same project ?
• How even do I transfer them to a different version of the same file, if the filename is adjusted in any way ?

I could in principle use “Copy All Links” but again I don’t tend to need to do that because I work off the “main branch”. In the future, Hook needs to support multi-selection and operations on multi-selections of links.

@RobTrew

These sudden costs, sudden disappearances of sets of links (in whose collection significant effort has been invested), are hard-baked

Links don’t disappear. They continue to point at the original resource from which editing may proceed.

@quorm

I think Hook is not so much document-oriented as it is oriented to linking “data objects” in however way such objects are exposed (via scripting) to the user. E.g., we can (or, at least some people can) link to “sheets” in Ulysses, which are not really “documents” and are not locatable in the file system.

I think that’s an important point. Hook supports linking to (and navigating among) as many types of resource as possible. This is helpful for a large variety of use cases.

@RobTrew

• The group of links accumulated for a project needs to be immediately available to a set of documents.
• The totality of links needs to be viewable and editable to the user.
• In particular links need to be transferable from one (project/context) to another

This requires a longer answer than I will provide right now. In a nutshell, I acknowledge that many users will find it helpful for Hook to support some kind of tagging/project feature.

1. This does not mean that tag/mesh like features handle the majority of cases,
2. nor even that it will/would be useful to most users or most use cases,
3. nor that tagging should have been part of a minimum viable Hook product.

This is based on my prior analysis. I believe it is corroborated by the Benefits page which links to several other page, which essentially contain a long list of use cases/benefits that are not predicated on tags/projects). Again, I am not saying that tagging won’t be helpful. I’m suggesting that “The idea of document ⇄ document links turns out to be a liability and real cost. A failed experiment, I think.” is incorrect. Can Hook be made even more useful. Yes.

Also, I think that the tagging/project feature that we will/would produce will be pleasantly original/unpredicted.

More anon.

[RobTrew]

The trick is to get to the stage where using Hook is transparent and helpful enough to go viral.

Not there yet – I had stopped using Hook for a while – the ratio of operational value and visibility to operational cost just wasn’t working – and at least one other user has reported the same to me.

I’m using it a bit more now that I’ve discarded the pop-up and moved to using Markdown links in a TaskPaper file for each project, but that won’t suit all.

Links don’t disappear. They continue to point at the original resource from which editing may proceed.

The point is that links do disappear from the working context of the Hook user. They are no longer simply at hand – the whole proposition of Hook.

I think you’ve got a very good chance of getting there, but over-attachment to an existing scheme can be a symptom more of the Concorde fallacy than of iterative optimisation (of value divided by cognitive processing cost) for the user.

Schemes like:

use Save As to make an archived version, use Hook to link that archived version to the current working version, then continue working from that.

offer little (if any) improvement (in the ratio of value/effort for the user) when measured against the old-fashioned (Hookless) expedient of keeping a markdown link in a text file.

Yes, that can be done, but now we have two problems instead of one. Not just

• where do I keep my links ? but also
• how do I work around the Hook architecture in this context ?

Users will need something slightly more transparent and effortless if use of Hook is going to catch on and spread, and not be gradually put aside after a week or two of favourably inclined experiment.

What your business needs is a natural continuity of use, and a natural tendency to recommend to others.

Web links found it. Hook links may, but haven’t yet.