I'd Rather Be Writing » concision

Book Review: Letting Go of the Words, by Ginny Redish

Tom Johnson — Fri, 08 Apr 2011 06:07:18 +0000

Letting Go of the Words, by Ginny Redish

Letting Go of the Words (2007), by Ginny Redish, puts forward an idea that many readers will eagerly embrace: think of writing as you would a conversation. Anticipate the reader’s questions as you craft your content. Redish explains,

If you think of the web as conversation, you’ll realize that much of your content is meant to answer the questions that people come with. you do not want an entire site to be in a section called frequently asked questions. You do want to think about what people come wanting to know and then about how to give them that information as concisely and clearly as possible. (5)

In other words, for Redish, to think of the web as conversation means to anticipate the main questions your users will have, and then to structure your content as answers to those questions. You might use subheadings phrased as questions, but it’s not necessary. She’s not urging every page to look like an FAQ page, but to simply keep the user’s questions in mind as you write.

This technique is brilliant for two reasons. First, it gets you thinking about your users. It’s hard to consider what questions your users would have if you haven’t already defined who your users are. So immediately you’ll begin to think carefully about who your users are, and what sorts of backgrounds, scenarios, and contexts they have.

Second, the web as conversation technique prompts you to consider your user’s pain points. Rather than wandering about in obvious information, by answering questions you’re tackling the user’s real problems. You’re addressing why your users came to your site in the first place — to get answers to issues and problems they’re experiencing.

Redish also suggests that you start by answering the most important questions first, and then in inverted pyramid style work your way down to questions of lesser importance.

This web as conversation technique is the most appealing and novel idea in the book. But while the “web as conversation” is a model that feels right, Redish’s take on writing as conversation doesn’t involve social media. Granted, Letting Go of the Words was published in 2007, and probably written during the several years prior to that, before social media saturated the web.

But today, when we refer to the web as conversation, we’re referring to the idea of the reader as an active participant in a content dialogue — not just metaphorically. As a reader, you can speak to me by writing comments on this post. You can write your own post discussing points you agree with or disagree with. You can publish responses on Twitter, Facebook, or other social tools. You’re not a silent reader whose questions and thoughts I have to merely anticipate. The web as conversation means the content flows both ways. I write, you respond, I write back, you respond, and so the conversation goes. As a result, an initial post might triple in word count when you consider all the conversation that takes place from that initial post. (See Post Publishing Word Count Can Be Three Times as Long.)

Unfortunately, Redish never gets into social media in Letting Go of the Words, so it feels a bit dated. But even dated, Redish’s technique to consider the user’s questions is still right on target. It’s advice that, if everyone followed, would make the web a much better content experience.

As for the title, “Letting Go of the Words,” Redish returns again and again to the idea that writing needs to be concise and goal-oriented. ”The key to successful writing on the web is to let go of the words without losing the essential messages,” she explains (98).

Omitting needless words is nothing new, of course. It’s solid writing advice that you find in classics such as Strunk and White. Because of this and many other basic writing principles that receive constant attention and emphasis, seasoned web writers familiar with web conventions may find this book too introductory. Additionally, the initial appeal of the web-as-conversation metaphor gets diluted by the ever increasing scope of the book. By the end, she covers so much territory (lists, tables, illustrations, links, headings, paragraphs, white space, etc.), that the book becomes more of a general guide on “writing for the web.”

Still, as a general guide on writing for the web, it’s useful to have next to your other books on style. For example, last week my colleagues and I were discussing list alignment (whether to indent lists or keep them aligned with the paragraph’s left edge). I opened to Redish’s chapter on lists to review what she had to say on the issue. Did she anticipate our questions? She does note that text should wrap under text, not under the bullet or list number. It wasn’t exactly our question, but by not addressing it, we decided either way was acceptable.

If you’re working with web content, Letting Go of the Words is a good book to ground you in the basics. You get a taste of a lot of disciplines mixed together here — usability, information architecture, typography, copywriting, and more. If you’re a digital native, however, who spends more time online than offline, you may be better off reflecting on the writing as conversation metaphor and then jumping into a book that discusses more social media strategies.

