For the last few weeks, I’ve had a chance to play with the beta of oXygen 17, which has just been released by publisher SyncRO Soft. In keeping with my previous post, I’m going to focus on how the software is evolving. However, since there are a good 80 new features in this release, I can’t avoid doing a bit of feature listing
My previous look at oXygen 14.2 also served as a general product review. Since then, this top class XML Editor has continued to evolve toward the non-specialist user in two ways. It makes XML editing easier for people who don’t know anything about XML and don’t want or need to, and it also provides easier access to the XML structure for those who do.
Not only that, this new release goes a long way toward making the job of developers who want to customize oXygen much easier, while retaining the features that make it popular with geeks and specialists.
The programmers in Craiova (Romania) seem to have been liberated by the release of CSS 3, and they’ve prettied up Author view like crazy! Features related to this include:
- A new Styles dropdown in the (newly) configurable toolbar provides a number of out-of-the-box rendering choices in Author view. These styles can be modified by adding different toggled display options, for a total of over 2000 rendering possibilities.
- If you’re interested in PDF output, you can use the same CSS used in the display to produce your output, making it real WYSIWYG, at least for that format.
- You can now control the style of tag displays at CSS level.
- The Styles dropdown includes options to show inline hints and actions for DITA and some other XML models.
- A new CSS inspector is available with a simple right click, that provides quick access to the CSS rules applied to the current element. If you want to change the display of the element in Author view, a single click takes you to the right context in the CSS editor.
- A Presentation Mode allows you to use oXygen as a power-point like presentation tool, where the display can be modified using all the above features.
While much of this represents the ability to create clear views that suit an author’s personal needs, I have some reservations about the use of the “styles” dropdown in its current form. The whole idea of XML is to separate semantic structure from display. Prettying up the display puts us back into a word-processing frame of mind, and crossing the editing interface with (PDF) output goes all the way back to the old model.
When we are writing single sourced, topic based material, there is no “preferred” output format. We have no idea of the context or display attributes the final product(s) will have. As authors, we need to think only of content and how best to communicate it. Looking at a themed display, even if we know it has nothing to do with final production, deceives our brain into thinking this is what people will see.
As Mark Baker has often pointed out, this means getting away from any notion of WYSIWYG and thinking about display in the UI as a way to facilitate our view of the structure. I’ve called it WYSIWYN – What You See Is What You Need. To date, I’ve not seen such a display in any XML authoring software.
The problem, of course, is that for a programmer, it’s so obvious – you look at the tags. I’m one of those who likes full tag displays in Authoring view, for that matter. But not everyone is comfortable with that, and we’re still very far from a true WYSIWYN display.
That said, the flexibility provided in oXygen 17 to edit or create the CSS used in the Author view (and even to switch between several of them) provides the opportunity to create views and layouts for reviewers, SME’s and other non-specialist authors, and even for technical authors who don’t like dealing with tags, elements, and attributes. Your attribute values can be in pick lists, you can toggle inline attributes with a single click, right in your topic, instead of going to a separate panel, and you have a level of guidance that goes well beyond the usual list of allowed next elements. All of this renders authoring in XML, and especially in DITA, accessible to more people, and provides many new doorways with lower barriers into the world of structured authoring.
API Documentation in DITA
API documentation is becoming more and more important. It’s definitely a growth area in our profession. oXygen 17 has some features to facilitate API documentation that are, for me, the most important thing to note in this new release.
You can use a custom URL to bring a Java class into your project as a generic, read-only, DITA 〈topic〉. You don’t include this topic in your published output, but you use it as a source of 〈conref〉 calls, to show the source code for a method, for example.
The advantage of this is that when the Java class changes, the DITA topic that references it is automatically updated. At the same time, its ID will change, so the 〈conref〉 actually breaks. This is useful, as it serves as notification to the documentation author that the source has changed, and s/he can then confirm if other modifications are needed.
The same kind of roundtrip can be performed with other types of files, such as excel, markdown, CSG, other types of XML, and many others.
Given that XML is XML, this is an excellent way for oXygen to differentiate itself from other XML text editors, and it meets a real need in our community.
Guided XML Authoring – Automating the Hard Stuff
A good editor lets you forget about fiddling with it, and just get down to writing. oXygen, of course, is a lot more than an authoring tool. It’s a full fledged suite of tools that includes an editor and a complete IDE for development of all the behind-the-scenes stuff that you need in order to publish XML to multiple outputs (XSL transforms, Stylesheets, Schema languages, publishing engines…).
As a result, it can be easy to get distracted, because oXygen out of the box gives you a lot to fiddle with. But if you have one good geek on your team, oXygen also provides lots of tools to automate all the fiddly stuff, so you, the author, don’t have to worry about it. And this release makes it even easier for the geek to do it, with simplified development tools galore.
Besides the custom forms based options that have been around since 14.1, oXygen 17 takes a giant step forward in the realm of Guided XML Authoring. The first level of this is found in the inline hints and actions that you can call up from the Styles dropdown. Hints shows you style guide information about how to use the various elements in your topic. Actions effectively reveals the entire content model, showing at each point, the elements that are available to you. The Actions are controlled by a dynamic information model in Schematron. They are sensitive to position, and to changes you make in your topic. These features are available in DITA and other XML models.
Complementary to Hints and Actions are Quick Fixes. These already existed for some models in oXygen 16, but now they are extended to RelaxNG and Schematron based models. Quick Fixes go beyond error trapping and validation. If, despite everything, you enter invalid or incomplete elements or attributes, the Quick Fix not only alerts you to that fact, it proposes one or more solutions, much like a spell checker, that you can select from a list. If your selection requires a follow-up action, Quick Fix will also propose that.
Refactoring has gotten a lot easier, too. A new XML refactoring tool built around XQuery lets you do global search and replace operations in a safe mode that preserves attribute order, DOCTYPE declarations, and other essential parts of your model that XQuery doesn’t know anything about. Global refactoring can be done on a folder or even an entire project. Our geek friends can easily define custom working sets for us, to define a specific scope for search. A preview mode shows comparisons before you commit. This is a feature I’ve often longed to have, and I’ll bet many of you, too, will be avid users of it. SyncRO Soft promises to extend this to XSLT processing in one of its next releases.
oXygen 17 can also find orphaned resources that are no longer used in a project – a function normally reserved for a CCMS.
A Few More Treats
There’s a lot more in this release, but I’ll just highlight a few that seem important to me:
- You can output context sensitive WebHelp to an iFrame (HTML 5)
- This release supports a number of new DITA 1.3 features, including the new Troubleshooting topic, though it does not yet support DITA 1.3 publishing features. I’ve been told this will be in an incremental release as soon as the standard is finalized.
- There’s a new version of the web app that is desktop computer friendly, reuses the same actions as in the standalone application, including hover actions. It is fully adaptive for mobile devices.
- As far as I know, oXygen continues to be the only major XML editor that runs on MAC OS, and this release is compatible with Retina displays (including purpose-built icons).
- A number of user interface customizations have been added, including configurable tool bars, and increased display support for DITA.
- Other improvements in DITA support include responsive page displays in Author mode, and improvements in DITA validation.
This is an amazingly rich release of a product that was already amazingly rich. We users love the abundance of really useful features, but there is a danger here. It is already impossible for any one person to be aware of all oXygen can do. Not just an ordinary person, even its creators have admitted that they don’t know all it can do. We don’t necessarily need to know all – but we do need to know that it can do what we need it to, and the big question is, how do we find out?
The product is a success. The combination of certain features provides a powerful environment to facilitate the authoring process. For example, the guided XML Authoring tools, coupled with the CSS inspector and Styles dropdown possibilities can provide a series of highly specialized workflows and automated environments for different kinds of authors with different needs. I don’t know of any other editing tool that goes this far in that direction.
To stay successful, oXygen must be careful not to cross the line from feature acquisition to feature bloat. So far, oXygen’s brain trust has managed to walk the line, and keep the product filled with useful stuff. A word to the wise: beware of the saturation point!
It’s also important to keep purpose in mind. My earlier comments about prettying up the UI speak to that.
- Why do we do structured writing?
- Why is it topic based?
- What can an editor do to support that?
- What shouldn’t it do, so as not to distract from that?
These are questions that developers, in general, don’t ask – but a product manager should ask them, and guide the development such that its evolution continues to build on the strengths that have made it such a great product.
My Wish List
It’s not very long:
- For some of the great customizable stuff, provide a few more out-of-the-box solutions that are very generalizable – most people will use these, and never customize.
- oXygen does a lot of XML formats, including some that are not specific to the technical documentation space, but it doesn’t do S1000D, which is vital to some sectors in our world.
- I wish that oXygen will keep developing as it has, that it will evolve toward greater ease of use, toward simplification of a complex environment, and that it will avoid the pitfalls mentioned above.
Update 18 May 2015: I have been informed that the concerns about simplifying the UI are part of the oXygen road map, and that version 17’s default toolbar actually has fewer buttons on it than the default toolbar in oXygen 16. This is a welcome trend.
Please see my post on my approach to software tools. I have free access to this software, and a friendly relationship with its publishers.
I do not currently use any professional editing software on a daily basis, so my opinions are not based on that kind of use, but rather on my knowledge of the product when I did use it on a daily basis, and how it has evolved since.
I reserve the right to an independent opinion, and that is what I’ve written here.