What to do when the app has multiple windows open?

[Guest]

Hi, I have another Webhelp question.

How do I provide the proper screen help if there are multiple viewing panes open within a window? (Not sure if I'm wording this right.)

The application I am currently working on is in an asp environment. The end user, who accesses the app via IE 6, can select HELP FOR THIS SCREEN from a drop down menu. (There is a separate menu option for SYSTEM HELP.)

However, at any given time in the application, a user has the option of splitting the main work window into several panes, or viewing/work areas, each with its own screen. This allows the user to multi-task. But in these instances, when the user asks for help, I'm not sure which screen he/she wants help for.

The only help I've created until now is single-topic window-level help--one window, one screen, one help topic.

I'd be happy to try setting it up such that the user could place the cursor in the viewing pane where he/she needs help. But so far I haven't found the info on how to do that.

I'd be grateful to anyone who can give me some tips on how to approach this. Many thanks!

[Codestone]

Hi,

If you have one topic that covers all elements of each split screen then just pop up the same topic for any split screen that currently has the focus.

HTH

MikeL

[Guest]

Hi, Mike,

The thing is, I wrote a topic for each inividual screen, which is what I'm used to. There is no "master" topic that can be used to cover all screens (of which there are over 100 for the application I've been assigned).

One help screen/topic would work fine, if the user were only allowed one screen at at time. But I'm being asked to accommodate a situation where there are multiple, unrelated screens displayed in one window, and there is only one help button on the menu bar at the top.

If the screens were related, it might make a difference, in that the help option could open a "master" topic that would in turn offer the user a logical menu of topics from which to choose. Alas, this is not the case.

So, the only solutions I can see are:

(1) Request that the programmers go back and add a HELP button to each individual screen. The user will click the help button for the screen he/she wants help for. As for the help button on the menu bar at the top of the application, that would be reserved for System-wide help only, having a TOC and keyword search capability. Don't know how happy the development team will be with that suggestion. Not that I think it would be hard to do, but with about 1000 screens spanning numerous applications, it's still work.

(2) Forget about asking them to add a Help button to each individual screen. Just don't offer context-sensitive help. Instead, set up the help button on the menu bar for System-wide help only, providing an introduction, TOC, and keyword search capability. (Something along the lines of what you get when you're working in Robohelp X5 and you click Help.) It's not as user friendly, but it would be better than nothing.

(3) Offer field-level help. But the problem with that (other than the fact that I've never done it before, but how hard could it be to figure out?) is that I don't have lots of time for this project and there are many elements on each screen. I see that as being unacceptably time consuming.

And can you even do field-level help in Webhelp?

Lori

[MergeThis]

Your developers will have to do the heavy lifting on this one.

Context-sensitive help, whether at the form level or field level, requires a partnership between you and them as to naming issues. However, whether all windows provide help when focused but only when not detached, etc., is strictly up to them and their efforts.

The RH help has plenty of info for you and the developers under, surprisingly enough, the Context-sensitive Help folder.


Good luck,
Leon