Untitled Page 13

Chapter 4. ePorts: Making the Passage from Academics to Workplace

Barbara J. D’Angelo

Arizona State University

Barry M. Maid

Arizona State University

The apparently “age old” discussion of whether to teach tools or rhetorical skills in technical communication courses seems to naturally come to a head when faced with the creation and assessment of capstone ePortfolios. This only makes sense when ePorts are viewed as the passageway from demonstrating proficiencies in meeting academic program outcomes while also meeting entry skill levels into the workplace. Technical Communication and other applied programs are constantly being pressured by different stakeholders, both internal and external, to teach specific software tools. One of the challenges Technical Communication program directors have faced is to make sure we include appropriate and assessable technology outcomes into our program outcomes; we need to sustain ourselves as an academic program and yet still meet workplace needs.

And we are here as on a darkling plain
Swept with confused alarms of struggle and flight,
Where ignorant armies clash by night.

—Matthew Arnold, “Dover Beach”

Though clearly out of context, perhaps this quotation from Matthew Arnold really does sum up the seemingly ever-present dissonance between academic and practicing technical communicators. Both groups are somewhat naïve as to the conditions and needs of the other. As a result, they often almost operate in the dark with regard to the other. As academics many of us believe that all we teach needs to be grounded in good theory that can then be implemented into best practices. We are concerned with “how” and “why” not with “what” and “how to.” On the other hand, practitioners seem to be (from an academic’s perspective) obsessed with how to get things done and what they need to know. They are champions of knowing specific tools and creating necessary “bodies of knowledge.”

Thus, those of us who teach in, design, and administer academic programs in technical communication are faced with a dilemma. How can we prepare our students with a solid academic background that is often seen as too theoretical and out-of-touch with the workplace while still making sure they have the skills to compete in what is often a very tight job market? For us, in the Technical Communication (TC) Program at Arizona State University (ASU), the answer lies in creating a set of program outcomes that can be accepted by both worlds. We then assess our graduating seniors for their proficiency in those outcomes by means of an electronic portfolio.

When we developed the program in Multimedia Writing and Technical Communication (now just Technical Communication) at ASU, we were primarily concerned with meeting academic-based outcomes. A set of outcomes appropriate for a technical communication program was built on the Writing Program Administrators’ (WPA) Outcomes Statement (OS). The original statement was revised so that technology outcomes were present. Those outcomes were then modified to include information outcomes as well. That story has been told elsewhere (see D’Angelo & Maid, 2004; Maid, 2004).

Although the original WPA Outcomes Group discussed incorporation of technology into the WPA OS, debate about the responsibility of first-year composition to teach technology outcomes or competencies resulted in the adoption of it without them. However, debate related to inclusion of technology outcomes continued and a new WPA group met at the 2005 WPA Conference in Alaska to begin discussion about how technology could be incorporated in the document (Yancey, 2005). In 2006, the group drafted a revision of the WPA OS to incorporate both technology and information literacy (IL); a revised draft was presented and adopted at the 2007 WPA Conference in Tempe, Arizona.

The revision incorporates outcomes for composing in electronic environments as a fifth category rather than as outcomes integrated into the original WPA document so that the existing categories, already accepted and adopted by both rhetoric and composition and other fields, not be disrupted. The outcomes included in the new section relate to the use of technology as tools to compose and for research as well as to rhetorical strategies related to both print and electronic texts. Thus, technology is incorporated both as tools and within rhetorical contexts while IL is embedded as the use of technology to access information.

It is important to understand this context for our integration and use of technology outcomes as a foundation for our approach. We integrated technology as a construct for programmatic learning and assessment prior to the development of the revised WPA OS section (see Albert and Luzzo, 1999, for more on perceived barriers in career development). Because our approach to integrating technology was holistic, integrating constructs where appropriate in each of the original OS’s four sections, rather than adding a separate section, our approach to assessment is also holistic so that students’ use and learning of technology is evaluated as part of a whole rather than as discrete skills. Specifically, the TC Program at ASU has the following outcomes that can be considered to be technology outcomes:

• Understand the role of a variety of technologies/media in accessing, retrieving, managing, and communicating information
• Use appropriate technologies to organize, present, and communicate information to address a range of audiences, purposes, and genres
• Use appropriate technologies to manage data and information collected or generated for future use
• Understand and apply legal and ethical uses of information and technology including copyright and intellectual property.

