Digital Design Tips

See how our next #Ps25Under25 artist gives material life to her digital designs. https://t.co/l13fYh0Slu pic.twitter.com/tASD7W0S1f

— Adobe Photoshop (@Photoshop) December 14, 2015

For the Technical Writing Newbie

In response to a request for information from a newly-graduated English major seeking work as a technical writer, I provided the following suggestions:

For the newbie tech writer, the game is all about giving yourself as many stand-out selling points as possible.

As many have mentioned, tech writer tool knowledge (Robohelp, Flare, etc.) can be a significant selling point.  For many positions, tool knowledge is the primary issue for many hiring managers.  If you are not an expert in Word or if you cannot demonstrate linking topics in FrameMaker, you are out the door.

Closely related to tool knowledge is knowledge of single-sourcing systems. Admittedly, single-sourcing systems are generally employed only at large and forward-thinking companies (thereby excluding most employers of tech writers).  Nonetheless, if you can get your mind wrapped around the idea of writing self-contained topics, procedures, and concepts; mapping the links between these packets of data; and using the XML usually involved in single-sourcing, you will have an advantage.

In addition to learing the tools, consider familiarizing yourself with concepts of intercultural communication.  Since most products are shipped from America's high-context communication setting (where we expect to be told everything) to low-context cultures (where the reader expects the writer to correctly address a number of culturally-controlled topics -- or they stop reading), a little knowledge on this might help you deliver an outstanding product for your employer.

One other stand-out selling point that a newbie might develop involves interviewing and researching.  If you can demonstrate an ability to gather information and then interview the experts at your employer, it will be to your advantage.

Finally, if you are on LinkedIn, you are obviously oriented toward networking.  However, the one resource that landed me a job at Johnson Space Center and then in the oil industry when NASA was laying off was my networking through the local chapter of the Society for Technical Communication.

Social Media and the Technical Writer's job search

Currently, I have a job as a technical writer; therefore, I do not expect to have to seek a job anytime soon. However, in preparation for the unknown, I have set up a profile on LinkedIn and have cultivated a set of 47 professional connections. Using LinkedIn, I have renewed professional connections that I started when I was more active in the Society for Technical Communication. Additionally, I used connections established through LinkedIn to gain the 150 survey participants for part of my thesis research. Therefore, I seem to be well on the way to proving Noz Urbina’s point that “social media is not just for socializing” (3).

References

Urbina, N. (2010). A super-role for technical communicators. ISTC Communicator,  Retrieved from http://www.farbey.co.uk/wp-content/uploads/2010/03/ISTC_Supplement_on_Social_Media.pdf

Social Media and Technical Writing in Today's Economy

At some high-tech companies, there may be active use of social media resources among their technical communication groups.  However, at a number of companies, many parts of lower management have heard of the hacking of Target's customer database and have an active fear of the weakness of their company's Internet and Intranet systems.  Fear of letting proprietary information about the company product out on the web paralyzes quite a few supervisors.  Still, possibilities exist within social media applications (SMAs) (Stolley 350) that could be useful to technical writers like me.

The safest proposal to advance tomanagement would involve setting up a wiki on our local, protected Intranet.  On that wiki, both technical writers might be able to share information, post edited photos of new components, and store copies of style guides or other reference documents (Wagner and Schroeder 71).

Additionally, I think that it would help technical writers to use tagging to find what blogs, Twitter, and other new media might be saying about the company products (Stolley 356) (Urbina 3).  If I were to be able to prove the value of letting technical writers bookmark sites for an hour and reviewing the results for a few hours per month (as opposed to limiting ourselves to only revising documentation)(Stolley 356), then we might be able to produce documents that address the needs of the audience.

The problem with both of these proposals will be that most technical writers in today's economy are up to our necks in work.  As Panke and Gaiser mentioned (and Amidon and Blythe before them), many corporate writing groups have “minimal physical presence” (323).  Therefore, asking for something that takes time will be a big request.  Still, as Zarella points out, the price is right because:

“New web technologies have made it easy for anyone to create—and, most importantly—distribute their own content. A blog post, tweet, or YouTube video can be produced and viewed by millions virtually for free.”

References

Panke, S., & Gaiser, B. (2009). With my head up in the clouds: Using social tagging to organize knowledge. Journal of Business and Technical Communication, 23(3), 345. doi: 10.1177/1050651909333275

