writing is personal. that’s the first thing we have to acknowledge. every writer has their own process, with unique idiosyncrasies, and their individual flow. so it’s difficult to generalize.
however, we can say some things that will “often” be true for writing as an activity, and which will hold for many writers, perhaps even most (albeit not all).
one of those statements is that a written piece of significant length usually proceeds from an outline into a “rough draft”, and then makes its way through successive versions which become increasingly solid and eventually nicely-polished.
in the beginning, it’s enough to just “get the words down”. then, after that, the focus shifts to “re-writing”. and, in the case of something long, such as a book, those phases of re-writing accumulate into months, occasionally even a year or more. it is a process.
a little later, i will break down this analysis here into “the 4 stages of writing longform”. this specific breakdown, into 4 stages, is somewhat arbitrary; it could’ve been 3 stages, or 5, or 11. and those could have worked equally well. but i think the breakdown is accurate enough that it can be instructive to us.
yet another one of those “usually-true” statements is that some tools can facilitate the writing process. for instance, we can consider the simple typewriter. historically, it has given countless writers a leg up, just by providing us the ability to create clean and readable pages from our longhand.
continuing apace, the computer word-processor has revolutionized the experience of writing for many of us. being freed from the need to retype stuff, and given valuable functionalities like spellcheck, and find-and-replace, plus nice formatting, writers have been able to focus instead on the rewriting which is the essence of high-quality content.
further along, we now have the web, which promises a tool-chain we don’t have to pack around physically, available to us at every place with a web-connection. the liberation from this paraphernalia could be very good for many writers. perhaps even more importantly, the web has embedded us in a social milieu, so publishing becomes effortless, and writers can be connected directly with our readers.
we’ll certainly want to take advantage of these opportunities, of course, so at least one of the versions of our writing-tool should be available in a web-based app. it’s not that i think lots of people are going to want to write in a browser. i don’t. but i do think that some people might want to do it on some occasions, so they will want to have that option open. perhaps more to the point, i think people will want to have a writing-tool with behavior that is consistent pan-platform, including the web, so they know they can use it anywhere, any time. even if they never do.
the web, however, has thus far been somewhat more friendly and useful to readers than to writers. perhaps the best example of how the web is still unfriendly for writers is the web’s “textarea”, which is the mechanism for people to enter and edit text.
sadly, however, the browser textarea is very primitive, much closer to being a text-editor than a word-processor, and a very crude text-editor at that. this unfortunate fact constitutes a big obstacle to our efforts, so let’s see if we can address that problem.
as its name reflects, the textarea doesn’t try to be much more than a field which collects text.
the textarea shows all the text within it using one-and-only-one style. it can be any style -- bold, italics, big, small, any font -- but all of the text gets rendered in that one same identical style. this, obviously, will not do for writing, where we often want to italicize a word for emphasis, to use just one example.
and more complicated stuff, like blockquote formatting, or a hanging indent? totally impossible.
moreover, the standard font-style for a textarea is a monospace font. ugly. and yeah, sure, it's easy enough to change from that default, i'll grant you that. but the selection of a monospace default is a firm indication of my point: the web textarea is not a serious writing environment.
even in the very first stages of the writing process, where the important thing is to “get the words down”, the textarea is lacking significantly. and to deal with it, it might help to review the stages of writing longform.
here are the 4 stages of writing longform:
(again, this is just a heuristic; not something you must take absolutely. i think this is all fairly obvious, maybe even to the point it is trite. but if you disagree, then please enact a brief suspension of disbelief.)
let’s look at each stage with more depth:
some people might want to label stage 3 as “editing” instead of “rewriting”. but i’d like to reserve the “editing” term for cases where somebody else becomes involved in the process (i.e., “an editor”). and the truth is that a writer can involve another person for assistance and feedback during any of these 4 stages. an editor in stage 1 is usually named “a structural editor”; one in stage 2 is often called “a developmental editor”; stage 3 is often serviced by a generic “editor” label; and stage 4 is “a copy editor”.
so, while this model could certainly encapsulate collaboration, it’s easier to just leave such issues completely out of the picture here for the time being. so that’s what i’m going to do.
and nope, i am not suggesting that these stages are hard and firm, because that’s obviously not the experience of most writers (if any). we’re constantly shifting between stages, even on the same chapter. and frequently some sections will be all the way to the polishing stage, while others are limping along, slowly, surely (or not), way back in the writing stage.
once again, this is just a guide for us, meant to be general and instructive. we don’t need to quibble on the details of this specific breakdown. if you’d like to propose some other one, please feel free to do it.
in the meantime, let’s see if this breakdown helps give us a map for our journey.
as far as publishing goes, there has traditionally been a big difference between “input” and “output”. 100 years ago, for instance, an author would use a typewriter to create a manuscript to send to the printer, who would then transform that text into a typographic format that was printed in a press-run which produced books. you could see the relationship between them, of course, but the typewritten sheets and the pages of the hard-copy book did not look the same. what you saw, as an author, while typing your pages, was definitely not “what you got” when you looked at the typeset printed book. for instance, a chapter-title on the typewritten sheet is the same size as all of the other text. but in the printed-book, the chapter-title is bigger. (and bold, and centered at page-top.) to rephrase, there was a rather sharp demarcation between “the input” and “the output”.
in terms of computer writing tools, the prevailing trend for decades has been “wysiwyg”, which is short for “what you see is what you get”. computerized word-processing apps could represent, on-screen, the nicely-formatted display previously reserved for books. so, even in your word-processor, that chapter-title was shown bigger, and bold, and centered. moreover, you could do the editing directly, right inside that nicely-formatted display. with wysiwyg, editable text and nice display are one and the same.
wysiwyg has been tremendously useful in the offline world, where manuscripts almost always consisted of ink printed on 8.5x11 sheets of paper, or any time you knew how the reader would encounter the text, because you could design the content for that specific form-factor, so it was presented nicely.
however, wysiwyg is less useful in the online world, because the size of the display used by readers can vary wildly, from the index-card-sized form-factor of your smartphone up to huge electronic-billboards in times square in new york. and “what you see” will depend on the screen you’re using. the document that works fine on an 8.5x11 page might not work well on an android tablet, or a times-square billboard. and a document that you create might look good on your ipad, but not good on someone else’s desktop computer monitor, or their smartphone; and it’s hard for you to anticipate that. previously, it was the inflexibility of the display that allowed us to design the content so that it “looked nice” on that specific display. but now, we don’t know what display people will use to read our text. (or, to be more precise, we know that people will use all kinds of displays.)
now, some writers in some situations might be willing to return to a world where input is separated from output. the popularity of light-markup systems and “distraction-free” apps show that many writers want tools to “get out of the way and let me write.” still, plenty of writers are accustomed to wysiwyg; they don’t just want to see what they’re gonna get; they demand it.
the other reason wysiwyg doesn’t work online is because of the primitive nature of the web’s textarea, as discussed above, which is incapable of wysiwyg. one font, one size, and one style; that’s all you get.
some people are working on bringing editing capabilities to other web-structures, so that we can retain the “wysiwyg” model (because it does have popular demand), and i wish those people the best of luck, but it’s been tough slogging for them, primarily because internal differences between browsers complicate the issues. (and browser-makers haven’t standardized, despite years of opportunity to do so.)
one route to wysiwyg is “contenteditable”. if you’re in a browser now, viewing this as a web-page (not a .pdf), the text inside this box is using contenteditable. as you see, we get things like:
you just click inside the text and start editing. go ahead and try it right now!
to get italics or bold, you just select some word or phrase, and do the standard keyboard shortcut — (command-i or command-b) — and that will toggle the styling. when it works, it’s great!
the problem, though, is that in some browsers, it doesn’t work, unfortunately.
and even when it does work, some things can get more thorny, like forming a link, or doing a footnote, or specifying an image. it’s not always so simple as a keyboard shortcut.
another problem is that the formatting for a section can get screwed up if you paste in content copied from elsewhere which contains formatting that conflicts.
the worst problem, however, is that there are cross-browser inconsistencies, so what works in one browser doesn’t always work in another. also, there are flocks of bugs in every contenteditable implementation, and crashes are not unfamiliar. (if you tried it, i hope your browser didn't crash!)
and, remarkably, none of the browser-makers seem to consider contenteditable as any priority, let alone a big one, so none of these problems have been addressed in many years. it is sad.
this has led many people — some of whom had invested years in the tactic — to abandon it, which issues a huge precaution in our evaluation. at the same time, we can express good luck for those who work on this approach, and hope for their success. more options are always better.
but we're gonna look elsewhere...
other people take another route, using the textarea as is, plus a “display” pane for the formatted text.
this returns us to a clear demarcation between “the input” and “the output”, but i don’t necessarily believe that that’s a regression. indeed, it gives benefits.
a very common use of this interface is for light-markup editor applications, where the “input” is the light-markup; the “output” is the generated .html.
let’s look at an illustrative example. on the left we see the textarea, where the writer writes, creating “the input”. and on the right we see “the output”, the nicely-formatted display version.
so the left side has plain-text, in the textarea, where the writer uses the conventions of light-markup to get things like:
## the 2-up interface
other people adopt
a different scheme,
which accepts the
textarea as is, and
then incorporates a
"display" pane for
the formatted text.
this returns us to
a clear demarcation
between "the input"
and "the output", but
i don't necessarily
believe that that's
a regression. indeed,
it gives benefits.
a very common use
of this interface
is for light-markup
editor applications,
where the "input"
is the light-markup;
the "output" is the
generated .html.
let's look at an
illustrative example.
on the left we see
the textarea, where
the writer writes,
creating "the input".
and on the right
we see "the output",
the nicely-formatted
display version.
so the left side
has plain-text,
in the textarea,
where the writer
uses the conventions
of light-markup to
get things like:
o _italics_text_
o *bold*text*
o proper lists, etc.
other people adopt a different scheme, which accepts the textarea as is, and then incorporates a “display” pane for the formatted text.
this returns us to a clear demarcation between “the input” and “the output”, but i don’t necessarily believe that that’s a regression. indeed, it gives benefits.
a very common use of this interface is for light-markup editor applications, where the “input” is the light-markup; the “output” is the generated .html.
let’s look at an illustrative example. on the left we see the textarea, where the writer writes, creating “the input”. and on the right we see “the output”, the nicely-formatted display version.
so the left side has plain-text, in the textarea, where the writer uses the conventions of light-markup to get things like:
again, i have long been a proponent of this 2-up input/output interface. it’s handy in a wide variety of situations, because the second pane can become a “workspace” which can show whatever is necessary. for instance, it might display the table of contents, a find/replace capability, a spell-checker, a thesauraus, a carousel to review your graphics, or other widgets. this gives us a lot of flexibility with our interface.
i also prefer the 2-up interface because i think it’s important to keep input and output separated. some approaches have tried to “smoosh together” the input and output into a single window. i think it’s probably impossible to do that, because you end up with the worst of both worlds instead of the “best” of both. but i think it’s also the case that it’s not a good thing to do, in the long run, because it becomes confusing as to what is input versus output. this is especially true when people are first learning light-markup.
however, i have recently come to a slight change in my thinking —
surprising, considering i had held it firmly for a decade (or more) —
given my analysis of the 4 stages of writing longform.
although the 2-up interface is ideal for the vital “writing” stage,
it’s less important during the other stages, and can even be a distraction.
so i now believe the writing-tool should be able to shift easily
between the 2-up interface and a 1-pane model, where the single pane
is either the textarea or the “display” pane,
whichever is more relevant. so let’s step through my new thinking...
first, let us review the stages:
let’s examine our 2-up interface via those stages:
## 2-up for writing
bookish paragraphs all
by themselves can be
quite inspiring.
but seeing lists,
headers, blockquotes,
_italics,_ and
often more
-- nicely-formatted --
feels _accomplished._
and pictures too!
http://placekitten.com
plus live links...
http://apple.com
and tables:
| . | col 1 | col 2 |
| row 1 | no | no |
| row 2 | no | yes |
| row 3 | yes | yes |
and *bold* and ~code~.
> and blockquotes!
> i love quotes!
> _--_a_quote lover_
(click each paragraph to show its editor.)
in the “rewriting” stage, when the spotlight is on each specific individual paragraph, having two copies of the text — one on the left, the other on the right — becomes redundant and distracting.
since we’re editing only one paragraph at a time, that’s the only paragraph where we need to see both input and output. for all other paragraphs, it’s better that we see just the nicely-formatted version.
if we find a paragraph that needs editing, we’ll click it and — only then, for that one paragraph — get a 2-up view.
if we find a paragraph that needs editing, we’ll click it and — only then, for that one paragraph — get a 2-up view.
to sum up, this analysis here of the 4 stages of writing longform caused me to make a slight but significant modification of my longtime advocacy favoring a 2-pane input/output writing-tool interface.
i now believe the writing-tool should shift between the 2-up interface and a 1-pane model, where the single pane will be either the textarea or the “display” pane, depending on which one is more relevant at the time.