Like all the other program outcomes, we ask students to demonstrate proficiency with these outcomes in their senior capstone electronic portfolio. See Hakel & Smith, 2009; and Edwards & Burnham, 2009 for more information regarding institutional assessment and outcomes-based ePortfolio work. However, unlike the other outcomes, students will not be able to even complete an electronic portfolio unless they have a certain level of technical proficiency. Purposefully, we chose not to use any kind of canned portfolio software where students can easily dump content into a template. Rather, we expect our students to be capable of making choices about the best possible tools to present their portfolio. Once they’ve made the choice, we expect they will be proficient in that tool. We clearly resist the notion that it is the responsibility of an academic unit to train anyone in software proficiency. While those skills are useful, and often necessary, we feel it is not the kind of skill one gets academic credit for mastering.

On the other hand, we do feel it is important for students to understand what tools are capable of doing. That means, when given the option, they should be able to pick the most appropriate and most effective tool. For example, it is relatively easy to create a brochure using today’s word processing software. The question becomes, however, is that the best tool to create a brochure? The answer may not always be the same. We would hope our students would know the capabilities and the limitations of both word processing and desktop publishing software to make an informed choice.

Yet, despite our beliefs, the question of relevance of our outcomes to practitioners remains. Using comment from portfolios and a survey of practitioners helps us answer this question. In 2006, Scott Crooker, a student enrolled in the Master of Science of Technology program at ASU, asked how practitioners viewed our program outcomes. That ended up being the research question for his master’s thesis where he surveyed members of the Phoenix Chapter of the Society for Technical Communication about the program outcomes (Crooker, 2006). In the light of this research, we began to rethink how our academic technical communication program prepared students for real jobs by addressing how our outcomes were perceived by practitioners.

Tools or Theory

Those of us who have been teaching writing courses from technical communication to first-year composition have been faced with the “Do you teach the tools” question for decades. At its most basic level, this question is raised because the assumption is that students are not capable of using digital tools unless they are specifically trained to do so. This assumption is reinforced by the huge software training industry and exacerbated by organizations that refuse to give employees access to tools necessary for their jobs until they have undergone prescribed training. And, of course this perspective is reinforced by the numerous certification and assessment tools promoted by the software/technology industry, ranging from Microsoft certifications to more academically-based tools such as Educational Testing Services’ (ETS) iSkills test.

While we can certainly understand the desire to make sure people are well-trained, the reality is that if the same demands were placed on how people should be trained to write before they are allowed to do corporate writing, everyone would be trained in endless grammar, punctuation, and mechanics drills before being allowed to open a new word-processing document. It may be the only reason Human Resource types aren’t demanding that is because of their faulty assumption that English is fixed and never changes so they don’t realize that English version 1930 is different from English version 2009.

Though it’s easy to try to dismiss the tool-centric people, it is also expedient to try to understand them. We suspect they have a legitimate point of view, though one that doesn’t necessarily align with what most of us see as our primary mission as technical communication educators. In framing this issue we have chosen to do so as if we were consultants coming into an organization from the outside. In that scenario, one of our first questions would be, “What is your core mission?” Looking at academic programs, it seems that our mission is to prepare our students to have successful careers, writ large, throughout their entire lives. On the other hand, hiring managers prefer people who will have successful careers, writ small, within the particular constraints of an organization. Both points of view are reasonable, but often conflict.

Another way to understand these points of view is with a football analogy. Every spring as professional football teams prepare to draft college players, endless time and energy is spent on finding which player best fits the needs of a team. The assumption is usually that in the highly specialized world of professional football, filling specific needs is the best way to excel. The old Dallas Cowboys had a different philosophy. They simply wanted to draft the best player available—assuming that talented players would find ways to be productive and successful. In many ways, this is no different than when academics recruit faculty. In most instances departments look for faculty who can teach or research in highly defined specialties—instead of just looking for the most talented candidate available. That’s exactly what hiring managers in the industry are doing when they try to recruit technical communicators and require that candidates must know SuperSoftware, ver. 7.65.

