Ragged-right or justified alignment?

Which alignment on the printed page is better: Ragged-right or justified? It seems that ragged-right is preferable, at least in some circumstances.

Today, I’m re-posting a piece that I first published on April 23, 2009, on the now defunct Content Wrangler site and then moved it to this blog as legacy material that was buried in the dark links of history…

I’m revisiting that post for two reasons: To my surprise, this has been one of my most popular posts in terms of search queries, so apparently this is an interesting topic. And I’ve discovered an additional argument with a twist that was new to me…

But first, let’s rewind…

Last year, I wrote:

How do you argue for the preference of ragged-right over justified alignment in print? Searching the web, I soon came across pages which mentioned research, but it was harder to actually find it.

  • The National Center on Educational Outcomes put out the NCEO Technical Report 37 which summarizes several arguments and references on the topic in “Table 3. Characteristics of Legible Type”, see the entry on “Justification”. Among them are:
    • Margaret Gregory’s and E. C. Poulton’s article “Even versus Uneven Right-hand Margins and the Rate of Comprehension in Reading”, Ergonomics, Volume 13, Issue 4, July 1970, pages 427-434. From the abstract: “… made no difference for good readers, but for the poorer readers the justified style resulted in a significantly worse performance.”
    • Steven Muncer, et al’s article “Right is Wrong: an examination of the effect of right justification on reading”, British Journal of Educational Technology, Volume 17, Issue 1, January 1986, pages 5-10. From the abstract: “… with reading material presented in right-justified format and in ‘ragged’ uneven line format, subjects performed significantly worse on right-justified material.”
    • David R. Thompson’s paper “Reading Print Media: The Effects of Justification and Column Rule on Memory”, paper presented at the Southwest Symposium, Southwest Education Council for Journalism and Mass Communication (Corpus Christi, TX, October 6-7, 1991). From the abstract: “… best score for recall was recorded in the flush left/jagged right.”
  • The UK government agency RNIB’s “Clear print guidelines” on designing printed information that is accessible to people with sight problems: “… avoid justified text as the uneven word spacing can make reading more difficult.”
  • The SEC’s “Plain English Handbook: How to create clear SEC disclosure documents” (PDF), see p. 50: “… spacing between words fluctuates from line to line, causing the eye to stop and constantly readjust.”
  • … and a thoughtful blog post by Ken Adams with an argument by Ellen Lupton, curator of contemporary design at Cooper-Hewitt National Design Museum, and author of “Thinking with Type: A Critical Guide for Designers, Writers, Editors, & Students”: “… subtle word-spacing and letter-spacing algorithms are needed to make justified text look ‘good’.”

Now I’ve found more arguments:

Karen Schriver’s book Dynamics in Document Design of 1997 is both comprehensive and excellent in explaining the motivation, the tools and the history of good document design. Be warned, however, that it deals almost exclusively with printed document design. Online design is the afterthought that takes up Appendix C, pages 506-517. (That detail right there tells you pretty much what kind of a book it is… 🙂 )

Schriver essentially argues that ragged-right vs. justified is the wrong question – imposed on us by software options, I want to add. According to Schriver, the real issue is word spacing.

Regular word spacing makes for faster reading and more accurate comprehension, in both ragged-right and justified text. Much of the software we use for writing gets word spacing in ragged-right alignment reasonably right without too much trouble. The problem with justified text is that it requires a sophisticated balance of letterspacing, word spacing and word hyphenation which much software apparently doesn’t get right automatically. Instead, it…

…creates a disturbing visual illusion known as “rivers” – paths running vertically through the text that connect the blank spaces between words on adjacent lines. (p. 270)

Here’s an illustration of rivers, from the Wikipedia article on Sentence spacing:

An example of the "river" effect in justified text

So, the bottom line is: If you have rivers in your text, consider ragged-right alignment to do your readers a favor – or invest extra time in spacing your lines nicely.

– If you know of any other arguments or sources that can help us tech writers with alignment and justification, please leave a comment!