Blog Sponsors

Less Text, Please: Contemporary Reading Behaviors and Short Formats

Tom Johnson — Fri, 21 Jan 2011 08:29:12 +0000

Yesterday I had a meeting with some managers about a series of quick reference guides that I had been preparing. If you remember, much of my callout post referred to a strategy about callout design. It was the same project. (The team actually went with bubble callouts rather than my minimalist callouts, but that’s another story.)

During the meeting, as the team looked at the callouts on the quick reference guides, they felt there was too much text. Reduce the text, increase the font, they said.

Reduce the text? Make it even shorter? The content was already a two-page quick reference guide. Were we now to make it a postcard?

I get this feedback a lot. Hand any help material to a non-writer in a meeting, and the request I routinely hear is to make it shorter. Too much text. People aren’t going to read this, they say, as if they were expecting to take in the entire content with a five-second glance.

My experiences lead me to wonder about the possible transformation of reading experiences, and if reading is still the same in our online age. When you add in the immediacy of online content, hyperlinks, mobile formats, RSS feeds, and endless information, do people still read in the same way? And if people read differently today than they did 50 years ago, how do we change our help deliverables to fit contemporary reading patterns?

Attention Spans

Probably the most radical argument about shifted reading behaviors comes from Nicholas Carr, who asserts that Google has rewired his brain, reduced his attention span, and given him more superficial reading habits, including some fidgeting. In short, Carr thinks that Internet content has made him “stupid.” In an article in The Atlantic, Carr explains,

Over the past few years I’ve had an uncomfortable sense that someone, or something, has been tinkering with my brain, remapping the neural circuitry, reprogramming the memory. My mind isn’t going—so far as I can tell—but it’s changing. I’m not thinking the way I used to think. I can feel it most strongly when I’m reading. Immersing myself in a book or a lengthy article used to be easy. My mind would get caught up in the narrative or the turns of the argument, and I’d spend hours strolling through long stretches of prose. That’s rarely the case anymore. Now my concentration often starts to drift after two or three pages. I get fidgety, lose the thread, and begin looking for something else to do. I feel as if I’m always dragging my wayward brain back to the text. The deep reading that used to come naturally has become a struggle. (Is Google Making Us Stupid?)

In other words, rather than sitting down with a book and immersing himself in it, drowning out the world around him as he drinks in page after page, he now gets restless after a few pages. His attention span compels him to turn somewhere else, to read from a different author or source. His reading experience is much more cursory and shallow, thanks to the Internet.

Steven Johnson also argues a similar point in the Wall Street Journal. He has the epiphany while sitting alone in a restaurant in Texas. He argues that the deep, immersive reading experience evaporates with the ability to immediately view or download any content, almost anywhere. Johnson writes,

Because [print books] have been largely walled off from the world of hypertext, print books have remained a kind of game preserve for the endangered species of linear, deep-focus reading. Online, you can click happily from blog post to email thread to online New Yorker article — sampling, commenting and forwarding as you go. But when you sit down with an old-fashioned book in your hand, the medium works naturally against such distractions; it compels you to follow the thread, to stay engaged with a single narrative or argument. (How the e-Book Will Change the Way We Read and Write.)

In other words, the shift from print books to online content, in which every page is linked to another page, in a giant web of connected content, has given readers a lack of patience. They can’t remain on one narrative thread for long periods of time. They instead jump around. They sample and move on, they glance and click. No one sits down to eat a long literary dinner any more.

Hyperlinks

One main enabler of the short, cursory attention span is the hyperlink. At the last STC Summit, Ginny Redish and Kathyrn Summers noted how the hyperlink becomes an obstacle for low-literacy users, causing them to click links randomly and lose their train of thought. Each hyperlink presents a forking path for the reader, presenting the reader with the decision to click elsewhere. If a reader is slightly bored, the temptation to move on to greener web pastures is often too much, regardless of the literacy level.

Smart Phones

