Graph view (or at least, all hooks view)

Why doesn’t Hook yet have a graph view or, at least, an all hooks view? :wink:

Hook is capable, but I still have trouble wrapping my head around how I might want to link things together. One solution for me would be to have an all links view, or, ideally (and really… I think this would help sell Hook), a Graph view like Obsidian.

1 Like

Great suggestion. I can’t support this enough. Using Hook with Apple (supported by Apple Shortcuts) would take it to a new level if there were a graph. Currently I use Obsidian too because of the graph, but I’ll not experienced enough to do scripting on those files. This is where Shortcuts comes in. So I’m using both Notes and Obsidian, which becomes confusing.

1 Like

And it would be better than Obsidian’s because it wouldn’t be only markdown note files… it would be any file AND many other types of data.

it’s just fun to play with that graph view.

May I add a word or two of caution? I don’t use Obsidian so I don’t know if the example graph above is the only mode, the default mode or typical, but to my eye it’s awfully cluttered. Something like Tinderbox’s hyperbolic view, which can start at a note/ node and grows as you search/ navigate, seems more useful to me.
But TB has the advantage over Hook of knowing the contents of notes, which to Hook are just URIs. In TB you can readily search for notes (or sets of them) internally. Using a Hook graph I think you’d have to search for a starting point externally, which isn’t necessarily a problem given the power of tools like DEVONThink or Spotlight.

Finally, I think it’s worth asking the question, is this something that should be part of Hook? Hook is elegant in its simplicity, adding functionality might well detract from this. Perhaps the solution is to encourage CogSci to document, perhaps even open source, Hook’s database (it’s a SQLite file as far as I can see) so that others can write applications against it.

1 Like

A postscript to my previous post. I know that Hook has AppleScript automation, but if you’re going to write adjunctive applications that use Hook’s data, they’ll very likely be written in Swift or some other language. The question then is whether it’s easier for CogSci to write and maintain APIs for popular languages, or just publish/ license the data model. Every language has bindings to SQIite.

1 Like

Hook is elegant in its simplicity

I like Hook, more as a concept (still) and implementation than as a productive tool, but while it could be called “elegant” I don’t think it is simple. It’s actually (still) confusing. I don’t think it’s terminally confusing because improvements keep coming, but I feel like there’s too much attention on lesser-value improvements. I mean, it’s cool that Hook supports so many apps… but how many people use these apps? How many more people are going to care about Hook if you add support for another (essentially) no-name app/service?

But back to confusion…
One way to overcome this confusion is to make it so you can see the totality of your linked items… like in a graph view… and a popular graph view at the moment is in Obsidian. But, I’ll take a navigable/hierarchical list view. I just want to be able to see all of the stuff I’ve linked. (and, no, I won’t use the “Hook” tag because I don’t like “Hook” as a tag in my system… I want to be able to set my own tag to indicate hooked items, like this: :hook:. And, even then, the tag will only show me the Finder items). But seeing all the hooked stuff is not even a half-step towards discoverability. You need to see the lines so that your eyes can follow them without having to actually traverse each node. Again, like in a graph view.

I actually won’t use Obsidian (not interested in the limitations of plain text or markdown), but it is the current note/PKM darling. Everybody loves that graph view. Hook should have this attention because it is so much more than Obsidian… except when it comes to discoverability.

Hook is lacking a view on all hooked items. Showing the hooked items, in a linked map, is trivial (relatively speaking).