No Copy as Link

I have to be missing something very simple. The quick start and everything I read say to select something, open Hook and select “Copy as Link.” Problem is, I do not have that menu choice no matter what is selected. Am I seeing old tutorials, or is something wrong with my installation?

Welcome to the Hook Productivity Forum, @ccrayton .

The screenshot you included is of the Gear menu at the bottom right of Hook’s contextual window. The Copy Link menu item is in the the Title menu, per Copy Link – Hook. If you click on the title of the Hook window, you will see the Title menu with that item. You can also access that menu by typing ⌃T when the Hook window is present.

When you click on a link, you will see the Link menu, which contains a corresponding menu (i.e., that operates on the linked item).

So it was really simple. :smile: I installed this about two weeks ago, and only had a chance to play with it today. As soon as you said that I remembered I needed to change the Typinator keystroke away from ^T (its default) so this would work. Thanks for the quick reply!

1 Like

Thanks again for your feedback. I’ve logged a feature change request to change the default status bar message to Click on the titlebar to see menu items for <title>".

Even though I use Hook frequently I also find the menus confusing. Two menus, where one would suffice. Items on each menu that look like they belong on the other menu. Visual clues that do not do what it would seem they do (i.e., there’s a downward pointing caret that does nothing, except every once and a while it does something).

Messy and not at all keyboard-only friendly. Could use advice from a UI / UX expert.

(and a bit of basic cognitive theory : -)

1 Like

thanks for the feedback, @quorm

which two do you want to merge? Are you talking about putting the Title menu commands directly in the Hook window?

Here is some of what we are considering going with the Hook window, due to adding new kind of information in the Hook window:

  1. there would be sections (including new kinds information compared to what we’ve shown previously),
  2. users would be able to configure which sections they see, including commands that are currently in the title menu. (Several people told us on the forum, when 1.3 was published, that they wanted to see the commands back in the main part of the UI window; I initially resisted this but with other information being configurable, giving the possibility of showing commands makes more sense than it did. But several people told us they prefer the 1.3 look. So we would give people the choice.)

By default, however, the Title commands will only be in the Title menu.

when does the caret do nothing? Every time you click on it, it exposes the title bar menu.

We did consider making the V button more button-like. There are many constraints/considerations. Amongst others, KIS, minimalism and design trends. For comparison, the firefox address bar has a similar indicator for similar purpose, as do many other apps. LaunchBar (which I use and love) only displays the gear menu when you hover over the title; and it’s just a one-liner until you type.

Every Title menu and Link menu command has a keyboard shortcut.

Well, you’re in luck Rob, because CogSci Apps has an integrative design-oriented cognitive scientist on board who’s written a couple of books on cognitive productivity :slight_smile: . Chapter seven of his first Cognitive Productivity book discusses reflective practice, where one learns from Schön that there’s no direct translation between science and practice. Applying scientific concepts and principles is typically rather messy and knowledge-intense. Cognitive science will not tell you exactly where to place your widgets. Being an engineer will not tell you exactly how to build your bridge.

Most of the time. Maybe after three or four clicks it does bring up a menu.

All of them. A little widget with multiple menus is unweildy.

I’m not a designer, just a user.

Thanks for your feedback, @quorm. I’ve logged an issue about clicking the title bar.

Our co-founder, @bshi, would like them in the main part of the window too. @grahamb had proposed (during the 1.3 design changes) that we give user the option to show the menu items, and I had gone against that to keep the app simple. But clearly enough users prefer the commands to be visible.

Might that suggest the raising of an eyebrow at the centrality of “cogsci” references in marketing ?

( A demonstrably excellent bridge is more persuasive than any pile of qualifications in some field of engineering )

Thanks for asking, Rob.

I do hope the CogSci Apps brand raises an eyebrow. In a nutshell, the line between science, engineering and application is not direct. But that’s not to say that science and engineering are irrelevant. It’s just to say that it’s complicated. I didn’t want to wax on about the brand in the forum (partly in deference to yourself, as I got the impression you didn’t want to hear about it). But you’ve inspired me to write some blog posts on it … at least to put it on my todo list. Meanwhile, the long version of the answer is in the Cognitive Productivity books. One way to read the first book is as a spec of weaknesses in software from a cogsci perspective. In fact, the book can be read as a subtle specification of several types of app, some for each chapter. CogSci Apps Corp. will not do them all; some of them its co-founder might be consulting on with other companies (…). In the first book and on the blog, I mention that I had an exchange with Steve Jobs about how to improve macOS and the announced iPad along cognitive productivity lines. I’ve also blogged about how Kindle could be better. Some of those changes are in place. Cognitive science helps one understand problems, requirements and overall design ideas. In engineering, that is typically what matters most, or at least a lot. Otherwise, one builds the wrong product, or fails to build the products that are needed.