Stolley, K. (2009). Integrating social media into existing work environments: The case of delicious. Journal of Business and Technical Communication, 23(3), 356. doi: 10.1177/1050651909333260

Urbina, N. (2010). A super-role for technical communicators. ISTC Communicator,  Retrieved from http://www.farbey.co.uk/wp-content/uploads/2010/03/ISTC_Supplement_on_Social_Media.pdf

Wagner, C., & Schroeder, A. (2010). Capabilities and roles of enterprise wikis in organizational communication. Technical Communication, 57(1), p.71.

Zarella, D. (2009). Social media marketing book O'Reilly Media, Inc.

Technical Writer Theme Song

For those under the delusion that the image of technical writers has improved over the past 50 years, please consider the concepts central to the following video.

Then again, has anyone considered the light that Dilbert puts on engineers?

Subject Matter Expert Interview Tactics for Technical Writers

For New Projects\New Subject Matter Experts\New Tech Writers

Set Up your Part in the Project

Introduce yourself. If you are new to the company, introduce yourself as the new technical writer. If you are new to the subject matter expert(s), introduce yourself as a writing and editing resource. If you are starting a new project, let everyone know that you control the project.

Get Resources to Study Arrange access to sales material (pamphlets or brochures), web resources, engineering drawings, and legacy manuals.

Arrange a Documentation Kick-Off Meeting

Have a meeting for the team members.  Facilitate having the subject matter experts seeing others involved in documentation.

Present the document development schedule. Provide the major milestones and the delivery dates.

Define the document type and the subject matter expert input needed. So that the subject matter expert will know what topics to bring to the interview, define the type of document to be produced (for example, procedural). Provide specific goals and objectives.

Planning for the Interview

Set up for the Interview

Arrange for the room to be used during the interview.  It is best to select a neutral territory rather than using either your office or the office of the subject matter expert.  While arranging for the room, take consideration of the resources you will need during the interview.  Will you need an outlet or network cable for a computer?

Get stakeholder buy-in.  For every company, there are people who control (and will benefit from the success of) the products produced and the projects.  These are the stakeholders of the company.  Once you convince that stakeholder of the need for your document, you will need to get proof of this.  By getting a letter, note, e-mail, or just an agreement from the stakeholder, it will be easier to get the cooperation of your management and the subject matter expert.

Get management buy-in.  Once stakeholder buy-in is procured (or if no stakeholders can be contacted for support of your documentation), get the support of your management.  Their support will help when subject matter experts must return documents from review in a timely manner.

Get subject matter expert buy-in.  Finally, convince the subject matter expert of the importance of your document.  It may be important to the subject matter expert to have his or her name.

Get approval for the equipment that you will need for the interview.  Specifically, ask for permission to record.  If you will need to photograph equipment or take screen captures as the subject matter expert outlines the necessary procedure, have the camera or computer approved.

Studying for the Interview

Research common knowledge on the topic.  Read textbooks, web pages, trade publications, applicable standards, and other resources.

Research competitor information sources.  Delve into their web sites, brochures, and pamphlets

Research the company’s information sources.  Read legacy manuals, advertisements, brochures, and pamphlets.

Research the audience.  Talk to the sales department and find out whether the purchaser will be the audience.  Look into the audience’s possible education level, supposed interests, language, and ethnicity (for a starting point).

Schedule the Interview

Consider the document schedule.  Consider the date assigned for delivery of the document.  Does the timing of the meeting allow you enough time to accomplish the needed tasks?

Consider the subject matter expert’s schedule.  Your subject matter expert will likely have a number of products to work in addition to providing verbal input to your document.  Whether the subject matter expert is an electrical engineer, programmer, physicist, or other professional, thAlso consider the time that the subject matter expert must spend in review of your text. 

Consider your other projects.  As a technical writer, you can expect to work on four to five projects concurrently.

Prepare for the Subject Matter Expert

Meet the subject matter expert.  Observe his or her demeanor.  Make note of co-workers’ opinions of the subject matter expert.

Determine the subject matter expert’s position in the organization.  Figure out how powerful a position the subject matter expert holds. 