How advertising is the opposite of documentation

You know that documentation and advertising are at odds, if you’ve worked in either for any length of time. Here’s a conspicuous definition of advertising that’s pretty much the opposite of what documentation does:

I want to make the public aware of something they don’t quite yet know that they know – or have them feel that way. Because they’ll move on that, do you understand? They’ll think they thought of it first. It’s about transferring information, but at the same time about a certain lack of specificity.

I found this in chapter 7 of William Gibson’s novel Pattern Recognition. Last I heard, the book hadn’t yet become one of the seminal texts in advertising, so take it with a grain of salt… 🙂

Trends in technical communication 2010

Tech writers will branch out into related organizational and technological functions, according to the transcontinental webinar on “Technical Commmunication Trends for 2010 and Beyond“.

Sarah O’Keefe from Scriptorium, Ellis Pratt from Cherryleaf and Tony Self from HyperWrite gathered around a virtual crystal ball and shared six trends they’ve indentified.

I’ll summarize and comment on two of the trends that have resonated with me. The recording and slides are available on the web, so be sure to check out all six trends…

Shape an emotional user experience

Ellis sees that documentation will leave its detached attitude behind: Instead, it will be part of a more personable, emotional user experience that’s driven by mutual trust, community participation and brand loyalty. So documentation should be planned as part of a more holistic user experience. Look for docs going touchy-feely is what I was hearing.

I find that very fascinating and engaging – I’m just not sure I really see it. I’m all for making documentation trustworthy and engaging, to empower users and solicit their feedback. But unless you have somewhat homogenous user groups and know them very well, you might rub some of them the wrong way: What’s amiable to some is inappropriate to others.

Much also depends on context: If your product is hip, chime in with hip documentation, why not. But for many professional products, especially in regulated environments such as medicine or pharmacy, I’d rather play it straight to be taken seriously.

Include content curation

Sarah argues that documentation will include content curation, that is the evaluation, editing and incorporation of other people’s contents. As part of larger content strategy, tech writers get to deal with user-generated content and information by colleagues in a company where “everyone can write“. So in addition to producing content, tech writers also become gate-keepers, similar to a newspaper editor or a librarian.

Sarah added that you’ll still have to draw the line due to technology and regulations: You obviously can’t curate sources that are beyond your control (such as third-party blogs), and regulated industries may require you to keep official documentation and user contributions strictly separate.

I think Sarah’s hit on a good compromise between inviting community participation on the one hand, but retaining some (quality) control over the contents on the other hand. I believe such a curating role would make the available content more valuable by presenting it in context and by directing user attention – not unlike a museum curator does!

In fact, content curation is a good description for what I find myself doing frequently: Rather than creating contents from scratch, I collect and aggregate it, write up a nice label (like a wall text, so people know what they’re looking at) and in general make it presentable.

Your turn

What do you think? How do you see our role in the changing tech comm landscape? What does your crystal ball show? Please leave a comment.

How you can manage your career…

You should manage your career as a continuous habit. – That’s the gist I got from a (re-)tweet by my friend Scott at DMN. I bring it into blogland where I can comment on it in more than 140 characters. Thanks, Scott, for bringing an excellent and relevant blog post to my attention!

Lance Haun’s blog Rehaul presents a great guest post by Steve Browne:

10 Career Management Tips In The Age Of Job Fear

Reasons why we don’t…

First, Steve gives some four reasons why we don’t manage our careers. What they have in common is that most of us seem to think of career management as occasional sprints – but not as a continuous habit.

I know this has been true for me: I would try and jumpstart my career management once I got really miserable in a job. Then it would be a lot of effort to make my past achievements presentable to others and to make my future vision clear to me. Which is, of course, only the first step…

Suggestions how we can…

Then Steve lists ten suggestions what we can do to manage our careers. They’re all great suggestions: They are actionable and real, so you’re not chasing some ideal self. At the same time, they are effective enough to rise above the level of mundane tasks. I especially like these three ideas:

4. Intentionally seek professional development