Smart phones also contribute to the shift in reading behaviors. The smaller display and screen real estate on a smart phone, as well as the smaller font of the text, strain reading. But the portability of the smart phone compensates for the strain in an overpowering way, so that the reverse is also true: people read more, at least according to Peter Collingridge, a publisher of Enhanced Editions software for the iPhone.

Collingridge says that “People aren’t reading less on mobile devices, they’re reading more.” This is because “occasional reading suddenly became so much easier: on the bus, waiting for the tube, opening an app that remembers the exact place you left it for a quick literary fix becomes second nature very quickly.”

Collingridge finds that to deal with his insomnia, he’ll read his “iPhone in bed at all hours, without the need for a light” (Reading Wolf Hall on the iPhone).

Collinridge specializes in digital editions for e-books, so perhaps readers are able to enter the deep-focused reading state that Johnson describes, even on mobile. However, on my smart phone, a Palm Pre, I tend to only read RSS feeds. I can move through dozens of feed items relatively quickly, choosing to save good reads through my Read It Later app, which saves posts to Instapaper.

Reading an article longer than 3,000 words gets tiring, and I quickly feel like I’m making my way through Moby Dick. It’s a bit harder to jump and skim on the mobile device, because I can only see a two-inch span of the article. Still, I may read more content because I can curl up in my favorite position on the couch or bed and read from a device in my hand. I may lie there reading for an hour or more, but moving from feed to feed, from site to site, often in the dark.

This behavior no doubt turns habitual. Soon my reading pattern is to jump and click, moving from site to site, regardless of whether I’m at a desktop, a laptop, or holding a book or magazine. The smart phone inculcates a new reading pattern in me that favors short text.

As the following image shows, the shift in media from books to television, and then to video games, Internet, social media, and smart phones, has slowly rewired our brains. We have shorter attention spans. We prefer short texts.

Rewiring the brain through shifts in technology

Given this rewiring, perhaps we technical writers should start producing help materials optimized for this type of brain? I’ll come back to this idea in a minute. First, a few more arguments about how reading is transformed.

The Blog

In contrast to book authors, the army of daily bloggers cranks out a million short posts a day. One rarely finds a 5,000 word essay to slog through on a blog. And if you do find one, given the average literary skill online, it might not be worth reading carefully. In fact, most blog posts are re-spun cliches or ideas that we’ve already read or already understand, so skimming this content only makes sense.

Regardless of the content quality, if blogs are the new format for online content, and most are short articles (under 2,000 words), doesn’t this new standard for brevity reduce the reader’s ability to endure long, book-length texts? The more you read blog posts, the more you expect content to be short. We’re surrounded by a culture of content in which short formats are the norm.

Even critics who defend the intellectual depth of these short formats still acknowledge their brevity. Clive Thompson in Wired says, “The torrent of short-form thinking is actually a catalyst for more long-form meditation” (“The Short and the Long of It,” January 2011). His assertion is brilliantly illustrated through this simple concept diagram.

"The torrent of short-form thinking is actually a catalyst for more long-form meditation." -- Clive Thompson

Whether all of these short-form texts aggregate into long-form trends and deeper, more extensive analysis overall is beside my point. I cite Clive here as yet another critic who acknowledges the shift in formats from “long, well-thought-out arguments” to “text messages, tweets, and status updates.” These short formats may be micro-components of a collectively intelligent macro discussion. But the mere fact that discussions take place in short formats rather than long ones reinforces the trend I’m highlighting: short texts surround us as the norm.

Tags and Categories

In addition to favoring short forms of content, blogs are also structured with tags and category links, which invite readers to explore content thematically rather than as a whole. Interested in the topic of web design? Click this web design category link and peruse the available articles. Or click the usability tag and see even more specific selections on the topic. Thematic reading often spans numerous articles rather than pointing readers to a single lengthy work. You end up reading an online bibliography or collection rather than a single book.

At my work, we just released a notebook tool that allows users to highlight passages and bookmark articles as they read site content. They can add the content to a folder and tag it. The result is a chopped up bag of short content that provides a litany of quotations, highlights, and article titles on a topic. All short and concise. A reader can move through dozens of sources, sampling each article in very little time. Eventually you’ll be able to share your collections with other readers, so readers will no longer be turning to lengthy primary source material for learning. Instead, they’ll move through a smattering of individual paragraphs from dozens of sources, all compiled together in a list showing 10 items per page.

