Are serifs or non-serifs easier to read?

Are serif fonts easier to read than non-serif ones? No, is the conclusion in Alex Poole’s exhaustive post.

After reviewing more than 50 studies, Alex comes to the conclusion that “serifs or the lack of them have an effect on legibility, but it is very likely that they are so peripheral to the reading process that this effect is not even worth measuring”.

Serif vs. non-serif fonts as illustrated by Wikipedia

Thanks to Chris Atherton for pointing me to this post which perfectly complements one of my most popular posts: Ragged-right or justified alignment?

I must admit this came as a surprise to me, since I always liked the argument “Serifs are used to guide the horizontal ‘flow’ of the eyes”. But unfortunately, simply liking an argument doesn’t make it so. 🙂 It might just be a case of confirmation bias, as in this case…

Typography primer

Today’s bonus link is to a cool, comprehensive article in Smashing Magazine about typography including justified text, hyphens, dashes, smart and dumb quotes: Mind Your En And Em Dashes – Typographic Etiquette.

Advertisement

Recommended read: Degree helps tech writers

Here’s an example of how graduates of a tech comm program put their skills to use in a high tech company.

Specifically, National Instruments at Austin contributes two guest posts to the Texas Tech STC Student Chapter blog. Yes, these are recruiting posts, but they do ring true. I think they reflect well how a company can take tech comm seriously and benefit from the formal training and academic skills of graduates. It may be an exception among the employers of tech writers, but it’s an encouraging example. So I recommend these two posts:

Tech Writing…It’s Not Just For Tina Anymore
… asks Texas Tech alumni who now work as tech writers and their managers how they can apply what they’ve learned and what advice they have to students and prospective employees:

• Rayo emphasize task analysis before tool skills – which I’m glad to hear.
• Robin gives SME interviews a reality check that strikes a balance between what’s desirable and what’s possible.
• Heather explains how she determines which documentation formats get produced.

Technical Writing Skills
… has Nathan Stokes list and explain 5 skills which every tech writer can benefit from – especially in this less than obvious combination:

• Editing, including yourself: If you can edit yourself, you’ll be a better writer.
• Productivity, i.e., project management skills to keep yourself organized.
• Enthusiasm
• Curiosity, which can drive you and help you to grow.
• Computer Knowledge

– Previously in these pages, I’ve covered a how a (non-tech comm) degree can help a tech writer.

Your turn

Are these skills useful in the tech writer workplace? Can you learn them – or at least expect to learn them – in a tech comm program? If you have any thoughts or experience, please leave a comment.

How a degree helps a technical writer

A college degree can help you in technical writing, though maybe not in the ways you expect.

How relevant is a college education for the field of technical communication? A couple of very good and influential tech writing blogs have recently discussed this issue:

• Why Tech Comm Is a Career Path of Last Resort for Students, by Tom Johnson, about an English department
• Rhetorical theory vs. tech comm reality, by Ryan Fulcher, Scriptorium, about a tech comm program

The question is both pertinent and impertinent, because Tom and Ryan frame it in a way that devalues college education [… at least in the specific program they are criticizing, see Ryan’s comment below. 18 Nov 2010]. Tom says tech comm “should not be taught in the context of an English department, because [it] is not understood or encouraged in traditional English curricula.” Ryan says he’s gained more useful knowledge in 5 months in the job than in his entire time in the tech comm MS program. I cannot argue with their experiences, and I cannot hope to convince them otherwise.

To help anyone with similar questions who’s in college now or has recently graduated, I can offer my own alternative assessment: How a college degree helped me become a passionate and, I dare say, good technical writer.

What I sought

Computer Science and Business as a combined major was how I started college. I sought to learn how to build software and how to run a business. What I got was learning by rote, too much how it’s done and not enough why and how it could be done better. I dropped the major after a semester.

I had embarked on rational and reasonable education and found that my heart wasn’t in it. I just couldn’t see myself spending several years getting a degree as a means to an end. I expected college to teach me something that was interesting in its own right, not a promise that I could apply it in a future job, or maybe not.

American Studies is what I declared as my major after two weeks of soul searching. That’s where I found my academic home. The curriculum was heavy on literature, social history and culture. The emphasis was on understanding what holds the USA and its culture together, to come to terms with its cultural and artistic developments, and to use whatever academic theories could be made useful.

Over ten years ago, I’ve received my M.A. in American Studies. I’m a technical writer by choice and practice, with the heart and the outlook of an Americanist.

What I learned

In American Studies, I learned a lot of things. Almost all of them do not directly relate to technical writing. Here are some things that I’ve found useful and applicable as a technical writer:

