5 ms·

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 law

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?

swalsh 10y ago
You should try putting the text into git, has all those tools built in... plus a lot more, and no emailing.
- 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.
AnimalMuppet 10y ago
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.
- zekevermillion 10y ago
  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.
Jtsummers 10y ago
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.
- zekevermillion 10y ago
  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...
  - Jtsummers 10y ago
    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.
    - zekevermillion 10y ago

swalsh 10y ago

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

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.

AnimalMuppet 10y ago

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.

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

Jtsummers 10y ago

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.

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