Hacker News Reader

Comment by zekevermillion | Hacker News Reader

The problem I see is that it is very difficult to improve user tools when the users (such as myself) are stuck using the wrong abstractions. I'm a corporate lawyer, and the #1 and 2 tools of my trade are Word, followed by Acrobat. Typical process for negotiating a contract is to save new versions in .docx and run "legal compare" in some tool such as DeltaView or Workshare to show change dif between versions. This snapshot dif is then emailed to the people who need to see it. This is a relatively powerful abstraction for a limited field, but is hard to adapt. There is no feedback mechanism between users and developers of these tools. So they basically do not improve, and actually the experience of using them has only gotten worse with time for everyone involved. So the immediate benefit to switching philosophies is zero, though the long-term benefit is huge. But how do you overcome this initial starting friction?

View on HN

Actually, going on my other post, this isn't as limited a use-case as you might think.

Anyone doing contracts, requirements documents, writing/editing cycles could use something like this with varying additional capabilities.

With no change to philosophy (still staying on the user side), a system could be made based off the principles of existing software.

You need some workflow management software + a document store. The document store needs to provide rich text editing, and the ability to edit only specific sections in parallel. "section" is a customizable unit depending on the type of contract. Could be paragraphs, or larger logical units. Part of the workflow management is kicking the contract back and forth between you and your collaborators and the other stakeholders. At various stages it's editable by different people, some stages are just for review (not edit), finally various sign-off stages.

It's pretty typical of requirements document databases. You'd need it exposable to third parties outside your company, and you'd also need confidence in privacy and security. Neither are trivial, but neither are impossible.

The software for your needs literally exists, but isn't marketed to you. It's too costly for smaller offices (both licensing costs and management costs), and would require a good sales pitch because, well, people don't like change.

No one has yet managed to build the workflow management that is needed for this. The best efforts I have seen to date are Docracy and Contractual.ly. But neither quite got it right. It is an interesting problem, and seemingly straight-forward to solve, yet it is a graveyard of failed attempts so far...

Is the workflow uniquely complex? It was never my job but I've seen (trying to remember what we used) some pretty complex workflows for handling requirements documentation, testing, and code development (reviews and such, specific tasks handled in JIRA) handled pretty effectively. Would've been one of the Telelogic (now Rational) tools.

I doubt the workflow could be any more complex than what you have seen. In many ways, it should be less so. There are some nuances, however. Partly the problem is the extreme egos involved in many business negotiations. Every communication sent has to help the sender to look good. There has to be a bias against publicizing changes before the author is done. There also has to be flexibility to override approvals. A lot of big deals would never close if someone had to take personal responsibility for waiving closing conditions that aren't satisfied at closing.

Regarding hiding changes until they're done, that shouldn't be in feasible except that you (or your counterpart) may not want to use a system owned by the other, because you lose that guarantee. A third party hosting it could offer that (naturally), but takes on extra liabilities with securing the documents in progress.

You should try putting the text into git, has all those tools built in... plus a lot more, and no emailing.

Which gets to the post (so I assume this is meant ironically/sarcastically?), steep learning curve of numerous tools.

What lawyers (specialists in their field) and others negotiating contracts could use is a subset of git, with better UI.

They need version control of the document.

They need to know who can edit it at this stage, or who needs to sign off (workflow management).

They need to know who did edit it.

Systems like this exist that are better than git, some people in the software industry use requirements tracking databases. These are almost literally what's needed once you (often included in them) add on the workflow management: collaborative document editing, ability to view diffs, knowledge of who edited it, restrictions on who may edit it and when, etc.

But if it's too small a field, or too disconnected from those of us who can make it, then software like this won't be made or widely used and they'll continue using the functional (but error-prone) method of copy/rename and email.

It started off a smug joke, but in all seriousness... git/github is the PERFECT tool to store legal documents. Pull requests have clear documented changes. Documents can be forked, different lawyers could work on the same document, and merge changesets whatever. Everything programmers do to source code, lawyers do to law documents.

I agree. But it still has the problem of:

They need to learn a new document markup (how well does word play with git for grabbing diffs?).

They need to learn git/github.

