Working with people from around the globe has become common practice for both authoring teams and technical documentation professionals. A recent survey conducted by SDL investigated the development of global authoring. The results were compared to surveys from 2007 and 2006. They reveal trends in working methods and shed light on the effects of globalization on global authoring.
Contrarianism inevitably leads to a conflict, but in a good way. Conflict is an essential ingredient to writing because where there is conflict, there is story. The more you wrestle with conflict, the better the story. And story is what makes our lives meaningful. It’s what makes life interesting, anyway, so naturally it’s the direction in which we gravitate.
Technical communication practices have been changed dramatically by the increasingly ubiquitous nature of digital technologies. Yet, while those who work in the profession have been living through this dramatic change, our academic discipline has been moving at a slower pace, at times appearing quite unsure about how to proceed. This article focuses on the following three areas of opportunity for change in our discipline in relation to digital technologies: access and expectations, scholarship and community building, and accountability and partnering.
Writing is a complex, cyclical task. The writing task requires more than formulating text to express ideas, it involves data gathering, managing constraints, formulating intentions, planning, and revising goals. Much of the complexity is due to the management of simultaneous activities and constraints. Management of these processes can lead to 'cognitive overload', which in turn can negatively affect the quality of the text produced. With technical writing, these same issues of task complexity are applicable.
I’ve been working on some collaborative authoring scenarios for our Agile teams – we’re going from 5 people to 47 people in total who could author external or internal documentation within our two week sprints. Turns out, we likely represent some trends in the enterprise.
Say you have a document that needs to be presented in two languages and you are the translator. While the translation is in progress, someone revises the original master document. This means you now might be working with an outdated paragraph or one no longer present in the master version. This article tries to map this problem to parallel development, which version control systems solve with the branch and merge model. You will also see how svk helps you maintain translated documents easily.
Collaborative walkthroughs are a technique that my team used while rewriting our Help and adopting DITA. We believe that we were able to improve the user experience by improving the collaborative experience.
Mention team technical reviews to a group of tech writers and chances are good that you will either get a loud, collective groan, or the group will vie to tell the best review horror story. On the one hand, technical reviews are a vital part of our jobs because they help us to produce high quality product documents. On the other hand, technical reviews gone wrong are the bane of our existence. The good news is that we have the power to conduct consistently effective technical reviews. This article summarizes why we do reviews and what often goes wrong in reviews, and then summarizes steps to take before, during, and after technical reviews that can help you conduct effective team technical reviews. Although your process and team may differ from what’s described here, you can apply the information in part or in whole to improve your current review process.
Some years ago, I used to suffer from developer neglect, or to use a more scientific term, from a kind of information exclusion complex. You know what I’m talking about. Developers make updates to the interface, often at the last minute, and don’t let the tech writer know what changed. As a result, the help is wrong and out of date. It’s a frustrating experience from the writer’s perspective.
Technical and professional writing pedagogies have traditionally understood collaborative writing as an aggregate, cooperative venture between writers and subject matter experts. In contrast, this tutorial argues that Web 2.0 technologies offer technical and professional communication pedagogies more advantageous conceptions and practices of collaborative writing. The tutorial analyzes how new media technologies create a different collaborative writing environment and then discusses how these environments help collaborative writing methods create an alternative writing situation. The study concludes by examining the outcomes of student Web 2.0 research projects and by offering technical and professional writing instructors new pedagogical strategies for teaching collaborative writing.
Previous research indicates that voice annotation helps reviewers to express the more complex and social aspects of a collaborative writing task. Little direct evidence exists, however, about the effect of voice annotations on the writers who must use such annotations. To test the effect, we desinged an interface intended to alleviate some of the problems associated with the voice modality and undertook a study with two goals: to compare the nature and quantity of voice and written comments, and to evaluate how writers responded to comments produced in each mode. Writers were paired with reviewers who made either written or spoken annotations from which the writers revised. The study provides direct evidence that the greater expressivity of the voice modality, which previous research suggested benefits reviewers, produces annotations that writers also find usable. Interactions of modality with the type of annotation suggest specific advantages of each mode for enhancing the processes of review and revision.
Technical communicators frequently collaborate in workplace projects and bring a host of different kinds of expertise to this collaboration. Yet the understanding of communicators’ expertise among managers and subject matter experts is grounded in a view of writing as a finished product and authorship as singular. This article documents many different kinds of 'contributory expertise' employed by writers collaborating to produce articles for publication. Expertise in research, textual composition, visual composition, as well as other kinds of expertise garnered on previous projects is often brought to collaborative projects. Often emerging and developing as a function of collaborative work is expertise in framing the project, conducting review processes, and assessing outcomes. These categories are discussed in some detail to provide practicing communicators with ideas for documenting expertise in their specific workplaces, to provide students with ideas for developing expertise in various areas, and to prov
Although writing centers have used computers for over a decade now, they have used them primarily in autotutorials (computer-assisted instruction) and word processing. These applications reflect the influence of the process movement in composition studies and the writing center's commitment to the individual writer. Yet as the field moves towards the social in its scholarship and its writing technologies, writing centers might look towards e-mail to seek out new forms of tutor-student collaboration. The essay describes an experiment with e-mail tutoring and explores implications of new working conditions for online tutors.
In an advanced technical and professional writing course, a pair of in-class exercises integrates the teaching of teamwork with other class topics of project management and observation-based research. The first exercise introduces teamwork in a positive way, by raising awareness of strategies for solving problems successfully. The second exercise follows up on the first, focusing on assessment of problem-solving teamwork. The pair of exercises is memorable and effective, showing students in an engaging, thought-provoking way that they have control and responsibility for the success of their teamwork. The materials for conducting the exercises, provided here, encourage reflection and discussion.
Want to know the secret to better quality documentation and improved software design? Will Kelly outlines how the key is an effective relationship between project managers and technical writers.
For those of us in the field of technical writing who didn't come at this from a computer science background (raise your hand if you’re an English major), we’re often introduced to unfamiliar technologies and terminology at the start of a project. It’s understandable then that we'd want to keep quiet and stay on the sidelines until we better understand what the developers are discussing. I’d like to suggest that doing so will lengthen the ramp-up time, and...
One common complaint a lot of technical writers have is that they aren’t included early enough in lifecycle of a project. The downsides are that by the time work hits your desk you don’t have a full picture of who the customer is, why they want whatever it is you are building, and how they want it provided to them. All of which directly impacts the information being created.
Using a qualitative approach to data collection and analysis, this article discusses some of the findings from a larger study on collaboration and the role of gender. Here, we profile three student engineering teams as they participate in processes leading to the submission of a report for a team-based technical communication course. While some theorists suggest that gender can play a significant role in achieving a successful team dynamic, our study only partially supports that claim. A synopsis of two women from two predominantly male teams reveals glimpses of what the literature describes as traditional gender-linked behaviors by both men and women, but the all-female team does not conform to stereotypical patterns and their behaviors call into question the existence of these interactional styles. We suggest that factors other than gender and independent of a team’s gender composition—such as team commitment and a strong work ethic—exert a greater impact on collaboration. Nevertheless, the study does caution against assigning women to predominantly male teams since, when a team’s social structure is mostly male, traditional gender-linked interactional behaviors as well as manifestations of the culture of engineering are more likely to emerge. Overall, the study underlines the importance of examining specific face-to-face interactions to see how behavior is situationally produced in order to more fully understand the interactional strategies open to individuals.
Larbi discusses the transition—including advantages—that many lone writers face as globalization becomes more prevalent and individual consultants transform into lone writer teams.
This article recommends strategies academics can use to contribute to an issue of great interest in industry: how best to define, measure, and achieve quality documentation. These strategies include contextualizing quality definitions, advocating the use of multiple quality measures, conducting research to identify specific heuristics for defining and measuring quality in particular workplace contexts, and partnering with industry to educate upper management about those heuristics and the benefits of promoting technical communicators to the strategic role of organizational “gatekeepers of quality.”
We tech writers can learn from our chunks of content: What makes a topic successful can also make us writers successful! I think there’s a lesson for tech writers here beyond team management: How successful you’ll be in your work as a tech writer depends on how well you define your job’s purpose and communicate it to others.
If you asked me what the most painful part of being a technical writer is, my answer would be: 'Getting reviews on time. Getting good feedback and inputs on your work.' For me technical writing has been very pleasurable because I hardly got any review comments. My morale has therefore been very high. Project managers, developers and others are so busy trying to come up with good software (read trying to fix all the goof-ups and bugs!) that they usually tend to give documentation lesser importance. User manuals, who reads them anyway? We do not have time for it!
In this video clip, Ecademy’s Thomas Power talks about how business leaders will have to switch between “institutional thinking” (closed, selective and controlling) and ”network thinking” (open, random and supportive). There’s a similar challenge for technical communicators - between traditional “closed” user documents and collaborative, conversational, “open” online user assistance.