Well, I ended up ditching the "Import Word Document" method just because it was too hard to work with, the HTML anyway. So, I started from scratch and it's working out better, minus the amount of time it is taking. I'm still curious if I could have managed with the import method instead of starting over like I did?
1 person found this helpful
Sorry for slow reply, I missed this because of a forum hiccough.
Does it make sense to "reengineer" the help to fit the web?
Yes. Print is linear. Web, as I think you realise, is follow the route you need.
Besides that issue, it needs to be setup so context sensitive help works.
Another reason for doing the same thing.
If the current format will work where it basically looks like a word document online, I have the issue of setting up the CSH. To properly accomplish CSH, do I have to create a topic for each item to be mapped?
If you use URLs to call the help, you can include a bookmark so you don't necessarily have to create separate topics. Also it depends what level you want your CSH to go to. For one product, we historically have one topic for every field and now it is a massive beast requiring lots of resources to feed it. For other apps, we put the fields in a table in one topic. It works just as well for users and the field help is in with the screen help which they also like. The developers know that in screen X, all calls to the help just go to topic X
When you import from Word, you can break the document based on styles. That might help break your document up better.
Hope that helps.
See www.grainge.org for RoboHelp and Authoring tips
Okay, that's what I figured. With the assistance of the conditional build, I think I'll be able to get what I want. Thank you for your insight.