This is going to be very true right up until it isn't.
Yeah, I know that sounds fake-deep but we've seen this before; I'm old enough to remember when WordPerfect was the standard that wasn't going anywhere.
It will just be one of those inflection-point thingies.
I'm surprised Google Docs doesn't support all the features lawyers need by now. Seems like a market they'd want to go after, and their .docx conversion seems decent enough for basic formatting, tables, etc.
Curious what the top 3 features are that are missing. The article only mentions multi-level decimal clause numbering (e.g. 9.1.2). Seems like it would be a very easy feature to add. I've heard that line numbering is also a big legal thing, but Docs already has that.
I've been doing all my personal notes etc that I want a rich text format in .ODT for decades now and don't regret it one bit.
I do regret being overly paranoid in my 20s and not writing down my master passphrase to my personal documents -- I lost a huge chunk of diaries and writings due to that.
Fun fact: ODT uses Blowfish encryptio. Remember when we made Bruce Schnierer a meme like Chuck Norris? He wrote it -- apparently it's faster than AES?
Anyways, if you save with password in a .ODT file, if you pick a strong password you've got a nice little self contained encrypted volume that doesn't require "suspicious" software to open.
ANYWAYS, a bit of a tangent but... looking forward to death of Word.
The proposals suggesting markdown + git just sound like tone deaf proposals from 'coders' that are trying to push their square peg through a round hole. More appropriate proposals would be LaTeX + git or Word + subversion or some other vcs that has good binary support
Nonetheless, agree with the author that I don't see anything disturbing Word in that space for a long time, as good luck trying to get a middle-aged with minimal tech understanding to learn and use LaTeX over Word.
It's easy to think that Word's functionality is what you see on the Ribbon, mentally map that to Google Docs, and think that the latter can replace the former. But Word is extremely deep. The templating and style sheets allow for a level of fine grained control that doesn't exist in alternatives. There are features that exist purely for the legal market, like Table of Authorities, and customizable line numbering and hyphenation.
Maybe one day there'll be a product to replace Word, but it won't succeed by claiming to be a generalist replacement but only as a niche product that solves a particularly painful problem for lawyers and then expands over time to capture more use cases.
When you cryptographically sign something you need to be sure of what you are signing. That means that you have to be able to look at the document and see each and every character that you are agreeing to. So in a future where we actually work out how to do cryptographic signing we will be forced to use something very close to plain text. You need a format that will not unexpectedly change on you sometime in the future. That might break the signature or worse, maliciously change the meaning of the document without breaking the signature.
Opaque blobs like docx are not suitable for applications where the content of the document has to be completely clear to the various competing parties involved in something like a contract. It only works because the document gets printed out and then signed with a pen. If we want to move past that we need something different.
LibreOffice can export into PDF with embedded source document. This PDF can be opened for editing in LibreOffice. I think, they should make more use of this feature. Signature can be applied to PDF half which is definite enough
"git doesn't really work ... because docx is a binary blob."
Well, yes, but the binary blob is a zip archive of a directory of text XML files, and one could imagine tooling that wraps the git interaction in an unzip/zip bracket.
The real problem is that lawyers, like basically all other non-programmers, neither know nor care about the sequence of bytes that makes a file in the minds of programmers. In their minds the file IS what they see when they open it in word: a sequence of white rectangles with text laid out on it in specific ways, including tables with borders, etc. The fact that a lot of really complicated stuff goes on inside the file to get the WYSIWYG rendering is not only irrelevant to them, it's unknown.
Maybe the answer here will be along the lines of Karpathy's musings about making LLMs work directly with pixels (images of text), instead of encoded text and tokenizers [1]. An AI tool would take the document visually-standard legal document form, and read it, and produce output with edits, redlines, etc as directed by the user.
> For coders, visual aesthetics don’t matter. For lawyers, they are a technical requirement. While this difference may seem arbitrary on the surface, it is downstream of a critical technical difference between the two fields. Machines interpret the work of coders. Human institutions interpret the work of lawyers.
I believe this is not only infuriating, I am pretty sure it is actually illegal. If lawyers would think that visuals are more important than semantics, they would explicitly discriminate blind people.
A proper single-pane WYSIWYG editor that uses Typst under the hood would be able to stop the MSWord train by matching the features end users need.
- Small caps, no problem.
- Multilevel heading numbering, no problem
- Table of Authority, no problem
- Line numbers, no problem.
- Paragraph numbers, no problem.
- For missing features the community is more than capable of providing extensions to fill the gap. Redlining would be an example.
Ironic claims for me to see, observing the legal profession was the first time I noticed formatting could be irrelevant. LexisNexis on a text browser with dot matrix was just as legally binding as the case references before it.. Similarly the early ToS display.
> Additionally, every colleague, counterparty, outside-counsel, and client a lawyer ever works with uses docx. To introduce a new format into this ecosystem would introduce friction into every single interaction.
As an attorney, this is what kept me from switching to LibreOffice or Google Docs. I gave it a shot, but since the other attorneys I work with (both in and outside the US) and my clients all use Word, I ended up wasting a lot of time fixing files after converting between formats. In the end, it just wasn’t worth it.
I’m fairly tech-savvy, but many of my coworkers struggle with the mental effort required to switch to new software. Two colleagues I greatly respect still use WordPerfect and Word 2003 because they dislike change so much. It's too much of a lift for these people to wholesale switch word processors.
I used to think so. But over the past 5-10 years I’ve seen the quality of the mac application go down. Things, that used to work, are buggy. Bulleted lists, indents, even scrolling. Compatibility is going, too. I add pictures to find them not rendering once the file has been opened on a pc. I get files back from the customer with figure references having turned static. I’ve been using Word in some way or another since the beginning and it has never been that bad. Eventually this trend will degrade the usability to the extent a competitor would emerge.
There is a real world alternative to Markdown. Ada programming language standard is defined in a text format that is converted to TXT, HTML and PDF. Tools can compare different Ada standard versions, sometimes several versions, producing multi colored documents.
I'm honestly surprised this is such a groundbreaking insight.
The OP may be exaggerating a bit (it's marketing for their startup after all), but I'd expect that if you want to develop a product for a certain market, researching how the customers in that market operate and what their technical constraints are would be one of the first things to do.
Obviously, random people on Twitter won't do this, but here there seem to be entire companies that expect the whole legal system to move into their proprietary cloud. How did they imagine this would work?
It's a bad format for the imaginary problem but it shows that government action can actually force a change in workflows in the legal profession.
Akoma Ntoso has been pushed onto legislative bodies and by extension onto most of the legal profession in the EU and in many 3rd world countries. It does not solve the diff problem but it kind of solves the machine-readable storage of laws.
I'd go a few layers even broader than this article and say that the modern tech industry has an abysmal track record when building tools for non-software technical fields. Tech builds either their own software-oriented workflows or the most dumbed down consumer-oriented workflow they can. Law is an excellent example of a field with a very high degree of fidelity, philosophy, and process yet it can only ever have partial crossover with software development methodologies. Tech often treats someone like a lawyer as either a substandard developer or an advanced consumer without making a real effort to understand the context and needs of highly complicated yet non-software professions.
The problem with many programmers is they think the world revolves around them. That their way is the only way. That everyone should be doing things the way they do.
27 comments
[ 2.6 ms ] story [ 50.6 ms ] threadYeah, I know that sounds fake-deep but we've seen this before; I'm old enough to remember when WordPerfect was the standard that wasn't going anywhere.
It will just be one of those inflection-point thingies.
Curious what the top 3 features are that are missing. The article only mentions multi-level decimal clause numbering (e.g. 9.1.2). Seems like it would be a very easy feature to add. I've heard that line numbering is also a big legal thing, but Docs already has that.
I do regret being overly paranoid in my 20s and not writing down my master passphrase to my personal documents -- I lost a huge chunk of diaries and writings due to that.
Fun fact: ODT uses Blowfish encryptio. Remember when we made Bruce Schnierer a meme like Chuck Norris? He wrote it -- apparently it's faster than AES?
Anyways, if you save with password in a .ODT file, if you pick a strong password you've got a nice little self contained encrypted volume that doesn't require "suspicious" software to open.
ANYWAYS, a bit of a tangent but... looking forward to death of Word.
Nonetheless, agree with the author that I don't see anything disturbing Word in that space for a long time, as good luck trying to get a middle-aged with minimal tech understanding to learn and use LaTeX over Word.
Maybe one day there'll be a product to replace Word, but it won't succeed by claiming to be a generalist replacement but only as a niche product that solves a particularly painful problem for lawyers and then expands over time to capture more use cases.
Google offers so many things free out of the box. And for serious spreadsheet sort of work, I use numpy.
Google pretty much won the Office software war.
Opaque blobs like docx are not suitable for applications where the content of the document has to be completely clear to the various competing parties involved in something like a contract. It only works because the document gets printed out and then signed with a pen. If we want to move past that we need something different.
That's PDF. PDFs are for the final work product. Word is for the work in progress.
Well, yes, but the binary blob is a zip archive of a directory of text XML files, and one could imagine tooling that wraps the git interaction in an unzip/zip bracket.
The real problem is that lawyers, like basically all other non-programmers, neither know nor care about the sequence of bytes that makes a file in the minds of programmers. In their minds the file IS what they see when they open it in word: a sequence of white rectangles with text laid out on it in specific ways, including tables with borders, etc. The fact that a lot of really complicated stuff goes on inside the file to get the WYSIWYG rendering is not only irrelevant to them, it's unknown.
Maybe the answer here will be along the lines of Karpathy's musings about making LLMs work directly with pixels (images of text), instead of encoded text and tokenizers [1]. An AI tool would take the document visually-standard legal document form, and read it, and produce output with edits, redlines, etc as directed by the user.
[1] https://x.com/karpathy/status/1980397031542989305
I wonder if M/S got that "fixed", early on they had a hard time with it.
I believe this is not only infuriating, I am pretty sure it is actually illegal. If lawyers would think that visuals are more important than semantics, they would explicitly discriminate blind people.
- Small caps, no problem. - Multilevel heading numbering, no problem - Table of Authority, no problem - Line numbers, no problem. - Paragraph numbers, no problem. - For missing features the community is more than capable of providing extensions to fill the gap. Redlining would be an example.
As an attorney, this is what kept me from switching to LibreOffice or Google Docs. I gave it a shot, but since the other attorneys I work with (both in and outside the US) and my clients all use Word, I ended up wasting a lot of time fixing files after converting between formats. In the end, it just wasn’t worth it.
I’m fairly tech-savvy, but many of my coworkers struggle with the mental effort required to switch to new software. Two colleagues I greatly respect still use WordPerfect and Word 2003 because they dislike change so much. It's too much of a lift for these people to wholesale switch word processors.
Sources of standard: http://www.ada-auth.org/arm-files/2022-SRC.zip
Format tool can be found here: http://www.ada-auth.org/arm.html#Format_Tool
Sample output with edits: http://www.ada-auth.org/standards/22aarm/html/AA-5-2.html
Red color is for Ada 2012 -> Ada 2012 TC1 diff, green color is for Ada 2012 TC1 -> Ada 2022 diff.
The OP may be exaggerating a bit (it's marketing for their startup after all), but I'd expect that if you want to develop a product for a certain market, researching how the customers in that market operate and what their technical constraints are would be one of the first things to do.
Obviously, random people on Twitter won't do this, but here there seem to be entire companies that expect the whole legal system to move into their proprietary cloud. How did they imagine this would work?
It's a bad format for the imaginary problem but it shows that government action can actually force a change in workflows in the legal profession.
Akoma Ntoso has been pushed onto legislative bodies and by extension onto most of the legal profession in the EU and in many 3rd world countries. It does not solve the diff problem but it kind of solves the machine-readable storage of laws.