Ask HN: “Git” for Microsoft Office?
Is there anything out there, capable of working with MSOffice stuff in a granular and collaborative way? I can’t believe non-geeks have lived like this for 30 years.
Is there anything out there, capable of working with MSOffice stuff in a granular and collaborative way? I can’t believe non-geeks have lived like this for 30 years.
A couple years back I built this: https://github.com/tomashubelbauer/modern-office-git-diff
It is a pre-commit script which unpacks Office XML into text contents and tracks that alongside the source file. This way you can consider the binary to be a source of truth, but with each commit you also get a textual diff showing what changed content-wise. More or less.
Some person built the same thing for OpenOffice and I link their project in my readme, too.
Thanks!
You can do that with pandoc[1] as a git diff-viewer[2] too.
[2] https://github.com/vigente/gerardus/wiki/Integrate-git-diffs...
You can have that Golden Version and everyone can suggest changes and edits, then the document owner can accept or decline the edits.
[1]: https://support.office.com/en-us/article/Collaborate-on-Word...
>if the same slide is present in 15 Powerpoint decks any edit will require tons of mindless and error-prone copypasting
This is exactly what you want SharePoint for. Have 15 people open the same PowerPoint deck, in desktop PowerPoint, editing the file simultaneously. It's fully versioned and you have no merging of files back together.
I wish there was a “pull request” for office with a permission that allowed suggestions but not edits.
Intuitively, this doesn't really seem possible to me for a sophisticated document format. E.g., how would you represent a change to an embedded graph in a pull request? (And would that same approach scale to any form of embedded media?)
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!
My current understanding is that live collaborative editing is the solution for the same problem version control solves for non-plain text file formats (and therefore, also the solution for non-programmers). Think of how much programmers complain about the complexity of git, and that's using it with plain text, a format that facilitates version control like no other.
For collaborating in every document format that isn't plain text, my solution has been to use live collaborative editing.
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.
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
On Office 365 at least, it does tell you all of those things.
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.
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.
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.
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.
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!
Of course one can't do a pull request with Office (non-geeks would struggle with the idea anyway) but live-editing of shared documents and version history is now built-in.
If two or more people open the same .docx/.pptx/.xlsx from a shared environment (Sharepoint/Teams/OneDrive), and then proceed click on Open in Desktop App (the browser-based apps are unpolished IMO), AutoSave is automatically turned on, and they're automatically thrown into live collaboration mode. This is the new norm in most enterprises that have Office365.
Most office folks require version history rather than version control -- not many are likely to need to branch, merge, pull, push -- and Office365 definitely supports the former. You can even have a threaded conversation about the changes in the document itself. -- when you add a comment, the chat sidebar opens. The back-and-forth comments are stored in the document.
Note: this is different from "Track Changes" in older version of office -- which still exists but is more for visual diffing. Version history only stores snapshots.
I lived through the days of Microsoft being predatory and evil and I hated Microsoft because their products sucked (not sure if anyone remembers the strident rhetoric in comp.os.os2.advocacy -- that newsgroup raised Microsoft hatred into an art form). For years this emotional response blinded me to the pockets of genuinely good technology that Microsoft had in its lineup (like SQL Server).
When I started working in an enterprise environment, I often ended doing things the hard way because of this blind spot of resisting anything Microsoft. It cost me so much.
It was only when I was forced to put aside my prejudices that I discovered that it was actually possible to be productive while using Microsoft tech. Nowadays I favor pragmatism and productivity over partisanship, and try to choose the best tool for the job, and if it means choosing MS tools occasionally, that's ok.
In my experience, merging seems to fail more often with Excel and PowerPoint than Word, but even in Word applying doc-wide changes (e.g. change of language) while someone else edits usually fails.
For sequential editing it works fine and keeps an automatic version history.
Is it possible you’re using a older version of Sharepoint that isn’t collaboration aware? I know in older versions of Sharepoint, documents get checked out and locked all the time. Are you able to do live editing? If you aren’t, we might talking about different versions here.
With Office 365 and Sharepoint 2016, I was under the impression that collaboration uses operational transformations (like Google Docs) or CRDTs rather than continuous merging —- which isn’t feasible for real-time live editing anyway. Unresolvable conflicts are rare because the merge is happening at the action level, not document level.
The experience in Office 365 has been similar to Google Suite for me.
I get that they're headed towards WebKit for all their apps, but it's kind of frustrating to have to head to outlook.com for some things and have to use the desktop version for others (though the search via outlook.com is vastly improved over the desktop versions of Outlook).
My $0.02: just use git?
Sounds good in theory - now imagine explaining to a group of regular office workers concept of commits, merges, pull requests, whole workflow and additional software for doing all of this. It's just not possible.
The only caveat I'd offer is, for MS Word specifically, you can have: (1) Large complex documents (i.e. lots of links/references, sections) OR (2) Many collaborators. Pick ONE. If you must have both of these, leave track changes off, and use highlights and comments.
I've been in the unfortunate position of being next to a deadline, where the word document was the key deliverable. And then having that document become corrupted. Fairly certain it was a confluence of the above factors that caused it. If the doc is starting to take 30 seconds or more to just scroll down or edit one character, that's your first warning bell.
We tried opening in Word Online, Word Mac, Word Windows and even LibreOffice. No dice. What worked in the end? A smart chap on our team thought to try importing the doc into Google Docs, and then exporting it again...
We regularly edit complex documents with large numbers of collaborators. Track changes and collaboration are different though (the former has been around since time immemorial but collaboration only came out a couple of years ago)
No, but people seem to get work done anyway. It's very strange to me.
My current and previous jobs are very corporate, so much of the business and IT uses Office products all the time. I somehow managed to set the standard that I don't do it that way. I still have to sometimes, but it's not very often.
The key is to acknowledge that using Office effectively is a difficult skill. It makes management feel smart that they know how to do something technical a developer doesn't. Then it's just a matter of finding and highlighting alternatives. Plain text and/or a wiki covers almost everything in my experience.
It’s very hard though, because the files combine data and styling. Plus, the data is spread over several XML files.
If you want to message me: jan at the domain above
Edit: While Google Docs, Office365 and other collaborative editors are great for editing a document at the same time, from my point of view the real power of Git is branching, merging, and having a concept of distinct versions (which may consist of several files).
There's a variant to use TortoiseGit as a git desktop client (only Windows) versioning directly office documents because of that one pops up the resolution of the conflicts directly with the office apps.
There're some folks followed me to markdown-git using desktop clients like Typora and Gitbook (editor and other services), but it's not suitable for everyone.
https://support.office.com/en-us/article/enable-and-configur...
Is not perfect but it works.
Tested with TortoiseSVN 1.11.1, TortoiseGIT 2.10.0.2, MS Office 2010 on docx documents.
We have our non-technical editors using Markdown and git just fine, but you may have a lot of initial resistance. We were able to force them to switch because we're mostly a tech company. They hated it at first even though they love it now.
Never found a good solution to powerpoint
tpp or LibreOffice's Impress.
Using open formats diff better. There's also the homebrew method I use where I decompress the document and store that tree in git too, sometimes it helps and is easy to recompress into document format. It's part of my regular checkin script.
Long story short, some recruiters don't like pdf's (from LaTeX) so I've got a mixed setup of LaTeX and libreoffice. The LaTeX copy produces several different documents with varying amounts of personal information. This is toggled through variables in the script so some outputs are web-safe (nothing but email), some I sent to recruiters which have temporary phone numbers on which are disconnected when I'm FTE. The other has a real SIM mobile on that I use on company internal job boards.
LaTeX wins here, but to keep some recruiters happy I copy the changes into an odt format. Yes I know about Calibre.
There are lots of markdown presentation tools, I've enjoyed using https://remarkjs.com/ which sounds like it could fit your workflow.
One thing that can make things better is to teach people to use Styles correctly.
Technically, you could use git, and it works decently with the xml-based Office file types, but it's a hard job to get people used to the workflow, and things like merge conflicts are going to be even more of a headache.
I beg to differ as normal people would expect their old documents to work, and the subset of things that work in web is not enough. Quite like LO-supported, totally not on par with native.
You can even work with multiple users as the same times (for example when opening files via webdav with nextcloud, or any other way to share your data) !
Edit: There's some recommendations on versionning odt files by using .fodt extension [1].
[0] https://wiki.documentfoundation.org/Track_changes
[1] https://wiki.documentfoundation.org/Libreoffice_and_subversi...
If you would need an exact version, you can build this version out of its components of that version.
However, you can't really used them to dump the current database, and they don't both appear to be used in timabell's work for a quick glance.
The loader method even allows for the lighter-weight Forms from the other Office applications to be pulled into Access, though the motive for using them would not be clear.
My intent had been to write an Excel macro workbook as a manager tool, and use it to manage Access Dbs in git.
I have a library I call "The NecroVisualBasiCon" out in GitHub that I'll share if anyone is interested in peering into an abyss.
You still have some pains with it, but its better than anything else I have seen for a non technical user.
Second point, I haven't tested this, but docx, xlsx etc are XML based and may be happily Git compatible.
Third point, if the above doesn't work, look into automatically saving / converting documents into and out of a Git compatible format with minimal loss of formatting etc. You may be able to convince your team that this is an acceptable compromise between the tools they are used to, and the power of DVCS.
Which make a version control pretty much impossible.
Indeed, pass (https://www.passwordstore.org/) uses this to allow diffing and sane tracking of its password files, even though they are binary encrypted GPG blobs.
I do this with LibreOffice. I've not tested Microsoft Office with this workflow.
It allows you to create "Cards" or snippets of any size, of any part of the document, and save it, version it, and sync it with any other document. Even with documents in Google apps (Docs, and Sheets). A Card can be a sentence, paragraph, or entire document, up to you.
Disclaimer: I'm the CTO of its parent company.
Nonetheless, by simplifying the FODS files to use a subset of the format, the diffs are looking okay now. I created a wee little canonical string representation of the style parameters I want to use, and putting that string in the style:name attribute when I clean up the document.
I recently worked on a word doc with four other collaborators. Someone inserted a footnote. Looking through versions it took me 10 minutes of sifting through the dozens of versions (auto save creates new versions very frequently) to find who and when that section changes.
I wish there was a git blame for office.
I also wish the old day of “checked in” versions where I could set a number and a comment.
That's exactly what "Track changes" is for.
Blame goes through the entire history of a file.
This is what I did in college because (for some reason) everyone expects word files for everything.
Workplaces where knowledge is organised in some shared drives folder tree are rather unproductive by nature. There are tools to deal with that for a good reason.
Ive also seen some advanced document comparison tools that plug into MS Word and redline differences (more advanced than the built in one).
I guess these tools could help ensure faith in the latest approved or “gold” version.
It works really well!
But it won't work with your nontechnical office staff. :(
Is track changes not good enough?
(2) What happens when someone checks in a hand-reconciled merge that is not a valid XML file, because whoops?
I find that most office users can’t use SharePoint. There’s too many things that are confusing or don’t work as expected, so it’s rare to find a business user who can set up SharePoint sites or workflows or even document organization.
So I’ve seen “SharePoint developers” who are consultants who know what to click and configure.
If I’m going to have to hire special people to make web sites, I’d rather just hire more technical people who can code something or tie together products. SharePoint developers cost the same as Wordpress developers to me.
The big advantage, I think, for collaboration software is to have contributors work directly with each other. Having to go through a secretary to convert work to some special format eats up the big benefits from stuff like SharePoint.
Document organization will be a problem wherever you settle. What are your abstractions, what are your folders, who can create what at what level.
Files can be opened directly from within word or excel, but browsing a team’s SharePoint is faster than navigating Excel’s open dialog. Similar to how browsing File Explorer or Finder and then opening a file is faster.
So avoiding SharePoint isn’t very likely, I think.
It's much much faster to open Excel and type a couple characters of the filename into the File > Open search field, than it is to navigate structures.
An open source Git extension for versioning large files https://git-lfs.github.com/
https://www.theverge.com/2020/5/19/21260005/microsoft-office...
https://support.microsoft.com/en-us/office/get-started-with-...
I'd be happier with something that simply allows me to have a github-like workflow where I can propose and justify changes to this or that block of document, and an owner can sanction and merge. This would not touch internal hierarchies (the most sacred element of corporate life) but would improve collaboration.
If Fluid is a step in that direction, it's welcome. Unfortunately to me it looks more like "web-native COM objects" and few people ever liked those.
This is called 'Tracked Changes' and 'Comments' in Word. Under the Review ribbon.
Here's the How-To: https://support.office.com/en-gb/article/track-changes-in-wo...
Absolutely not comparable to a github experience, as far as I can see.
Given how shitty MS software has always been, I can't believe people not only pay money for it but also accept it as the norm.
As for your question, non-geeks have been coping with this by saving a copy of a document before each edit so that when the inevitable catastrophe occurs, they can roll back. As a geek, you can use git manually. Adding that as a feature to Office would make it even more incompatible with itself than it already is.
* Document1 FINAL
* Document1 FINAL DRAFT (DO NOT EDIT)
* Document1 FINAL EDITED
* Document1 v2 FINAL
- Substantial changes result in a new version number at the end of the file:
Document v34
- Branching to try out ideas uses a marker what this idea was:
Document v34-2 test-color-scheme
If the idea is approved, it results in a new version:
Document v35
- Tagging for long running designs adds the context where it was last used, this can be considered a final release version
Document v36 - July 2020 promo
Once a file is used like that, an export copy with the same name is saved in the same folder:
Document v36 - July 2020 promo.pdf
This document is copied using a general name and then moved to a different folder:
promo2020/july/flyer/Document.pdf
This is what is printed, e-mailed etc. Date and file size allow comparisons to find out which version this was.
While this falls apart for testing a lot of similar ideas at the same time, it has served me well to have a history of snapshots and their context, have all final documents archived, and ignore (or delete) all the versions in between, while still saving progress over days/weeks.
Less than a year later I left that job. I'd rather learn a trade than be paid to use MS Office.
It even lets you switch to any version on the fly.
Part of my company uses SAP for their doc control, part of my company uses MasterControl. I hate hate hate SAP. I have a few bones to pick with Master Control, but overall, it's tolerable. If you'd like to chat more about how this process works in the workplace, you can find me on twitter @failbridge or on reddit as /u/daveslash
It's not that I think they are inherently bad pieces of software, they're actually all pretty amazing. It's just that after years of using markdown, org-mode and python, I get frustrated by how long it takes to debug a spreadsheet or format a document.