Until now, to create a contract in Tractis, contextual buttons had to be used (“Add section”, “Add clause”) which appeared when the cursor passed over the text. We liked that solution because it forced users to indentify/semantize the type of element before adding it. For each element (title, section, clause, etc.), we used a different textarea, which enabled us to apply different behaviors to each paragraph (a grey background for the editor, yellow for hoover, etc.). Thanks to CSS, users didn’t have the feeling that they were editing a form full of textareas but that it looked like a single document. In theory, that was the perfect solution. But only in theory:

Each textarea was a single compartment. Unlike Word which does permit this, users could not surf the contract downwards only with the use of cursors. Whether you believe this or not, we didn’t realize this until we tried it. We could have resolved this with more javascript but we knew that we were already overusing it.

Users could not cut and paste a contract from their favourite word processor, they had to do this paragraph by paragraph (create a clause, paste the paragraph, create a clause, paste…). Again, we didn’t realize this.

When the contract increased in size, the editor became extremely slow and unstable (we would look through the document’s DOM continually during execution time to ascertain where the cursor was or where changes had taken place).

The appearance of menus when moving the cursor was quite distracting, and javascript generated serious compatibility problems between the various browsers.

Users complained that the editor gave them a “strange feeling”. They couldn’t explain it but it was something they were not used to. Our objective was that they could edit contracts 100% online, forgetting about their word processor. If the editor gave them a “strange” feeling, we were running the risk that they would not use Tractis or that they would continue to use Word or OpenOffice and then cut and paste the text in Tractis. Unacceptable. We had to change the focus and make substantial changes. Even if this meant throwing away the code and hours of work.

What was happening to us was a perfect example of why continuous repetition (develop, test, repeat) in the development is a thousand times better than the “big bang” strategy (one year developing and testing it at the end). Until you test your ideas, you’ll never know whether or not they will really work.

We’ve decided to use an existing WYSWYG editor. After analyzing several options, we chose Dojo Editor. We changed it to integrate it into our version comparisons so that it produces a clean XHTML, whose meaning we can interpret, and restricts entry (cut & paste) of unpermitted labels. Now, instead of asking users to tell us the meaning of each element, we deduce the meaning of the document’s structure. With the new editor engine:

The document can be edited in a more traditional and intuitive way.

There’s no need to hit the buttons to add elements. All you need to do is press return to create a paragraph.

Editing is faster (instead of many textareas, we use a single iframe).

Users can cut and paste contracts from their word processor into Tractis in a second.

We don’t have to try a large amount of javascript code in each browser (the Dojo people are in charge of this).

Personally, I’m very happy with the result. It’s fast, very fast. Even in large documents. You feel that you’re using the desktop editor that we’re all used to and it’s much more stable and compatible with the browsers than before. If you’re a beta tester, don’t worry: no document has been lost in the transition .