A few questions on search keywords...

[kdeuler]

Hi all. I'd be grateful for experts' comments on these questions:

1. Is there a way an end-user (a reader of the WebHelp) can specify keywords in the search query (something perhaps like "kwd:installation"), such that only topics with the keyword "installation" are returned?
2. Is there a way to search across all topics that have NO keyword (eg, "kwd:"")?
3. Is there a way to configure RH such that when an author creates a new topic, a default keyword, or set of keywords, is added automatically to the search Keyword field for the topic?

Thanks in advance

-Kurt

[Willam_van_Weelden]

As far as I know, 3 x no. But perhaps I've overlooked something.

Kind regards,

Willam

[Peter Grainge]

Are you talking about keywords where the term is not in the topic? If so, then patently the user cannot define those as they would have to find the topic to link it to the keyword and if they have found the topic, why would they want to create a keyword?. However, if you can guess the words they might use to search on, then Synonyms would help. Perhaps we are not understanding what you have in mind.

Isn't searching across topics without keywords just a plain search? Perhaps you have something else in mind.

The nearest would be to create a draft topic and tag it out of any build. Then in Project Manager, you could click on that file and select Duplicate.

---

See www.grainge.org for RoboHelp and Authoring tips

@petergrainge

[Captiv8r]

Hi Kurt

Hopefully my colleagues Willam and Peter won't mind my offering a bit of a different take here...

You asked:

Is there a way an end-user (a reader of the WebHelp) can specify keywords in the search query (something perhaps like "kwd:installation"), such that only topics with the keyword "installation" are returned?

There is this really cool feature that RoboHelp offers. Basically, this feature allows you to anticipate and define the keywords you think users may choose to use when looking for information. Essentially, the way it works is this. You define the keyword, then you choose to associate topics of interest with the keyword. After you generate the help and make it available to the end user community, when they are looking for the information, they begin typing the keyword they are looking for and BOOM! Automagickally, the output sets about wildly trying to match existing keywords to what they are typing. It's quite amazing really. For example, perhaps they are looking for "installation". As they type the I and the N and the S, the list of keywords scrolls and adapts. Quite often, the user sees the keyword they want before fully typing it out. They click and see all the topics associated with this keyword. Oh, the name of this feature is the "Index".

You also asked:

Is there a way to search across all topics that have NO keyword (eg, "kwd:"")?

That would be known as the typical "Search" RoboHelp offers.

And lastly you asked:

Is there a way to configure RH such that when an author creates a new topic, a default keyword, or set of keywords, is added automatically to the search Keyword field for the topic?

My esteemed colleague Peter answered that quite well. If you are wanting the topic keywords field completed.

But there is a similar approach you might consider. That approach would involve creating a Master Page. You would then add the keywords you want to the Body area of the Master Page. Then when you create topics that use the Master Page, whatever is in the body text of the Master Page is copied to the new topic and is searchable.

Cheers... Rick

[Peter Grainge]

@Rick No problem with any suggestion but ultimately the Index is still not user configurable.

---

See www.grainge.org for RoboHelp and Authoring tips

@petergrainge

[kdeuler]

All- Thanks for your thoughtful comments. Some good ideas here.

I should step back and describe the general problem I'm trying to solve...

I'm creating WebHelp for my company's software products. There is a main product, and several "module" products, each with their own versioning! Customers can potentially have different combinations of product versions. For example:

• Customer One might have main_product_v_10, sub_product_A_v_2.3, and sub_product_B_v_1.0, whereas...
• Customer Two might have main_product_v_10.1, sub_product_A_v_2.2, and sub_product_B_v_1.1.

Some topics (like installation, release notes, etc.) are very product+version dependent. Others (the majority) don't really change over time, and would apply to all customers' set of products.

One requirement is that all topics are potentially available one search interface. However, another requirement is that customers should to be able to perform searches in such a way that topics that are NOT relevant to them are excluded from search hits. For example, if customer Two searches for 'installation sub_product_A', I don't want them to have to look at hits for installation instructions for each version.

To help customers exclude irrelevant version-specific topics from their searches, I thought I would add abbreviated keywords to the product/version-specific topics, and then provide search instructions in their use. For example, to ensure that customers find instructions that just apply to sub_product B_v_1.1, they could do a search for, say "spB1.1". Then all topics that include spB1.1 as a keyword would be returned. I'd also like customers to be able to search across all topics that 1) Apply only to their software set 2) Apply to all customers (non-product/version specific) and 3) does NOT apply (only) to product/versions that the customer doesn't own. (Point #3 relates to my interest in a default keyword, such as "common". Rick's last idea using master pages looks interesting.)

Use case: Customer Two wants to search for the string "customization" in all topics that apply to his/her set of software. The search would be therefor be something like: customization AND ("main10.1" "subA2.2" "subB1.1" common)

Thanks again!

-Kurt

[Jeff_Coatsworth]

If you offer up all flavours of choices to everybody, maybe something like DUCC would work?

[kdeuler]

If by DUCC you mean use of Content Categories, yes, I'd thought about this. 2 fatal flaws with this option:

1. WebHelp Pro doesn't support them yet. (The Pro output is required for RH Server, which we'll likely implement.)
2. DUCC wouldn't be able to (practically) handle every possible set of product/versions that a customer might have.

My ideal search interface is one that presents customers with checkboxes. I'm chatting with WrenSoft about this approach:

Select your Main_product_Ver:

o      all

*      12.1

o      12.0

o      11.3

o      11.2

o      11.1

o      10.1

o      10.0

Select your version of SubProduct_A version:

*      (not purchased)

o      2.3

o      2.2

o      2.1

o      2.0

Select your version of SubProduct_B version:

*      (not purchased)

o      1.3

o      1.2

o      1.1

o      1.0

[Jeff_Coatsworth]

So would you allow a construction like “main_product_ver: 12.0” AND “Subproduct_A: 2.2” AND “Subproduct_B: 1.1” or some different logical operators? Many of us are very interested in how you think this sort of selectable search parameters thing would function.

[Peter Grainge]

I'm thinking merged help is the answer here. See my site for how it works.

I'm thinking you would generate for the main product and all versions of the modules into one merge, then you would supply any given client just the bits they require. The search and index would then be specific to their setup.

---

See www.grainge.org for RoboHelp and Authoring tips

@petergrainge

[Jeff_Coatsworth]

@Peter – but it sounded like the OP wants to give all clients access to all flavours of their products

[Peter Grainge]

@Jeff I was working on the basis "they know not what they ask".

---

See www.grainge.org for RoboHelp and Authoring tips

@petergrainge

[kdeuler]

@peter I'm intrigued by your comment:

I'm thinking you would generate for the main product and all versions of the modules into one merge, then you would supply any given client just the bits they require. The search and index would then be specific to their setup.

I understand the first bit, up to the comma. But I don't understand how to make a different set of material available to each customer. How can search and index be unique to their setup?

(And I've have been reading up on your fine merged help instructions. I'll be testing it shortly. At the moment, merged help seems like primarily a doc-source-organization technique, rather than a user benefit. Plz correct me if I'm wrong.)

Thx.

[Peter Grainge]

You supply the parent to all customers but only the relevant children.

Generate all three in my demo and view to see all three children. Then

delete one of the children from the output. Still works but with only those

two.

[kdeuler]

Hmmm. I'll keep this in mind as I continue testing. RH Server might also offer some access rights tricks. Main idea is to keep the manual customer-specific presentation effort to a minimum.

Thx.

-kt

[kdeuler]

@Jeff I described my interest in a multi-attribute selection form to Support at WrenSoft (the ZoomSearch people). David (Wren) replied:

There is a categories function that should work. You'll need to check the box to allow searching in multiple categories. You'll end up with check box per category on the search form.

There is also the custom meta fields feature, but I don't think you'll need to go that far.

See, http://www.wrensoft.com/zoom/support/tutorial_custom_meta_fields.html

Note in particular the sample search form near the bottom of that page:

This is something like what I had in mind. I'll be testing ZoomSearch on RH Server-delivered content.

Thx.

-Kurt