Hook 3.6 asks for permission to access apps that make no sense to have Hook involved. In the hour since I installed 3.6 I’ve been asked by Hook to give it access to:
the SpeedTest app
the NetAuthAgent app (this agent checks to see if network disks are mounted)
the AdGuard preference configuration app
These apps have been around on my system for a long time, and I’ve used them for a long time while previous versions of Hook were running. Why, now, does Hook 3.6 want access them -– I see no reason at all to Hook to the NetAuthAgent app, etc. Obviously, just to make Hook go away I’ve denied access.
Edit: just after posting, Hook requested access control for coreautha -– a system control related to TouchID. It’s ridiculous that Hook would ever been used with a background daemon like this.
I think that suggesting I hobble an interesting new feature to prevent Hook from asking to control apps that no reasonable person would want to create a link to using Hook is unfortunate. In essence: “You can have our nice new feature if you’re willing to put up with annoying behavior from our software.”
I would rather that Hook be customer-friendly by being a bit intelligent about what it’s asking for -– i.e., don’t ask to control things like coreautha or NetAuthAgent. This is not difficult. If an app resides in the System library, for example, then program Hook to ignore it.
Like we said in the newsletter today, we are looking for feedback and realize that the feature will be improved. Adding further exclusions is on our list. I was just trying to say that for now if you don’t want the dialog boxes some of which are for irrelevant processes, you can turn the feature off. I was not saying that we won’t add more exclusions. Just giving you a way out if you want it. Your choice.
Our priority right now is to have a hot fix, or a quick release, to provide additional criteria to exclude feature-incompatible user-added scripts as such (an issue with a user-added Reminders script surfaced, a script we published).
We might soon after add a checkbox in user-defined scripts for users to exclude the script from this feature, and then deal with attempts to get hooked status from irrelevant headless processes.
Not only are the pop-ups annoying - they break the application. Many of these new pop-ups do not let you reject permission. Hitting the Decline button has no effect. I can’t tell if my answer is not registering, or if my negative answer prompts it to immediately ask the same question again. Either way, I’ve found the solution is to either quit Hook, or quit the app that Hook is requesting permission on. Hitting the Escape key seems to close the popup too.
Or simply accept that the whole idea of shifting attention to a separate area of the screen violates the Prime Directive of Hook - to reduce cognitive distraction.
And instead build a graphical tree allowing users to browse, search, and edit their entire Hook database.
I don’t see would be an either or @rkaplan. Several users have asked for the feature we have implemented. In fact it’s amongst our top requested features. There’s a different way to do it, also on product road map, also aligned with requests. We will reduce the notification noise in Hook 3.6.1.
As for the network views, we have not ruled it out. And we are happy to work with developers who want to build extensions, including us adding facilities in Hook automation to facilitate others using third party graphic libraries. The navigable list contextual window , however, is here to stay, though of course we will continue to release improvements to it.
As much as I am a big fan of what Hook can do, I am pointing out - in the interest of a constructive suggestion - a glaring inconsistency and one which clearly has been of concern to many users. There are not many software apps such as yours which discuss the academic theory of their design. Your whole existence and corporate mission is to reduce cognitive friction; but having to look at the menu bar to check if a file is Hooked and/or having to use memory to know what files are Hooked result in the exact opposite of your core mission.
Moreover quite a number of the requests I have seen on the Forum have been for a Hooked Indication to be not in the Menu Bar but rather integrated into the finder - similar to what Dropbox does in identifying local vs cloud files. An icon or other indicator in the finder does indeed reduce cognitive load since it is in the exact place a user needs to go anyway to access the file.
Trying to train oneself to routinely look in the Menu bar after selecting a file from the Finder is frankly a non-starter; virtually nobody is going to do it and those who do will note significant reduction in their efficiency on the computer.
Sorry to be so blunt. You have had many successes and I love the software. But between the security dialogs and the location of the alert, I very much believe the menu bar feature should simply be abandoned.
Thanks for clarifying, @rkaplan. I agree the menu bar icon is distant, particularly on a large monitor. It’s a first step. Having said that, we’ve already received feedback from users who are enjoying it, presumably because they don’t always need the information, and appreciate not having extra clutter in their UI. Moreover, the habit-forming power of new features can be hard to predict.
Still, we are very likely to implement an optional floating window that users can position where they want, as noted in:
We may be able to take that even further, but we can’t comment on that aspect yet.
as noted, that will be dealt with in Hook 3.6.1
We’ve recently added a bit of “Hook” Finder tag maintenance. Further Finder integration remains on our road map (competing with other features). However, we do need to keep in mind that Finder is just one of many apps with which Hook is compatible. Finder is important, but given that Hook works with so many apps, no app captures a large percentage, let alone the majority, of all usage. Hence, one of the advantages of the designs we have published and are developing in house for this feature is that they work consistently across all apps, such that user does not need to look in different places for same thing in different contexts— another cognitive consideration amongst a buch of tradeoffs. Having said that, Finder is of course special and merits, as you and I would agree on, special consideration.
It asked for login window permissions. I only discovered it when I tried to activate the menu bar icon. I set the prefs but I do not the menu bar icon.
A suggestion for whitelisting/blacklisting: Would it work to initially NOT poll apps, but the first time Hook is invoked manually on an app it is then polled from then on?
