Oxygen XML Forum

Could you briefly please let us know of any improvements and additions to DITA Webhelp in the upcoming 14.2, and beyond?

I think Webhelp output is a real asset in the oXygen products, as it positions oXygen as a real end-to-end solution. I hope that it can continue to be developed.

I'd really like to see some kind of facet-based browsing possible, i.e. clickable facets that display content differently.

For example, if content could be chosen and displayed according to specialised profiling attributes from subject scheme maps, it would make Webhelp output very powerful. It would almost be a replacement for a content management system.

I'd be interested to hear your throughts on this.

Thanks

John

Hello,

John_Tait wrote:Could you briefly please let us know of any improvements and additions to DITA Webhelp in the upcoming 14.2, and beyond?

Version 14.2 will not bring new features or important visual improvements. It will fix some bugs that were present in version 14.1, for example: fixing some broken links in the breadcrumb in the page header that were generated in some cases, preserve BOM marker correctly when copying JavaScript files in the Webhelp output directory, handle copy-to attribute correctly, added a small button Expand All/Collapse All in Contents panel, reduce the scope of the email notifications for the default settings of a new user registered for the feedback system, etc.

One important addition for a future version will implement a Webhelp version for mobile devices. What new Webhelp features would you like to have in the future versions?

John_Tait wrote:I'd really like to see some kind of facet-based browsing possible, i.e. clickable facets that display content differently.

For example, if content could be chosen and displayed according to specialised profiling attributes from subject scheme maps, it would make Webhelp output very powerful. It would almost be a replacement for a content management system.

Do you mean a switch in the Webhelp output for choosing on the fly between different output profiles that were set in the XML input sources with different values of a profiling attribute, for example the DITA attributes audience, platform, product, etc.? Wouldn't that clutter the output by mixing output for different audiences in the same set of Webhelp pages? I think usually the profiles are generated and displayed one at a time for only one type of audience: the Novice Users profile of a user manual is generated and displayed/deployed at one location/URL on a Web server, the Advanced/Expert Users at a different location on the server, etc. Can you please give an example of how you see these facets working in the output Webhelp pages and a short description of their audience?


Thank you,
Sorin

Thanks for your prompt reply.

I don't work in computer documentation (or use DITA at work at all). What I'm thinking about is a simple general case that could be applied to any kind of online content.

Please see a toy database on my website (which I use for self-teaching about DITA): http://www.johntait.org/#sec-12

(The sec numbers will change over time so it's not a permalink, unfortunately.)

I've created a toy TV database, and invented three different attributes that are applicable to the TV show, to describe it:

doctor: for lead character and the main actors
story: for different types of story, and story elements
era: for the producer of the show (because the show is broadly characterised by its producer at the time)

I can populate the attributes with values from subject scheme maps. Because subject scheme maps are taxonomies, the values aren't just in a list, but a hierarchy.

This means that there are many, many ways I could filter the information using DITAVAL files. For example, I could display a single producer (from the era attribute), or I could display all the sixties stories, because the producers are also grouped under decade. This would filter results containing more than one producer.

Another example: I can display all the stories with episodes that missing in the archive or, because I can break it down further with a taxonomy, display only the stories that are completely lost (no surviving episodes), or stories with at least one missing episodes and at least one surviving edisode.

So I have lots of imformation to play with. The problem is that I have to guess what a potential reader might be interested in each time, filter that, than go back and filter every possible combination to get all the possibilities out.

In my toy example I have linked some sample rendering alternatives together with a menu (the outer limits of my technical skill).

I'd love webhelp to generate some clickable buttons that could allow a reader to select attributes chosen from the subject scheme, and for webhelp to display the results dynamically or chosen from a very large number of pre-rendered possibilities.

Does this sound possible?

Thanks

John

(PS A mobile webhelp will be excellent. I've tried the current webhelp on an iPad - I think a native webhelp would be neater.)

Hello,

I looked at your database application example and it sounds more like a database front-end application than a set of interlinked HTML pages. I think the Webhelp is more like a client-side set of HTML pages with some primary features like hierarchical grouping (the Content panel) and linking (the breadcrumb links, the Related Topic links, the regular HTML hyperlinks implemented as <a> elements), while your example looks more like a Web front-end for a database, where a database would be appropriate for holding the actual data on the server and for performing the queries necessary for the different combinations of switches.

The Oxygen Webhelp does not have a database back-end which executes queries requested by the client. For example the searches executed in the Search tab of the Webhelp output are executed in the client (Web browser), not in a database stored on the server. In case of a large application I think it would not be feasible to store all the data (the possible values of the switches and the data that match a switch value) in the client and execute the query corresponding to a combination of switches in the client.


Regards,
Sorin

Okay, thanks.

I still think that some kind of dynamic rendering would be very useful, especially for technical authors like me who aren't equipped to develop databases, but I do get the point that a client-server model is more appropriate for handling queries.

Many thanks and good luck for XMLPrague 2013.

Hi,
Sorin wrote:

Do you mean a switch in the Webhelp output for choosing on the fly between different output profiles that were set in the XML input sources with different values of a profiling attribute, for example the DITA attributes audience, platform, product, etc.? Wouldn't that clutter the output by mixing output for different audiences in the same set of Webhelp pages?

I believe that what John wants is facetted search (at least, that's what I want). This does not clutter anything if done right. In the search pane, allow the user to search for something, and then dynamically reduce the amount of hits to whatever facets the user picks. This does not require a database, but some fancy javascript.
This is the intended use case and argument for subjectScheme.
It would be really nice if the Oxygen webhelp output could support this!

Hi,

DeNelo wrote:I believe that what John wants is facetted search (at least, that's what I want). This does not clutter anything if done right. In the search pane, allow the user to search for something, and then dynamically reduce the amount of hits to whatever facets the user picks. This does not require a database, but some fancy javascript.

Once the values of the attributes defined by the subject scheme are passed through to the output of a DITA transformation, yes, I agree that it would only be a matter of some JavaScript code to make use of the attribute values. Unfortunately that is not available yet in any DITA transformation.

DeNelo wrote:I believe that what John wants is facetted search (at least, that's what I want). This does not clutter anything if done right. In the search pane, allow the user ...

This is the intended use case and argument for subjectScheme.

Maybe the general intended use case for a subject scheme is more like filtering the DITA topic content based on an attribute, like allowing a classification or grouping of content based on some defined set of values for an attribute, and marking that content with the values of the attribute for filtering purposes? This would apply generally to the aggregated content of a DITA map, not just to a list of search results in a search panel.

This is not available yet in any DITA transformation, however the DITA-OT 2.0 has something like that implemented for passing the subjectScheme attribute through to the output of the DITA transformation. We will include DITA-OT 2.0 in a future Oxygen version. How should the subjectScheme attribute values be presented in the webpage: as a combo box, as a tabbed panel with one distinct tab per attribute value?