An attempt to distill and disseminate key principles and practices relevant to managing scientific and technical information in environmental conflicts.
Just the thought of dealing with Subject Matter Experts (SMEs) can create stress in the life of any documentation manager. Some SMEs can be self consumed, preoccupied, distant, and even rude. But why do these behaviors exist? This article briefly describes how to interact with people who might be difficult to motivate and how to work with people who have priorities different from yours.
Part 2 switches the focus to members of your management team and what you can do to sell your team’s professionalism. Also included are hints on how your writers can individually sell themselves to gain cooperation from SMEs.
Remember that a successful project has a measurable and positive impact on the client's business objectives. Set a time period to measure the progress toward achieving those objectives, and plan to measure progress on a regular basis. If you find that there are adjustments that should be made, or additions that can improve the project's functionality, do them.
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.
I talk with Katherine (Kit) Brown, Brenda Huettner, and Char James-Tanny about their latest book, Managing Virtual Teams: Getting the Most from Wikis, Blogs, and Other Collaborative Tools.
While you’re always optimistic when leading a team, you know that not everyone’s got your back. Liars and poor communicators can wipe out good work faster than a 404 error. Learn how to think critically about verbal and non-verbal behavior and to separate office politics from truth, so you don’t let the Werewolves win.
Technical communication consultants may find that marketing writing makes an excellent second line of business. Technology companies, marketing services firms, and advertising agencies often use freelancers to write marketing documents. They particularly need good writers who understand technology. This paper discusses the business of freelance marketing writing and how it differs from independent technical writing. Topics include the kinds of projects that marketing writers work on, how development cycles typically differ from those of technical documents, and how to effectively market yourself as a marketing writer.
No matter what your current status—employee, looking for a job, or independent consultant—marketing yourself is necessary. Marketing is determining what your customers need and then showing how whatever you are selling meets those needs, i.e., provides benefits, and does it better than the competition. When you market yourself, you are basically doing the same thing. If you are an employee, how are you developing your skills so they continue to meet the changing needs of your employer? If you are looking for a job, how does what you bring to the table make you a better candidate than everyone else? If you are an independent, how do you benefit your clients so they turn to you over and over again?
A case study of a course in which students used collaborative online tools such as Google Docs for major writing assignments, and the results the instructor discovered.
Our tabletop research efforts at Stanford University have focused on how tabletop user interfaces (UIs) might respond to and even influence a user group's social dynamics.
Mercurial is a modern distributed version control system (VCS), written mostly in Python with bits and pieces in C for performance. In this chapter, I will discuss some of the decisions involved in designing Mercurial's algorithms and data structures. First, allow me to go into a short history of version control systems, to add necessary context.
Imagine getting back 3 different versions of what you originally wrote, then taking every paragraph and comparing it with those 3 new versions. The only way that I can characterize this is by being a painstakingly awful process. Sure, track changes help. At least I know which sentences were modified. The problem comes when you send your documents out to more than 1 collaborator. Then track changes are fairly useless; especially when each collaborator has its own “better” version of the same paragraph.
As XML becomes ubiquitous so the need for powerful tools to manipulate XML data becomes more pressing. Merging XML is particularly tricky, but often necessary to consolidate data feeds from heterogeneous systems, or to synchronize submissions of XML fragments which make up a larger document. An automated mechanism for defining and controlling such merges has been developed and is demonstrated to provide a consistent, adaptable and resilient solution to this problem. Integration into an information pipeline allows limitless customization.
Among the most influential intercultural communication theories is Ting-Toomey's face-negotiation theory. The theory has undergone a number of refinements over the past two decades and has emerged as one of the most cited theories in intercultural business communication research. The theory posits that face or "identity respect and other-identity consideration" is maintained and negotiated in communications and interactions of members of all cultures; however, it is perceived and enacted differently across cultures as a function of the cultural dimensions of individualism and power distance. Our study is a meta-analysis of all research that we could find that has been conducted about the cultural propositions related to conflict management styles in face-negotiation theory. Specifically, these propositions state that individualist cultures tend to use more dominating conflict management styles whereas collectivist cultures tend to use more integrating, compromising, avoiding, and obliging conflict management styles. We integrate findings across studies to answer the degree to which these theoretical propositions are answered by empirical research.
Technical communicators have lately become interested in participatory design as a way to structure and guide their research and development efforts, particularly in online media. But attempts to use participatory design - in technical communication and elsewhere - have been hampered because participatory design has typically been seen as an orientation or field rather than a methodology with its own methods, techniques, and acceptable range of research designs. In this article, I work with a range of participatory design sources to describe it as a methodology useful for technical communicators. After providing the historical and methodological grounding for understanding participatory design as a methodology, I describe its research designs, methods, criteria, and limitations. Finally, I provide guidance for applying it to technical communication research.
Track Changes in Microsoft Word is an indispensible tool for editing, but it is not the best tool for the job in every editorial situation. You may find that both tiny details and big-picture edits cause you-and your reviewers-to want less tracking, not more.
This report is a summary of a two year research project carried out by the IT byg group at BYG. DTU for the Danish government agencies Erhvervsfremmestyrelsen and By- og Bolig-ministeriet. The objectives were to collect data on the use of IT by the PPB housing consortia, a development project to test out various innovations, to map communications between the partners, and compare IT usage with their original proposals. Data was collected on communications in housing projects in the period June 1999- Aug 2000. The original PPB proposals were made in 1994/5 but there have been breaks in the flow of projects, and information technology has gone through much change since then. Use of Email has taken over from post and fax, and Project Webs have been developed in most consortia. Consortium members' policies have dominated the choice of management and logistics software, restricted compatibility in the consortia, and limited willingness to share data. Greater involvement by the client, and more sharing of equity, would have encouraged adoption of common IT systems and created more trust for data sharing between partners. PPB projects have allowed consortium members to test out new technologies but, in general, the IT systems used have been similar to those which the larger firms use elsewhere. Vertical integration has been limited by lack of experience and technology in smaller firms. In future, access to Project Webs from mobile devices should help use by all partners from any location. In all the projects studied, and in spite of the introduction of Email and Project Webs, the ratio of non-IT communications to IT varied from 0.8 to 4.6. When problems need to be solved rapidly there appears to be a tendency to revert to traditional means of communication - meetings, telephone and fax.
A quick overview of the Usability Professionals Association Board--what functions it performs, how it's structured, and who's currently performing what role.
The author discusses her transition from academic professor to corporate worker and back to academic professor. She compares and contrasts some fundamental differences between these environments on the dimensions of teaching, research, collaboration, problem solving, and ethics. She describes some of the lessons she learned as she moved back and forth across these environments. She concludes by suggesting that, however large these transitions seem, they are transitions we routinely expect our students to make when they migrate from school to work.
This paper challenges the popular notions of tacit and explicit organizational knowledge and argues that its philosophical underpinnings derived from Gilbert Ryle are problematic due to their logical behaviourist perspective. The paper articulates the philosophical problem as the neglect of any role for the mind in organizational activity and the representation of mental activity as purely a set of behaviours. An alternative realist philosophy is advanced taking into account the potential of adopting a number of competing philosophical perspectives. The paper forwards a realist theory of organizational knowledge that moves beyond the surface behaviours of tacit and explicit knowledge and argues that collective consciousness and organizational memory play primary and deeper roles as knowledge processes and structures. Consciousness is not a Hegelian world spirit but rather a real process embedded in people's brains and mental activity. Further, the paper argues that organizational routines provide the contingent condition or `spark' to activate organizational knowledge processes. The implications of this model are explored in relation to the measurement of intellectual capital. The theory developed in this paper represents the first attempt to provide a coherent philosophically grounded framework of organizational knowledge that moves organizational theory beyond neat conversion processes of tacit and explicit knowledge.