Pretty fun article. I did a major Research Paper on slowing down the English "writing process" on purpose to focus more on fundamentals (grammar, spelling) without the assists of modern technology. Start with quill, eventually get to typewriter.
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).
> Writing well takes active thought. That's why this quote is, to me, giggle worthy
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?
For anyone doing a double-take on the essay's title being outlandish for 1954, that's her year of birth and this essay is an excerpt from her 1994 book Bird by Bird.
I have these monologues too, and they are far better written than anything that comes from my hands. So I am pretty sure I am composing in "mentalese" augmented with just enough English to fool me into thinking I am making good prose.
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.
When I'm starting a piece, I typically bang out whatever comes to mind. I keep at that for a while, and then rearrange it, as a crude outline. Then I flesh it out. Often, first thing in the day, blocks just come out, as if someone is dictating to me. Sometimes, I wake up seeing printed text. Then I go back and rewrite, and shuffle as needed.
I've come to like Geany, because it's simple, but has spell check. I don't have much need for layout, beyond HTML.
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!
A friend of mine is an extremely talented developer (between jobs actually) and he loves his tech gear. Specifically smart phone tech.
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.
Digital becomes a real boon when you are creating knowledge networks; connecting pieces of information, or tagging them. This metadata is, as far as im aware, best suited for being stored digitally.
Disclaimer: I'm working on a knowledge management app thats core focus is connections and tagging (amongst many other useful features)
One of the better pieces of advise I got in college was to use dictation to make a rough draft. Basically explain what your topic is about as if you were telling a friend, or get a friend and explain it to them. Then go back and edit.
Huh. Interesting. I'm going to have to try that. Sometimes the writing process does get in the way, as speech allows for faster changes in thought and direction than writing or typing, I feel. Which makes it good during the brainstorming phase.
The best writing I ever did was on an Alphasmart 2000 word processor [0]. I'm way better at getting my thoughts down using a keyboard than pen and paper, but computers are just too distracting.
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.
> Formal writing style - especially in long essays -
is quite different than spoken word cadences.
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:
> i think many observers say that reader preferences are trending to a more conversational style these days anyway.
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).
nobody talked about dictating "true, actual conversation".
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.
While I'd concur in your skepticism about voice specifically, I still think documents are becoming increasingly multimedia, with elements such as video, interactive elements, graphs and tables etc, and I feel like traditional word processors, which are the go-to tool for many people for authoring, are woefully inadequate to handle such rich documents.
Most of the time, I feel like it would be easier to write HTML markup to style documents than it is to poke and prod at the Word formatting options. In college, when I was routinely having to write papers that needed footnotes and specific formatting styles, I nearly broke down and learned LaTex, I got so frustrated. And, with HTML, it would be trivial to add in the types of multimedia elements you mention.
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.
The funny thing is, what you're dreaming of is basically WordPerfect, the word processor that ruled the world for many years until Word came along and killed it.
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.
I find that to work effectively on large Word documents you really need to understand the underlying object model. Everything is an object, and the objects fit together in reasonably consistent ways. But when you don't understand the model then it seems like things happen randomly to the document format for no good reason.
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.)
Do you know any visual (dare I say wysiwyg) HTML authoring tools that adhere and emphasize semantically sensible markup and working efficiently with styles, especially in the context of using some predefined corporate templates? Something that captures the few good bits from Word and applies those to HTML based document model?
SharePoint was a great asset for my proposal team over in Finance for version control issues and Word compatibility. Not a cure-all, but it worked for the non-technical folks well enough (and saved a lot of heart burn).
If only we had a decent way to print those html pages to pdf. But It seems like the print-css is kind of neglected. The stuff barely is doing what it should(page-break and friends).
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.
Actually I will do my best to agree with you outright on the multimedia front! I'm a huge fan of Medium (70+ pieces on there) because of the freedom to intermingle material with the text. It's quite powerful.
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)
> Pretty fun article. I did a major Research Paper on slowing down the English "writing process" on purpose to focus more on fundamentals (grammar, spelling) without the assists of modern technology. Start with quill, eventually get to typewriter.
But it's only recently (two century or three) that grammar and spelling are the fundamentals.
Some portions of the bible were written by a scribe who took dictation. Sometimes they took the pen to write something important in their own hand, (normally a closing), but most of it was not written this way.
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)
Forget the Bible -- "take a letter please" was an almost stereotypical expression associated with executive types and their secretaries. Dictation to a human secretary was a more common form of "input" for the executive class than writing the letter oneself; personal computing was met with some resistance by corporate execs in the 70s and early 80s because you had to type at a PC to operate it, and typing was viewed as a skill used by secretaries, clerks, and other such minions.
The way that the Bible reads today, in English, after countless revisions and reformulations, translations and copyings, is so far removed from the original Greek or Aramaic that it's almost inconceivable that the words on the page are even close to what was written two thousand years ago.
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.
True but unhelpful, since Aramaic had riches and critical distinctions that have been dropped entirely or conflated on the way through low ancient Greek and into older English. For example, four or five different words with quite different meanings have all been rendered as "forgive" or "forgiveness" in the KJV translation making a contradictory and uninformative mess. (Philosophically speaking - it's still great if not entirely comprehensible poetry.) Given how central the Bible was to that concept, the KJV also impoverished our language, setting up an impossible problem for translators and helping to make us all much more ethically moronic than we'd otherwise be.
And how many revisions of editing (and translation) has the text gone through from the point of dictation to the current day when we consider it to have formal style? I wouldn't be surprised at all to learn that even the scribe would perform significant amount of editing on the fly to construct reasonable structure.
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?
US regional accents are pretty mild compared to what you would see in some other languages (and even to some extent to what you'd see in English in some other places).
I have a friend who is a professional translator and apperantly speech to text is heavily used in that field (and thus translators often benefit from having quite beefy PCs).
That seems odd, since translators are usually concerned with written, rather than spoken material (the latter generally being the province of interpreters).
"Word processors" were always a stilted compromise; they try to weave together the acts of composition and layout, when each necessarily constrains the other. As you compose a document in a word processor, you end up "fighting yourself"—making changes on the composition side that require matching changes on the layout side, or vice-versa. And not only this, the two tasks are mutually distracting—fiddling with layout after writing a single sentence can be used as a means of procrastinating from writing the next sentence; and endless copyediting can be used as a distraction from deciding on layout. A program that functions to do both tasks concurrently, is often far less than the sum of its parts, in productivity terms.
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.)
I don't know how you're laying out text in InDesign, but in the workflow I was speaking about above, you draw a set of "text boxes", link them into a sequence, and then drop an RTF file onto one of the boxes to create a live link between the boxes and the RTF document's content. You then align text to things like guides/rulers by snapping the boundaries of the text boxes to those guides/rulers.
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.
I do understand the workflow you outlined, but I don't follow it, because I don't like it. In InDesign, I just open up a text box and start typing. Once I am within a text box, however, my irritation begins. I don't want to use tabs to align text. I suggested an alternative in my first post.
> adopt a content pipeline approach,
as every commercial book publisher,
newspaper and magazine does
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.)
I don't see self publishing happening on a large scale. The publisher is a reference for the work, and also they know all the details about layout and formatting (how many knows how to use em-dashes, en-dashes, and hyphens?), and have professional editors.
> those people will have to learn how to fix that bad habit.
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.
> 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?
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... :+)
But in fact word processors like Word provide everything you need to cleanly separate text from style. They just are possible to use even if you have no idea how to do any of that; that's the appeal. The learning curve is zero.
There are a couple things that all these "death to word processors" articles overlook:
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.
MS Word exports RTF, which is a pretty powerful plain-text format. Our application generates RTF with some fairly sophisticated features (bold, italic, indented paragraphs, footnotes, images, index, vector graphics) and MS Word imports it flawlessly.
I get what you're saying. RTF is nice as an open-standard alternative for storing rich text.
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.
I'm a plaintext evangelist but "the focus should be on the data" is not the only priority for the general user. The reason When the average layperson sees anything (Markdown formatted or not) in a Sublime Text tab, they see "code".
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.
The code is not the data. It is a representation. Even the LISP code you write as text is not the code meant by "code is data", that would be the in-memory representation created by the reader, i.e. a bunch of conses.
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.
The reason for our privilege, I think, comes from the abysmal education the "regular user" is getting.
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.
everyone from every field is saying this. "public schools should teach more [programming/accounting/nutrition/formal writing/auto mechanic] skills to young kids!". nobody disagrees, because the value seems obvious, but you can't have it all. we are biased because we make our living working intimately with computers, but plenty of people learn exactly as much as they need to know about computers in middle school.
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 know the curriculum is full. This is why I proposed we remove other stuff.
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.
This is happening in the UK. Small children learn Scratch, which, of all the decades of attempts at beginner's languages for kids, turns out to be the one that works:
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.
> 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.
This is exactly why walled gardens are terrible. It's killing innovation and actual improvement in this case.
Plain text is "powerful" in some ways, but supporting links, styles, a bibliography, and even embedded scripts, in the way Word does, is not a power it has.
Well, it kinda depends on what you mean by "plain text" and what you mean by "support." You can get a lot of these things through text-markup systems like Markdown.
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.
If you mean "it's technically text but you have to have a program that knows how to parse it" then it's not really much of an advantage over docx having zipped XML.
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.
> it's not really much of an advantage over docx having zipped XML.
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.
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.
The examples I'd hold up as useful here keep the markup simple, so that the files are still usable when viewed directly, but provide lots of other functions by being clever.
Again, Orgmode is a great example. I can (and sometimes do) use my org files outside of emacs.
plain text, in the form of light-markup, can support all of those things, if you bring it into any number of the systems designed to handle it, many of which are open-source and free of cost.
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.
Yes, and by the time you're done supporting everything it's no longer a "light markup" but a complex format that is difficult to implement support for, much like the (specified and open) docx format.
fortunately, i don't find that to be the case for myself.
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.
Except for the gui (by which I assume you mean wysiwyg) Emacs with Org-mode meets these requirements, albeit requires a bit of configuring and a couple add-ons. It takes a bit of learning, though, and wouldn't meet a user-friendly requirement. Org-mode does meet a few wysiwyg items (font size, underlining, italics, etc.) but certainly isn't full wysiwyg solution. Still, it's probably a better solution than LaTeX, because (1) Org documents can be seamlessly exported to LaTeX (and many other formats), (2) Org documents tend to have much cleaner (or even no markup) compared to LaTeX, and (3) add-ons extending functionality can be easily crafted in Emacs.
To get an idea of what you can do in Orgmode, a good place to check is the books/publications linked on John Kitchin's page. He's a professor of chemistry who uses Orgmode for lots of different things. Among other things (and also listed on the linked page), he is the author of the org-ref extension that integrates citations and referencing into Orgmode, using the bibtex database:
That's interesting, but I think the author misses the fact that lots of writing is still done with the page in mind.
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.
Word processors actually do quite a lot. Word is host to multiple scripting environments and can do all kinds of useful stuff (the "useless bloat" you're always hearing about).
It still shocks me how many folks absolutely ignore the features of Word that make it powerful. A huge one is styles.
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.
I understand why people don't use it correctly -- it requires a deeper level of knowledge, after all -- but I don't understand why I constantly see people in technical forums claiming it doesn't support such a thing.
I could be flip and say "because Microsoft," but there's probably some truth there. Lots of very technical people reject MSFT out of hand, and for a long time it was pretty easy to understand why, but Word has always been very, very capable.
The first time I used semantic style structure in a Word doc was in Word for DOS in about 1992.
Nice demo. I wonder if it handles tables, images. How is the document stored? Can it import text-based formatted files (eg: RTF)? Is there a Windows version?
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).