Posts Tagged 'Technical Communication'

The Engineering Student….and Tech Comm

What is the number one killer of fantastic research and amazing projects? The answer is quite simple – poor communication skills. As an engineering student, I fully understand the daunting task of completing an engineering program. All of our classes are cognitively draining and require constant attention and retention.   The perk of mental “cache emptying and defragging’ is not available to us. However, when I have spoken to working engineers, one thing they mention, time and again, is that they wish they had taken a technical writing class while they were in their undergrad programs.

So, why would I suggest adding ONE MORE CLASS to an already intense load? It doesn’t matter how talented engineers are or what amazing work they may do. If they cannot communicate effectively and clearly, their work or projects are then classified as “okay…not, great, mind you….but ok… MAYBE we will look at it.” However, if engineers are able to utilize strong technical writing and communication tools, their work will be understood, appreciated, and utilized (which is the whole purpose….right???)

The need for strong communication skills does not simply apply to the future. How many classes require technical writing skills students do not have? How many labs, reports, and projects would have seriously benefitted from an engineering technical writing course taken during the sophomore year? The fight to keep an engineering program within a four-year time frame and still meet ABET standards means that classes that would create EXCEPTIONAL engineers are overlooked and under-utilized.   Engineers in the field often have a list of classes that they wish they had taken in school because their work NOW would seriously benefit from them. However, the rigid schedule did not allow for it – Technical Writing, Business, and Tensor Analysis (to name a few).

Engineering students need to understand that their beginning, mid, and end product communication must be understood on many different levels. Reports are not ONLY going to be read and analyzed by other engineers. In most cases, money and needed support is determined by a team within management that is made of “support career fields” that may have engineering training…but do not live within the engineering “life sphere.” “Lay people” are often put in a position of examining work created by engineers. If engineers are not able to thoroughly convey their work in a way that can be understood by non-engineers within their fields, mistakes and misunderstandings produce costly outcomes that could have been avoided.

Why not strive to create exceptional engineers who can communicate across the board of disciplines? Universities across the US are grappling with this very issue. As undergrads, there are classes that are required for creating “well rounded” students. Let’s have one of those classes be something we will ACTUALLY use in both our more advanced classes and our professional lives.   What is the purpose of producing just engineers when we have the option of training engineers who can effectively communicate as well?

Inspired by Melissa Marshall’s so witty plea on a recent Ted Talk, please teach us to talk nerdy!

Advertisements

Writing User Help for Older Users

Facebook’s users are getting older. A recent report found an 80% increase in users over age 55. The effects of this change are reverberating, and it’s not just that teenagers are fleeing Facebook like rats off an aging ship. This older demographic may require different approaches to user help. And that’s why the internet has seen a rise in videos like this one helping seniors adjust to the site:

Facebook isn’t alone. The number of older computer users is growing dramatically. In response, companies like HP have designed technology specifically for older users. And several businesses and non-profits, including one founded by this enterprising San Francisco teen, devote their time to helping seniors learn and use technology.

Gail Lippincott argues that “Technical communicators can play a crucial role in meeting the needs of this growing audience of aging adults by acting as user advocates for accessible documentation and interface design.” This requires understanding how older users might approach and use instructions. Considering research that older users are much more likely to reference a manual, this understanding becomes even more important. While many researchers caution against stereotyping all seniors, they have also uncovered some general tips for writing manuals catered to older users:

  • Consider Formatting: While many seniors are in terrific physical health, others need formatting accommodations to improve a manual’s usability. Larger type, easily-turned pages, and fewer distracting elements can help many users. Demiris, Finkelstein, and Speedie provide several recommendations for accommodating elderly users in web design, and many of their suggestions–such as limiting colors, providing several methods for completing tasks, and providing several ways of getting assistance–apply to user help as well, especially when it’s online. W3Schools also provides accessibility guidelines for older users.
  • Increase User Confidence and Motivation: Older users may assume that they just won’t get new technologies. While watching older people use digital products, researchers Abdusselam Cifter and Hua Dong observed that many weren’t motivated to complete the task and blamed themselves for the failure. Manuals that provide extra cues to increase motivation and confidence can help. Nicole Loorbach, Joyce Karreman, and Michael Steehouder found that adding “confidence” elements to a manual increased the number of tasks users could complete and improved their persistence when facing a difficult task. In the study, confidence elements included a section labeled “No prior knowledge of skills required” to convince users that they, like millions before them, could master the task. The manual also offered strategies for reading the manual and included steps helping users check the success of their work.
  • Provide More Context: Older users may need context that younger users take for granted, such as the purposes of technologies and particular tasks. Patricia Robinson writes, “Older users may not automatically fill in missing information that is obvious to younger users,” partially because their thinking patterns are based on “older technological models.” Technical communicators may need to provide additional information or explain metaphors and processes that might be confusing.
  • Involve the Audience: There’s no better to meet users’ needs than to get them involved. Consulting with seniors and testing documentation with them can only improve the product. Plus, it helps companies avoid patronizing older users by creating user help with titles like “Manual for Seniors Scared of Technology!”

