20 days ago, Microsoft announced the ODF translator project. Brian Jones clarified a few issues in another blog post a few days later. Currently, an early version of the ODF translator project is available for Word. It integrates into Word as an add-in. You can download a copy as well as the full source code from sourceforge.

One of the most contentious issues became right away how the ODF add-in integrates into Word. Brian claimed:

“It’s directly exposed in the UI. We’re even going to make it really easy to initially discover the download. We already need to do this for XPS and PDF, so we’ll also do it for ODF. There will be a menu item directly on the file menu that takes to you a site where you can download different interoperability formats (like PDF, XPS, and now ODF).

Heck, if you wanted to be even more hardcore, the Office object model allows you to capture the save event. So if you wanted to you could make it so that anytime you hit save you always used the ODF format, just by capturing the save event and overriding it. I’m not expecting folks to do that, but it does show just how extensible Office really is. ”

The following screenshot shows the default integration as an ODF menu item in the Office button menu with an associated flyout containing the Open and Save commands:

It didn’t take long for the criticism to start. Rob Weir, for example, critiqued in his blog post that ODF cannot be found in the Save As and Open dialogs nor can be made the default file format.

As this is an UI issue, I decided to take a closer look.

The facts

• Let me start out with one simple fact: The ODF translator add-in has to make do with what currently exists in the Office 2007 extensibility model. Why?
  
• Microsoft is providing ODF support as an add-in, not as a built-in feature. That means, the add-in is limited to what every other Office add-in can do. As it is not a built-in feature, Microsoft was able to announce it as an open source project.
• Microsoft isn’t going to provide any special MS-only hooks in Office 2007 just to integrate the ODF, PDF & XPS things into it. MS-only hooks would just be a waste of development resources and non-MS add-in developers would want to use them as well (which would be simple due to the open source nature of the ODF translator project). Hence, this is either going to happen through a normal Office 2007 add-in mechanism, or not at all.
• The Open & Save As dialogs cannot be customized: There simply is no way for an add-in to add another file format to the file type list in those dialogs. I checked this with the Office beta team just to be sure.
• It is possible to write a custom file import/export converter for Word. This would add the file type supported by the converter to the file type lists in the Open and Save As dialogs. Unfortunately, this is not an option for the ODF translator project. Such a custom converter would convert between RTF and the desired format, which simply misses the point for the ODF translator add-in. For more details, see the respective MS KB article.
• The ODF translator add-in is therefore limited to what can be done via RibbonX.

Why not provide the ability to customize the Open and Save As dialogs?

• ODF support was clearly an after-thought for Office 2007. It was announced after the release of Beta 2. Office 2007 was for the most part feature complete with Beta 2 and it is therefore extremely unlikely that Microsoft is going to make any substantial changes to the extensibility model between now and RTM.
  
• Why should MS waste resources on providing one particular feature for add-in developers that most Office add-in developers (all not affiliated with Microsoft) would put at the very bottom of their wish list? How many add-ins would actually use such a feature (answer: 3; ODF, PDF, XPS). Sorry, but providing such a feature to satisfy 3 add-ins is a real waste. There is so much missing in Office 2007 from the point of view of an add-in developer, that MS has enough work for the entire next release (after 2007) before even considering the Open & Save As dialogs issue.
• For more about this, see my blog comment.

The RibbonX side of it

If you download the source code, you’ll find a file named “customUI.xml” in the OdfConverter\source\OdfWord2007AddIn\resources folder. The file contains the RibbonX code that the add-in uses:

This RibbonX snippet shows how simple the integration of this add-in into the Office button menu is. Let’s see how we can modify this.

The first modification we can easily make is to get rid of the ODF menu and integrate it differently into the menu. The following screenshot shows the Open ODF command directly below the Open command, and integrates the Save as ODF command into the Save As flyout:

In order to accomplish this, we’ll need to use the following RibbonX:

The modification of the splitButton “FileSaveAsMenu” shown above adds an item to the Save As flyout. The “insertAfterMso” attribute specifies the exact position in the flyout menu and in the menu itself. You can see from this example that the order of the items in the XML code doesn’t matter when we use this attribute. The Open ODF button is in the XML below the modification of the Save As flyout, but the button nonetheless right after the built-in Open button.

The only effort required to use this customization is to change the “customUI.xml” file and rebuild the add-in with Visual Studio 2005.

Providing our own Open and Save As dialogs

A much more sophisticated customization is to replace the existing Open and Save As dialogs with our own ones and also to override the Save command. This should never be used for add-ins in an uncontrolled environment, as my UI style guide explains. I would like to discuss the option here though, because of the way I see the ODF add-in being used:

Most average users really don’t care about ODF vs. OpenXML. All they want to do is save their files and they are hardly ever going to change the default file format anyhow. As Brian has pointed out before, ODF doesn’t support all of what OpenXML supports, and hence ODF is not useful for most users as the default file format for Office 2007 (lack of full fidelity).

Most people who will use ODF will do so due to company/agency policy. That means, the ODF add-in will be preinstalled for them by their network administrators. Network administrators can easily change the add-in (one of the benefits of open source) in such a manner that ODF will be the default for open and save. Everyone else who downloads the ODF add-in, will actually know what they are downloading and will have no problem finding it at its prominent location in the Office button menu.

That means, I see this add-in either use in a controlled environment where repurposing is no problem, or by power users who can either choose to use the repurposed version or easily use the menu items in the Office button menu.

In order to override the built-in features and render ODF the de facto standard file format, we’ll need to override three things: Open, Save and Save As. In RibbonX, the result looks like this:

You might be wondering about the enabled=”false” in this and all previous RibbonX snippets. The code for saving in the ODF format isn’t implemented yet in the Word add-in that was released on July 5, 2006. Once it is implemented, those attributes can simply be removed. The above RibbonX code assumes that ExportODF handles the different behavior of “Save” and “SaveAs”.

In the C# code of the add-in itself, the signatures for ImportODF and ExportODF need to be changed to:

public void ImportODF(IRibbonControl control, ref bool fCancelDefault)

public void ExportODF(IRibbonControl control, ref bool fCancelDefault)

fCancelDefault determines whether the built-in action is executed after the repurposed action or not. If fCancelDefault is true, then the built-in action will not be executed. For the ODF add-in, fCancelDefault should be returned as true therefore.

This modification changes the default file format of Word 2007 to ODF. At the same time, it doesn’t allow the user to save in any of the built-in file formats. In order to make this add-in behave more realistically, the Open and Save As dialogs in the add-in should include the default file formats and trigger the respective action via the Word object model. In addition, when ODF was chosen as file format, the add-in should disable all functionality in Word that cannot be saved in ODF. This is similar to the Compatibility Mode in Word 2007: When working on a Word 97-2003 file, features that are specific to Word 2007 are not available. I could imagine e.g. that SmartArts would be disabled in an ODF Compatibility Mode. Maybe someone in the community is going to implement such a more advanced add-in and it will be provided as an alternative on sourceforge?