Determine the subject matter expert’s organizational needs.  Does this programmer seek a higher position that could come out of a successful product?  Does this physicist want to publish papers, but needs a proofreader familiar with the publication’s requirements?

Create the Questions for the Interview

Ask open-ended questions.  For example:

• Who uses this product?
• What do they need to know before starting?
• Where does the user enter the commands?
• What maintenance must be done?
• What common errors might the user make?

Center some questions on the process and the product.  With your new knowledge of the product and the user, determine topics that could be confusing and have those topics clarified.

Center some questions on the user.  Make yourself the user’s advocate.

Sequence the questions logically.  You might order the questions to follow the process involved in running the product.  You might order the questions by the type of the input needed (such that physical machinery questions, computer input questions, and questions involving ultrasonics might be addressed separately).

The Interview

Craft the Interview to fit the Subject Matter Expert

If the subject matter expert is uneasy about an interview, start with small talk.

If the subject matter expert is rushed, start the interview.

Listen actively.  That is, listen most of the time, but also repeat back primary points to the subject matter expert.

Listen.  As someone who has only read recently on the technology, the technical writer must allow the subject matter expert to provide the most verbal input.

The Follow-Up and Review

The Follow-Up:  Reviewing the Notes

Perform your note reading and recording review as soon as possible.  Add more text to make your notes understandable.

If there are questions, get back with the subject matter expert as soon as possible.

The Review

When the document has been written, highlight the text that came from your interview so that the subject matter expert can review it for correctness.

Provide an achieveable due date when you send your document for review.

More Reading

Alberts, D. J. (2007). A model of multidiscipline teams in knowledge-creating organizations. Team Performance Management, 13(5/6), 172-183.

Flammia, M. (1993). The challenge of getting technical experts to talk: why interviewing skills are crucial to the technical communication curriculum. Professional Communication, IEEE Transactions on, 36(3), 124-129.

Graphing Bureau of Labor Statistics Data to Track Trends in Technical Writing Employment

As a second response to the same LinkedIn conversation as mentioned in the The Complex Web of Industries Technical Communicators Support post, I created the following short procedure explaining how to make your own Bureau of Labor Statistics (BLS) graphs tracking the top client industries of technical writers nationwide:

1. Go to http://www.bls.gov/oes/tables.htm
2. Download the National industry-specific and by ownership Excel files for the years that you desire to include in your final graph (for example, download oesm11in4.zip and extract file nat3d_M2011_dl.xls)
3. In Excel, select all of column D (occ_code). Go to the Data tab and click the Filter button.
4. At the upper, right corner of column D, a down-triangle will appear. Click it to display a Filter pop-up window.
5. In the Filter window, de-select the Select All checkbox, select the 27-3042 checkbox, and click the OK button.
6. Create a new Excel file and name it TechWritingByYears.
7. Select all rows in the original BLS Excel file and copy them to a new spreadsheet in your TechWritingByYears file. Create a new spreadsheet for each year to be included. Repeat steps 1-5 for each of these years and copy the rows into the year-based spreadsheets in TechWritingByYears.
8. Sort each new spreadsheet on column G (tot_emp).
9. Copy the top rows of the first spreadsheet to a new file (name this one Graph) with new spreadsheets for each year.
10. Repeat steps 8 and 9, copying the top rows of each TechWritingByYears spreadsheet to the corresponding Graph spreadsheet.
11. Create one more spreadsheet within the Graph file. Name this spreadsheet Actual Graph.
12. Copy the top rows out of the first year's Graph spreadsheet and into the the Actual Graph spreadsheet. Eliminate all columns except for the naics, naics_title, and tot_emp columns.
13. Take note of the naics code for each of the technical writing client industries in the Graph spreadsheets created in steps 10 and 11 (for example, naics code 541000 for Professional, Scientific, and Technical Services). (That is, take note of the naics code on each row.)
14. From the Graph year-based spreadsheet for the second year, copy the tot_emp cell from the row that has the naics code corresponding to the naics code for the first row of the first column. Paste the value one column to the left of the cell containing the first year's tot_emp for that naics code. Repeat this process for the second row and each following row until you build an entire column (accounting for all of the technical writing client industries for that year).
15. Repeat steps 13 and 14 until you fill each column for each year. If the titles naics_title and tot_emp are on the spreadsheet, remove naics_title and replace each tot_emp with the year for that column. Delete the naics code column. At the end, you should have a table like that shown below.

