'Mesh' doesn't fix Hook's design problem

The ‘Mesh’ solution to the discovery hole at the heart of Hook’s design risks simply digging a deeper and larger hole (at a geometric rate).

If we select N files and drag them to the menu-bar hook icon, the notification tells us that sum [1..(N-1)] new links have been created. For example:

6   files ->   15 new links
10  files ->   45 new links
25  files ->  325 new links
100 files -> 4950 new links

In other words, instead of doing what we really need – adding a Project or Context element to the core of the scheme (as in where are all the links I need for project X ?) – the “mesh” approach still attempts, in the tradition of the Procustes story, to shoe-horn human work into the existing (and not really adequate, realistic or productive) url-only universe.

The Mesh solution is resource-expensive (inflates the database at geometric rates), inflexible (how do I add another 6 files to an existing mesh ?) and still leaves the hole at the middle of the donut:

  • what and where is the name of the project ?
  • how do I find it ?
  • what happens when the same file has a role in two or more projects ?
  • how do I add further links to an existing project ?

If I add six files, ‘mesh’ looks like this:


Whereas what cognitive efficiency really needs is a named project or context – a scheme which has TWO types of entities:

  • Named projects or contexts
  • links

(simplifying the addition of further links to an existing project, and saving the database from geometric bloat and redundant complexity):



Thanks, Rob. I should have said “and other features” :slight_smile:

1 Like

@RobTrew You probably know this already, but this is possible today with the central project entity being a notes file or similar.

A stellate structure in the existing url-only scheme would be:

  • Fiddly, inconvenient and accident-prone to build (you would have to return each time to the url which you had decided to consider axial – and make sure that you remembered which it was) – not a recipe for low-friction cognitive flow.
  • Unhelpful to use – from each satellite link we would only see the central link.

What we need is:

  • a default ‘current project’
  • a menu of such projects
  • project ⇄ url links

We need to be able to:

  • see, at a glance, all the urls that are linked to the currently default project,
  • browse quickly through the available projects, and see the sets of links attached to each,
  • immediately see all the links attached to any project(s) which the active file/resource is linked to.

We also need to be able to rapidly expand the url-list of a project by just:

  1. Setting the active project
  2. using a single shortcut on any file/resource which we want to add to that project.

It would also be helpful to enable the building of larger projects from smaller ones with project ⇄ project links.

I’m probably being naïve, but is some of what Rob is proposing achievable in TheBrain? https://www.thebrain.com/products/thebrain I’ve dabbled with it in the past, and I think I will try it again, particularly as the latest version of DEVONthink has left me dissatisfied.

I experimented with a horrible kludge yesterday in which I used a UUID as a tag, thus associating certain files with each other – look for the UUID in Spotlight or Leap and it shows all the files. Not really all that workable, but I wanted to play with the concept.

I do deeply appreciate the contributions.

However, 9 times out of 10 the typical user is linking objects outside of projects. User may work on N projects during a day, flipping between them. User will often do things outside of project mode in order to deal with asynchronous task demands.

I’m not denying the need to support projects in some form – for some users, some of the time. But there is a very large number of requirements at play here, a large number of possible designs whose trade-offs are complex and involve other information, and a product road map that we have not disclosed that will make some of this moot because we can deal better with what is discussed here than with a traditional project mindset.

but again, the input is helpful.

1 Like

“Projects” is just a word, a red herring, and I wouldn’t fixate on it. The problem I think @RobTrew is concerned about is that over the long run, unless we made sidenotes about what we did with Hook, the app fails at what it is supposed to make it easier: find related files and bits and pieces of apps like Bear, etc.

It is impossible to discover that relationships exist without manually clicking around to select a file or note in Bear or whatever and clicking around to see “hmmm, did I connect something to this with Hook”. Hook is a dark room.

I just want a super-index view that shows me all the blobs of Hooks that I’ve made so I can pick a blob from a view, maybe give it a name, and revisit that grouping and traverse the links.


Absolutely – a ‘blob’ by any other name would work as well.

Quorm’s helpful diagram shows a category with two levels of structure:

  • linked urls
  • blobs

Hook’s current defects are baked into the single-level design.

That is an evidence-based claim ?

The raw materials of a good design process are the points of friction.

In my work, Hook is impeding flow (to the point of limited utility) by failing to make existing (Hook-captured) links either visible or accessible while working with related resources.

Part of the solution lies in composable links. If if X is linked to Y, and Y to Z, then Z should be visible and clickable from X.

Y can be a hub entity (a named link-set|blob|context|project) or another url.

image File:Commutative diagram for morphism.svg - Wikipedia

Thanks, Rob. this is aligned with some of what we have in the near-term road map (and hence in our issue tracking system), and was part of what I was alluding to as things we intend to do that will address concerns expressed in these topics. Also near term is a “recent links” feature (for recently created or accessed links).

The underlying software can evolve gracefully to provide this, named blobs, and other navigation features we have planned but have not yet disclosed. Hence my resistance to labeling this as a “design problem”. Of course, there are several missing features, i.e., we have a road map.


