Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Using Microsoft Word with Git

blog.martinfenner.org

Post reply on HN
Print view View original

31–40 of 136 posts

Re: Using Microsoft Word with Git

#31

Post by Timpy »

MarcScott wrote: post #28

I really don't understand how Word remains so popular. It was created at a time when few people had internet access, and was designed to produce printed documents. It was the perfect tool to write newsletters, flyers, articles, academic papers and manuscripts. The world has moved on though, and I fail to see Word's relevance today, other than the sheer number of people that are familiar with it. Word is expensive, pr…

In my opinion the issue is path dependency. Everybody in my generation grew up with Microsoft Office free on every installation of Windows, and teaching everyone new efficiency software is costly. It looks like Google is trying to win the next generation and Chromebooks are taking over the classroom. When today's youth grow up I wouldn't be surprised to Google Docs as the new standard.

Re: Using Microsoft Word with Git

#32

Post by PeterStuer »

codingdave wrote: post #14

My SaaS deals primarily with legal documents that for years had been maintained with Word. The pain of emailing documents is real, but the comfort level with how Word works is also real. Over the years, most organizations have developed internal workflows to share and send documents around that bypass the pains, and while they may not be perfect, they work. The funny thing is that the document authors like these ways…

Hear hear!

I've spent many years in 'collaborative writing' in R&D, mainly grant proposals and joint reports/deliverables, most in the CS/IT domains. Writing those texts is very different from writing the software.

First thing you should realize is there are no 'tests', and all the 'code' is usually in a single big file. Anyone that has touched the document can have potentially messed up everything, both content, layouts and meta-data, and there is no automatic way to check whether it still makes sense. Many times people will not use the agreed upon editor/version, and sometime (often) that means a boatload of minor edits to the document all over the place just from opening and saving. Imagine everyone in your software team using different editors all with their preferred coding conventions that are automatically applied to the whole project at load.

From this you can deduce the enormous responsibility of ownership and gate-keeping in the workflow. The absolute worst collaborations I have been part of were those that somehow believed that if they used a collaborative document editing facility, wikis or Google docs for instance, that would negate the need for assigned owners/editors. Those tug-of-war shitstorms got exponential the closer one came to the submission deadline (technically incorrect, i know, but you know what I mean).

Some tips:

- Have well defined ownership for each section or part of your document. The owner receives and makes all changes for that part.

- have a final editor that is responsible for the complete document receiving the changes of the parts from their owners only.

- Do not trust 'track changes', but use Word's built in document compare if you are the final editor. For complex formatted documents (nearly all instances require you use an insanely styled template, you 'clean room' import (C/P through notepad) the text changes into the correctly formatted doc under your control.

- release the current trunk document often, ideally once per day. This requires staggering, with subeditors closing submission windows and submitting their updates to the main editor before EoB. Everyone editing should work against the latest release.

-Every version published by the final editor should be immutable. Mail it to everyone if needed, but if you use a link to some sort of repository make sure it is a deep link to a version that can not be updated in the repository, or hilarity will ensue.

- use versioning in the filename. filename_YYYYMMDD_HHMM_dXXX_rNN.docx where XXX is the assigned party acronym for the person making the update. 'YYYYMMDD_HHMM' is only touched by the editor, 'dXXX_rNN' is the NN'ed changes release by part XXX against version YYYYMMDD_HHMM .

Most certainly Git can function as a repository, but there will be people that will not work with it (nor any other repository) so always assume mail interactions as well.

Finally, there should be a special place in hell for the people that designed SharePoint versioning. Don't even think of going there.

Re: Using Microsoft Word with Git

#33

Post by MarcScott »

viraptor wrote: post #30
MarcScott wrote: post #28

I really don't understand how Word remains so popular. It was created at a time when few people had internet access, and was designed to produce printed documents. It was the perfect tool to write newsletters, flyers, articles, academic papers and manuscripts. The world has moved on though, and I fail to see Word's relevance today, other than the sheer number of people that are familiar with it. Word is expensive, pr…

> If you're collaborating on a document then markdown or LaTeX has you covered. These are not WYSIWYG solutions which answers 99% of your question "why". When people want to write a document they want to write things and have the things appear on a page, possibly in different formatting. Injecting ideas like source files, rendering pipeline, etc. will just result in confused people. That's why online solutions like G…

I think my argument is that WYSIWYG needs to die. For the vast majority of people they want nothing more than:

> text

> image

> more text

> table

> more text

There are any number of applications that allow you to write markdown and view the generated HTML in whatever formatting you want. Your recipient then gets to choose their own fonts, colours etc, which from an accessibility point of view, is much better.

Unless you're printing a hardcopy or creating a PDF, what is the point of Word?

Re: Using Microsoft Word with Git

#34

Post by michihuber »

codingdave wrote: post #14

My SaaS deals primarily with legal documents that for years had been maintained with Word. The pain of emailing documents is real, but the comfort level with how Word works is also real. Over the years, most organizations have developed internal workflows to share and send documents around that bypass the pains, and while they may not be perfect, they work. The funny thing is that the document authors like these ways…

I agree with this being about workflows, not documents, but isn't branching and merging a workflow and storytelling tool?

