The key function of Hook (at least in my workflows), is to quickly provide a URL for any document (and sometimes even, given the excellent scriptability, to sub-components of a document or database).
The key weakness, at this stage, is in helping us find these URLs when we need them.
The current approach (link-collection menus available only from central working documents) inevitably fails us whenever a project has more than one central working document, either:
- at a given moment (2 or 3 main documents in a given project), or
- over time (different central documents at different stages of the same project.
In the medium or long term for Hook, project-level link collections for the Hook GUI seem likely to imply a root and branch rethink of the DB structure, and possibly even of the central marketing metaphor, but in the meanwhile, I find that when I do use Hook it is in a simpler but still very useful mode, in which all projects:
- Have their own project folder,
- have a TaskPaper (or other .txt) summary file at the top level of that folder, which (inter alia)
- Contains all the
Hook > Copy as Markdown LinkURLs that the project accumulates and needs.
A meta level of this, in my own case, is that I also have an
~/activeProjects.taskpaper file, which:
- Opens automatically at login,
- is always just one (Keyboard Maestro) shortcut away,
- contains (inter alia) names of, and Hook-pasted Markdown links to, the current handful of active project folders.
Hook > Copy as Markdown Linkis proving very useful.
Hook > Copy as Linkwell … to be honest … in this form … not so much …
To put it all a different way, the key cognitive links are not, in fact,
document -> document, they are really
project ⇄ document.