Hacker News Reader

Comment by jedieaston | Hacker News Reader

Technically, tracked changes and SharePoint. But in practice, you’d rather send the changes to the project owner via carrier pigeon.

I’ve looked into what it would take to make a git style system for docx (since it’s just zipped XML, right :D), and the file format was a nightmare whenever an edit was made. Someone smart should take a look at it, as there would be a massive market for a DVCS for Office files. Imagine a world where every bill in Congress was committed to a central repo so the whole world could see the changes, or where someone in your team wants to play with the formatting on a shared requirements document without breaking the page you’re writing on. It would be a boon for productivity.

View on HN

> as there would be a massive market for a DVCS for Office files

Would there, though? I mean, we HN readers want that, but I don't see any evidence that the average Office user is clamoring for it. Even comparatively crude systems like Track Changes aren't used in my experience as often as they could be, and those are a hundred times easier for non-technical people to wrap their minds around than a Git-like system would be.

I suspect that part of the reason this problem is so intractable is that it's really two problems. The first is actually tracking the changes to the underlying document, which, as you note, is hard enough by itself. But then on top of that is the second problem, which is that you'd also have to come up with an interface that could make the power of a Git-like system comprehensible to non-technical users. And you'd need to solve both problems to have a product that would actually be ready to take to market.

People get that mailing revisions of documents back and forth feels rickety. In my immediate circle I noticed that people some mild amazement that geeks use Wiki-style collaboration environments instead of office suites.

> I mean, we HN readers want that, but I don't see any evidence that the average Office user is clamoring for it.

My current experience is that non-geeks have no idea that another way of life is even possible. You won't clamor for something you cannot even conceive.

I bet that tons of orgs would rush to adopt a github-style workflow if MS made it available. After trying out the "Track changes" and collaborative modes people have mentioned here, I can see why people in my company don't use them - they are flaky and don't really enforce rights, they basically just nudge the user.

Not laws, but some US gov tech strategies and policies are tracked and edited in GitHub. It looks like it’s not the literal authors making changes, but someone is making changes to markdown documents.

For example, the Federal Data Strategy, https://strategy.data.gov/overview/, is created from https://github.com/GSA/data-strategy

It’s been nice to follow updates and the specific changes using git diffs.

My wife is a laywer and she and her colleagues (and the other lawyers they are working with) pretty much base their workflow for revising documents on track changes. I've never heard her complain about it.

Maybe she is used to it? I have used track changes and it is good and all ... but it may not be exactly the same as being able to know where and when a change was done, by whom, and with the reasoning sometimes added with it that comes from VCSs like SVN and GIT.

I think that's the point - if you use these things expecting them to work like a revision control system for code you'll be disappointed and frustrated.

Meanwhile, people who have no such expectations cope perfectly well.

> Meanwhile, people who have no such expectations cope perfectly well.

You know how they do that right, stay in online chats and ask who, how, why, when. Awful waste of efforts

> where and when a change was done, by whom, and with the reasoning sometimes added

On Office 365 at least, it does tell you all of those things.

For procedure-style documents, I co-founded a company called ProcedureFlow[0] that allows change requests but for hyperlinked flowcharts. My inspiration was 100% GitHub/pull requests. We found that a lot of organizations store procedures in document form which change all the time. So, the purpose behind our product is to move away from a document into a format that easier to use/change/track.

Copied from another one of my comments in this thread:

A procedure is made up of many flows that are linked together. Everyone that uses the procedure views the "live" flows (like a master branch). Each user gets their own branch which we call a "draft". In a draft, a user is free to make any changes they want (add/delete/modify flows) and then submit all the changes for approval. Approving the change request then merges the changes into the "live" for everyone else to see/use. I even went so far as to build side-by-side diff of the flowcharts, rebasing/merging with live, and conflict resolution.

It's simplified in the UI so the terminology isn't 100% like git. But, one of our biggest hurdles though is actually teaching users how this works why it's better than the current mode of document locks/real time editing. And when our customers "get it", they really fall in love with the concepts and why it's better!

[0]: https://procedureflow.com/

Or even just OneDrive -- SharePoint isn't strictly necessary anymore.

OneDrive is a client and api grafted on top of sharepoint. It's all sharepoint under the hood.

You also dont need to use OneDrive to sync SharePoint, you can use the File > Open menu to open in Word, Excel, PowerPoint to open files directly.

Reply on news.ycombinator.com