This is good for my job because it keeps my skills sharp and up to date. And it’s good for me because it lets me check whether I like and care about where I’m going.

6. Don’t be a lurker or a slug

By all means, stick your neck out! Do it in a responsible and respectful manner, but do it. It is called technical communication after all…

7. Volunteer and be broad in your scope

Anytime you volunteer, someone’s bound to learn something! And once you’ve volunteered for a bit, you’ve learned enough so you can avoid the topics that are too broad for you… 🙂

– Now, go over to Steve’s post and read it, if you haven’t already… 🙂

Asking your users, part 2

To get the most out of a user survey, make sure your users can give you answers which are measurable and actionable. This is, in my experience, the key to a good user survey.

Make your survey measurable, so you can quantify who among your users requires what from your documentation. This ensures you get a clear picture of the current state of both, users and documentation. It also means you can repeat the survey with little or no changes in a year or two. To see how your demographics have changed and how your documentation has improved.

Make your answers actionable, so you can connect insights from the survey to specific tasks and their priorities. For example, you might find that marketing pushes for a quick start guide, but even novice users don’t really demand it, because most of them find their way around the product using existing documentation or other means.

Today, I’ll look at questions that can help you serve your users better while keeping you efficient and focused. (This comes on the heels of last week’s post where I looked at obvious, yet unfortunate questions.)

Segment users

Segmenting your users is important to distinguish newbies from power users, private from corporate users or whatever groups your product targets and serves. This can help you to prioritize the results and actions. You can ask users to identify with one or several options of segments. For example, ask for which purpose they mainly use the product (if several), how often or how long.

I recommend to respect the users’ anonymity since I think it increases their trust and honesty in the survey. For transparency’s sake, I suggest to start with these profiling questions, so participants already know what they’ve revealed of themselves before they give their opinions.

Survey effectiveness

This means to gauge whether or not your documentation helps users to get stuff done. Bad scores in this area indicate poor coverage: The documentation doesn’t cover (all) the right topics. Be as specific as you need to with questions such as these:

  • Does the documentation help you achieve your task or a step in that task?
  • Does the documentation offer sufficient background or contexts for the instructions it provides?
  • Is the documentation clear, complete and easy to follow?
  • Does the documentation help you to recover from occurred errors?

Survey efficiency

This means to rate how well and quick your documentation helps users to get stuff done. Poor grades suggest poor usability: Users have a hard to time to find or apply the documentation. To survey efficiency, consider questions such as:

  • Can you find the information you need quickly and easily?
  • Does the documentation you find apply to your task or question?
  • Does the documentation “speak your language”?
  • Can you find related information, such as similar topics, quickly and easily?

How others do it

To get a second opinion or if you find that the effective vs. efficient distinction doesn’t work for you, check out:

Your turn

Which strategies have you used to survey users? Feel free to share any tips for what works and what doesn’t!

Asking your users, part 1

We tech writers need to know what our readers need (see “Serving the customer” in my earlier post). One of the simplest ways to find out is to just ask the users. However, the most obvious questions aren’t necessarily the best ones.

Today, I look at some questions that don’t work as well as you might think. Next weeks’ posts will describe questions that do work and how to ask them.

The following obvious questions aren’t bad as such. I just think it’s unlikely that they really help anyone, because they set the wrong kind of expectations on both, users and writers:

  • They demand of users a knowledge and judgment of documentation where most of them have informed opinions at best.
  • They expose writers who ask them to unreasonable or unrealistic demands.

So here are my top 3 obvious, yet unfortunate questions that tech writers can ask of users:

1. What kind of documentation do you need? What do you want to do with the product?

When we tech writers start to write about a product, this is the most important question: What should we write about? The problem is that users usually don’t know either! It’s almost like a teacher asking schoolkids: “So, which part of physics should I explain?”

Instead, ask product management. They should be able to tell you what users are supposed to do with the product, and that’s what you should write about. Collect everything you can get, discard what’s internal, irrelevant or already used by marketing, and use the rest.

