Hi Richard,
Yes, we're already working on responsive WebHelp skins and this is scheduled to be released with Help & Manual 7 in the spring, or possibly a little later. They will work automatically on desktop, tablet and phone browsers and they will be really, really fast. Current testing shows topics loading in between 15 and 80 milliseconds, including initialization, as compared to up to a second or more for complex topics a the moment. In addition to this the
index.html?topic.htm syntax will be a thing of the past. Instead, the URL for each topic including the entire user interface will always be just
topic.htm and nothing more. In addition to this you will also be able to embed WebHelp in an existing page with a single snippet of code, similar to the embed code for a YouTube video.
I'm still getting to grips with Responsive Web issues, but it seems like replacing the iframe would be a good start. I guess I don't like this anyway as I'm not sure if search engine spiders can navigate it properly?
There is a tiny bit of truth in this. This is obscured by a huge dead weight of incorrect myths and knee-jerk prejudices about frames (more specifically iFrames, which are the only valid version now).
In fact, iFrames are not a problem at all for search engines if you do them right, and Help & Manual does. Not only that, they are actually essential for some aspects of WebHelp. Bear with me for a moment, that will become clearer shortly.
The actual topic pages that get loaded into the topic iFrame in the main index.html page are normal HTML pages that exist in the same WebHelp folder as everything else. Search engines spider these pages directly when they are stored like this, so they always get indexed. Their results then link to the individual topic pages, i.e. to
topic.htm instead of to
index.html?topic.htm. In the past, Help & Manual WebHelp used to automatically reload the topic in the full user interface when it was opened like that. However, the Google algorithm was changed over the last couple of years and now incorrectly identifies reloads like this as "duplicate content" and then excludes the pages from the index. So now, instead of doing the automatic reload, a topic page opened on its own offers a highlighted link at the top with which the user can reload with the full user interface if necessary. This is a stopgap solution, but it works very well and Google indexing proceeds normally.
The reason you need iFrames in WebHelp is because you need to have a huge (
really huge) amount of data in a single page, and you need to replace parts of that page dynamically without reloading the entire page when the user browses in the help. In addition to the current topic you are looking at you have a table of contents, which can have thousands of entries, a keyword index, also with thousands of entries, a search page that can also load a huge list of results, and possibly also other dynamic components.
Theoretically you could use modern AJAX commands to load all these components into a single page, replacing the contents of the container tags with the contents of the pages you are loading. The problem is, if you load all the components of WebHelp into a single page like this you get a really, really huge page that goes far beyond what browsers are willing to cache and this comes with unacceptable performance problems.
The solution is a hybrid structure: In the future the topic content is going to be reloaded in the main page with AJAX calls integrated with the HTML 5 history API, which is fast and efficient and makes it possible to have the simple URLs, and the main pages will always be the topic pages that are indexed directly by search engines. The table of contents, keyword index and search pages are going to continue to be loaded into iFrames. This keeps them in separate pages (an iFrame is really like a separate browser tab displayed in a location in the current page), so they don't overload the WebHelp page. They don't need to be indexed by search engines anyway, and having them in iFrames also means that they can load asynchronously (all at the same time), significantly speeding up the initial load time of WebHelp. In addition to this, all three of these components will be in separate iFrames, which means that switching between them will be instant.
) reasons, I've tended to ignored mobile browsers, but now the time is right to make my commercial sites mobile-friendly and responsive...