As soon as we released Hookmark 1.0 in beta, we received several requests for a more visual representation of the links managed by Hookmark. (For example, this post in February 2019, the month we released Hookmark beta.)
Here’s a conceptual schema of a network graph view.
We would like to gauge the interest in a visual representation of the links in Hookmark. A initial version of this would be a floating window that shows the network of links from the current context. Like the menubar icon, it would dynamically update itself based on the selection or open resource in the foreground app. For apps that are most link-friendly using AppleScript, Hookmark the updating would be dynamic. For apps that use other means of automated linking (such as x-callback-url or UI scripting), you’d need to manually refresh the Graph View window, or select a bookmark in the Bookmarks window.
I like the sound of this. I can’t be sure how much I’d use it, but it’s clearly the case that I see things in visually presented information that I overlook in a list.
Visual representations are almost always better. I would use this. It’s a bit like the graph in Obsidian, but much more powerful in that it picks up items not inside the Obsidian silo.
Definitely interested in a graphical network view of hooked items, especially as part of a hook bookmark library management feature. Think of the way Personal Wiki systems (Obsidian, Org Mode, etc.) allow you to assess the network of interdependent links and update them to reflect your current understanding of the information and it’s use in subsequent projects.
Barring divine intervention of the UI gods it would probably be a distraction. I could find use of an inverted tree of links similar to the graphic assuming it was functional. Would I be able to add a link directly from pdf-a to pdf-c from within the graph or open a selected link? How many levels would it cover and would that be a selectable range? Etc, etc.
I’m not a bit interested. I’ve used Obsidian for years and love it, but I never use the graph view. I’ve looked at it a few times because it is pretty, but have never used it for anything productive. Don’t waste your time on bringing it to Hookmark.
Just adding my thoughts on what utility I am truly seeking from Hookmark. Between the “Hooked” and “Indirectly Hooked” lists that appear when I invoke Hookmark on a file (or other linkable object), I can quickly access items that conceptually “fan out” from the item I have selected, allowing for quick navigation to nearby items.
What benefit does the addition of network graph view UI give the user? It may come down to the user, who may be more visually oriented. In my usage, how close nearby doesn’t matter, I only need quick access to nearby items - which “Indirectly Hooked” caters beautifully for. A network graph view may show the same information, but the user would need to visually scan across it to pick out the item - I think a list is much cleaner and faster.
Underdeveloped thought here, but I use HM as an archive of connectedness. Invoking it thus enables me to rediscover sometimes unexpected connections that I have already established. That archive of connectedness also offers real convenience, moving back and forth across a group of hooked items.
The sort of larger scale discovery of connectedness that a graphic view nominally offers moves Hookmark toward being a different sort of tool - it shifts from being fantastic at making visible the interconnecting edges to instead focusing on the nodes.
