Funny play on the Beatles' "Paperback Writer" by a Canadian tech writer.
And the original: Beatles promotional video -- very leading edge.
Sunday, November 9, 2008
Monday, August 4, 2008
Lurking in the blogosphere
Blogging is not natural to me. For someone who shreds papers before throwing them out, rarely provides an address more specific than my city, and enjoys "lurking" in discussion groups unless I have something that I consider really relevant to contribute, posting my thoughts in blog form is contrary to my nature and, frankly, somewhat unnerving. Nonetheless, recognizing that it probably does add to my "critical awareness" (and as directed by my digital research professor), here I am: a participating member of the blogosphere. One of our blog prompts was the question of how comfortable I would be if someone studied one of my digital communities. My first thought was: "That's already happening in this blog." Of course, the question is really deeper than that.
What if, without my prior knowledge, a researcher was studying my contributions to an online forum? What if I was in, for example, a cancer survivors forum and a contributor who I believed to be a fellow survivor was actually a researcher who used and published the material gathered? Honestly, it is so difficult for me to relate to that situation because I simply cannot see myself blogging or posting about anything that I would not want to share in the first place. So I questioned myself regarding my loved ones: What if my dear cousin, who is indeed a breast cancer survivor, posted her thoughts during her ordeal to an electronic forum and a researcher used that information without her prior knowledge? Perhaps I should think that would be wrong -- but really, it seems that no matter from what angle I view it, I cannot see electronic posts in a public or semi-public forum as privileged or private in any manner. Even when masked with an alias and a password, it is relatively easy to identify an e-author in blogs and discussion groups.
For the most part, I take an approach of "Don't say anything you wouldn't say to your mother." Now granted, my mother was something of a character, so that philosophy gives me a great deal of latitude. Nonetheless, the point is that if I post my thoughts, or feelings, or whatever in a forum that other people can access, then I should be prepared for other people to read them, quote them (and misquote them), and use them in whatever other way they want. Electronic forum equates to "open forum" in my mind.
What if, without my prior knowledge, a researcher was studying my contributions to an online forum? What if I was in, for example, a cancer survivors forum and a contributor who I believed to be a fellow survivor was actually a researcher who used and published the material gathered? Honestly, it is so difficult for me to relate to that situation because I simply cannot see myself blogging or posting about anything that I would not want to share in the first place. So I questioned myself regarding my loved ones: What if my dear cousin, who is indeed a breast cancer survivor, posted her thoughts during her ordeal to an electronic forum and a researcher used that information without her prior knowledge? Perhaps I should think that would be wrong -- but really, it seems that no matter from what angle I view it, I cannot see electronic posts in a public or semi-public forum as privileged or private in any manner. Even when masked with an alias and a password, it is relatively easy to identify an e-author in blogs and discussion groups.
For the most part, I take an approach of "Don't say anything you wouldn't say to your mother." Now granted, my mother was something of a character, so that philosophy gives me a great deal of latitude. Nonetheless, the point is that if I post my thoughts, or feelings, or whatever in a forum that other people can access, then I should be prepared for other people to read them, quote them (and misquote them), and use them in whatever other way they want. Electronic forum equates to "open forum" in my mind.
Monday, June 16, 2008
Just write
There are just about as many approaches to writing as there are writers. Some technical writers start with an outline, some start with engineering specifications or market requirements. Unless it is a completely new product or process or whatever, most technical writers start with the existing (or similar) documentation. Some writers take a sort of 'stream of consciousness' approach. With all of these approaches, the author has at least a general thesis in mind: we know what we want to write about. I am particularly fond of this last approach for technical writing.
Starting writing is almost always difficult. Gene Fowler, a 1950's era screenwriter, is attributed as saying, "Writing is easy. All you do is stare at a blank sheet of paper until drops of blood form on your forehead." Overcoming the initial inertia of a "blank sheet of paper" can be almost overwhelming. As the director of a technical writing team, I was fond of telling my staff to "just write." Don't get caught up in style, or organization, or what you don't know. Just write what you do know. "Just writing" (with the appropriate end in mind, of course) allows for a focus on the text itself -- the rhetoric of the message. And as a great bonus, it leads to getting a lot of writing done. At the end of the day, the paper is not blank.
Knowing when something is "finished" has its own set of problems, There is always something else that can be written, or edited, or otherwise mucked around with. Using the parieto rule, 80% of the writing probably takes 20% of the time; the last 20% takes 80% of the time. Much of that is because we change and reorganize and edit and format and do a number of things at the end that don't have a lot to do with content. "Just writing" also helps prevent too much mucking. If you are focusing on the writing, you are not focusing on editing or formatting or rearranging. When you have nothing new to say, you stop -- and move on to the next topic to "just write" about that. It actually works.
At my company, we have been interviewing senior managers for the technical communication and training departments. A major topic of discusion is our corporate initiative to move to a structured authoring paradigm for creating "architected" knowledge bases using XML and DITA. XML is the extensible markup language. DITA is the Darwin information typing architecture. Both are technologies that facilitate creating documentation in a topic-based architecture, which makes it easier to reuse content. Because the new manager will manage in this new paradigm, it is important that we discuss it as part of the interview process. To date, each candidate who has already worked in a structured authoring environment stated that the technical communication team initially resisted it. From initial resistance, technical communicators either embraced it once implemented or left for environments more appropriate for their interests (often completely out of technical communication). I hear similar stories from my colleagues at other companies: initial resistance, then either a complete turnaround or total exodus.
Now the reason my little writing trick is of particular interest to me here is that it seems to be a good way to approach writing in the structured authoring paradigm. Research that I began for my master's thesis surfaced some initial data that supports this. However, my sample size was small and it was admittedly slanted toward adopters of structured authoring, so it really provides more of a possible direction for research rather than answers to the questions that I initially sought. One unanswered paradox continues to intrigues me: Why do some technical communicators seem to thrive writing in "topics," focusing almost exclusively on the text rather than format or style? And why do some thoroughly resist it? Before we had "word processors" and everything was typeset, technical writers had little to do with the way something would appear in a final document. The same is true when writing for publication even today; each publication has its own rules about style and format, which leads the author to emphasize the content without relying on format as a rhetorical vehicle for the message. So "just writing" is not specifically a question of the digital age, but it has come to the forefront as technical writing more and more becomes structured authoring.
Starting writing is almost always difficult. Gene Fowler, a 1950's era screenwriter, is attributed as saying, "Writing is easy. All you do is stare at a blank sheet of paper until drops of blood form on your forehead." Overcoming the initial inertia of a "blank sheet of paper" can be almost overwhelming. As the director of a technical writing team, I was fond of telling my staff to "just write." Don't get caught up in style, or organization, or what you don't know. Just write what you do know. "Just writing" (with the appropriate end in mind, of course) allows for a focus on the text itself -- the rhetoric of the message. And as a great bonus, it leads to getting a lot of writing done. At the end of the day, the paper is not blank.
Knowing when something is "finished" has its own set of problems, There is always something else that can be written, or edited, or otherwise mucked around with. Using the parieto rule, 80% of the writing probably takes 20% of the time; the last 20% takes 80% of the time. Much of that is because we change and reorganize and edit and format and do a number of things at the end that don't have a lot to do with content. "Just writing" also helps prevent too much mucking. If you are focusing on the writing, you are not focusing on editing or formatting or rearranging. When you have nothing new to say, you stop -- and move on to the next topic to "just write" about that. It actually works.
At my company, we have been interviewing senior managers for the technical communication and training departments. A major topic of discusion is our corporate initiative to move to a structured authoring paradigm for creating "architected" knowledge bases using XML and DITA. XML is the extensible markup language. DITA is the Darwin information typing architecture. Both are technologies that facilitate creating documentation in a topic-based architecture, which makes it easier to reuse content. Because the new manager will manage in this new paradigm, it is important that we discuss it as part of the interview process. To date, each candidate who has already worked in a structured authoring environment stated that the technical communication team initially resisted it. From initial resistance, technical communicators either embraced it once implemented or left for environments more appropriate for their interests (often completely out of technical communication). I hear similar stories from my colleagues at other companies: initial resistance, then either a complete turnaround or total exodus.
Now the reason my little writing trick is of particular interest to me here is that it seems to be a good way to approach writing in the structured authoring paradigm. Research that I began for my master's thesis surfaced some initial data that supports this. However, my sample size was small and it was admittedly slanted toward adopters of structured authoring, so it really provides more of a possible direction for research rather than answers to the questions that I initially sought. One unanswered paradox continues to intrigues me: Why do some technical communicators seem to thrive writing in "topics," focusing almost exclusively on the text rather than format or style? And why do some thoroughly resist it? Before we had "word processors" and everything was typeset, technical writers had little to do with the way something would appear in a final document. The same is true when writing for publication even today; each publication has its own rules about style and format, which leads the author to emphasize the content without relying on format as a rhetorical vehicle for the message. So "just writing" is not specifically a question of the digital age, but it has come to the forefront as technical writing more and more becomes structured authoring.
Wednesday, June 11, 2008
Ruminations about offshoring
Discussions about outsourcing technical communication come up frequently in Society for Technical Communication events. Everyone "knows" someone who has lost a job due to outsourcing or has worked with an outsourcer or has provided outsourcing services. Where technical communicators stand on the topic generally has much to do with their own personal experience of outsourcing.
Outsourcing is not a new phenomenon. "Contractor" used to imply something less than "employee." A fellow contractor once referred to a group of us -- most ungraciously -- as "high tech prostitutes," the implication being that a contractor would do anything for money. I was offended by the remark. I would have characterized it differently: contractors tend to be willing to do what it takes to get the job and to get the job done.
As a natural progression of globalization, outsourcing has moved to offshoring (outsourcing that moves certain functions to another country). 'High tech' has outsourced and offshored functions like translation and quality process auditing to Canada and Ireland for decades. Perhaps because these functions were new (quality systems) or required expertise not available en masse (translations) in the United States, the popular reception of this type of offshoring generally was not particularly negative. Now, with more mainstream and traditional functions being offshored, offshoring is again getting media attention. Outsourcing, it seems, has gone mainstream.
Information technology support, call center support, software development, technical communication, and popular media reporting that previously was performed domestically is being offshored to skilled workers in India, Eastern Europe, China, and elsewhere. The company where I work is an international telecom developer that has grown largely through acquisition, with two of the divisions acquired in two different countries. Further, we use an outsourcing consultancy that often uses the more recent outsourcing method of "onshoring" (using workers in rural and other lower-paying areas).
Because it is on the minds and lips of my fellow technical communicators and my coworkers, outsourcing, offshoring, and onshoring picque my interest. I am particularly interested in different perceptions of these phenomena and intend to review how popular media as well as certain trade articles talk about them. If I can obtain IRB approval in time for this initial microstudy, I will also review discussion list posts on the topic from STC and techcomm lists that originate both domestically and abroad. To get at the meaning of the text, I will do text analysis of the metaphors and other rhetorical language that is used, analyzing the sources and the results to determine what patterns emerge. Although I have some notions of what I will find in this research, the rapid and widespread expansion of outsourcing in its many forms as well as the explosion of international collaborative teams may be changing how these phenomena are perceived.
Outsourcing is not a new phenomenon. "Contractor" used to imply something less than "employee." A fellow contractor once referred to a group of us -- most ungraciously -- as "high tech prostitutes," the implication being that a contractor would do anything for money. I was offended by the remark. I would have characterized it differently: contractors tend to be willing to do what it takes to get the job and to get the job done.
As a natural progression of globalization, outsourcing has moved to offshoring (outsourcing that moves certain functions to another country). 'High tech' has outsourced and offshored functions like translation and quality process auditing to Canada and Ireland for decades. Perhaps because these functions were new (quality systems) or required expertise not available en masse (translations) in the United States, the popular reception of this type of offshoring generally was not particularly negative. Now, with more mainstream and traditional functions being offshored, offshoring is again getting media attention. Outsourcing, it seems, has gone mainstream.
Information technology support, call center support, software development, technical communication, and popular media reporting that previously was performed domestically is being offshored to skilled workers in India, Eastern Europe, China, and elsewhere. The company where I work is an international telecom developer that has grown largely through acquisition, with two of the divisions acquired in two different countries. Further, we use an outsourcing consultancy that often uses the more recent outsourcing method of "onshoring" (using workers in rural and other lower-paying areas).
Because it is on the minds and lips of my fellow technical communicators and my coworkers, outsourcing, offshoring, and onshoring picque my interest. I am particularly interested in different perceptions of these phenomena and intend to review how popular media as well as certain trade articles talk about them. If I can obtain IRB approval in time for this initial microstudy, I will also review discussion list posts on the topic from STC and techcomm lists that originate both domestically and abroad. To get at the meaning of the text, I will do text analysis of the metaphors and other rhetorical language that is used, analyzing the sources and the results to determine what patterns emerge. Although I have some notions of what I will find in this research, the rapid and widespread expansion of outsourcing in its many forms as well as the explosion of international collaborative teams may be changing how these phenomena are perceived.
Subscribe to:
Posts (Atom)
