Gilles Gravier's Weblog

Saving as ODF, or Exporting to ODF?

Now that states around the globe are starting to mandate the use of ISO/IEC 26300 (Open Document Format) for storing and exchanging documents around the world, the legitimate question that arises is how should this be made available to users of business automation software suites?

Several approaches have been starting to appear. Native support? Plug-in? External application? Let's look a bit at what each of these bring to the user.

There are quite a few software suites that already offer native support for ODF. OpenOffice.org, Staroffice, KOffice (since version 1.5), IBM's Workspace, Textmaker, Abiword, Gnumeric, Writely. These applications have chosen to directly manipulate ODF documents. The result is extremely comfortable. Any document created is automatically saved in the ODF format. Groups that have a requirement to use ODF don't need to worry about inadvertantly saving a document in a legacy or proprietary format. People with disabilities have simple one-step "Save" and "Open" operations. No need for convoluted manipulations. This is the most transparent method.

Using a plug-in can enable an application that doesn't natively speak ODF to still operate in an environment where regulations require the use of ISO/IEC 26300 open standard for document management. Depending on the plug-in API for the application, the result can be made almost as comfortable as the native support of ODF. Indeed, if the plug-in API permits the replacement or overloading of the default "Save" and "Open" functions, it can be just as comfortable as for native support. Alternatively, the addition of a "ODF Save" or "ODF Open" set of functions can bring sufficiently close functionality to satisfy requirements. Note that with adding "ODF Save" and "ODF Open", there is still a risk that the user may inadvertantly use the old "Save" / "Open" functions and save the documents in the legacy / proprietary format that is native to the application. Also, the quality of the conversion by the plug-in is a critical factor in adoption of this kind of system. Since the native format isn't ODF in this case, there needs to be a conversion that is done. The risk that the conversion doesn't work 100% is there and some documents could come out requiring some editing in order to be as they are expected. This problem is common to all situations where documents are converted from one format to another.

Using an external application is an easy to implement solution. In fact, it doesn't require much work to implement at all. Just take something that can do the conversion for you, and have it do that for every document that you need converted, when you need it. You could imagine doing it that directly from OpenOffice, since it is freely available, and supports several document formats in addition to ODF. Installing OpenOffice on a system is a cheap and easy way to get to this external application mode. Of course, you need a few wrappers so that you can have a command line or graphical user interface to control document conversion. The really serious drawback here is for people with disabilities. Since this type of process requires up to several additional steps. So of course, it becomes much less comfortable. And also, the risk of users deciding to not use the approved format, just for sake of ease of use, is high, putting administrations at risk if they are constrained by regulations to use ODF. Same limitation about quality of converters applies here as for plug-in approach. Make sure the conversion tool you pick is very good or your experience will be negative, because of that tool, not because of ODF.

Another problem related to both plug-in and external application approach is that, if users are tempted to still save in legacy format and only convert when they need to interact with other official entities, they will use features that are hard or impossible to convert between their legacy / proprietary format and the ODF. They will be tempted to rely on these features and, when it is time to convert the documents, will have to go through great pains to make the documents compatible between the two formats. Result will be a negative experience.

In summary, whatever method chosen, great care should be taken to ensure the following points:

1) Quality of the conversion. If documents get badly converted, the interest of the approach will not be bery high.
2) Ease of use of the generation of ODF documents. The more required steps the harder it is and will impact users with disabilities.
3) Temptation to not save in ODF format (linked to ease of use, also). Look at the risk that non ODF documents will be generated in day-to-day use because it's easier. That leads to predictable future problems when having to convert them to ODF to communicate with others.

Chose what suits your needs best, and enjoy a new world of open standards where everybody can exchange information regardless of the application each individual or service elects to use!

Posted at 11:53AM Jul 11, 2006 by gravax in Opensource  |  Comments[0]