What WYSIWYG Got Right About Writing

In my last post, I argued that web and structured writing tools need author assurance: the confirmation that authors have done their job or that there is a clear path to fixing errors. In this post, I discuss the sense of assurance that WYSIWYG-style desktop publishing tools provided, and identify three components of that experience that we must transfer to structured authoring environments.

Many of us started our serious writing somewhere like this:

What we saw on screen was pretty much what we would see on paper. Buttons looked like what they did: a heavy “B” for bold; a kind of I Ching hexagram for centered. If a paragraph style was obviously unsuitable, you picked the right one. If images didn’t line up with the right text, you moved them. If page breaks fell in confusing locations, you adjusted them. 

Sometimes, this fine-grained control lead us to spend excessive time on design decisions. We might find ourselves dwelling on page breaks or wrestling with list numbering. We might advance to full desktop publishing tools such as InDesign, with a whole different set of controls and 12 kinds of space to choose from.

But we generally learned to use our tools in a way that suited our needs. While nobody ever said they loved Word, they grew comfortable with it.

The web brought trouble. While design tools such as Dreamweaver and in-CMS editors such as CKEditor tried to recreate the familiar WYSIWYG experience, the resulting mess of code was inflexible and hard for designers to work with. The gaps in the DTP metaphor started showing up to authors as well. James Morrish wrote about the WYSIWYG editor in WordPress:

Uploading and floating images, changing font sizes – doing pretty much anything unleashes a torrent of divs and in-line styles. Deleting a header and replacing it with plain text resulted in the paragraph being the same font size as the header – it’s clear the editor can become easily confused.

For a while, format-based elements such as <b> and, later, inline CSS wrestled readers’ browsers into submission. Where that wasn’t enough, Flash took over the browser to control not only what appeared, but when it appeared.

But with the big push for web standards, the separation of HTML from CSS, and the birth of responsive and adaptive design to cater for various viewing contexts, it was clear that authors would need to be weaned off WYSIWYG to more controlled forms of content creation. The same applied in the parallel world of product documentation,  where the need to produce some form of HTML-based content (or at least produce PDFs more efficiently), led information development teams to adopt XML. 

Us structured content implementors assured writers that a more controlled environment would make life easier. They could focus on the words they wrote, and the system would present those words attractively. Moreover, with a slight effort to add metadata, their creations would be delivered to all devices and all platforms, cut up and reassembled into suitably flavored pieces for each individual reader. A few of us promised even more. 

However, while structured content did indeed bring great benefits, it also brought pain. There was the initial effort to get used to a whole new way of working — an effort that organizations sometimes underestimated. But then, even after a system was mature, it didn’t always live up to expectations. 

Form-based web interfaces didn’t offer sufficient control and feedback on what textual content was associated with what visual or multimedia content. As Jeff Eaton wrote in The Battle for the Body Field, writers: 

…needed to mix in multiple videos, a gallery and a poll, or several related article teasers, at specific points in each article. Carving out these elements into separate CMS fields or standalone pieces of content would make storing and remixing them easier. However, relying on rule-based CMS templates to display them would also break their connection to the specific sentences, paragraphs, and sections they were meant to enhance.

Where authors did have more control, often this meant inserting short tags, attributes, or other metadata values in an all-too-manual way. Relying on memory for these increased the burden on authors and risked expensive errors, particularly where the content had legal or safety implications. The effect of a metadata choice might not be visible until content was made public, and even then was only visible in certain situations. 

In structured content environments where XML would be transformed to PDF, again authors often had to remember special codes. Checking their work involved publishing, looking through, then figuring out what went wrong. And when things went badly wrong, error messages were often cryptic. Where a “simple”, Word-style authoring environment had been introduced, serious errors might be hidden altogether, or the environment would just freeze or crash.

Quietly, some writers wondered whether things had been better in the days of desktop publishing. More vocally, some teams who hadn’t yet moved to structured content wondered whether it was even worth it. It was easy for implementers to dismiss these concerns as fear of change or reluctance to give up creative control over formatting. But most professional writers have always been willing to adopt new ways of working when they learn about the benefits. They have more patience with tools than they are often given credit for (after all, they learned to use Word!) And the increasing popularity of Markdown, a syntax that offers virtually no creative formatting control, shows that “font fondlers” (if they ever really existed) are dying out. What WYSIWYG really meant to writers was knowing when they’d got it right. When we abandoned desktop publishing tools, they lost that sense of assurance. Their discomfort was less personal and more professional: all too often, the new systems proved to be error-prone, distracting, and time-consuming.

