XML Blog

Saturday, November 15, 2014

Alternate sales pitch

Share to Facebook Share to Twitter Email This Share on Google Plus Share on Tumblr

This year was my first participation at Tekom Europe, we had lots of discussions with interested potential customers and one of them asked me to give him my sales pitch of why he should buy my product instead of a competitor's one. I'm not a salesman. I've always wanted to work for a product which is so good that it sells itself. And I do.

So here's my alternate sales pitch:

Ideally whenever you choose between any two software products which will be used daily by people in your company you should make a pilot test project with two user groups made of the people who will be actually using the product after it is bought. Ask them to use the product for a month performing tasks similar to what they will do after the purchase. Ask the two user groups at some point to switch products and see how that goes. And in the end let most of the decision to be made by these people who will actually be using the product in their work.

Working for an extended period of time with the product will also show how stable the product is, if it crashes often, if it has small annoying bugs and if it sometimes behaves unpredictable.

We are a productivity application and in my opinion the goals of such a type of application would be these ones:
  • shorten the amount of time users spend doing their daily tasks
  • allow users to fulfill their tasks with the least amount of frustration, let them concentrate on what should be done and not on the tool which is used in that process, be intuitive and easy to use

Look what types of operating systems are used in your company, can the tool run on all of them?

Read the product's End User License Agreement, I know it's a boring task but you might find some gems in there. For example does the user based license allow the user to install the product on multiple computers as long as he/she is the only one using it?

During the trial period ask questions on the technical support email address.
  • Are they responsive?
  • Are they helpful?
  • Do they know what they are talking about?
  • Do they go that extra mile to help you?
  • Is there a public forum available? Is it well kept, does it have a lot of activity?
  • Is there an user's list available? Register on it, see how questions are answered.

Find out how long the company which makes the product has been in business. Google the product online, read blogs and look for opinions on it.

In the end it will come down to two things: quality and price. But you need to make sure you are listening to the people who will actually use the application.

Tuesday, November 04, 2014

Public hosted Oxygen Plugin and Framework Projects

Share to Facebook Share to Twitter Email This Share on Google Plus Share on Tumblr
There are a couple of interesting Oxygen plugins and frameworks which are developed as separate public projects (and maintained either by us or by our users). I will try to compile a list below:
  1. Besides being bundled with Oxygen the TEI framework is also available as a project partly maintained by the TEI community: https://code.google.com/p/oxygen-tei/
  2. HisTEI: An Oxygen framework for historical documents encoded in TEI.
  3. Ediarium is an extension package for TEI editing within Oxygen.
  4. Framework which adds JATS/NLM support for Oxygen developed by Wendell Piez: https://github.com/wendellpiez/oXygenJATSframework
  5. Automatic builder for Oxygen frameworks which allows user to describe framework's behaviour by using only XQuery, HTML, and CSS, and automatically generate the framework archive ready to be deployed (developed by Claudius Teodorescu):http://kuberam.ro/oxygen-addon-builder/
  6. LanguageTool plugin for Oxygen: https://github.com/danielnaber/oxygen-languagetool-plugin
  7. Framework which adds Daisy support in Oxygen: https://github.com/oxygenxml/Daisy
  8. Framework which adds STRATML support to Oxygen: https://github.com/oxygenxml/stratml
If anyone else wants to add something else to the list, just drop us an email.

Wednesday, September 10, 2014

Cool Stuff to Look for in future DITA publishing

Share to Facebook Share to Twitter Email This Share on Google Plus Share on Tumblr

First of all a big thank you to all you Oxygen XML users who have been from the very beginning the driving force behind many of the improvements we have added into the application.

In my opinion of all the people who try an application for the first time only a few of them will ever bother to write to the application's producers and give feedback about things which do not properly work. Most of them probably suffer in silence and maybe end up abandoning the application alltogether. So feedback received from people using a trial license of Oxygen and who still bother to report a problem instead of giving up is quite valuable and we are grateful for it.

We have many Oxygen DITA users and this leads to many requests to improve the DITA Open Toolkit publishing. Our policy so far has been to contribute these improvement suggestions back to the DITA Open Toolkit so that they benefit others as well. Also we should all be grateful to Jarno Elovirta, the main DITA OT contributor, guru and developer who makes all of this possible for all of us.