The assumption, especially in tight job markets, is that the quicker a new hire can actually get to work, the more money the company will save. After all, hiring new people is expensive. In addition, in many workplace cultures, being perceived as having software skills tends to lend status. Software skills also appear to be more quantifiable (though this may be completely subjective and illusory) than the other kinds of skills technical communicators must necessarily possess. As a result, the kind of results “rePorted” by Clinton Lanier (2009) in a recent issue of Technical Communication should not be unexpected.

Lanier describes the results of an analysis of 1,399 technical writer job postings for the types of skills and experience required, resulting in the following categories: experience, technical knowledge (specific computer or markup languages, subject expertise, or foreign language), technical writing specific knowledge (formats and genres), technologies/tools, several software categories, and project management skills. Interestingly, he included rhetorical skills such as audience analysis within the broad category of technology/tool knowledge but broke out specific types of software knowledge as separate categories. Lanier found that employers require some type of subject matter experience 33% of the time. In addition, he found that 16% of ads required proficiency in online help software, 20% in specialized software tools, 24% in graphics software, and 34% in publishing software. In comparison only 17% required basic technical writing skills (in which Lanier categorizes audience analysis/writing for specific audiences). He believes his results challenge assumptions that teaching tools is unimportant. However, he places less emphasis on analyzing the project management category, which includes communication skills, collaboration, analysis, and others, despite the finding that 32% of postings call for interpersonal and collaborative skills. Lanier’s lack of emphasis on project management seems to be based on the belief that the communication category is vague and hard to define or plan within a curriculum (2009). Lanier’s findings, however, contradict earlier analysis of survey findings by Rainey, Turner, and Dayton (2005) in which they found that despite an emphasis on technology skills, managers were more concerned with employees’ ability to be able to adapt and learn new software quickly. Rainey acknowledges the tension between technical skills and other “soft” skills such as collaboration and people skills that pervades the field and the often contradictory evidence gained from industry; this tension clearly continues as evidenced by Lanier’s findings.

Indeed, the tension between academic and industry perspectives has been a constant theme within technical communication, with certification acting as another indicator. Turner and Rainey (2004) review the history of debate surrounding certification. While these authors advocated for a mechanism for certification to codify bodies of knowledge for technical communicators and to identify the ethical and professional responsibilities of technical communicators, certification still remains an object of debate which is constantly revisited in the literature and within professional and practitioner societies (Hart, 2008; Rosenberg, 2008). Clearly this debate and conversation impact on curriculum. There are a limited number of hours within a degree program, thereby constraining what can be taught. Some have attempted to address and frame technology skills by contextualizing them within the literacy debate. In this perspective, technical or tool literacy becomes one of several literacies advocated for in technical communication education (Breuch, 2002; Cargile Cook, 2002; Nagelhout, 1999). Lastly, this debate has importance because what is taught and how we teach is impacted by assessment and the methods we use to evaluate student learning. Certification, for example, is a type of assessment; yet, it is often correlated with quantifiable mechanical skills of tool use. For academic programs such as ours, assessment is more broad-based to incorporate a more holistic range of outcomes.

Bridging the Academic/Workplace Gap?

From the beginning, we used ePortfolios to assess whether our students are meeting program outcomes. Electronic portfolios are a common method of assessing student writing, including technical communication. Students enroll in a capstone course during their semester of graduation in which they review outcomes and the scoring guide which faculty use to evaluate portfolios and work together to draft, revise, and finalize portfolios. Students select and use examples of their work as evidence for claims made in a persuasive cover statement to demonstrate their learning and growth in the context of program outcomes.

As mentioned earlier, we do not mandate a specific application or technology for students to use to submit their portfolio. Since the portfolio itself is an artifact, we believe that the students’ choice of technology and application is a demonstration of their achievement of outcomes. Of the 32 portfolios submitted since fall 2006, 27 were websites and 5 were PowerPoint files. The same criteria and scoring were used to evaluate all portfolios regardless of the application used to submit them. Though we do not explicitly address issues related to technology with evaluators, we expect that they assess the portfolio based on its achievement of outcomes. Since the portfolio itself is an artifact, we expect rater scoring is influenced by how the portfolio is constructed and how the student uses the selected software to present their argument about achieving outcomes. We would be surprised if the use of an application to present the portfolio did not influence rater scores since a portfolio which contradicted claims made by the student would undermine their argument for achieving outcomes, resulting in lower scores. For the fall 2008 and spring 2009 semester, one of our adjunct faculty, who is a practitioner, became one of our portfolio evaluators. These evaluative comments give us an added perspective on our students and curriculum. Part of our scoring process asks evaluators to add formative feedback for the student. Some of the comments, included below, indicate how students bridge the academic-workplace in their use of technology:

