Wish Candidates: Project Search

[dbc183c7]

Expecting full well that much of v3+ is already coded, spec’d, time lined (hence ‘+’) ...

- It would be nice to navigate the Project Search options via keystroke, given that my hands were just on the keyboard and soon will be again to input my search string. (And that my mouse movement is less precise than my typing.)
- For navigating longer documents found by Project Search, once I’m in one of them, it would be nice were Ctrl-F (and its kin) pre-filled with the successful search string.
- In the Project Search box, a key-accessible drop-list of prior search strings would be nice. Likewise for Ctrl-F.
- And as a variation of that drop-list, once a filter option for a table search is selected for the Project Search (EG, Labels), it would be nice were there a table-value drop-list (IE EG, of the project’s labels).
- It would be better (for me?) were the Project Search string box to wait until I finished typing the string before it began its search. (I’m no typing-wiz, but no slouch either, so the code would not have to be too patient.)

(I still dream that one of the 'filter' options will be -- in v15? -- a cross-project search, perhaps only of the active project's contents dynamically, and of other projects' via static indicies, whether open or closed).

[AmberV]

For navigating longer documents found by Project Search, once I’m in one of them, it would be nice were Ctrl-F (and its kin) pre-filled with the successful search string.

That’s a part of the original design, but there are/were technical difficulties with populating the Find panel with data or altering its search parameters (to match the Project Search) programmatically. I’m not sure what the status on that one is, but we know about it!

In the Project Search box, a key-accessible drop-list of prior search strings would be nice. Likewise for Ctrl-F.

For Ctrl-F I can get there just fine with Shift-Tab (from the original Find field). All of the UI elements for me are selectable with the keyboard using (Shift)-Tab to rotate through them (caveat: I’m old school and run Win7 with the classic Win 2k era theme instead of that fancy frosted glass and Helvetica stuff that is all the rage these days, maybe MS took away the ability to tab between widgets—I’d imagine there would have been an uproar if they did though!).

As for the first part of that though, I’m not sure how that would be different than your first bullet point, so I may not be understanding either of them. If you mean to say the little magnifying glass thing, I don’t think it’s possible to get the keyboard in there from the field, unfortunately. Hmm, once the menu is open, some accelerators so that you can tap a key to select options would be nice, just like in the main menus. I’ll see about that.

If on the other hand you simply mean getting the cursor into the search field, try Ctrl-G, S (press G and then S in sequence).

And as a variation of that drop-list, once a filter option for a table search is selected for the Project Search (EG, Labels), it would be nice were there a table-value drop-list…

I need clarification on what you are referring to by “table-values” or “table search”.

It would be better (for me?) were the Project Search string box to wait until I finished typing the string before it began its search. (I’m no typing-wiz, but no slouch either, so the code would not have to be too patient.)

The idea behind the popularity of this model is that dynamic search results as you type promote efficient usage. If you find during the course of typing that you’ve narrowed the list down far enough to move on to browsing results, you can stop. With a blind search, where you type and then submit, you may not type in enough initially and have to perform a second search. This tends to result in overcorrecting, typing far more than you need to to actually get a good enough result.

It is also a matter of taste, to a degree, I’ll grant that, especially on slower computers, but I think the days of type-then-submit style searches have, for most things, had their day at this point. Even Web site search engines tend to provide global dynamic results as you type.

(I still dream that one of the ‘filter’ options will be – in v15? – a cross-project search, perhaps only of the active project’s contents dynamically, and of other projects’ via static indicies, whether open or closed)

Sadly that is a bit of a dream. Scrivener would have to know where each project you’ve created is located, and given its architecture that isn’t possible, just as Word doesn’t know where all of your .docx files are, and Paint doesn’t know where all of your JPG files are. You’re thinking more of a system like Evernote or Onenote, where one does not have the liberty to organise their work using the file system, and must dwell within some arcane container. It has its advantages—such as universal search features, but on the other hand you can’t very easily send your Evernote database to a colleague via email, or archive successive copies of the database to portable drives that you keep stored in the local bank vault for backups.

[dbc183c7]

Thank you Ioa for your quick replies Labor Day.

