Earlier quoted context omitted.
Home Edition: "People are familiar with using Office at work, so they'll probably want to use Office as well when it's time to design that Garage Sale flyer." Student Edition: "Give them Office now at a discount, and they'll keep using (more expensive versions of) Office when they get a real job." Office is named Office for a reason. Its entire existence revolves around the typical 20th-century white-collar office. A…
Instead of being cynical, maybe consider the fact that students find it easier to type essays with Word than with other products, so Microsoft gave them a discount so they could afford it? Win-win. Just a thought.
Why Microsoft Word must die
331–340 of 387 posts
Re: Why Microsoft Word must die
#332Earlier quoted context omitted.
No offense, but using git for collaborative writing? That's like using nukes to get rid of mosquitoes. SVN would be a poor but better choice, but you'd rather use stypi, google docs or something like that.
that's a dumb thing to say. It's reasonably frequent that the best tool for a job is one that scales from the smallest possible use case (individual) to the largest, smoothly and without hassle. Git fits this criterion. SVN is a real pain by comparison.
Re: Why Microsoft Word must die
#333Earlier quoted context omitted.
I can not think of any scenario where svn would be preferable over a distributed vcs such as git or mercurial. They can both be used exactly the same way as svn if you feel for it but come with tons of other benefits. I even think there's less friction to start with for non techincal people because you are always working in "everything always checked out"-mode and there is no need for a common server. Just let them e…
>I can not think of any scenario where svn would be preferable over a distributed vcs such as git or mercurial. After forgetting to push after commit and then dropping your laptop, you'll know.
Re: Why Microsoft Word must die
#334Earlier quoted context omitted.
Last time I checked not even Microsoft Office implemented the version of OOXML they forced through ISO which somewhat undermines your point. http://adjb.net/post/Microsoft-Fails-the-Standards-Test.aspx Note that post isn't written by some random GNU fanatic, but one of the key figures involved in the standardization. "The simple validators developed by me (Office-o-tron) and by Jesper Lund Stocholm (ISO/IEC 29500 Val…
This was 3 years, a beta, an entire office version and numerous service packs ago... Not only that it complied to transitional schema at the time. Office 2013 supports full strict compliance. Office 2010 can read strict and write transitional. Transitional will be deprecated when Office 2010 is EOL (2020). Get your facts right.
ECMA does that for a living but they only got away with it at ISO because Microsoft promised it was only for legacy documents and they would fully comply with strict. It looks like they're at least claiming strict conformance for output in 2013 (as the blog notes basic tesing showed they couldn't even document their own output correctly in 2010).
And you're proudly claiming that they'll phase out the production of documents they described as only for "legacy" in 2008 a mere 12 years later.
They destroyed the credibility of the ISO to maintain their format monopoly.
Re: Why Microsoft Word must die
#335Earlier quoted context omitted.
Actually, that's what I was trying to say. Word's review functions appear as pretty colored bubbles and a bunch of icons on the Ribbon. It's easy enough even for Humanities professors to use on a daily basis, despite the fact that as a VCS, it's strictly inferior to something like git. Actually, I think it's popular precisely because it ain't git. Most professors who are fluent in Word's review functions would be hop…
I think you're absurdly underestimating people. A diff is a bunch of lines removed, and lines added. That's a pretty damn natural representation. As for git's complexity, it's all in its completely opaque display of its internal state. A chain of deltas - diffs - isn't complicated. It's all git's (perverse) desire to follow the exact-same command-line interface as cat and awk, when neither contain persistent state.
Word shows pretty bubbles next to sections that have been edited. The bubbles are color-coded so it's easy to tell who did what. The edits can be accepted, rejected, or further modified with a couple of clicks. There is no list of commands or keyboard shortcuts to memorize. Just a bunch of icons, menus, and clicking around.
Word doesn't require your content to be made up of neat lines of verse, either. Natural languages don't organize themselves into 78-char lines. It should be OK to edit a few words in a long paragraph of prose. Even Wikipedia's messy "Revision History" is probably better than git in this regard.
Re: Why Microsoft Word must die
#336It would be possible to grow a tool infrastructure around Latex (and/or Context) to eliminate the practical problems working with that system, but at present it does not exist.
Word's support for change tracking is very good. Change-tracking is a very different thing to version control: version control is about storing and reconciling difference versions of a file, while change tracking is about communicating the changes made for the other person to check. If I edit your text, I can switch change tracking on and off, so that the relevant changes I have made to your writing are visible for you to step through one-by-one, while the changes my macros made to make font choices consistent are untracked, so will not waste your time when you review the text. If version control and change tracking overlap somewhat in functionality, they have different uses and fundamentally different semantics.
Re: Why Microsoft Word must die
#337I'm surprised nobody mentioned Pages on a Mac. It's a style sheet-based tool, where the styles are quite easy to work with. I've been using it for years now and it does almost everything I need it to do. I realize there are people who absolutely need every little feature in Word, but for things like letters, technical reports, briefs or software documentation Pages works just fine, and produces nicely-formatted docum…
> I'm surprised nobody mentioned Pages on a Mac. It's a style sheet-based tool, where the styles are quite easy to work with. ... Pages works just fine, and produces nicely-formatted documents. Microsoft Word is also a styles-based tool, and produces nicely-formatted documents that are consistent with a stylesheet. The problem is that people don't use the styles.
I only needed to style H1, H2, P, EM and possibly A (they don't have those names in Word, but you get the point). That's probably the simplest document structures you can have for a task that reasonably makes use of styles.
The biggest problem was, those styles are like liquid, slipping between your fingers as you work with them. You do one thing to the text and suddenly you find yourself in a style that's "adapted" from a style you've already defined, I think I've even encountered a new hybrid style between two of my user-defined ones. And then there's of course the "built in" paragraph and heading styles, occasionally thrown into the mix as well.
The point is, this is not at all like an actual style sheet based way of working, such as with CSS/HTML. You could get the above result by using (bad) code such as
OOPS
, you'd also get a mix of three styles. But the thing is, in Word, all these new hybrid styles got added to the style sheet!So get this, I wrote part of a document, decided (as long as I have to do this in Word ..) I'd use style sheets, made the styles, continued writing on the document and the existing styles changed as I moved bits of text around.
Not having exactly that happen, is one of the main reasons to have a strict separation of content and style in the first place, is it not?
I'm sorry but, I don't think Word actually supports "styles". It's got some stuff that kind of looks like styles, but once you actually try to use it, it'll just waste your time at exactly those moments where you'd expect a proper styles system to save you time.
At some point I had finished the content and I decided to make the H2 a bit bigger font. With styles that should be the easiest thing right? Haha! Right. That's when you get to see all the adapted styles that suddenly appeared in your H2's markup, and they don't change along. So instead of just changing your styles, you are going to have to edit your document content anyway.
The whole experience was very, very messy. In hindsight I'd have preferred to keep the "style sheet" in my head and apply all the markup manually, like most people do, instead of relying on the program to take care of this for me, but wasting my time instead. No wonder that's the route most people seem to take.
(disclaimer: this experience was a few years ago, maybe they fixed it by now and styles are actually styles and don't change while editing your content, and are in fact either applied to some part of the content or not, and not somewhere in between)
Re: Why Microsoft Word must die
#338What's crazy is that most briefs are actually just a series of links: cite to Case A, B; cite to document C; cite to statute C...Sometimes attorneys will make "e-briefs" to actually link PDFs, but those usually cost thousands of dollars to manually generate.
I'm working on an open-source court filing project that would let attorneys and the court write and post everything in an electronic format for easy linking and search. Think of it as a free, universal ECF/PACER for state courts. If anyone is interested in helping, feel free to drop me a line.
Re: Why Microsoft Word must die
#339Earlier quoted context omitted.
Actually, that's what I was trying to say. Word's review functions appear as pretty colored bubbles and a bunch of icons on the Ribbon. It's easy enough even for Humanities professors to use on a daily basis, despite the fact that as a VCS, it's strictly inferior to something like git. Actually, I think it's popular precisely because it ain't git. Most professors who are fluent in Word's review functions would be hop…
I think you're absurdly underestimating people. A diff is a bunch of lines removed, and lines added. That's a pretty damn natural representation. As for git's complexity, it's all in its completely opaque display of its internal state. A chain of deltas - diffs - isn't complicated. It's all git's (perverse) desire to follow the exact-same command-line interface as cat and awk, when neither contain persistent state.
It is a horrible representation for stuff where edits may consist of both typo fixes, and separate wording changes in a single sentence - where you might want to accept change to one word and reject change to another word, despite that they came from a single "commit" to a single line.
For collaborative text editing both word's track changes and google docs features are far superior to git.
Re: Why Microsoft Word must die
#340Earlier quoted context omitted.
>Microsoft Word was never designed to be an ideal tool for creative writing, programming, or any such thing. He pointed that out. And he pointed out that the industry was still foisting it on him. That is why he wants it to die. This was the summary at the end of the article in fact.
Then shouldn't he be far more mad at his industry, not the tool?