Can you elaborate with perhaps a screen shot what you mean when you say: I have "pcap" and "pcaps" in the search keyword list for the "PCAP Files" page
<meta name="search-keywords" content="pcap, PCAP, pcapng, ..." />
That is correct: I provided the HTML rendition of the field.
Exclude this topic from Search has never been enabled.
So as I wait for a response, perhaps it will help to advise what my own understanding is of how the search ranking works.
Assume you have 100 topics in a project. Three of those topics mention RedRabbit somewhere in the text. If you searched, you should find the three topics. Likely the topic that would be listed first would be based on the way the Topic Title was named. Perhaps something like this:
A house in the woods
Some farm in the country
Now, if you added a few paragraphs to the Westward ho! topic where RedRabbit was mentioned a few more times, it should then be listed first, because it had the largest number of instances where RedRabbit occurred.
But say you added a topic called "General Store". And in that General Store topic, you had a heading level that mentioned RedRabbit. Perhaps in a Heading Two the text read: Selections of RedRabbit. Because that text is a heading level, it should cause the General Store topic to be listed first because a Heading level is more priority than basic text.
And if you added a topic where the Topic Title contained RedRabbit, then it would gain first place because Topic Title would have more importance than heading levels.
Hope this helps a bit... Rick
So it's ranking the pages according to how many times "pcap" appears in the body?
Does the number of "pcap" occurrences in the body outweigh the presence of "pcap" in all these other places?
If that's the case,
- The help files need to be altered to reflect this reality.
- I need to put "pcap" in the body of that page about a dozen times but hide them under a conditional tag?
Unfortunately, I've never read anything official from Adobe on this. What I'm sharing in this thread is simply what I've personally learned by simple experimentation.
So if no topics have pcap and one does, of course it should be the only one found.
If pcap appears 1,000 times in the body text of one topic but appears only ONE time in another topic but it's in a heading, that topic will be listed first.
And what seems to trump all is the existence of the term in a Topic Title. There may be small variations that could occur as "tie breakers". For example, say two topics had a heading with the term in it, I might expect the topic with more occurrences to be given more weight. Or if two topics have the term in a heading but one is a heading 2 while the other is a heading 1, then I would expect the topic with a Heading 1 mention to be given more weight. But I'm not certain about this. Just a hunch on my part.
Listing something but hiding via conditional tag would defeat the purpose as that text would not be present after generation.
So the little Search Keyword field helps in some cases, but isn't the end all solution.
The results that I pixellated out do not contain "pcap" in the title except for the 4th entry in the list, which ideally should show up in the top 3 results.
The other topics contain "pcap" to a much lesser degree than "PCAP Files" and do not contain "pcap" in their TOC or Title.
So it sounds like the Rh ranking algorithm is not very good and hasn't been improved at least since Rh10.
This is the topic page in the help files: Adobe RoboHelp (2015 release)
Exclude unreferenced topics from search
The Exclude Unreferenced Topics From Output option in layout properties ensures that search results are displayed only from topics that are referenced in the following project components:
•CSH map IDs
•See Also keywords
•Related Topics keywords
My output is Multiscreen HTML5, which provides the options to Exclude Unreferenced Topics from Output and Exclude Unreferenced Baggage Files from Search. I've selected both options.
Apparently to no avail.
Thanks anyway for your input.
Note that what I mentioned was results for WebHelp output. While one might expect the results for Multiscreen HTML 5 to be the same, I'm not certain they will be.
Out of curiosity, why multiscreen and not Responsive? Responsive is vastly more simplified than Multiscreen.
- I just barely upgraded to Rh2015, less than 2 weeks ago. IIRC, Rh10 did not offer Responsive.
- When I selected Multiscreen HTML5, about 4 years ago, it was because Top Brass thought it would be cool to offer the Help Files over mobile devices such as tablets and smartphones. (That Top Brass has since moved on to other companies.)
- It turns out that our users typically don't access the help files with mobile devices (I asked), so there has been no user demand for me to define other screens besides Desktop.
- Maybe I'll switch to Responsive, but my current workload doesn't permit that for the next few months.
Just being silly here. But your current workload prevents you from double-clicking the Responsive layout? I mean, it really is that simple.
I tried that.
It comes up with Not My Formatting.
It's not really that simple.
LOL - “Not My Formatting” – what’s that??
Isn’t it just a matter of slapping on a nice looking skin & applying some CSS lipstick?
"Not My Formatting" is what it says: formatting that is not mine.
Which, my formatting is six flavors of awesome, not a pig on which to smear some cheap lipstick.
I'm a prefessional [sic].
Excellent! You only need to employ an HTML5 programmer to tweak your skin for your six flavours of awesome formatting then ;>)
LOL on the lipstick...
I just found out via a MadWorld report (yes, I know) that 72% of customers check out the support site (meaning Help Files) before buying, and that help files are viewed as more honest than marketing.
A nice-looking skin isn't enough. I gotta have First-Class Branding going on.
Which, I do.
This has gone off topic re the search issue and there's not enough information about the formatting for anyone to help see if there is a simple solution. Is it that you have styled the multiscreen layouts and don't have the time to do the same in responsive, understood, or is it to do with fonts being wrong or similar? That might be a simpler fix.
See www.grainge.org for RoboHelp and Authoring information
I'm struggling to understand the need to use Responsive at all. My users are on workstations, not mobile devices.
At some point I will have to port my material to MadCap Flare, because that's what the rest of the company uses (I came in with an acquisition). I'm not interested in Responsive.
In addition to everything that has been said so far, as you struggle to understand the "NEED" for responsive, it may well boil down to simple perceptions.
Yours would certainly NOT be the first case we have ever seen where some knucklehead makes a decision on something like this for the simple reason that it "looks cool" or that they fear "looking dated" and they really want to "be hip". So the choice may have been as simple as that.