I'm not a programmer, please forgive me, but I love using sublime as of writing tool for legislation and public policy in my work. The color coding system popular in programming, has been invaluable in drafting legislation.
super interesting!
I'm thinking out loud: could be possible that there is niche waiting to be untaped with new tech–tools for lawyers (and others professions)?
Edit:
I mean, no high–tech, but tools with a higher level of complexity where the UI isn't a dumbed down version, and where the software exposes some functionality to a better skilled user.
I'm thinking the "millennial" professional, should be more comfortable with software and pushing the limit a little bit.
I'm a third year law student (well, my last day was this week!), and I've been using Sublime to take notes and outline things for class. I use a custom syntax highlighting (modified version of the markdown syntax) to make it easy to read.
It is common for law students to digest course material into a short-ish (20-30 pages, depending on the class) outline of the material, as a way of studying. With my modified syntax highlighting config, I use different color bars to represent different level headings to make it easy to see how my document or outline is organized.[1] I then have a latex template for pandoc which lets me convert it to a beautiful document that is useful during open-book exams.
Using Sublime as a WYSIWYM editor is much more pleasant, as the editor is far more responsive, than using a WYSIWYG editor (like MS Word). I actually recently wrote a paper for class entirely in Markdown in Sublime. Pandoc lets you convert markdown to PDF (it uses latex internally), and when you convert to docx format for Microsoft Word, you can use a reference file to define the style formats. It's really easy to write something like a brief or a memo and convert it with a reference file to a format that others can work with, properly styled.
This is pretty neat. As a programmer, my editor not only color codes, but it gives me sort of hyperlinks to other definitions i am using/referencing, both to others work and my own. It also provides me hints and help about the current context i am writing about (working in), and it is often very relevant to what I am currently working on. that help is invaluable.
I'm actually building a note-taking webapp based around Markdown! I was wondering what features you found lacking or wish you had with your setup? (and if you'd like to try it out feel free to dm me)
I desperately want git-style DVCS for complex contract drafting with multiple contributors. It needs to handle a Word docx file natively, so it'll me do blame on a line, merge changes, all that good stuff, as well as retain proper version control so I have one file on my drive instead of a hundred variants of v1_changes_final.updated.doc.
There is no reason why plain text wouldn't work. You have something like Pandoc (with a markdown type text) convert the text to your format (Word docx for example or a PDF).
Difficulty there is collaboration with various groups that are completely set on Word. Some of those groups are external: in most cases contract format is dictated by the client and that invariably means a Word document laid out in their specific structure with tables for deliverables and subheadings and boilerplate and the rest. Reverse-engineering hundreds of those things into something Pandoc can spit out is a giant challenge and likely a bit fragile. Then you have internal legal function which uses Word and various workflow plugins to do their job of sense-checking all of it.
The obvious suggestion would be to have internal groups (excluding legal) collaborate on some common plaintext markdown format where DVCS tools would provide an advantage, then publish to docx and hand over to legal for review. Unfortunately what always happens is that major changes to the contract are needed after legal has done their work, and it's easier (and acceptable) for all groups to work on the final paper together. That's where it breaks down.
I really feel that in 2016 having some poor bastard do clerical coordination of this stuff is just wrong. It's a mechanical task that's highly both error prone and a major source of operational risk, and it should be doable by the computer.
I actually kind of want to build this. Word (and the rest of office, I have the same problems with spreadsheets and powerpoints) plus plugins as the IDE, solid version control in the backend.
Why exclude legal? Understanding a commit graph isn't too technical.
As far as I know, passing docx files back and forth is more similar to working with git than a google doc, so the workflow also wouldn't be dramatically different.
If it was a "web" app and people approved of PDF files that are of a certain version it could track changes based on responses back from the PDF approval process.
Through git and pandoc in the background and put a UI on top that is idiot proof and boom.
The funny thing here is that, if people wouldn't rename the document, Word handles change control natively (including comparison of versions). You can also do it with documents named differently, but the bad habit of baking each file differently really makes that a mess.