• How to write long, coherently argued, understandable papers in correct English. It took me a long time to get it right. It took me longer yet to realize the importance of tailoring my message and language to my audience. And it took me even longer to realize that all this combined is a rare and marketable skill.
• How to explain something that defies explanation to people who think they already know how it works. After you’ve ever tried to explain America to Germans who have it all figured out from movies and news media, writing user manuals is actually pretty easy. Most products I’ve dealt with are less complex than a country of 310 million people, even if you only regard the most recent 400 years.
• How to cope with complexity. Literary studies can appear pretty neat, especially when you deal with only one author or one book. Studying a country and its culture is a more daunting task, not least because the people carry on so, with no regard for your studies. Trying to keep your insights reconciled with an ever-changing reality is a good preparation for your survival in large corporate environments and their organisational quirks.
• How to organize to finish. Formulating a thesis and then framing and arguing it was part of my later assignments. That was a good preparation for writing user manuals from scratch. The “thesis” in that case is the easy part. The customer wants to do stuff with the product and look cool while doing it. But the rest is again up to the writer: Framing the text in a context of use, consulting all available sources, explaining it in the most understandable and most efficient way.
• A turn of phrase occasionally: That a question can be both pertinent and impertinent (see above) is something that I learned from Thoreau’s Walden, the second paragraph of the “Economy” chapter to be precise.

What I know now

A college education can work very well for you, if you take it for what it is and don’t expect something that it isn’t. Stanley Fish makes a very astute argument for what a university can be and do:

When it comes to justifying the humanities, the wrong questions are what benefits do you provide for society (I’m not denying there are some) and are you cost-effective. The right question is how do … your program of research and teaching fit into what we are supposed to be doing as a university.

It’s important to realize that this kind of education comes with no guarantee: It guarantees you neither a job, nor happiness, nor that you’ll always be right or make the right decisions.

But it gives you the tools to gather information, take responsibility and make the decisions that affect your life. In short, such an education can give you hope. In the words of Václav Havel, writer, dramatist, and the first President of the Czech Republic:

Hope … is not the conviction that something will turn out well, but the certainty that something makes sense, regardless of how it turns out.

Your turn

What did you get out of a college education? Was it useful for immediately applicable skills? Was it instrumental to become who you are? Or was it a waste of time?

Psychology & technical communication, Chris Atherton at TCUK

Technical communication benefits greatly from cross-pollination with related disciplines, such as cognitive psychology. That was my conclusion after the presentation “Everything you always wanted to know about psychology and technical communication … but were afraid to ask” by Chris Atherton (@finiteattention).

Chris is an applied cognitive psychologist and Senior Lecturer at the University of Central Lancashire. She has the rare ability to cut through the crap without shortchanging her subject or her audience. She makes Occam’s razor user-friendly, if you will.

Here are my top 3 insights from Chris’ presentation and how I find them applicable to technical communications:

1. Do your reader a favor and supply context

Context relates different pieces of contents. More specifically, it relates what users already know to what they need to learn right now as they read the help. For example, an essential setup procedure is not helping the user, if they don’t know where to set up stuff. Well-written headings and carefully arranged “related links” help users to establish context and to evaluate whether the content they found is relevant to them.

Context also means the “location” of pieces of content. That location can be in a book (for example, about half-way through), on a page or screen (near the top) or in an online table of contents, such as Word’s document map (a sub-topic on one of the first branches after the introduction). Note that all the examples are really vague. But as Chris says, “we remember the gist and location.” And that’s what we go by when we try to find content again.

By the way, Chris pointed to research by Jakob Nielsen who found that location still works on long pages that require vertical scrolling! Apparently, readers do scroll – and remember the general location of what they read.

(You might recognize these points about context as two of my Top 10 things that users want to do in a help system.)

2. Simultaneity implies causality

That means that we often understand two things happening at the same time to be related by cause and effect. In technical communications, this is most relevant to training videos and user interfaces. For example, two call-outs appearing at once will be assumed to be related somehow. Don’t let the user guess, instead:

• Be careful to create logical sequences.
• Avoid presenting alternatives or unrelated items at the same time – and if you do, ensure to label them clearly (which will hopefully clutter up your screen or script enough to convince you to break them apart…).

Another example where simultaneity implies causality is people who can turn off streetlights simply by walking past them – which brings us to:

3. Don’t waste time catering to dogmas

This is a tricky one: Some psychological concepts are generally accepted as facts. Yet they make many scientists gringe, because the numbers and the evidence just aren’t there. For example, Chris referred to substantial criticism that’s hacking away at the alleged foundations of individually preferred learning styles.

For me, as a non-scientist, that means that I can support different learning styles in my documentation if it’s done easily and with no or insignificant additional effort, but I won’t go out of my way.

From here on, it’s a sliding scale into the murky depths of psychobabble which is easier to decode and ridicule. To quote an example from an NLP website: “Use brain gym to calm, energise or reconnect right and left brain for improved concentration.” (Apparently, in most people, the left and right brain are successfully connected, regardless of the brain trouble they may believe to have…)

