There were a few useful concepts covered in this chapter. Two of them that Gere found helpful are hierarchical mapping and the relationship tables. These are two concepts she’s applied in the past. In an example of her experience, she writes, “When I worked at a mid-western university, we decided that a website was the best means of communicating with our email customers. We would be able to provide them with a database of instructions and troubleshooting information so they could fix minor issues themselves. We also incorporated a training schedule, registration and feedback system into the website.”
Finally, we had a section that maintained server statistics and server updates. The process of creating the website entailed creating a hierarchical map and relationship tables. By planning everything on paper first, we knew exactly what information we needed, how it needed to flow and how to set up the menus. This simplified the process of actually creating the website. Our customers really appreciated the effort and took advantage of the website.
Gere’s example was helpful. From someone working outside of the field currently, the use of technical jargon in this book can be overwhelming. However, even to a technical novice like myself (Monique). there were a few concepts that stood out. For instance, the content plan is relatable to any industry and therefore was easy for me to understand. Concepts such as identifying final deliverables, developing an annotated list (or inventory, for all intents and purposes) and using information releases are essential to making any content plan work; regardless of industry.
Both of us agreed that a huge concern presented in the materials of the chapter was the over-reliance on the idea that technical communicators work in teams and have access to marketing people, and are involved with product development. While that certainly can happen, it’s only one facet of technical communications.
Another area of interest that related to Patrick’s experiences concerned the creation of content plans and their relation to instructing groups of tennis students. While Patrick doesn’t have any direct experience working in the implementation of topic architecture, he does have experience with teaching in a group setting. Specifically, he has experience with teaching tennis to groups of individuals; these clinics required a great deal of planning and organizing. His experience involved organizing an entire “clinic” where he was responsible for creating, essentially, a content plan that planned, produced, and delivered tennis instruction to large group groups as large as fifteen students. Patrick’s experience with creating content plans, in the context of a tennis “clinic,” was crucial to the successful participation of his participants.
Overall, the idea of constantly having to work in a team is a theme in this book. Coming from the non-profit world where resources are scarce, it’s understood that collaboration is necessary for success. However, in a corporate environment, with presumably much more resources, it seems as though constant collaboration might not be as essential to a project’s success. With such a rise in freelance and contract work, though, it might be reasonable for the emerging technical communicator to get familiar with group work.
DavisCollinsHirschEng577 