So Much Content

Never mind the type or format of content, another cause behind the changed reading behavior is the abundance of content. With a thousand new posts in Google Reader all the time, access to every online newspaper in the world, new podcasts to listen to, email to check, updates to Twitter and Facebook arriving every three minutes in little corners of the screen — it’s no wonder people have short attention spans. There’s simply no way to get through the sea of information navigating a sailboat. You need a speedboat to manage the choppy waters, with a strategy to skip and skim as fast as possible.

Lament

Despite the abundance of short text, I still lament the trend. The less I write, the happier my project teams are. If I could deliver everything in a handful of haikus, I would be the most popular writer in town.

Text in this long guide

Reduced to a few callouts

Users jump with joy

The shorter documentation is, the more likely people will read it. But at some point, brevity doesn’t translate into simplicity. It translates into obscurity. Knowing the exact point that happens – when text I’ve shortened lacks clarity and only becomes confusing – isn’t always apparent. It depends on the context the reader brings.

The same people who clipped back my copious callouts into a few marketing bubbles would have also pruned this post from 2,000 words to 200. Would that make the text more valuable? Just as there’s a balance between simplicity and obscurity, there’s a balance between length and learning. More people might read a short text, but a longer text yields more learning. Is there no pleasure in learning anymore?

At any rate, as technical writers, the era of brevity invites us to emphasize short forms of instruction. As such, I present to you, patient reader, a list of the top 10 short text deliverables, optimized for the online reader:

Quick reference guides
Screencasts (1-2 minute)
Visual callout guides
Role-based guides
Interactive rollover screen tutorials
Instructive blog articles
Online quick reference sites (example)
Laminated job aids
Cafeteria table tents
Standalone diagrams and illustrations

These formats may not be ideal in all situations, but the trend is clear: shorter guides, more visuals, and less text, please.

Blog Sponsors

Ginny Redish — Letting Go of the Words (Podcast Interview at STC Summit)

Tom Johnson — Wed, 06 May 2009 02:58:06 +0000

Download MP3 (to download, right-click and select Save Target As)
Length: 8 min.

Ginny Redish -- Letting Go of the Words

Ginny Redish has just written a new book, Letting Go of the Words: Writing Web Content that Works. I had a chance to meet up with Ginny at the STC Summit and interviewed her briefly about her new book. Redish told me, “Every use of your website is a conversation started by the site visitor.” Here’s an extended description:

People come to web sites for the content — for the information that answers their questions and lets them complete their tasks. In Letting Go of the Words, Ginny Redish provides easy-to-read guidelines with many full-color examples to help you plan, organize, write, and revise web content so that it is easy to find and easy to use.

You can buy the book here. It really is in full color with a lot of attractive diagrams and illustrations.

I haven’t read it yet, but the writing-as-conversation metaphor is appealing. The basic idea, I believe, is to anticipate the reader’s questions and then construct your writing as a response. This type of writing focuses you on your audience and gets you thinking about the specific questions, concerns, issues, and other problems your users might have. Each sentence you write should somehow answers those questions — you construct the conversation. Sounds like a brilliant technique, though I’ve never fully implemented it.

More Resources about Ginny Redish and Letting Go of the Words

Blog Sponsors

Lessons Learned with Quick Reference Guides: Timing and Truth

Tom Johnson — Fri, 27 Feb 2009 06:55:45 +0000

One of the fundamental aspects of quick reference guides is knowing when to create them. A few weeks ago I was assigned to a small project team working on a relatively simple application, and I pitched the idea of several role-based quick reference guides for the help content. I showed samples from other projects, and the project team agreed it was what they wanted.

Soon after, I started designing the help content for the application. I brought a few of the quick reference guides to a meeting — they all felt it was perfect and I felt good about what I’d done. And then little by little things began to unravel.

The quick reference guide I showed the team

