The Humanist Nerd Reviews oXygen 14.2

oXygen’s new release is part of the company’s policy of regularly (every three or four months) releasing “incremental” upgrades. I use quotes because Syncro Soft, the publisher of oXygen, regularly includes major new features in these free, “incremental” upgrades. This was especially the case with release 14.1 that included forms based editing of XML attributes – about which more in a moment.

In fact, the release of 14.2 is simply an excuse to review the product as a whole, something I feel I ought to do, after reviewing Adobe’s Technical Communication Suite 4 in this blog.

A Rich Package

oXygen, in fact, is not a product, but a suite of products:

• oXygen XML Author is an XML content authoring tool.
• oXygen XML Developer is an environment for editing and developing DTD, CSS, XQuery, XSLT, and a variety of schema languages.
• oXygen XML Editor packages all of these together.

It successfully and seamlessly integrates a number of tools, including validation software and rendering engines, many of them open source, to help XML authors and developers do their work. DITA publishing is done through the DITA Open Toolkit.

The developer tools include converters between different schema languages. The author tool supports Microsoft Open Office XML (OOXML) as well as the Open Document Format (ODF) used by Open Office and its descendents.

To the best of my knowledge, oXygen is the only product of its type that is totally cross-platform: Windows, Mac OS X, Linux, Solaris.

oXygen is packaged in a variety of formats: standalone desktop client, Java Web Start (thin) client, or as an Eclipse plugin.

It has connectors to software version control, and component CMS systems, as well.

Power to Spare

The list of features in oXygen, whether in the authoring package or the development package, is immense – and most of them are really useful, which is really rare. I can’t and won’t cover a long list, but will call out two recent additions that are worthy of special consideration for content developers:

• Forms based attribute editing for authors and SME’s (introduced in 14.1)
• Enhanced reviewing aids (introduced in 14.2)

WYSIWYN

The Content Wrangler Community on LinkedIn has been having a lively debate on the possible imminent death of WYSIWYG editing. Some of what has been discussed there centres around the tools an author needs to be able to do her or his work properly. Is it necessary to see how the text will be displayed? If so, and if you are single sourcing and multi-channel publishing, which channel do you need to see, and when? What information does an author really need? Does s/he need to see XML tags, or are there better ways to define structure?  etc.

oXygen’s forms tool takes us to a higher meta-level: forget seeing what you get, let’s have WYSIWYN (my coinage, probably not unique): What You See Is What You Need.

An author writing text does not care if the tag associated with the text s/he is writing is a <p> or a <context> tag. The author cares about what the function of this particular bit of text is. Why not be able to just select that from a drop-down list? Let the software decide which tag to use!

The forms tool allows you to do just that. It uses a custom CSS that lets a document architect design an authoring environment in which the writer never has to look at an XML tag, but where s/he does have to choose from available structural options, and make choices that correspond to attributes for the elements selected.

A writer who is not interested in XML will never know s/he is producing it.

In short, we are in a world of structured authoring, where the output is assembled modularly, and where we publish to many different formats with many different displays. When writing a module, what the author needs to see is not how one of those particular formats will appear, but how text is grouped, gathered, and structured, so that it makes sense, and so it fits together with other text modules.

oXygen doesn’t do this out of the box, of course, but with a minimum of knowledge about writing CSS code, and using oXygen’s extensions, you can design a forms-based master that authors can use to write their content, without thinking about XML, output formats, or anything except the sense and structure of what they are writing. This is huge, and I believe the impact of this feature will be enormous in the long run.

What does come out of the box are a number of samples that use the forms tool, so you can easily learn how it works, or even modify one of the samples to suit your situation.

Enhanced Reviewing

oXygen has long had MS Word-like change tracking – it provides colour highlighting to changed text, and inserts change bars in the XML.

With release 14.2 there is now support for multiple authors (colour coded). You can see changes as callouts or in a new reviewing panel. Comments, added text, and deleted text are grouped in a separate panel that does not clutter up the main editing workspace. This makes collaborative reviewing easier. Change notes are stored in the document as processing instructions, so they do not interfere with the actual XML.

Another addition is that you can now highlight text that you want reviewers (or your own self) to give special attention to. This highlighting, again, is stored as processing instructions, and only shows up in the authoring view.

Three Views

Authoring is one of three views provided by oXygen, it shows a generalized formatting that makes text readable to those who are not XML Geeks – not a true WYSYWIG, just enough to give you what you need, once again. As with most XML editors, you can toggle different levels of tag display.

There is also a pure XML text view, a code level view that pleases geeks and is also invaluable when you don’t understand why it’s behaving in a certain way…

The grid view gives you a hierarchical glimpse of the structural relationships of your elements as nested rectangles. This is a supplement to the usual outline and map management panels. The only other editor where I have seen this type of view is Altova’s XML Spy, which is not an editor oriented to content developers or the DITA crowd. I have often found this view to be useful.

Who Should Use It?

To me, one of the major advantages of oXygen has always been its geekiness. I’m not being facetious here – I have clients who just “get” oXygen right from the start. They understand XML from a coding perspective. They get modularity, so they understand structure and reuse quickly. They like it because they can get under the hood and tweak it. It lets them easily create scripts that automate a publishing build that becomes part of the nightly software build, all with one button-push.

Other editors also allow these things, but in oXygen it’s just so easy to get at, and oXygen does so many things.

So, I was all set to write a review saying that it was the ideal tool for people who like looking at code, inspecting tags and attributes, an editor for people who like tuning their own carburetors.

But then, there’s the forms tool – and suddenly, the world changes. Suddenly, oXygen can be for people who don’t want to know anything about XML at all. It really can be an all-purpose editing tool that fits almost any writer, including SME’s who are not document specialists.

The one caveat is that someone still has to do the tool building work, and write the CSS code that will make that possible. If you, or someone in your organization is capable of that, you’ve got all the bases covered.

So far as I know, oXygen is the only full-featured XML editor that runs on Mac OS X. So if you are working in native OS X mode, this editor is your go-to choice.

oXygen is also around half the price of other editors, and if budget is tight, you’ll appreciate that. I would not choose oXygen just for the price, but it’s a nice benefit if it’s the right fit for you. And their tech support is personalized and helpful.

Room for Improvement

There is one area where I think oXygen could do better: it depends primarily on the DITA Open Toolkit for publishing DITA content. Getting really good looking output from it requires a lot of tweaking in CSS and XSLT. Really a lot.

You can, of course, publish to other publishing engines, if you wish. If you use a component CMS, you can use it to control your publishing options, and you bypass oXygen altogether.

Still, it would be nice if, just as oXygen supports a number of Schema languages, it would support directly, out of the box, a number of publishing engines. Getting really good looking output from DITA and other XML formats remains one of the more daunting tasks for a publications department, and any tools that render this task easier are welcome.

Full Disclosure

There are a ton of features in oXygen that I have never touched or used – I’ve not had need, so far. I’ve avoided commenting on them, but in so doing I might have missed something that would be important for you – sorry.

In my review of Adobe TCS 4, I indicated that the company asked me to do the review. This was not the case with oXygen. I decided, on my own, to review the product, because I’ve been using it, and because, having opened the door to reviews on this blog, I feel it is only fair to be even-handed. Following up on that, I might review other products that come along, that are of interest to me. There are a lot of them out there, but I haven’t used them all, and I’m not a professional software reviewer.

I should say that both Adobe and Syncro Soft have provided me with complimentary software. This was not specifically for review purposes, but for other activities.

In the case of Syncro Soft, I will be volunteering on a project to integrate a DITA style guide into the DITA author editing view.

In all cases, I reserve the right to give frank, honest opinions.