4 ms·

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

by swalsh 10y ago

Jtsummers 10y ago
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.
- swalsh 10y ago
  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.
  - Jtsummers 10y ago
    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?
    - jolux 10y ago
      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.
      - zekevermillion 10y ago
        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.
na85 10y ago
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.
- zekevermillion 10y ago
  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.
  - na85 10y ago
    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?
    - zekevermillion 10y ago
      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.
- leohutson 10y ago
  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.

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

by swalsh 10y ago

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.

swalsh 10y ago
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.
- Jtsummers 10y ago
  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?
  - jolux 10y ago
    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.
    - zekevermillion 10y ago
      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.

na85 10y ago

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.

zekevermillion 10y ago
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.
- na85 10y ago
  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?
  - zekevermillion 10y ago
    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.
leohutson 10y ago
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.