To give an example: in my opinion, if one ships a productivity suite without a productive practice app , that suite is not a complete cognitive productivity suite. My first book makes a very strong case for that. and yet none of the big OS vendors and productivity suite vendors include that. And the concept of productive practice app itself cannot be articulated without an integrative design-oriented cognitive science perspective. In fact, the concept did not exist before I developed it. But it is based on other cognitive science concepts. I think if one disagrees with that, the discussion is best held on the forum for that book.

I agree qualifications in themselves don’t matter. Every company chooses a brand (hopefully aligned with their mission, core competencies, and values). Ours is sincerely based on a keen interest in cognitive science and a belief in its relevance to productivity software. I am deeply immersed in cogsci. I try to take the high road, a difficult one ( integrative design-oriented approach is not the easy way to do cogsci.) I do my best to apply the approach. I would have developed software much faster, and made a lot more money if I hadn’t cared about the approach. Conversely, I would have published loads of papers and books if I didn’t dedicate so much time to knowledge translation and building software. And none of our users are required to care about cognitive science. In fact, most obviously don’t. And that’s fine. Some people can see a pattern in mySleepButton, Hook and future products, and affiliated goods and services; some will appreciate it. But they do not have to.

Not to belabor the point, but one of our goals is to attract other cognitive scientists to the interesting issues that we address (information retrieval, etc.) We do have collaborators but we are seeking more momentum there. Also, as we roll out more features, the cogsci angle may become more apparent. Again, the story is longer than this. E.g., my Cognitive Productivity books are not short, and there are several other resources that substantiate the cognitive science research programmes in which our work is inscribed. But I don’t discuss it much on the forum. I’m delving into some of it here because you asked.

1 Like

Hook version 1.5.1 contains a fix for this issue (to make it easy for users to get the title menu by clicking on the title or V icon).

I have 1.5.1 and it is not fixed. I still need to click on the caret or nearby the caret 10 or 15 times before it activates the menu.

Thanks for letting us know. It will be interesting when we know what the difference is.

Hi @quorm,

have you tried disabling utilities such as Keyboard Maestro or Path Finder, or any other automation tool to see if it would eliminate the issue? E.g., if you were to launch Hook at startup before running other utilities, would you have the same issue?

If you use LaunchBar, does clicking on the title label in the bar work as expected (exposes a menu). It’s a different app, obviously; but the UX is similar. In its case, dragging the title label is for pasting contents of the referent; in our case it is for moving the window.

This is a mouse click we’re talking about. KM is not running. Do not own LaunchBar or Path Finder.

It’s not the gear in the Hook menu that is difficult to successfully click. It is the rest of the control – the leftmost 85% of so of the bar. It’s just not a good design.

Thanks. Yes, we understand you are having difficulty with the label. We haven’t been able to reproduce it in 1.5.1 (and have investigated with curiosity), but the code to allow both dragging and clicking the label would likely be the issue. So we might provide an advanced preference to allow users to turn it off.

I recall your opinion on that. Our own assessment of the design, as is typical in software development, is based on multiple criteria/constraints/requirements (one may be surprised to find how long and intricate is the list of requirements behind a UI decision, and how many extensive discussions happen in a company regarding what may seem simple from the outside). It resembles an optimization problem. Developers will never be able to please everyone. The current design is a bit like launchers, which are also compact and also place some commands in a menu. To vaguely allude to an obvious set of requirements: Space is at a premium on Macbooks. ( there are other considerations.) However, as you may recall, following user feedback on Hook 1.3, we’ve signaled our intention to provide a non-default option to put commands in the Hook window for users who are not inclined or able to use the much faster alternative of keyboard shortcuts (99% of the time when interacting with the Title menu, users would use Copy Link, for which Hook provides ⌘C as keyboard shortcut, which is standard in macOS, and ⌘V, also quite standard in macOS – you can think of Hook to Copied Link [previously known as Link to Copied Address, as pasting a bidirectional link in the Hook database. However, there are other useful commands in the Title menu, and we do not expect/require people to memorize or even use keyboard shortcuts. )

The “copy link” menu doesn’t open for me, at all. I’m on Mac. I just bought the paid version of Hook and would love to use it. Am I doing something wrong?
Here is a video

Thank you for sharing that, @Ingrid, and Welcome to the Hook Productivity Forum.

We didn’t get to the bottom of why one or two users, and now yourself, experience the issue but not others.

However, we’ve made significant changes to the title menu in the upcoming Hook 2.0, private beta, which likely fixes that issue as a side effect. (Public beta expected this week).

If you try ⌃T does that show the title menu?