[txcwpalpha]

>My professors would have been very confused if I had sent them anything other than .doc(x) for review.

This, in particular, is the most important point. The parent commenter says "I prefer to let the final production medium to dictate the production process". Well, in the vast majority of cases, .docx is the final production medium. Most people use MS Word as both a document editor and a document reader.

I've worked at many companies and very rarely is any of the work product "finalized" into something like a PDF or a magazine. 90%+ of our work is meant to be continuously iterated on and added to over time, meaning it needs to stay in .docx. This applies even in the tech world, where things like design documents, project plans, etc are all used as well.

[kijin]

Moreover, I think the trend you described will only become more popular as the world moves away from printed media.

When STEM people think of a "final production medium", they usually think of articles in journals. But who reads paper journals anymore? Most people who are active in their fields don't even read PDFs of paper journals; they've already seen the preprints on arxiv. We're all just exchanging tarballs of source code, and nobody is compiling anything.

The thing I like the best about Microsoft Word is the review feature. Multiple people can edit, annotate, and comment on specific parts of the same document. You can inspect each diff and either accept or reject it. Everything is color-coded and can be manipulated using a mouse. It's like commenting on a github commit, but much more intuitive for people whose job is to exchange human-readable documents, not source code.

[kqr]

> The thing I like the best about Microsoft Word is the review feature. Multiple people can edit, annotate, and comment on specific parts of the same document. You can inspect each diff and either accept or reject it. Everything is color-coded and can be manipulated using a mouse. It's like commenting on a github commit, but much more intuitive for people whose job is to exchange human-readable documents, not source code.

This is an interesting perspective! I author in plain text, and when collaborating, I prefer using what's essentially the Phabricator code review workflow to elicit comments and improvements until the change is fixed.

Working with changes this way is useful in that it atomises and comparmentalises changes, so the history is easier to inspect after the fact. And so far, few people have found it unintuitive -- they don't even know it was designed for source code in the first place, they just like that it's clear what's expected of them at each step in the process.

I think sometimes it's easy to underestimate how good tools for programmers are, but it's easy to see why: in any field, if you want to find good tools, look at what the toolmaker has to use. I think a lot of people would prefer the programmer tools if given sufficient polish and the proper introduction.

[kijin]

Programmers' tools are great for dealing with plain text, so if you write plain text, good for you! But other people often deal with things that aren't plain text, and I don't think it's a good idea to try to squeeze them into the lowest common denominator just because it's more natural for us.

It's easy to underestimate how much meaning ordinary people bestow upon layouts, colors, and other stylistic choices that programmers often think is frivolous. I think we should focus more on how we might design tools that allow people to work together effectively on non-plain-text content (rich text, photos, videos, you name it) than how we might convince everyone to adopt our plain-text tools.

[welly]

I think you overestimate the technical ability of many users who are using tools such as Microsoft Office (or Libre Office), given many of them struggle even with those tools never mind anything more technical.

[kqr]

Those tools have interfaces that have remained virtually unchanged since the infancy of personal computing. I highly doubt they represent the pinnacle of user interaction.