We met on at least three separate occasions, each time reviewing the help content. Since I designed the information in a specific layout in Adobe Indesign, these little adjustments were tedious. Sometimes adding information made the text extend beyond the allowed column length. Or taking away information left odd-looking gaps. To compensate, I adjusted the spacing and kerning/leading in places, and sometimes removed an image or added one.

Designing for an information space (the double-sided page) before the information was locked down was a major mistake. Each adjustment required not only an adjustment of text, but often an adjustment of design.

Nearly a week before the release deadline, I announced that I could also include an online help file, since the online help would merely involve copying the same content from the quick reference guides into a short online help file. I already had a stylesheet set up from another project and would only need to tweak a few colors of the skin.

I manually copied the text from the quick reference guides into the online help, and then I decided to check the accuracy of the help a few more times to make sure it was still correct.

Here’s where it started to get a little more “interesting.” In all my meetings, dev and QA were absent. The meetings included the project manager, product manager, audiovisual, the sponsoring business department, and the interaction designer. We relied almost exclusively on the interaction designer’s prototypes as we discussed functionality, workflow, and special cases. I somehow had the impression — perhaps because the interaction designer kept affirming it — that the prototypes matched the development environment, or that the development environment would need to match the prototypes before the release.

Little did I know that, in fact, there were significant differences between the prototypes and the dev environment, including bugs in workflow and printing processes that the developers couldn’t fix and weren’t planning to fix. I ran through my instructions half a dozen times, walking through each step and noting the discrepancies.

As I had already copied the quick reference guide content into the online help file, I now had to make twice the amount of updates: one update to the quick reference guides, and another update to the online help.

After working deep into the night before the announced code freeze, I finally delivered the six quick reference guides that I’d promised along with an online help file that mostly acted as the web interface where users could download the guides.

I learned several important things about quick reference guides from this experience. First, I really should have created the material in an online help file first. If I design the quick reference material first, I spend too much time adjusting the design instead of focusing on the accuracy of the content. It’s better to create the quick reference material at the end, like icing on a cake.

Second, I should never fully trust anyone on a project. I don’t mean this disrespectfully, because I work with competent, talented professionals. But no one has the full picture of how the application will truly work. The quality assurance (QA) engineer usually has the clearest picture. The program manager and project manager are often living in a slightly different world, full of a vision of how the product should work and how they expect users to interact with it, but sometimes they’re missing important nuances in the actual implementation. The interaction designer builds prototypes and assumes the developers will build them to spec, but since the prototypes are usually HTML-based, and not in Java or .NET, variances are inevitable.

Despite the helpfulness of QA, they largely take orders from the interaction designer, developer, and project manager, so even QA can’t totally be trusted. They’re only knowledgeable about the current state of the application, the bugs they’ve logged, some awareness of the bugs that will actually be fixed or ignored, and expected delivery dates. They’re infamous for changing things at the last minute without telling you, because it’s tracked in their database according to the system they set up.

To avoid information surprises, I recommend you gather your information from every source on the project. Remember that each person has part of the truth, and when you get enough pieces, you’ll see the whole.

While you’re still gathering the information, don’t start designing your quick reference material, because the information and application is still in a state of flux. Instead, throw that fluctuating, still-under-review, subject-to-change text in an online help file until the content is locked down.

After the help content is truly locked down, not only will you only have to copy and paste once, you’ll know the app well enough to have a clear idea about the essential tasks you need to pull out. Once you do have the essential information, you’ll only have to design on your double-sided page layout once.

Have you had any lessons-learned experiences creating quick reference guides? If so, I’d love to hear them.

Blog Sponsors

Quick Reference Guides: The Poetry of Technical Writing

Tom Johnson — Sun, 06 Jul 2008 22:27:13 +0000

How many times have you written a 75+ page guide and heard the customer say, This is great, but can you give us a condensed version?

After the third or fourth time I’d heard this, I decided to actually try it. I wasn’t sure exactly how to lay it out, so I spent a couple of days flipping through magazines — especially WIRED — looking for attractive layouts to copy.

I also needed a better tool than Word, and managed to acquire a copy of Adobe InDesign. After a few days of prototyping and writing, I finished my first one-page quick reference guide.