I was struck by your comment in your statement conclusion where you noted that there is “an ever growing demand for communication to bridge the juncture where human interaction meets technology ... That beautifully describes where we are in 2008. And as a Technical Writer in 3G Technologies, and as an Instructor at ASU, I am pleased to welcome you into this exciting profession.”

Your final project, your group evaluation of projects, was a nice evaluation of products. This is what technical writers do! ... Your portfolio showcased a nice array of applications.

Your portfolio is fun and appropriately tells a framed story. You have a strong voice and your use of technology places you in an expert category.

Not all was well, of course. Other comments included:

I’m not seeing a wide-range of technologies here. I don’t see any mention of flash, for example, or other tools. And I would have liked to have seen evidence of your web site.

PowerPoint is a powerful tool. You didn’t use any graphics. The words were not placed on the page with thought to design. Your Portfolio did not have a professional look and feel. It should be the culminating artifact of your MWTC experience.

Of course, comments to individual students may or may not be representative of overall student achievement, of their ability to use technology, or of the relevance of those outcomes to the workplace. However, these comments do indicate that students are learning technologies and tools and trying to adapt them for their work to varying degrees. As part of an overall program assessment strategy, since spring 2008 we have asked graduating students to complete a short survey about the capstone course and about their experiences in the TC Program. A link to an anonymous online survey is sent to students after graduation and grades are posted to allow students (now alumni) to provide us with information they are not able to present in their portfolios.

Lack of direct instruction in tools or software is the most common negative comment, with three out of six suggesting that some type of tool learning be incorporated into the TC Program in some way. For example, one student recommended that students be required to take an exploratory course to learn basic software tools or that the TC Program partner with companies to provide online training or workshops for students. Two other respondents recommended that students be required to take a web- or multi-media design course. This focus on tools is, perhaps, not surprising from students who are either currently practitioners or who are searching for a job and faced with meeting requirements related to specific software applications in job ads. Certainly the perspective of these students is consistent with that of Lanier. If we take job ads as guiding criteria for making decisions about curriculum, then teaching of tools would seem to be paramount (Zhang, Olfman, & Rachtham, 2007). However, as we have seen in the conversations over certification and literacies, the evidence for teaching of tools is not consistent (Jones & Lea, 2008).

Another indication of how we are bridging the gap between academic and workplace needs is an analysis of the results of a master’s student survey of Phoenix Chapter STC members, including students of the TC Program, to determine the relevance of TC Program outcomes to practitioners as knowledge areas and skills (Crooker, 2006). Crooker’s thesis has provided us one way of understanding how our outcomes meet practitioner needs. Out of a sample of 167, Crooker analyzed 46 submitted surveys (40 from practitioners, 6 from ASU students with industry experience). Although he surveyed chapter members on all outcomes, we focus here on his results related to technology outcomes only. Breaking out these outcomes, Crooker found that the majority of respondents found technology outcomes to be essential for technical communicators. He sums up his results at the end of his thesis by saying:

This study found that the specific educational outcomes designed for the technical writing curriculum at ASU are considered up-to-date and are generally regarded as relevant to professionals who have current experience in the field of technical communication. This means that, according to professional technical writers and technical communicators, ASU’s technical writing program seems to be teaching material that is essentially on track with the current educational needs of college students. (p. 61)

In many ways the strongest indictment that Crooker’s study had of the program was of what he implied was academic jargon in the outcomes. He pointed out that many of the practitioners were uncomfortable with the word “genre” and suggests we use language more appropriate for a lay audience in the future (Crooker, p. 60). In the midst of the discussion about certification and defining a body of knowledge, we find it strange that practitioners, who we assume might need certification, if it is ever created, would be uncomfortable with using the professional language of the field. This appears stranger when we assume that one of the skills that would necessarily be part of any body of knowledge would be identifying the appropriate level of discourse for any particular audience. Surely, anyone proficient in technical communication would be a member of the technical communication discourse community. We recognize the reality that the tools controversy is never going to go away. We also know that there are many technical communication positions where practitioners will have to be proficient in specific tools. However, not all technical communicators write help files. If they don’t, do they really need to be proficient in RoboHelp? If they never write a document longer than twenty-five pages, do they really need FrameMaker skills? In fact, it would probably be healthy for the field if it recognized that technical communicators worked in many industries—not just software.