What can we do about this? We can’t go back to pure WYSIWYG, for sure. Today’s structured content authors are responsible for more than just the words on a page, and have to be aware at least of the possible contexts in which their work might appear. They should be able to associate articles and even inline terms with the real-world entities they describe. But there are some important components of author assurance that we can apply from WYSIWYG to our authoring environments: boundedness, immediacy, and narrative control.

Boundedness: you knew where your responsibilities ended

In Word, you wrote on a virtual sheet of paper. Unless you were in the unfortunate position of using Word to author Web content, your task was bounded by the limits of print. Hyperlinks and TOCs or indexes were a minor and usually unproblematic exception. While of course it was very possible to get yourself messed up with auto-numbering and lists, it was rare to see an error message, and what you saw on screen was pretty much what would be printed out.

In web and structured authoring, writers are responsible for a lot more than a single possible rendering. Their creations may appear at many sizes, in many different layouts, in part or whole. As we’ve seen above, they are often required to remember obscure codes and enter them accurately, even to enable a print emulation of what was previously authored in WYSIWYG.

The needs of author assurance demand that tools provide some sense of boundedness; of when the author’s task finishes and the system can be trusted to do the rest.

Immediacy: your errors showed up straight away

As I noted above, while you could certainly get yourself into trouble with tools such as Word, the problems usually showed up straight away. In Adobe InDesign, not only did you see exactly what was on the page, you also had a visual indication of what was not there, when there was too much text for the current frame.

In structured authoring, not only are writers responsible for more than a single presentation; they are not always informed promptly (or at all) when they get things wrong. It may not be until days or weeks after their content goes live that a serious error is noticed. When attempts to catch errors are made, too often they are in the form of custom scripts or plugins — of clunky bolt-ons to a poorly designed system.

Author assurance demands that tools demonstrate errors as soon as possible, and in as direct a fashion as possible. In the same way that a mouse or touchscreen provides direct manipulation of virtual objects, so errors should manifest in a tangible, controllable way.

Narrative control: you felt better able to shape the story

To convey anything other than atomic facts, writing must take a narrative structure. This is true no matter the format or subject matter. Reports flow from introduction through methodology and details to a conclusion. Effective emails move quickly from a reason for writing to a required action. Even short knowledge base articles say who they’re for and what problem they solve before getting to instructions and examples. If writers fail to fulfill these narrative expectations, readers will be forced to work harder to understand the meaning, and may give up. There are valid reasons for making readers work a little, but lack of discipline is not one of them. 

Online texts form part of a longer narrative that readers participate in directing — the journey through various sections on a website or screens in an app. If this too finishes without satisfaction, the story will resemble a poorly written Choose Your Own Adventure book — one with a variety of fatal endings and few successes.

The best way to really grasp the narrative we are writing or reading may be through physical media — the painstaking covering of sheets with ink; the leisurely leafing through several hundred pages, where progress is marked not by a line of pixels, but by the proportion of pages in each hand.  

The second-best way for writers to grasp the story they are shaping may be through paper analogues such as DTP tools. As they scroll through a Word document, the effort of swiping upward or rolling the mouse wheel reminds them that we are progressing through words that readers themselves will need to work through. 

Of course, even in print, readers haven’t always followed dutifully along the paths that authors laid out. In a hypertext environment, and especially if content is laid bare to external search, the expectation has to be that they won’t. So, rather than relying on the false assurance of a book-centered tool, we have to consider how authoring tools should help writers construct the narrative forms that are relevant now. 

A very successful format on the web is what we could broadly call an article — for example a blog post, wiki page, or technology tutorial/recipe. This format can provide ample context and rich examples while still being suited to consumption in one session. Yet, many structured authoring tools either require writers to create smaller chunks instead of writing the article together, or simply dump them in a sea of text that they cannot even intersperse with images or charts. To write a story, we must see the story — see it together without the need to check in / check out a dozen tiny chunks, and without needing to follow the text with a finger to make sense of where we are.

The narrative that readers experience often involves them following hyperlinks, yet some automated publishing environments give few clues to writers as to what kind of links will accompany their work or lead to it. The quality of the links may disappoint, especially for writers who have been assured that the system would do a better job of linking than they themselves could do manually. Even when links are effective, the algorithms used to generate them may be complex or opaque. If writers are to be more than form-fillers, they need to understand the kind of contexts in which their text will appear, and why, in order to shape that text more effectively to its purpose and its audience. They can’t always control those contexts, but they need to understand them, and writing environments must play a better role in that.

No wonder many writers miss WYSIWYG. It’s not that they want to return to print publishing, or that they expect pixel-level control over web formatting. Rather, many structured or web authoring environments are failing to provide them with the necessary assurance that they are doing their jobs ok, or the support to fix things when they go wrong.