As the blog Workplace Writing argues, businesses can’t afford to ignore seniors. And if they can’t get good help using new technologies, they won’t use them.

Cute Error Messages: How Cute is Too Cute?

Every internet user has experienced the frustration of not connecting to the internet page they want. And by now, most internet users have encountered cute or clever error messages, often “page not found”  (“error 404“) messages. These cute attempts by search engines and content providers try to lessen the user’s annoyance when something goes wrong. Clever “page not found” errors have become so prevalent that the design magazine SpeckyBoy cataloged 50 of the best. Certainly, these clever approaches are better than other options, such as 1) no explanation at all, 2) a dry, technical message about the problem, or 3) a message making the problem seem like the user’s fault. But some of the messages I’ve encountered lately may be too cute for their own good. Cute is a great supplement to a helpful message, but a poor substitute for one.

With that in mind, I’ve been compiling error messages that achieve, or at least attempt, “cute,” in order to find that fine line where cute can still be helpful. Prepare for an onslaught on mildly amusing error screens!

Cute but Helpful

The best cutesy error messages manage to get a laugh (or at least a chuckle), calm the user, place the blame elsewhere, and give the user some options for moving forward. By that criteria, this “page not found” screen from Zenplanner.com is the best error message I’ve seen in the past few months.

ZenError

The “Oh My, How Undignified..” is just funny enough to lighten the situation (especially since users probably imagine the webpage speaking in a British accent. At least I did). Plus, the humor also focuses the blame on the website instead of the user. And the page presents plenty of options for moving forward.

Firefox uses a similar approach with their error screen, which I consider one of the classics of the genre:

FirefoxError

Again, the humor is light and focuses blame on Firefox instead of the user. Plus, users get some suggestions for moving forward (but not links, as in the Zenplanner example above).

And I’m probably biased, but the error screen for my home institution, UAH, balances cutesy and helpful nicely:

UAHError

I think it’s the “UH OH” sign that does it for me. Well, that plus the helpful search box that offers a way forward. The page also puts the technical details at the bottom in light gray font – they are there if you need them, but not in your face where you don’t want them.

Just Cute Enough

Unlike the examples above, some pages just manage to justify their cutesyness by either being pretty funny or marginally helpful (but rarely both). This Google error, with the broken robot, is just endearing enough to momentarily take a user’s mind off the lost page. But the “that’s an error” message doesn’t prove helpful or funny, and the poor robot can’t offer much advice beyond just trying again in 30 seconds, which is what most users would likely try anyways.

GoogleError

On the other hand, some error screens are useless but so funny that they can get away with providing no help. For instance, one of my colleagues recently found this error while searching a library site. It pretty much speaks for itself:

nessieerror

This screen is so cute you might actually be happy that you encountered an error.

Not Cute

Then, there are the error screens that just don’t work. They’re either not helpful, not funny, or both. The retro feel of this Panopto error screen does little to alleviate a user’s irritation, and it provides nothing but a dead end.

PanoptoError

But the worst “cute” error message I’ve seen recently is more confusing than funny.

