Show HN: Version Control for Microsoft Word(simuldocs.com)
simuldocs.com
Show HN: Version Control for Microsoft Word
https://www.simuldocs.com/blog/ben-morris/version-control-for-microsoft-word
117 comments
This is interesting, but what's wrong with "Track Changes"? (a feature Word had for at least 10+ years now).
I believe for most people that is more than enough for version control purposes.
For tech people that actually know what Git is and how to use it, I bet they'd want real Git integration, or they'd choose to store the document in a different (more easily managed by Git) format such as .md or .html.
It doesn't scale. E.g. a common operation in a law firm is to send a draft of a Word document,[1] to several people for revisions and comments. You get back several redlines against a common version that some junior associate then has to integrate manually.
[1] It has to be a word document for integration with tooling that does stuff like generating tables of authorities and whatnot.
[1] It has to be a word document for integration with tooling that does stuff like generating tables of authorities and whatnot.
the built-in 3-way merge tool will do that... just set it up to be called from your favourite VCS.
z:\presentation\2017\Skyscraper.doc
z:\presentation\2017\Skyscraper.doc.final
z:\presentation\2017\Skyscraper.doc.final.legal_edits
z:\presentation\2017\Skyscraper.doc.final2Couldn't you use pandoc to convert Word doc to a git friendlier format for comparison?
But then you still have to do all the editing manually in Word (unless the pandoc if perfectly convertible back to Word, which it is not).
If all you need is to diff documents (Word, Excel, PPT, or arbitrary PDFs) then I can't recommend https://draftable.com/compare enough. It's an amazing tool. Granted, you need to do merges manually with just a diff tool, but that's not usually the bottleneck.
Seems like Draftable does not support Excel files.
Office comes with a spreadsheet diff tool since 2013 and I think there might be something like that for Word too.
There is. There is also 'diff' integration with the Tortoise range of tools also (i.e. TortoiseSVN, etc).
let me guess:
- unzip the .docx file into xml files
- parse the xml into something organizable by line (csv? etc)
- commit this other file format
- in the GUI of your app, when someone selects a snapshot in time, go from the by line (csv? etc) format back to .docx
- open in word
- profit
(way back when we did this with excel, but ultimately gave up https://github.com/decisive-wizard/GridHub)
- unzip the .docx file into xml files
- parse the xml into something organizable by line (csv? etc)
- commit this other file format
- in the GUI of your app, when someone selects a snapshot in time, go from the by line (csv? etc) format back to .docx
- open in word
- profit
(way back when we did this with excel, but ultimately gave up https://github.com/decisive-wizard/GridHub)
Decades ago I had started a company to do this, for all but executable files (that was for later) and finished a working prototype that was very fast, no known issues. The prototype was limited re file size because of extended/expanded memory issues with that Borland compiler, but the new compiler to solve that had already been published. Then Microsoft announced they were bringing out a similar product. My backer pulled out immediately thereafter, and that was the end of my company. But the Microsoft product never came out, after all... good old FUD.
Most of the damage done by not enforcing anti-monoploy laws is entirely invisible, the dogs that don't ever get a chance to bark.
Most of the damage done by not enforcing anti-monoploy laws is entirely invisible, the dogs that don't ever get a chance to bark.
To me, one of the biggest problems with weird file formats is that every single problem has to be solved again, just for that. Not only that but once a solution has been created, it is probably the only option (instead of one of a dozen) because it is so much harder to do the combination of both $DESIRED_FEATURE and $PARSE_FILE, not to mention $DEBUG_QUIRKS.
[deleted]
This is a great addition for such a used tool as Microsoft Word is.
It could also help to stablish a better mindset of what version control means for non techie people.
Congratus on the release!
Is there any way to delete documents? I uploaded a trash document just to try it out, but now I can never delete it - only "archive it" which is bugging the OCD side of me
Good idea in general, but with one major flaw: no self-hosting option.
I can't imagine lawyers will be queuing up to host their sensitive legal documents on someone else's server.
I can't imagine lawyers will be queuing up to host their sensitive legal documents on someone else's server.
Why do you need admin rights to install?
this is great! congrats on this!
Unfortunately can't check it out because I get "We are checking what's changed in this version. Won't be long..." for any test docx I upload / blank docx. Maybe server overloaded?
My two cents: Congratulations on launching your product! There simply is no real good versioning system for Office files, so this is a step in a good direction.
I agree with others that ditching all the "Git" references would be beneficial, because your target market most likely doesn't care about Git. What is missing in the versioning market is exactly what you may provide: A clear way to see what has changed where and an easy way to merge things together.
I do believe that you are missing a valid comparison / valid take on what Office 365 / SharePoint Online / OneDrive versioning can give you. Your main argument against it is "necessarily want the real-time coauthoring experience offered by Microsoft SharePoint or Google Docs., this can inhibit your ability to determine who is responsible for specific changes to content". Comparing Co-Authoring to versioning is comparing apples and oranges. The co-authoring experience in Microsoft products is great! I can work on a document with multiple people at the same time and I can even see in real-time what part of the document they are working on and what they are changing. We're working with multiple people on important documents simultaneously very often and this is a life saver.
Versioning of course could be better: SharePoint only offers you a main branch and no tags. That means I can go back to a different version, also compare that version to my current version or any other version (!) - but I don't have tags or a method to know that "version 12.0 from 07:02" was the version I was looking for. However the versioning system is very robust and proven. With products such as OneDrive / OneDrive for Business or Office 365 I have said versioning out of the box plus 100 other features. I don't know whether your versioning would make me want to switch just for the additions you show.
What I can't see in your demo (and can't test myself) is how you handle complex changes and this is where the meat is. Changing fox to wolf... yeah... I have documents where all heading format changes from Arial to Times New Roman and the bullet points are arrows now instead of bullets. Also my colleague has added three images and right aligned two of my images, oh yeah and applied some pretty image borders around some images. Would all of that show in the "what has changed" view of Simul? It would show when using SharePoint versioning together with Word. Granted: I can't see all these changes in SharePoint - but Word does show everything perfectly.
Again: Love the way you are going with this. The existing versioning could be made better, but besides branches and tagging I don't see any benefit compared to regular versioning using Microsoft products.
My two cents: Congratulations on launching your product! There simply is no real good versioning system for Office files, so this is a step in a good direction.
I agree with others that ditching all the "Git" references would be beneficial, because your target market most likely doesn't care about Git. What is missing in the versioning market is exactly what you may provide: A clear way to see what has changed where and an easy way to merge things together.
I do believe that you are missing a valid comparison / valid take on what Office 365 / SharePoint Online / OneDrive versioning can give you. Your main argument against it is "necessarily want the real-time coauthoring experience offered by Microsoft SharePoint or Google Docs., this can inhibit your ability to determine who is responsible for specific changes to content". Comparing Co-Authoring to versioning is comparing apples and oranges. The co-authoring experience in Microsoft products is great! I can work on a document with multiple people at the same time and I can even see in real-time what part of the document they are working on and what they are changing. We're working with multiple people on important documents simultaneously very often and this is a life saver.
Versioning of course could be better: SharePoint only offers you a main branch and no tags. That means I can go back to a different version, also compare that version to my current version or any other version (!) - but I don't have tags or a method to know that "version 12.0 from 07:02" was the version I was looking for. However the versioning system is very robust and proven. With products such as OneDrive / OneDrive for Business or Office 365 I have said versioning out of the box plus 100 other features. I don't know whether your versioning would make me want to switch just for the additions you show.
What I can't see in your demo (and can't test myself) is how you handle complex changes and this is where the meat is. Changing fox to wolf... yeah... I have documents where all heading format changes from Arial to Times New Roman and the bullet points are arrows now instead of bullets. Also my colleague has added three images and right aligned two of my images, oh yeah and applied some pretty image borders around some images. Would all of that show in the "what has changed" view of Simul? It would show when using SharePoint versioning together with Word. Granted: I can't see all these changes in SharePoint - but Word does show everything perfectly.
Again: Love the way you are going with this. The existing versioning could be made better, but besides branches and tagging I don't see any benefit compared to regular versioning using Microsoft products.
So Google Docs? It seems close enough. What's the main advantage over Google Docs?
The addition of tags/versions is something that I would kill for in Google Docs. It would make life so much easier in my current role if we had the ability to tag a version so that you can easily see a diff between that specific, tagged version and the current version (rather than just seeing diffs over time as it is currently implemented).
Exactly this. Right now, Google Docs marries the worst aspects of version control (long, weird, unstructured, incoherent change history) and the worst of no version control at all (the need to keep creating final.v2.edited.JS_changes copies as a multi-author document evolves).
I'm fairly convinced that Google doesn't really give a shit about their apps suite. The apps have barely changed in years.
I'm fairly convinced that Google doesn't really give a shit about their apps suite. The apps have barely changed in years.
There's an add-on you can get in whatever marketplace they have. But I hate using those because it's not clear to me what these third parties can or can't see. I found it when I realized that despite Google storing extensive change history they hardly do anything with it.
I feel like I've searched pretty extensively but not found such an add-on. If you can remember the name and link it here that would be awesome.
Word is tons more powerful than Google Docs, has add-ins, way more formatting and styling. In my mind, Google Doc is not a direct competitor to Word when it comes to professional editing and writing.
Ideally, styling should have nothing to do with editing or writing. You're talking about print (or PDF/static image) publishing, I guess?
Professional firms that produce contracts and reports generally have document format guidelines and standard templates. They may also have approved typefaces, up to and including brand-custom typefaces. And while these things could be applied by document editors or tools later based on a simple set of text documents (I'd be in favor of that), in reality everyone works in Word, and the working Word documents are what will eventually become signed legal documents or stamped and sealed engineering studies, or similar. Styling does matter.
Ideally, yes. But so many people only know of Word, or have been writing using Word for so long that they won't change their workflow and they simply do what works for them.
...in the real world, they're one and the same.
I guarantee you anyone considering paying for a Word tie-in does not need to be convinced to use Word over Google Docs.
From the article
There is a lot of overlap here with the authoring process of a Word document. You don’t necessarily want the real-time coauthoring experience offered by Microsoft SharePoint or Google Docs., this can inhibit your ability to determine who is responsible for specific changes to content. Branching offers a much clearer audit trail of changes. Like with code, tags can be added to signify a minor or major version of a document is ready to be published.
I've never used this, but I intend on checking it out. Just from the website, it seems it brings all the benefits of git like branching, merging, etc whereas Google docs revision history is strictly linear.
Too many more features, fonts, style, customization etc....plus lots if companies already use it for everything, may not want to swtich to google.
Google Docs is only online, I have to give my documents to Google and is quite thin in product features.
Can't use Google Docs offline for one
Nice to see this happening! I wrote about "Git for everyone" in Idea Dump 6 in 2012.
http://willgrant.org/post/idea-dump-6/
http://willgrant.org/post/idea-dump-6/
This is actually a great idea, but not a new one. See this TED talk from 2012 [1]. I hope this kind of thing is integrated into more products and services
[1] https://www.ted.com/talks/clay_shirky_how_the_internet_will_...
[1] https://www.ted.com/talks/clay_shirky_how_the_internet_will_...
Took me a while of reading here to realise, there's no git here. This is a seperate thing that cannot be integrated with your existing stuff, if you're already using Git.
I'd like to have the option of Word documents in Git but I don't want a whole other system just for the special snowflake that is Word as I'm already using Git for managing LaTeX documents and doing that entirely on my own infra.
I'd like to have the option of Word documents in Git but I don't want a whole other system just for the special snowflake that is Word as I'm already using Git for managing LaTeX documents and doing that entirely on my own infra.
I don't think people who already use git and latex are the target audience for this.
Then they shouldn't market based on it.
I agree. Git / version control is too complicated for most people. Doesn't Microsoft have its own collaborative editing / version control system in Office365 yet?
Office365 does have versioning. I'm not going to say this is better or worse, but it does exist.
Slightly off-topic, but if you're using Git for managing your LaTeX documents, you might like to give Overleaf a try -- it allows you to clone your LaTeX project on Overleaf to a local Git repo (which can be a submodule of a wider project). Details here: https://www.overleaf.com/blog/195
If you do use it, feedback is always appreciated (I'm one of the Overleaf founders), thanks.
If you do use it, feedback is always appreciated (I'm one of the Overleaf founders), thanks.
Is that something people care about though?
I'm asking honestly as someone who was in this space several years ago, I'm not convinced that even if it was backed to git that would be a big enough lure to make people want to use it.
Please feel free to convince me I'm wrong :)...
I'm asking honestly as someone who was in this space several years ago, I'm not convinced that even if it was backed to git that would be a big enough lure to make people want to use it.
Please feel free to convince me I'm wrong :)...
Every lawyer who works in litigation would give an arm for something like this if it actually works. I spend so much of my time in "Track Changes" under Word and after three redlines it's basically incomprehensible.
I've used git for word docs for years now. Using pandoc to convert them to markdown allows sensible diffs to be displayed as well. Works great for redlining.
I tried doing something like this a couple of years ago by embedding an actual git repository inside a docx or ODF file. Unfortunately, most popular word processing suites back then trashed the git directory instead of leaving it alone (as they should, according to the standards)
I did something similar: I built a tool in Python called musdex to use in git (or any other VCS) hooks to extract the zip file that a docx/odf file is before commits and recombine them on pull/merge (essentially treating the docx/odf as something of the build product of the repo). Run an xml lint tool on the XML in them and you get decent diffs.
How big do you think the intersection is of people who can use git and people who want to use Microsoft Word?
It includes at least me :) I switched to Latex for writing my second master thesis because I wanted to use version control but Word is far more easier to deal with when the document include unicode character outside the BMP. So I really wanted Word + git from that time.
Also when collaborating for writing a paper with Word, version control can be a huge help.
Also when collaborating for writing a paper with Word, version control can be a huge help.
Did you ever try Xelatex? I think it has support for arbitrary utf8 characters. Also for your system's built in fonts fallbacks is a character is missing from a font.
Why not use something like Google docs or office 365 then?
Word has way more features than GDocs. Haven't spent time with O365 but as far as I know half the draw is you can use it with Office.
I could recommend this for something like bank compliance. We're stuck with Word and have a largely non-technical staff, but could dramatically improve our performance if our documents were version controlled. If I were OP I would look banks as a launch point.
Want to? Near zero. Have to? Maybe a bit larger, hard to say.
As much as I hate having to work in Word for small things that could so easily be a plain-text format, the versioning system within Word isn't exactly the worst thing ever.
As much as I hate having to work in Word for small things that could so easily be a plain-text format, the versioning system within Word isn't exactly the worst thing ever.
Significant.
Most engineering firms (web dev << the development world) have a need for proper documentation, and LibreOffice generally won't cut it either.
Most engineering firms (web dev << the development world) have a need for proper documentation, and LibreOffice generally won't cut it either.
One would expect an engineering firm to be able to set up doc conversion for the special people who need "proper documentation" and consider Word to be at all related to that. Every "document" I've ever gotten from an engineer has been a PDF, which should work even for special people.
in over 20 years crossing around 10 different companies, all documentation produced has been in Word format... never a single exception other than simple text files for extremely minor stuff.
Word rules the world... love it or hate it, its the truth.
I love Word.
Finally someone is doing this! I've been toying with the idea myself but haven't been able to dedicate time to it, mostly I was deterred by the MS Word format mess. I'm sure it wasn't fun making this work with a 21st century versioning system.
I'm sure lots of people will happily throw money at you for this!
I'm sure lots of people will happily throw money at you for this!
it already exists... version control tools can start Word to compare and merge .doc files.
What's wrong with using a document management system instead of this?
Most DMSes utilize a "check-in/check-out" process, meaning that only one person can work the document. Others can work on "copies," but there is no way to sync their changes back into the main document stored in the DMS.
Exactly. It means incompatible changes have to be merged manually later. It causes problems with large reports where, for example, an electrical engineer may be editing one section and a civil engineer another, but only one can have the document checked out at a time. It's possible to break large reports up into many small section reports, but that's a workaround to the real issue.
It also means that when someone checks a file out and then goes home for the weekend without checking it back in no one can update the file in the DMS without administrator support.
It also means that when someone checks a file out and then goes home for the weekend without checking it back in no one can update the file in the DMS without administrator support.
...or just putting your docs in version control and using Word as the diff/merge tool?
[deleted]
The group of people who still do their day-to-day by passing around Word docs via email or LAN likely does not intersect well with the people who fully understand (or have much less heard of) Git.
Thus, I'd remove pretty much all mention of Git from your project landing page (except perhaps to say that it was inspired by its success in the programming world to manage a similar need) so as not to scare off your likely target market (lawyers... who are ALSO notoriously Luddite!)
Thus, I'd remove pretty much all mention of Git from your project landing page (except perhaps to say that it was inspired by its success in the programming world to manage a similar need) so as not to scare off your likely target market (lawyers... who are ALSO notoriously Luddite!)
Future of education is plain text
Congratulations on your launch!
Other folks have provided a bunch of commentary on the validity of your idea, so I won't address that.
BUT: if this is a good idea, your pricing is far too low for a niche product like this. $10 (or 10 quid) is too low a monthly fee for pretty much any product marketed as a business product. 10 per seat per month is probably also too low, but would be a better starting point.
Likely objection: "But Spotify is only $10/mo!!!" Spotify has the much larger addressable market of people with hearing and an Internet connection. Even Dropbox has a higher price point for business users, and it also has a far larger addressable market.
If you're building something that's useful for people, charge more.
Good luck!
Other folks have provided a bunch of commentary on the validity of your idea, so I won't address that.
BUT: if this is a good idea, your pricing is far too low for a niche product like this. $10 (or 10 quid) is too low a monthly fee for pretty much any product marketed as a business product. 10 per seat per month is probably also too low, but would be a better starting point.
Likely objection: "But Spotify is only $10/mo!!!" Spotify has the much larger addressable market of people with hearing and an Internet connection. Even Dropbox has a higher price point for business users, and it also has a far larger addressable market.
If you're building something that's useful for people, charge more.
Good luck!
Plugging these patio11 posts because a)they might be helpful if OP hasn't read them and b)even if OP has, somebody else here might not and they're pretty much evergreen:
The Black Art of SaaS Pricing: https://training.kalzumeus.com/newsletters/archive/saas_pric...
Doubling Saas Revenue by Changing the Pricing Model: http://www.kalzumeus.com/2012/08/13/doubling-saas-revenue/
Selling To The Fortune 500, Government, And Other Lovecraftian Horrors: https://training.kalzumeus.com/newsletters/archive/enterpris...
Patrick's default pricing model: https://twitter.com/patio11/status/479095257284345857
The Black Art of SaaS Pricing: https://training.kalzumeus.com/newsletters/archive/saas_pric...
Doubling Saas Revenue by Changing the Pricing Model: http://www.kalzumeus.com/2012/08/13/doubling-saas-revenue/
Selling To The Fortune 500, Government, And Other Lovecraftian Horrors: https://training.kalzumeus.com/newsletters/archive/enterpris...
Patrick's default pricing model: https://twitter.com/patio11/status/479095257284345857
Just to echo Patrick's default pricing model. If it's too cheap (and you currently are), I would not trust the developer having resources to make the product stable enough for me to trust it with my data. Also, it costs money to go through certification (without which you will not penetrate the market where this pain point is clearest).
As someone who evaluates and purchases business software on a regular basis, I agree with this. Business users will pay more for something that's useful.
And you don't want to lock too many customers into low pricing early on - it's a real challenge to start charging customers more when they're used to paying a ridiculously low rate.
And you don't want to lock too many customers into low pricing early on - it's a real challenge to start charging customers more when they're used to paying a ridiculously low rate.
I would be careful with raising pricing. It is a very specialized product that requires changing the way people work with their documents today - meaning you need to educate the users on a) why they need this over the regular document version control in something like Sharepoint b) educate them on how to actually use it and c) define how this product fits into existing document management systems and workflows.
It's hard enough to train people to use existing baseline document management systems and not simply email these things around.
Also, the fact that you need to use your cloud service is a red-flag for certain clients.
It's hard enough to train people to use existing baseline document management systems and not simply email these things around.
Also, the fact that you need to use your cloud service is a red-flag for certain clients.
Then do a promo pricing period or something. But don't lock users that would pay higher rates into a low subscription fee structure.
Slight aside (since LibreOffice != Word, and XML diffs are still horribly messy):
If you save your LibreOffice documents in flat XML format, (e.g. fods, fodt instead of ods, odt), placing them under version control becomes slightly less annoying — the diffs become at least _potentially_ human readable.
See also:
http://blog.riemann.cc/2013/04/23/versioning-of-openoffice-l...
https://listarchives.libreoffice.org/global/users/msg48067.h...
If you save your LibreOffice documents in flat XML format, (e.g. fods, fodt instead of ods, odt), placing them under version control becomes slightly less annoying — the diffs become at least _potentially_ human readable.
See also:
http://blog.riemann.cc/2013/04/23/versioning-of-openoffice-l...
https://listarchives.libreoffice.org/global/users/msg48067.h...
This is very cool, and I wish we had something like this, but I don't see many law firms going for it.
Most law firms (and I would guess all major ones) will not allow uploading of client documents or work-product to any cloud provider, let alone an unproven start up. This risk is frankly way too high.
The only way I see this happening in the legal context is if it can be run from the firm's servers with all data hosted locally.
Most law firms (and I would guess all major ones) will not allow uploading of client documents or work-product to any cloud provider, let alone an unproven start up. This risk is frankly way too high.
The only way I see this happening in the legal context is if it can be run from the firm's servers with all data hosted locally.
This isn't as absolute as you'd think, at least in the firms I've seen here in the US. Nearly all have shifted to cloud solutions for some documents at least in the litigation world where I dwell, especially in doc production and discovery. In a recent class action, my team was sent opposing counsel's link to the Box folder with their 4gb+ docs sent over from their client. Which shows that the clients are demanding that their outside counsel use some of the tools that they've embraced.
You're right with respect to internal memos, notes, drafts of pleadings, etc. But I suspect this is changing too as more lawyers want to be able to work on docs from their phones and iPads and remote laptops.
You're right with respect to internal memos, notes, drafts of pleadings, etc. But I suspect this is changing too as more lawyers want to be able to work on docs from their phones and iPads and remote laptops.
This fills a niche I need but I can't use a service where I upload the documents to your server (unless you can show certification of at least ISO 27001). I would also be willing to pay more for it. Version controlling Word documents is a need for anyone doing a lot of QC. You have a superb product to sell.
Hey OP, this looks like an awesome tool, good job! Just a quick question, would the primary alternative to your product be Microsoft Sharepoint? If so, how would you market your service as better?
nice work! at my last company we hooked up word docs with SVN. Its very useful to have a workable format for lawyers to update, and then be able to process everything in the back end.
THIS is how Sharepoint should have worked from day 1. But I guess Microsoft thinks normal office workers won't get version history in their mind.
I've had multiple frustrating conversations where I tried to get people to stop using the strategy of copying entire folders in SharePoint to get some kind of versioning, so they might be right.
To be fair, plenty of _tech_ workers have trouble getting their minds around version control - it's a common joke on the internet for a reason
If you had a version that companies could install on a private internal network, you could easily charge between $100 and $1000 a month for this.
I work in legal and compliance technology, and it is very important to keep documents secured internally if the have confidential information.
I work in legal and compliance technology, and it is very important to keep documents secured internally if the have confidential information.
Legal/compliance work is probably where this sort of service would be most useful.
1000% agree.
FogBugz offered a server version where you could install on a private server yourself. They still offered a cloud version if you didn't want to manage the data yourself.
This point is huge. I'm a technical writer for a large conglomerate, but often get pulled into drafting or contributing to business documentation that is all created in Word. These things have to cross the desks of over a dozen different people spread across three continents so versioning is painful and it's often left to me to put everything back together. I need this product, but there is no way we can put sensitive sales and IP details onto some random cloud service.
Make this a standalone product and it's a no-brainer that can command an enterprise price point.
Make this a standalone product and it's a no-brainer that can command an enterprise price point.
SVN does version control for word documents just fine.
it absolutely does... with word integration also...
...but people here irrationally hate svn, so you're getting unfairly downvoted.
...but people here irrationally hate svn, so you're getting unfairly downvoted.
Cool!
Here's my unsolicited opinion: you preemptively answer "why wouldn't I just use git?" but I think "why is this better than track changes?" is the question prospective users are more likely to have. Comparisons to SharePoint versioning might also be helpful.
Here's my unsolicited opinion: you preemptively answer "why wouldn't I just use git?" but I think "why is this better than track changes?" is the question prospective users are more likely to have. Comparisons to SharePoint versioning might also be helpful.
I hope OP helps lots of people, because if they've been so abused by their computers as to think "Track Changes" is anything other than a torture device, they really need help.
It'd probably work better if more people used the "accept/reject" functionality. But yeah it can be awful.
I think this is a good product, once worked in strategy as an intern at a bank and we basically used manual versioning where we would version using date and time or even content, this is definitely a step up
I worked for a company that did studies to get FDA approval for a medical device. The company was very professional and well managed. But THIS is what they were lacking. I always thought they need something like github and Version control for the constantly changing documents.
Many others have said it already, but I'll say it again:
1. You have a fantastic product
2. Many potential users won't accept to have their documents stored "in the cloud" (even though those same users share those same documents by email with zero security, all the time)
3. Offer a stand alone version and sell a licence (or a rent, think the former Google Search Appliance)
4. Charge an arm and a leg for it -- think Oracle pricing
5. Get rich!
1. You have a fantastic product
2. Many potential users won't accept to have their documents stored "in the cloud" (even though those same users share those same documents by email with zero security, all the time)
3. Offer a stand alone version and sell a licence (or a rent, think the former Google Search Appliance)
4. Charge an arm and a leg for it -- think Oracle pricing
5. Get rich!
6. Realise that you've recreated a feature that already exists natively in word... Doh!
Not the OP, but I really don't think it does.
Word has native diff-ing and 3-way merging. version control systems can call this as their diff tool.
The fact word offers a competing feature does not mean this is not a pain point people would pay money for.
Have you tried to use Word's features as part of a mid-size team to manage a complicated document being edited by multiple users? Word's merge is crap.
My old law firm used version control software that appeared to be straight from 1991. So there's plenty of room to solve real problems here.
OP, I wish you the best of luck. But I concur with others, the use case for this product I see is for a team or company to learn to use it internally, not for a bunch of lawyers to use it across firms. So, keep the free tier to attract people who are willing to use it on their own (or in case someone can convince those outside their organization to sign up in order to participate on projects), and then increase pricing to any sort of team.
Also, I'm sure my firm could never have used a cloud-based solution, regardless of security, because we probably had clients who would not allow their information to be stored in the cloud.
Also, because I can speak to lawyers, the diffing needs to be excellent and it needs to be easy to create and share redlines in the ways lawyers are used to (send as a word doc/PDF, etc.). Perhaps this is already there, I'm excited to check it out.
Have you tried to use Word's features as part of a mid-size team to manage a complicated document being edited by multiple users? Word's merge is crap.
My old law firm used version control software that appeared to be straight from 1991. So there's plenty of room to solve real problems here.
OP, I wish you the best of luck. But I concur with others, the use case for this product I see is for a team or company to learn to use it internally, not for a bunch of lawyers to use it across firms. So, keep the free tier to attract people who are willing to use it on their own (or in case someone can convince those outside their organization to sign up in order to participate on projects), and then increase pricing to any sort of team.
Also, I'm sure my firm could never have used a cloud-based solution, regardless of security, because we probably had clients who would not allow their information to be stored in the cloud.
Also, because I can speak to lawyers, the diffing needs to be excellent and it needs to be easy to create and share redlines in the ways lawyers are used to (send as a word doc/PDF, etc.). Perhaps this is already there, I'm excited to check it out.
I think if you can get people to use this and try it, you're going to make a ton of cash. This has been needed for years and doing it within Word sounds to me like the absolute best solution. Get in touch if I can help at all or you're raising!
Word has a diff tool built in. There is also integration with version control (i.e. double click in TortoiseSVN for example brings up a correct diff view of the word doc for 3-way merging).
Firstly, great job in getting that mess to play well with Git!
For plain text, sure, for markdown, nope.
"...and fonts"
Sure, but formatting can be applied after. With markdown, it supports HTML so you could event apply custom formatting inline, if you really wanted to do something so dirty.
"This is usually too much of a sacrifice for companies as formatting needs to be reapplied with each publication, which is very time-consuming and prone to errors."
Why not solve this problem? Why not make markdown more accessible to those wanting to use Word? Make something that looks like word, but in reality takes markdown and renders it using some flexible settings file?
I personally quite like markdown, to me it represents a minimal, future proof language. I would actually change a few things about markdown to make it more useful in an academic setting. Issues for me are referencing structure, diagrams, embedding content (at the position) and plots. Those things fixed, I would never look back at LaTeX or Word again.
One thing I would like to see remain, is the plain-text readability and being able to process it line-by-line without having to remember anything about the previous line.
Good luck with this venture, but if you're wanting to take a pivot, let me know :)
The main limitation with Git is that it only works with
plain text (think Windows Notepad). I have seen authors
resort to plain text or markdown in order to take
advantage of Git, but this means losing all of your rich
formatting such as images and fonts. This is usually too
much of a sacrifice for companies as formatting needs to
be reapplied with each publication, which is very
time-consuming and prone to errors.
For plain text, sure, for markdown, nope.
"...and fonts"
Sure, but formatting can be applied after. With markdown, it supports HTML so you could event apply custom formatting inline, if you really wanted to do something so dirty.
"This is usually too much of a sacrifice for companies as formatting needs to be reapplied with each publication, which is very time-consuming and prone to errors."
Why not solve this problem? Why not make markdown more accessible to those wanting to use Word? Make something that looks like word, but in reality takes markdown and renders it using some flexible settings file?
I personally quite like markdown, to me it represents a minimal, future proof language. I would actually change a few things about markdown to make it more useful in an academic setting. Issues for me are referencing structure, diagrams, embedding content (at the position) and plots. Those things fixed, I would never look back at LaTeX or Word again.
One thing I would like to see remain, is the plain-text readability and being able to process it line-by-line without having to remember anything about the previous line.
Good luck with this venture, but if you're wanting to take a pivot, let me know :)
I'll answer some of these questions for the developer, because I'm smack in the middle of their target market: litigation attorney.
Anything other than Word is a non-starter for 99% of law firms (and the other 1% is still on WordPerfect). Markdown is awesome and I use it for my notes files and all kinds of things but contracts, settlement docs, pleadings, motions, etc etc all exist strictly and only in Word. And probably 50% of those are still .doc format, which was left behind more than a decade ago in Word 2007.
This product, if it works, will be a God-send for firms like mine (small to medium litigation shops that don't use full document assembly software with built-in version control like the AmLaw 100 firms. And it looks like even those firms might profit from this solution if it plays well with their customer style sheets and macros.
I wish it were different, but sadly the state of legal tech is mired in the late '90s.
Anything other than Word is a non-starter for 99% of law firms (and the other 1% is still on WordPerfect). Markdown is awesome and I use it for my notes files and all kinds of things but contracts, settlement docs, pleadings, motions, etc etc all exist strictly and only in Word. And probably 50% of those are still .doc format, which was left behind more than a decade ago in Word 2007.
This product, if it works, will be a God-send for firms like mine (small to medium litigation shops that don't use full document assembly software with built-in version control like the AmLaw 100 firms. And it looks like even those firms might profit from this solution if it plays well with their customer style sheets and macros.
I wish it were different, but sadly the state of legal tech is mired in the late '90s.
Another lawyer here (tax, UK) - there are similar products available and they're pretty commonly-used over here (such as Worksite for DKMS/version control and Workshare for comparisons between docs).
But the VC tends to be centralised, rather than distributed. I've often hankered after a more git-like experience when working remotely or offline, and I will follow this project with interest.
One area that is underserved at the moment is diffing .ppt files. Since a lot of the tax industry in particular uses PowerPoint for step plans and structure papers (because it is generally easier to build structure charts). Whilst it isn't the right tool for the job, for as long as people continue to use it, getting this working on your app would be huge.
But the VC tends to be centralised, rather than distributed. I've often hankered after a more git-like experience when working remotely or offline, and I will follow this project with interest.
One area that is underserved at the moment is diffing .ppt files. Since a lot of the tax industry in particular uses PowerPoint for step plans and structure papers (because it is generally easier to build structure charts). Whilst it isn't the right tool for the job, for as long as people continue to use it, getting this working on your app would be huge.
I'm pretty sure the latest version of worksite/workshare (never was sure which is which or what all the names are) can diff PPT files; apologies if I'm misremembering but that is my recollection from my firm.
I agree the developer needs to take a look at these if he/she has not already but there's plenty of room to improve on those products; I don't think the existence of some mediocre solutions should put the developer off.
I agree the developer needs to take a look at these if he/she has not already but there's plenty of room to improve on those products; I don't think the existence of some mediocre solutions should put the developer off.
Completely disagree. There's a bunch of "word-like markdown editors" out there. We don't need one more of those.
There's a real market here. Word is huge, and people aren't gonna give it up. This looks to be a good technical solution. Trying to move people from word to markdown is an ok ideal, but not a practical business move.
My advice to the creator, ignore bArray's advice.
There's a real market here. Word is huge, and people aren't gonna give it up. This looks to be a good technical solution. Trying to move people from word to markdown is an ok ideal, but not a practical business move.
My advice to the creator, ignore bArray's advice.
I agree with your comment.
I'm coming at this exact problem from the opposite direction, making a Markdown-based static-publishing CMS intended for corporate use (aimed at official documentation, standard operating procedures, handbooks, etc) and weening people who are used to it away from Word is the most difficult part of the entire process.
On the other hand, Word falls short when it comes to a large number of related documents, with inconsistent styling, flakey 'hyperlinks', ridiculous attachments and lack of good version control (something Simul appears to be tackling).
There's plenty of room for innovation in this area and props to the OP for actually tackling the harder challenge head on. My fear in trying to sell this to businesses would be that letting their confidential docs leave their network is going to be a hurdle. A self-hosted version would definitely be onto a winner, and anything that's not Sharepoint is a good thing.
I'm coming at this exact problem from the opposite direction, making a Markdown-based static-publishing CMS intended for corporate use (aimed at official documentation, standard operating procedures, handbooks, etc) and weening people who are used to it away from Word is the most difficult part of the entire process.
On the other hand, Word falls short when it comes to a large number of related documents, with inconsistent styling, flakey 'hyperlinks', ridiculous attachments and lack of good version control (something Simul appears to be tackling).
There's plenty of room for innovation in this area and props to the OP for actually tackling the harder challenge head on. My fear in trying to sell this to businesses would be that letting their confidential docs leave their network is going to be a hurdle. A self-hosted version would definitely be onto a winner, and anything that's not Sharepoint is a good thing.