Writing on a computer has a ton of advantages over ink on paper: you can undo mistakes, insert new content into existing text, rearrange ideas, copy and paste, correct spelling and grammar…. These features make it easier to create polished documents—to turn a rough draft into a publishable work with few traces of the mistakes and dead-end ideas along the way. But, they make it unsuitable for some purposes, like keeping an authentic journal.
Furthermore, perhaps writing with the constraints of pen and paper helps develop better habits, like thinking through how ideas should be organized and worded before setting them down. (Not to mention practice writing without typos.) And maybe we have become less mindful of how we come across in writing because we’re too accustomed to the ease by which we can reword our thoughts before committing to them.
Last week, I picked up where I had left off several months earlier in Becoming a Technical Leader by Gerald M. Weinberg. I was on chapter 7, “A Tool for Developing Self-Awareness.” Weinberg challenges the reader to, “Starting now, and continuing for three months, spend five minutes each day writing in a personal journal.” He recommends investing in a nice notebook and pen, but using a word processor may be OK in some situations.
Through numerous anecdotes, he makes a case that the value of a journal comes from the honesty and candidness of its contents, which emerge in part from the constraints of the medium.
The book is from 1986, long before our default computing mindset changed to expect everything to be saved to the cloud and all our data accessible from any device. We no longer need to be at a desk in order to use a word processor. How might that affect the advice about journaling using a word processor?
Personally, I don’t know where I’ll be when I get my five minutes to write in my journal. Yes, I could carry a paper journal and pen with me, but I already have a word processor in my pocket. I also don’t know where I’ll be when I want to read my journal. If I’m sitting at my desk, I’ll read it on my PC; in my recliner, on my tablet; on the throne, on my phone.
Following are experiments exploring the idea of modifying a word processor to offer the benefits of the constraints that come from writing with pen on paper. View this page’s source to see the code for the examples.
There are several ways to create a text editor in a web browser. One is
<textarea> element. This has limitations, though,
because it can’t contain descendant elements—it’s for plain-text only.
contenteditable attribute to an element doesn’t
suffer from that limitation, so that’s what I’ll be using for my
There are some basic modifications that can be made to an editable element that achieve a few of the constraints of pen and paper writing.
- The browser’s integrated spell checker can be disabled by setting the
spellcheckattribute of the element to
- Edits other than normal text entry can be prevented by adding a
handler for the
beforeinputevent that calls
preventDefault()on it if the
inputTypeis anything other than
"insertParagraph". This prevents most cutting, pasting, dragging and dropping text, undoing, and deleting.
- Additions of text and newlines can be forced to come at the end of the
input by updating the
beforeinputhandler, preventing editing text that was already written.
⚠️ These simple hacks don’t work for IME composition, like virtual keyboards on phones and multilingual input methods. To get the intended experience, try these examples with a hardware keyboard with keys mapped directly to characters.
Further modifications can be made to add features that are possible when writing by hand.
- Text can be underlined to draw attention to it. Marking text multiple times can add more marks under the text.
- Erroneous text can be struck out. Striking out multiple times can visually redact the text by completely obscuring it.
In order to add these features, when the user shows an intent to format
or delete content, the selected text can be nested in an inline formatting
element (such as
<del> for deleted text.) CSS can be
used to add more markings to formatted text that is nested multiple
One problem that arises when trying to format text across lines stems
from the browser’s default line breaking behaviour, which is to wrap
subsequent lines in
<div>s. In order to keep the
formatting code simple,
"insertParagraph" input intents can be changed to simply add
Another problem is with the way DOM
Ranges work. When there
is a non-text node as the last child with text content in the input, new
text will be added into that element. That would be a problem when the
last node is a formatting element because there would be no way to break
out of it. To address that, a zero width no-break space character can be
added after any trailing formatting element. During subsequent text input
events, the unnecessary space characters can be removed.
To turn this demo into a proper journal there are a few more features that may be desired.
- Each time a new session is started, the current date and time can be automatically added.
- Previous journal entries can not have any content or markings added.
An example of these features, including persistence and other improvements, can be seen at journal.figureandsound.com.
There are several other features of ink on paper writing that might be suitable for an application like this. For example:
- Notes can be written in the margins of the pages.
- Corrections can be added between the lines of text in the way that one might edit a double-spaced manuscript.
And, somehow, accessibility to different input methods such as IME composition needs to be figured out. Also, an interface should be added for formatting that doesn’t rely on shortcuts only available to physical keyboard users.
That said, I still want to challenge you to try to write a paragraph or two on journal.figureandsound.com (with a physical keyboard, as noted above) and ask yourself whether these constraints make you think differently about writing. ✍