(I'll focus on the Find/Project Search-string drop-list specific conversation in a later post to this thread, keyword “droplist” with an 'x' appended.)

If on the other hand you simply mean getting the cursor into the search field, try Ctrl-G, S (press G and then S in sequence).

Thanks. I’ve actually swapped that keystroke chord with F5 . (Old habits; F5 triggers a similar search tool in Info Select, my ‘Scrivener’ for the past two+ decades.)

you may not type in enough initially and have to perform a second search. This tends to result in overcorrecting

I understand, hence “for me”. In my case of searching 100s MB of text for serendipitous philosophies however, I intentionally run many (at the moment, 20+) concurrent efforts, several beyond the 'Collection' stage. Because of this, in at least the first 2/3s of their development, more than one to several could, do, have the same statements in them. I’m more likely to be searching a project for STRINGS, e.g. “contradiction of using drones on domestic americans”, than I am for singleton or a couple of words ("drones").
(The 'contradictions of drone use' is an example of a singular case easily referenced in essays otherwise having unrelated legal, military, linguistic, et al. foci.)

“Not type in enough” is not a string-search problem I usually have.

You’re thinking more of a system like Evernote or Onenote

Actually, I was thinking of Nota Bene with its capacity to search a great number of large documents quickly (in a proprietary format), mostly because it uses static indices. (Which can get slowly out of date if not updated. But then, signal phrases are not the text that is often changed.)
I was thinking of a (complex ) hybrid search of active-project and static indices. But I honestly do understand, hence the 'dream' for 'v15'.

Again, Thanks for this quick response. (As noted, I'll come back later about the drop-lists etc.)

[dbc183c7]

Ioa,

(This post focuses on the FIND and PROJECT SEARCH string drop-lists etc. (Keyword: “droplistx”); responses to our other thoughts were made earlier.)

In the PROJECT SEARCH box, a key-accessible drop-list of prior search strings would be nice. Likewise for Ctrl-F.

For Ctrl-F I can get there just fine with Shift-Tab (from the original Find field). All of the UI elements for me are selectable with the keyboard using (Shift)-Tab to rotate through them …

What I was thinking — Ah I see whither you went with my description! — I wasn't thinking about 'prior' in the sense of 'Previous' search hits in the document for a single FIND operation. What I was thinking was the case of an action path like:
I search for, say, “ctrl”,
then I search for “project”,
then for “better”,
then … .

Each of these, looking for 'ctrl', then looking for 'project', then ... Each of these is a separate FIND search action.

Then, if I wanted to do another FIND search for “project”, it would be of use to me were there a keystroke activated and accessible drop-list (are such things called ‘comboboxes’, ‘listboxes’) containing:
ctrl
project
better
… .
It would be a list down which I could ‘arrow’ to select “project” *, which selection would put “project” back in the search text box so I could either
search again for “project” by hitting/clicking … ENTER,
or edit it to search for “projects” or “projected”. (For examples.)

*Or, pie in the sky, it would be a list from which I would select “project” merely by typing (in this case) a ‘p’! (Because no other prior string in the droplist begins with ‘p’.)

Of course, the longer the search string, the more of use, even useful, such a function would be. For example, searching for “All of the UI elements for me are selectable with the keyboard” would certainly be easier than if I had to retype it.

As for the first part of that though, (is that) different than your first bullet point(?)

If I’ve done a better job now of explaining ‘prior search string drop list’ …
#1 was about getting to and selecting PROJECT SEARCH options via keystroke. (As you say, the UI elements of FIND are already key-accessible.)
However, ‘the first part’ (of bullet/dash #3?) is not about options, but rather about search strings, ‘words’. My intent was that both the PROJECT SEARCH text box and the FIND text box would have a drop-list of prior search strings.

Hmm, once the menu is open, some accelerators so that you can tap a key to select options would be nice, just like in the main menus. I’ll see about that.

THAT is the ‘right’ response for the first bullet! — AFTER we ‘get to’, open, the magnifying glass via keystroke!

And … once a filter option for a table search is selected for the PROJECT SEARCH (EG, Labels), it would be nice were there a table-value drop-list…

I need clarification on what you are referring to by “table-values” or “table search”.

Re where you said above, “tap a key to select options …”:
My thought is that when (for example) the PROJECT SEARCH ‘Label’ option is tapped, a list of currently defined labels would be droplisted from the text box, key-accessible (arrow?), similar to the prior-input-droplist I was also thinking about for the SEARCH/FIND text boxes, noted above -- and the sky-pie).

My use of “table-values” and “table search” came from my thinking that perhaps the label names (values) might be loaded in a table somewhere in RAM to facilitate their being found more quickly.

Emending my earlier obscurity that you quoted:
“And as a variation of the prior-search-string drop-list (now clarified ) above, once a particular PROJECT SEARCH option is selected (for, say, Labels), it would be nice were a list dropped from the text box showing the already defined Labels, from which a particular label could be chosen for PROJECT SEARCH to seek.”

This table-value/search bullet is about interactively responding to the PROJECT SEARCH option-selection by providing an option-appropriate droplist of established values when an option-selection is made. ( Does that help?)

Thank you for your quick response.
I must expose a bit of honesty here. I am (mostly) resisting wanting Literature&Latte to convert Scrivener to Info Select's (Infoselect) way of doing things. So my Tech and Wish posts to-date actually pretty much exhausts the stack of observations and thoughts that I intended to pass on from among the differences I found between my past ‘Scrivener’ (a.k.a., Info Select) & my present and future Scrivener.
I look forward to the lessons I’ll learn from Scrivener’s flexibility and ‘ecosystem’ about writing and perhaps about my way of doing it.

I may be retired from ‘gainful’ employment,
But I certainly am not (brain-)dead; am willing and pretty much still able to exercise both hemispheres.

Again: Thank you.

PS: An observation about something we touched on earlier:
When I begin typing a search string (a word or more) in the search box of my 2010 version of Outlook, as is the fashion Outlook starts its search of the 900+ MB of my current and deleted emails immediately, before I finish the input. (Which search also takes ‘quite a while’.)
However, Outlook does allow me to continue my input, does not freeze my typing, and the search results do conform to my full string. (Though it likely does restart its search with each new keystroke or word! )

[AmberV]

All right, so a search history, you mean? If so, of course this isn’t an uncommon thing, thanks for the clarification. It might be possible to add elements to that panel in the future, and if so that kind of feature would make sense to me. I’ve certainly made use of search string histories whenever I have them available to me in other programs. I’ve made note of it for future consideration.

As for the same in the project search area, I’m not sure if you meant to make that suggestion there as well, but it might be more awkward since these higher level “item” search types have that aforementioned integrated option menu. I suppose you could mix recent strings with it, but with so many options it’s a bit awkward. Where I’ve seen that done, the search options are in the realm of three average, if there are any options at all.

Regarding accessibility of specific labels and such in searching. Yes, that’s definitely something we’ve given some thought to over the years. I’ll add your idea to the pile we have on that.

However, Outlook does allow me to continue my input, does not freeze my typing, and the search results do conform to my full string.

So you mean to say your objection to dynamic search is more in the mechanical flaws of the current implementation, rather than the idea as a principle? I can see what you mean there, in that case. We’re switching to a more modern programming framework for the next release. It’s quite the overhaul, but it could mean improvements in areas like this. I can’t promise it will keep up with Microsoft Outlook’s team however.

Thanks again for the feedback.

[dbc183c7]

Yikes,

All done! (At least, all that I wanted to communicate for this thread. )
Thank you.

Except for an afterthought (a fit of L’esprit d'escalier) :
I don't want to change people's MO, habits, so I mention this with my usual caveat -- For me, a Scrivener newbie with sometimes different habits and way of thought construction ... . Thinking of the filtering options available in PROJECT SEARCH: Perhaps at least two of my 'wishes' for keystroke access to its options might be invoked right there in the text input box, 'automatically' -- "Exact Phrase" and "All Words". ('Assuming' the All/Title/Text/... extent is what 'I' want; which display in the textbox I do, BTW, appreciate.)
My (after)thought is that when the text string is to be handled as an Exact Phrase search, it could be preceded by a double prime (aka, double quote); when as an All Words search, not. (Of course, this too might be in the reworking done, being done, to come.)

thanks again for sticking with 'it', me, on these.
(No reply necessary !)