This content has been marked as final. Show 5 replies
I guess it depends on whether development want to pick up the cost from their budget. :-)
I maintain a number of help systems and one is a merged webhelp setup comprising over 12,000 topics precisely because it has a file for every field. For our new products I persuaded my management it was a nonsense maintaining that. I produce a topic describing a function, sometimes several topics, but somewhere in the page(s) for the function will a table or tables listing the fields. The developers map all the fields to the appropriate page and the user then has to locate the field in that table.
The users are happy with that as they can see several fields at a time plus some general stuff.
End result is a much more compact system that everyone is happy with including, most importantly, the users.
Thanks for getting back to me so quickly. I was hoping that someone would say that. So, essentially, you create a topic for a function (NOT a screen), then create a table within the topic listing the related fields and what they're used for, what they can do with them, etc? That sounds like a better plan, and I'm pretty sure I can sell them on it. I think if I also explain that development will be responsible for matching up topics to fields and MAINTAINING it (creating their own matrix, spending extra time and money), they might reconsider.
Yeah, lay it on with a trowel just how high maintenance and boring it will be for them. Works a treat.
If I am understanding this correctly, I think a good workaround is to create a limited number of topics but let the developers go ahead and create a map number to every field. You can assign multiple map numbers to the same topic.. It might make for a long .ali file but it will be a manageable project. Depending on your development environment, it might be easier for the developers to generate a map ID for each field. We use visual C++ and it automatically assigns map IDs to bits of the window frame. We just direct all of these to a single topic.
Here's a nice, convincing argument that I just thought of - the only thing wrong with it is that I don't know if it's true or not.
Does the end user's browser cache the .htm files for the help topics that are grabbed from the server? If so, consolidating the field definitions lessens the server traffic.
(Always get the server guys on your side - everywhere I've worked, they wield a big stick!)
Also, I'm a big believer in functional help topics, but I have compromised for some clients and included one-per-screen conditional topics with the field labels. John, I wish I had known about the map numbering trick back then - I would have loved to give them F1 help.