MonkeysError

The highly trained monkeys line shows promise, but then the joke goes too far. Can I really contact someone, monkey or not? Should I really share this text? Does the text actually mean something, or is it part of the joke? Plus, the giant block of text isn’t helping anything.

The Bottom Line

Cute error messages show that technical communication can be fun, personable, and engaging. At their best, they improve an unpleasant experience. At their worst, they intensify it. If you’re aiming for a cute error message, make sure that the tone of the joke fits in with the overall message, places the blame off the user, and provides users a way forward.

Technical Writers? We Don’t Need No Stinkin’ Technical Writers. Oh, Wait…..

Imagine: A quiet day at the office. Working away, on-target and on time, when suddenly the universe hurls a supermassive monkey wrench into your plans. All you can do is scramble to adapt. There’s no one there to help you. No one there to guide you. And it’s life or death because “your office” is… SPACE!

Image

Sound like the plot of the latest Hollywood blockbuster? Well, it is. We can all relate to this situation from Gravity, the latest movie starring Sandra Bullock. We’re in the middle of an important task, we’re alone, and technical problems arise. What’s a user to do? We consult the manual!

Who writes this stuff, anyway?

User manuals are not generally known for ease of reading. No one I know takes them to the beach or on vacation as a pleasure read. And yet we have them. We have them because we need them. But who actually writes these manuals? In recent years, some in the technical communication industry have noticed a trend toward Subject Matter Experts (SMEs) as technical writers. A recent internet search for technical writing jobs reflects this trend. Requirements include “Bachelor’s degree in Computer Science/Engineering or a related technical discipline,” “Bachelor’s degree and five years work related experience or a Master’s degree and one year work related experience in a relevant technical discipline,” and “Bachelor’s degree (in related technical field) or equivalent, and zero to two years of related (technical writing and copy editing) experience.” It would seem the “writing” part of technical writing is taking a back seat to the technical aspect. While knowledge of the topic is certainly important, knowledge of writing, specifically the methods and theories of technical writing, cannot be overlooked.

In space, in the office, or at home (SPOILERS)

In Gravity, Bullock plays Dr. Ryan Stone, who finds herself alone and faced with the need for knowledge of complex equipment. What does she do? All her other resources have been cut off – her communications with NASA have been lost and (SPOILER ALERT!) all the other astronauts are dead. So she gets out the manual, just like any user would do. And, voila! She’s alone no more. It’s as though she has a technical writer with her.

Image

Dr. Stone’s best chance of getting back to Earth alive is to pilot a Russian Soyuz capsule from the International Space Station back into Earth’s atmosphere. Piece of cake, right? Sure, until that monkey wrench enters orbit. How about a ship that’s out of gas AND has a dashboard written in Russian (which she doesn’t read)? Luckily for Dr. Stone, there’s a manual in English. Assuming that manual is accurate, easy to follow, and well organized, she should be home free! (This is where we hope NASA hires good technical writers, or she’ll never make it home.) The craft of a technical writer – conveying the right information, and only the right information, when, where, and how the user needs it – is what she’s counting on now. Whether at home, at work, or in orbit, all users need accessible information that works for them in their specific situation – even a situation like Dr. Stone’s, that the technical writer probably never dreamed of.

User Needs — in Space and on Earth

Image

Dr. Stone has a task she must complete; like most users, she dips in to the manual, finds the information she needs, and dips out again. Most do not read the entire manual. (Ron Byrne offers insight into why in the HCi Journal of Information Development.) Even though some users (like Dr. Stone) may have been trained on the product or a version thereof, situations arise where very specialized information is needed. Information that can take a user

from this   Image

to this       Image

or from this Image

to this        Image.

Who can best convey this information? I vote for trained technical writers. Chunking, relevance, consistency, and hierarchy – these are ideas that technical writers have thought about, are experienced with, and know how to execute. (More on these components of information mapping on the TechWriter Wiki and I’d Rather Be Writing.) Others have argued that technical writers are necessary for clarity and to reduce costs, to act as user advocates, and as usability experts. Add to that someone whose documentation can get me home in one piece – or just help me make the printer work – and it’s clear. Technical writers? Yes… we do need them.

