Responsive webhelp question

Simon Dismore · Tue Oct 13, 2015 12:02 pm

I'm trying to implement a contents page that links to individual topics. It might be a table as below, or a vector graphic generated dynamically using run-time javascript. Either way, I have been generating it using external tools, copying it to the baggage folder, and linking from the TOC using a web link address targeting the topics frame. The table isn't as simple as it looks, each cell is built from semantic <dl><dt><dd>, supports keyboard navigation and displays extra content in the focused cell, so it wouldn't be feasible to create it using the current H&M editor. It uses % widths so behaves reasonably well using the current 7.0.5 responsive skin.

Example of table as H&M contents page.png

That approach isn't safe in the long-term, per Creating new topics in the TOC in H&M7's help, as Tim recently pointed out. So I'm wondering how to achieve something similar to what used to be possible, but in a more future-proof way.

I appreciate that I can insert the externally-generated code as an HTML code object. But that requires me to update my H&M project whenever the externally-generated code changes. Another approach is to use the external generator to produce a snippet XML file that's linked from the project. This means I can re-publish without making any changes to the project. That's the best solution I've found so far, but it forces me to generate special output and republish manually.

Is there anything I could be doing to insert the entire webpage dynamically into the topics area, as if it was an external page but without the need to wrap it in snippet xml? If not, could anything like this be available as a feature in future?

Thanks

Martin Wynne · Tue Oct 13, 2015 12:09 pm

Hi Simon,

Have you tried #MERGE to link an external HTML Code Object?

http://help.ec-software.com/index.html? ... gehtml.htm

regards,

Martin.

Martin Wynne · Tue Oct 13, 2015 12:20 pm

p.s. An alternative to #MERGE is to use an <iframe>. This embeds an entire external web page as-is, with its own styles, scripts, etc.

I have topics written as embedded Wiki pages this way. It enables users to update the Help content themselves and share easily with other users.

An iframe also allows installed EWriter content to be updated in the same way as normal Webhelp.

The disadvantage is no searching and direct links to other topics are not possible.

Martin.

Unread post by **Tim Green** » Tue Oct 13, 2015 12:38 pm

Hi Martin,

The disadvantage is no searching and direct links to other topics are not possible.

That depends: So long as the file in the iFrame is on the same domain you should be able to link to other topics from it so long as you get the target and path right. I'm not sure if this would work with EWriter calling syntax though. You can ameliorate the searching issue to a certain extent with keywords in the parent page.

Martin Wynne · Tue Oct 13, 2015 12:53 pm

Tim Green wrote:That depends: So long as the file in the iFrame is on the same domain you should be able to link to other topics from it so long as you get the target and path right. I'm not sure if this would work with EWriter calling syntax though. You can ameliorate the searching issue to a certain extent with keywords in the parent page.

Thanks Tim. I will do some experimenting.

The simple solution is to put some "see also" links above the iframe in the containing topic. Which also works in EWriter of course.

I long ago discovered that a good Index is much more useful than searching. It is extra work to create though, needing much thought.

Martin.

Simon Dismore · Tue Oct 13, 2015 1:34 pm

Martin Wynne wrote:Have you tried #MERGE ...?

No, I'd completely forgotten about it – even though it dates back to H&M4 at least – thank you very much for pointing it out so quickly. I've now tried it as a full <html></html> page using an empty template, and also as a partial using the contents of <body></body> with a <style scoped></style> (as a quick fix). Merging the partial is probably the way to go in the long term, because then it can be wrapped in json and injected anywhere.

Martin Wynne wrote:p.s. An alternative to #MERGE is to use an <iframe>....

Actually that's what I was thinking about first, but there are extra steps creating responsive content that way, using postmessage so the host can negotiate the iframe height. As you say, it has the advantage of being entirely dynamic if desired. Not sure whether I need that.

Anyway, your first answer completely solved my current concern. I owe you

Unread post by **Tim Green** » Tue Oct 13, 2015 3:46 pm

Martin,

I long ago discovered that a good Index is much more useful than searching. It is extra work to create though, needing much thought.

Zoom also includes the keywords in its search index. That's why you sometimes seem to find pages where the search terms are not directly visible in the topic content.

Help & Manual Forums

Responsive webhelp question

Responsive webhelp question

Re: Responsive webhelp question

Re: Responsive webhelp question

Re: Responsive webhelp question

Re: Responsive webhelp question

Re: Responsive webhelp question

Re: Responsive webhelp question