Project Search, Search Results & Binder History

  1. Project search replaces the Binder view with the striped search results view. So the Project search field really should be over the binder, not over the documents. It can sit at the very top of the binder, and be available even if the toolbar is off.

  2. Saved searches would be more visible and accessible if they were listed in the search drop-down itself, perhaps directly under or above “Save Search”.

  3. The binder shows binder contents in different states (what’s open, what’s closed, perhaps some form of “hoisting” to focus on a sub-document); as well as search results. Perhaps a separate history and back/forward button for the binder?

  4. The results of a project search appear as a flat list. It can be quite helpful to see binder context for each item. “Reveal in Binder” would work well if some kind of “Back” button on the Binder (see #3) took me back to the Search results screen.

1 is pretty standard - a search field in the toolbar is normal and you get used to where it affects. That won’t change.

I like no. 2. A submenu of saved searches in the search menu instead of having saved searches in the binder at all would actually be a much better solution and I may change it to work like that for 2.0.

Hoist may come in 2.0. I’ve added code but have yet to test it in the interface, so I can’t promise anything.

As for 4, the flat list for search results will remain. Again, it’s pretty standard, and besides the control won’t allow for arbitrary levels for this sort of thing.

Best,
Keith

#3: was not wishing for hoisting, but providing examples where a “binder-panel history” would be useful.

#4: was not arguing to change the flat list, but proposing two ways to conveniently see see the binder-context for each element in the list.

Thanks

Keith:

If you implement saved searches in the dropdown, will we be able to arrange them in subfolders? I like this idea but don’t know how practical it would be.

When I click on a binder-item result of a Project Search, it would be great if the text could jump automatically to show the first hit in that document.

It would also be great if I could choose to exclude Document Notes from a Project Search.

  1. You can just use cmd-F (normal Find) to go through all results within the document - the search term will be loaded up.

  2. Under the “Search In” section of the search field menu you can choose only to search in certain parts of the document (although at the moment you cannot combine them).

Hope that helps.

All the best,
Keith

So I can! (Although to be picky, it is slightly annoying that, after clicking on a binder document, I then have to click back into the main pane to give it focus before cmd-F (or, better, cmd-G) will work this way. Otherwise I just get an error beep.)

I set the toolbar to text-only immediately I first got Scriv and only ever invoked Project Search with the key command, so I actually never knew there were search options. :wink: So now I will use hide/show toolbar instead. Thanks!

Changing that behaviour would have an annoying side-effect for people who are browsing through the Binder looking for something. They would need to be constantly switching back to Binder focus after every selection.

You can access full search capabilities without the toolbar even being shown. Cmd-Ctrl-F will ordinarily put the cursor in the search field, but if the toolbar is hidden it will open a separate window (which contains the search options menu). So if you like, you can keep things in text only mode.

I don’t quite understand the situation you mean. If they’re navigating by cursor down through the binder results, they still have to switch focus to the editor to scroll and see more of the text than fits in the current view, and then back again. And if they’re navigating by mouse, selecting a document and then selecting some text in the editor, then a click in another part of the binder result list immediately switches to that document with no necessity first to switch focus.

Personally, in general I resent being forced to use the mouse. Perhaps an equitable solution would be to have, as well as (or even instead of) the “Navigate to” commands, a key command simply to cycle focus forwards or backwards through binder/each visible pane, like cmd- and cmd-tab- work in multi-window apps. (Unless this already exists and I don’t know about it.)

My bad: that is actually the behaviour with a text-only toolbar too (because there is no search field). I just never noticed the disclosure triangle that harbours the search options. :wink:

Would now be the right time to confess I never RTFM or WTFT because I was, um, too busy writing? :blush:

2.0 will have ctrl-tab to switch between the binder and editors. However, Amber is right. It would be horrible if you navigated in the binder and as soon as selecting a document there the focus was immediately stolen by the editor - you would never be able to use the arrow keys to navigate down through documents in the binder as for each document you selected you would suddenly find the editor had focus and would have to click back into the binder again. Not good at all.
Best,
Keith

Good news! 8)