Zoom Search v. 8 Help System issues

[rkg82]

The new v. 8 help system compiled as "ZoomHelp.exe" has a few issues concerning the search form, and the search instructions provided in the form.

1) The wildcards "*" and "?" do not match the space character.
Example: I want to search for all instances of "case-sensitive", entered without the quotes, and match "All search words". None of the following patterns returns any results:

case-sensitive
case?sensitive
case*sensitive

Because only "case sensitive" returns results, one concludes that there are no instances of "case-sensitive" anywhere in the help system. The same search patterns used with the match "any search words" option produces the same results.

2) The use of double quotes for explicit search strings" works, but is not documented in the form. In this case "case sensitive", including the quotes, returns two instances. The search form input box, however, strips the quotes away after providing the results. Using single quotes instead of double quotes does return results, but not the expected one, and the input box only strips the closing single quote.

3) Finally, the link "Javascript option" at the bottom of the form is broken, and returns "Status 404: File not found".

If all the described behavior is by design, then the search instructions need to be explicit about all the supported and not-supported options. I haven't checked, but I expect all the search-form templates and script strings generate search instructions with the same limitations.

Because the search pattern constraints change depending on configuration settings for language options such as stemming, and sub-string matches, the template text should be amended to suit, or at least the help system should document the appropriate instructions for acceptable patterns in each context.

[David]

Wild cards for search words have never matched a space character, or any other character that divides words.
If a word has a space in it, then it isn't a word. It is two words.

Exact phrase was never supported in the Javascript option.

Yes that Javascript link is broken and we need to fix it.

[rkg82]

Thanks for the clarification. Here is my use case:
We index URL paths and file names. Our server search logs show users typing underscores or hyphens to join presumed compound name elements in directory or file names, instead of the space characters that constitute the actual directory or file names. When they get no results with a hyphen or underscore, they attempt a pattern with the wild card, because, presumably again, a directory or file name is conceptually a single word. As you may gather, I have users with programming experience in Linux environments searching for files and directories created on Windows systems by people with no programming experience or experience with other operating systems.

[Ray]

In your case, I would suggest disabling Hyphens and Underscore characters from the "Indexing word rules" for joining words (under "Configure"->"Indexing options").

By unchecking these two options, a word such as "case-sensitive" and "case_sensitive" would be indexed as two words "case" and "sensitive". Similarly, when an end user searches for "case-sensitive" or "case_sensitive" or "case sensitive", the results would be the same.

However, it means that you would not be able to search for a specific instance of "case-sensitive" that occurs. Results matching all of the above would now be equivalent.

But with the above, there should be no need for your users to resort to wildcard characters.

Hope that clarifies.

[rkg82]

Yes, thank you for the clarification. The options you suggest would indeed reduce the number of logged failed searches, and presumably an explicit (in-quotes) search for "case-sensitive" would still work regardless of the the hyphen being disabled as a join word?

[Ray]

Yes, that is correct.