- Sep 2016
-
courses.christopherylam.com courses.christopherylam.com
-
Too many writers seem eager to craft"perfect" prose with the writing aspects overriding thecommunication issues inherent in the specific audienceand task.
I find this passage interesting since it seems to to imply that some writers put themselves ahead of their audience. I would think that technical writing is at it's best when it's useful to the end user, not the one who crafted it. This brings me back to a central theme in the article which is that the role of technical communicators is changing. Writers can no longer crank out a manual and call it a day. The work is a living breathing thing. This type of communication is designed for multiple audiences and with advances in technology, usability testing is now a crucial part of this as well. The work is never quite done. The user needs to always be front and center in the minds of the technical writer when working on any project.
-
emem-ber, the user cares nothing about how the manual is automat-ically generated through nifty scripts that assemble XML frag-ments and create a FrameMaker file for final editing. The usercares only that the correct information is provided in thecorrect format at the point when it's needed.
While explaining the effects of technology on the field of technical communication Albers details how the need to write for multiple audiences should not be lost as the field is attacked with more and more software.
He is correct, the end user could care less how the information is made, all they want to do is be able to use it as efficiently as possible when it is done. So even though we are changing how we make certain deliverables, the audience is still just as important. The product is a failure if the audience it is intended for doesn't want to or can't use it. Like we discussed in class, the more audiences we can appeal to the more effective our writing will be.
-
A possible alternative, he says, is for techni-cal communicators to become the problem solvers anddesigners who will create the content management sys-tems and document databases
This quote by Gregory Williams adds an interesting angle to how the roles are changing. One of the labels for technical writers that I've seen tossed around is that of Information Architect. Williams points out in the above quote that technical communicators need to transform into the problem solvers and designers that create the actual CMS's and databases that even Pullman and Gu discuss in "Rationalizing and Rhetoricizing Content Management". Even in "Records as Genre" by Catherine Schryer, the need for more effective problem solving skills in graduating students is behind the adoption of the POVMR system of record keeping. The ability to be apart of the problem solving process to me will ensure more active participation in future work. We as communicators are here to solve problems and the more ways we find to solve them, the better.
Technical communicators need to have a hand in the creation of these systems or be relegated to lesser roles as Williams suggests. We as the writers have an opportunity to shape our own destinies if we choose to.
-
Without the ability to coherently participate in theconversation occurring around the cross-functional andinterdisciplinary team table, technical communicators riskeither being left off the team because they not assets orbeing relegated to the clerical position of taking notes andcleaning up the team's reports.
I found this passage to be interesting because like much of the article, this passage illustrates how technical communicators need to be more than just writers. The need to learn and even understand the language of technology is more important than ever.
This also hit home for me as I too am learning the language of technology. My wife will be the first tell you that I don't "do" computers very well. I'll admit during our lecture and lesson about basic html in regards to our Wordpress sites, I ran into a bit of a language barrier. So in reading this passage afterwards it all made total sense.
As noted in “A Pedagogy of Multiliteracies: Designed Social Futures” by the New London group, they go on to state that, “With new worklife comes a new language. A good deal of this change is the result of new technologies, such as the iconographic, text and screen based modes of interacting with automated machinery; “user-friendly” interfaces operate with more subtle levels of cultural embeddedness than interfaces based on abstract commands.”
After re-reading this passage what Albers is stating above fits right in. We the communicators have to stay current with the language of technical communication which means that we must stay current with technology. If a technical communicator is unfamiliar with the technology used by the teams they work with, they will be left behind. A worse case scenario would be that a writer that does speak the language is hired to take their place.
This brings up a question as well. How are the different modes of communication changing? Do they change? Like genre, do they evolve?
-
he panelists at the conferenceagreed that that management and business knowledge are amajor missing piece in the typical technical communicator'stoolbox of soft skills.
A word that pops up this article as well the article by Pullman and Gu, "Rationalizing and Rhetoricizing Content Management", is content manager. Technical writers are not just writing the content but in today's job market they are also managing the content which means a closer relationship with new and different technology. Once the content is on the web, it does not go away and must be monitored and maintained.
The business side will always be looking a for new technology to find a way to streamline the business and make more money. This means that technical communicators will be apart of this process whether crafting communication for internal use or the users the technology may be intended to help.
-
he vendors whoprovide tools sell them with a hype-filled message of howtheir products will revolutionize the business and thenprovide training on only the basic operation of the tool.Issues of how the technology applies to the business andhow a tool relates to the other tools and technologies in thecompany are neglected. Or, to parody a textbook, themethods of integration are left for the writer to solve.
While most of this article is explaining how the roles of technical writers are changing, this passage explains how there will also be job security in the future. Like we discussed in class today, if our boss wants an app, we would be told to make the app happen. In this case, a business is buying software, but they are only concerning themselves with the surface level tech requirements. It falls upon the technical communicators to facilitate the integration of that software into the existing systems of that business, which includes integrating humans into the new system as well. After reading "Rationalizing and Rhetoricizing Content Management" by Pullman and Gu,sometimes these failures to foresee the integration doom the roll out of the new tech/software over all.
-
. And more thanjust understanding the individual technologies, we need toconsider how they interact and influence each other. Notechnology exists alone, no matter how much we try toisolate it
As Albers concludes the article he makes sure to add one more gem. Technology does not exist alone. Software is built on other software and even code is built on existing code. There is a source. None of these systems exist in a vacuum. While we may be expected to help with the roll out of a new software, we will also be on the front lines trying to figure out how the new software will integrate with the current software. Technology is influenced by other other technology. The more we familiarize our selves with technology the easier it will be for us to keep up.
-
Writing is only one element of pro-viding that information; to ignore the other elements is toensure both our long-term obsolescence and lack of powerand respect within the project team and corporation.
This quote explains why the title "technical writer" is morphing in to "content manager" and "information architect". Albers mentions that "writing is only one element of providing information". I think given our readings and discussion of mode this is true. Trying to convey complex ideas in just one mode is a recipe for failure. While we need to find ways of conveying information in as many modes as we can we also need to be aware of how new technologies can help us in this problem as well. While we can add different modes of communication, there could also be an app based software for example, that packages these modes in way that a 10 year old understands better than if we use a written manual.
-
Unfortu-nately, although there are six excellent articles in this issue, itis lacking one aspect I had wanted to cover. As Hackos pointsout in her commentary, most of the articles examine the "whatis" of the present rather than "what might be" in the future.
This passage for me, brings to light how the study of technical writing is lacking. While many in the academic world seem to focus on the state of technical writing right now, Albers wants to focus more on "what might be". I think by creating a discourse that is grounded in the future of technical communication we can all become more proactive as the industry continues to evolve.
When speaking about technology, the idea of "what might be" is a powerful one. New technology is created to solve a problem. That means technology can be created to solve existing problems, but also to solve problems that may not exist yet. By at least following the trends of where the next major developments in technology will come from, technical communication will always have a place in the modern business world.
The need to understand where the industry is going, not where it is currently is the most important aspect of this article.
-
It's very tough to drain the swamp when you spend allyour time battling alligators. Individuals need to strive to bemore integral, organizations such as STC and ACM SIGDOCneed to provide support for and push an agenda at a higherlevel than individuals can operate, and academic programsalso need to reexamine the core goals that technical com-munication graduates should possess (see the article byRainey, Turner, and Dayton in this issue).
This to me, is one of the central points of not only this article but "Rationalizing and Rhetoricizing Content Management" by Pullman and Gu. We as technical communicators have to take it upon ourselves to evolve with the industry. Nothing is lost through more education, except ignorance. Sitting and waiting for the someone to tell us what we need to know to stay relevant is not going to happen because someone else already knows and they just took your job. In the previous paragraph, my favorite part of the article is Alber's definition of post-mortem planning, "...wondering how the company could outsource documentation to an overseas company and lay off writers who had produced perfectly written, unread manuals". To me this so perfectly lays out what happens when communicators become reactionary in regard to technology and not proactive.
Of course changing how technical communication is taught will be helpful as well. Instead of client facing projects that simulate problem solving in the real world, we could be learning how to write a Nokia cell phone manual like Dr. Wharton mentioned today in class...
-
In the past, we have certainly seen a trend towardintegration of technologies into writing. For example,hefore desktop puhlishing, one would not have expectedwriters to know much about font or layout, as they werespecialists in text, grammar, style, rhetoric, information,or any one of a number of fundamental "on the page"skills. After widespread adoption of desktop publishing,which put the means of production into every writer'shands, writers' joh descriptions were likely to include arequirement that they know layout software, under-stand typefaces and white space, and participate in thephysical publication process in ways that were previ-ously unheard of. (Carter 2003, p- 31
Here Albers is quoting L. Carter from "The Implications Single Sourcing for Writers and Writing", who is explaining how technology has been integrated into the writing process of technical communicators. This is interesting since as I read his quote, I was able to recall my first time using MS Word in 1995 on my mother's laptop. To see how much has been added to the software since then is to see what a writer is now expected to understand. We are expected to already understand layouts and fonts as we transform into "information architects". The new requirements for technical writers will not be a mastery of MS Word, but of FrameMaker and other similar software. The more software changes and evolves the more we are expected to already be proficient in said software. As Albers mentions earlier, if we don't keep up we will find ourselves relegated to the sidelines.
-