|
About a decade ago Microsoft Windows changed significantly when it moved from Windows 3.1 and 3.11 to Windows 95 and then Windows 98. In this transformation the standard Windows help format moved from WinHelp (.hlp) to HTML Help (.chm). But since then, despite the significant change in Windows when XP was developed, there has been no real change in Windows help format standards. The only real development has been in alternative help standards, where WebHelp (browser-based help), JavaHelp, MS Help 2 and other options have become available.
But whispers about a major change started to be heard a few years ago, and have been evolving, as they tend to, from whispers to rumours and eventually from rumours to announcements from Microsoft. The future, they say, will be XML-based help.
Of course, in the technical authoring industry, we're interested in the benefits of XML in documentation solutions, rather than in the computing industry generally. This is why XML-based help is going to be so important.
What is XML?
So, what are XML and XML Help, and what will the introduction of XML Help mean to us all? Simply, XML is the eXtensible Markup Language. It was released in 1998. XML's design has some similarities to HTML (HyperText Markup Language), but there are crucial differences. HTML often handles content and appearance together, whereas XML is more of a data management system, designed for the structuring and storing of data, as well as the passing of data between systems that would otherwise be unable to communicate with each other.
Some of you may have heard of XML's predecessor, SGML (Standard Generalized Markup Language), and are wondering what's happened to it. SGML actually came before HTML (HTML was essentially a cut-down, more adaptable version) and at the time some thought SGML would become what many now are confident XML will become: an industry standard for cross-platform, reusable data. SGML is still popular with some organizations, for example those that need to manage large documents originating from a variety of sources that may be revised frequently and need to be output in different formats. However, for many organizations it is just too complicated, and the overheads for them of going down the SGML route outweigh the benefits.
XML, on the other hand, is simpler. But it's not simple. There is still an overhead, and the benefits of moving to XML are not appropriate to all organizations. And, crucially, there are many uncertainties as to what Microsoft's XML help will be like and what level of worldwide take-up it will have.
So, is there a risk that XML will fail to take off like SGML? No, not really. When Windows Vista is released, not only will many applications be written using XML coding but also, according to Microsoft Senior Vice President Steven Sinofsky the default file format for the new version of Microsoft Office applications is XML. What's more, it's worth keeping in mind that XML is a data exchange technology, and therefore many implementations may use it for describing and transferring the data, but use HTML to format and display it.
Then there's the whole issue of what 'flavour' of XML is appropriate for your organization's documentation's needs. For many this will primarily be the choice of DITA (Darwin Information Typing Architecture) or non-DITA. DITA is a way of using XML that automatically has a pretty good set of parameters for technical documentation projects. DITA's architecture is topic-based ('topic' here meaning a 'chunk' of information, not necessarily the same as a help 'topic'), so a help topic could comprise several DITA topics. This enables technical authors to order, reorder and nest topics to create any kind of information product. And, critically, each topic is only written once, and then is re-used wherever and whenever appropriate.
At some point, there's a whole lot of "stuff" you will end up needing to know if you're using XML in your documentation solutions, such as the difference between "well-formed" and "valid" XML, and what DTDs and Schemas are for, what people mean by specialization, and so on. But if your organization's not yet in the right place for the move to XML, then leave those technical issues for another time.
Summarizing the XML benefits
Here are some of the benefits of using XML in an organization's documentation solution:
 |
 |
|
| |
 |
The separation of data from layout. For some people, this may not seem a benefit, but honestly in terms of efficient authoring, it is. Technical writers can concentrate on writing top-quality documentation, and at some point they or even someone else (e.g. a designer) can worry about its appearance. |
| |
 |
Reusable components. XML makes it much easier to have topics, sections, paragraphs, and so on, that you can re-use time and time again which you only need to write once. |
| |
 |
Content identification. Text elements in XML are identified on the basis of what they are, not what they look like, i.e. their significance in the document's context. |
| |
 |
Single source publishing. Although the XML-development applications aren't at an advanced state, theoretically it will be easier to produce various types of help and guides from a single source. There are a few tools already trying to steal a march on the market, including Mad Cap Flare and Justsystems XMetaL Author DITA Edition. Some of these tools are worth looking at by organizations keen to migrate to XML. |
| |
 |
Similar coding to HTML. So those of us who already have experience writing HTML help topics will have a springboard to learning about XML. One thing to bear in mind though is that the coding rules are stricter, for instance all tags must be properly terminated with an end tag. |
| |
 |
Most modern web browsers are inherently capable of displaying XML files already. |
| |
 |
There's a degree of flexibility, in how "tight" or "detailed" the XML code needs to be. So, it may be that initially your learning curve is not too great because you choose to adopt a very "loose" set of rules, but over time you can "tighten" these rules. |
Current XML issues
Despite the theory that people from different locations using different tools can all contribute to providing XML Help, the reality is that for a variety of practical reasons a team of technical writers will all use the same help authoring tool. And, quite simply, the tools for authoring and producing quality documentation using XML are still in their infancy. We're starting to see some authoring applications with good user-interfaces that let technical authors efficiently write documentation that can be output easily to multiple destinations (e.g. compiled help, web-based help, printed documentation). But their limitations mean that they don't yet fully satisfy large sections of the help writing community. That's not to say that they aren't ready for the right organizations - undoubtedly more organizations every month are taking steps towards an XML-based technical documentation solution.
Conclusions
Although perfect for some, for most of Armada's customers, and most organizations throughout the world who are not already implementing an XML or SGML based solution to their documentation needs, now is not the time to change. That time will probably be around the release of Windows Vista.
|
 |
|