I know this is probably an intractable problem, but the new 2.0 interface has one characteristics that throws me every time: the highlighted line is the first “Recent” hook, not the actual context item being hooked. Hence when I want to Copy hook (⌘C) or Hook to copied link (⌘V), which are my two main uses, I have a fraction of a second’s friction to double check I’m hooking the right things together.
Of course, I could not show the Recent list, but I actually find it useful …
If you asked me, I would highlight nothing when calling the hook shortcut. A simple press of the down button would then. signal intent (“I want to use the list of recent hooks”) and position the highlight bar in the first position …
[edited title at Luc’s suggestion to make it clearer]
Thank you, @seishonagon. I agree with you this is one of the current UX challenges posed by Hook due to it being rather unique (a contextual / context-sensitive app) : there are two objects: the context (title item) and the selection. People who use the keyboard (the majority of early adopters, and I ) need to know the conventions as a reflex.
There is definitely a tendency to assume that ⌘C applies to the selection rather than the title item, whereas it is ⇧⌘C that applies to the selection. The assignment is based on the fact that the vast majority of the time, the user actually wants to copy the Title (context) item, not the link. The links in the body of the window (HOOKED, RECENT and PINNED) are mostly used for opening items (return).
There are some UI/UX design solutions to this ambiguity, but there are tradeoffs. Rather than expression possibilities here, for now, I’ll try to just let you and other forum members inform us here of their opinions without saying much about the options. (I might chime in with some clarifications and explanations.)
I would suggest that it would be desirable in some situations to invoke Hook solely to view the selection list but without any contextual item at all. I may wish to use Hook to find an item which I know is in the recent list; currently that always results in adding the current document website etc to the recent list even if I do not want that item to be added to Hook. Complicating it more, there is then no way for me to delete such extraneous items from the Hook recent items list.
Continuing the thoughts further… Hook 2.0 appears to make the assumption that when retrieving a past item as a selection, the user will want to search by title or maybe in future releases search by tag. Perhaps there are some users who indeed want to create a large Hook database for that purpose, though I would argue that lots of other software applications are better for that purpose including DT3, KeepIt, and others.
I view Hook as much more helpful as a transient database - effortlessly tracking the documents and websites that I am using today or maybe that I used yesterday or a couple days ago. My key “search criteria” in this situation would be when I accessed it last - not a search by title or tag.
Thus I would suggest regarding the Recent list:
(1) Some automatic annotation of when each item was added to the Recent list would be very helpful - often “That website I viewed Tuesday morning” is the easiest/quickest means of retrieval
(2) The current maximum of 20 items in the Recent list seems arbitrary - the ability to include a higher (or infinite) number along with scrolling would be really helpful. I would use this all the time to retrieve items. This way if I am working on something now that I want to come back to in the future - but maybe do not want to go through the effort of formaly creating a record/tag/etc in some database - I could simply click the Hook icon in the menu bar, knowing that is going to add the current item to the “Recent” list and then I can easily retrieve that item tomorrow or next week.
A key problem with the list of 20 items is that currently an item disappears from the list when it is # 21. So I cannot rely on being able to retrieve something too far into the future because it may fall off the list. Much better would be for this list to fit as many items as I want, with the list organized by hour/day/week etc
Thanks @rkaplan, for the feedback. They would be worthy of a separate topic, given the focus of this topic (2202), which is that there are two objects to which commands apply in Hook window — and sometimes users use the wrong keyboard shortcut, as described above and rephrased below.
Title item (the “context”)
The selection (the link selected in HOOKED, RECENT, or PINNED sections)
There’s a parallel set of commands for each type of object, and the actual shortcuts are variants (so there’s a system) :
Title item:
c. Copy Link (⌘C)
d. Copy Markdown Link (⌘M)
e. Hook to Copied Link (⌘V or ⌘L)
f. Reveal File in Finder (⌘R) (if the title item is a file)
Selection
c. Copy Link (⇧⌘C)
d. Copy Markdown Link (⇧⌘M)
e. Hook to Copied Link (⇧⌘V or ⇧⌘L)
f. Reveal File in Finder (⇧⌘R) (enabled if the linked item is a file)
When using the trackpad/mouse there is no confusion. The occasional confusion is that sometimes one falsely expects ⌘C or ⌘M to operate on the selected link.
Like I said, we do have several ideas for helping people with the distinction.
FYI: (There are other commands listed on the shortcuts page. And we will very soon add “open” (which is ‘return’ key for links) and “rename” commands/shortcuts for each type of object).