The user’s word processor of choice was used to manage form volumes in FastDraft. To improve the user experience FastDraft needed a way to let the user define a new component for example and then have FastDraft insert it in the correct place in the current document. The same was true for variables, logic and various style modifiers. To accomplish this, the original versions of FastDraft used macros for Word and WordPerfect to integrate with FastDraft when editing a form volume. Macros were also used to clean up various formatting issues after a document was drafted and the user could specify additional macros to load and run at the end of the assembly process. This worked reasonably well but in 2009 it was clear a different way was needed.

At Valeo Software we had all but abandoned supporting WordPerfect by 2003 partly because of the issue of maintaining the WP macros. In 2004 when Valeo Software ceased operations and I decided to provide very limited support to FastDraft’s user base I completely abandoned WP. WP still worked and the installer still installed the macros if the user chose WP as their word processor but I had no intention of updating the macros when the next version of WP was released mostly because I had no intention of updating FastDraft or the installer. Most of the FastDraft community was using Microsoft Word at this point and the 80/20 rule won out.

There were a few WP users who had some issues and I was able to help them and I did make updated versions of the WP macros available to anyone who wanted them but there were very few who downloaded the updated macros. Right or wrong, this seemed to confirm the decision to focus on Word was the right one.

With the release of RediDraft replacing FastDraft in 2010 I went all in on integrating with Word. FastDraft used the rich text file (RTF) format to store the form volumes and assembly documents; RediDraft used the Word docx format. This change completely solved some style and format issues we had fought with for years and with a fully supported library to break apart and reassemble the Word docx files it truly felt like a no-brainer. I also moved away from Word macros and embedded Word within a form to interact with RediDraft while editing a form volume. This too felt like a no-brainer at the time but it introduced new intermittent problems during content curation.

Now there is a better way.

I still want the user to be able to use a word processor to curate their content if they wish. To support that in Microsoft Word a new Office Add-In for Word was created to handle the interface between Word and RediDraft. This add-in handles all the familiar things like setting up a new component, formatting and inserting variables, defining linked, excluded and secondary document components, and adding logic blocks to a component. This approach has a huge benefit over the way this has been handled before. Starting with the 2024 release, a user can re-open an edited form volume outside of RediDraft and have it connect behind the scene to fully integrate with RediDraft. If you are working with a normal document this add-in never activates. It is a great user experience.

<NEED ADD IN SCREEN SHOT>

RediDraft is a niche product and I am still trying to decide whether to put the add-in in the Microsoft store or not. It is easily side-loaded into the stand alone or online versions of Word. I guess my fear is putting it in the store might lead to some confusion when stumbled upon. What does it do? Why didn’t it do anything after I installed it?

Small and boutique law firms are the primary users of RediDraft and this add-in is only needed if you are curating content in Microsoft Word. If you are just assembling documents you don’t need it and it would never activate even if it was installed. At this time, I am heavily leaning to the side-loading approach.