Nice of you to provide the steps needed in the event someone needs them.
I'm curious, however, about what led you to the decision to abandon your topic glossary and opt instead for the RoboHelp supplied glossary?
When I facilitate a RoboHelp class, I usually mention that one also has the option of a Topic glossary as well as describing the limitations of the RoboHelp glossary. For example, using just the GLO file, you aren't able to insert images and provide links that point to additional content.
Hi Rick. We haven't committed to switching, but we're evaluating it. We have several hundred terms, and manually copying/pasting those from a topic to the GLO pod would probably be sufficient to nix such a move. So this was a proof-of-concept exercise to see if/to what extent I could automate the switch. As to why we're considering the switch, here are several factors:
- Broken JS: Our current single-topic glossary uses a custom JS file + topic to deliver 26 static letter jump-links (A, B, C, etc.) at the top of the topic; it was developed for us by a contractor nearly 15 years ago. It worked great while we were publishing CHM help, but we're moving to Responsive/HMTL5 output and it doesn't work there. I haven't dug into how to repair it, or what else we could replace it with while maintaining the single-topic enviro because.... (see next point)
- Glossary Hotspot: I demo'd the hotspot feature in a smaller project and our users thought it was really slick. By delivering a term's definition in the topic, users don't have to "leave" the topic to go look it up. I do have concerns about running the wizard against a project with several thousand topics (manually choosing which "term" instances to apply it to/which to skip vs. crossing our fingers, holding our breath, and auto-applying to all instances and the likelihood that a term or phrase in a topic shouldn't receive the hotspot); not to mention the fact that we'll have to run the wizard every time we update the project (term, definition, or topic).
- Output Integration/Accessibility: We like the way the glossary integrates with the responsive layout in RH2017 (always accessible, accessible similar to the other standard functions, etc.).
- Less Content:
- Content Development: We're transitioning from waterfall to Agile. With a bigger focus on providing core/basic content, we're trying to be more concise and less explicit in our content. This means less content.
- Output Display: As we transition from CHM to responsive/mobile-based output, screen real estate carries a bigger premium; so we're content to exclude images from definitions.
Obviously, many things to consider! We haven't made a decision, so if you have any additional thoughts on one vs. the other, please share!
<?xml version="1.0" encoding="utf-8"?>