When people in the legal or corporate world sit down at their computer to write a brief, a memo, a personal note, they likely begin by opening Microsoft Word, the de facto corporate word processor. They start with either a blank page or a template and begin to enter text, but quickly realize that their input might not look exactly how they want so they spend the next twenty minutes changing fonts, spacing, styles, and other formatting items that should take a back seat to the important content that they are meant to be emphasizing.
Once the page looks exactly as the writer likes, they may begin entering the content again. But wait; something doesn’t look right. The bullet list has weird spacing gaps and Header 2 is still in Calibri! The writer then watches as another 15 minutes are sucked away by formatting. Finally, the draft is completed and ready to share with a colleague for edits before the final version can be sent.
A day goes by and memo_v2_JAF_edits.docx appears in the writer’s inbox. Their colleague has enabled track changes (good) and proceeded to change all the fiddly line spacing rules, tab sizing, and manually added an extra space to the end of every sentence (bad). Worse still, the only change to the content is a comment on a paragraph that just says, “plz fix, thx.”
Bike-Shedding, or Parkinson’s Law of Triviality
If this has happened to you or someone you know, you might be familiar (or should become familiar) with the term “bike-shedding” (known more formally as Parkinson’s Law of Triviality). In 1957, C. Northcote Parkinson of Parkinson’s Law fame (“Work expands so as to fill the time available for its completion.”), presented a fictional argument, based on real observations, centered around the design of a nuclear power plant.
As the story goes, the plant designer presents his plan for the plant to a board who holds the purse and the power to make any changes. The designer first presents the plans for the reactor, the complex and expensive design at the center of the plan. It is, obviously, the most important design and should have the greatest amount of oversight. The board asks no questions and approves the reactor design without hesitation. With the most important piece approved, the designer begins explaining the minutia: the simple design of a shed on the outskirts of the premises intended to be a storage area for employees who bike to work. Arguments ensue and opinions are shared, shot down, defended. Time is essentially wasted since the design of a bike shed has little to no impact on whether the nuclear reactor is safe and efficient.
The reactor is approved quickly because it is so complex that the board either has faith that the designer knows what he is doing and that his plan is more than adequate or they don’t want to waste the mental energy trying to understand it all. The board instead focuses on the bike shed. It is something each member understands easily and can afford to have a preference on with little chance of ruining the project as a whole.
When coworkers review written Word documents, they inevitably begin to bikeshed. Aesthetics guide emphasis and if one is able to change the aesthetics, they will. How can this problem be solved? How may focus be returned to the nuclear reactor?
Substance Over Style
The primary way to avoid revisions (and distractions) based on style is to separate the content of a document from the formatting process. Ideally, text would exist in its own file, plain and unadorned. Then, in a separate file or section, choices about how the text is to be rendered, such as font choice, line spacing, or margin size, would be listed. To pair specific parts of the text file with the decisions made in the formatting file, a simple set of tags would instruct the computer when a line is a section header or part of a list.
If you have dabbled in computer technology over the last few decades, this will probably start to sound familiar. Add an additional file with instructions to update the content of pre-marked sections with text or images based on a context or user input and this series of files begins to mirror the one of the fundamental frameworks of the internet: HTML + CSS + JavaScript.
HTML (HyperText Markup Language), CSS (Cascading Style Sheets), and JavaScript work together to create some of the most complex documents imaginable, but much of the information on the web shares CSS and JavaScript. You can see this on blogs, social media sites, or most anywhere online that offers the opportunity for many people to separately input text. This is why all tweets look the same when rendered. With this model, text can be slotted in to a style any time during its production and when the text changes, the formatting stays the same. An additional benefit is that should a judge or a partner want to see the content in a different style, they simply need to load it with a different formatting file. A widespread adoption of this way of creating and formatting text would solve many of the issues that surround compatibility, file size, and conflicting preferences. It would save time, shift focus to substance, and facilitate the automation of court-specific or judge-specific formatting requirements.
But is it too complex?
Multiple files to create one document, scripts changing some of the content automatically, less control over how a reader will see each page of your brief: separating the substance from the style seems like it would require a steep learning curve and steeper time commitment for already time-constrained lawyers. This is deceptive, however, and following an initial setup (likely by technologists, not individual lawyers) creating format-voided content should be as simple as using a digital typewriter.
To see an example of how simple this could be, consider the proliferation of Markdown, a markup language that is distinguished by simple markup tags and easy conversion to other formats, namely HTML for display on the web. It has free and open-source online editors, like Dillinger, as well as deeply complex desktop or iOS apps, like Scrivener. Markdown has gained much of its popularity among writers and bloggers as the level of technical knowledge or familiarity required to produce great looking text is fairly minimal and the tags can be quickly learned by writers of all skill levels. Markdown, however, was created for parsing text to be read on the web. It lacks features that would be fundamental to legal documents while easily incorporating others that would have no place in a brief. It is important, however, to consider Markdown in the context of how it has changed the workflow of writers. With the creation of a legal markup language, these same benefits can be visited upon lawyers as well.
What about Word?
But could one just use Word for this? While the potential exists, in practice it would be stripping Word of its core functionality and purpose. First released in 1983, Microsoft Word was marketed as a “What You See Is What You Get” (WYSIWYG) editor, meaning that formatting is inherently tied to the Microsoft Word writing experience. It is exceptionally hard to separate out the meaningful content and Word will always show a facsimile of a piece of paper, a ruler to declare tab size, and a drop-down font picker. Additionally, the way the underlying Word document files are structured commingles formatting decisions with the actual text of the document.
Word does have some great an inspired writing tools like spell check, track changes, and styles. Recently, however, these tools have been appearing in text editors of every flavor, with styles even being at the core of Markdown as headers. Tools to facilitate collaboration, specifically, have begun to grow as always-on internet has become the norm both in the office and at home over the last two decades. Tools that replicate or exceed all the functionality that Word provides lawyers, while leaving much of the kitchen sink back in Microsoft’s suite, are on the rise, although not always precisely customized to address the needs of lawyers.
The Lag in Legal Tech Adoption
While all of the above may sound like the solution to countless problems, lawyers en masse have failed to adopt these practices. I see several reasons for this:
- Word is ubiquitous and has been for decades. Clients and co-counsel will all be able to (and often only want to) open, edit, and revise documents provided in .DOCX format.
- Law schools and firms don’t teach or adopt alternative technologies, likely in part because the more established senior members of the profession feel that their time is better spent not learning new drafting technology.
- There is a general lack of exposure to technology and technological advancements in the legal profession, with attorneys who are too busy to upend their status quo and aren’t able to try technology with real-world examples during practice.
- There currently does not exist a legally-focused tool that is good enough. While Word can do everything that is needed for the creation of briefs, it too is unwieldy and not focused on the legal market any more than the market of aspiring novelists.
Because of the above, Word will not be replaced any time soon in the legal practice. It is simply too engrained in both the firm and client culture. This is why we decided to build LitKit as a suite of tools that brings some previously out-of-reach automation, such as applying redactions or renumbering exhibits, directly into Word. While we wait patiently for the day the legal world adopts easily portable and platform agnostic technologies, we encourage all lawyers and legal technology providers to become more familiar with the functions and benefits Microsoft Word can offer.
Today, the best tool for programmatically generating legal content is a little-known solution called LaWTeX. LaWTeX works within LaTeX—a program that allows the writer to adjust nearly every facet of a print with typesetting markup. LaWTeX is a macro package that attempts to solve some of the pain points in legal drafting, such as automating citations in Bluebook style.
While LaWTeX has many benefits, it does come with some downsides. Firstly, unlike most Markdown editors, live previews are not available and the document must be compiled before shown. Secondly, the markup LaWTeX uses is fairly complex. While powerful, it is unlikely that WYSIWYG users will find the transition as easy as transitioning to Markdown. Lastly, LaWTeX has not seen significant updates since its release in 2014 and does not have any type of user support beyond community forums. With this, it is unlikely that law firms will seriously consider adopting LaWTeX, though smaller firms with tech-savvy staff may be able to more easily implement it.