So here are some of the DITA publishing improvements I'm looking forward to see in the future:
  1. The Oxygen team is actively working on a DITA Open Toolkit plugin which will use CSS to render PDF output from DITA content. The plugin could be used with commercial rendering engines like Prince XML and Antenna House which support obtaining PDF from XML and CSS. Initially the plugin will provide support only for the Prince XML engine This would mean that most PDF customizations which are currently being done using XSLT could instead be done via CSS styling which is far easier for users who are not experienced XSLT developers. I will present the general architecture of the plugin on the DITA OT Day in Munich this year. And if it proves to be succesfull we are willing to make this plugin available as an open source project or part of a future DITA OT distribution. Oxygen 16.1 which will be released in a few weeks will have an experimental version of the plugin included with its bundled DITA Open Toolkit.
  2. DITA Open Toolkit 2.0 will probably generate HTML 5 compatible output by default.
  3. DITA Open Toolkit 2.0 will generate the Index page for PDF output even when using the Apache FOP processor. The changes are already incorporated in the DITA OT distribution which comes with Oxygen, you can also incorportate them quite easily in your DITA OT by modifying an XSLT stylesheet: https://github.com/dita-ot/dita-ot/pull/1587.
  4. Using the DITA Open Toolkit 2.0 you will also be able to pass profiling attributes and values from the DITA content to the generated HTML content: https://github.com/dita-ot/dita-ot/issues/1739. This means that instead of profiling the content before it is published, you will be able to profile it at publishing time by using Javascript to show/hide parts of the content depending on the user role for example.
  5. Besides lots of bug fixes Jarno Elovirta made lots of memory and processor optimizations which also will be included in the next DITA Open Toolkit 2.0 release.

I'm also looking forward for the support for the DITA 1.3 specification which will slowly begin to be implemented in future DITA Open Toolkit releases.

So what are your ideas for future DITA OT publishing enhancements?

Tuesday, August 05, 2014

The Oxygen SDK (Part 2: Frameworks)

Share to Facebook Share to Twitter Email This Share on Google Plus Share on Tumblr
This is the second part of a blog post I started some time ago:

There are two ways of customizing the application, by implementing a plugin or by implementing a framework:

A framework configuration provides validation, content completion and editing support for a certain XML vocabulary. 

If you are already using Oxygen for editing DITA, Docbook, XHTML or TEI documents you may notice that Oxygen knows how to validate these vocabularies and that it can propose content completion entries while you are editing. Also when you are editing in the Author visual editing mode you have lots of custom vocabulary-specific toolbar buttons which can be used to insert links, images, to manipulate tables and so on. This happens because each Oxygen installation comes with pre-bundled framework configurations for certain XML vocabularies that we consider to be more important for our users.

Knowing how to create and modify a framework/document type association configuration will benefit you in two ways:
  1. Create your own framework which adds editing support to Oxygen for certain specific XML vocabularies and then distribute it to your team.
  2. Customize an existing framework bundled with the installation (DITA, Docbook, etc) and change certain behaviors in it.
Our user manual contains a special step by step tutorial which explains how a new framework configuration (document type association) can be created and configured:
The Oxygen Preferences->Document Type Association page lists all detected frameworks (document type associations). Usually looking inside one of the pre-configured document type associations (eg: DITA) is a good place to start exploring what such a customization contains:
  1. Association rules - when one of these rules matches the opened XML document, Oxygen will associate it with the current document type association. The rules are pretty simple to compose, they refer to a certain root name, namespace, certain attributes set on the root and so on.
  2. Schema - specifies a grammar to be used to providing validation and content completion if the opened XML document does not refer directly to any particular gramar.
  3. Classpath - a list of JAR libraries which contain Java extensions for this specific framework.
  4. Author - contains all necessary support for editing the XML in the Author visual editing mode:
    • CSS - one or more CSS files to be used when rendering the XML. If you define alternate CSSs, you will be able to switch between them when editing. The user manual contains a list of supported CSS features and additional available extensions.
    • Actions - a list of actions specific for modifying the edited content. An action has a name, description, icons and shortcut key. It also has one or more activation contexts which depending on an XPath expression enable a certain operation be be executed. A fair amount of basic operations are already available but you can create your custom operations.
    • Menu, Contextual menu and Toolbar - you can easily mount defined actions to the main document type menu, to the contextual menu or to the special Author toolbar(s).
    • Content Completion - add defined actions to the content completion window (shown when ENTER is pressed in the Author editor mode) or remove existing entries from the content completion window. You can for example replace some of the insert suggestions given by the association grammar with your own custom actions.
  5. Templates - points to folders which contain new file templates for this particular framework. These new file templates will be shown in the New wizard dialog.
  6. Catalogs contains a list of XML catalogs which will be used to indirectly solve various references (like references to schemas or other XML documents).
  7. Transformation may contains a predefined list of transformation scenarios which are available when you want to publish your opened XML document to various output formats.
  8. Validation may contain a predefined list of validation scenarios which are used to add complex multi-stage validation (with multiple engines) for the XML documents matching the document type association.
  9. Extensions - contains implementations of the available Java extensions which are used to provide further functionality for editing in the Author visual editing mode. Here's what some of the extensions do:
    • AuthorExtensionStateListener - provides a way to be notified when the XML was opened in the Author editing mode. You can then add all kinds of listeners and react to edit events done by the user. For example add a modification listener, send the edited content to an external spell checker engine and then add highlights in the content on invalid constructs.
    • AuthorExternalObjectInsertionHandler - reacts to drag and drop and copy/paste events containing with HTML content or resources. In the case of DITA for example this handler is responsible of the automatic conversion of HTML pasted from the browser to DITA content.
    • SchemaManagerFilter - filter and modify the insertion items detected from the associated grammar when editing XML content. For example even if the schema proposes certain elements as valid insertions at the caret offset, you can filter out and restrict the suggestions given by the associated schema (grammar).
    • StylesFilter - take control over the rendering styles for each node by adding this layer of Java customization over the styles provided by the associated CSSs.
    • AuthorSchemaAwareEditingHandler - handle special editing cases and provide fallbacks which keep the document in a valid state. For example if the user starts typing text between two paragraphs, the handler can automatically create a new paragraph.
