First impressions or assumptions based on the words we use

I love the Nielsen Norman Group articles. Their tag line summarizes their style of writing well: “Evidence-Based User Experience Research, Training, and Consulting.” Their articles are focused, on a single topic, and they always include inline links to other articles they are referring to or building off of. My favorite part of their articles, when they include it, is the references section at the bottom. I’d bet most people skip that section, but I always find the gems of evidence-based research there. Today’s article was no exception.

Hoa Loranger posted the article, “Cringeworthy Words to Cut from Online Copy,” and the references section was a pleasant surprise for me. The article itself reports personal choices of “cringeworthy” words (such as utilize, enables, and very) — what a great word cringeworthy is to choose to use here, to convey the emotion behind certain words, to convey how readers make assumptions based on the words we use. Within the introduction and the five choices are links to other NN/g articles that back up her choices. (I encourage you to explore all of the articles linked to in this one.)

When I got to the conclusion and saw the reference, I did not expect to find an article that was published in Applied Cognitive Psychology journal:

Oppenheimer, D. M.(2006). Consequences of erudite vernacular utilized irrespective of necessity: Problems with using long words needlessly. Applied Cognitive Psychology, 20, 139-156.

(I found a PDF of this journal article from a handy-dandy Google search.)

How could I not go and try to read a journal article with such an appropriate title and subtitle? I geeked out as I read through the journal article, which described 5 different experiments that were performed at Stanford University. The net results stated: “needless complexity leads to negative evaluations” in particular about the author’s intelligence. While many people often use more complex words in an attempt to sound more intelligent, these experiments showed that the opposite first impression occurred. Oppenheimer does acknowledge that the experiments were limited to a student population, and that complex words might not always be problematic if the intended audience were more likely to readily understand those complex words.

Once again, we are brought back around to two basic guiding principles of technical communication: (1) know your audience and (2) keep it simple.

Posted in Copy editing, Language, Terminology, Writing | 2 Comments

Standard English is built from agreed-upon conventions

I’m busily preparing a course for the UCSC Silicon Valley Extension Technical Communication certificate program. It is “Grammar and Style for Technical Communicators.” I’ve chosen three (yes, three!) textbooks, and I continue to find wonderful articles across the bloggersphere and twittersphere that I keep adding to the introduction area. I do realize that most of the students who sign up for this class are doing so only because it is one of the required courses before they can take other courses in the certificate program. I guess I am hopeful that the students might enjoy discussing or debating the ideas behind the pedantic arguments about grammar (which are often not really about grammar, but about style, but let’s not digress and go there).

One of my favorite blogs about grammar is the Lingua Franca blog on the Chronicle of Higher Education site. A blog post from March 2015 made its way around the Twittersphere recently called “Talking About Grammar Pedantry.” It is a wonderful essay about Standard English. This quote from the post is at the heart of my grammar course:

Standard English, like all standard languages, can serve as a kind of lingua franca, especially in writing, for people who use different dialects. It also provides a target for speakers learning English as a second or foreign language. The problems emerge when standard English gets mistakenly equated with “the only kind of good/right/correct English.”

I applaud this author’s view that we should avoid “proper” or “correct” modifiers for English. Also, the author likes to use the word “conventions” instead of “rules,” to bring the conversation away from the polarization that comes from engaging in grammar pedantry. Standard English is an agreed upon set of conventions for the written word such that we can write, edit, revise, and potentially translate the information quickly and easily. And another great quote from the post about pedantry:

What a good usage guide can do is help us understand and effectively navigate those distinctions to achieve our own purposes as speakers and writers without ill-founded and sometimes snobbish pedantry.

To be a good technical communicator — be that a technical writer or a technical editor — you must be able to understand style guides and usage guides for your products and communications. I think that’s why I assigned three different textbooks for my course; I want my students to see how differently authors organize the grammatical and stylistic conventions for producing clear communication. You encounter and use many different style and usage guides, so having a solid foundation in grammar and style is a key to your success as a technical communicator.

Posted in Copy editing, Grammar

The value of edit summaries

