Standalone Help Page Usage/Suggestion/Request

[sizbut]

Having started using HMv7 in earnest, I demonstrated to my developer colleagues the various options they could incorporate our PPv3 skinned help directly into our products own web pages; i.e. field popups, topic popups, embedded help.

However, their request is to be able to have a method for a help link for a particular page to be able to display that page in an iframe without any of the additional help navigation components. That is, no navigation pane, no previous/next topic icons, no breadcrumb trail. Yet, at the same time, still be able to call it as a standard full help system when required.

Experimenting with one of the non-PP skins, I've been able to do exactly that (using some extra javascript that triggers off the presence of ?toc=0 in the URL called and sets the style of the various help navigation components to 'none').

The developers are happy with that as an option, but I'm not as it means that users of the full help lose the other very nice usability features of the responsive PP skin. However, attempting do the customize the PP responsive skin behaviour has (no surprisingly) defeated me. I can get the page to almost appear as required, but the responsive elements in your own scripts re-position the page text if the window is resized, and even if I get that conquered, passing in a variable to trigger my customer script has eluded me also.

Now the begging part: In an ideal word, it would be great to have a script similar to 'hmEmbeddedPopups.js' that can be passed the target help page name and a target (traditional frame name, iframe name, new window) into which it should insert the resultant standalone page. i.e. very much like the topic level popup but placing the HTML into a frame rather than pop-up window.

[Tim Green]

Hi Sizbut,

Since this is a Premium Pack request I've moved it to the PP forum.

That's an interesting request and it's the first time this has come up. When I set up the system for embedded topics the assumption was that it would be a lot more flexible if it didn't interfere with the host page at all, and so far nobody else has asked for an option like this.

I will look into this but at the moment I can't promise anything. Making changes like this always involves a huge amount of work because of the necessary testing on multiple platforms and unexpected side-effects, which always occur, and I'm not sure that I can justify that at this juncture.

[sizbut]

Fully understood and appreciated Tim.

I've looked at some of the PP scripts and immediately backed away as their contents show what we pay ECSoftware for, ie. detailed knowledge of the behaviour of different browsers, platforms, etc.

I've presented what I can do with the non-PP skin to the developers and can handle picking up other variables to use within the non-PP help also. As long I can agree with them on what projects they want to link to as standalone pages, if its only one or two then I can live with those looking and behaving differently from the others. In fact depending on size we may be able to publish PP and non-PP versions to keep them and myself happy.

As ever thanks for all your help.

[Martin Wynne]

Hi,

In the H&M HTML Export Options you can choose the extension for the topic files -- htm, html, php.

This means that you can have duplicate topics of the same name in your output folder, one as say .htm and the other as say .html.

You could therefore run the publishing task twice into the same output folder, firstly without a skin using say .htm extensions, and secondly using a responsive skin as say .html.

Then calling a topic as .htm in an iframe gives you whatever you have set up for it in the page template (no navigation etc., if not wanted). Your page template will be ignored by the skin version.

And calling the topic as .html would open it in the full responsive help system.

I haven't actually tried this, but it is the sort of "Meccano" approach to H&M which I am fond of.

cheers,

Martin.

[sizbut]

Martin,

An interesting idea but I think I will avoid trying that. The non-PP skin uses a flat-folder output so you would have all its baggage, images, scripts, etc in the same folder as the PP skin's html files. I couldn't help but be constantly concerned about some unplanned or unintended interaction lurking there even if initial testing showed it worked okay. Maybe I'm OCD but it doesn't appeal to the tidy part of my mind.

Also, by having the non-PP output in a separate folder, I can exclude that folder from the user support web sites overall search function. So user searches will only find the version of help they are meant to use but development can still make direct calls to the special standalone pages version of the help. And I've already added links to the template of the standalone pages so that users can click a 'more help' option that launches the full PP flavour help for them in a separate browser tab.

The batch publishing mechanism of HMv7 makes having two outputs trivial so the only issue is the increased disk space for two parallel help variants - but at the moment its just one help project being treated that way so an acceptable cost (when we translate it into 16 languages peoples opinions may change a bit but that's the price for wanting special behaviours and having the support text that appears inline in their web based application's config pages provided/maintained and translated by the documentation team).

[Tim Green]

An interesting idea but I think I will avoid trying that. The non-PP skin uses a flat-folder output so you would have all its baggage, images, scripts, etc in the same folder as the PP skin's html files. I couldn't help but be constantly concerned about some unplanned or unintended interaction lurking there even if initial testing showed it worked okay. Maybe I'm OCD but it doesn't appeal to the tidy part of my mind.

You're absolutely right there. I would never recommend putting two WebHelp collections in a single folder. In addition to the possibility of conflicts, remember that the search index is generated from the files in the output folder. If you have another collection there the index will contain both, and if you have two different formats you will get a mess (and the search index files will probably overwrite each other too).

Putting the files in a separate folder is the only way to go. There is also no "duplicate content penalty" on Google, in case someone says you should worry about that. That is a myth that Google has tried often to debunk. Info here.