Ever since I started working on my legislative editor (http://legalhacks.org/editor), I’ve been asked over and over if I was using Google Docs, and if not, why not.
So to answer the first part of the question, the answer is a simple no. I don’t use Google Docs or anything like it.
There are a number of good reasons why I take a different path. The first reason is that Google simply doesn’t open Google Docs to that type of customization. Even if the customization capability was there, there are still plenty of reasons why choosing to build a legislative editor around Google Docs would not necessarily make sense. We can start with the privacy and security concerns with storing legislation in Google’s cloud. Let’s set aside that level of concern to focus more on the technical issues of the editor itself.
We’ll start by considering the difference between a word processor and an XML editor. When done right, an XML editor should superficially look just like a word processor. With a lot of effort, an XML editor can also be made to feel like a word processor. When I was implementing XMetaL for the California Legislature, the goal was very much to achieve the look and feel of a word processor. That is possible, but only to an extent.
There is a big difference between a word processor and an XML editor. Just because modern word processors now save their data in an XML format, they are not XML editors as a result. If you take a look at their file formats, OOXML for Microsoft Word or ODF for Open Office, you’ll see very complex and very fixed schemas that are far more oriented around presentation than one typically desires in an XML document. In fact, we try to separate presentation from structure in XML documents while OOXML and ODF blend them together. That’s what is at the heart of the difference between a word processor and an XML editor. In a word processor you worry about things like page breaks, margins, fonts, and various other attributes of the document that make it “pretty”. In an XML document, typically all of that is going to be added after the fact using a “formula” rather than being customized into each document. So while what you see in an XML document might look WYSIWYG, it’s actually more like “Somewhat WYSIWYG” and your ability to customize the formatting is quite constrained. This approach focuses you on the content and structure of the document and allows the resulting information to be targetted to many different form factors for publication. By not dictating the formatting of the document, the publication engine is more free to choose the best layout for any particular publication form – be it web, paper, mobile, or whatever.
When I explain this, the next question is whether or not my implementation is similar to how Google Docs is implemented. The answer is, again, a simple no. Google Docs’ implementation is dramatically different from the approach that I take. My approach relies on the new APIs being added to the browsers, in a consistent standardized way under the HTML5 umbrella, that allow the text content to be selected, edited, dragged about, and formatted. While these capabilities existed in earlier browsers to some extent, the manner in which they were supported was in no ways consistent. This made supporting multiple browsers really difficult and the resulting application would be a patchwork of workarounds and quirks. Even then, the browser variations would result in inconsistent behaviors between the browsers and the support and maintenance task would be a nightmare. It is for this reason, along with a need for page-oriented layout features, that Google abandoned the approach I am taking – though at a time when the standards that help ensure consistency were lacking.
So how does Google Docs do it then? How come they didn’t get bogged down in a sea of browser incompatibilities amongst all the legacy browsers they support? They do it by completely creating their own editing surface in JavaScript – something codenamed “kix”. Rather than relying on the browser for very much, they instead have their own JavaScript implementation of every feature they need for the editing surface. That is how they are able to implement rulers, pages, and drag boxes in ways you’ve just never seen in a browser before. It’s an amazing accomplishment and it allows them to support a wide range of browsers with a single implementation. That’s what you can do when you’re Google and have deep pockets. It’s a very expensive and very complex solution to the problem I am attempting to solve with modern standards. So while I can reasonably support the future alone with no baggage from the past, they’re able to support future and past browsers by skipping on the baggage but instead having their own custom implementation of everything. While I’m amazed at Google Doc’s accomplishment, attempting a similar thing with an XML editor would be cost and time prohibitive. Keep in mind that a lot of the capabilities of Google Docs’ editing surface deal with presentation aspects of a document, something that is of less concern to the typical XML document.
I’ve been working in XML editors for over 10 years now. Over the years, I’ve spent a lot of time wondering how one might implement a real web-based XML editor. Every time that my thoughts went beyond wondering and moved towards considering, I quickly discovered that all the resulting limitations of divergent implementations of base technology would make the project impractical. That’s partly what drove Google to spend the big bucks on a custom editing surface for their word processor. Now however, HTML5 is beginning to make a web-based XML editor a practical reality. Don’t mistake me, it’s still very difficult. Figuring out how to keep and XML document and an HTML5 view synchronized in not a simple task. While the browsers have all come a long way, they all still have their own weaknesses. Drag and drop has been broken in Safari since 5.1.2. Opera’s selection mechanism breaks when you toggle the contentEditable attribute right now. But these are problems that will disappear with time. As the standards are implemented and the bugs are fixed, I can already see how much HTML5 is going to change the application landscape. I would think long and hard about returning to traditional application development given what I now know about HTML5.