After you complete an edit, do you take the time to review your edits as a whole and write an edit summary for the author? Or, is this (or some part of this) just part of your email that you communicate with the author?

To create a non-adversarial relationship with your author, you need to help your edits be considered more openly so that more of your suggested changes will be accepted and made. Editing is a critical process, and it is hard to have your writing criticized. As much as we editors might want our authors to believe that we are partners in producing the best possible information, the undercurrent of criticism will always be there. By taking the time to write 3 short sentences that summarize your edits, and trying to call out one positive element to the writing, you can build that partnership.

I was struck by An American Editor’s blog post about “trigger warnings,” and his musings about whether he should provide them to his authors. He doesn’t feel that we should need to provide them, but I think they can help build relationships and help more of our work be accepted and incorporated.

Happy editing everyone!

Posted in Copy editing, Substantive editing, Technical Editing | 2 Comments

2015 in review

The stats helper monkeys prepared a 2015 annual report for my blog.

Here's an excerpt:

A San Francisco cable car holds 60 people. This blog was viewed about 2,000 times in 2015. If it were a cable car, it would take about 33 trips to carry that many people.

Click here to see the complete report.

Posted in Blog

Many hats…but one love of technical editing

About a year ago, I wrote a post about where I was taking my blog — I was widening the scope to include more than just technical editing topics as my very first post suggested.

I did post on a much broader set of topics in 2015, but my technical editing topics continue to be the most viewed and most popular. I’m thrilled that one of my first posts, “Defining technical editing,” continues to be my most viewed blog post, year after year (I bet it is on a syllabus in some course somewhere!). As I prepare to teach a grammar course (for students in techcomm programs), I review and muse upon my posts this year and previous years about just how much grammar technical editors need to know. I hope to blog about the course in the new year.

One of my favorite posts this year was “10 basics every communicator needs.” It was based on an article about what journalists need today, but I applied the basics to the many hats we wear. I wrote a few posts like that — taking something targeted to one area and applying it or showing how to apply it to my own area. Because I changed jobs this year, and I no longer work in an information development department on product documentation, I started broadening my reading to even beyond techcomm topics — to content marketing. Even now, even after reading and writing about content marketing, I still have trouble accepting or thinking about what I do as content marketing.

I hope I get into the groove of posting regularly again, like I did at the start of 2015. I hope you all continue to enjoy the random ruminations of this editor at heart who enjoys wearing many hats.

Posted in Content Strategy, Information Architecture, Technical Editing

Learning from the 2015 web design trends

Hello, loyal readers! Here we are, at the end of another year, and I once again struggled to keep an even publishing schedule of posts. I start out strong, hit a vacation time, and struggle to get back into the rhythm again. Well, a new year is right around the corner, so hopefully I’ll do better next year.

My Twitter feed served up the article, “The 10 Big Web Design Trends of 2015” by Jerry Cao, and it just seemed like a really good one to review my year and share some ideas of what writers, editors, information architects, and content strategists can learn from these web design trends.