Finally, we have tried working with the local STC chapter that has graciously allowed students to attend software-training workshops, which they sponsor at a discounted price. We have also had a program alumnus volunteer to give software-training workshops. Despite the hue and cry for the training, very few people used the opportunities. We understand timing and money may be a factor. We hope to have online modules developed that may help students in the TC program. In addition, the TC Program requires students to take 12 hours in related area courses from outside of the TC curriculum. This requirement is intended to allow students to take courses that match their interests and job- or career-paths. Many of our students take advantage of tool-centric courses offered by ASU’s College of Technology and Innovation, for example, while others enroll in courses in other programs to enhance the skills and knowledge areas that best match their career plans.

Ultimately, we feel that the tools controversy is more of perception than reality. The reality is that students preparing for careers as technical communicators do need to possess certain abilities. We feel the outcomes our students demonstrate in their capstone ePortfolios demonstrate proficiency with those skills. This same skill-set is confirmed by practicing professionals in Crooker’s thesis. In addition, the fact that our students must submit an electronic portfolio using tools of their choice, tells us that they are capable of learning and utilizing appropriate digital tools. We believe the perception that only people who are trained in specific software tools can be successful technical communicators is specious. Yet, our job as technical communication educators is sometimes a balancing act between that perception and reality.

References

Cargile Cook, K. (2002). Layered literacies: A theoretical frame for technical communication pedagogy. Technical Communication Quarterly, 11(1), 5-29.

D’Angelo, B. J., & Maid, B. M. (2004). Moving beyond definitions: Implementing information literacy across the curriculum. Journal of Academic Librarianship, 30(3), 212-217.

Edwards, T. S., & Burnham, C. (2009). The promise of eportfolios for institutional assessment. In D. Cambridge, B. Cambridge, & K. B. Yancey (Eds.), Electronic portfolios 2.0: Emergent research on implementation and impact (pp. 87-90). Sterling, VA: Stylus.

Hakel, M. D., & Smith, E. N. (2009). Documenting the outcomes of learning. In D. Cambridge, B. Cambridge, & K. B. Yancey (Eds.), Electronic portfolios 2.0: Emergent research on implementation and impact (pp. 133-135). Sterling, VA: Stylus.

Hart, G. J. S. (2008). Why certification by STC won’t work. Intercom, 55(7), 11, 13.

Lanier, C. R. (2009). Analysis of the skills called for by technical communication employers in recruitment postings. Technical Communication, 56(1), 51-61.

Maid, B. M. (2004). Using the outcomes statement for technical communication. In S. Harrington, K. Rhodes, R. Overman-Fischer, & R. Malenczyk (Eds.), The outcomes book: Debate and consensus after the WPA Outcomes Statement (pp. 139-149). Logan, UT: Utah State University Press.

Nagelhout, E. (1999). Pre-professional practices in the technical writing classroom: Promoting multiple literacies through research. Technical Communication Quarterly, 8(3), 285-299.

Peckham, I. (2006, August 14). Tech outcomes [Online discussion comment]. Retrieved from http://lists.asu.edu/cgi-bin/wa?HOME

Rainey, K. T., Turner, R. K., & Dayton, D. (2005). Do curricula correspond to managerial expectations? Core competencies for technical communicators. Technical Communication, 52(3), 323-352.

Rosenberg, N. (2008). Certification: Why we need to begin. Intercom, 55(7), 11-12.

Turner, R. K., & Rainey, K. T. (2004). Certification in technical communication. Technical Communication Quarterly, 13(2), 211-234.

Yancey, K. B. (2005, July 12). Re: The technology and outcomes discussion at the WPA. [Electronic mailing list message]. Retrieved from http://lists.asu.edu/cgi-bin/wa?A2=ind0507&L=WPA-L&P=R46003&I=-3

Zhang, S., Olfman, L., & Rachtham, P. (2007). Designing ePortfolio 2.0: Integrating and coordinating web 2.0 services with ePortfolio systems for enhancing users’ learning. Journal of Information Systems Education, 18(2), 203-214.