Capstone Project Progress

So far I have been unable to secure an interview with a film critic working in the field today, but am still trying. I have sent out emails to many different organizations and film reviewers and am still awaiting a response. I am working my way through the second book which I selected to reference for my presentation, and have learned several very important things already. The first being that the -5 to 5 scale that I have been utilizing up to this point is really not that effective, and I believe that using a simpler yes/no approach to reviews would work much better. The other major thing which I have discovered is that while there are many different approaches to criticism, honesty is the most important quality which you can develop and display. People who read criticism often only read the review to find out whether they should see it or not, and frequently don't read past the rating as they aren't interested in any kind of deconstruction or analysis. In this way, film criticism must deal with the same hurdles and difficulty as newspapers:  people will only read into an article if their attention is grabbed quick and early.

Reading #10: Chapter 12

Chapter 12 deals with evaluating the usability of artifacts, or more appropriately, usability testing. I found it interesting that this chapter comes before chapter 13 which deals with developing a document or artifact that would then go on to be tested, but oh well. I also think that the book overuses the word heuristic to the extreme. I had never heard that word used until I picked up this book, and I wouldn't be surprised if actual technical communicators never use it either. This raised another important question, which relates back to the descriptive/prescriptive approach:  this book is full academic writing, and for the most part prescriptive in it's examples. So what happens in the real job sites, meeting rooms and other associated places with technical writers who are actually writing in the fields? You can study this book's recommendations to death, but if the people working in the real world speak a different language, how does that help? At the end of the day, any exposure to the inner workings of companies is beneficial I suppose. The chapter mentions that the effectiveness of a document depends on how well it connects with its audience, and I think that this is an important notion. Everything in tech writing depends entirely on the audience, as we have covered before. Three types of testing are mentioned:  cognitive walkthroughs, in which a specialist performs predetermined tasks using the document and gathers data on how well the tasks can be performed, expert reviews, in which experts review the document, and heuristic evaluations, in which rankings are assigned to how well the document meets various criteria. I found it interesting that if the document is incomplete in anyway, testing will be unable to discover all the issues that might arise with full testing. Two different types of testing were discussed, dealing with tests that are conducted in the early stages of document development, formative, and testing taking place at the end of development, summative.

Reading #9: Chapter 13

Chapter 13 is entitled Managing Projects, and deals with the step by step process of how projects can be taken from the conceptual stages, through to a fully realized physical product. I found it interesting that the chapter discussed the difference between the prescriptive vs. descriptive approach to the entire process:  is it better to do have an outline, or prescribed way of working that should followed, of a detailed descriptive walkthrough?  The chapter discusses the waterfall method as being the main asses that technical communicators have at their disposal for planning and management, but does mention several others including:  iterative, or user centered design, extreme programming, in which pairs work closely together and test, test and retest until problems are solved, and agile, in which small teams focus on small parts of large products and chew their way through one piece at a time. The steps involved in the waterfall method are as follows:  planning, in which 30% of the total time spent on the project is recommended to be spent, research/info gathering, in which info should be sought actively rather than passively by technical communicators, composition/invention, in which documents are drafted, reviewing/testing against quality criteria, revision, production, and dissemination. I thought the chapter did a good job of balancing the heuristic heavy approach that the book is infamous for by this point with alternatives and other important information pertinent to the discussion. The alternative methods to the waterfall method were interesting to read about, and I can see how each approach would be best suited to a different situation.

Reading #8: Chapter 16

Chapter 16 deals entirely and unrepentantly with the concept of visual design, and the different approaches and methods that are available to the enterprising technical communicator whereby they might be successful. From the text "A fundamental goal for information design is to enable and enhance relationships among stakeholders for an artifact...The field of information design focuses on devising novel ways to enable relationships among people through the effective design of content." Appearance is front and center in this chapter, as we are informed multiple times of the manner in which human beings read things, from the first glance and impression to the way we process information in a chunked/non-chunked presentation. There are three main concepts proposed in the chapter:  1) rhetorical grouping of information; 2) contrasting ideas; 3) signaling structural relationships.  One of the phrases that was used in the chapter that I found most helpful in understanding, and that in fact made me think of visual organization in a different way was, "strategic content grouping - making implicit structures explicit." This makes total sense. At last! A clear, concise description of all the rigmarole involved. What we all should aspire to when we design visual documents is to make the implicit explicit. The chapter talks us through the use of seriff vs. sans seriff fonts, double signaling, and the way the human mind works with the x height of different fonts, which was honestly quite interesting to read about. The remainder of the chapter gives a heuristic for leaning how to work this into your own life. I had almost managed to wipe the dreaded heuristic from my memory, but here it has crept back into my life. I think that these are bloated, counter-intuitive and unnecessary. Something that I found frustrating was a passage that said "for examples of this, see X and Y, where they of course named two scholars. Why not put the information into the body of the text? They didn't even refer to what the referenced material really had to do with the broader discussion! They simply said, see this to understand this. I took a few things away from the chapter, but overall I think that visual design is quite straight forward and the book didn't really do anything to build anything more than a basic understanding.