You can create automated tests for your frameworks:

and even debug their functionality:

Thursday, June 26, 2014

Webinar: New in oXygen XML Editor 16 - XSLT Quick Fixes

Share to Facebook Share to Twitter Email This Share on Google Plus Share on Tumblr
This webinar presents the XSLT Quick Fixes functionality in detail and then go through some of the other important new features in the new oXygen release including:

  • new XSLT refactoring actions
  • support for developing XSLT stylesheets for Saxon CE
  • XPath execution over multiple files
  • the new Ant editor
  • and more.





Tuesday, June 10, 2014

How To Disable Caching In WebHelp Pages Created By Oxygen Application

Share to Facebook Share to Twitter Email This Share on Google Plus Share on Tumblr
Sometimes a set of WebHelp pages needs to be updated often on a company website, either an intranet site with important information shared between different departments of the same company, or a publicly exposed website. The need to always deliver the latest version to the intended audience arises in such cases, with the immediate consequence that the latest version of a WebHelp page should always be requested from the server upon re-loading that page in a Web browser on the client side, rather than re-using an outdated version cached in the browser.

This no-cache policy is implemented in a WebHelp page with the addition of the following two HTML META directives:

  <meta http-equiv="Pragma" content="no-cache" />
  <meta http-equiv="Expires" content="-1" />


These directives must be added in the file:


OXYGEN_INSTALL_DIR\frameworks\dita\DITA-OT\plugins\com.oxygenxml.webhelp\xsl\createMainFiles.xsl


in the template with the attribute name="create-toc-common-file", in the <head> element, for example:


  <html>
    <head>
      <xsl:if test="$withFrames">
          <base target="contentwin"/>
      </xsl:if>
      <meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>
      
      <!-- Disable caching of WebHelp pages in web browser. -->
      <meta http-equiv="Pragma" content="no-cache" />
      <meta http-equiv="Expires" content="-1" />
      .  .  .


After this modification in the createMainFiles.xsl file, repeating the WebHelp transformation in Oxygen will add the two META directives to the generated WebHelp pages.

Tuesday, June 03, 2014

Create a Custom Skin for Oxygen WebHelp Pages with the WebHelp Skin Builder

Share to Facebook Share to Twitter Email This Share on Google Plus Share on Tumblr
One of the new features of Oxygen 16.0 is the option of setting a skin for the WebHelp pages created by the DITA WebHelp transformation or the DocBook WebHelp transformation, in the form of a CSS stylesheet that modifies the default look of all WebHelp pages in a consistent way.

You can choose one of the six predefined skins available on the Skins tab of the DITA WebHelp transformation:

The Skins tab in the Oxygen WebHelp transformation

or you can build your own custom CSS skin visually on the Oxygen website: 

The Skin Builder in action on the Oxygen website


The WebHelp Skin Builder is a small Web app that allows you to configure many CSS properties of a large palette of elements in the header area, the content area or the Table of Contents area of a WebHelp page, like: background color, border, margin, font properties, text properties, adding a logo image in the header area, etc. The properties are grouped by type of component of a WebHelp page like: title, paragraph, list, figure, table, etc.

Once created with the WebHelp Skin Builder and set in the Oxygen WebHelp transformation as a custom CSS skin, it can really give a professional look to a set of WebHelp pages published on your company website, which has the potential to impress your users. Give it a try and let me know what you think!