The Future of the Word Processor (2016)
motherboard.vice.com
motherboard.vice.com
Writing well takes active thought. That's why this quote is, to me, giggle worthy:
>"In 15 years I think the input interface and the idea of a 'document' [will] be entirely reimagined," Chen suggests. "I don't think we'll be at telepathy in that timeframe but I can see a lot more speech and audio playing a larger role for input. Video is already augmenting the document, but VR could be ubiquitous by then."
Formal writing style - especially in long essays - is quite different than spoken word cadences. Basically my point is people don't customarily speak with the same discipline or rigor that they might put into writing. Tack on the issue, in the US at least, of thick regional accents and I really, really don't see Voice Input being the amazing game changer it can be advertised as from time to time (see: Siri).
If only I could convince the non-technical people and management on my team to ditch Word docs... If nothing more, it more make version-control merge conflicts so much less painful to deal with.
WordPerfect didn't use HTML for formatting, because HTML hadn't been invented yet. But it did use its own set of formatting tags, which are more or less analogous. And it had a "Reveal Codes" key you could press at any time to show all the formatting tags that were active in the current document, letting you tweak their placement, add new ones by hand, etc. You could always get directly at the logic that was being used to format your document.
Word's big selling point was that, being Windows-based, it could abstract all that complexity away and let you format documents entirely visually. And it worked! Or at least, it worked well enough for most people most of the time. But the problem with Word's approach has always been that, when it doesn't work, it can be incredibly frustrating to figure out exactly why. Which was never a problem with WordPerfect, since there was no layer of hidden formatting magic sitting between you and your document.
Neither can you really use min-height=20mm. A pity. And the nicer pdf creators (weasyprint) don't understand the new css rules like flexbox or grid.
So we are still stuck. No easy way to force a footer to the end of a printed page via css.
Aren't margin boxes the way to go for page footers and such?
edit: This page recommends PDFreactor, which seems to support at least flexbox https://print-css.rocks/tools.html#pdfreactor
It also helps to turn on the display option "Show all formatting marks". That way you can kind of see the objects and boundaries. Even though you can't directly manipulate those markers like tags in TeX or something they still give helpful clues as to what's happening.
(I'm not trying to defend the usability problems in Word, just pointing out some ways to live with them.)
However, I use those elements as supplements to the written word, not vice-versa (ex: blog spam / slide shows with large image, little text, big ads)
Today we consider their writing formal. Was it that way then though? (I've never actually cared enough about the topic to see if history says anything more)
The formality of the Bible in English can be in large part attributed to the King James version, and other versions of that time period, where you've got the turmoil of the reformation, with the English King as the head of the Anglican church in opposition to Rome, as well as a relatively tumultuous internal political climate, and so a lot of passages were tweaked around to reinforce royal authority.
Modern translations are done based on analysis of the existing Greek manuscripts, not based on the KJV so any political meddling with the KJV doesn't affect the NIV, ESV or similar.
I would also imagine that dictated language and spoken language are somewhat distinct categories, I would rather consider dictation to be an input method for writing rather than a form of spoken language, if that makes any sense. Sadly I don't have any background to actually claim this as a fact, maybe some linguist could chime in?
The only people I've seen (and Ive tracked metrics in stuff like this among large user) using dictation beyond texts and short replies are specialists like attorneys and doctors and people in a bind with injuries.
Personally, i type faster and more accurately than I talk. The 1960 version of me would probably prefer dictation!
We had a long argument about usefulness, because as a Writer, I carry a small notebook and pen. Our joking back and forth went over stuff like "Battery Life" (Phone has a concern, notebook does not) and "Water Resistance" (neither scores that great), "Cost and Maintenance" and so on and so forth.
For my needs - writing notes - the little old school approach won, but it was inferior for his needs.
Disclaimer: I'm working on a knowledge management app thats core focus is connections and tagging (amongst many other useful features)
Sure, but it's not clear that forcing all of that thought to happen before the first draft actually improves the final result. Many writers feel they need to bang out a shitty first draft and that much of the magic happens in later revisions.
> Tack on the issue, in the US at least, of thick regional accents and I really, really don't see Voice Input being the amazing game changer it can be advertised as from time to time
I often experience a funny phenomenon. A lot of times when I'm out for a walk or a long drive, I'll start thinking about fiction ideas. Before too long, my wandering mind drills down to what I think is an actual internal monologue of prose. In my head, it flows smoothly and sounds compelling.
I always mean to start writing it down when I get home but never seem to find the time or discipline or whatever to do so. Maybe already being in the middle of a 200k-word nonfiction book has something to do with that...
What I've always wondered is if I am actually narrating real words or just sort of imagining that I am in that way that it's always easier to imagine a drawing than it is to draw it. The real experiment would be to get a recorder and start dictating, but I never have. If I did, would that work?
If so, than it means I might "write" works in this way that for simple practical reasons would never come about at all without the speech recognition. Even if I were to summon the discipline to manually transcribe my inner monologue, would something be lost in the translation? Or gained? Or both?
Speaking out loud while thinking is a good exercise, and more difficult than just thinking. But when I do it ends up in a conversational style, as if I was giving an talk to tech colleagues.
Also when I am in Germany, I find it very easy to "think in German" even though I can't speak properly.
I've come to like Geany, because it's simple, but has spell check. I don't have much need for layout, beyond HTML.
To that point, the essay "Shitty First Drafts" by Anne Lamott, 1954 is a great essay on the importance of shitty first drafts.
https://www.google.com/url?sa=t&source=web&rct=j&url=https:/...
This little thing was perfect. A 4-line black and white LCD screen with save files and no frills. Push the power button and start writing. Use AA batteries that last forever. Practically indestructible - toss it in a backpack and go.
[0] http://lowendmac.com/1999/alphasmart-2000-a-different-kind-o...
i think many observers say that reader preferences are trending to a more conversational style these days anyway.
and, if you have an iphone, you can use the dictate command on the keyboard to input into the notes app. you need to do a fair bit of editing, it's true, but many first drafts require that anyway.
so all in all, i think that dictating your first draft is a pretty smart idea, especially if these conversational flashes happen to you during a walk, and also if you are prone to forgetting them before you get them down.
for instance, i dictated the first draft of this comment on my walk just now, and then emailed it to myself to post it here. i cleaned it up, of course, but if you want to see the original, as is, i posted it here:
Even if that is true, actual conversation is full of digressions, half-completed thoughts, repetition, incorrectly chosen words, etc. It's remarkable how incoherent a transcript of speech can look compared to how coherent it sounds listening to it (Donald Trump is a prime example of the phenomenon, as an untrained public speaker).
here's what prompted that:
> when I'm out for a walk or a long drive, I'll start thinking about fiction ideas. Before too long, my wandering mind drills down to what I think is an actual internal monologue of prose. In my head, it flows smoothly and sounds compelling. I always mean to start writing it down when I get home but never seem to find the time or discipline or whatever to do so.
But it's only recently (two century or three) that grammar and spelling are the fundamentals.
Everything is much simplified if you just avoid this weaving altogether, and adopt a content pipeline approach, as every commercial book publisher, newspaper and magazine does. In this approach, you use pure-composition programs for your composition, and pure-layout programs for your layout. When you are working on one, you are not distracted with the demands of the other.
In fact, two different people can be working asynchronously on these two components; and, indeed, if the work of one stage is finished first, this enables an extremely useful static constraint on the work of the other, simplifying the decision-making for it greatly. Layout can determine target word-count; or word-count and paragraph composition can decide layout.
What you don't have is the constant tweaking, pitting half-finished layout and half-finished prose against one-another. Each is effectively opaque to the other until the end of the process.
The most wonderful thing that has happened to composition in recent memory is the GUI Markdown editor. Until these, all composition programs that weren't simply plaintext, had at least some layout elements. (This is because their target format was RTF, and RTF contains things like per-line margin settings.) But .md is a fine format for storing compositions: it lets you specify the "tone" of text with markup, but contains no mechanism to (reliably) specify final appearance.
Combine such documents with a program like Publisher or InDesign (or, partially, LyX or Pages) for layout, and you've got a very nice workflow. And, as a side-benefit, the prose created during the composition step will be exactly what is needed for web publishing as well.
Not to me. I was so happy when I tried MacWrite on my new (early 1984) Macintosh. I enjoy "fighting myself" because I am very unwilling to separate content and appearance. InDesign provides me with some succor but nowhere near what I would like. It is not visual enough. Why can't I align text by dragging a vertical line onto the text and request alignment to that? After all, this can be done with figures in InDesign, and unlike tabs, you get an immediate sense of what the result of the alignment will look like.
(A sad setback in word processing is Apple's Pages. It has two modes "word processing" and "page layout". I hope Larry Tesler never encountered it.)
Changing the text layout automatically re-flows the text across the text boxes. That means: adding/removing a text box; editing the properties of a text box; changing the content in the linked RTF; or moving another element to partially overlap a text box, when the box is set to make the text dodge intrusive elements. You don't have to worry about resizing a text box to make room for something; that text just appears in the next box and pushes everything down.
And changing the visual layout does absolutely nothing to the text. That is: moving any of the text boxes, or moving/creating/destroying any element other than a text box, as long as this doesn't affect overlap; editing text boxes of a different linked document, or static text boxes (e.g. a masthead); etc. So, visual design tweaks are guaranteed not to wreck a finished typography pass, even if that means you're sliding the margins around.
For the sake of anyone who hasn't tried a system like this: picture creating an HTML CSS layout, with your composition embedded in a <div> with `overflow: scroll;`... but then picture a magical new <viewport> element, that provides distinct viewports onto a single scrolling container's render-context at different (contiguous, non-overlapping) scroll offsets. You could use such an element to implement CSS columns—but also any number of other arbitrary layouts.
Thank you for getting back to me.
the main reason they do it that way is because they have different people doing the writing and the layout tasks.
but the writers of today and tomorrow are much more likely to be self-publishers, who are pricing their work such that they don't have the margin to employ others to do layout.
now, it's true that some people are incapable of doing both tasks at once, and find themselves procrastinating by doing one task when they should be doing the other.
those people will have to learn how to fix that bad habit.
but it is equally true that other people are quite capable of doing both tasks at the same time, and they'll typically do the complete job in much faster time doing both at once.
and they often end up doing a much better job too, because they're working with a tight feedback loop between the tasks.
now, i do agree with you that a light-markup editor can enhance such a feedback loop. a 2-pane setup, a la the ghost interface, requires the entry of clean text and couples it with a display that lets a writer confirm they will get the output they want.
(indesign is outdated. if you need a .pdf today, repurpose your .html using prince, renting it on a monthly basis via docraptor. that way, a single input creates .html, .epub, .mobi, and .pdf.)
You realize that I'm not talking about a problem that you either have or you don't, but one that everyone has to some degree, right? Anything that's a matter of willpower, some people will have less of; and, in fact, everyone will have less of as things happen to them that deplete their willpower throughout the day. Consider the needs of "you at 4:30PM on a Friday"—they find it much harder than you do to be productive, right? Well, that's why things like distractionless editors exist. So motivated-you can make a choice (use a spartan editor) that boxes unmotivated-you into having nothing else to do but work.
> and they often end up doing a much better job too, because they're working with a tight feedback loop between the tasks.
I do agree with this. But keep in mind that you don't need any special kind of program to accomplish this. You can have your (auto-reloading-text-boxes) layout program open in one window, and your (auto-saving) composition program open in the other, maybe across two monitors. Works just as well, and—unlike a "composition with preview" style editor—the "preview" pane is instead a real WYSIWYG editor for the layout and typography, as well as showing the state of your composition.
> indesign is outdated
Yeah, true. It's better to have a format that actually produces digital-native results as well. It's (sadly) not usually feasible in large orgs, given that there are separate teams with separate skillsets that want to take one composition as input and run it through two separate (web and desktop) publishing pipelines. Even if you can align them all on the same software, attempting to do any "layout rule-sharing" is a lot like trying to get the mobile and desktop frontends of an app to share code.
> repurpose your .html
That's one (valid) approach, sure. The other one (that I personally favor) is to start with the print layout, in a desktop publishing program that happens to use a layout format that is a superset of HTML+CSS, which gives you the ability to add CSS media queries to said document to specify how it should render when exported as an ePub or as HTML.
One example of such a digital-native desktop publishing program is iBooks Author. You get a proprietary, fixed-layout "rich eBook" format from it by default; it exports to PDF at full fidelity (though you lose some TOC metadata); but it also exports to ePub and HTML.
It's honestly a shame that the EPUB 3.0 standard hasn't seen traction or gotten an equivalent authoring experience from anyone, because it's basically the same idea but not proprietary. It's a perfect "mother format" to reduce down to assets for every kind of content channel you'd care to use.
i don't see it that way. i especially don't see it as involving "willpower". i see it more as a specific skill.
now, as i said quite clearly, some people lack the skill. and some of those people will be totally unable to learn it. the most unfortunate ones should adopt your 2-stage workflow.
but most people can learn to drop the procrastination habit and pick up the skill of simultaneous writing and layout.
plus, on the other side, some people thrive on that method. not just do they not "have a problem" with it, to any degree, but they actually perform better when they work in that way.
> It's (sadly) not usually feasible in large orgs, given that there are separate teams with separate skillsets
i agree that such organizations won't change their workflow.
but i'm not really all that interested in empowering _them_.
> iBooks Author
> It's honestly a shame that the EPUB 3.0 standard
it's much better if i don't get started on either of those topics... :+)
1. Stickiness.
Google Docs (and even Microsoft Word) work so well when you use them in conjunction with their respective ecosystem. Many users choose Google Docs over Dropbox Paper simply because they already have Google Apps accounts, even though as a product what they really want is something more like Dropbox Paper.
Inevitably, what happens is that those who can try out a new product on a small team do so, but those who are forced to work between teams or even between companies choose the solution they're already using; i.e., the stickiest.
2. Plain text is powerful
I'm sure I'm preaching to the choir here, but each new "office productivity" or "word processor replacement" tool comes with it's own silo. Even Microsoft Word, which has it's own file type that you can save to your Desktop, is largely a proprietary format. You can export data out of Google Docs or Dropbox Paper, etc., but the idea is that you're leaving the promised land. You're packing up and moving somewhere else.
On the other hand, we know from the Unix philosophy that plain text is a universal interface. Using plain text can help us escape these siloes. The problem, of course, is that from grade school we teach students that to edit text we use Microsoft Word.
There are a lot of cool new products in this design space of "word processor replacements," but few which tackle these two fundamental issues.
But once again we see this described as "exporting." The focus is on the silo. You're in the silo or you're not. Rather, the focus should be on the data, and applications should merely manipulate them.[^1]
[^1]: In many ways, there is a similar distinction between programming models. For example, in an "object-oriented" style the object owns the data and the functions on that data. In a "functional" style, the data exists, and there are functions on that data. The analogy isn't perfect, but at least it sheds new light on the word processing issue.
Rich-text, WYSIWYG editors give people more of a feeling of control and perceived ability to see the big picture. Sure, we can argue that this impression is largely superficial and adds more distraction than anything. But that's because we're experienced computer users who know that "code" directly relates to what WYSIWYG displays, i.e. WYSIWYG is just a middleman. But this is something that has to be experienced to really be grokked. If it weren't for sites like CSS Zen Garden that made it clear how style could be completely separate from content, I'd probably still be making pages in Dreamweaver today.
At school, pupils are taught Microsoft Word most often, and LibreOffice at best. They know nothing but WYSIWYG and separated applications that don't talk to each other (Microsoft Office can be scripted with VBA, but they don't know that).
The fundamentals of computing are not taught. File formats are not taught beyond "this app opens that format". Plain text is that ugly stuff you read with Notepad. The internet is accessed with a web browser. And so on.
---
This needs to change. Computing education should be expanded, and other curriculum should be cut or adapted accordingly:
Data formats should be taught. HTML could serve as a first example: you can view it online, you can save the page and view it offline, you can view the source with ctrl+U, or even modify the source with Notepad (Kudos if your school uses a free operating system, but let's not require it right away).
Rudiments of programming should be taught. Something like Human Resource Machine (a coding game in pseudo-assembly) could serve as an introduction —or we could stop there, that game is pretty complete. Now that's quite a heavy topic (I expect Human Resource Machine alone would take a whole semester), so I propose we use the Math class for this, and cut on other math topics (I'm not sure which, though).
The internet and the web should be taught (and not just used). I believe the English class is most suited: the internet is mostly about reading and writing (YouTube notwithstanding). We should cut down on classical literature and literary analysis, and focus more on information processing (reading more or less reliable stuff and come up with reliable information), and public writing. If there's a class that ostensibly teaches citizenship, it should be used to teach public debate, which are arguably more important than the arcanes of your country's constitution.
i just think that kids spend enough of their time on regimented learning. nine hours a day plus homework. we should stop inflating the curriculum and leave some of their mental energy in reserve so they can spend it on self-driven freeform learning and hobbies.
I do not propose we teach actual programming to kids. Just the fundamentals of computational thinking, for which an introduction to programming may work really well, and I expect 40 hours will be more than enough. Even a couple hours may be enough.
Computers pervade our lives. They're becoming the medium through which we do everything. We'd better learn to control them before they control us (I'm thinking of golden cages like the iStuff, and surveillance/advertising machines like gMail and Facebook).
The printing press allowed the people to read. The internet is allowing the people to write. Such a fundamental change in communication structures is bound to have similarly profound effects. But first, people need to learn to write. School isn't the place for that. So far, my best writing school has been public internet forums. School only taught me the very basics, then went on having me read novels I didn't enjoy. Before 1995, this was fine. Less so now.
https://reddragdiva.tumblr.com/post/127964136013/it-turns-ou...
https://reddragdiva.tumblr.com/post/137374628373/scratch-is-...
https://reddragdiva.tumblr.com/post/137376311558/scratch-is-...
Apparently it's not just the academically bright kids, the middling ones get it catching their attention too.
Later they get taught "textual languages", which I'm pretty sure will be Python.
They also get taught to use the office apps - but they are introduced early to the concept that these machines that civilisation runs on are things they could tell what to do.
The rich-text, WYSIWYG interface shows the data people want to interact with; they care about the text in their document and how it is formatted on the page, not how it is stored on disk.
So I disagree with z1mm32m4n about the power of plain text. Plain text is useful in Unix because as a storage format it corresponds to the usage pattern of typing text into a terminal; meaning interactive data entry and reading from a file don't have to be different.
But plain text is a lie on all modern Unix systems, it has been replaced by a mix of text and escape codes. Recently I tried to cat initial-commands.txt - | some-interactive-program and did not get the expected result because the pipe between cat and the program was not a tty. (The solution was to use script to enforce tty-like behavior.) The reason these escape codes exist is that people wanted more than plain text could give them (e.g. color).
However, this is not to say that a universal storage format for data of a kind (e.g. formatted text) would not be useful to avoid siloed applications; if you are working with data that already has a standard format, inventing your own and requiring import and export for everything else is just silly.
This is exactly why walled gardens are terrible. It's killing innovation and actual improvement in this case.
There's a growing class of editors that strive to provide a richer document experience while still relying on plain text as the file format. I don't usually suggest normal people adopt it, but an example of this kind of hybrid approach is Orgmode in emacs. I can do ALL SORTS OF THINGS with my org files, but the actual data is still just plaintext with minimal and human-readable markup. The editor does the rest of the work.
I find that promising.
There was an (astute, I think) article from "Joel on Software" years ago saying that the main reason that supporting the Word format was hard was that, by implication, you needed to implement every feature Word had to do it right.
Again, Orgmode is a great example. I can (and sometimes do) use my org files outside of emacs.
a plain-text light-markup file -- easily read, parsed, and rewritten when necessary by a plethora of apps (text-editors, spell-checkers, grammar-checkers, link-checkers, sanitizers, validators, on and on) -- is a big advantage (gargantuan!) over a complex xml-format document stored in a .zip container.
and editing and ease-of-use (and re-use and repurposability) is much friendlier as well.
But you can get pretty far down the road. That's my point.
light-markup will never do everything ms-word does.
nor should it.
but typical light-markup systems these days handle all of the features needed for the vast majority of long-form documents which are now being produced -- books, annual reports, scientific articles, etc. -- and do it with an eye toward mounting on the web.
whereas ms-word is still stuck in a page mentality, and creates .html output which is rather horrendous.
but i agree that ms-word is still valuable to many.
and i no longer feel it necessary to bludgeon word for being the "de facto default" out in the world, where everybody uses it because everybody uses it, and nobody can use anything else because "conform".
so if someone needs one of the "does more" things where ms-word does more, i'm glad they have word. it's a tool in their chest, no reason to begrudge. i'm happy, even, that word has true fans like you.
i'm also glad the rest of us can move on now to something that we think is better. it's about time.
ms-word can support those things as well, but only when you bring its proprietary format into its proprietary, closed-source app, which is not free of cost. the silo only looks better when you are locked inside it.
it's fine to prefer ms-word. prefer whatever you like. but think clearly and fairly if you start to bring up objective comparative advantage.
and i like the simplicity and flexibility and freedom of plain-text as my format of choice. but if you or anybody else prefers something different, i urge you to take that path.
1. not siloed in a binary format, i.e. could export to a plaintext-ish format
2. had a gui for those who want it
3. had seamless citation/bibliography tools, e.g. based on Citation Style Language (CSL) & web lookup e.g. on Google Scholar & PubMed
4. had seamless integration for Figures + numbering/captioning, Tables + numbering/captioning
I would pay lotsa $$ for it
I know LaTeX tools and/or pandoc tools can accomplish this but they are not user friendly enough
http://kitchingroup.cheme.cmu.edu/blog/2014/08/08/What-we-ar...
Here is a youtube video demonstrating use of the org-ref extension for citations and references:
That said, I absolutely do composition in tools other than Word most of the time unless I know I'm writing for print or a print-analogue (we deliver lots of work product as PDF, which may as well be printed).
What I care more about than print or nonprint, though, is file format longevity, which is why most of what I do is in plain text. That's an orthogonal concern to the issues of the piece, but it still bears discussion given how much data over time has been lost in orphaned formats.
Before we had semantic markup on the Web, Word was doing something similar with meaningful styles that could drive document structure and whatnot. It's astonishing how often I see people either manually format headings (like, referencing a postit that says "heading: bold, 14pt") or use unstructured styles instead of the actual heading options.
Word will give you a document outline in a "slide out" window that populates based on your headings. It can be HUGELY USEFUL when you're building a longer, more intricate document, and yet it's rarely used properly. It's baffling.
The first time I used semantic style structure in a Word doc was in Word for DOS in about 1992.
Then copy/paste into word, or preferably something else for formatting.
Too many distractions in a modern word processor.