Oxygen WebHelp-based site for an enterprise's entire set of products?

[Graham Hannington]

Suppose that:

• I have several dozen software products
• The product (user) documentation is in DITA
• The documentation authors use Oxygen XML Author
• I want to publish the documentation for all of these products—in fact, for the multiple supported versions of all products—on a single website

For an example of what I'm talking about, see IBM Knowledge Center:

http://www.ibm.com/support/knowledgecenter/

I want to treat each combination of product and version (down to the granularity of major.minor version)—for example, Product A 1.1.x and Product A 1.2.x—as a unit of deployment; a "content plugin". (A content plugin might include one or more pre-built PDF files that correspond to the HTML-format topics. The HTML topics might contain links to those pre-built PDF files for download.)

Publishing a new content plugin, updating a content plugin, or removing a content plugin should not affect the availability of other content plugins.

I want a more integrated solution than simply publishing separate WebHelp "sites" for each product/version combination, and then having a parent site as the single point of entry to those (sub-)sites. For example, if I want to change the body text font family for all content plugins, I want to edit only a single CSS rule.

I want a single entry point for each product, and then for the user to select their product version, or just go to the latest version of the product (with a corresponding "latest" URL that always goes to the latest version, whatever that might be). Perhaps even, while browsing a topic, switch to the same topic for a different version.

I have many more detailed requirements, but that will do for now. In a nutshell, my requirement is this: I want WebHelp for multiple versions of multiple products, where I can manage (publish, update, remove) each product/version documentation set separately.

Is this within the scope of future Oxygen WebHelp features?

Suggestions welcome.

[Radu]

Hi Graham,

We have plans to approach such portal-like functionality in a future WebHelp release, we have an internal issue registered for this but we have not yet analyzed what it would take.
But there are other companies like "Fluid Topics", "Zoomin", "Oberon Technologies" which can generate HTML-based documentation from DITA and integrate that in some kind of portal. So in a way that's the beauty of using a standard, you may find other companies which can create such portals from DITA content.

Regards,
Radu

[Graham Hannington]

We have plans to approach such portal-like functionality in a future WebHelp release

Any update on this? No worries if not, but I'm curious.

[ionela]

Hi,

Unfortunately, this feature is not scheduled to be implemented in the short term.

Regards,
Ionela

[Graham Hannington]

Understood, thanks. In the meantime, how about an Oxygen blog post demonstrating how to create a search page that searches the indexes of multiple instances of Oxygen WebHelp Responsive? Such a multi-WebHelp search would be one of the key components of a multi-product documentation portal. That, combined with a simple "product index" page (or index of WebHelp instances), could be the basis of a portal.

[Costin]

Hi,

Yes, we have this logged and I've added your comment to it.

We will let you know when this functionality will become available.

Regards,
Costin

[Graham Hannington]

Thanks! In the meantime, for any other users interested in this, and with apologies if this is stating the obvious, "one WebHelp instance per product version"—that is, all of the "publications" ("books") for a product, at a particular version, in a single WebHelp instance—might be the way to go, so that users can easily search across all docs for a product, at that version. This is where "search scope" would be useful.

[jdupont]

I face a similar challenge here.
I try to publish a huge set of DITA content to webhelp.
I have one main map which refers to about 100 submaps and about 25000 topics.
If I generate webhelp output from the main ditamap the process takes hours and generate a huge webhelp package (about 6GB).
I noticed that each html files from webhelp includes the full table of content which is big (about 200kb) so the TOC takes about 5GB in this publication.
I decided to minimize the amount of generated html files by using "chunk to-content" on my submaps which minimize the package size but impacts the build time. On my recent dev laptop it takes about 10 hours.
If I generate a webhelp package per submap then the global process is faster but I loose to important features:
- we don't have a global search
- we can't use the contextid mecanism as we don't know in what webhelp package our context (resourceid) is located

It would be great to have a kind of global index html page with unified search and contextid feature.