My take on how Hook’s concept could be utilized more productively (for me at least) would be if it functioned as a universal tagging system. Currently macOS has tagging, but you cannot tag all elements with which I interact to work, such as email messages, Apple Notes, Apple Reminders, etc. And third party apps that have tagging capabilities don’t use Finder tags, so immediately you have multiple tagging systems. Keep It, the collection app I am currently using, syncs with Finder tags, but to tag emails I have to import them into Keep It, thus taking them out of context. To tag Apple Notes I have to share them with myself and then add a link to Keep It. This is disruptive to workflow. Hook seems to be a potential answer if one could link via Hook a “tag” to each item. I’ve envisioned creating text files with the file name serving as a “tag” and linking that to each file/email/etc that I want tagged, then viewing all items linked to that text file, BUT that only gives you a view to a single tag’s associated file and if you use tagging as I do, a project for example would have multiple tags that when combined result in a collection of items that make up the objects of the project. Using Hook via text files as tags breaks down in this instance because I can’t see the intersection of the sets of these “tags” which is what defines the various projects. Keep It allows me to drill down to more and more specific subsets of the whole through its tag cloud, but again, I have to import items to do this and can’t use an app such as Apple Notes or Reminders as taking them out of their native app doesn’t let one interact with them in their original format.

So in my mind, the linkage in Hook should be between various files and a metafile, then viewing the files that are linked to by a collection of those metafiles (“tags”) would create a focused view of files that I want to work on.


We can (have) certainly see(n) the usefulness of Hook with tags, including as a tag unification system, for many users and many uses. We don’t view the latter as the only way of using Hook (and probably not the standard usage once this kind of ability is in place). Examples where one often would not want to bother tagging/using a project: “Link to New” for annotating a doc one is reading; linking a pair of web pages together; drafting text for comment in a forum – eg. I am writing this in BBEdit; pasting links obtained from Hook into a document or field; sharing links with friends. (Benefits). In many of those cases, relating the resource to an aggregate (e.g., choosing a tag) is an unnecessary step. No need to consume resources.

(Having said the above, there are also some automatic ways of achieving some of these requirements, as @RobTrew alluded to above, that are also on our radar.)

I mention this not to say that tags, aggregation, and project management with Hook would not be helpful. I am saying this because so much emphasis in this thread has been put on these features that it seems helpful to put it all in context: Hook still needs to be useful for people that don’t want the overhead of projects, and to support the many cases that don’t require such an intermediate, extra step. (⌘N, and “Copy Link”+“Link to Copied Address” are comparatively rapid, highly automatic actions, which deal with a lot of cases. These are actions that users often take. Users are often in modes where their project is not clearly defined; when they need to switch tasks dynamically; even when they are in research mode but respond to opportunities or problems related to other motivators.)

So rather than “the linkage in Hook should be between various files and a metafile” we prefer to say that such abilities would (will) certainly be a great addition to Hook.

There are several possible requirements designs/variants of this – not all of which are compatible, but not all of which are mutually exclusive. This is and has been on our radar as I noted above. We can’t publicly commit to particular designs or ETAs at the moment (this is all interwoven with other requirements that have not yet figured on this forum), but we welcome this discussion. It has helped us realize that there are several expert users of Hook who want this very much as the main way of using Hook.

1 Like

Point taken about “should” versus “would”/“could”. As you say, I don’t see these approaches as mutually exclusive. The tags could be small text files as mentioned, but to make my system work, Hook would need to have a way to show the intersection of sets of files linked to the various tag files. I think that is a lot of the message in this thread, adding additional ways for Hook to display the information that it contains is needed, which it sounds like you are aware of and working on, which is exciting!

1 Like

This outlines my use experience with Hook and it has greatly enhanced my ability to access related material on the fly in my day to day use of my computer. That, to me, represents a success for Hook’s nimble approach. I can see the benefit of more advanced use modes described in this thread, but it’s certainly possible that they are covered by other apps which specialize in more intensive, project/blob oriented approaches. The sacrifice might be that for that approach to work optimally, you have to take items out of context and import them into the app (EagleFiler, etc).

The problem with other software (or even notes on paper) for visualizing and tracking the relationship between files / notes / images, etc., is that tools like that – I’m thinking of Curio, Tinderbox, Explain Everything, etc. – are external to the collection (blob) they describe. They are meta, and, like any metadata, require endless gardening to be useful. Whereas the innovative benefit of Hook is that Hook already contains the data about relationships internally – in theory (and maybe on the mysterious “road map”).

The frustration for now is that I cannot see what Hook knows the way Hook knows it – the current implementation is like a 2-D projection of a multidimensional set of relations. We cannot see past the edges.

But you already have a universal tagging system: Finder.

Tags are buckets – they are do not denote relationships between two edges.

See the image – the relations between A, B, and C in the three graphs are all different yet the edges are the same. I believe Hook is capable (someday) of capturing and displaying those relations to us, on the fly. If, however, all we did is apply tag RELATED to A, and B, and C, we would know nothing about their relationships other than they live in the same bucket.

1 Like

The Finder is most definitely NOT a universal tagging system. There are Finder tags yes, but they can only be applied to documents that Finder accesses. You cannot tag emails, Apple Notes, Apple Reminders, Message chats, or any other objects that are contained within a database system and not held in the Finder in some way.

Everyone has different ways of conceptualizing their work space and therefore different needs. Through a universal tagging system I can accomplish all of what you describe in an efficient manner, using a standardized set of tags and keyboard shortcuts. Each object is described by tags of various categories, including descriptive of what the file pertains to, but also status tags such as active, task, waiting on, etc.

Regardless of this, what I think the incredible power (and potential) of Hook is that the concept of it is adaptable to many, many different ways of approaching organization and structure for a wide variety of people. But that power for now isn’t fully accessible as you aptly describe. We need a way to visualize all the connections that Hook contains beyond what is visible in the current manifestation. Sounds like there is a roadmap that will address these issues that will become apparent over time.

1 Like