– Mandy Hughes

Designing Dynamically

Technical writing is often built around encouraging action on the part of the reader, like instructions for building a piece of furniture. While words alone can be effective, many have chosen to use illustrations as part of that, not only including pictures of objects, but of objects being acted upon by a visible person. In American popular culture this has been seen before and technical communicators can learn from the art of the comic book.

 

Personas

                The most obvious is the figure itself. In comic books you develop personalities that are developed over time and then reinvented for a new audience when the original personality no longer connects with the intended readership. While technical communication rarely develops personalities, it can try to connect to the audience through art as well as words.

In some technical documents, like Scott McCloud’s Understanding Comics, the author is very clear about his reference material… he draws himself as a guide. But, in mainstream comics, the figure is often masked or hidden. The first is a way of connecting to the reader on a personal level, but it doesn’t create a persona for the reader in the way that mainstream comics often do. Arms and hands are often visible, and perhaps the most important element of all is the ¾ rule… the figure is not shown straight on or completely from the side, but a mix of both. This creates dimensionality and encourages engagement.

Art

McCloud himself points to the simplicity of comic art as a good thing; it emphasizes what the artist is trying to communicate. This is already an active principle in technical communication, but the awareness of it. Michael Opsteegh’s article for “Techniscribe,” “What Technical Communicators can learn from Comics,” covers much of the elements that can be duplicated in technical communications, such as wavy lines to indicate a bad smell, or straight lines to show speed.

Design

Opsteegh even takes us back in time to Will Eisner’s M16A manual, given in WWII to soldiers in order to efficiently communicate the care and use of the weapon, but Opsteegh misses an important part of  the art of comic books, even in Eisner’s case. Instead of looking at an individual panel, or one piece of art, we can look at the page design. Comics have ranged from magazine size (in the Golden Age of comics) through to pamplets (like Chick Tracts, some Tijuana Bibles, and other experimental efforts). This has required some interesting artistic choices. Eisner, in “Comics and Sequential Art,” talks about the flow of information across panels, unifying the document. Any technical document that wants to motivate the reader needs to do more than just guide the reader with big arrows… it also needs to design the page so that the graphical elements in the instructions themselves naturally flow toward the next instruction.

You can bet that with the rise of graphic journalism, the need to communicate to non-literate audiences, and the ability to create information dense documents, you’ll be seeing more graphic communications in your technical soup.

Talking the Talk: Being Articulate at Your Job Interview

If you have expertise in Word and Excel, create InDesign documents just for giggles, and hold an academic resume that deserves an award, then I owe you a hearty congratulation. You are officially a technical communication geek! [Audience wildly applauds and chants your name.] You probably have spent a substantial amount of time and effort on learning how to manipulate various editing and publishing software and you are ready to move up in the world, as a professional technical writer. Presenting yourself in a resume, as a skillful and competent candidate, is just half the battle when persuading an employer that you’re the right one for the job. In Pete Geissler’s, The Power of Being Articulate, he interviews company CEOs who hire their management team not only for what they know, but their ability to effectively communicate what they know. The ability to communicate effectively, with Standard English, has taken a back seat in the Technological Age, while brief electronic messages have dominated interoffice communication.  It is one thing to be an SME, but lacking the ability to communicate your genius ideas it is another which brings me to my point.

Tip 1– Don’t be an ummm person. You know the language that is filled with excessive unintelligible murmuring.  We are all guilty of brain farts every now and then, but lacing your sentences with too many ummms can disrupt your audience from clearly hearing your message. Writing your thoughts before you present an idea will improve your speech delivery. You will be able to recall your main points quicker than if you had not prepared at all. You will be praised for your ability to deliver details without meandering and never getting to the point.

Tip 2 – Know your stuff, and tell it. For instance, if you are interviewing with a company that does contracts with the government, then you should look up some basic conventions for MIL-STDs (military standards). Be somewhat familiar with the writing style that you will use on the job and articulate your knowledge about it. If your interviewer is not impressed, then at least they have an idea of how well you take initiative to be prepared. You will be showing on-the-job skills before being hired! If your interviewer does not notice your initiative, then they are just a bad person. Hmph!