Your turn

Do you know of other insights from psychology that can benefit technical communications? Or do you want to share ideas or experiences with one of the ideas above? Feel free to leave a comment!

What can tech writers learn from history?

Histories … can reflect on how technology led the field [of technical communication] to this point, … provide a springboard for predicting how technology might affect the field in the years to come, [and help us] make informed decisions about the future…

This is Saul Carliner‘s claim in his concise, yet comprehensive historical essay called, “Computers and Technical Communication in the 21st Century”. I’ll summarize his argument, respond and cite some academic responses.

The essay appeared last November in Rachel Spilka’s Digital Literacy for Technical Communication: 21st Century Theory and Practice, a book that addresses students, educators and practitioners of technical communication (TC) alike.

Carliner tells the history in two parallel strands, first how TC evolved in a large IT company (IBM), and then how technological developments changed the TC workplace. Telling the histories one after the other makes for some redundancy; I’ll merge the strands into one in my summary.

Carliner’s argument

Explaining functions and features to professionals was the main task of TC around 1980. Technical writers were hired either for their technical expertise or for their writing skills.

TC centered on users and their tasks throughout the 80s, when the range of applications and audience widened. The first desktop publishing applications enabled writers to get more involved in the production of their deliverables.

With the rise of PCs in the 90s, three trends drove changes in TC:

• The “GUI revolution”, which presented applications in windows-like desktops, further widened the audience for documentation. Users required task-based documentation for more purposes than before. At the same time, technical communicators could address users in new formats, from searchable online help to self-guided e-learning courses.
• The web and browser technologies have moved publication and delivery of documentation online, where text and images were easier, faster and cheaper to distribute.
• Standards and standard-like formats, such as WinHelp, FrameMaker, HTML, PDF and XML established common interfaces and practices. They ensured that even complex applications could distribute contents and services reliably.

Technical communicators responded to these trends with a new role: User experience experts design interfaces and interactions, for which technical writers structure and define documentation contents.

In the last few years, the three trends have further diversified the tasks and products of technical communicators in both roles. For example, films and sound have become as easy and fast to distribute as text and images. The DITA standard has enhanced the XML standard for TC purposes. Two additional developments shape TC significantly:

• The two-way Web 2.0 has evolved more recently and encourages users to not only consume, but create contents as well in virtually all documentation formats.
• Content management systems support the continuous production and publication of content that can be dynamic and user-specific.

My response

I appreciate Carliner’s grasp which admirably summarizes and structures decades of volatile developments in IT. I was surprised to learn that several technologies that I had taken for granted had been introduced shortly before I started in TC.

It’s interesting to see that some early practices still stick around, for better or worse: We’re still debating whether technical or language skills are more valuable. Carliner’s history is one of evolution, not of discrete stages where a new stage replaces the previous one. So the old is not necessarily bad, the new is not better just because it’s new (and Carliner doesn’t claim it is).

One of his premises seems to need a qualifier: I think that technological developments as such don’t drive the evolution of TC. This idea of “build it, and they will come” has been proven wrong in the dot com bust (which Carliner mentions). Whether or not any technology prevails to change the TC workplace depends on several factors, including its usefulness and efficiency, the marketing and market share.

Given such a complex motivation of changes in TC, I can’t quite imagine how looking at technology might shape the field and help us “make informed decisions in the future.” I think it’s more useful to keep an eye on user benefits and how they’re embodied in use cases and services.

Academic opinions

Syracuse University has used Carliner’s text in their CCR 760 class “TC in the Digital Age” that is part of their Composition and Cultural Rhetoric PhD program. Teacher Mike Frasciello points out that many more roles produce documentation than just technical writers:

In many ways, the activity of producing information products was decentralized and moved out of documentation groups. Business analysts were writing and publishing use-case studies. Programmers were writing help statements as conditional code statements. Quality analysts were writing FAQs and user documentation. These individuals were not recognized as technical communicators…

And Missy, a student, argues that technical communicators’ improved skills to produce their own deliverables is quickly taken for granted and therefore seems to lose value. She makes a comparison to

Deborah Brandt’s Literacy in American Lives when she talks about how increasing access to education and higher rates of literacy are seized (that may not be the right word) by corporate/economic interests that begin to expect (or demand) higher levels of literacy while the way those literacies are valued begins to decrease. So, as Carliner demonstrates when he talks about the kinds of technical skills technical communicators are expected to come into the workplace with, being able to use various kinds of software or internet technologies becomes a necessary prerequisite for technical communication jobs rather than something that is valued as specialized knowledge.

Your turn

What do you think? Does technology drive change in our field? Or is it customers and business? Or is it pointless to separate the factors? And how useful is history as our crystal ball? Feel free to leave a comment…