Each of these trends are for web site design, but I found myself thinking about just how many we apply to the technical communication that we work on or deliver either via a web page, web site, or online delivery mechanism of some kind. In addition to describing each trend, Cao does a great job of providing a list of tips and a list of free online resources. Spend some time on this one, as it really provides a wealth of great information. Here are the 10 trends, with my own thoughts on how they might apply to technical communication:

  1. Minimalism – In some ways, this could better be said by “simplicity” but minimalism is in the mainstream now. In technical communication, or really training, there is the minimalism principle that we have been applying for quite some time. Here’s my own blog post about minimalism.
  2. Long scrolling – Jakob Neilsen and Jared Spool have been repeatedly debunking the myth that users don’t scroll and don’t like to scroll, and the one article that he links to about the “below the fold” myth includes links to these classic researchers in our field. In my personal experience, I am truly annoyed by news sites or resource sites that break an article into multiple pages instead of one uber-long page; it’s much easier for me to skim and scan one single page than have to click multiple times and wait for pages to load. Seems like this is an artifact of more mobile devices?
  3. Flat design – Making graphics simpler, so that they load more quickly, especially on mobile devices is definitely where we are headed. I’m not a graphics person, so some of what Cao suggests here goes right over my head, but I can definitely appreciate the KISS principle!
  4. Powerful animations – While it would be easy to associate this with providing more video content, which many technical communicators are doing these days, I think this speaks to animations within the user interface. Animations that are just a part of the interface design, not part of the content per se. (I wrote a blog post that summarized my notes from a webinar on video production, and the different types of videos we might need to create for our users.)
  5. Lively colors – Oh my! I don’t know that this really applies to much of our content, but choosing colors based on color theory does sound like good advice. Personally, I’d have a hard time integrating bright or lively colors in any of my designs.
  6. HD backgrounds – So many of our devices are HD or can take advantage of HD displays. I definitely work with our graphics team for background images for banners to take advantage of this.
  7. Expressive photography – So many sites (have you seen Apple’s site lately? or even Microsoft’s site!?) are starting to include photographs of people using technology on their site, instead of drawings of objects and things. I think this is fine for more marketing content, but for technical content, you still need the diagrams and screen grabs to support your text.
  8. Dynamic typography – Cao suggests remembering minimalism and flat design, and the simplicity of those two trends, as choosing the one or two typefaces for your site, or your content. Legible and readable must take center stage in applying this design to our information.
  9. Fuller interactions – From personalization to comments to notifications, to unique sounds as they make their way through the site, all of these ways of letting the user engage with and interact with the content is important. Clickable buttons to highlight downloadable code or sample apps they can run all enhance the user information experience..
  10. Card layouts – I think of this trend as the Pinterest Effect. They implemented cards as their site design years ago, and between Twitter cards and Facebook share posts, this layout has really taken hold. An image, a title, an abstract, and a link to the full page or article. It’s a dynamic, simple way to present information that users seem drawn to. How might you redesign a top-most topic or top-most page to show the sub-topics chunked into card-like elements?
Posted in Content Strategy, Information Architecture

Defining information architecture

A few year’s ago, I made a pass at defining information architecture from a technical communicator’s perspective, which described how I morphed from a technical editor into an information architect, and which was mostly based off of Peter Morville’s work. This morning, I ran across UX Booth’s “Complete Beginner’s Guide to Information Architecture,” which is more based on Richard Saul Wurman’s work and Dan Klyn’s as well. Klyn’s video that introduces IA is embedded within this guide, and in just 4 minutes, you are taken from Wurman, to Morville, to his own definitions of IA.

There are a few things that I want to muse upon, extending my own initial attempt at defining information architecture, as my definition and my tasks as an information architect are definitely more in line with what is presented in this UX Booth guide.

From a technical communicator’s perspective, I feel that there is a continuum of IA work: UX to IA to Content Strategist. When describing the tasks that an IA does, this guide talks of user research and analysis, which to me falls more in the UX space. So, IAs partner with UX to contribute to and benefit from any user research and analysis. Another set of tasks is navigation and hierarchy, and also wireframing, which really seem to be shared tasks between UX and IA, with either one leading or driving this effort. Then, we venture into the true IA baileywick with the tasks of labeling, taxonomies, and metadata. (I think it is here that technical editors start to become IAs or interact more with IAs, because of the focus on language and meaning inherent in each of these.) Finally, the last task that they describe is content modeling, which to me falls more in the content strategy space, with the IA partnering and contributing to the modeling. While an IA can certainly do all of these tasks, I think it is important not to think of these tasks as only a part of IA. Much like technical communication, information architecture is a broad field that crosses into many other realms; many different professionals DO information architecture.

I’m now going to cycle around to Klyn’s video, and the three things he includes in his definition of information architecture: ontology, taxonomy, and choreography. I loved his definition of ontology, which I took to mean “the rules and patterns that govern the meaning” of something. And, his for taxonomy, he nailed it again with “systems and structures for what everything’s called.” Then, for choreography, which I thought was a very interesting word choice, he essentially was referring to the human interaction with things. He summarized his definition by returning to a definition within Wurman: Making the complex clear. It’s no wonder so many technical communicators start to call themselves information architects, because making the complex clear is also at the heart of our own realm.

Posted in Information Architecture