This content has been marked as final. Show 9 replies
Xenu is terrific; I've been using it for almost three years, now. Just point it at your main start page, and let 'er rip!
I save the results into an .html file, then open that file in Notepad to strip the irrelevant stuff. You might find it duplicating the occasional result because of case differences. I also get links not found to external web sites to be erroneous.
Between this product, FAR, and ExamDiff Pro, I can't imagine maintaining our 40-project, 2.5K-topic merged WebHelp without them (maintaining two concurrent major versions). Especially now that I've incorporated Zoom search as well. As to FAR and Zoom, their original designers often are the ones to answer your requests for assistance. Although I haven't had to contact the other two, I wouldn't be surprised if their responses were similar.
You've also got the built-in checker for internal links, Tools > Report > Broken links.
Thanks, Leon. That sounds like a ringing endorsement to me! I think I'll look into Xenu. I'm also intrigued by your comment about incorporating Zoom Search, as we're looking at it as well. Did you incorporate it directly into your help project, or are you using it as more of a development tool? Any further insight in that area would be appreciated, too.
msiano, thanks for the reminder about broken links. We do indeed use the broken links list.
If your topics begin with an H1 title heading that matches the topic's html title (in the head section), you need to wrap it inside ZOOMSTOP/ZOOMRESTART Zoom tags. Otherwise, the "Meta description" would include that repeated title at the start of the first few lines of topic content. We also needed to wrap, in the same manner, a right-aligned DIV for InThisTopic and RelatedTopics links (a sort of "topic site map"), as well as "Return to Top" and mailto "Feedback on this topic" links at the bottom of each topic.
However, RH completely ignores those Zoom tags in the generation process (it just leaves them behind). Adding these to the output after each generate/publish, in a 40-project merged WebHelp product, would have simply been impossible.
Our solution here is to run Zoom agaainst the source files, instead. Options abound, such as Zoom delivering its output files to a different directory (the output file directory). I have to run some FAR batch files aginst the zoom_pageinfo.js file to:
1. Do some lowercase stuff (which our release Engineers already do to all the htm files with some Perl scripting)
2. Change all path names from /projects to /mergedProjects (obviously unnecessary if you don't have a merged project).
3. Remove the additional space that Zoom mysteriosly adds before punctuation (commas, periods, etc.), which they've said should be taken care of in a future build.
Great product, especially when used in concert with the ones I mentioned previously! Managing a help output of this size and complexity (all the while trying to cater to management's evolving wish list of help features) would be impossible without my "best friends."
I'll happily endorse what Leon has said about ZoomSearch. There's a tutorial on my site but note I implemented ZoomSearch in a different way to Leon. I first encountered it based on a recommendation here and implemented it working with the output files. My logic being that they contained the words to be searched for whereas the source might contain additional wording excluded from the output by a build expression.
If I recall correctly, Leon started to use ZoomSearch when I said what a great tool it was and his own tests made him a convert. However, he needed to use ZoomSearch in a different way to meet his needs.
Between my topic and Leon's posts here, you should be able to decide what works for you. If you do need to contact ZoomSearch, do mention hearing about the product on this forum. The more RH users they know are using their product, the greater their incentive to make changes that suit us, as I know they did for Leon.
Wow, that's terrific info, you guys! I see I am going to have to do a little homework on how well our headings match up with what Zoom wants.
Leon, you mentioned your large merged webhelp project with beaucoup component projects. Do you ever deliver different configurations of that project to your clients? What I'm trying to get at is how one would configure ZoomSearch to manage a configurable set of help projects, rather than an unchanging monolithic set. For example, Client 1 has help projects A, B, and C installed, while Client 2 has help projects A, C, and D installed. The same Zoom Search index would not be appropriate to both client installations. Have you managed to surmount this problem as well? (Sorry - perhaps this ought to be posted separately.)
Thanks again Peter and Leon. I sure appreciate the feedback from the trenches. And if I get the chance, I'll certainly mention to ZoomSearch where I got the recommendation.
One thing you can do with ZoomSearch is have the Search button you create call a topic with a number of buttons that access a filtered search. So Buttons 1 is Search in Product A, another button is Search in Product B and so on.
You then tag those buttons to suit a particular build.
Doesn't address the problem of the all help search across a configurable set of projects. Not sure how you could do that without multiple searches being created. Any ideas Leon?
No, G, we only deliver the entire help system; the consensus here is that the help modules for portions of the app that the customer didn't buy will serve as free advertising.
To expand on Peter's last post, I think you'd probably need to think about how you could get your developers to create some privileging controls and/or create separate Zoom indexing passes for multiple project configurations, which would then be placed into separate folders. You and your developers could then set up some simple alias files that would call the Zoom results from the appropriate folder.
If you could get that worked out, the same format could be expanded to encompass any number of future combinations. The downside is that you and your folks need to put in some design time to get this working in an easily maintainable structure that will suit your needs.