It needs to be secure (these are legal contracts, potentially containing detailed information that doesn't need to be out when it's in draft and not signed). This is fine, host your own git repos, but that's an additional technical cost to the company.

It is, ultimately, still an ad hoc process. Is the cost of learning and adapting to this, to only gain the version controlled document store, sufficient to justify the process? Across an industry?

It probably wouldn't diff terribly but the markup used in .docx is extremely verbose and not really designed to be human writable the way say markdown is. Most users don't see formatting as markup, because as far as they can tell it's WYSIWYG and stored that way. The idea that content and style can even be separate is very foreign for lots of folks, let alone that the representation on disk is text without style.

Ideally the markup would be limited to section numbering (need more levels of nesting than md or html offers) and definitions. Then once a contract is finalized you could apply fancy styles before printing a closing set.

I have family who are lawyers.

They and a great many of their colleagues can barely type without looking at the keyboard. You're suggesting that the kind of person who still double-clicks on hyperlinks can learn git?

I'm an aerospace engineer and I can barely use git. Git's UI/UX is a fucking disaster that just happens to suck less than what came before it.

I think you would want to combine an open source toolset with a paid service with trained monkeys to bridge the gap. For instance let's say I send a draft out, and receive a PDF markup back. The trained monkey would make sure that the new version is accurately reflected in the repo. As long as I am working natively, then exporting my response back into whatever lame format is desired will be trivial. It's a bridge to a better world and more elegant system.

The engineer in me hates how inefficient that is. Also it smacks of a make-work project... paying someone to manually insert markup seems like a huge waste of money.

Surely it'd be cheaper in the long run to just spend the money on some UX designers?

I think you need a human to manage the import bc any OCR or conversion error could kill the whole experience. Hopefully rhe machines could get us 90 percent of the way there. You know law firms used to employ armies of typists to prepare manual (pencil) difs of paper docs, so there is a certain cultural willingness to pay for perfect results, particularly on larger transactions.

Git is not great UX wise, but it's probably not as big of an issue as people like to make out, especially if you are already comfortable in a shell. The reason people find git hard is that concepts of distributed version control are hard.

There are plenty of nice git native GUI's and web apps, and mercurial offers a more consistent command line UX, but that doesn't change the fact that people need to understand a crap load of higher-level concepts before they can find their DVCS useful. Such as:

file-system folder structures

diffs/patches

commits/uncommited changes

branching

merging and conflict resolution.

remote vs local repositories

To me it's like how people complain about mathematical notation being complicated and inconsistent, but that's just the first superficial "alien" looking stuff that tells you that you don't understand the new concept. Once you understand the underlying concepts, the notation doesn't get much further thought.

>The reason people find git hard is that concepts of distributed version control are hard.

Maybe. For me it was because the documentation is written like a comp sci whitepaper. I've ranted about this elsewhere on HN but the man pages are filled with stuff like "update remote refs" as if a person would have a fucking clue what a ref is and why you'd want to update a remote one.

Branching, merging, tagging, all of that sounds great. I've been using git for years, but the problem is that I don't use it every day, and so I still get a little wary when I want to run a merge. I can't tell you right now off the top of my head how to merge if there is a conflict. I always have to google around for "how to undo a commit". Etc. etc. etc.

Where the fuck do my files go when I switch to a different branch? Do they actually change in the working directory? Checkout vs fetch? Where exactly in the file system is this alleged "staging area"? I have no idea about any of these, mostly because the documentation is just so poorly written that it takes me too long to find out the answers and I have more important things to do than Greco-Roman wrestling matches with my software tooling, but I'm afraid that if I just try things at random I'll do something I can't undo because none of the options seem particularly intuitive.

It's just not a very good piece of software.

Software is good , your mental model of it is bad. Trying to put the squre peg of git into the round hole of filesystem is bound to produce frustration.

> The reason people find git hard is that concepts of distributed version control are hard.

Have you ever used Mercurial?

You get together with a few others, and figure out what's wrong with the current tools, and how they could be better. Then you figure out if people would spend money for better tools. If so, you've got a niche startup.

I have some strong ideas about what's wrong w current tools. I would love to work on this as a side project but I think it needs to stay non-proprietary if it's going to be any different from current, reasonably usable enterprise tools.

Reply on news.ycombinator.com