It's curious to me how many people think "just convert it to a different filetype" will solve the problem.
Do you think there are other professions/industries that would benefit from this?
replies(4):
My recollection of his takeaway was that lawyers actually didn't want a lot of the things git offered. For example, they always wanted to be using the latest version -- the abstraction of multiple branches where multiple people independently worked on things then merged them back together wasn't quite how most lawyers worked. And the other big thing was a network problem: a lawyer has to us microsoft office's version control because the opposing team is going to use it, so even if you use some better editor software it still has to be sent as a word file showing the tracked changes to the other side.
Definitely. Finance professionals, academic researchers, legislators, among many other professionals, encounter similar version control issues. We are currently focused on law because of our domain expertise and because the problem is particularly pronounced in the law.
This depends a lot on the practice. Transactional lawyers working in M&A and real estate encounter the issue of parallel drafts all the time. Personal injury lawyers tend to work in isolation and don't need all of git's functionality. Pretty much every lawyer redlines in some capacity, however, and benefit from visualizing a linear version history.
>And the other big thing was a network problem: a lawyer has to us microsoft office's version control because the opposing team is going to use it, so even if you use some better editor software it still has to be sent as a word file showing the tracked changes to the other side.
Yes, this is absolutely correct. This is one of the main things that keeps docx entrenched as the standard in legal collaboration. It would be an enormous faux-pas to send another lawyer a contract in an application that they're unfamiliar with. Backwards compatibility with their existing workflows is essential.
Why don't more people use Git and Markdown for their todo lists and/or GTD systems?
The Git client is ideal for displaying lists and editing a little text file you git push could not be more simple.
It felt crazy that there wasn't better tooling for this, but I also appreciate the difficulty of trying to get lawyers out of the MS Word workflow that they know.
Good luck to the team! I hope you're successful.
Git is a tool built around the needs of software developers. Because git is too complicated and branching, though in principle, would make sense in some situations, is actually pretty difficult to manage (especially for binary documents).
Also, they do use version history built into tools like Sharepoint/Office, or the document itself.
All I need is a file structure that I understand, and an editor for typing and searching :)
Git is great for (i) persistence, (ii) availability and (iii) the merge flow encourages me to review/clean changes before merging them to main.
For example, "they always wanted to be using the latest version". Was that said _before_ or _after_ git was vaguely explained to them?
Maybe showing a working prototype has a different effect than explaining branches and commits.
> still has to be sent as a word file showing the tracked changes to the other side.
Dude spent a lot of time understanding docx. This sounds like a feature he could implement if he wanted to (Export changes to classic word...).
I get that dislodging docx is an impossible job, but since docx is a terrible format for anything, it needs to be done for all the reasons the author mentions. The codes that run society should not be locked up in bad proprietary formats.
They're all incredibly capable formats (from a user perspective anyway), with the caveat that they're utter hell to work with in terms of a programming perspective. It's easier to just toss it into a black box parser/serializer and hope that all the text you need in/out comes out properly on the other side.
Actually generating docx or xlsx files (that aren't trivial) that look exactly like another input file (so you have to account for every notable difference in formatting) is a ton of work; most people who have touched webdev will probably at some point have had to format their emails for Outlooks half-assed ancient HTML parser and even there, you at least control what it's going to look like.
This group of people is willing and ready to learn but you still often hear "just checkout the project again" when a problem is encountered.
Most people just use an app and are fine with that functionality. My partner and I use a Google Keep list that is shared between our accounts. Live editing included and it does everything just fine.
There are more elaborate app solutions out there that do more and solve most of the problems.
Back in the day, to solve that (before I became a software developer and knew about git), I basically re-implemented "git in Microsoft Word version control".
On bigger contracts with dozens and even hundreds of pages, with more than 2 parties involved, we could have 3-4 parallel changes to the same documents at once. And a lot of times some of the parties didn't want to advertise their changes.
What I did was construct a table in Excel with each "version" of each clause, and where they were present omitted. It was a lot of work to maintain, but back then I didn't know any better, but worked.
By saving the versions of the files we sent for revision (think of the main branch), I could receive the version from other parties (kind of like feature branches), turn on Word changes, paste the complete content of the original, and we could visualize the difference.
It's been more than 10 years since I stopped dealing with contracts, but I imagine a lot of lawyers, specially older folks, are still either doing very convoluted processes to track changes like me or not even bothering most of the times.
The article is spot on on the issues (even brought back some memories). This is something I'd use for sure in my previous life.
Inherent in contracts are so many assumptions based on historical precedent, hacks to work around vagueness, etc. that to achieve this would require a rewrite of global legal systems, including centuries of case law.
Even getting a lawyer to change one word of a contract clause that's been in use for decades is a challenge (because to change anything would be to erase all known jurisprudence about that clause's interpretation, creating risk where formerly there was none).
But to upend the entire legal system to make contracts verifiable (which they could never be anyway thanks to the imprecision of human language) would be herculean.
EDIT: For example, consider the phrase "best effort." If you had to express that logically in order to make it verifiable, you'd have so much expensive negotiation about what "best effort" actually means. Presently, it's determined by a jury if there's a lawsuit in the future, where the jury relies on their own personal experience and expert testimony about the standard practices in that specific field.
Unscrupulous opponents will turn off Track Changes in MS Word to catch you off guard.
This discussion is about contracts, not legal codes. I agree with your statement, but decades now of people on Slashdot being unable to differentiate copyright and patent has made me this way, where anyone potentially mixing up legal concepts has me triggered and jumping down their throat.
<strike> is deprecated.
This kind of notation is similar but not the same as redlining. Whoever reads the law actually wants `git history` in this case. The diff is not a means to an end (a fully edited document), having the diff explicit is the end goal.
I used the papertrail gem to track changes to the contract object and provided diffs and commenting and then allowing collection of digital signatures (Docusign was pretty new at the time so we rolled our own)
The founder has cofounded another one in the same space https://recitalapp.com/
IANAL, but this was a key step for me as well. If you maintain copies of the versions sent out (and modified copies sent back), you can always get a clean diff of the copy sent out versus the copy sent back, or of an earlier version versus a subsequent revision.
The compare/combine tools in Word aren't great, but they are functional. Kind of like a local maximum, I suppose.
i’m so sad about the shithead influence of microsoft on our society.
No, quite the opposite. Too often developers tell users what the developers think they need with little to no understanding of what the users really want, which is the parent comment's point.
Meanwhile, as another comment in this thread noted:
>Git is a tool built around the needs of software developers. Because git is too complicated and branching, though in principle, would make sense in some situations, is actually pretty difficult to manage (especially for binary documents).
Every alternative I've seen proposed, especially by non-lawyers, has been far too complicated for our needs and attempts to tackle problems that really aren't actual problems in real everyday practice.
It often seems like developers in this space speculate on theoretical problems they feel lawyers must face and create solutions a programmer would appreciate for those.
> Big flaw in the product: 60 year old partner who still makes hand edits and has the Secretary scan the pages and send them out of order to the associate
> Second big flaw in the product: specialists edits get rejected because they don’t know the deal points and are just swooping in
I took issue with this as step 4 seems to involve an M&A lawyer accepting/rejecting specialist edits piecemeal, to which he responded "Right, but that doesn’t actually save that much time. It’s the same work that an M&A associate is already doing"
> Third big flaw in the product: big law firms are the least innovative organizations on earth
> Fourth big flaw in the product: having junior associates do menial tasks at $800-950/hr is a feature, not a bug, of law firm business model. So you are solving for something that the target customer doesn’t necessarily want solved.
and there it is :/
https://decoded.legal/blog/2023/06/but-lawyers-know-nothing-...
https://news.ycombinator.com/item?id=36510439
https://news.ycombinator.com/item?id=13446275
(https://jduclos.com/notes/github-for-lawyers is dead but several versions can be found on Internet Archive)
The best interaction is on Google Docs which is somewhat ok, definitely better than sending some docx back and forth. The main friction seems to be that very few things beat email attachments, no auth to fight with.
Wish these folks the best.
My partner worked as a veterinarian for several years, and it was fascinating to see how vets use computers. These were brilliant people - I knew three who did literal brain surgery. But they just had zero patience for computers. They did not want to troubleshoot, figure out how something worked or dive deeper. Ever. They didn't care! They were busy saving the lives of people's pets.
It was a good reminder there are many smart people who do not know computers work and do not care to. A good startup acknowledges this reality.
- Many [ / most? ] law firms have a large, overly-complicated "doc database." These have Word plugins, and they're usually required to 'check-in' each version they prepare prior to sending out. This seems like a very natural point of attack for a dramatically superior git-esque solution.
- Most lawyers / firms have a massive distrust of cloud-hosted tools. I've heard "well, Google can read everything in Google Docs!" more times than I can count. Maybe the public is better educated now, but... maybe don't count on that.
- Toolset for bundling up *ALL* edits compiled by one side, having these "merged" and some sort of formal "approved to send" step would be huge.
- Please continue to track which person made every edit, when, and ideally, if said edit was "merged" and "approved to send" to counter-party.
- Over-invest in super easy UX & eye-candy: you're trying to overcome engrained use of a tool that's about as ubiquitous as the air we breath -- you're going to have to deliver 10x value, and ease-of-use will be critical for adoption. The current demo, and dragging links between boxes.... well, imho, perhaps not quite there yet.
- Finally, I've worked inside MSFT publishing docs & books, worked on hundreds of contracts in biz-dev & corp-dev & investment banking, and please let met state very clearly the need for this product is overwhelming. Please please please build this, and wish you all the luck in the world.
PS: Contractual.ly was pretty great. Wish it had caught more traction.
Happy hunting!
We've designed our product to be backwards compatible with existing workflows. It does not require every team member to use the product to add value. Partners who prefer their way of doing things can continue to do so allowing associates to add their drafts to Version Story to create redlines and consolidate changes.
>specialists edits get rejected because they don’t know the deal points and are just swooping in
The possibility of incorrectly rejecting specialists edits exists with or without Version Story. Our product makes it easier to understand what's changed so lawyers can exercise their judgement about these decisions.
> Third big flaw in the product: big law firms are the least innovative organizations on earth
I think this assumption is worth challenging. Millennials are becoming partners at law firms and are spearheading initiatives to update their tech stacks. This is reflected in legal tech budget growth trends (https://www.legalcurrent.com/tech-spending-remains-especiall...).
> Fourth big flaw in the product: having junior associates do menial tasks at $800-950/hr is a feature, not a bug, of law firm business model. So you are solving for something that the target customer doesn’t necessarily want solved.
Making mistakes is not a feature (https://newsletterhunt.com/emails/40489). In the example I outline in the essay, the lawyer made three separate mistakes when manually merging documents.
But later, about 9 months ago, Chris Krycho published this lovely blog post[1] about jj and a thread about it was quite popular on HN. Again, really interesting, but not something I was going to dig into.
Finally, I come across this post today and it occurs to me that designing a project like this for lawyers is probably pretty challenging with git as the backend and I'm sure Jordan could use whatever the state of the art in VCS is. I hope they take a look at jj and consider it as an alternative backend. It seems there's an entire team of engineers working on jj at Google now full time.
Steve Klabnik wrote a beautiful book style tutorial[2] about getting started with it. Hopefully it inspires someone else to take a look!
[1]: https://v5.chriskrycho.com/essays/jj-init/
[2]: https://steveklabnik.github.io/jujutsu-tutorial/introduction...
Sometimes you automate something because you want to do it faster / cheaper. Sometimes you automate something because you need it to be done _correctly_.
I would much rather my critical but menial $900/hr task be done by someone double-checking automated work than the same amount of time being spent doing the menial work.
You could even introduce flaws (in the review step) to catch if you're concerned about the human getting bored and just automatically mashing the "merge" button...
There was a freakonomics[1] podcast about mechanical support of human activities...
[1] https://freakonomics.com/podcast/new-technologies-always-sca...
So my "copying current version changes" to Excel was kind of like git merging to the main branch.
People from outside the craft usually get super confused and frustrated by how many hours those contracts could take ("it is just a Word document!"), but that used to be a huge reason why.
You've got some bleeding edge lawyers if they're using Microsoft Word. The legal industry is one of the main reasons that WordPerfect continues to exist.
LaTex is just ugly and surprising. People want to write and see what they've written, not type and then render. It's a backwards development workflow from the instant feedback of wysiwyg (which is why wysiwyg was so revolutionary, and became the de facto standard for the task).
1. Lawyers don't want everyone holding the pen at the same time. Specialists want to make their changes and have them reviewed in isolation from other's changes. Think of a redline like a pull request. You don't want other people's changes in your work when it's getting reviewed.
2. Google Docs breaks down when even a single person drafts outside of it. See the section of my essay about why lawyers will never stop using Word. Even if you managed to get an entire firm using Google Docs, it still wouldn't work because they need to exchange drafts with external parties.
Git for normies already exists even MS Word has document versioning. If they cannot be bothered to use the software and technology they need to then they should be unemployed.
Also, the billable hour is somewhat misunderstood. It is more of a process tool than a hard reality. Repeat clients expect the bill to end up within a certain range. And law firms expect their people to work a certain number of hours.
(To other commenters, this is not an invitation to dunk on Apple. Please keep discussion on track)
- User actually drawed the screens he wanted, presented to the developers. After a short discussion, one dev added column sorting to a table. That was enough. The user wanted to be able to sort, ended up hallucinating a lot of convoluted screens. He wanted to make a toast but was asking for an oven.
- Users would oscillate between wanting to increase the table height and wanting to decrease the table height. Some of them wanted it bigger, some of them wanted it smaller. It took a while for everyone (users and developers alike) to notice what was happened and realize what we really needed was a resizable table.
Those are small, uncertain requests. The user needs to do something and _believes_ it knows what he wants, but can't communicate or relate his needs to the developer team. Or the developer team is unable to gather specific, real requirements from these small requests. It happens in larger teams too, but often for different reasons (oversight, lack of attention due to multitasking, bureaucracy).
If you work enough as developer, you'll eventually experience this kind of disconnect.
As a dev commit/push/pull is trivial, but may God have mercy on the veterinary who needs to do a complex conflict merge across branches.
If most devs are confused then imagine vets.
The DMS providers have a great business and their product is stickier than glue. Fortunately, they are very startup friendly and have built out a whole app store ecosystem so other companies can layer on new capabilities that deepen the value of the DMS and make it even stickier.
For example, I was talking about veterinarians. They need to type records into a web browser, but that's about it.
Veterinarians spend their time learning about things far more valuable to them. For example, which painkillers are safe to use on a cat recovering from surgery, or how to precisely drill into a dog's spinal cord to remove a fluid buildup that's robbed it of the ability to walk, or how to stabilize a dying animal in the emergency room.
These are the least "dumb" people imaginable. They do not need "upskilling" - they went to four years of medical school. They have more important things to do than figure out computer arcana.
FTFY ;)
Computers are just another modern convenience. We need to be making them more user friendly and safe. Nobody wants to spend all their time learning, maintaining, and fixing their computers any more than they want to do that with their cars.
They should just work, without surprises.
- It may be that, as in the example, you have an associate who is mindlessly merging others' changes into the master document. But the hope is that the associate is also thinking critically about the changes as they are merging them, picking up on things like "this probably won't work, I should flag it for discussion", "if we change this clause we'll also need to make consequent changes to that other clause", or even just typos and syntax errors.
- In addition, the hope is that the associate is learning while merging the changes. They are gaining familiarity with this type of contract and the kind of points that tend to be discussed/negotiated.
- If you don't have many specialist teams that you need to work with, you can just ask them to put their changes in a new version (ie, do it synchronously).
- That said, there are definitely arguments for replacing this internal workflow with a fancy new collaboration-focused platform. I can't see it replacing the legacy workflow when actually negotiating deal documents. When I trialled similar software in the past, the way it was presented to me was that we would need to get our clients, counterparties and their lawyers, etc to access the document through our instance of the platform. Which just seems like a non-runner to me.
- It is well known that lawyers are very slow to adopt new technologies. However, I can say from experience that a lot of the software that is peddled to lawyers is awful. Like, stuff seems designed to work well and look great in a demo, but as soon as you start using it in the real world you run into all sorts of edge cases where things don't work properly, you get obscure error messages (that are often just stacktraces), etc. Of course I'm not saying the software in the article is like that but a lot of lawyers have been bitten by botched software transitions and are reluctant to move from what they know as a result.
Juro and others make the other guy onboard because that limits the scope of the engineering problem. You can only create what the platform lets you create, so you know in advance what the system needs to handle. This approach makes it easier to build. But the problem is that it is really hard to get the other guy to onboard. As a result, your MVP is not really an MVP.
Our approach required way, way more engineering work up front. But it put us in a position where getting the other guy to onboard is a "nice to have", not a requirement.
> It's a backwards development workflow from the instant feedback of wysiwyg
No it isn't. I've already explained this in my original comment, and you've provided little rebuttal here. What is the value of instant feedback? As far as writing documents, there is none. That's because the people who write documents are interested in the text, which they get instant feedback on in their text editor. They don't really care how it looks while they are in the process of writing it. Instant feedback may be useful if you are interested in styling a document, but usually style sheets are prepared once and reused many times. Documents are not like computer programs, you typically write the entire thing out then compile it once or maybe twice to fix typos in command names. Even if you think instant feedback is intensely valuable, there is no reason you can't have it in the case of LaTeX (or LaTeX adjacent) documents. Simply design your document editing software with two windows, the one on the left shows the textual source, and the one on the right shows the compiled document. These can be kept in sync in real time.
If you don't have at least some knowledge, you probably won't be a very good inspector. If you have more knowledge, then you'd be better.
If you require document versioning, you should know, at least a bit, how to use a Version Control Software. You don't need to know the internals, but enough to use it.
To me, saying that change tracking in Word is fine when you've never seen anything better is kind of like someone 60 years ago saying, "A typewriter is fine, and everyone I know agrees. All these software people are trying to solve theoretical problems with word processing software."
You might not agree with particular solutions you've seen for improving change tracking for legal documents, but I'm surprised you don't see room for improvement in change tracking.
From my experience as a client who had to participate in the process, I saw lots of issues:
First, it's super slow. A large document with lots of tables and lists takes 20+ seconds to load. Searching is also much slower than it should be.
There's a ton of noise. When I was reviewing documents, 80% of the changes that showed up as redline changes weren't real changes but were just formatting updates (e.g., page renumberings, section renumberings). It made it hard to find the real change vs. just formatting changes.
The changes are all in separate files rather than having a single tool that can show you each version in a single place.
The Word doc supports inline commenting, so it's helpful for each side to be able to discuss it internally within the doc itself, but then that creates the risk that you'll accidentally share a version with the opposing side that includes private notes. As far as I know, Word doesn't have any way of making this safe by default. Rather, it's on the attorney to remember to scrub private information each time before sharing it with the other side.
I think there are two principles at play here. First, I suspect that veterinarians that go into practice as a whole prefer physical manifestations of their intelligence rather than abstract intangible prizes. This is similar to my story of starting vet school after doing bioinformatics.
Second, computer tinkering is similar to shade-tree mechanicing. I drive a car. I even know how to change my oil and can look up how to replace the alternator if I need to. I don't get much satisfaction out of working on my car, though, so I outsource (when I can afford it) to allow me to focus my time on things that drive my professional life forward or are pleasurable.
Add to these that current vet medical records software sucks, and it leads to extreme impatience, and even an expectation that computers don't work, and the cycle continues.
I've actually worked extensively on audio hardware and software. The mixer slider is there because audio engineers don't benefit from having to type in a float value for gain and need to adjust up and down to balance levels. That said, most effects that affect perceptual loudness have an autogain feature such that the mix fader doesn't need to be changed because of the complexity introduced.
A better example is routing in audio software. This is way more complex than users imagine it to be, and that's because the interface is a simple "connect input to output" that abstracts the underlying complexity.
> A simpler interface is only achieved by making assumptions about how people will use the product, and these assumptions often cause issues for people.
No, it isn't. That's why UI/UX is a different skillset than engineering - discovering how to intuitively present something that isn't complex (note: the complexity of the problem is not the complexity of the interface - if you equate the two, you're doing bad interface design).
> What is the value of instant feedback?
I see what I want and move on instead of fiddling around.
> Simply design your document editing software with two windows, the one on the left shows the textual source, and the one on the right shows the compiled document. These can be kept in sync in real time.
There's a difference between "can" and "should." Now you have to look two places - where you are editing, and where it is rendering.
Like I don't know why software folks are so keen to throw away 50 years of HCI research that's led to local maxima in terms of interfaces - WYSIWYG is not preferred because it's easier to develop or maintain, it's because users actually find it easier than remembering how to invoke the exact sequence of characters in a document to get what they want!
you could restrict their software movements to the bare essentials for their work and they’d be happier for it. hell, i’m sure most would be happier with no gui if the interface provided them with only what they need. and most need just a place to create a document, type it in, commit the document, view it, and relay it to storage or another user. then a browser to look things up.
but we live in the age of general-purpose computing where people need to use general programs thoroughly unadapted for their specialized jobs, forcing the user to coordinate multiple contexts, which should really be coordinated by the machine. most jobs could be done with nano and sendmail. add an form input field editor and selector and it’s golden. if something else is needed, it should be one command away.
it’s not for them to inspect computers. it’s for devs and enterprises to create software systems such that the tech-naive user would have no need to ever touch anything outside of what they need.
Although the country where I am in doesn't restrict me from vaccinating my pet by myself, I'd rather just outsource it to a vet. vet clinics here also have added facilities like pet cleaning etc which is a plus . In this case I find I'd rather enjoy my pet than figure out its innards or it's anatomy.
I have extreme doubts about that. Yes, people find these things easier when they don't understand them, but what about users who do understand? I know for a fact that when I started out programming, Scratch was very easy. But as I became better, the GUI aspects that made it simple became hindrances. I sincerely doubt there has been any research done on this at all, because it simply isn't feasible to ask someone to spend several hundred hours practising something over the course of a study.
> Now you have to look two places
Many pieces of software present more than one piece of information on the screen at once, and the only way to do this is to put that information in different locations. The idea that you need to look at both is a little silly, because you don't need to know how a document will be styled to type the text of it in.
> WYSIWYG is not preferred because it's easier to develop or maintain, it's because users actually find it easier than remembering how to invoke the exact sequence of characters in a document to get what they want
Well I am a user, and this is not true for me. My mother has always been horrible with computers, but she worked as a secretary when early document processing software came on to the scene and she managed just fine typing the commands in. "Remembering words" is not a difficult activity. You remembered many hundreds of words to write that reply and I doubt you found it challenging in the slightest. Learning words is difficult, but once you have learned them, they are easy to remember.
When I've seen professionals using software, they tend to avoid the GUI. Users remember many hundreds of key shortcuts (much harder to learn than words as they're just arbitrary letters) and do everything in their power to avoid using the GUI for anything, to the point where many people who do things such as video editing have an entire extra keyboard for entering auto-hotkey scripts. Advanced users are not only capable of learning, but actively prefer it to using a GUI.
Users who don't know the functionality of software want some simple way to have it all presented to them. But users who know what the software is capable of find this to be a drag. They already know the command they want the software to execute and so want to have the simplest possible way to communicate that desire to the program.
-Robert A. Heinlein
A computer is a tool. I don't expect them to know everything, but I do expect them to know a little.
Who cares if it's electric or ICE, how combustion or regenerative breaking works, why you need to balance tires, how to change brake pads etc. I take it to the mechanic (IT Department) and they do magic, then give it back to me.
Same for computers. Why does the user need to know about USB 2 vs 3, memory, disk space, multi-threading, ad blockers, etc. Turn it on, use it, and send it out to be fixed when it doesn't work.
Ive started realizing that specialists who lack general skills like computer knowledge o the ability to learn things outside of their domain as needed are themselves tools.
If you can't understand things outside of a very narrow slice of specialization you're just a tool to be used by generalists.
If you hired a driver which would you rather hire, the one who knows which grinding sounds that a vehicle makes are good/bad or the one who just keeps using it with disregard for the grinding sounds because it isn't currently inhibiting their ability to drive?
Git can compare binary diffs like Word files by using custom diff drivers and external text conversion tools. Git allows you to configure a process where these files are converted into a readable format for diffing.
Define a custom diff driver. Create or edit a `.gitattributes` file in your repository and associate Word files with a specific diff driver, for example: `*.docx diff=word`. Then, configure Git to use an external text conversion tool for this driver. This is done by running a command like `git config --global diff.word.textconv "your-conversion-command"`, where `your-conversion-command` is a tool or script capable of extracting text from Word files.
`pandoc` can extract text from Word documents, and you can configure it by running `git config --global diff.word.textconv "pandoc --to=plain"`. Another option is `docx2txt`, which can be set up with a command like `git config --global diff.word.textconv "docx2txt.pl -"`.
Running `git diff` on Word files will pass them through the configured conversion tool and display the differences in their text content. This approach is ideal for comparing the textual content of Word files but doesn’t account for formatting or binary-level differences. If you need a detailed binary comparison, you can integrate an external diff tool with Git by using `git difftool`.
Could it be better? Sure.
But the alternative would have to be absolutely amazing to justify the expense of an additional tool and the time spent learning the intricacies of said tool. Word is already good enough at covering the bases that it's almost impossible for an external tool to be worth it.
There's a ton of noise. When I was reviewing documents, 80% of the changes that showed up as redline changes weren't real changes but were just formatting updates (e.g., page renumberings, section renumberings).
These are real changes. Citations are important for lawyers. For example, in an M&A deal, language in the contract will very frequently refer to another terms, conditions, or other language in another section of the contract. This makes it imperative to be able to track section renumberings, because those internal references matter. (Word does have the ability to create internal cross references that will automatically update when sections are renumbered, but not many people know that this functionality exists...or that it has been part of Word since at least Word 2000.) Also, bold, italics, and other emphasizing formatting can have a semantic bearing on the interpretation of contractual language. They may not be significant to you but they are significant to someone.
As far as I know, Word doesn't have any way of making this safe by default.
This is the same risk you would have with any comments stored within a document shared with external parties. The solution is not to become dependent on an additional tool; the solution is to build it into the process by having an attorney or paralegal spend 5 seconds to scrub the document using the built-in Word tools designed for this task.
It doesn't really solve the problem of these formats not working well with collaboration and sync tools, but it would probably be good enough for some use cases.
Building easier tech creates jobs for engineers, and saves the time of the people who are willing to do the stuff that's way harder than engineering.
It probably makes things cheaper for people trying to save their pets too.
But priorities are also important, and some skills can only be learned by doing. Which is often unpleasant, expensive, and dangerous, and time consuming.
Some stuff has a very low chance of directly being needed. I've never written a paper check. I could probably Google how to balance accounts if I had to.
Vets should have a little more tech skill, but software should be a lot easier.
Excuses are excuses and shouldn't be tolerated.
in practice... google docs and libreoffice still have formating and vcs compatibility issues. To an amateur it looks fine because both systems claim to support docx and will open/write files. To someone who deals with a lot of documents... let's say it caused enough issues where it didn't pick up or properly delete microsoft word's proprietary track changes to where our lawyer just offered to personally buy me an official microsoft word license to avoid the back and forth. Actually, that was when i was already using the web-based microsoft365 word online! the codebase for desktop word must be deep deep spaghetti.
if you think you can solve what Google hasn't in 15 years despite many dedicated resources, or the entirety of the FOSS efforts over 30 years for libreoffice... that would be literally incredible
An example I've been running into myself lately has been trying to get a portrait photography workflow running with only FOSS tech. I've been fighting with darktable and libgphoto for months (and even tried submitting patches!) and tethered shooting still doesn't work right. I could continue sinking time and energy into this, but at the end of the day I just want to shoot tethered to a laptop, a basic function of modern photo editing systems.
I had more time when I was a student for learning how new systems work, but between full time work, the admin of being an adult, maintaining various relationships--I don't have the resources I once did, and I'm content to consider solving them someone else's problem.
The reason I go to my vet is so they can "troubleshoot" my pet. I don't have the expertise to do so myself; why would I expect the reverse to be any more true?
If you cannot operate the vehicle you need to do your job you don't have that job. I'm not saying that people need to be experts. I'm saying if you cannot learn the tools needed to do your job then you shouldn't have the job.
I shouldn't.
And nor should it. The workflow is awful for anything but software development (and even on that, views differ). It is unsuitable for versioning binary blobs. It contains dozens of footguns that routinely catch out software engineers who use it all day, every day.
I assume that if you're not a cellular network engineer, the answer would be "very little".
They have a workflow that works just fine for them, and if they don't, they already have an abundant market of tools suited to their field that they can just go out and buy if they wish.
Also, starting with menial work is how junior associates are trained to do more complex work.
https://www.loom.com/share/a4c5f5bf035c43938b342361154b6753?...