From early 1993 through July of 1994, three STC chapters jointly managed a research project on Technical Communication in Western Canada. Based in Winnipeg, Calgary and Vancouver, the managers were thousands of miles apart, relative strangers and simultaneously engaged in running their own businesses. In this volunteer assignment, they involved committees within their own chapters. As team building and collaborative arrangements become more prevalent in technical communications projects, it can be instructive to look at how such a farflung research project fared. We will relate this experience briefly to some research results reported in Technical Communication.
While producing a new deliverable to improve the out-of-the-box experience for a major software product, the team of writers, graphic designers, human factors engineers, and marketers responsible for the deliverable faced many challenges and overcame many obstacles. Anyone involved in the production of such a deliverable will learn from a discussion of the problems we faced and the approaches we took to solving them. This discussion will be particularly relevant for anyone creating such a deliverable for the first time.
Professionals use contextual collaboration most frequently. It includes two forms: genre use and document borrowing. Professionals use hierarchical collaboration in moderation. It includes two forms: author-centered and sequential. Professionals use group collaboration the least of all.
Technical writers sometimes find it difficult to explain what they do in a few words. Maybe it’s not so bad when you’re talking to your uncle, but if you’re unable to explain this to your project manager, it can be awkward.
Today's electronic and paper-based approaches to the sharing of project information do not scale to the information sharing and interaction challenges of multi-disciplinary project team meetings. The inability to share and interact with information easily and effectively is one of the biggest bottlenecks in using electronic (online) information for collaborative decision-making. Through scenarios from recent construction projects, this paper summarizes existing approaches to the sharing of information and assesses their effectiveness in supporting multi-disciplinary decision-making by project teams. It then discusses recent research into interactive information workspaces where, with minimal software overhead, participants can share information that is relevant to a particular context to establish a common focus. We believe that the construction community can make significant progress quickly in leveraging existing and future investments in information infrastructure if it not only pursues information sharing through the use of product models but also formalizes the focused sharing of information and separates information interaction and view control from software services and underlying data as outlined in this paper.
In recent months, as part of my doctoral research, I have been interviewing technical communicators, users and developers of information systems to try and find out if in fact the work of a technical communicator is of value to those developing and using information systems. The interviews demonstrated clearly that technical communicators do add value. This was further confirmed in Paris where I discussed my work with technical communicators at the Comtec '97 conference. The following discussion encapsulates some of the comments from participants at Comtec '97 and the interviews I conducted.
When you get fed up and do decide to blaze your own trail, don't forget to take some friends along with you. You never know when you're going to run into a wild past participle that you need help taming.
Improving technical reviews, when subject matter experts, or SMEs, review content for technical accuracy, is a challenge every technical communicator faces sometime during their career. Every year, journal articles are published, presentations are made, and discussions are initiated on this very topic. Most of them conclude that SMEs are difficult. It's your job to bribe, cajole, or coerce a better review out of your SME. I don't agree.
To succeed in the corporate world, then, technical types have to learn to live with -- even serve -- nontechies. This article gives tips to help you get along with -- and maybe even learn to like -- people, whether the same as us or different.
This article explores the implications of choosing to work as a cog in the field of technical communication. The author includes perspectives from cog-colleagues and manager/cogs, and touches on concepts of ownership, recognition, and egoless communication. She recommends exercises in discipline-specific poetry and editing in a workshop setting as practical ways to work toward detachment.
I’m amazed when I hear people say they learn nothing from others in the technical communication field. Some people have a lot of experience, so they feel there are few opportunities to learn from others. I believe they forget that often through discussions, we discover a new perspective or a new way to solve an old problem. Different approaches can also lead to new techniques and solutions.
Subject matter experts, under the influence of modernist notions of authorship, often view technical writers as mere grammar and punctuation specialists and marginalize them as their ignorant 'other.' Technical writers, on the other hand, as rhetoricians occupying a liminal space between different disciplines, can understand different disciplinary rhetorics. If subject matter experts, instead of marginalizing technical writers, would view them as liminal subjects who are knowledgeable in different disciplinary rhetorics, then technical writers, through liminal practice, may be able to use their knowledge of audience and rhetoric to improve the quality of documentation.
A 20 minute monologue about the best way to get information from SMEs--sit by them, permanently if possible. Many IT organizations station the writer remotely from the developers, programmers, and other SMEs, but nothing could be more damaging to getting the information you need. Increasing your proximity also increases the communication you receive.
The development of a modern software product is a complex process involving a variety of disciplines, including that of the technical writer. It is essential that the writers establish close relationships with all other groups in the process and that they build effective and efficient systems of communication between them. The job of the writing manager is to ensure that the writing team obtains the information it needs in a timely manner and that the group interacts effectively with other groups in the process. This can be achieved by a blend of intergroup communication, background research, documentation and schedule planning and a well organized documentation review process.
Although many would not believe such to be true, there is a vast amount of communication that must be done in the IT world. This is even truer when the IT organization is involved with a regulated industry (e.g., pharmaceutical). In general, procedures and practices that went into the development, installation, and use/maintenance of a system require documentation and the communication of outages to the user community are also important. Among the more specific areas are help documentation, user instructions, code comments, installation instructions, and maintenance procedures/schedules. When a problem arises, it is often necessary for the IT professional to explain exactly what happened and provide the resolution in a coherent, layman-termed method, whether it be verbal or written (or both). Unfortunately, not all IT professionals are capable of doing this.
You don't have to spend hours making cold calls or squander money on invisible advertisements in order to find new clients. In fact, savvy businesspeople--technical writers included--know the best way to expand your client base is by leveraging the resources you already have. You might ask, "What resources?" Well, pull out your personal address book. This database of contacts--friends, relatives, and co-workers--is a gold mine when prospecting for business. By knowing how and who to ask, you can soon have as much business as you can handle!
NetWorks is an association of people involved in public relations, technical/computer documentation, marketing, fund raising, planning and development, training, journalism, editing, video production and publishing. We have a common interest in sharing ideas, information and resources.
Pedagogical and scholarly representations of collaborative writing and knowledge construction in technical communication have traditionally recognized consensus as the logical outcome of collaborative work, even as scholars and teachers have acknowledged the value of conflict and "dissensus" in the process of collaborative knowledge building. However, the conflict-laden work product of a Denver task force charged with recommending changes to the city police department's use-of-force policy and proposing a process for police oversight retains the collaborative group's dissensus and in doing so, illustrates an alternative method of collaborative reporting that challenges convention. Such an approach demonstrates a dissensus-based method of reporting that has the potential to open new rhetorical spaces for collaborative stakeholders by gainfully extending collaborative conversations and creating new opportunities for ethos development, thus offering scholars, teachers, and practitioners a way of reimagining the trajectory and outcome of collaborative work.
Technical communication programs should help students prepare to work with technical staff as well as develop writing, analysis, and communication skills. This presentation identifies assignments faculty can use to help students prepare to work effectively with technical staff: learning about what the writing technical staff do; learning about working in technical settings; interviewing faculty and staff; writing about science and technology for different audiences; editing a research article manuscript; learning about data networking; shadowing a technical professional; publishing a newsletter incorporating graduates’ observations and suggestions; having technical staff as well as technical communicators as guest speakers; and participating in STC.
I walked into my first meeting in Northeast Ohio and didn't know anyone. I no sooner stuck my name badge to my shirt and someone was there to introduce themselves to me. From there, the person took me around the room and introduced me to others. I left that night feeling as though I had met 20 new professionals in my field. I couldn't wait to go to the next meeting. This fall, many of you and your chapter leaders will be running formal membership drives. You will be looking for new members and trying to identify ways to retain your current membership. You don't have to be the Membership Drive Chairperson or on the committee to help. Here are a few suggestions.
If you area technical writer who writes software documentation, chances are you have been informally involved in testing the software that you are documenting. In larger organizations, entire divisions are devoted to thoroughly testing software before it is released. In smaller organizations, this position could be informal or nonexistent. In this workshop, you will learn a basic methodology for testing software that you can use as a starting point for a new or expanded career.
Tech newbies, and often these are people from an older generation than us techies, are easily overwhelmed by technology. Why do we expect them to get it? It's not their business to get it, it's our business to get it and then translate it to them. Do we think we are impressing them with all our knowledge? Chances are we are intimidating them. We need to stop, slow down and listen, ask questions, understand where they are coming from and then meet them where they are at. It isn't condescending or patronizing to slow things down and start with the basics.
The author argues that users see texts as tools when they recognize the texts' specific value and function within highly localized use settings. The author argues that users "ground" their texts to local use settings by altering the ways in which the texts structure and represent information (e.g., underlining, annotation, and sketching). The author discusses three practices by which texts are grounded as tools in document reviews: mode shifting, layering, and marking. These practices reflect different ways by which users add, subtract, and restructure information in a text so that it is usable under very specific conditions. This article explores document review as a practice in which grounding is the object of discussion (how others use the reviewed documents) and a practice by which review is facilitated. These observations will be important for exploration of technology to support "grounding" practices.