At the next project meeting, I brought color copies of this one-page version of instructions. The response was overwhelming. You’d think I was handing out free candy. Everyone wanted one.

They immediately started looking it over. In contrast to the pained expressions I’d seen after handing people long manuals, their faces showed incalculable glee. At that point, I knew the quick reference guide was a must-have deliverable for every one of my projects.

The names can vary — “Cheat Sheet,” “Getting Started,” “Fast Track,” “Job Aid” — but the concept is the same. Condense the most important information into one double-sided page. By “condense” I don’t mean shrink the font to 6 pt., decrease the leading, and eliminate all white space. With the quick reference guide, you take something that’s robust and complex, and distill it down to its essence, but distill it in a way that brings perfect clarity to users. Quick reference guides are like the poetry of technical writing.

Part of the appeal of quick reference guides is the close way they model software learning. Almost invariably, when people need to learn an application, they follow this same pattern:

They sometimes read a little bit about the product (maybe 2-3 minutes).
They open the product and see if it’s intuitive to figure out without the manual.
When they get stuck, they turn to the help for information about a specific task.

The quick reference guide serves the user’s needs in step 1. Arguably, many people don’t even complete step 1, and just dive straight into the application. Still, having a one-page guide to quickly refer to while stumbling around the user interface for the first time can be helpful.

Other than brevity, how then are quick reference guides like poems? It’s more than just being concise. With poetry, the poet attempts to evoke a mood or paint a moment, and in that brief moment, capture the entire essence of something. Here’s an example of one of my favorite poems, “Lying in a Hammock at William Duffy’s Farm in Pine Island, Minnesota,” by James Wright.

Over my head, I see the bronze butterfly
Asleep on the black trunk,
Blowing like a leaf in green shadow.
Down the ravine behind the empty house,
The cowbells follow one another
Into the distances of the afternoon.
To my right,
In a field of sunlight between two pines,
The droppings of last year’s horses
Blaze up into golden stones.
I lean back, as the evening darkens and comes on.
A chicken hawk floats over, looking for home.
I have wasted my life.

In 13 lines, the poet has captured the entire essence of a lazy summer. The last line in particular, “I have wasted my life,” contains levels of depth.

Writing a quick reference guide is much the same effort. It’s not that you merely cut words to give a shorter manual, but that you try to compress the manual and express in its five-word equivalent.

I’ll grant that the task is probably impossible for technical material. Still, the attempt is there. The philosophy remains the same. Teach us how to use this manual in 5 minutes rather than 5 hours. It’s a philosophy of simplification and linguistic efficiency.

Many people think that the relationship between brevity and obscurity trends in the following direction.

In other words, as your writing becomes more brief, the level of obscurity increases. Actually, a good quick reference guide that does the job in a minimalistic way can have the opposite trend: becoming less obscure as the brevity increases.

This is because, simply put, no one reads the big manual. If you force the reader to wade through hours of preliminary text — a table of contents, table of figures, preliminary legal jargon, explanations of icons and style notations, introductory pages, lists of file menus, tab menus, icon meanings, and so on, before even getting to an actual task — the reader’s patience times out long before the manual ever teaches them something. I remember one time I was reading an AuthorIt manual. I’d reached page 87 and still didn’t see a single how-to task.

You don’t want to focus on too much in a quick reference guide. Remember, the poet focuses on a telling moment, and doesn’t narrate the whole of history. Likewise, the scope of a quick reference guide focuses on core tasks — tasks that are representative of the application as a whole.

Also, don’t be deceived by the brevity and scope of the quick reference guide. In wrangling with layout, scope, and concision, you might spend several days writing just one page. But when you’re done you can practically hang it on your cube wall.

A good layout tool is handy when creating quick reference guides. Adobe InDesign is a powerful tool, but you could probably make do with any program you’re familiar with. Here’s a sample quick reference guide template (an Indesign .indd file) that I sometimes start with, and then modify to best fit the help content.

If you have any sample quick reference guide layouts that you like, I’d love to hear about them.

Update: For more information on quick reference guides, see my list of other posts and templates on quick reference guides here.