If there are sufficient user requests, we will introduce an option to automatically hide Bookmarks window, but I doubt most users will want that. I suspect most users will use bookmarks window to do multistep operations, so they won’t want to automatically close the window. For instance,
Bookmarks window supports multi-select, which requires persisting the window.
user may wish to do multiple operations in the Bookmarks window
Hookmark 6.1 has a tag view.
Hookmark 6.x will support drag & drop onto the bookmarks window and from Bookmarks window. E.g., you’ll be able to multi-select items in the context window and drag them onto one or more bookmarks in the Bookmarks window to mesh link them together. **_Obviously if we had all the UI in a context window as some users have suggested, this would be impossible or at least impractical.
Consider traditional, old school, bookmark managers like GoodLinks, Instapaper Pocket and Anybox. They don’t auto-dismiss the window.
Elsewhere on this forum I have explained why there are now two windows:
Context-sensitive: Contextual window
context-free ( Bookmarks window)
Would be impossible, or at least impractical from a UX and UI perspective. What happens when we’re designing software is that we spend hours, days, weeks , months thinking through the design space. We’re very happy to receive user feedback, questions, and criticism. But each individual user just sees a small % of the feedback on the app. We receive emails, PMs, etc. and talk internally for hours and hours about Hookmark. That doesn’t mean our decisions are perfect, but I can assure everyone on the forum that we are confident our decision to have 2 windows ( Bookmarks + Context sensitive) is a wise one.
There are many, many, many new capabilities coming to Hookmark which inform the new UI. We can’t disclose them, except to Hookmark Ambassadors (readers who wants to become an ambassador can PM me).
thanks again for writing. We will update our software.
I forgot one more thing. When I hook a URL to something, I have to copy the URL twice, so Hookmark shows the title.
Meaning, I copy the link, paste it to the other thing, and Hookmark shows the URL as the bookmark title (in the list of hooked things). I go back to the URL, copy the link again, and then Hookmark shows the page title as the title.
I’ve encountered the same issue with version 6.0.1 (5788). Additionally, I’ve noticed a somewhat counterintuitive behavior in the bookmarks functionality. Here’s a step-by-step breakdown of the process:
I start by invoking Hook.
Next, I press ⌥⌘F to bring up the Bookmarks window. However, the last selected item remains active, which requires an extra step to actually execute a search.
To focus on the search bar, I need to press ⌘F, and then I enter my search terms.
After searching, I press Tab to change focus to the bookmarks list, using arrow keys to navigate to the desired bookmark.
However, there’s a hiccup here: pressing Return doesn’t open the selected bookmark as one might expect. Instead, it acts like a ‘Rename’ function, just like it works in Finder. To actually open a bookmark, I now have to use ⇧⌘O. While this is likely a matter of getting used to the new shortcut, I found the previous functionality, where Return would open the bookmark, to be more intuitive and faster.