Problems with searching in Web help (premium pack)

[bruno.stivicevic]

Hi,

the users of our Webhelp documentation, built with the Premium Pack 2.42, complain more and more about search problems, both in Index and full-text.

For the purpose of this report, let's assume you have the topic that explains about Windows Error Reporting (WER). The WER word is in the title. Moreover, the WER is indexed as the first-level keyword.

Capture.JPG

1/ Index searching problem
You search for WER and it starts to search from the beginning of the index, in entire text of the index, therefore finding a lot of hits that **contain** "WER" or "wer", e.g. viewer, newer etc.

capture2.JPG

In this case, I need to re-click the Search Keywords button more than 80 times to find the first level keyword WER. (It is not needed to say that in CHM index, WER is found as the first hit. I understand that here we have two different technologies, but, independently of the technology, a keyword search should be the keyword search and not a full-text search in a smaller subset of words).

If I click W first, to jump on the section that contains keywords with W, then I have to click the button about five times. Of course, it depends on the keyword I'm looking for.

The users find all this quite frustrating.

Although the possibility to search also the second level keywords may be considered as a feature, the missing choice of "where to search?" is a killing problem. Therefore, my questions are: how can I make the keyword index be searched only on the first level? If that's not possible, how can I make it be searched only for "whole word"?

2/ Full-text searching problem
When I search for WER in full-text, without using any wildcard, I get 76 pages of results, and again, it is a great pain to find the topic that regards Windows Error Reporting. Questions: why WER query works as it would be followed or preceded by a wildcard *, e.g. why it behaves as *wer* ? If the wildcard * is turned on by default, what's the purpose to have it in the first place? How can I force it to search for exact match?

Capture1.JPG

Thank you for your prompt answers.
Regards
Bruno

[Tim Green]

Hi Bruno,

You can't change the way keyword index searching works at the moment, sorry about that. We'll think about it for a future release. It would probably make sense to search only from the beginning of the keyword and not also for occurrences inside the entire string.

On the full-text search problem: If you enclose your search term in double quotes ("WER") it will only search for entire words. However, if you have so many instances of WER in your project that is not something that the

[bruno.stivicevic]

Thanks Tim. Is the keyword search in JS or similar? On the full-text side: I have just one WER instance in my project, the fact is that the full-text search by default searches for *WER* without making it clear and then finds all words containing wer (and wer is very frequent in English). Can you explain me how the asterisk is to be used in the full-text search?

BTW, I suggest you to amend the label on the full-text search screen to mention the double quotes for the full-text search exact match, I'll do it on my copy of the skin...

Regards
Bruno

[Tim Green]

Hi Bruno,

Yes, the keyword search is a JS routine, that's the only way to do it. The * and ? wildcards work in the standard way -- * stands for any number of characters, ? for a single character.

[bruno.stivicevic]

Thanks Tim. Regarding full-text it looks like I didn't explain it well.

When searching full-text for WER on the Web pages built by the Premium Pack, it behaves as I would type (asterisk)WER(asterisk) as it finds the token in any position of any word.

In that context, I don't see any use of the asterisk operator itself, as it behaves as I inserted it (but I didn't): therefore, the default label that mentions its use is simply wrong.

In other words, one would expect, when searching on Web, created by H&M that:
- the query WER (therefore, without any asterisk) finds only WER or wer, but not were or newer (that's how it works in the CHM full-text or on Google).
- the query wer* (therefore, followed by an asterisk) finds WER, wer, were etc., but not newer (and that's how it works in the CHM full-text search).
- the query *wer (therefore, preceded by an asterisk) finds WER, wer, newer etc., but not were (and that's how it works in the CHM full-text search).

The double quotes are typically used for the exact phrase, and not for the single word.

I reckon it doesn't work as expected above, and I just wanted to stress that it is appears to be a sort of a square wheel - different than the behavior of similar searches in other software, and creating problems and confusion for users that switch between CHM and WEB platform - with drawbacks on the Web platform side.

I hope this issue will be addressed soon and made closer to the standards.

Regards
Bruno

[Tim Green]

Hi Bruno,

This has nothing to do with the Premium Pack skins. Search in Help & Manual WebHelp has always worked like this, it is the way the Zoom search component works, particularly when you are using the JavaScript search platform. Entering search arguments without quotes is effectively like entering *searchargument*. Entering them with quotes is like entering "argumentA AND argumentB AND argumentC" or "argumentA OR argumentB OR argumentC", depending on whether the user selects the "all words" option or not. You only get exact phrase searches in double quotes with the PHP or ASP platforms, which should always be used for larger projects anyway (the JS platform can only handle small projects efficiently).

The wildcard characters can be used to replace parts of words.

[bruno.stivicevic]

Thanks Tim, for this clarifications.

[Tim Green]

Hi Bruno,

Update: Version 2.5 coming out soon will only search for keywords from the beginning of the keyword and will also have an "Instant search" checkbox that will be on by default. The keywords will then scroll down to the first instance as you type and pressing ENTER will scroll further to the next instances.

In addition to this, 2.5 will include a major new feature called "timed browser cache" that will ensure that your users always see your latest updated content instantly, without needing to reload the website or clear their browser cache. Topics that they re-visit during their current session WILL be loaded from cache, however, so this will not have a negative impact on browsing performance or bandwidth. This feature will be available in the WebHelp skins, smartphone skins and iPad skin, but not in the 1.x classic skins.

[bruno.stivicevic]

ok that great! Will get it as soon as it is ready!

Thanks again
Bruno