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. 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!
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
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 : -)
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:
- there would be sections (including new kinds information compared to what we’ve shown previously),
- 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 . 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.