Wednesday, Jan. 8

QUiz Recap and Major Takeaways

Reading Quiz #1 (10)

• We won't recap every single one of these, but I want to go over the quiz for today.

Share Writing from Reading Responses (15)

Normally, I will share excerpts from your writing to spark discussion about the readings. I will highlight responses that offer diverse and relevant connections, and that pose good questions about the content. I will not critique or say negative things about your writing when sharing these responses. 

If you do not want your writing shared in class, please let me know at the top of your Reading Response and Dig Deeper submissions. (Ex. "Please do not share this response in class")

Safeeyah, Langston, Kosuke, Helen, Kendra, Haochen

Safeeyah

• Technical communication, as discussed in Introduction to Technical Communication and the foreword to Technical and Professional Communication, emphasizes the importance of understanding and adapting to audience needs​. A great example of this can be seen in health tracking apps like MyFitnessPal. These apps cater to diverse users by addressing cultural attitudes toward fitness, varying levels of technical skills, and accessibility requirements. By using clear instructions, intuitive designs, and features like language options or data visualizations, these apps make complex information easy to understand and use. This aligns with the technical communication goal of creating user-friendly and effective tools that solve real-world problems.

Langston

• One of the biggest takeaways I got from the reading was the importance of, and how to look at, audience in the process of technical communication. I think this is really important to me because of the communities I am a part of. For example, if technical communication is geared toward the Black American community, there is already cultural knowledge and general understanding that other communities may not have. Depending on how this information is provided (tone, paternal, info the community already knows), the intended audience may not receive the information as it was intended. Additionally, in communication, the Black community (among some other American communities) generally prefers tone and sentence structure as a mode of clarity, while non-Black communities often prioritize diction. Thus, if this technical communication is geared toward the Black community, the writer(s) might prioritize tone and sentence structure instead of diction. Moreover, examples to clarify certain concepts/instructions/etc. would also benefit from being culturally connected to the audience. For example, if an example references haircare, there would be---not only---an functional disconnect from the community---but also---an emotional one, a sense of "this is not for me." 

Kosuke

• The first reading by Markel and Selber, Ch. 1 Introduction to Technical Communication was honestly a lot harder of a read than the second one. It felt like that the Markel and Selber's reading was more geared towards research and advancement of the field of Technical Communication and Johnson-Eilola and Selber's reading was more geared towards the practical application of Technical Communication (guidelines, importance, etc..) 

It's interesting to me that Selber is the Author in both of these texts but there seemed to be some clashing ideas. In Markel and Selber's reading they mention how ambiguity is a part of language and technology and not really a problem, that it might become a positive resource. (They do mention that eliminating ambiguity was a vital strategy historically). But in the second reading they mention clarity as a defining characteristic of a excellence in technical documents and under it they have "Your goal is to produce a document that conveys a single meaning the reader can understand easily." I think the key word here is "conveys a single meaning." 

Helen

• The Markel and Selber reading reminds me of the time I worked at a clinic over the summer. I had a front desk position, and one of my duties involved taking calls from patients both old and new. Since the clinic I worked at did not have a website, I’d occasionally get a new patient inquiring about what exactly our clinic does. Without really realizing it, I was practicing a minor form of technical communication through the phone whenever I would answer questions about the clinic. I would have to first listen to see if patients were calling in using Chinese or English, as the majority of our patients were Chinese, and if they used Chinese, I would have to use Chinese during the call to make their experience calling the clinic smoother. I would then give a basic overview of our clinic—our hours, what our doctor does, and the fact that we always have a really long waitlist. If patients had further questions about things like insurance or if we can see children, I would then answer those. With every patient that called in and asked about our clinic, I would have to deliver information to the best of my ability through the phone and make sure all their questions were answered. 

Kendra

• Finally, something interesting I noticed about this chapter is when the author says a technical document must have clarity or it can “be dangerous”. This reminds me that laws can be written vaguely and allow for loopholes/vast interpretations. One example that comes to mind is how the 2nd amendment right to “bear arms” was clear at the time written, but has now been up for interpretation and debate. My question is, what do we do about similar instances where the technical document made sense at the time but now doesn’t? Are there any more examples of this?

Haochen

• How can technical communicators balance the need for clarity with the inherent ambiguity of language and technology, especially in high-stakes fields like healthcare or engineering? Should ambiguity always be minimized, or it can sometimes enhance user engagement and problem-solving?