Tip 3 – Don’t be a chatterbox. In his book, Geissler mentions several habits that articulate people avoid, and one of them is being verbose.  He says, Articulates never interrupt or finish the sentence of those who are speaking to them, and they avoid people who do. While on your interview, remember that communication is a tool for conveying your ideas, answering interview questions, and articulating your awesome abilities. Make your responses concise and to the point. You may want to refrain from regurgitating the tech comm encyclopedia during your interview. Don’t fret! You can impress your friends with your new found jargon later. 

-Jennifer F.

Technical Communication in the Game Development Industry

As a gamer, I have been wondering about the job outlook for technical communicators within the video game development industry. This seems like a fantastically exciting industry to work in if one is a technical communicator who just so happens to be a gamer and passionate about gaming. After completing an exhaustive search on the internet for technical communication jobs within the gaming industry, I found that it seems like they are either hard to find or are slim to none.  So I figured that these jobs must be titled something else other than the usual technical communicator or technical writer.

According to a whitepaper on the gaming industry by Laura Hamilton, there are four common job titles for technical communicators in the gaming industry which include, “instruction manual writer, web content writer, strategy guide writer and game designer.” (Hamilton)

The instruction manual writer writes the small instructional booklet that comes with the game inside the case. This booklet lists rules, controls and other important information needed for a user to get started playing the game. The web content writers write technical content for the development company website.

The strategy guide writers write books which help users complete and win the game. In some cases, these books can be referred to as a “walk-through” of the game. A good example of a strategy guide would be the Elder Scrolls V: Skyrim Official Strategy Guide by David Hodgson.

Image

 

Game designers write the game design document. According to gamasutra.com, a major website for game developers, it says, “the purpose of documentation is to communicate the vision in sufficient detail to implement it.”  So the game designers would come up with an idea for the game and put it on paper which would act as a guide for further creation of the game. Next, the designer would use this document to make a technical design document. According to Sloper, this is, “a document that describes the process they will use; what engine or other technology, and will identify the challenges (of designing the game) and address how to handle them.”  Lastly, the game designer would create a game proposal. According to gamasutra.com this document should include, “the revised game concept, market analysis, technical analysis, legal analysis, and cost and revenue projections.” After the game designers have gotten everything about the new game on paper, they will work with the programmers and other team members to make the game come to life.

There are many video game development companies in the United States. One of the most prominent ones is called 343 Industries which is owned by Microsoft Studios. 343 developed Halo 4 which came out about three weeks ago.  343 industries is now in control of all things Halo related. Halo was once controlled by Bungie, until they broke off from Microsoft and became independent. Afterward, Microsoft created 343 Industries to take control of Halo. 343 Industries is based out of Washington.

Image

 

Another popular video game development company is Bethesda which is owned by ZeniMax Media. Bethesda is both a developer and a publisher and they are based in Maryland. They have released games such as the popular Fallout 3 and the entire Elder Scrolls series including the award-winning Skyrim.

A third popular video game development company is Epic Games. They have made games like Gears of War and the Unreal Series. They are based in North Carolina. A fourth popular development company is Gear Box Software. They made the Borderlands series and the Brothers in Arms series. Gear Box Software is based out of Texas.

Image

 

The last two popular development companies I researched were Infinity Ward and Treyarch. Both companies have worked on and developed games in the Call of Duty series. These two companies are both owned by Activision Blizzard, which publishes their games. Infinity Ward made the first Call of Duty as well as four other games in the Call of Duty franchise. Treyarch has made Black Ops, Spiderman 3 and Quantum of Solace. Infinity Ward and Treyarch are both located in California.

Image

 

It seems like there are technical communication jobs in the game development industry, but they are hard to find. I am glad I did the search early enough to know what I am in for when I do start job hunting. If anyone has any other information on this topic, please let me know.

 

Ruby A. Stevens

 


Archives

Advertisements