Pesky navigation pane inconsistencies

[Guest]

Hello. I have gone back through the forum and been able to find out most of the answers to my navigation pane issues for WebHelp.

For TOC font, I have edited whtdhtml.htm; for TOC spacing, I have edited whthost.js; for Search, I have edited whfbody.htm; for Index I have edited whibody.htm, and for the pane width, I have edited whskin_frmset01.htm.

And while that has made the pane much better, there are still a few anomalies I can't quite reconcile. For each of the three tabs (TOC, Index, and Search) I am using the same font style and size (currently Times New Roman 14).

The three remaining issues are:

• The TOC tab defaults to open without it being left justified, thus cutting off the book image. I have moved the page (with the question mark) image to the right, but I can't seem to get the main book image to move and/or get the tab to open with it scrolled all the way to the left so that it is not cutting off the book image.
• There is still some inconsistent spacing between entries/results on these three tabs. Changing the space between TOC items was easy enough (changing the var gsMargin value), but I'm not sure of an Index and Search equivalents.
• The settings in the whfbody.htm file are the same as the other two tab settings: setFont("Normal","Times New Roman","14pt","Black","Normal","Bold","none"), yet the search results do not appear bold.

Hopefully, the following illustration shows these three issues a little more clearly.

With our new application primarily set for screens, tablets, etc., I need to really be aware of TOC, index, and search entry sizes and spacing. So, if anyone has any ideas on further refining the far left TOC book placement, the spacing between results across tabs, and the lack of bold font on the Search tab, I'd really appreciate it.

Thanks,

Kevin

[Jeff_Coatsworth]

Have you ever played with the new Multi-Screen HTML5 layouts? They're the ones that are the fit for screens, tablets, phones, etc., not plain old WebHelp, IIRC...

[Guest]

Thanks, Jeff. Yes, I set up a project to use with one of our apps, but the company decided not to use it because of the limitation of the look and feel. I probably should have said that the new help will often be used on a touchscreen display moreso than a tablet. Sorry.

[Willam_van_Weelden · Accepted solution]

Hi,

Getting fine grained control requires you to modify the files whfhost.js (Search), whghost.js (Index) and whthost.js (TOC). Each file contains a function that writes the CSS and you have to modify the CSS in the JavaScript files. Follow the links for in-depth information about those files.

And I agree with Jeff: If you are supporting tablets or other touch enabled devices, WebHelp is not a good choice. It is not optimized for touch and the frames used in WebHelp may not work consitently on all devices. Give your managers a try on an iPad and see how they react 😉

Greet,

Willam

[Guest]

Willam, thanks for the help. I will use those .js files to edit the settings I was unable to change previously. I will just need to remember to save a copied of the modified files elsewhere and replace them after I compile the help or else the new settings would be overwritten.

I just spoke with our product manager, and he believes the next version of this particular product will be used the way it primarily has in the past - at a station that has a touch screen display. He doesn't believe iPads are in the mix just yet. I did use Multiscreen HTML 5 a while back for our app going on the Apple store, and it worked OK but because of layout and style limitations, higher ups decided not to use my help project (just my content), and they had Dev and Graphics do the coloring and GUi to match the look and feel of the app itself.

Thanks again for all of the help and suggestions.

Kevin