2. What format of documentation do you need: Quick start guides, user manuals or reference guides?

As tech writers, we definitely need to know which formats we should provide. But we shouldn’t look to our users to tell us. If we do, novice users will ask for quick-start guides. “Oh, and please include all the background concepts, too!” (Which would make it a less-than-quick-start guide…). Some will ask for video tutorials. Advanced users who are familiar with the concepts and similar products demand reference guides. In short, users will want the format they’re most comfortable with.

Instead, look over the topics you’re writing about:

  • Procedures with numbered steps go well into user manuals and “how to” guides.
  • If you can collect all the most basic and mandatory procedures, that might be your quick-start guide.
  • Very technical information, for example, about permitted value ranges, goes well into reference guides.
  • … and maybe you shouldn’t lock yourself into set formats at all, because you can offer user assistance in an easy-to-use online interface that transcends formats…

3. Is the documentation good? What should be improved?

Of course, we tech writers need to know where our documentation is not as correct and complete, as clear and concise as we aim for. But asking the question in such general terms is less than helpful, since users often cannot judge whether documentation is sufficiently complete and concise. Users may also have differing or unrealistic expectations on the documentation as you can provide it.

Instead, get answers to these questions from internal users or colleagues or, as part of the review process, from subject-matter experts. It’s easier to negotiate with them and takes you out of the spotlight of users who may wonder why you ask them if you can’t deliver.

– In my experience, tech writers need answers to these questions to do their job well. But tech writers who can avoid asking users these very questions have a better chance to do their job efficiently and effectively.

Maybe your experience differs: Have you asked these or similar questions of users? How did that work out? Do you know other “unfortunate questions”?

#1 motivation for tech writers

A sense of purpose! – Having a sense of purpose has motivated me as a tech writer most reliably over the years, regardless of the project at hand. It helps me overcome adverse conditions and huge workloads. But what is that sense of purpose? And how does it work as a motivating force?

A sense of purpose in tech writing

I usually find a sense of purpose outside the document I produce: It can be a recently hired colleague who tells me my manual helped her get up to speed quickly. It can be a customer services colleague who tells me my online help provided the answers a caller needed. It can be colleague from the training crew who recommends my tutorial before or after a training course. Or it can be a customer who felt confident about upgrading because the Release Notes told him what he was getting himself into.

So to me, finding a sense of purpose goes beyond me and my document (though that should still be well laid out, spelled correctly and all that). It is about the relationships which my documentation facilitates between the product and its users. It is knowing that the product and the company are better for the documentation. And it is frequently knowing that my documentation serves the customer.

How a sense of purpose works

A good explanation of the motivational forces of purposeful work is a psychological model called the “Self-Determination Theory” which I found summarized on the Study Hacks blog:

To be happy, your work must fulfill three universal psychological needs: autonomy, competence, and relatedness.

Specifically, excerpted again from the Study Hacks post:

Autonomy refers to control over how you fill your time.
Competence refers to mastering unambiguously useful things.
Relatedness refers to a feeling of connection to others.

That pretty much describes my ideal workplace as a tech writer. Of course, reality takes its toll occasionally, with deadlines, less than useful tools or an out-of-sync irritation when I find that various documents available to customers are at odds.

Ensuring a sense of purpose

If you are managing tech writers, there a few things you can do to make sure your writers can be motivated by a sense of purpose:

  • Allow for sufficiently autonomous time management: I’m all in favor of deadlines, but tech writers and managers should sit down to agree on the desired quality and scope of documentation to come up with reasonable deadlines. Or if you have a set deadline first and foremost, agree on what scope and quality can reasonably be achieved within that time frame.
  • Encourage writers to reach out to other departments to share contents, documents and purpose: Frequently, training and customer services hold related stakes in having high-quality and useful documentation.
  • Ensure that regular documentation user surveys align the supplied documentation with its usage and expectations.

Dan Pink has more advice for managers in his article on “Gainful employment“.

What’s the best motivation for your writing? What provides you with a sense of purpose?