It allows multiple people to work in parallel (and in private). When somebody sends a pull-request eventually, they are presenting a story of changes that they want to get into the document and people can discuss them and approve them individually. (Of course, git the tool isn't necessarily suitable for non-technical people, but git-the-workflow seems to be a good foundation.)

Could you elaborate on what such a tool could look like without git style branching?

Re: Using Microsoft Word with Git

#35

Post by atoav »

codingdave wrote: post #14

My SaaS deals primarily with legal documents that for years had been maintained with Word. The pain of emailing documents is real, but the comfort level with how Word works is also real. Over the years, most organizations have developed internal workflows to share and send documents around that bypass the pains, and while they may not be perfect, they work. The funny thing is that the document authors like these ways…

As someone who is at the intersection of tech and arts one of the things I like about using git in projects is that it is very clear what is the latest official defintive final variant of a piece of data and you don't have to ask anybody to get it.

When I worked as a VFX freelancer I was amazed at the number of hours (=money) burned by marketing agencies who didn't manage to give me the definitive variant for a simple list of things they wanted. In one instance they gave me everything they had, including crude and unrecognisable filenames, hints about things that I should ignore via telephone etc. I had to make sense of it and compile a list which I sent them to approve. They ended up approving another list (!) which they themselves sent me two weeks prior and they only managed to correct this once I hinted at this.

Of course this is a example of saw qhow things should never be. This usually involves somebody getting sick and some uninformed person taking over etc. But what I learned on film sets is that you should choose the defaults of your communication culture in such a way, that it works under the absolute worst conditions (bad weather, hungry, stressed, confused, etc).

And I have seen so many organisations fail at precisely that. If you get I'll someone else should be able to take over without heading to an oracle. This is not a special function limited to a version control workflow, it is something that has to do with clear communication.

Using git can sometimes help avoiding the whole problem by making it obvious which file is the latest and which is a variant of it, the people using it will have to use clear communication as well (e.g. by writing good commit messages, choosing the "right" commit sizes, naming things the right way etc). So if you know how to use git, you just might value clear communications a little bit more than the average person.

Re: Using Microsoft Word with Git

#36

Post by jagged-chisel »

codingdave wrote: post #14

My SaaS deals primarily with legal documents that for years had been maintained with Word. The pain of emailing documents is real, but the comfort level with how Word works is also real. Over the years, most organizations have developed internal workflows to share and send documents around that bypass the pains, and while they may not be perfect, they work. The funny thing is that the document authors like these ways…

Personally, I'd be tempted to write Git for Word as a plugin that Just Worked. Users are given a new interface (The Document Repository?) from whence to select documents. Every auto-save is a commit. Enforce "explaining why" by ... what, requiring an in-document comment near the changes? A popup asking for explanation, and that's added as a commit message?

I don't know, I'm just spitballing. Sounds like it'd be fun for awhile to attempt to seamlessly get this into the workflow and see how it's accepted.

Re: Using Microsoft Word with Git

#37

Post by de_watcher »

codingdave wrote: post #14

My SaaS deals primarily with legal documents that for years had been maintained with Word. The pain of emailing documents is real, but the comfort level with how Word works is also real. Over the years, most organizations have developed internal workflows to share and send documents around that bypass the pains, and while they may not be perfect, they work. The funny thing is that the document authors like these ways…

Commits of a version control have text that explain why, when and who.

I think it's more about the user interface. The user interface of Git is essentially what programmers already do - code.

Re: Using Microsoft Word with Git

#38

Post by achr2 »

mehrdadn wrote: post #8
tinus_hn wrote: post #5

Earlier quoted context omitted.

It’s a zip, that’s not the hard part. Apart from attachments and metadata the actual document is some kind of xml monstrosity that contains the text and the markup. It’s not very useful to just create diffs from that, it looks a bit like the HTML created by FrontPage if you remember that. You can just rename a docx file to .zip, unpack it and peek around.

The XML might be awful for viewing but I do wonder if it would diff better for storage? Git is awfully inefficient for storing binary data.

Not really, as there isn't a linearity or markup feel to the XML. Outside of straight text changes, formatting, rearranging, and internal markups, are not possible to 'visually' diff in the XML.

Re: Using Microsoft Word with Git

#39

Post by anjc »

binbag wrote: post #22

I don’t understand why this 6 year old article has been posted when current Microsoft 365 versions of Word et al have built in version control and real time collaboration.

Yep. They've had version control for at least a decade, diff'ing also, by way of Compare. I'm also not sure why people are fascinated with using git here. It's weird seeing all of the complex solutions in this thread for a problem which does not exist.

Edit: I meant 'fascinated with using git here in this context'.

Re: Using Microsoft Word with Git

#40

Post by shawnz »

codingdave wrote: post #14

My SaaS deals primarily with legal documents that for years had been maintained with Word. The pain of emailing documents is real, but the comfort level with how Word works is also real. Over the years, most organizations have developed internal workflows to share and send documents around that bypass the pains, and while they may not be perfect, they work. The funny thing is that the document authors like these ways…

Interesting perspective. But I wouldn't say I want to use git because I want to branch and merge. I would prefer all history to be linear -- it's just not always possible. My main draw toward git is just for keeping track of past versions along with comments describing the changes (that's what I see as "the story" as you put it). It's nice to know I have merging tools available to help me if I get stuck in such a situation, but I would prefer to never have to merge anything.
Post reply on HN