Select all rows of the table, go to the Data tab and generate a Line graph.

The Complex Web of Industries Technical Communicators Support

During a LinkedIn conversation at the Technical Writer group, certain technical writers mentioned that the web of industries supported by technical communicators is very complex.  By chance, I had created an illustration in support of a point in my thesis that graphed the top employers of technical writers (refer below).

Although this table and graph only show five sets of industries, the Bureau of Labor Statistics (BLS) data shown comes from the top 10 employers of technical writers.  If you go to the source databases (http://stat.bls.gov/oes/tables.htm, National), you will find that there are over 100 industries that employ technical writers.

From the Trenches of Technical Writing: All Quiet on the Hardware Front

The Only Noise Comes from the Drone of Oilfield Equipment

So, working as a technical writer in the oilfield has its benefits (such as continuing to maintain paid employment during this protracted recession/lame recovery).  As oil climbs to $109/barrel, I am certain that conditions will become tighter for technical writers as more of all companies' resources become tied up by our need for energy.  However, since technical manuals are a resource often sought after by the one group that our employers must not ignore (our customers), technical writers must point out the benefit of providing good technical manuals.

A recent discussion on LinkedIn accented the link between quality technical manuals and good customer relations.

On the Software Front, Single Sourcing is Hot

In technical communication circles associated with software companies, single-source methodologies have taken center stage.  Although this new methodology requires the writer to write toward self-contained topics, concepts, references, or tasks, this methodology allows us to write text once and use it many times.

Please Forgive the Sporadic Posts

Because I am still working on my thesis, these posts will remain light and tight.

Working with Engineers (Part of the "Things to Expect" Series)

Good news and bad news

When it comes to the relationship between engineering and technical writing, there is good news and bad news.  First, the good news comes in a message of continuity – as long as there are products to be designed, companies will need engineers.  Similarly, as long as products are engineered, writing (status reports, white papers, presentations, product brochures, operations manuals, and much more) must support the products.  On the other side, the bad news seated in many engineers’ attitude of writing plagues may technical writers.

Neither of these issues are new.  In her 1990 article Engineering Writing/Writing Engineering, Dorothy Winsor reported on the existence of attitudes that I have encountered throughout my years of working with engineers.  Just as she observed, I have encountered engineers that have seen their job as only designing products – not writing reports or manuals.  Some engineers have pigeon-holed writing as “secretarial work.”  A few engineers have insisted on only providing short answers in personal interviews and data sheets as input to manuals and reports that I have written for them.

Although some of these engineers would never admit it, most of engineers would agree with Ms. Winsor’s assessment of engineers’ reliance on writing.  That is, “while … writing is not the final product, it is an essential means by which that product is created because it is the essential means by which engineering knowledge is created” (343).  These engineers would most likely also agree that the layout, writing style, and formatting used in many of their reports are based only on engineering department tradition that is only perpetuated in order to prove that the engineer is an engineer.  Therefore, the need for trained technical communicators who know to focus on the needs of the user should be painfully obvious.  Through the research of James Paradis as expressed in his Text and Action, it is.

Mr. Paradis discusses how task-oriented literature (user guides, operations manuals … ) must be used make technology useable by people.  As both positive and negative proof of this contention, he points out:

·         Some of the benefits of textual delivery of technical information.  For example, texts can deliver a cost-effective teacher/student ratio (p. 368, first paragraph) or break down complex events or objects (373).

·         A few of the drawbacks of poorly written instructions.  One such drawback occurs when the linearity of written instructions and the need to reduce complex situations results in the omissions, vagueness, and misunderstanding (368).  Another happens as technology becomes more complex and thereby forces the operationalization of human behavior.

·         The textual elements of object, agent, conditions, and action (367) used in task-oriented text.  As I mentioned in my first bullet, the use of action to break down complex events or objects (373) is a very effective tool of writers.  However, as Paradis points out, engineers often ignore this tool.  Therefore, this points to the need for technical writers.

·         Studies of two court cases centering on accidents involving stun guns.  The weaknesses in the manuals (produced as an afterthought by personnel whose primary role was not one of writing for the user) was found to be a major causal factor in the accidents.

Finally, Mr. Paradis observes that “in the legal context, operational discourse takes on the social and material consequences of liability” (375).  Similarly, I have considered how the greatest portion of my writing is used to protect my employer from lawsuits (for example, when I write manuals describing the safe operation of equipment).

Gloomy Good News

So technical writers can expect a good job forecast for the foreseeable future.  Also, before I finish this post sounding like glass-half-empty pessimist, I have to mention that there are indications that things are improving (and those indications will be discussed later).

References

Paradis, J. (1991). Text and action: The operator's manual in context and in court. Textual dynamics of the professions: Historical and contemporary studies of writing in professional communities, 256-278.

Winsor, D. A. (1990). Engineering writing/writing engineering. College Composition and Communication, 41(1), 58-70.

Blogging into Technial Writing

Recently at the Society for Technical Communication group on LinkedIn, a member asked:

Hello, I am considering starting my own blog in hopes of landing a job in Tech Com. Any suggestions on how I should go about that at no cost? For those who have a blog, how has it helped your career? Thanks

At first, this seemed to go against the grain of what I had been taught about both blogging and technical writing.  In Content Rules:  How to Create Killer Blogs, Podcasts, Videos, ... , Handley and Chapman ask "Who are you?  What's unique about you?  What are your point of view and your perspective?"  (p. 21) when pointing the reader to defining himself or herself as a blogger.  Similarly, Macarthy suggests:

Solve Problems
One of the main reasons that people search the Internet is to find solutions to their problems, whether it be how to sew a button back on to their shirt, how to house train their dog, or how a guy makes himself irresistible to the opposite sex. Focusing on the solution to problems, especially for businesses, is a great way to come up with new ideas for blog posts and attract web traffic. Think about the problems that your customers want solving and use your expertise to tell them how they (or your business) can help. To go back to my dog example, a pet store owner might blog about the best way to stop your dog from barking, or how to teach it to sit or fetch. Think about how you can become an invaluable blogging resource for both your customers and those searching for solutions to their problems on the Internet.

Based on these quotes, it would seem that you would at least need to be an emerging expert on the topic before you started blogging.  Similarly, authors of technical writing textbooks have both sought to make technical communicators into experts on information delivery and have encouraged us to seek out the expertise of our subject matter experts (SMEs) (Rainey, Turner, Dayton 324).  Therefore, it does not seem that we should expect to turn both of these paradigms (that of blogging and of technical writing) on their heads.

The problem with this line of thought is that it assumes all bloggers are seeking a wide audience of people seeking our technical writing expertise.  However, the newbie blogger really is seeking to showcase his or her own technical writing skills to potential employers.  Rather than answering the questions of how to perform technical writing tasks, this blogger demonstrates how they have a mastery of the technical writing tool.

Therefore, it seems best to encourage all new and aspiring technical writers to blog.

References

Handley, A., & Chapman, C. C. (2012). Content rules: how to create killer blogs, podcasts, videos, ebooks, webinars (and more) that engage customers and ignite your business (Vol. 13). John Wiley & Sons.

Macarthy, A. (2012). 500 Social Media Marketing Tips: Essential Advice, Hints and Strategy for Business: Facebook, Twitter, Pinterest, Google+, YouTube, Instagram, LinkedIn, and More! Kindle Edition.

Rainey, K.T., Turner, R.K., & Dayton, D. (2005).  Do curricula correspond to managerial expectations: Core competencies for technical communicators. Technical Communication, 52, 323–352.

Four Important Personalities at your Next Professional Society Meeting

When (not if) you visit the local chapter of your professional society, you will likely get more than you expected.  Whether you visited the Society for Technical Communication for a presentation on single-sourcing techniques or the American Medical Writers Association for tips on presenting medical information, you will likely encounter four types at the meeting. 

1. The Critic rarely finds anything or anyone that measures up to the lofty standards formulated by this person.  Although there is value in identifying things that are wrong in a situation, becoming identified with this person by other society members might not help your networking.  So (if you tend not to see the faults where they occur) go ahead and touch base with this person, but don't spend the whole meeting absorbing toxic words.  If you tend toward the critical, spend more time with the rest of the crowd.  In the end, hopefully you will have a good balance of perspectives.
2. The Newbie can bring a new perspective and new energy to old practice; however, if you are new to the profession or new to the profesional society, you do not start with a lack of either.  So the fellow newbies that you find at society meetings should be sought out and recruited as fellow laborers.  Make yourselves accountable to one another in order to stave off the critics.  Make yourself conversational on other newbies' tech comm hot topics.  Encourage eachother to attend meetings. 
3. The Networker keeps current on key technologies and demonstrates that knowledge in conversation and in articles.  This person also keeps in touch with the key people that might want to hire technical writers and the writers who might recommend a colleague.  Therefore, these people are worth following and emulating.
4. The Volunteer keeps the society going.  Therefore, without this class of people, there is no society, no advancement of the field, no opportunities for the critics or newbies, and no network.  By learning the things that make up the volunteer and his or her work, you will be well on your way to building a technical communication career that will make a difference.

Four Things that You Can Expect as a Tech Writer

Once you transition from technical communication classes to real-world technical writing, there are at least four things that you can expect.

1. Your boss will not have had any experience with technical writing.  Most likely, your boss will have worked his or her through the workplace environment.  Therefore, your boss may be very familiar with managing manufacturing personnel.  Your boss may be an expert salesperson.  However, unless you work for a firm that specializes in technical writing, the chance that your boss will be familiar with localization, page design, usability, or any other technical communication topic will be minuscule.
2. Your boss will likely provide grammar edits (usually incorrect), word choices (usually jargon-based), and layout demands that will completely contradict everything that you were taught.  Because you are the new kid on the block, this will be an opportunity to learn both tact and assertiveness.
3. Your boss will have no idea of how long it will take to interview Subject Matter Experts (SMEs), compile a manual, have it reviewed, and send it to print.  Nonetheless, your boss will likely be very familiar with the contractual delivery schedule that everything sold by the company must meet.
4. Your proposals to improve processes will meet resistance.  Still, do not let that stop you from writing style guides.  Your company needs to know to improve intercultural communication (even in brochures and tech manuals) and you need to stand on your training as a technical writer.

Five Things Aspiring Technical Writers Must Do

Anyone desiring to work as a technical writer should take the following five steps, reflect on the steps taken (to see if those steps reflect a true image of the writer), and repeat:

1. Write technically by finding a technical topic you know and producing something that educates the rest of us.  This will involve applying your writing skills in several venues, including:
• Writing articles for an organization that centers on technical communication (refer to #2 on this list)
• Writing procedures for open source programs or non-profit organizations that need documentation
2. Network locally at your local chapter of at least one of the following groups:
• American Medical Writers Association - A great resource for writers working for medical device companies, pharmaceuticals, or similar entities
• Association of Proposal Management Professionals - A place to learn about writing an exciting proposal under tough deadlines
• International Association of Business Communicators - The best resource for organizational writers, public relations writers, and other business writers
• IEEE Professional Communication Society - A resource for writers addressing electronics or software
• Society for Technical Communication - The largest group of technical writers (including a number of special interest groups)
3. Commit yourself to continual learning (of software, of technical writing techniques, and of the technologies we document).  This may involve:
• Accessing online help sites of popular software packages
• Reviewing the current topics in technical writing circles by reading:
• I'd Rather Be Writing - A blog produced by a technical writer
• ffeathers - Another blog written by a technical writer
• STC's Notebook blog - One of many resources available from the STC
• TechComm Today - Another resource from the STC
• One of the many other blogs on technical writing
• Taking classes or doing online research of the techology used by your new employer.  Since I have worked at NASA, a few oil exploration companies, and some computer companies, this has involved a wide range of learning.
4. Network online in addition to your local efforts.  Join LinkedIn groups that are organized around technical communication.  Create a profile for yourself on Monster, Dice, and CareerBuilder.  Make yourself known to the local headhunters.
5. Be visible -- Make certain that your newest writing is available online.  If the chapter of your professional society (refer back to #2) is not online, post it yourself.

Things that Technical Writers Need to Provide (Part 3)

A recent discussion on the Technical Writer group at LinkedIn asked how to explain to a client that a technical writer need not be an expert in the subject matter of the manuals. As technical writers, we have to be learners, but we usually do not begin as experts in the scientific topics we cover. However, we must be:

• Experts in Document Design
Although technical writers do not need to be experts in semiology, psychoanalysis, or content analysis, we need to know enough about document design to create manuals, web sites, brochures, and other communication packages that speak to the audience. We need to know enough about the audience's eye movement across the page to make a page that flows. That is, for English speaking audiences, we need to know that the audience's eye will track from the upper left to the lower right of the page. For audiences who primarily read Chinese, Hebrew, or Arabic, those eyes will track in different directions.

Additionally, we need to be aware of the limitations of the fonts we incorporate (Are the lines so thick that they are hard to read from a distance?), the mix of colors we use (Can the elements of our pictures be distinguished as separate elements?), and the amount of white space incorporated in our illustrations and text. Although Jan White claims that serifs have a functional value in that they direct the eye and san serif fonts anchor the eye (Kostelnick and Roberts, 1998, p142), there have not been corroborating studies confirming these findings. Therefore, other than my own anecdotal evidence in support of White's study, I really cannot recommend this limitation on use of fonts. However, I can point to more than a few sources that would confirm that using more than two or three fonts on a page will reduce the readability of the page (Becker, 2009)(Krug, 2006, p36).

As mentioned previously, we also need to consider the cultural side of our pages and illustrations. Do procedural photos that are directed at Americans include someone pointing to the audience with the middle finger? Does a photo for an Arabian audience show the sole of a model's foot?

References

Becker, E. (2009). AMWA Presentation to UHD.
Kostelnick, C., & Roberts, D. D. (1998). Designing Visual Language: Strategies for Professional Communicators. Needham Heights, MA: Allyn & Bacon.
Krug, S. (2006). Don't make me think: A common sense approach to web usability. Berkeley, Calif: New Riders.

Things that Technical Writers Need to Provide (Part 2)

A recent discussion on the Technical Writer group at LinkedIn asked how to explain to a client that a technical writer need not be an expert in the subject matter of the manuals. As technical writers, we have to be learners, but we usually do not begin as experts in the scientific topics we cover. However, we must be:

• Experts in Communicating Across Cultural Lines Because our audience likely consists of at least one more culture than our own, technical communicators must take account of differences between different cultures. Therefore, G. Hofstede's cultural dimensions, A. Trompenaars' cultural theories, and E. T. Hall's cultural factors should be known and used as a first step in making our manuals applicable across cultural divides. Additionally, knowledge of the audience's culturally-based preferences.
  
  Worldwide audiences have wide-ranging ideas of how one communicates logic, credibility, and the rest of the message. In America, manuals often contain a picture of an open hand with the palm extended (refer to the illustration) to tell the reader to stop and read this text before proceeding. To the Greek, the same picture says “go to hell” (Flammia & Voss, p.84). To a Westerner, white may be associated with brides or the “good guy.” In China and Japan, white is the color of mourning (Vanka, p.16). Therefore, a writer should either know enough about cultural differences that can affect text and graphics or that writer should know enough to have their work checked by an editor for localization issues the document is complete.

(To be continued.)

References

Flammia, M., & Voss, D. (2007). Ethical and Intercultural Challenges For Technical Communicators and Managers in a Shrinking Global Marketplace. Technical Communication, 54(1), 72-87.
Vanka, S. (1997). Culture and Colors: Sacred Green, Lucky Pink? The Futurist. 31(40), 16-17.

Things that Technical Writers Need to Provide (Part 1)

A recent discussion on the Technical Writer group at LinkedIn asked how to explain to a client that a technical writer need not be an expert in the subject matter of the manuals. As technical writers, we have to be learners, but we usually do not begin as experts in the scientific topics we cover. However, we must be:

• Experts in interviewing the subject-matter expert (SME). In other words, we will have researched the topic, formulated intelligent answers, created ways to keep the SME engaged in the conversation, envisioned ways to calm a nervous SME, and organized methods to assemble the information into a helpful document.
• Fluent in speaking to and for the user. As we interview the SME, we must inject questions that the user would ask. As we write, we need to describe the steps of our procedure with the audience's education, technical expertise, and culture in mind. When in meetings, we need to represent the user among the engineering and programming experts. When observing in the design lab, we should bring results of recent usability research. To do these things, we must know the audience. Whether this knowledge comes through conversations with the sales force, through direct-response cards inserted into our manuals, or via social media accounts created for the promotion of our company, it does not matter.
  
  Likewise, as we speak to the reader through our document, we must write with a consistency that promotes user understanding. In other words, we must use one term for each piece of hardware or software that we document. We must resist the temptation to use "fastener" and "clip" for the same piece or switch between "clicks" and "taps" in the same procedure. To ensure this consistency, many writers assemble a glossary and stick to its terms. Additionally, compiling a glossary creates a valuable tool for translation and localization (which brings us to the next point).

To be continued.

A Letter from the Trenches of Technical Writing

Although I have not yet landed a professorial job teaching technical writing, I currently plan to teach technical writing on a part-time basis while continuing to work as a tech writer. Therefore, when I do get that first teaching job, I would like to offer my students the perspective of a technical writer on the front lines.  Having written NAVSEA manuals for 7 years, I have an idea of how to comply with multiple specifications.  Having edited and co-written manuals with the programmers of Unisys (who later became the programmers of the United Space Alliance), I have interviewed Subject Matter Experts, augmented the interviews by looking for their in-code comments, and pulled together their manual on time and under budget.  From my years of contracting with BP, I have experience in writing for offshore systems.  Finally, with over 5 years of working with Tuboscope, I have an idea of the processes involved in using ultrasonics and electromagnetic induction to test ferrous pipe for flaws.

From this experience and more, I would tell students that there are at least four things that you need to be good at to succeed as a technical communicator:

• You need to be write well and like to do it. Any engineer or technician can pull together an unstructured, grammatically-incorrect report (and save the company the expense of your pay). A technical writer is needed to pull together a document that meets the need of the audience while communicating the needed points.
  
  Regarding the part about liking to write, if you are really good at writing, you usually do like it. However, if you hate writing and are only after the paycheck, the tight deadlines usually associated with technical communication might not make this the best profession for the undecided.


• You need to get accustomed to continually learning. While in college, I read that the greatest number of technical writing jobs involved writing about computer programs; therefore, I took classes in COBOL and FORTRAN. Naturally, the first technical writing job I got had nothing to do with programming. Instead, I had to learn about pressure drops, cavitation, metal-to-metal seals, and other issues cogent to valves sold to the Navy. Through my 7 years at that Navy contractor, 12 years at NASA, and 10 years at various oil/gas companies, I have always had to learn topics I had not considered before.
• You need to learn your business environment by:
  • Introducing yourself to the stakeholder for the department that drives the company.
  • Making certain that your communications contribute to that department's and that stakeholder's success.
  • Just looking at the way things are done and following that model (but not giving up what makes you unique).
  • Meeting the subject matter experts and finding out how to help them.


• You need to learn about your audience. When I started tech writing, that meant going to the educational seminars my company provided for chief petty officers. Today, it might include creating a Facebook page, printing a mail-in card for inclusion in manuals, or conducting a wants-and-needs analysis. Additionally, it might include translation and cultural communication considerations (each of which would provide enough material for months of blog posts).

With all of this having been said, I look forward to hearing from you, my newest audience.

Finding the Time to Write Right

At this point, I am:

• Still part of a Master of Science in Professional Writing and Technical Communication at the University of Houston-Downtown (UHD),
• A student of a course on technical communicators' use of social media,
• An employee of at a major player within the oil/gas industry,
• The technical writer in charge of documenting a number products that non-destructively test ferrous pipe, and
• A student that may be within a month of completing his research on his thesis.

I have not yet:

• Finalized the last set of proposals to management regarding cross-cultural communications, localization, single-sourcing, usability testing, or plain language;
• Completed the writing on my thesis;
• Completed the course on technical communicators' use of social media;
• Completed the never-ending train of assignments at work (and am not seeking an end to them); and
• Investigated methods of fulfilling the responsibilities of a professor while working as a technical writer (however, I have read that professors at junior colleges usually work at one other job).

So why am I starting a blog?  Certainly, it is not for a lack of things to do (especially since I am also the father of a teenage son who usually needs as much help with his homework as I once needed).

One reason to start pops up out of the social media class I mentioned. Another reason to write this blog is to build up a reserve of examples I might use as I teach future classes. Maybe some of the blog material I put here might – with the input from all of you – be presentable to my compatriots at work.

The biggest reason that I write comes from my being a writer.