Designing Web-Based Applications for 21st Century Writing Classrooms 9780895037992, 9780895037978

Citation preview

---

DESIGNING WEB-BASED APPLICATIONS FOR 21ST CENTURY WRITING CLASSROOMS

Edited by George Pullman Georgia State University and Baotong Gu Georgia State University

Baywood’s Technical Communications Series Series Editor: CHARLES H. SIDES

Baywood Publishing Company, Inc. AMITYVILLE, NEW YORK

Copyright © 2013 by Baywood Publishing Company, Inc., Amityville, New York

All rights reserved. No part of this book may be reproduced or utilized in any form or by any means, electronic or mechanical, including photo-copying, recording, or by any information storage or retrieval system, without permission in writing from the publisher. Printed in the United States of America on acid-free recycled paper.

Baywood Publishing Company, Inc. 26 Austin Avenue P.O. Box 337 Amityville, NY 11701 (800) 638-7819 E-mail: [email protected] Web site: baywood.com

Library of Congress Catalog Number: 2013008941 ISBN 978-0-89503-976-1 (cloth) ISBN 978-0-89503-797-8 (paper) ISBN 978-0-89503-798-5 (e-pub) ISBN 978-0-89503-799-2 (e-pdf) http://dx.doi.org/10.2190/DWB Library of Congress Cataloging-in-Publication Data Designing web-based applications for 21st century writing classrooms / edited by George Pullman, Georgia State University and Baotong Gu, Georgia State University. Pages cm. -- (Baywood’s Technical Communications Series) Includes bibliographical references and index. ISBN 978-0-89503-796-1 (cloth : alk. paper) -- ISBN 978-0-89503-797-8 (pbk.) -ISBN 978-0-89503-798-5 (e-pub) -ISBN 978-0-89503-799-2 (e-pdf) 1. Educational technology. 2. Language and languages--Study and teaching--Technological innovations. 3. Literature--Study and teaching--Technological innovations. 4. Academic writing--Study and teaching--Technological innovations. 5. Web-based instruction. 6. Technical writing. I. Pullman, George, 1962- editor of compilation. II. Gu, Baotong, 1963- editor of compilation. LB1028.3D483 2013 371.33--dc23 2013008941

Table of Contents

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . George Pullman and Baotong Gu

PART 1 Writing Environments . . . . . . . . . . . . . . CHAPTER 1 Theorizing and Building Online Writing Environments: User-Centered Design Beyond the Interface . . . . . . . . . . . . . . . . . . . . Michael McLeod, William Hart-Davidson, and Jeffrey Grabill CHAPTER 2 : An Electronic Writing Space . . . . . . . . . . . . . . . . . . . . . . Ron Balthazor, Christy Desmet, Alexis Hart, Sara Steger, and Robin Wharton CHAPTER 3 Redevelop, Redesign, and Refine: Expanding the Functionality and Scope of TTOPIC into Raider Writer . . . . . . . . . . . . . . . . . . . . . . . . . . . Robert Hudson and Susan M. Lang CHAPTER 4 The Role of Metaphor in the Development of an Instructional Writing Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Mike Palmquist CHAPTER 5 Creating Complex Web-Based Applications with Agile Techniques: Iterations as Drafts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Matt Penniman and Michael Wojcik

1

7

7

19

37

51

69

PART 2 Individual, Standalone Applications . . . . . . . 93 CHAPTER 6 Visualizing Knowledge Work with Google Wave . . . . . . . . . . . . . . . . . Brian J. McNely and Paul Gestwicki iii

93

iv /

DESIGNING WEB-BASED APPLICATIONS

CHAPTER 7 Students Playing as Scholars and Selves: Academic Synthesis as Conversation Game . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 David Fisher and Joe Williams CHAPTER 8 Designing, Implementing, and Evaluating a Web-Based Instructional Application for Technical Communication Classes . . . . . . . . . . . . . . . . . 125 David Chapman CHAPTER 9 Supplementing a Professional Writing Course with an Interactive Self-Learning Document Design Tutorial . . . . . . . . . . . . . . . . . . . . . 141 Suguru Ishizaki, Stacie Rohrbach, and Laura Scott CHAPTER 10 Developing a Web-Served Handbook for Writers . . . . . . . . . . . . . . . . . . 155 Stephen A. Bernhardt

PART 3 Open-Source Modifications . . . . . . . . . . . 175 CHAPTER 11 Peersourcing the PIT Journal: The Technosocial Pedagogical Hooks and Layers of Collaborative Publishing . . . . . . . . . . . . . . . . . . . . . . . 175 The PIT Core Publishing Collective CHAPTER 12 Blogs as an Alternative to Course Management Systems: Public, Interactive Teaching with a Round Peg in a Square Hole . . . . . . . . . . 195 Steven D. Krause CHAPTER 13 Developing a Course Wiki for Accessibility and Sustainability . . . . . . . . . . . 211 Karl Stolley CHAPTER 14 An Interface for Interaction Design: Using Course Wikis to Build Knowledge Communities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231 Steven T. Benninghoff Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247

Introduction George Pullman and Baotong Gu

The present collection of chapters was written by technical and professional writers and teachers who have come by different means to the same conclusion: that if you want something done right when it comes to information technology and writing instruction and research, you have to do it yourself. Not all of us, of course, do all of it ourselves. Some of us collaborate with professional programmers to design instructional resources that are both informed by writing pedagogies and more responsive to our disciplinary needs. Others of us use commercially available software to write and design instructional modules that can fit inside existing electronic environments. Some of us install and tailor open-source software to better suit our unique needs as writing researchers and teachers. And still others among us, fascinated by the unexpected similarities between writing code and writing prose, and conscious of the fact that text has become an interactive medium, taught ourselves how to program for the Web. Apart from fascination, our motivations were multiple and diverse. Some of us were frustrated in various ways by courseware purchased by our institutions, typically without much faculty input. While there are numerous reasons to complain about courseware, primary among the issues is its having been designed as a glorified grade book, emphasizing attendance and re-presentation of lecture notes rather than interaction, peer review, and authorship. One might argue this complaint is no longer fair, especially as the few products left in the market have changed considerably in response to user input. Nevertheless, the complaint articulates the need many of us have for a tailored fit and the desire to create something of our own, analogous to the difference between assigning a textbook and writing one. This analogy may seem a stretch for people who see software as an invisible container for ideas and textbooks— all books in fact—as knowledge products to be sold. We do not see either as software. We see software as a web of interconnecting workflows that amount to a social and intellectual environment; a place that influences the creation and exchange of ideas. Mistaking the digital world for everyday life, where words evaporate and paper disintegrates over time, leads people to rhetorical blunders like posting bacchanals on Facebook or sending “sext” messages to coworkers or blogging unreconstructed opinions about whatever for the world to read. Digital artifacts are more like tattoos 1

2

/

DESIGNING WEB-BASED APPLICATIONS

than footprints; time contorts, but it does not erase them. Cautionary tales are far less effective than direct knowledge of how computers actually work. Given that we see computers as environments rather than as objects, it makes sense to us to understand how they work, but more importantly, how they influence the way we work. Once having seen that influence, we arrived independently at the same conclusion: we need to assert a greater measure of control over our electronic environments. In addition to the need to understand in order to control our digital environments, many of us have pedagogical goals that are inconsistent with the traditional “sage on the stage” models of pedagogy that inform unidirectional communication tools. These alternative, student- and learner-centered pedagogies, led us to look for new ways to incorporate computer technologies in our classrooms. Some of us wanted our students to build interactive Web sites and experiment with the kind of computer programming that makes Web sites dynamic, but we were told by the local information technology authorities that security demands made it impossible for students to have server access. Or they could have storage space, but not the kind of space that would allow them to run scripts or databases. The exigencies of the information technology people, security, liability, scalability, legacy systems, and so on can readily conflict with the changing needs of teachers and students, especially those who want to perform pedagogical experiments that might impact the digital infrastructure. Consider, for example, the strain on storage and bandwidth caused by having students creating 3-minute documentaries with IMovie or MovieMaker. Given the reasonable resistance of IT professionals on campus, a number of us simply sought alternative avenues, installing rogue servers in some cases, or getting permission to install experimental servers, or simply going off campus to companies that provide server space. Thus we began wandering, in the company of some of our students, down the road to Linux and PHP and MySQL, free and open-source tools that require time and thought but no money and more importantly, no local institutional support. These forays into Web-based programming intersect powerfully with a much wider range of interests in our rapidly and dramatically changing field. The realization that composition today is multimodal has renewed general interest in high-level computer literacy and fundamentally changed our ways of thinking about communication. The instructional manual is long gone. People learn how to do things by watching videos and screen flows. Diagrams with callouts and features lists are disappearing fast. Even online help is dying. While many of us still emphasize textual clarity in our technical and professional writing classes, we move on quickly to graphics and animations and screen captures and sound and movies. Learning how to communicate effectively using these new forms requires considerable technical skill with some fairly sophisticated software. Words have become data, texts are becoming communities, consumers are becoming producers. At Amazon, for example, one can buy books, of course, but one can also write reviews of them and interact with others who have read and reviewed them. If you read an electronic copy of a book using Kindle software, you can see what others have highlighted and thus have a sense of what others think matters. At IReport, anyone with a wireless phone can broadcast (or narrowcast) news. And the work of

INTRODUCTION

/

3

technical and professional communication, indeed the work of writing teachers more generally, is becoming increasingly involved in the design and implementation of places of interaction. One does not need to know anything about programming to participate in this technological revolution. No technical knowledge is required to teach using Facebook or Twitter or Blogspot, for example. Nevertheless, an increasing number of members of our profession have begun to realize that deep thinking about the changes going on in communications as the digital revolution occurs requires closer involvement and direct engagement. Knowing how to make the machine do what you want it to is far better than learning how to bend your workflow to a corporation’s conception of your work. Very little has been published about writing professors writing software. The first monograph related to the subject was published by Cynthia Selfe in 1986. Computer-Assisted Instruction in Composition: Create Your Own encouraged teachers of writing to team up with colleagues in computer science to develop computer-assisted instructional software. The next book appeared 7 years later. Paul LeBlanc’s prescient Writing Teachers Writing Software: Creating Our Place in the Electronic Age (1993) spoke very effectively to the issues, opportunities, and problems facing English faculty who might be considering writing software for the desktops of the day, especially issues of media distribution, operating system compatibility, access, and expense of production. In addition to these two monographs, a handful of articles have touched on the subject, many of them appearing in Computers and Composition. In 1986, Thomas Barker published “Issues in Software Development in Composition.” In 1992, Paul LeBlanc published “Shaping Virtual Spaces: Software and the Writing Classroom. In 2002, George Pullman published “Electronic Portfolios Revisited: The Efolios Project.” In 2004, Carl Whithaus published “The Development of Early ComputerAssisted Writing Instruction (1960–1978): The Double Logic of Media and Tools” in Journal of Computers and the Humanities. And in 2006, Robert Commings published “Coding with Power: Toward a Rhetoric of Computer Coding and Composition” in Computers and Composition. The pace of publications dealing with modifying existing code and creating our own electronic environments will no doubt begin to accelerate. Indeed, we hope that as a consequence of reading these chapters you will feel encouraged to pursue work of this kind and to publish your results. We no longer live in a world of texts and monographs. We inhabit a digital world composed of electronic media, and to be technically and professionally literate today means to have a skillset none of our teachers had. It’s a commonplace of contemporary education that “the digital” natives arrive at college already fully computer literate. This commonplace, like most commonplaces, doesn’t reflect so much as imagine reality. In our experience, students are adept at consuming electronic products but just as desperate for instruction in the larger issues as we retrofit. It’s time to upgrade. In Chapter 1, “Theorizing and Building Online Writing Environments: UserCentered Design Beyond the Interface” McLeod, Hart-Davidson, and Grabill, argue “for broader acknowledgment of the role of rhetoric and writing theory in the design and implementation of writing software” by demonstrating how existing technologies

4

/

DESIGNING WEB-BASED APPLICATIONS

often fail to accommodate the way real writers write. They then offer an example of an alternative environment that they are developing at Michigan State University. An equally ambitious enterprise has been going on now for some time at The University of Georgia. As Balthazor, Desmet, Hart, Steger, and Wharton explain in Chapter 2, the ongoing production and modification of “, An Electronic Writing Space,” has witnessed many of the changes in Web coding that the Internet has experienced over the last 10 years. The goal of this software is to provide “a Web-based suite of applications designed to support all phases of the writing process— from invention, document exchange, and peer review to assessment of both individual texts and of writing programs,” and it has achieved this goal by constantly evolving to accommodate student and institutional needs by taking advantage of technological changes in Web programming. At Texas Tech, Hudson and Lang inherited a writing environment originally designed and developed by Fred Kemp in the 1990s, called TTOPIC, and have rebuilt the system to accommodate contemporary Web practices and technologies. The newly rewritten environment, called Raider Writer, not only provides a more stable and extensible place for students to write and receive feedback on their writing, it also provides data upon which to base research on the teaching of writing in first-year composition institutionwide. Chapter 3 provides a technical blueprint for the redesign of legacy systems with an eye toward providing institutionally viable, learner-based assessment data. It’s the onsite design and implementation of the system that makes the data possible, and thus the system provides access and insight that no commercial product could provide. At Colorado State University, Mike Palmquist has been developing the Writing Studio, an open-access collaborative writing space designed on WAC pedagogical principles and made available to institutions beyond Colorado State. Palmquist began thinking about this project in the late 1980s while still a graduate student at Carnegie Mellon, and the current incarnation of the site has a vivid Internet presence. As Palmquist notes in Chapter 4, “At the beginning of 2010, the site offered more than 35,000 pages of instructional content and had recorded more than 5 million visits during the previous year. During that period, more than 25,000 writers from more than 1,000 academic institutions worldwide logged into the Writing Studio an average of 42 times. During the two years prior to 2010, more than 900 instructors from more than 100 academic institutions created class pages for more than 2,000 classes.” Palmquist provides a detailed history of the development of this environment. His experience highlights the importance of finding ways to work within the institutional superstructures of a university when developing a writing environment as robust as the Writing Studio. In Chapter 5, “Creating Complex Web-Based Applications with Agile Techniques: Iterations as Drafts,” Penniman and Wojcik explore the ways in which writing code and writing text as well as the social interactions inherent in both can inform each other. As they explain, “Agile is the dominant approach in professional software development today. It integrates writing documentation into the development process, so many technical writers who work in the software industry work in an Agile environment. Agile is strikingly similar to a lot of what we teach in the

INTRODUCTION

/

5

writing classroom. It emphasizes elements like drafts, invention, peer groups, revision, and editing.” McNely and Gestwicki argue in Chapter 6, “Visualizing Knowledge Work with Google Wave,” that a site properly designed to accommodate collaborative learning and writing is one best designed by collaboration between computer scientists and writing teachers. Thus they embarked on an ambitious project to create a learning space that facilitates information visualization and sharing within the Google Wave framework. This chapter inadvertently highlights one of the risks associated with working in instructional technology. On the very day the revised version of this chapter arrived in the editors’ inboxes, Google cancelled Wave. The chapter remains immensely valuable, despite the change of Google’s heart, because it is an example of close collaboration between disparate disciplines that nevertheless possess intersecting needs and goals. In a ludic departure from the more traditional academic environments thus far discussed, Fisher and Williams’ Chapter 7 offers their “Students Playing as Scholars and Selves: Academic Synthesis as Conversation Game.” As they say, “As theorists, we wanted to explore questions about the nature and structure of scholarly discourse and citation and the boundary between fact and fiction in games.” And thus they set about constructing a gaming framework that allows their students to create conversational spaces inhabited by other players who read and make connections among ideas found in texts. In Chapter 8, David Chapman’s “Designing, Implementing, and Evaluating a Web-Based Instructional Application for Technical Communication Classes” argues that researches into how to “incorporate a Web component into an otherwise traditional course have been limited to the use of course management software rather than the development of custom-built Web-based instructional tools.” Thus, he set about creating Interweb: The Interactive, Web-Based Learning Project, which is a peer-reviewed-based instructional module written in PHP, MySQL, and AJAX. The tool allows teachers to assign writing assignments and encourage peer review in the form of students voting for the response they think works best. The tool incorporates equivocal tasks—prompts for which there is no set answer. Once the tool was developed, Chapman assessed its success by using it on two different occasions in a technical editing class. The results were interesting and instructive. Ishizaki, Rohrbach, and Scott’s Chapter 9, on “Supplementing a Professional Writing Course with an Interactive Self-Learning Document Design Tutorial,” describes in detail an interactive self-learning tool that enables students outside design classes to develop the visual communication skills widely acknowledged to be important for all people writing in technical fields but that are rarely taught due to time constraints. Unlike most online tutorials, theirs includes frequent self-reflective assessment tools. In Chapter 10, “Developing a Web-Served Handbook for Writers,” Stephen A. Bernhardt addresses the question of usability in reference to first-year students learning how to diagnose and solve their own writing problems using an online handbook. Bernhardt’s work is different from the other pieces here because he is working directly with a textbook publisher to provide a better, learner-centered, pedagogical experience rather than going it alone, as the rest of us have tended, in varying degrees, to do.

6

/

DESIGNING WEB-BASED APPLICATIONS

Bernhardt’s experiences are instructive in several ways, not the least of which is that he proves that as a community, we can work with related industries to provide an improved experience and an improved product. In “Peersourcing the PIT Journal: The Technosocial Pedagogical Hooks and Layers of Collaborative Publishing,” The PIT Core Publishing Collective use the language of software engineering to revisit the language of composition instruction, or as they put it, “We want to begin by making explicit the overlap between tinkering with technology and tinkering with writing.” In more concrete terms, they installed and modified an instance of Drupal, an open-source content-management system, to provide their students with a peer-reviewed journal. By having their students write in public, they were able to give their students a sense of writing for a real audience and thus a more “real-world” experience of writing. At the same time, they learned a great deal about installing and customizing a powerful piece of software for specific instructional purposes. Chapter 12, “Blogs as an Alternative to Course Management Systems: Public, Interactive Teaching with a Round Peg in a Square Hole,” offers another object lesson in using open-source software to customize an alternative to the standard courseware suite. Krause first begins with a critique of course-management systems that contextualizes his decision to do it alone. He then explains how he modified WordPress to create his own learning and teaching environment. In a similar vein, Chapter 13, “Developing a Course Wiki for Accessibility and Sustainability,” explores customizing a piece of open-source software, WikkaWiki, to create a better learning environment. In this case, Stolley is particularly concerned with addressing “accessibility” and the need to create environments that meet the needs of all learners. Additionally, Stolley indicates a further avenue of research and publication by the fact that he has released his modifications to the open-source software under the GNU General Public License. While direct contributions to the software industry by members of our community are still rare, the lead Stolley takes here is one that is sure to be followed by others. The final piece in the collection, Stephen Benninghoff’s “An Interface for Interaction Design: Using Course Wikis to Build Knowledge Communities,” also looks at wiki technologies, specifically at implementing PmWiki to provide an electronic environment designed specifically for writing students.

http://dx.doi.org/10.2190/DWBC1

PART 1

Writing Environments à à à CHAPTER 1

Theorizing and Building Online Writing Environments: User-Centered Design Beyond the Interface Michael McLeod, William Hart-Davidson, and Jeffrey Grabill

While there are many reasons to create your own software if you teach writing, fundamental to all of these is an idea that often goes unstated: whoever writes the software encodes a vision of the way writing works into the product. Simply put, for every piece of writing software there is a theory of writing and also a pedagogy, ideas about who and how people should write (Selfe & Selfe, 1994). These ideas not only manifest in the user interface, but form the basis of the internal structure as well: data models, programming design patterns, flow logic, as well as information architecture and interaction design. In this chapter, we begin with the premise that when writing software fails to meet the needs of users, it may be due to an incomplete theory of writing underlying the code: a vision of the writing process, for example, that does not adequately capture users’ goals and activities. This is a lesson we have learned over many years of working with existing software tools and working on software of our own design. Developers of new writing software—particularly Web-based software due to its reliance on browsers and the W3C Document Object Model (W3C, 2005)—face similar problems 7

8

/

DESIGNING WEB-BASED APPLICATIONS

when they encounter implementation hurdles imposed by others’ conceptual models of texts and writing activity. In this chapter, we argue for broader acknowledgment of the role of rhetoric and writing theory in the design and implementation of writing software. We do this by illustrating the ways that writing environments can fail to meet the needs and/or expectations of both users and developers due to a flawed conceptual understanding of the human activity the system is designed to support. Drawing on a specific and detailed case example, we point to conflicts in existing writing software and discuss our own attempts to better meet the needs of writers, teachers of writing, and students by changing the deep structure upon which writing systems are built. Our case emphasizes the ways that a common writing activity—peer review— is poorly supported in two common types of writing software: desktop editing (e.g., Microsoft Word, GoogleDocs) and course management (e.g., Blackboard, Angel) packages. Our Web-based application solution to these problems redfines the basic data structures associated with writing review to better suit the goals of all relevant user groups: writers, reviewers, and review coordinators (e.g., teachers). But our case also helps us to illustrate that making software, for those who have a stake in theorizing rhetoric and writing, also holds tremendous benefits. Whether we implement software on our own or come to the design table as collaborators or consultants, extending our efforts at user-centered design of writing tools “all the way down” to the core data structures of writing environments can help us to reexamine and expand our own theories about the practice and learning of everyday writers. MOVING USER-CENTERED DESIGN BEYOND THE INTERFACE Paul LeBlanc’s 1993 book Writing Teachers Writing Software—though written well before the emergence of the World Wide Web and the subsequent solidification of Web standards had made creating writing software the relatively approachable idea that it is today—still stands as the most thorough case for writing teachers and researchers to expose their work to the world via software tools. Central to LeBlanc’s argument is the idea that we might build environments for writing that carry our own best ideas about how people write, and how they learn to write, throughout the writing process and even beyond the walls of the classroom. But if we are making an honest assessment of the work of writing teachers and researchers, we can conclude that very few have taken up LeBlanc’s challenge. The tools that most people, including students in our own classroom, use to write were made not by writing teachers or researchers. This is not to say that writing teachers and researchers have ignored technology. On the contrary, once largely the focus of subfields such as technical communication and computers and writing, the use of technology in both writing and the teaching of writing has become a mainstream concern for the field of rhetoric/composition, as the 2010 Conference on College Composition & Communication theme “The Remix” demonstrates. We applaud our colleagues for a tradition of hands-on, critical engagement with software tools and writing environments that goes well beyond skepticism and moves solidly into the realm of thoughtful intervention. But at the same time, we

ONLINE WRITING ENVIRONMENTS

/

9

would note that the pattern of scholarship in computers and writing and rhetoric/ composition has been to employ existing technologies to modify writing pedagogies, and vice versa. The modifications that get made to software tools, then, rarely run deeper than the user interface. But if we want to deliver complete user experiences that fit with our best theories of writing and learning, we have found that we sometimes must make fundamental changes to the ways writing activity is represented in software, all the way down to the data structures. We still share our field’s overall aim of creating a different, and better, user experience (UX) for writers. But we cannot assume that we can achieve this by altering the user interface alone.1 The elements designed into a software product that influence UX include many things that may never manifest in an obvious, concrete way in the UI: user roles, the goals toward which users work, and the actions the software recognizes as valid steps toward reaching those goals; groups of actions assembled into work routines; and finally data objects that result from and/or support users’ actions. DOING THEORY, MAKING SOFTWARE: EXTENDING THE SCOPE OF INQUIRY TO INVESTIGATE INTERVENTIONS IN WRITING ACTIVITY AT AN ORGANIZATIONAL SCALE At the Writing in Digital Environments (WIDE) research center, we are software designers only insofar as we are making and testing ideas about what literate activity is like and what users might need in order to improve their ability to meet their writing and communication goals. We make software as a means to test particular types of ideas—interventions in group writing behavior that we think might make a positive difference. When they are working in concert with best practices, we believe that others who create writing software are essentially doing the same thing, though they may not be doing so with the same basis in writing research or pedagogy that we bring to our work. Many software designers building writing software may not be familiar with theories of writing and/or rhetoric. This may or may not pose a problem. If software developers pursue user research that tests their designs against real-world practice, they may also be building, tacitly or explicitly, theories of writing that inform their design work. But if designers do not do this sort of work, or if they pursue too narrow a focus on a particular set of marketable features, for example, it can lead to what those of us who do writing research might characterize as mismatches between how writing happens in a software environment and how it happens in the world. These mismatches are not necessarily errors, nor are they huge social problems. But they do represent opportunities for new tools or new features, and they are, by their very nature, opportunities that writing researchers are best positioned to develop. In the 1

See Alan Cooper’s 1995 book About Face for one of the earliest arguments for a comprehensive approach to designing user experience as opposed to the more narrow approach to designing user interfaces.

10

/

DESIGNING WEB-BASED APPLICATIONS

next section, we discuss one such mismatch and the opportunity it has created for us to both test the validity of a theory derived from research on writing and to offer a new approach to designing functionality for writing tools/environments that remediates a less-than-optimal theory. SUPPORTING THE TEACHING AND LEARNING OF PEER REVIEW IN WRITING CLASSROOMS One of our first software designs began as a response to our own frustrations as writing teachers. We understand the importance of peer review in the classroom but have found it exceedingly difficult to teach both writing and review at the same time. The demands of reading student writing alone can be overwhelming, even without trying to gather and organize responses to that writing and tracking student review work over time. We examined a number of technologies and found them all to be lacking a fundamental understanding of peer review as an activity. There are any number of ways current technologies might be leveraged to get feedback on an existing text. Many text-editing applications have features that allow users to add comments and track changes, while many course management platforms have features like threaded discussion boards or chat rooms that, while not designed for review, many instructors have learned to reappropriate to support their classroom review practices. In either case, both text editors and course management systems value review only as a means of evolving the text to a “better” version—to a “draft 2.0”—which makes it nearly impossible for these technologies to value review itself as a teachable and learnable activity. It was up to us, being the “experts” on writing, to solve that problem. Microsoft Word is a perfect example of writing software with dedicated review features. Word has a sophisticated “Track Changes” feature that allows a reviewer to directly alter the text and leave a report of that change for the author, who has the option to accept or reject those changes. Both Word and Adobe Acrobat, a document viewer with limited text editing capabilities, have a set of commenting tools that allow reviewers to highlight selections of text and leave annotations, as well as digital versions of analogue activities like highlighting and “sticky notes” and drawing; Acrobat even has a set of features that allows reviewers access to proofreader marks and symbols. These features are incredibly powerful and make it easy to leave comments or suggestions for writers. Where these tools fail instructors, however, is in valuing the products of review. In Word, for example, when an author chooses to accept a change recommended by a reviewer, that change is hard-coded into the document and all traces of the suggestion are lost. The person who made the suggestion is not notified that their suggestion was accepted. In Acrobat, reviewers do not interact with the text directly (the software makes notes and edits over the top of the text, since it’s text-editing capabilities are limited), so the writer reviews comments and suggestions in Acrobat before returning to their text editor to make revisions, leaving no trace of the reviewer’s work in the next version. This not only makes it impossible for reviewers to know when they have made helpful suggestions or comments, but it also makes it nearly impossible for instructors to assess the review work of their students. Some instructors have found

ONLINE WRITING ENVIRONMENTS

/

11

clever ways to utilize these features for assessing the products of review: one secondary English teacher we interviewed, for example, has students either color-code or sign their comments with their initials before submitting the commented file for a grade. This allows comments to be attributed to specific students and assessed. Still, because of the way the system is built, there is no notification that comments or suggestions are valued by the writer, or that they make a direct contribution to a new version of the text. If the instructor wishes to assess the review work of a student over time, the instructor must store each and every file the student has reviewed and manually assess the work—a daunting task for any writing teacher, given that this same process is also necessary for each student’s written work. RETHEORIZING REVIEW: A NEW ACTIVITY MODEL There are two ways in which review, as it is implemented in writing technologies like Word, conflicts with review as it exists in practice. The first conflict is in the typical workflow of a review. Word does not see review as a distinct part of a workflow in which any number of other activities might be occurring. To put this another way, Word doesn’t understand “a review” to be an event, a kind of social transaction as we understand it to be in the real world. Word sees review as a solitary experience done in relative isolation by a single person. A review is not something a whole class does, as far as Word knows. Figure 1 is an illustration of our understanding of review as a social practice in which the writer, reviewer, and review coordinator all benefit from the work done as part of the review process. Realistically, Word, as it is currently designed, can only support steps 2, 3, and 7 of this process. It allows reviewers to insert comments into a text, make conditional changes to a text, and allows the author of that single text to review and either accept or reject those changes. What this means is that it’s difficult (if not impossible) to coordinate the complete review process using Microsoft Word; it falls to the teacher to make the connections between the supposedly isolated acts of review Word acknowledges. REDEFINING THE OBJECT STRUCTURE OF REVIEW: BUILDING ELI The second major conflict between how software like Microsoft Word implements writing review is in the structure of its data. The object structure for review as implemented by Microsoft Word is backwards from the way we as teachers require review to work in the classroom. As discussed earlier, it sees the artifacts of review (comments, suggestions, etc.) as temporary and disposable. If the writer accepts a recommendation, that change is made to the text; and if the writer rejects a recommendation, nothing happens; in either case, the work of the reviewer is gone, leaving no trace of its existence or record of its use. Figure 2 is an example of such a model. This is a comment left for us by one of the editors of the collection in one of the early drafts of this chapter. There were several such comments and suggestions left, and we acted on many of them, but the act of doing so was completely invisible to the editors. It would be up to them to hunt through the new version of a text and

/

Figure 1. Review as a social practice.

12 DESIGNING WEB-BASED APPLICATIONS

ONLINE WRITING ENVIRONMENTS

/

13

Figure 2. The static review model as implemented by Microsoft Word.

manually compare it to the previous draft to see if any change had been made; to be fair, some text editors like Google Docs can do difference comparison, though that feature is still in significant need of development. They also received no credit for having made a suggestion that may (or may not) have led to a change in the revised version. This suggests that the designers of Word or Google Docs or other such text editors are only interested in the product or artifact resulting from a review, while we as teachers or editors are interested in the review process, the products of review, and how the process reflects thinking. A system that truly values review, that makes it both learnable and teachable, must have a different theoretical understanding of the products of review. Our solution to these problems was to design Eli, a Web-based application that would support the coordination and assessment of writing review. Eli makes review activity focal and the shared object of attention in the system. A review is a group activity consisting of reviewers, review targets (documents), and criteria, all under the direction of a review coordinator. It utilizes the new review model introduced earlier and is built upon a set of data structures that regard the artifacts of review as independent objects and stores them separately from the text from which they originate (Figure 3). Storing artifacts of review outside of but related to the text tells us a great deal about each individual object. At a surface level, we have a base set of metadata that Word assigns to its comments—we know who wrote each one and when it was written. However, their independence affords many opportunities for users to interact with comments individually. Table 1 shows examples of some of the ways users in various roles inside Eli can interact with comments. These interactions cannot be accomplished simply by tweaking an interface or adding a new feature. Enabling these interactions requires a complete reconceptualizing of what comments are, how they are stored, and what information describes them

Figure 3. The Microsoft review object model vs. Eli’s review object model.

Eli’s review object model: Comments and suggestions are separate objects but maintain their relationships to each other. This allows for complex analysis of the comments as their own objects—how they are rated, if an instructor has endorsed them, if they’ve been used in a draft, etc.

/

Microsoft’s review object model: Comments and suggestions are embedded inside individual documents and do not exist as their own objects.

14 DESIGNING WEB-BASED APPLICATIONS

ONLINE WRITING ENVIRONMENTS

/

15

Table 1. Ways Users in Eli Can Interact with Comments Writers can:

Reviewers can:

Instructors can:

• rate individual comments—on a 5-star scale, thumbs-up or thumbs-down, or Likert (as specified by instructor) • add comments to a “revision strategy” • indicate whether or not a comment directly contributed to a revision

• see a detailed report of how their comments have been assessed, by writers they reviewed, and by instructors • be notified when their comments directly contribute to a revision • see formative feedback generated by the system based on their review activity

• view all responses to a student’s writing • view all comments made by an individual student and responses to those comments by writers • endorse individual comments and suggestions • view reports of student review work over time

(metadata). They require a complete top-to-bottom reimagining of what it means to do writing review electronically and a fundamental understanding of (a) review as an activity, (b) the needs of writers, and (c) the needs of teachers. A BROADER PURPOSE FOR SOFTWARE-AS-THEORY: REIMAGINING WRITING ACTIVITY One of the ideas we hope our colleagues take away from this discussion is the way that making software can itself be generative of new ideas, new theories of writing. When we were creating Eli, we began to realize just how important the act of writing review—and therefore the need to prepare students to be excellent reviewers of others’ writing—is in an information economy. We have known for a long time that students benefit as writers from engaging in peer review by learning to make explicit for others how a text does or does not meet audience expectations and what can be done to improve a text. We also saw implicitly what economist Yochai Benchler argues explicitly in The Wealth of Networks when he writes, To succeed, therefore, peer-production systems must also incorporate mechanisms for smoothing out incorrect self-assessments—as peer review does in traditional academic research or in the major sites like Wikipedia or Slashdot, or as redundancy and statistical averaging do in the case of NASA clickworkers. The prevalence of misperceptions that individual contributors have about their own ability and the cost of eliminating such errors will be part of the transaction costs associated with this form of organization. They parallel quality control problems faced by firms and markets. (2006, p. 15)

First, let us note how thoroughly “social” Benchler’s perspective on writing is when compared with even the most progressive view from our own field. As an economist, Benchler’s lenses see nothing but social phenomena, a fact made all the

16

/

DESIGNING WEB-BASED APPLICATIONS

more obvious when the lens is as macroeconomic as the one that produced the observation above. But we also want to note that Benchler’s observation is a powerfully disruptive concept to our fields’ typical priorities for including peer review in the writing classroom. Maybe, it suggests, we ought to focus not so much on the writing as on the review. After all, writing is like line-work in a manufacturing economy, while review is more like quality control, higher up the value chain than the routine production of texts and images. As we made Eli, and as we gained the ability to make review a focal concept of learning in our own classrooms, we became convinced that Benchler was right, even before we encountered his argument! And this made us wonder: just how might our other software projects help us to realign our values, to re-see what is essentially the writing process viewed as full-throated social phenomenon? We ask this question and others like it in the interest of pursuing writing research on a social scale unlike what we’ve seen our field carry out in the past. Influenced by both developments in and studies of large group phenomena in communication research (e.g., “crowdsourcing”), we turn our attention to large-group writing activity as well. Here is the question we posed for ourselves: what if our writing tools and environments facilitated users efforts not to make “edit documents” or “process words,” but something closer to “making rhetorical objects,” where a rhetorical object is something that can be passed along to others by its maker with some assurance that it will do some communicative work on the makers’ behalf. We say “object” because the form might not matter so much to the maker, or it may be variable, or multiple. The point is, for the maker, the form is a means to some end and not necessarily an end in itself; though, depending on the audience and purpose, form may become important, approaching a goal in its own right. RHETORICAL OBJECTS AND A MODEL FOR SUPPORTING THEIR CREATION Rhetorical objects are the building blocks of social life. As such, they are means to myriad ends. They support decision-making activity, they move people to action. They are highly variable and deliberately arbitrary structures that can correspond with semantic boundaries or structural elements of texts. They can also be physical objects in the world. And they can be “nonstructural”—purely semantic—in the sense that they represent qualities of a text or an artifact that are not readily mapped to a specific area, location, or subsection. Rhetorical objects are, by definition, social, in that they represent attempts to assemble and hold people together. Though they can manifest as texts, they are often more—and sometimes different—than mere texts. They may have social or legal standing, like a contract, or symbolic and iconic qualities like a campaign poster. They build relationships. Or simply keep them going. Or break them. Rhetorical objects are born of the written sign, though they travel in and out of oral, aural, performative, and other sensory forms. Following Derrida, we understand that rhetorical objects are never divorced from the inherent properties of what is written: they may be reiterated, ad infinitum. There is no end to the ways they may be interpreted. They are

ONLINE WRITING ENVIRONMENTS

/

17

always situated upon utterance and interpretation, but they are unbounded by time and space. They linger and reappear. They approach the infinite. Rhetorical objects are invisible, by design, most of the time. Their boundaries are nonnecessary in relation to the social goals of those who make and use them. Their form is inexact and variable, more or less stable depending on the exigence, like fire. Individuals who can see them, who appear to command them or manipulate them to their own ends, might be thought to be doing magic. This is because rhetorical objects are less particle than wave; the result of social forces that may be predictable on a macroscale, like the tide, but remain impossibly complex at the microscale, like the chaos of crashing surf. An individual can never master the surf, but one can learn to see the wave, ride it even, to the wonderment of others. At WIDE, we are interested in helping the world make and distribute rhetorical objects in the course of achieving its goals. We are focused on the large-scale social production of rhetorical objects and the ways devised by groups to ensure quality, manage effort, assess impact, and create meaningful results at the macroscale. Each of these activities might be understood as a kind of process or life cycle phase of production of rhetorical objects. And for any given project, document, or person, we might see this process as a kind of wave. But at scale, it cannot be understood this way. A better way may be the planar model as illustrated in Figure 4. Production, in this view of the world, is a process of lamination wherein each layer adds value to a rhetorical object. Means and ends exist at each planar level, as do goals, tasks, and milestones.

Figure 4. A planar process model of rhetorical objects.

18

/

DESIGNING WEB-BASED APPLICATIONS

What should be interesting to writing researchers is the way nearly all of the activity studied as composition exists only on the lowest plane. And yet meaning is made, remade, enhanced, spread, and enhanced all the way up the line. In fact, if we consider the terms on the left side of the diagram, they might be seen as an expansion of the classical canon; a figuration meant to approximate the scope of rhetorical production from its inception in ancient rhetorical treatises. The familiar canons, save delivery, perhaps, might be said to exist on the same continuum as the elements on the left side, collapsed in the space of the “Create” plane. But the terms “review, coordinate, analyze, visualize” represent equally essential areas that add to the scope of rhetorical performance. At WIDE, we have become interested in producing new technologies on each plane that has the potential to support activity at that level, but that also fosters learning in groups and individuals. What is learning? Simple. In this model, learning is a vector through at least two and often more planes. Learning manifests in the rhetorical object itself as well as in the people engaged in its making and use. In people, learning produces a change—in perspective, in attitude, in know-how, and so on. In objects, learning produces a change in value. We believe it is possible to evaluate change in both people and objects, and that doing so would help our field to make a powerful leap forward in the ways we prepare students for work in an information economy. REFERENCES Benchler, Y. (2006). The wealth of networks: How social production transforms markets and freedom. New Haven, CT: Yale University Press. Cooper, A. (1995). About face: The essentials of user interface design (1st ed.). New York, NY: Wiley & Sons. LeBlanc, P. (1993). Writing teachers writing software: Creating our place in the electronic age. Urbana, IL: NCTE. Selfe, C. L., & Selfe, R. J., Jr. (1994). The politics of the interface: Power and its exercise in electronic contact zones. College Composition and Communication, 45(4), 480–504. W3C. (2005). Document object model. Retrieved from http://www.w3.org/DOM/

http://dx.doi.org/10.2190/DWBC2

CHAPTER 2

: An Electronic Writing Space Ron Balthazor, Christy Desmet, Alexis Hart, Sara Steger, and Robin Wharton

(an Electronic Markup and Management Application) is a Web-based suite of applications designed to support all phases of the writing process, from invention, document exchange, and peer review to assessment of both individual texts and of writing programs. was developed for and by writing instructors in the University of Georgia First-year Composition Program and has been used successfully program-wide since 2005. In 2010, the cumulative database of users reached the 20,000-person mark. In recent years, has also migrated on a small scale to other programs on this campus and to other campuses within and beyond the state of Georgia. Between 2001 and 2010, the interface has gone through a steady evolution as teachers and developers have responded to student needs and emerging trends in writing technologies. Perhaps the most dramatic and important changes, from the point 19

20

/

DESIGNING WEB-BASED APPLICATIONS

of view of writing pedagogy, have been to the actual environment in which students write and the relation of that environment to the available Web displays. In tandem with these fundamental changes to ’s writing space have been adjustments to display and navigation that make all phases of writing more elegant and efficient. Finally, the past 6 years have seen the development of several research and assessment projects that draw on the resources provided by our ever-expanding database of student and teacher documents. FIRST: THE XML EDITOR The original development team was a self-selected group of faculty members, academic professionals, and graduate students from the UGA English Department. Nelson Hilton—then Head of the Department of English and now Director Emeritus of the University of Georgia’s Center for Teaching and Learning—was indisputably the moving force behind the project; his goal was simply to energize an interested set of colleagues to do “something” with XML (eXtensible Markup Language), whose potential and future importance for digital humanities he recognized and wanted us to address. We met for 2 hours each Tuesday afternoon in the spring semester of 2002 in the department’s cramped third-floor computer lab, exploring the nature and potential of XML but, perhaps more important, taking an actual course in how to do markup. Some of us were left by the wayside by the time we had moved on to designing style sheets with XSLT (eXtensible Style Language Transformations), but everyone knew how markup worked and what its potential uses were. We invited a consultant to help us understand how to take such a project from start to finish and then were left to the exciting part of figuring out exactly what we wanted to do and why. While some of the techies tuned out, the rhetoricians in our group spent a number of weeks debating vigorously the basic skeleton of tags—the DTD or Document Type Definition—that would govern the markup of actual texts. Based on advice from Wendell Piese, our consultant, we used sticky notes and a white board to imagine a structure for our writing application. This seemed to be a crucial point for us; the Peter Elbow expressivist in the group thought that an open category of would be least constrictive on writers, while others, perhaps more pragmatic, suggested that might be the basic unit of markup, even though such a 19th-century concept of essay structure risked inscribing our writing software within a currenttraditional model of composition instruction. Although every choice put constraints on the writer’s generic imagination, we finally settled on as our root tag and the most basic level of textual definition. These debates over nomenclature—really, a debate about the very nature of textuality—are what the original developers remember most fondly about the origins of the project. Finally, although we did not begin with any clear sense of where our imagined application might find a home, the presence of the Director of First-year Composition and the activity of writing instructors in the development group made the First-year Composition Program a natural home for the application that eventually was named . More specifically, the impetus for the project was rooted in shared dissatisfaction among the working group members with the technologies available to us as

: AN ELECTRONIC WRITING SPACE

/

21

writing instructors. For example, the members of the working group recognized that one of the major shortcomings of the commercial course management system (CMS) they were using in their writing classes was that it was not well-designed to accommodate the submission, review, and exchange of documents. As a result, student writers, reviewers, and instructors were exchanging documents as attachments in the CMS’s embedded mail system, or students were submitting completed assignments to instructors via an assignment “dropbox.” The dropbox method of document exchange also tends to treat student documents as fairly static entities rather than taking advantage of what Richard A. Lanham (1993) describes as “the truly enzymatic powers of electronic text” (p. 41). As Lanham argues in The Electronic Word, the visual quality of electronic texts, plus their potential for restructuring as a way of reviewing, enhances an understanding of the writing process. We created to collect and display the students’ electronic texts in their various stages, thus harnessing the power of the computer to enhance and augment the students’ recursive writing and reading processes and discussions of those processes. So, in addition to removing what we perceived to be general design flaws, we sought to create writing software that would promote active learning; in other words, we sought to go beyond creating writing software that would teach students “nothing more than how to type, format, open, and save” (Rice, quoted in Inman, 2004, p. 192). XML was and remains the principal component of the courseware. One reason we initially were drawn to XML markup as a writing technology is because it solved document incompatibility problems. We knew that XML offered us “the tantalizing possibility of truly cross-platform, long-term data formats [because] XML documents are text, and any tool that can read a text file can read an XML document” (Harold & Means, 2001, p. 6). We felt that XML also offered us “tantalizing” pedagogical possibilities as writing instructors. First, XML is a metamarkup language, which means that the data in a text document could be “marked” or identified with human-readable “tags,” and that these tags are not limited in type or scope. In other words, not only does XML allow developers and writers to create tags as they deem necessary for any given document, but the names of the tags can be read directly from the document; that is, “all the important details about the document’s structure are explicit” (p. 6). We initially designed with visible XML tags, making explicit the typically implicit details of a text in an effort to intensify the reader/writer’s self-consciousness about the text and, like other visual manipulations of electronic text, to cause “the perceptual field of the ‘reader’ [to become] considerably richer” (Lanham, 1993, p. 73). Just as important, through the use of shared tag sets, we hoped that student writers, peer reviewers, and instructors would enter a shared discourse community. Finally, we were drawn to XML because XML documents are highly malleable. Since XML is “a structural and semantic markup language, not a presentation language” (Harold & Means, 2001, p. 4), any given XML document may be displayed in a variety of ways. We anticipated that these various displays might provide some dramatic “aha!” moments for student writers. Thus, XML offered two key advantages: an open-document standard that avoided the compatibility problems created by proprietary word processing programs and the possibility of capitalizing on a reader/writer’s visual literacy with multiple displays.

22

/

DESIGNING WEB-BASED APPLICATIONS

The application involves an XML database on the back end, with a Web display using XHTML style sheets on the front end. This structure has remained consistent throughout the development of as a writing tool. But ’s front end, the application and interface through which XML documents were produced, has changed several times as we sought to balance writers’ need for a transparent medium that did not interfere with composing, readers’ need for clean and flexible displays, and the developer’s need to provide a mechanism that allowed text to become XML markup. When we began in 2001, the working group first attempted to create an XML editor from scratch. The result (see Figure 1), although expensive and timeintensive, was wholly unappealing. The interface was something only a coder could love, and the writing space itself was so minuscule that a return to the old-style word processor that revealed only a few lines of typing at a time would have been preferable. Next, the developers discovered the open-source application jEdit (http://www.jedit.org/), which had the advantage of being a robust application that engaged a vibrant development community. Even then, jEdit was obviously an application developed for database construction, for one of the first changes we had to ask for from the developers was an ability to scroll down more efficiently through long stretches of text, the kind produced by essay writers rather than coders. In this version, before a student began to mark up his or her text, he or she had to choose a predefined tag set—a document-type definition (DTD)—to go with it based on the assignment and the stage

Figure 1. First: Home-made XML editor.

: AN ELECTRONIC WRITING SPACE

/

23

of that assignment (e.g., draft, review, revision, etc.). Once the student had selected the appropriate DTD, he or she would compose (or paste) his or her text into the workspace. Then, depending on where the student placed his or her cursor, he or she was given a limited selection of suitable tags arrayed in a hierarchical structure from which to choose. For example, he or she might be given the option to insert a tag within a or to insert a or within a . We initially expected to gain significant pedagogical value from the overt disruption of the students’ texts that the insertion of the human-readable XML tags caused because, as Willard McCarty (2003) explains, adding markup to a document denotes the act and product of recording a textual entity in computationally tractable form . . . [it] discipline[s] reading with greater control of and responsibility to the data . . . [it] privileges the human reading with all its messy contingencies, then puts that reading to the test.

In other words, we expected the XML tags to defamiliarize the students’ writing, thereby making them more disciplined readers of their own and others’ text as well as more responsible writers. We expected that both adding markup and then viewing the markup would test the students as readers and provoke productive discussions about the “messy contingencies” of the texts as well as the very acts of writing and responding to particular assignments. Beginning with these possibilities for increasing students’ awareness of the complexities of the writing process by requiring them to identify and tag various features of their texts using XML, we began to create DTDs that were tailored for specific writing assignments and audiences. Because XML is a hierarchical markup language, the working group naturally began designing DTDs and tagging assignments that asked students to examine their own and others’ writing at the microscopic level. For instance, the “structure” assignment instructs students to identify and tag within an essay an essay title, several paragraphs, a topic sentence within each of those paragraphs, and a thesis statement within at least one of the paragraphs (see Figure 2). While the essay structure and tag set described here could be delivered “off the shelf” to students as part of a class assignment, this prepackaging differed from many existing commercial software packages because the instructor could share the DTD with the students, allow them to examine its structure, and even offer them the possibility of modifying the structure or creating a different one of their own. In other words, the early version of allowed students the opportunity to “see the man behind the curtain,” to see what levers and pulleys were being manipulated in order to attempt to arrive at the intended outcome. In addition, as mentioned before, the shared tag sets helped to build communities of learners with a common vocabulary for discussing documents and textual features. Beyond simple functionality, there were distinct advantages to this arrangement, as the conscious application of previously defined XML tags to texts simplified the display process and allowed for more elegant and varied displays. For instance, all of the thesis statements from a class’s collected essays might be displayed at once for discussion; essays could be

24

/

DESIGNING WEB-BASED APPLICATIONS

Figure 2. XHTML display: Topic sentences highlighted in paragraphs.

displayed as highlighting thesis and topic sentences as they appeared in the whole essay, then, with the click of a button, reduced to a structural outline showing only the thesis and topic sentences (see Figure 3). In addition, the ability to create such displays in real time during a writing workshop facilitated the discussion of the purposes of such textual features and allowed a class to review quickly numerous documents within the space of a 50- or 75-minute workshop period. While the members of the working group eagerly employed this homegrown writing technology, adding DTDs and even teaching students to write and use their own DTDs and assignments, eventually the jEdit working space and the display of the XML tags in the students’ documents became increasingly problematic as moved beyond the classrooms of the original working group members. Despite the pedagogical advantages of the visible XML tags discussed above, many of the students using became aggravated by trying to compose and review documents in which the XML tags were interspersed visibly and intrusively among the original text, and many of their teachers experienced similar frustrations, as well as difficulties balancing the teaching of a markup language with teaching writing. The widescale adoption of throughout the first-year writing classes at the University of Georgia and in other writing classes both at UGA and at other campuses around the country caused the working group members to rethink our choice of jEdit as the composing space for student writing and commenting in , as we did not want the implementation and use of the technology to begin to interfere with the other pedagogical goals of the courses in which it was being used. While the power of XML greatly enhanced the reading process, the XML editor proved to be a formidable obstacle for writers, as the tags, still quite prominent in the right-hand side

: AN ELECTRONIC WRITING SPACE

/

25

Figure 3. XHTML display: Thesis and topic sentences as a document tree.

of the writing environment, were also highlighted in different colors within the text, making the writer aware of the fragmented nature of markup and making revision, editing, and proofreading difficult (see Figure 4). NEXT: WRITING WITH OPENOFFICE Early promoters of XML predicted confidently the imminent demise of WYSIWYG (what you see is what you get) or the opaque surface of the familiar word processor. They were wrong: students raised on Microsoft Word rebelled at the exertions required of writers working with visible XML in their texts. Furthermore, the visible XML tags continued to work against what is probably the most important process to writing instruction: revision. In OpenOffice, we found a good compromise: a traditional (and free!) word processor that runs XML in the background. The biggest gain here was the comfort of writers; the biggest drawback was the unpredictability of Web displays, which tended to push further toward being a document-exchange application; that is, it was easier to download, read, and comment on essays in the word processor than to negotiate with the Web display. Thus, in this iteration of , traditional writing processes, collaboration, and peer review were supported by ease of document exchange. What was lost were the rich possibilities for display available when users controlled the XML content tags; not merely the cleaner, more elegant displays, but also the possibilities for visual manipulation and display transformations that had made “ First” so pedagogically rich and flexible. In this iteration, developers also focused on improving ’s LMS functions, for the prevalence of such systems as Blackboard and WebCT across the university

26

/

DESIGNING WEB-BASED APPLICATIONS

Figure 4. 1.1: jEdit as XML editor.

raised both students’ and teachers’ expectations for such management tools. incorporates course management functions standard in most LMSs: secure user registration and authentication; an online course site for posting syllabi, readings, and handouts; student tools such as course calendars, message boards, a Notes function for research collection and collation, and journals; teacher tools that allow teachers to track student data; and time-stamping and hosting of uploaded student documents. In addition, offers a robust and customizable ePortfolio hosting and assessment tool. PEDAGOGICAL IMPERATIVES: MAINSTREAMING ePORTFOLIOS THROUGH ePortfolio development represented a watershed moment in by shifting the developers’ focus from the possibilities of XML as a tool to a more complete vision of how XML can support the writing process and the pedagogical needs of a writing program. We began finally to think primarily as compositionists rather than as technical developers, or even just as teachers fascinated by the potential of tools for writing. By 2005, after a series of pilot projects, the First-year Composition Program at the University of Georgia incorporated ePortfolios into all sections of FYC (around 300 sections and 4,000 students a year) as a capstone project replacing the traditional 3-hour, in-class exam at the end of the semester.

: AN ELECTRONIC WRITING SPACE

/

27

The advantages of ePortfolio pedagogy are many. An in-class, handwritten, timed essay does little to assess the goals and activities of a writing course based on multipledraft composition, revision, and peer review. A UGA First-year Composition portfolio, by contrast, emphasizes revision (by asking students to revise essays submitted during the semester for the ePort); showcases processes as well as products (by asking students to demonstrate their skillset at such key activities as revision and peer review); and encourages integrative learning and reflection by asking students to reflect on the portfolio’s contents in a Introductory Reflective Essay. (For a survey of the different functions of ePortfolios, see Yancey, 1996; for the importance of reflection to ePortfolio pedagogy, see Yancey, 1998.) The value added provided by the “e” in ePortfolio is both practical and rhetorical. In practical terms, the electronic production of the portfolio allows students to create and teachers to assess the portfolios remotely; this is particularly important for teachers because each portfolio is graded by two instructors. More broadly for students, both the electronic “publication” of their work and the presence of a second reader and peer reviewers heighten the sense that this writing has a human source and is also designed for an audience more expansive than the course instructor. facilitates portfolio production and rating in several ways. First, students need only to construct through OpenOffice and upload a cover document consisting of a biography and image and then, with the click of a button, indicate which documents they will put in their portfolio and in what order (see Figures 5 and 6). The ease of portfolio

Figure 5. Adding documents to the ePortfolio with one click.

28

/

DESIGNING WEB-BASED APPLICATIONS

Figure 6. The ePortfolio interface: Biography and list of documents.

construction prevents technical issues of Web page construction from taking center stage at this critical juncture in the course. At the same time, through , instructors can enroll in their grading partners’ courses, read the ePorts, and assign them a holistic score; averages their grades, and if they differ by 10 points or more, signals the need for a third reader. There is also a place for instructors to share comments (see Figure 7). From a more general pedagogical perspective, the First-year Composition Electronic Portfolio also helps to restore to the textual surface of student writing the rhetorical power of visual display that tended to recede into the background with the move from jEdit to OpenOffice. Documents tagged directly in jEdit displayed crisply and beautifully, and the ease of using different DTDs allowed students and teachers a great deal of variety in displaying a single document. As XML was relegated to the background in OpenOffice Writer, the tagging became not only invisible, but impossible to monitor. Try as hard as they might, the developers could not control completely the Web display, which became a source of frustration for both writers and readers. The result was that students resorted to producing plain vanilla text or, in order to control their texts and include visual elements without creating textual chaos, resorted to submitting their documents in PDF format. In both cases, their texts began to look more like traditional word-processed documents that might be submitted in hard copy or submitted through a dropbox. The ePortfolio, fortunately, restored to as a writing environment greater opportunities for visual expression and play. Students have come to use ordinary

/

Figure 7. Grading interface for ePortfolios.

: AN ELECTRONIC WRITING SPACE 29

30

/

DESIGNING WEB-BASED APPLICATIONS

features of the OpenOffice word processor, such as cutting and pasting text, color highlighting, and the Comment or Note function to chart the progress of their work in the Revision and Peer Review Exhibits. The Web interface of documents published in the ePortfolio also encourages students to incorporate more visual (and sometimes even auditory) elements into the items submitted for their portfolios. Charlotte Byram, a 2008–2009 Moran ePortfolio Award winner for the UGA First-year Composition Program, inserted a scan of an original cartoon as part of her biography. (Figure 8 is just a small excerpt from the graphic mininovel.) Again, this rhetorical gesture can be made through a word processor without any Web interface, but the sense that the portfolio is being published to at least a limited audience of teachers and class members seems to encourage such creativity. Charlotte was, additionally, a consummate artist, because she managed to control perfectly even the vagrant Web displays of Open Office (http://www.openoffice.org/) in , as this inserted cartoon (Figure 9) in her Introductory Reflective Essay attests (the Dog as Editor has eaten a text inscribed with the word “Cat,” which explains the kitty’s distress). There remains, however, a tension between the need for ease of use with the application that produces text and the rhetorical possibilities for display in the ePortfolio and generally in ; and our latest attempt to mediate between these two imperatives will be discussed later in the chapter. INSTITUTIONAL IMPERATIVES: RESEARCH AND ASSESSMENT WITH As developers have worked continually to improve the application’s friendliness to users while expanding its display possibilities, other activities have been going

Figure 8. ePortfolio: Charlotte Byram’s cartoon biography.

: AN ELECTRONIC WRITING SPACE

/

31

Figure 9. ePort Web display with OpenOffice: Charlotte Byram’s Introductory Reflective Essay.

on behind the scenes, or more precisely, behind the Web interface, deep in the database structure of . Since its beginning, has been quietly gathering essays in its database to create a standing dataset for research that has been established through the University of Georgia’s Institutional Review Board (IRB). When first creating an account, students encounter an IRB-approved consent form and choose either to include or not include their work in the standing dataset that then becomes available for researchers. The size of the database is astounding. Just as a sample, between June 2009 and June 2010, there were added to the database 9,690,429 page views; 201,290 uploaded documents; 5,635 unique users at the University; 4,349 unique graded portfolios; 48,538 journal postings, and 11,839 forum postings. A separate, searchable corpus of First-year Composition essays that had been marked up with XML has also been constructed, again under IRB guidelines, for future research projects. To date, there have been four principal research projects that use the database and are aimed at improving students’ writing performance, and the First-year Composition Program in general. In one, two developers/FYC instructors and two librarians who support First-year Composition classes examined marked student citations and instructor prompts to assess the citation practices of sample students from these two professional perspectives (Barratt, Nielsen, Desmet, & Balthazor, 2009). In a major project conducted under the auspices of the Inter/National Coalition of Electronic Portfolio Research (http://ncepr.org/), the and FYC team studied student revisions through their ePortfolios (see Desmet et al., 2008, 2009). A study of teachers’ error markings, based on the XML templates used for the program Grading

32

/

DESIGNING WEB-BASED APPLICATIONS

Rubric, is ongoing. The size and richness of the database allow all of these projects to be conducted simultaneously at a macroscopic level (through examination of large numbers of students or marked items) and a microscopic level (through close analysis of individual essays and portfolios). Finally, and perhaps most immediately compelling for the First-year Composition Program, is an ongoing assessment of FYC ePortfolios according to the University System of Georgia (n.d.) learning outcomes for Written Communication in General Education. While this piece has had major importance for the university’s recent accreditation review, the project, which was begun in 2008–2009, will be ongoing and will be developed further as the UGA FYC Program participates in Cohort 6 of the Inter/National Coalition of Electronic Portfolio Research. The assessment piece of ePortfolios is simple. Once a portfolio has been graded as part of the regular grading process, each of the two graders is asked to assess how well the portfolio meets six learning outcomes, using a 4-point Likert scale. If instructors need or wish to refresh their memories about the definitions of the six assessment criteria, they can click a button at the lower right-hand side of the screen (“Show Outcomes Descriptions”) to bring up an expanded rubric with fuller descriptions for each category (see Figure 10). The creation of the assessment piece for required a technological threading of the needle; namely, we needed a piece complex enough to collect data on a granular

Figure 10. Assessment rubric for Gen Ed. outcomes, as part of FYC ePortfolio grading.

: AN ELECTRONIC WRITING SPACE

/

33

level, flexible enough to evolve over time to meet the needs of the program and the Office of Institutional Research, and simple and efficient enough for instructors to use. There are four tables in the database that define what is to be assessed and how it is assessed; that is, what the ratings are and what they mean; then there is a second tier of tables that collect the ratings themselves. The data is organized so that any particular set of vectors can be combined for comparison; for example, each learning outcome can be averaged by term or year, class type (e.g., Comp 1 or 2), by individual class, or by student. To date, extracting the data is a manual task, as we discover the most beneficial combinations of data points; we are currently at work on automating and streamlining the extraction so that longitudinal comparisons can become part of the continuing process. NOW: REFINING THE LMS AND DEVELOPMENT OF eDOCS While assessment took up much of the team’s attention in 2009, the most recent phase of development has focused on two areas: streamlining the application’s efficiency as an LMS and experimenting with the use of eDocs instead of an intervening word processor. development has always focused first on writing pedagogy, yet we recognize that smart Web-application design is essential; in short, to be a good writing tool, needs to be easy to use. Two particular areas of development follow this principle: ubiquitous use of AJAX (a Web technology that allows for more sophisticated and intuitive development); and eDocs (documents created and edited completely in the Web application). AJAX will allow for deeper integration of the various tools for writing in (i.e., journaling, brainstorming and research, drafting and revising, peer review and portfolios) primarily by making more like a desktop application. Various tools will remain in the state in which they were left while authors work in other parts of . For example, a daily assignment can be opened and read while working in the online forum without closing the forum; students can look at an assignment without leaving their essays. Instead of being bound by the limits of page redraws in the browser, AJAX allows for small and intuitive changes in the browser display and thus more timely information and interactions. With its newest writing platform, eDocs, is also moving toward the Web-based writing environments now familiar from blogs, wikis, or Google Docs, while also seeking to maintain the stable and clean surface that users who were raised on print culture and academic document design standards (e.g., PDF transformations of word-processed documents or desktop publishing) have come to expect in an educational setting. With the rise of Web applications as a regular part of our students’ lives, we have come to recognize the benefits of working in the browser alone, most notably, ease, efficiency, and portability. To that end, we are creating eDoc tools in that will simplify the work of process writing for students by allowing them to create, edit, revise, mark, and offer peer review all in the application (see Figure 11). ’s eDoc tools include a palette of markup items for various kinds

34

/

DESIGNING WEB-BASED APPLICATIONS

Figure 11. The new, streamlined eDoc interface.

of writing exercises—with one click, students can mark rhetorical elements (ethos, pathos, logos for example) or the parts of a sentence. Similarly, eDocs will allow instructors to respond to student writing in the browser with one-click links to the St. Martin’s Handbook. Finally, eDocs will allow inclusion of multimodal works like video or slide presentations. As they are part of the core, eDocs can easily be added to the portfolio or the zine, which collects together texts from different authors in a class on a similar topic or theme. FUNDING , AN ONGOING PROCESS Over the years, the development cycle has become more systematic. Head developer Ron Balthazor collects requests from teachers and writing programs that use and prioritizes them for each iteration of development, rolling out the latest version in the summer before a new crop of students and teachers arrives each fall; as the user base for and the uses to which it is put change, the application must metamorphose in response. Securing ongoing financial support for development, moreover, is itself a challenge. The first 3 years were funded by the University of Georgia’s Learning Technologies Grants, which offers competitive grants for large-scale technology projects at the university. But the third grant came with the caveat that it would be the last for the project; would have to become self-sufficient. A fortunate event has made this largely possible. Ron Balthazor contracted with the Regents Testing Office to design and run an online rating system for the writing portion of the Georgia Regents’ exam, a systemwide rising junior test in reading and writing. Monies from that project have supported the hiring of several developers each year. Of course, the English Department has continued to support

: AN ELECTRONIC WRITING SPACE

/

35

with hardware and infrastructure. The development team has always been small; usually just Ron (who has other duties as well) and two to four courses worth of Teaching Assistant work (about 20-40 hours a week of development time). The success that we have had with very modest means and manpower is due, we think, to the fact that the development has been spearheaded, and now taken over, by practicing teachers with an interest in rhetoric and composition and digital humanities. Changes that occur in the application are tied directly to the needs and experiences of writing teachers and their students. At this juncture in ’s development, however, the current administrative structure needs to be completely revamped. We have reached the point where it has become unwieldy to host and support other schools who want to use and where the time restrictions placed on using state funds have proved burdensome. For these reasons, with the University of Georgia’s help, the development team is working to set up Calliope, a not-for-profit organization designed to facilitate partnerships with institutions involved in the Project. Through Calliope, we will be able to offer support, hosting, training, and development packages for our institutional partners. CONCLUSION When the original teacher-developers were meeting in the spring of 2002, we wanted and needed a name of our “application.” (Who wants to go home and tell the family that you have spent the day with the “application”?) When won out as our fledgling writing application’s official name, we were not sure whether to privilege the idea of “markup” or “management” as taking priority in the name of our Electronic Markup and Management Application (or Electronic Management and Markup Application). Looking back at the development of as a Web application, we can see also how other changes in the application’s name reflect our changing sense of its pedagogical purpose. First, our front page described as a “suite of applications designed especially for writers”; later, as an “LMS for writing”; the difference is one of emphasis between a modular collection of applications and a unified “system.” Most recently, we have reverted to the simple adverbial phrase, for writing, which nicely removes agency from the machine and returns it to the writer and suggests the hope for seamless connection between ’s function as a writing space and a database. In the end, the different functions of have proved to be not only compatible, but also mutually dependent—as one might expect under the sign of Web 2.0. REFERENCES Barratt, C. C., Nielsen, K., Desmet C., & Balthazor, R. (2009). Collaboration is key: Librarians and composition instructors analyze student research and writing. Portal: Libraries and the Academy, 9(1), 37–56. Desmet, C., Miller, D. C., Griffin, J., Balthazor, R., & Cummings, R. E. (2008). Reflection, revision, and assessment in first-year composition. Journal of General Education, 57(1), 15–30.

36

/

DESIGNING WEB-BASED APPLICATIONS

Desmet, C., Miller, D. C., Griffin, J., Cummings, R., & Balthazor, R. (2009). Re-visioning revision with electronic portfolios in the University of Georgia First-year Composition Program. In D. Cambridge, B. Cambridge, & K. Yancey (Eds.), Electronic portfolios 2.0: Emergent findings and shared questions (pp. 155–163). New York, NY: Stylus Press. Harold, E. R., & Means, W. S. (2001). XML in a nutshell: A desktop quick reference. Cambridge, MA: O’Reilly. Inman, J. A. (2004). Computers and writing: The cyborg era. Mahwah, NJ: Lawrence Erlbaum Associates. Lanham, R. A. (1993). The electronic word: Democracy, technology, and the arts. Chicago, IL: University of Chicago Press. McCarty, W. (2003, June). Depth, markup, and modelling. Paper delivered at the ACH/ALLC 2003 Conference, Athens, GA. Retrieved November 27, 2011, from http://journals.sfu.ca/ chwp/index.php/chwp/article/viewArticle/A.25/53 University System of Georgia. (n.d.). General education learning goals [Online]. Retrieved from http://www.usg.edu/academic_affairs_handbook/section 2/handbook/2.4_core_curriculum/ Yancey, K. (1996). The electronic portfolio: Shifting paradigms. Computers and Composition, 13, 259–262. Yancey, K. (1998). Reflection in the writing classroom. Logan, UT: Utah State University Press.

http://dx.doi.org/10.2190/DWBC3

CHAPTER 3

Redevelop, Redesign, and Refine: Expanding the Functionality and Scope of TTOPIC into Raider Writer Robert Hudson and Susan M. Lang

For over 2 decades, scholars and practitioners alike in first-year composition have asked the question, “How have/will computers change the way in which we teach writing?” One of the most valuable answers we’d suggest, based on our experience with our particular software, is that they have changed the way in which we can do research about the teaching of writing. Our contribution will look at what has essentially been a redesign and rebuild of software originally developed in the 1990s. The purpose of our redesign and rebuild was essentially twofold: first, to create a stable and dependable working environment for students and instructors, and second, to take advantage of the research opportunities that existed but were not accessible in the previous software or in any commercial product. While our project (Raider Writer) isn’t complete yet, we are wrapping up our second phase of transition while beginning our third phase of migration into our new platform. THE ORIGINAL APPLICATION Raider replaced a system called TTOPIC, a Web application built by Dr. Fred Kemp at Texas Tech and used by the first-year writing program as a course management system. The earliest versions of TTOPIC contained common course management software features—students could access syllabi and schedules, turn in and retrieve graded documents, and see their grades; instructors could insert and grade assignments, keep a grade book (including attendance), and review student writing. TTOPIC also contained a function by which instructors could have students peer-critique each other’s work from within the application. In 2001, when the first-year writing program began experimenting with a distributed grading pedagogy, in which all assignments were pooled into a single queue to be graded by all course instructors, TTOPIC was expanded to enable that pedagogy. From 2002 to 2006, additional features were layered 37

38

/

DESIGNING WEB-BASED APPLICATIONS

onto the site, but by mid-2006, it was clear that the ability to add to or restructure the application was no longer possible without compromising the entire application. Since 2007, the authors have engaged in the redesign, redevelopment, and replacement of TTOPIC. By 2007, TTOPIC was outdated in functionality and contained many potential technical and security concerns. It didn’t support CSS, so all styles were hardcoded as attributes on particular HTML tags, which made maintenance difficult. Many pages were styled completely different from others based on when the pages were built. Outdated constructs like HTML frames were used, which complicated site maintenance and reduced accessibility. Additionally, the system was created with Classic ASP, largely regarded as a scripting language with very limited scaling, error handling, and debugging abilities. Additionally, all SQL in the application was inline with pages. Aside from obvious injection issues, this made the site less maintainable without a central repository for data-access routines. In its earlier iterations, TTOPIC focused primarily on the collection and grading of student writing; there were few ways, most very rudimentary, to examine the data collected, and what windows into the data existed were quite limited in what they could show users. Some of the reasons for these problems were related to the fact that TTOPIC was built incrementally by adding ASP script pages, one after another, to a growing well of other scripts. These scripts passed variables (easily modified on the URL line) and performed direct reads and writes to the database. The code was very loose, fragile, and more suited to be a demonstration/proof of concept than a public-facing enterprise system. Over time, as features were added, some pages were changed and many others were abandoned but remained on the Web site. As a new feature was added, old code was retired or in many cases commented out within active files, bloating them and making them difficult to understand. Thus, by 2006, the system contained over 2,800 pages that housed thousands of ASP 3.0 scripts that used inline SQL. Pages had to be edited by the now-deprecated Visual Interdev, which locked developers into the cumbersome update method called WebDav (Front Page Server Extensions), which was later found to be insecure. Further, changes could only be enacted within the Interdev environment, whose widgets and wizards further complicated the code. Since TTOPIC was based on a scripting language, it didn’t run efficiently within the Web environment. Scripts weren’t compiled, and as such, didn’t take advantage of the speed that modern development environments produce. Nor could scripting meet enterprise-caliber architecture requirements; most enterprise systems use some kind of middleware, or business layer, to negotiate with the database and provide information to the user interface. TTOPIC connected directly to the database and thus couldn’t take advantage of the benefits of distributing application logic across balanced tiers. Additionally, scaling the system to add more courses or departments was problematic. Since Classic ASP can’t be load-balanced while preserving user sessions, all traffic must route through a single server and incur a bottleneck. Modern frameworks like .NET can be scaled across multiple boxes, allowing the application to grow beyond its current capacity. Aside from growth, the application could be built to survive a server crash; if one Web server failed, the user session and work would seamlessly transfer to another. ASP was poorly suited for error handling and did not permit debugging, as a component-based system developed in a robust

REDEVELOP, REDESIGN, AND REFINE

/

39

programming language (like C # or VB.NET) provides. Error handling and fault detection are rudimentary; it’s virtually impossible to catch errors and fail gracefully to return the system to a usable state. Consequently, the system required constant adjustment to run properly; it couldn’t operate without continuous intervention by the developer, in setup, tear down, and ongoing activities. Setting up the system for a new semester easily took 20–25 hours of time, in which no fewer than 30 script pages had to be manually modified, and new tables had to be created. Tearing down the system at the end of each semester was similarly tedious and required not only a reverse of the setup process but also manipulation of table data to ensure grades were correct for students, particularly that late penalties were applied properly. Between those periods, operations needed to be tweaked frequently. Grading loads had to be manipulated to balance out available work and to ensure periodic dates and shares were appropriate for the state of the system (peak and nonpeak load times). Due dates were locked to a rigid cycle and could not be individually adjusted in the case of missed classes or changes to course schedules. Consequently, late penalties had to be changed directly in the database for each of many affected students. Finally, if a user’s session was interrupted or abandoned, database records could be left in a partial/hung state. There was no risk mitigation strategy. Since TTOPIC was built using what some term “cowboy coding” or “bolt on” principles, where code was developed live and put directly into production, the timeline for development could be very flexible and responsive. This flexibility was not without significant drawbacks. For example, the lack of consistent design in TTOPIC was evident: each new iteration of features had a different appearance, and these new features were often simply added to the production site (the only site in existence), and users had to deal with the changes immediately. Lack of a comprehensive development methodology could also introduce errors and maintenance issues in other parts of the site, and the lack of a consistent set of code standards meant that the system wasn’t maintainable by other people. This combination of a single developer and lack of consistent development and documentation practices made the system take longer and longer to fix, maintain, and add to the more code was introduced. Most troubling was the fact that if the developer became ill or unavailable, no other developers could quickly step in. The composition program would collapse; it was dependent on TTOPIC to manage thousands of students along with nearly 100 graders and classroom instructors. THE ORIGINAL DATABASE The data source, SQL Server 2000, was not in much better shape. It was underused as simply a storage repository and wasn’t leveraged as a programming environment. SQL Server provides error handling, encapsulated, reusable stored procedures, and functions that simplify the coding process and form the foundation for secure data access. In addition to neglecting SQL constructs, TTOPIC relied on a primitive data model that was denormalized and suffered from both performance issues and anomalies. Student records couldn’t exist by themselves; students were represented as enrollment instances. Remove an enrollment, a student was entirely removed. Students

40

/

DESIGNING WEB-BASED APPLICATIONS

with multiple enrollments (one in each of our two composition courses, ENGL 1301 and ENGL 1302, for example) had multiple records with no common ID numbers; it was difficult to identify the same student across the system, particularly if the e-mail addresses did not match. No foreign keys or dependencies were integrated into the database; any relationships were enforced by the application. While there were keys from particular tables stored in other tables, without explicit constraints, the only way to understand the database was to read the entire codebase while walking through the system. Furthermore, the massive database had no indexes and only rudimentary usage monitoring and profiling. Large tables were split into separate, semester-based tables for performance instead of indexing them. This made reporting difficult and dynamic SQL necessary. Each semester, new tables had to be created with new names, and the names had to be changed within the source code to match. DEALING WITH TECHNOLOGICAL AND PEDAGOGICAL RIGIDITY While TTOPIC’s construction would suggest that it was an experimental interface, it was simultaneously extraordinarily rigid and fragile. Any change to such a system could potentially cause destabilization of the system. Since there was only one active copy (no development server), one could only take so many risks without bringing down the live system. This rigidity meant that few, if any, modifications to the initial pedagogy, assignment structure, or grading interface could be made without seriously destabilizing and jeopardizing the system. This also meant that any research into instruction had ground to a halt. For example, while the idea to work with smaller subgroups of instructors had been recommended for a number of years, the existing TTOPIC code could not support such a modification without substantial redesign of both application and databases. When we took over the programming responsibilities for the first-year writing program, we (the developer and program director) knew that we first had to deal with these fundamental issues, or else we would remain locked into the crisis response role of our predecessor. The first task was to learn the system from the inside out. We documented all the business processes, added comments to code, and renamed singleletter variables to meaningful names. This made the code maintainable by the new developer, readable for the composition director, and accessible to another developer should the need arise. Once we completed this task, we began removing unused pages, and from 2007 to 2009, reduced the number of active pages from 2,802 files to 290 essential files. Every one of the remaining active pages had to be rewritten in order to reduce the amount of code to an efficient, manageable size. This work, along with input from our IT division, revealed another serious issue—site security. Security Problems and Fixes As an experimental system, TTOPIC was not developed or implemented with security in mind. Its early iterations contained several layers of vulnerability. First, the system was highly vulnerable to SQL injection. Second, the system did not encrypt traffic; every variable or piece of data was available to anyone on the network

REDEVELOP, REDESIGN, AND REFINE

/

41

monitoring traffic with applications such as WireShark. Third, variables that identified the users, classes, and assignments were implemented as sequential integers; anyone could simply add or subtract from the number to “guess” at another person’s ID and alter data for that person. Finally, the system allowed students to self-identify and self-register. While extremely convenient, there was no validation to ensure that they were who they claimed to be. The SQL injection vulnerability was by far the most pressing issue. SQL injection attacks modify querystring or posted form variables (which can be done from any Web browser) to manipulate data and gain control of the database or database server (depending on the security configuration). Virtually all of the 2,800 script pages in the system patched together SQL statements using the plain, unvalidated version of the variable sent across the address line or posted from forms. Although the university routinely scanned the department servers for security vulnerabilities and had been doing so for some time, these enterprise-level scans missed 95% of TTOPIC’s vulnerable pages. When, in 2008, we were alerted to some older security gaps (from 2004 or so), we performed our own code analysis and scans using the Microsoft Source Code Analyzer for SQL Injection tool () and found issues in virtually all of the 290 pages from the original TTOPIC that were still in use. We madly scrambled to fix the affected pages, one by one, by using parameterized stored procedures and input validation. Doing so ensured that things like student IDs were numeric and not cobbled together database commands to inflict ill upon our system. In the process, we combined and reduced the lines of code in those 290 pages by 35%. Less code meant fewer security vulnerabilities. Even though we were now validating incoming data for the proper format, we weren’t preventing people from modifying that data within the format to hack our system. People could still “guess” an identifier and gain access to data outside of their domains. We solved this problem by encrypting data (via Chilkat components) across the command line and through form posts. While it was easy for someone to guess numbers, it was highly unlikely that they could translate those numbers into a 14-digit encryption code. To further fortify the system, we wrote code to check explicitly if the logged-in users had rights to data that they were accessing. A student who attempted to view someone else’s work, for example, would be stopped at the gate as the system compared his identification with the owner of the work in the system. Outside of these programming practices, we had to address the network layer of our application. TTOPIC didn’t use SSL; all application data and traffic traveled in plain text from the English Department servers, the Internet home PCs, campus networks, coffee shops, and Internet cafés. Each one of these points could be accessed by any number of free network scanning tools. Someone could easily “sniff” a username and password, or an encrypted key for a student’s work and plug that data back into their instance of the application to add, update, or remove data. This was simple enough to fix; we purchased SSL certificates and installed them on our Web server for our particular application. For less than $1,000/year we now receive premium 128-bit encryption, which is sufficient for securing student and grade data. Note that we don’t store social security number or other private data, but grades are considered sensitive, so we do our best to protect them.

42

/

DESIGNING WEB-BASED APPLICATIONS

At the topmost level of security were business practices; TTOPIC permitted students to self-enroll by simply identifying themselves with a first name, last name, and e-mail address. They chose the section in which they were enrolled and were then “officially” enrolled in that course. They weren’t required to use their university e-mail addresses or any other university information; as long as their names appeared on the instructor’s roster, they were valid enrollments. This practice opened the system up to potential fraud; anyone could impersonate a student and do that student’s work. We addressed this particular concern in two ways. First, we enrolled students ourselves based on the roster. Second, we required students to use official university e-mail addresses. In the next couple of years, we will integrate our university’s single sign-on solution with our application. One final note on security: We have a somewhat unique position at Texas Tech in that our department not only hosts its own Web servers but also manages several other Web applications and opens up the servers for application development. University oversight comes in the form of application guidelines and requirements and regular, routine security scans to make sure obvious vulnerabilities didn’t compromise our department or the campus network. Additionally, when serious issues were found in the TTOPIC pages in 2008, we met with the university IT security and application development team, who were able to assist in fixing some of our security issues and leveraging standard libraries that the university used for secure authentication and authorization. This partnership works quite well, and the relationship, unlike many between departments and university IT, is not adversarial, but cooperative. We continue to work with these application developers as we need advice or require updates to the standard university libraries. THE REDEVELOPMENT Once we stabilized these security issues, we were able to return to our initial tasks of redeveloping the system to provide more technological and pedagogical flexibility for research as well as to create substantial administrative and research interfaces. Before we could focus on features, though, we needed to reconceive the fundamental application at a basic design and coding level. Page Layout and Design Since TTOPIC didn’t use CSS for display or layout, formatting was applied directly to HTML elements. Any style change across a page or set of pages had to be applied to individual lines of code on each page. Page formatting wasn’t consistent; look and feel changed between pages and wasn’t consistently or thematically applied. To resolve this, we developed CSS files that inherited the university’s branding and added our own particular interface needs, like table formats. In addition to using style sheets to control the look of form, text, and table elements, we also used CSS DIVs to lay out entire pages. TTOPIC exclusively used tables, which are semantically incorrect, to position items on a page. TTOPIC also employed HTML Frames liberally for critical system areas like attendance and grading. Frames complicated the site maintenance and made things like error handling impossible, as part of a page might fail and the other

REDEVELOP, REDESIGN, AND REFINE

/

43

frame might not. To resolve this issue, we used single pages with dynamically loaded content to account for what formerly were two or more files embedded in frames. We also employed user controls in our administrative application (written in .NET) to position content and hook data without relying on outdated HTML constructs. We’ll continue this practice going forward. Stabilization and Migration After better understanding the systemic issues, we created a plan for stabilizing TTOPIC (into the hybrid system called Raider Writer) until we could create an enterprisebased application. Stabilizing TTOPIC involved recoding significant portions so that the system could run without constant intervention. As previously described, we secured the system, reduced the code base, and made reusable modules to avoid redundancy and rework. We also made database-stored procedures that could be used on the new platform. Additionally, many system processes, like data loads, alerts, and initial setup processes, were tangled among the other application pages. We extracted these out and created distinct database procedures and programs that ran these alerts and processes separate from the working application. We’ll migrate these processes into our target system, an ASP.NET application (Raider Writer .NET). We began the migration to RW.Net in steps. We wrote discrete modules, like one to calculate grades nightly, in SQL Server Integration Services and C#; these can be used with our current application and continue to work within our new enterprise application in .NET. We also wrote administrative modules in ASP.NET to set up the system for new semesters, edit syllabi and schedules, modify groups, and report grades. These modules can be extended and expanded until the entire application is in ASP.NET. We’ll institute the cutover in phases, beginning with administration, followed by student submission of papers, followed by classroom management, followed by grading. This is the most complex area as it wraps up our distinct business processes and multiple-grader queueing. See Table 1 for a technological summary for the phases of the application, from current to final, indicating the migration from script languages to enterprise environments. Error Handling As we move to .NET, we are fortunate to have several error-handling options not available in classic ASP. Our current .NET application uses Google’s free ELMAH (Error Logging Modules and Handlers for ASP.NET), which logs and notifies us of unhandled errors. We’re also using Log4Net in conjunction with the robust error-handling blocks of C#. Now, we can “fail gracefully,” know where we failed, and understand what caused each error. We can also clean up after such failures and restore the system to a workable state. Making Effective Database Design Choices All database access is done from procedures in the database, not from individual pages with direct SQL. All data access in the Raider Writer .NET application is

44

/

DESIGNING WEB-BASED APPLICATIONS

Table 1. Migration from Script Languages to Enterprise Environment

Current Platform (Raider Writer)

Transitional Platform (Raider Writer/ Raider Writer .NET Administrative)

Destination Platform (Raider Writer .NET, complete)

Development Platform

Classic ASP scripts securely calling stored procedures and functions

Classic ASP scripts maintained; new development done primarily in ASP.NET/C#. Nightly jobs written in C#.

ASP.NET/C# for entire system

Database

SQL Server 2005

SQL Server 2005 SQL Server Integration Services

SQL Server 2008 SQL Server Integration Services

Security

Chilkat Crypt COM component

ASP.NET native encription. Classic ASP using Chilkat Crypt.

ASP.NET/C# encryption

Reporting

HTML reports

HTML reports Generated Excel and PDF

SQL Server 2008 Reporting Services

performed via a data access layer. The database now stores the procedures for any kind of site maintenance (run from inside the DB or within the application), reports, and application code. We now reuse procedures for viewing, adding, and updating data. For example, our procedure for reporting grades for an entire class is also reused for reporting individual grades. Our procedures for adding roles (instructor, administrator, student) are used in several places for adding in a batch or adding individually. Finally, we established constraints in the database to prevent data anomalies—like duplicate students or writing records—and spent hundreds of hours retrofitting and cleaning up past data that was not validated. TTOPIC and Raider Writer have massive tables, with hundreds of thousands of rows created across all tables each semester. Queries against that data were slow and often “timed out” the application. To solve this problem, TTOPIC’s developer created tables for each new semester so that they were smaller and could be accessed more quickly. A better solution is simply to use indexes to find data quickly based on the types of queries required. We analyzed the queries that the application was using, determined appropriate indexes, and eliminated the need to separate tables by semester. This made reporting and application maintenance simple since table names didn’t change across semesters.

REDEVELOP, REDESIGN, AND REFINE

/

45

Build Scalable, Growth-Oriented Systems Scalability means maintaining consistent system performance as traffic increases, the system data grows, or new users are added. With 3,000 users and the potential for many more as the program expanded or the system grew to accommodate other classes, the classic ASP solution was straining to keep up. Scripts timed out, the database required constant adjustment to meet the demand, and assignment turn-in times created “hot spots” in the database that became congested and often prevented students from turning in work on time. In contrast, ASP.NET provides the speed and expandability by promoting component-based architecture across the very fast .NET framework. Component-based architecture separates an application into tiers, each of which focuses on a particular aspect of the application and reduces the load on the other tiers. In our design, these tiers consist of a business layer, which handles business processes; a user interface layer, which manages the front end and consumes business objects; and a data layer, which performs all data access and hands that data off to the business layer. In Raider, the business tier focuses on managing processes like assignment queuing; running the reporting, from administrative to classroom level; and ensuring the proper flow of data between SQL Server and the Web application. With our previous twotiered architecture, the Web server managed the entire load and did so in a sequential fashion. This one-at-a-time process limitation is overcome by the .NET framework’s threading, which allows multiple processes or requests to be served at once, instead of requests being queued and ultimately timing out under heavy load. Balancing that load, or “load balancing,” a proven method of scaling an application, means that instead of all traffic being routed through one server, a load-balanced cluster allows the servers to share the work. DEVELOPMENT APPROACH New Procedures To maintain the existing system, build a new system, and ensure continuity of business in the event of a staff change or other failure, we needed to create a solid development process that included documentation, proactive design, and agile methods. This effort was substantial. TTOPIC had created significant “technical debt,” benefitting from rapid development at the cost (or debt) of maintainability, security, and continuity. Since the initial development was done as essentially an overload by a full-time faculty member with no formal training in software development, the nature of the position and the time constraints prevented the system from being built with standards or by a methodical process. All development was reactive and didn’t reflect any consistent process, documented or otherwise. By the time the new team inherited the system, the “payments” were overdue. We had to invest a significant amount of time to “pay back” this debt by identifying what we had, determining what to do to keep the system working, and planning to move forward into the future without facing the same consequences.

46

/

DESIGNING WEB-BASED APPLICATIONS

As Rob, a trained developer and architect, inherited the project, we created a one-man development shop that was agile, consistent, and redundant. Although we had a single developer, we operated as a larger, though somewhat modified, development shop. We added development and test environments (programming and database) to test changes before they were deployed to production; in the past, TTOPIC changes were always made directly to production code. We also created a development process that involved other departmental staff. While Rob was the primary programmer, the FYC program administrator performed moderately difficult database queries and updated some content and program code on the Web pages. She and other instructors became testers. These roles participated in our modified agile/extreme programming model. We operate with small, regular releases, sometimes a page at a time. Some releases, as to major features, can’t be helped as they impact the entire system. For example, our rewrite of the syllabus and assignment functions spanned instructor pages, student pages, and grader pages. The time frame for most of our changes is 1–2 weeks; we release at various times depending on the turn-in schedules for assignments. The Process • We begin this process with a brief narrative, or “user story,” which “describes functionality from the customer (user) perspective” and represents no more than “2-3 person weeks of effort” (Vaibhav, 2007). For example, “Susan wants to add discrete grading criteria to draft assignments that allow her to rank particular aspects like ‘Sources and Evidence’ on a six-point scale. When a grader, ‘Bill,’ opens a document, he’ll be able to choose from the items on the scale as they apply to the document he’s grading.” • Rob creates a prototype using Balsamiq Mockups, an inexpensive ($79/license at the time of this writing) tool for creating quick software mockups. The prototype takes no more than an hour or two to create and explains how the screen might work. Figure 1 was created for this feature and was created in Balsamiq. Note that the screen appears hand-drawn; this reinforces the idea that this is a prototype, not a finished screen, and that it is malleable. • Rob, Susan, and other stakeholders discuss this prototype and make any changes. • Rob then determines the technical requirements/feasibility and rapidly develops the feature in the development environment. • The stakeholders review the screen and test the features inherent in the story. Once the screen is approved, it’s moved into the test environment and ultimately pushed into production. RESEARCH IMPLICATIONS Stabilizing and expanding the capabilities of our system was the initial exigency, but a longer-term goal was to create a viable platform to enable research into firstyear student writing and first-year composition instruction. To date, most commercial course management systems provide very limited views and access to student writing, grades, and associated information, and most of that information is available at the individual class/section level rather than the program level. Obtaining more

REDEVELOP, REDESIGN, AND REFINE

/

47

Figure 1. Prototype using Balsamiq Mockups.

comprehensive information from these applications in any format, let alone one suitable for detailed qualitative and quantitative analysis, is difficult if not impossible, as these applications are not first and foremost designed as research tools, nor are the companies that provide them in the business of supplying this data back to their customers in formats to promote additional analysis. By redesigning our database structures to facilitate data extraction at variously scalable levels—from a single student in a course to all students for the past decade— we can support substantial research projects by faculty or graduate students. A sampling of projects currently underway includes • A postmortem analysis of a rolling admissions distance version of both courses. This instance of the courses was phased out in January 2010 in favor of a semester-based version of the courses, but the data from the rolling admissions had never been examined in detail. The initial phase of the analysis examines student grades, completion rates, and correlations between completion times and performance. This data will be used to provide a baseline comparison to the new

48

/

DESIGNING WEB-BASED APPLICATIONS

semester-based online delivery. Subsequent phases will examine the writing produced by the distance students and compare it to that produced by onsite students taking the course with the same syllabi and materials. • Exploratory analysis of instructor commentary on student writing. The use of graduate students with minimal or no prior teaching experience as composition instructors demands that administrators learn more about how to train new instructors to comment effectively on student writing. We can extract a sampling of one or more instructors’ commentary at any point in a semester or over several semesters, focus on a single type of assignment, or on a particular grade range within an assignment to see the typical commentary associated with that grade. • Analysis of student performance and retention. We can extract average grades on each assignment turned in for a particular class or the entire program, as well as the number of students turning in each assignment, in order to determine if there are particular assignments that seem difficult for students. Additionally, we can identify whether there exists a point in a semester where students are likely to withdraw from the course (officially or not) and determine if there are adjustments we can make to the curriculum to improve learning and retention. Additionally, in a culture of assessment, our ability to access and analyze data throughout and after each semester enables us to provide essential information to our Core Curriculum Committee to support ongoing assessment efforts. The windows into the instructional processes that the application provides have, since its early iterations, garnered the support of our administration at the college and university level. The restructuring of the database so as to facilitate information retrieval and analysis has made the first-year writing program one that is considered a model on campus for general education assessment practices, and we’ve presented elements of our work to faculty and administrators on campus and at regional and national conferences. CONCLUSIONS The past 3½ years of work have enabled the creation of a program both technically and pedagogically flexible and scalable. We can handle a large volume of students and courses while at the same time providing directed feedback in small groups that are connected to the classrooms and particular instructor methods for teaching. We can apply a single syllabus and pedagogy to all courses or create individual syllabi for particular sections. We can track nearly every aspect of the system to identify problem areas that include • trends in student grades in particular courses or sections to identify problem areas in instruction • evaluators who are providing minimal/inadequate/inappropriate commentary to students

REDEVELOP, REDESIGN, AND REFINE

/

49

• classroom instructors who are changing grades capriciously or to compensate for conditions that administrators should address (e.g., a particular evaluator doesn’t understand an assignment caveat given in the classroom) • plagiarism or other academic dishonesty (using a system we licensed from developer Tim McDonald) Additionally, we have an 8-year repository of data generated by both applications, TTOPIC and Raider Writer, from which to derive trends in student writing, writing instruction, and evaluation and assessment practices. This dataset has been scrubbed and normalized to enable access for research so that we can close the loop on our practices. Most significant, perhaps, to those who would like to build their own applications, is that we have set the groundwork for stable, ongoing development by hiring a full-time programmer/analyst and generating an application that can be understood by and taken over by others, should the need arise. REFERENCE Vaibhav (2007, October 16). Six Features of a Good User Story—INVEST Model. Agile Software Development. Retrieved from http://agilesoftwaredevelopment.com/blog/vaibhav/ good-user-story-invest

http://dx.doi.org/10.2190/DWBC4

CHAPTER 4

The Role of Metaphor in the Development of an Instructional Writing Environment Mike Palmquist

In this chapter, I discuss the development, current status, and plans for Writing@CSU (http://writing.colostate.edu), an educational Web site that supports the learning and teaching of writing (see Figure 1). Visitors to the site can view advice on writing, speaking, and conducting research; read guides about effective instructional strategies; and practice various composing processes. Visitors who create a free account in the site’s instructional writing environment, the Writing Studio, can also access drafting and project management tools, source management tools, a course management system, and publication and collaboration tools that allow them to create ePortfolios, blogs, and wikis. At the beginning of 2010, the site offered more than 35,000 pages of instructional content and had recorded more than 5 million visits during the previous year. During that period, more than 25,000 writers from more than 1,000 academic institutions worldwide logged into the Writing Studio an average of 42 times. During the 2 years prior to 2010, more than 900 instructors from more than 100 academic institutions created class pages for more than 2,000 classes. ORIGINS OF WRITING@CSU The origins of the Writing@CSU site can be traced to work carried out in the late 1980s. As a graduate student at Carnegie Mellon University, I worked with Chris Neuwirth and was able to observe and, in some cases, participate in her work on the development and assessment of a number of network-based writing tools, among them Comment, CECETalk, Notes, and the Prep Editor (see Neuwirth, Kaufer, Chandook, & Morris, 1990; Neuwirth, Kaufer, Chimera, & Gillespie, 1987; Neuwirth, Keim, & Gillespie, 1988; Neuwirth, Palmquist, & Gillespie, 1988; Neuwirth, Palmquist, & Hajduk, 1990). I also learned of plans by Neuwirth and Richard Young to develop what 51

52

/

DESIGNING WEB-BASED APPLICATIONS

Figure 1. The Writing@CSU Home Page.

would have been, had it been funded, the first campuswide, network-based, collaborative system designed to provide feedback to writers. Neuwirth and Young’s vision of a distributed system for seeking and offering feedback on work in progress to members of the campus community provided what was essentially the blueprint for a key component of what would later be known as OWLs (Online Writing Labs). At about the same time, at Colorado State University, Dawn Rodrigues and Kate Kiefer had been developing the Electronic Writing Service, which used the campus computer networks to deliver instructional materials and analyses of student drafts (Rodrigues & Kiefer, 1993; Rodrigues, Kiefer, & McPherson, 1990). The goal of the project was to create an environment where “students can ‘talk’ in writing to one another or to a tutor, a place where they will also be able to locate appropriate writing software to help them with a writing assignment in any of their courses” (Rodrigues & Kiefer, 1993, p. 223). The project went online in 1989 and was in use for nearly 2 years. In 1990, shortly after I joined the faculty at Colorado State, I began a collaboration with Rodrigues, Kiefer, and Don Zimmerman that would lead, in 1992, to a 5-year grant from the Colorado Commission on Higher Education (CCHE) Programs of Excellence competition. The grant allowed us to assemble a larger team and spend a year studying the uses of writing in engineering and composition courses on our campus, conducting a national study of professional engineers’ perceptions about the role of writing in their professional lives, and studying the roles and uses of writing in a leading software engineering company. In the spring of 1993, we held a retreat to review results of the studies and plan the development of a network-supported

THE ROLE OF METAPHOR /

53

WAC program. At the retreat, we decided to adopt an “integrated approach to WAC” (Palmquist, 2000; Palmquist, Kiefer, & Zimmerman, 1998; Palmquist et al., 1995) that relied both on traditional WAC strategies for faculty development and on direct outreach to students through a reconceptualized campus writing center and an “online writing center.” In the summer of 1993, work began on a network-based application that allowed students to contact instructors and writing center tutors via electronic mail, submit drafts for review by writing center tutors, view instructional materials about writing in the disciplines, and work on interactive writing tutorials. Developed in Asymetrix Multimedia Toolbook, the Online Writing Center would eventually be available on roughly 400 computers across campus (see Figures 2–4). In 1996, the Online Writing Center moved to the Web (see Figure 5). Although the limitations of the Web at this early stage in its development required us to sacrifice some of the interactivity afforded by Multimedia Toolbook, it seemed clear that the Web would develop greater capability over time and that we would benefit by shifting to browser-based delivery. By the late 1990s, our Online Writing Center Web site had grown to more than 65,000 pages, nearly all of which were in the form of static content associated with our instructional materials and class pages. Instructional material included “writing guides” that served as online textbooks, “writing activities” that allowed writers to complete exercises online, “teaching guides” that offered advice to writing instructors, and a large collection of course materials drawn from instructors in our composition program. It also provided an extensive set of links to related sites on the Web and allowed writers to communicate with and submit drafts for feedback from tutors in our campus writing center. In addition, we had entered into a partnership with the Syllabase group at Utah State University that allowed us to use their course management system (Buchanan, 2000).

Figure 2. From 1993 to 1996, the Online Writing Center was available as a campus network application, running on Windows 3.x.

54

/

DESIGNING WEB-BASED APPLICATIONS

Figure 3. Guides provided instruction on a range of writing processes and genres.

Figure 4. Writers could send drafts via e-mail to instructors, other writers, and writing center tutors.

THE ROLE OF METAPHOR /

55

Figure 5. In 1996, the Online Writing Center moved to the Web.

TAKING A NEW DIRECTION Sometime in the late 1990s, well into the development of our online writing center Web site, I realized that we’d taken a wrong turn. Although the site had become the largest and one of the most widely used sites for writers and writing teachers, something about it seemed wrong. As one of my graduate professors, Richard Young, would say (channeling Dewey), I was experiencing a “felt difficulty.” Despite our progress in creating what Lasarenko (1996) called a “full service OWL,” it felt as though the extensive amount of work my colleagues and I had put into the project had done little to improve the learning and teaching experiences of the students and instructors using our site. Our writing guides and teaching guides had become widely used, but the students who were using them would have gained nearly as much from print documents. Our writing activities were being assigned to students at key points in their composing processes, but aside from easy access via the Web and the convenience of online submission they offered an experience similar to print versions of the activities. In effect, and very much as Eric Hobson (1998) and Eric Crump (2000) had noted in their critiques of the uses of technology in writing centers and OWLs, our Web site seemed to do little more than extend a pedagogy developed for a print-based world. Addressing my “felt difficulty” involved extensive discussions with several colleagues, many of whom had worked on the project since its inception. My conversations with Kate Kiefer, who had played a central role in developing our online writing

56

/

DESIGNING WEB-BASED APPLICATIONS

center and worked with me on a year-long study of the use of computers to support writing instruction (Palmquist, Kiefer, Hartvigsen, & Godlew, 1998), were particularly productive and led to a clearer definition of the problem. Our study had compared learning and teaching in pairs of sections of our introductory composition course. Each pair of sections was taught by the same instructors but in different classroom settings: a traditional classroom and a computer-supported classroom. Our analysis led us to conclude that important differences existed across the two settings. Instructors indicated that they had approached the two settings differently, adopting different attitudes toward teaching and learning, control of the classroom, and expectations about students’ responsibility for their own learning. Students in computer-supported classrooms had shown greater growth in confidence about their writing, seeing writing as a more “natural” part of class, and revised more frequently than students in traditional classrooms. Most significantly, our findings led us to conclude that instruction in the two classroom settings differed in the underlying conception of what was being taught. Instruction in computer-supported classrooms seemed to resemble the kind of engaged and focused treatment of writing as activity that could be found in the treatment of art in an art studio course; while the instruction in traditional classrooms seemed to more closely approximate the treatment of writing as an object of study that could be found for art in an art history course. That is, the metaphor informing instruction in the two classroom settings seemed to differ in important ways (Palmquist, 2006). The role of metaphor provided an interpretive frame for considering the work we had done—and hoped to do—with our online writing center. If the metaphors of writing as activity versus writing as object of study had in fact shaped teaching and learning in the classrooms we had studied, then the metaphor shaping our understanding of the Web site we were creating had most likely influenced our decisions about how to design the site. Eventually, I concluded that the metaphor guiding work on our Web site was the single biggest contributor to the problem I was attempting to define. The metaphor of “online writing center” had led us to create a set of resources that supported writing instruction as it was traditionally conceived of in a writing center and, by extension, in writing classes run on a traditional, 20th-century instructional model. We had created instructional texts, tools for exchanging and commenting on student drafts, and so on. We had taken as a given the value of replicating what happened in instructional settings and learning contexts that were already well-established. What we had not done was ask the fundamental question of whether we were using the best metaphor. I found what I now believe is a more appropriate metaphor by considering the role of technology in writing instruction. Since entering the field in the mid-1980s, I had been told, sometimes with great fervor, that technology should not drive course goals (Kinkead & Ugan, 1983). I had long accepted this argument, in part because I had seen what could go wrong when classes were designed to take advantage of a new technology without a careful consideration of overall course goals. Eventually, however, I came to question the fundamental assumption underlying this approach to teaching in technologically rich environments—that there is no interaction between the development of new technologies and the work of writers, writing students, and

THE ROLE OF METAPHOR /

57

writing teachers—that, in fact, technology is simply an “add-on” that might be used to enhance a preexisting notion of a writing course. In fact, information technology has had a profound impact on what it means to write and be a writer. Any course, as a result, that treats technology as simply a way of enacting a set of pedagogical goals established sometime in the 19th or 20th century is unlikely to address the fundamental changes that have occurred over the past few decades in how we compose, review and revise, and reach our audiences (see Figure 6). This line of thinking led me to a decision to focus not on supporting our writing center or our writing classes, but rather on supporting student writers. I found myself asking, “What role can and should technology play in supporting the learning and teaching of writing?” My answer was that we should develop a learning environment for student writers, one that would allow them to collect and manage information; to plan, compose, and revise; to access instructional resources; and to share and seek feedback from others on their work. In 1999, we began work on what would become the Writing@CSU Web site and its Writing Studio. (For a review of early work in the development of computer-based writing environments and a discussion of the importance of metaphor in their design, see Palmquist, 2006.) Our first efforts to develop the Writing Studio focused on two concepts: tools for writers and “rooms” within the Studio focusing on specific writing activities. Our initial efforts to develop tools targeted drafting and project-management tools as well as a bibliography tool; our first effort to create a room focused on informative writing. Mackenzie Fogelson, an MA student in English at Colorado State University, designed and created content for the informative writing room and worked closely with Luann Barnes, then programmer for the Writing@CSU project, and me to design the interface

Figure 6. In 1999, a prototype was developed for the Writing Studio.

58

/

DESIGNING WEB-BASED APPLICATIONS

(Fogelson, 2002; see Figure 6). Our text-heavy design proved problematic, however, and by 2002, we had moved to a new design (see Figure 7). In 2003, we learned that efforts by our colleagues at Utah State University to commercialize their Syllabase course management system had failed and that development of the project had stopped. We found ourselves reluctant to turn to WebCT or Blackboard, at that time the dominant course management systems, because they were based on a lecture-class metaphor. Instead, drawn to Syllabase’s use of the writing classroom as its guiding metaphor, we decided to create our own limited course management system within the Writing Studio. In December 2004, the Writing Studio was publicly announced and was made available to writers and writing instructors outside the University (see Figure 8). At that time, it was treated as a project distinct from the rest of the Writing@CSU Web site. In 2005, we merged Writing@CSU and the Writing Studio. We also decided to drop the Studio’s “rooms” in favor of the concept of “collections” of resources on particular topics. CURRENT STATUS The Writing@CSU Web site and its Writing Studio currently provide access to a set of drafting and project management tools, collections of resources focusing on a range of writing processes and genres, and a robust course management system. Since 2005, we have added an ePortfolio tool, a Wiki tool, and a Blog tool. We have also developed

Figure 7. In 2002, the Writing Studio moved into a beta version.

THE ROLE OF METAPHOR /

59

Figure 8. A customizable personal page directs writers to resources on the site.

an outlining tool and updated our bibliography tool. In 2009, the site underwent a major redesign and, in 2010, content not directly related to the primary mission of the site was removed and posted on other university Web sites. The site currently contains roughly 18,000 pages of static content and roughly 5,000 dynamic pages supporting the Writing Studio’s writing and communication tools, interactive activities, and course management system. Site Resources and Architecture The Writing@CSU site is designed to provide access to four sets of resources: (a) instructional content in the form of writing guides—similar to online textbooks— that provide advice on a wide range of writing processes and genres; (b) interactive activities that help writers work through particular writing processes; (c) Writing Studio tools that support composing, project management, communication with other writers and writing instructors, collaborative writing, and publication; and (d) the Writing Studio’s course management system, which is open to use by instructors regardless of institutional affiliation. The site uses a home page, top-level pages addressing key functions of the site, a standard sitewide menu, a site index, and a search tool to help writers navigate the site. Visitors to the site can also view the site’s “collections” of resources on writing processes and genres to find relevant resources. Many of the individual resources also provide links to related resources. Visitors who create and log in to Writing Studio accounts are directed to a customizable personal page that provides access to writing, project-management, and publication tools as well as a personal calendar. A set of links

60

/

DESIGNING WEB-BASED APPLICATIONS

provides access to the writer’s wikis, blogs, ePortfolios, classes, files and file folders, and account settings (see Figure 9). Instructional Content When the Writing@CSU project was initially conceptualized, it was targeted at the University’s composition and writing-intensive courses. Our year-long assessment of writing activities and instruction at our research-intensive university had indicated that faculty would be less likely to use writing in their courses if they were asked to do so in a manner similar to that typical of writing-across-the-curriculum initiatives at institutions that focused primarily on teaching (Palmquist et al., 1995). We had learned, however, that they would be more likely to use writing assignments in their courses if direct support for students was provided through a writing center and/or a collection of online resources that students could consult for advice. We chose to pursue both options, linking our campus writing center to an online writing center that students could access to learn about specific writing processes and genres. Key instructional resources offered through the first version of our online writing center included writing guides, interactive writing activities, and teaching guides. When the online writing center moved to the Web, we added a set of links to resources elsewhere on the Web. In the early 2000s, we also began to offer video resources consisting of advice from experienced writers and readings of fiction, nonfiction, and poetry.

Figure 9. A customizable personal page directs writers to resources on the site.

THE ROLE OF METAPHOR /

61

Of these resources, all but the Web links continue to be used extensively. Currently, more than 80 writing guides, nearly 90 writing activities, and more than 30 teaching guides are available for use. The writing activities are designed to be brief but structured and typically run between 8 and 15 pages in length. In contrast, the writing and teaching guides vary in length from as few as 8 pages to as many as 250. In the past year, the instructional resources on Writing@CSU were accessed by more than 4.8 million visitors to the site. Composing and Project Management Tools The Writing Studio was developed to support student writers in the act of composing. Composing tools include an ideas tool (which saves brief memos and allows writers to link them into clusters), a notes tool, an outlining tool, and a drafting tool. Project management tools include a to-do list, bibliography tool (see Figure 10), and file management tools. The bibliography tool supports four documentation systems and allows writers to link notes to sources, save source content, and record source evaluations. File management tools allow writers to upload files to project folders, share files and folders with other account holders, share files with classes and wikis, and distribute files via ePortfolios. The majority of these tools use a WYSIWYG editor to support rich text editing. In the past year, these tools were accessed by roughly 250,000 visitors to the site.

Figure 10. Writers can control the display and content of a working bibliography.

62

/

DESIGNING WEB-BASED APPLICATIONS

Communication, Collaboration, and Publication Tools Writing Studio account holders can communicate with other writers via electronic mail, chat, rosters in the course management system and wikis that allow writers to view each other’s personal pages, and discussion forums in the course management system and wikis. Writers can collaborate by sharing project folders with other writers, an act that allows writers to share files and work saved through tools such as the bibliography and drafting tools; by allowing other writers to view and comment on their blogs and ePortfolios; and by working together in a wiki. Blogs and ePortfolios can be kept private; shared selectively with individual writers, all members of a class, or all members of a wiki (see Figure 11); or published openly on the Web. Both tools allow extensive customization, including the use of personal photos and banner images and custom coding of pages and posts. Wikis support collaboration among groups of writers. Each wiki provides access not only to standard wiki functions such as multiple versions of a page and the ability to undelete pages, but also to a shared calendar, discussion forums, file folders, and shared blogs and ePortfolios. All members of a wiki have equal administrative control over the wiki. Course Management System The Writing Studio’s course management system was developed as something of an afterthought, largely because we no longer had access to the Syllabase course management system developed by Chris Okelberry and his colleagues at Utah State University. In response to a great deal of feedback and suggestions from users at our own and other institutions, however, we have expanded it into a system that is comparable in terms of features and function to leading course management systems (see

Figure 11. Writers can keep blogs private, share them selectively with individuals, classes, or groups, or publish them.

THE ROLE OF METAPHOR /

63

Figure 12). Account holders can gain “instructor” status by sending e-mail to the project director and briefly explaining their plans for using the system. Once an account has been upgraded to instructor status, the account holder can create as many course pages as desired and can invite students to join the class. At Colorado State University, instructors can also populate a class roster by linking to the University’s enrollment database. Tools comparable to those offered by other course management systems include a calendar, syllabus, class assignments, class materials, gradebook, discussion forums, chat, file folders, and an assignment dropbox. Groups can be formed and given access to discussion forums and a shared file folder. In addition, the system allows students and instructors to share blogs and ePortfolios with the class and to create class and group wikis. Groups can elect to create wikis in private and, later, share them with the class. Members of a class can access a “classmates” page and, through it, visit each other’s personal pages (see Figure 13). The personal page viewer allows classmates to invite other members of the class to view blogs, files, project folders, and ePortfolios as well as send messages to each other. Classmates can decline a request to view resources that have been shared with them.

Figure 12. A class page from the University of California, Irvine.

64

/

DESIGNING WEB-BASED APPLICATIONS

Figure 13. Viewing a classmate’s personal page.

Instructors have access to course management tools, the class roster, and a teaching notebook where they can record their observations on the class. Instructors can customize the class (including adding custom background images, banners, and institutional logos), view and comment on student work, add co-instructors to the class, import materials from other classes, and create a copy of the class. Instructors can also post calendar entries and class materials to multiple classes at once. To date, more than 7,500 class pages have been created by roughly 1,800 instructors from more than 200 institutions. A handful of institutions use the course management system to support all or most of their composition courses, while a number of instructors use the system as a replacement for the course management systems used at their home institutions. During the past year, the course management system has been viewed during more than 1.5 million visits to the Writing@CSU site. REFLECTIONS In graduate school, I was counseled by Chris Neuwirth to avoid programming. (She might have used the phrase “like the plague” as she said it.) It would be far better, she told me, to lead development of a project, hire programmers, and avoid the time-consuming, detailed work of coding. For several years, I followed and profited from her advice. As a younger scholar, I conducted studies of computer-based writing instruction and led development of what we then called the Online Writing Center, but I did not spend a great deal of time creating applications. After I earned tenure,

THE ROLE OF METAPHOR /

65

however, I decided to make the Writing@CSU project one of the main areas of emphasis in my scholarly work. As I did so, I found that the best way to understand the limitations and potential of the Web, database-driven applications, and social media was to become a coder. I haven’t regretted that decision. I’ve learned that, with few exceptions, an application that can be envisioned is an application that can be created. I’ve also learned that the act of coding—I’m tempted to write “the materiality of coding” but it’s hard to think of code in that way—can lead to new ideas about potential uses of technology as well as the kind of felt difficulty I experienced as I was working on the Writing@CSU Web site in the late 1990s, a felt difficulty which, eventually, led to fundamental changes in the project. I would not recommend this path without reservation. I’ve been fortunate to work in a department that values both investigations of and the development of computer-supported writing tools. I owe a great deal to my colleagues Kate Kiefer, Dawn Rodrigues, and Charles Smith, who helped my department learn the value of such work long before I was hired. I realize, however, that many of us work in contexts where such work is not valued, and I would urge anyone who is interested in following a path similar to mine to consider their local situation carefully before proceeding. With that caveat in mind, I can say that following this path has been immensely rewarding. The Writing@CSU project has supported thousands of writing teachers and students and has led to a number of publications and presentations. Its greatest value, however, has been as a vehicle for exploring ideas about how we might approach computer-supported writing instruction, one that has allowed my colleagues and me to test our ideas about a range of approaches to computer-supported writing instruction. In this sense, the Writing@CSU project is best seen as a theoretical project, one designed to push the limits of commercially available tools. In other words, rather than accepting the theoretical framework informing commercial and open-source software (I’m thinking in particular of programs such as Blackboard, WebCT, and Sakai), the project has allowed us to experiment with alternative approaches and different metaphors. I would like to think that, in the same way that early work on word processing programs by members of the computers and writing community led to enduring changes in the word processing programs we now use, the tools developed through this project might have some influence on the development of course management systems and Web-based learning environments. PLANS FOR FURTHER DEVELOPMENT The Writing@CSU project is entering its 19th year of development. Plans for the future include developing a version of the Writing Studio that can be installed on servers at other institutions and creating an open-access, peer-reviewed textbook project. Plans to move forward with both of these projects were delayed for several months in the spring of 2010 when the English department at Colorado State University eliminated the programmer position that had been funded by the University’s Provost in 1997. It is anticipated, however, that both projects will move forward once new funding has been secured. In the meantime, the Writing@CSU project is being supported financially by the Institute for Learning and Teaching, which

66

/

DESIGNING WEB-BASED APPLICATIONS

is housed in the Provost’s Office at Colorado State University, and by contributions of time and energy from colleagues at Colorado State and other institutions. We anticipate that the project will continue for a number of years. We also expect it to change in response to new information technologies and the needs of writing students and their teachers. As we look toward those changes, I look forward to the opportunity to continue exploring new technologies and the new ideas they will surely generate.

REFERENCES Buchanan, E. (2000, April 21). SyllaBase Internet learning system grows from a USU basement to a worldwide network of students. Hard News Café. Retrieved from http://newscafe. ansci.usu.edu/archive/april2000/0421_hightech-syllabase.html Crump, E. (2000). How many technoprovocateurs does it take to create interversity? In J. A. Inman & D. N. Sewell (Eds.), Taking flight with OWLs: Examining electronic writing center work (pp. 223–233). Mahwah, NJ: Erlbaum. Fogelson, M. (2002). The Informative Writing Room at Colorado State University. Master’s project. Department of English. Hobson, E. H. (1998). Wiring the writing center. Logan: Utah State University Press. Kinkead, J., & Ugan, J. (1983). A report on the 1983 CCCC special session for writing lab directors. Writing Lab Newsletter, 7(10), 5–6. Lasarenko, J. (1996). PR(OWL)ING AROUND: An OWL by any other name. Kairos, 1(1). Retrieved from http://english.ttu.edu/kairos/1.1/binder2.html?owls/lasarenko/prowl.html Neuwirth, C. M., Kaufer, D. S., Chandook, R., & Morris, J. H. (1990, October 7–10). Issues in the design of computer support for co-authoring and commenting. Proceedings of the third conference on Computer-Supported Cooperative Work, Los Angeles, CA. Baltimore, MD: Association for Computing Machinery. Neuwirth, C. M., Kaufer, D. S., Chimera, R., & Gillespie, T. (1987, November 13–15). The Notes program: A hypertext application for writing from source texts. In Hypertext ’87 Proceedings (pp. 345–365). Chapel Hill, NC/New York: Association for Computing Machinery. Neuwirth, C. M., Keim, G., & Gillespie, T. (1988). The Comments program: Computer support for response to writing. Pittsburgh, PA: Carnegie Mellon University, CECE-TR-3, Center for Educational Computing in English. Neuwirth, C. M., Palmquist, M. E., & Gillespie, T. (1988). An instructor’s guide to collaborative writing with CECE Talk: A computer network tool. Pittsburgh, PA: Carnegie Mellon University, Center for Educational Computing in English. Neuwirth, C., Palmquist, M. E., & Hajduk, T. (1990, April 16–20). Collaborative writing and the role of external representations. Presented at the annual meeting of the American Educational Research Association, Boston, MA. Palmquist, M. (2000). Notes on the evolution of network support for WAC. In M. D. Goggin (Ed.), Inventing a discipline: Essays in honor of Richard E. Young (pp. 373–402). Champaign-Urbana, IL: National Council of Teachers of English. Palmquist, M. (2006). Rethinking instructional metaphors for Web-based writing environments. In L. Van Waes, M. Leijten, & C. M. Neuwirth (Eds.), Writing and digital media (pp. 199–219). Amsterdam, The Netherlands: Elsevier. Palmquist, M., Kiefer, K., Hartvigsen, J., & Godlew, B. (1998). Transitions: Teaching writing in computer-supported and traditional classrooms. Greenwich, CT: Ablex.

THE ROLE OF METAPHOR /

67

Palmquist, M., Kiefer, K., & Zimmerman, D. E. (1998). Communication across the curriculum and institutional culture. In D. Reiss, R. Selfe, & H. Young (Eds.), Electronic communication across the curriculum. Urbana, IL: National Council of Teachers of English. Palmquist, M., Rodrigues, D., Kiefer, K., & Zimmerman, D. E. (1995). Enhancing the audience for writing across the curriculum: Housing WAC in a network-supported writing center. Computers and Composition, 12(3), 335–353. Rodrigues, D., & Kiefer, K. (1993). Moving toward an Electronic Writing Center at Colorado State University. In J. A. Kinkead & J. G. Harris (Eds.), Writing centers in context: Twelve case studies (pp. 216–226). Urbana, IL: National Council of Teachers of English. Rodrigues, D., Kiefer, K., & McPherson, S. (1990). English department offers electronic writing service. Vector, 7(5), 3–4, 16.

http://dx.doi.org/10.2190/DWBC5

CHAPTER 5

Creating Complex Web-Based Applications with Agile Techniques: Iterations as Drafts Matt Penniman and Michael Wojcik

INTRODUCTION On the surface, they’re very different. Our Michigan Ave (Figure 1) is a community development Web site, designed to encourage discussion around urban planning for a major commercial corridor. It showcases photos, improvement ideas, and points of interest. Speech Made Visible (Figure 2) is a simpler site that invites visitors to upload an audio recording of speech and a transcript, and creates a styled version of the transcript that indicates pitch, speed, and volume with the size, color, and placement of the text. Yet what interests us most about these projects, which we both worked on extensively, is the common method that we used to build them: Agile Development. Agile is the dominant approach in professional software development today. It integrates writing documentation into the development process, so many technical writers who work in the software industry work in an Agile environment. Agile is strikingly similar to a lot of what we teach in the writing classroom. It emphasizes elements like drafts, invention, peer groups, revision, and editing. In Web application development it can get a usable site released very quickly, and although it works best when used by domain experts, it is flexible enough to accommodate learners as well. Agile also helps us bridge the gap between software development, crafting code for machines, and technical writing, crafting words for humans. As writing expands into online contexts, our work increasingly reaches both silicon and human audiences, and learning how to write to machines (that is, to write code) is a key extension of our core rhetorical skills. More and more documents of all sorts—technical, imaginative, creative non-fiction—are realized as software applications of some sort, from basic Web pages to dynamic interactive presentations to games and immersive environments. 69

70

/

DESIGNING WEB-BASED APPLICATIONS

Figure 1. Our Michigan Ave.

Figure 2. Speech Made Visible.

CREATING COMPLEX APPLICATIONS WITH AGILE TECHNIQUES

/

71

Writers, and thus writing instructors and their students, are called on to produce not just written content but complex software-based delivery systems for it.1 Moreover, creating software can open new possibilities for traditional writing activities and expand the horizons of writing itself. Of the two projects mentioned above (and about which we’ll say more below), one provided structure and opportunity for meaningful writing by students and community members, while the other lends new affordances to print text. Many of us have found exciting opportunities for writing and new ways and kinds of content to create through existing Web-based software, blogs and multimedia, for example, and creating our own software, incorporating our deep understandings of writing, can take this process further. By coding, we write and create new environments and occasions for writing. Writing instructors who hope to create Web applications face a difficult task: instructing novices in a new software paradigm, doing user research and testing, and creating a usable product for release. Agile offers a means of structuring these tasks in a way that closely resembles the drafting process. AGILE DEVELOPMENT Philosophy While there are a number of Agile methodologies, they share a philosophy that acknowledges change and difference, just like contemporary writing pedagogy.2 Agile stresses cycles: gather information, realize it by creating some kind of product, evaluate the result, reassess goals, and repeat. Agile cycles, or iterations, are often no more than a week or even shorter, to permit frequent revision; each cycle incorporates peer review and often review by other audiences as well. Short cycles let the work evolve to meet changing requirements, rather than being tied to an initial design, it can incorporate user feedback and student learning during development. From a relatively early point in the project, it should always be possible to “release” a version—even if it only has limited functionality—to users. Agile emphasizes releasing products when they’re good enough to use, and then improving them for the next iteration. Requiring a demonstration of some sort at the end of each cycle not only ensures that review happens, but keeps the team’s attention focused on their audience as well. Agile philosophy also stresses inclusiveness and self-organization, key features for classroom practice. Agile “feature teams” should include members with various competencies, so all the skills necessary for the feature are represented. In addition to students who are comfortable with writing code, an Agile team might have technical writers to produce documentation, user researchers who can discover requirements, and even documentarians who can record and comment on the development process itself. (One member of the Speech Made Visible team produced a short video explaining the project 1

Consider for example http://prezi.com or http://wordle.net/ See http://en.wikipedia.org/wiki/Agile_software_development and http://agilemanifesto.org for overviews. 2

72

/

DESIGNING WEB-BASED APPLICATIONS

and its origins; Huang, 2009.) Self-organization, in turn, means that feature teams should assemble themselves and members should choose their own roles, as far as is feasible. In a classroom, the instructor will likely have to impose some requirements, but it’s often possible to let students select some roles where they feel confident contributing and others where they have to stretch. In general, giving teams considerable freedom is part of Agile’s emphasis on reducing management overhead, which hopefully means less supervisory work for the instructor or lead researcher. 3 Elements So what are the elements of an Agile project in the writing classroom? We’ve already mentioned several, such as feature teams and iterations. Agile work is collaborative. Small projects generally have a single team, but larger ones are often the product of several teams, each focusing on a general area where an “area” is defined in whatever way makes sense for the teams (“data storage and access,” “view/edit user profile,” “usability testing,” etc.). Teams of three to six members seem to work best, and true Agile teams include a variety of skills and roles. Iterations are the work cycles of Agile. They include research and planning, producing the next iteration, getting feedback, and reassessing the project. Iterations should be short enough that the team can get through a few over the course of the project, and long enough that they can make progress during each one. Depending on the length and nature of the project, anywhere from a few days to a month might work. An iteration begins with planning: the team updates its list of tasks for the project (the backlog, described below); then each member selects some tasks to try to complete in the iteration. During the iteration team members work on their tasks, preferably with frequent interaction so everyone on the team knows how each member is doing. One popular Agile method, Scrum, holds a daily meeting (the eponymous “scrum”) where members each say what they’ve done in the last day, what they plan to do for the next day, and whether they’ve run into any impediments that are interfering with their work. We’ve found scrum-type meetings can be held effectively using group chat (a service that automatically records the conversation, such as Google Chat, is particularly useful). At the end of each iteration, the team should present a demo of their work so far to an interested audience. That might be the “product owner”—in a classroom, this is typically the instructor, unless the students are working for an actual client—or a peer group from the class, a group of potential users, and so on. (For faculty projects, the 3

See http://www.extremeprogramming.org/ for a discussion of the Extreme Programming (XP) Agile method, and the related http://www.agile-process.org/ for some more general comments on Agile development. (Note navigation on those sites is somewhat confusing.) Useful sites for information on the Scrum Agile approach include http://www.scrumalliance.org/ and http://www.controlchaos. com/resources/. Wojcik (2009) is a narrated version of his “Introduction to Agile” presentation, delivered to John Monberg’s TC491 class at the beginning of the Our Michigan Ave project. Wojcik (2010) is a longer presentation on Agile development which contains most of Wojcik (2009); the online version includes speaker notes.

CREATING COMPLEX APPLICATIONS WITH AGILE TECHNIQUES

/

73

product owners might be the team members, and recruiting another audience at the beginning of the process would be good.) Early on, a demo might be design documents or mock-ups; later it can be working software. Then the team discusses among themselves what went well or poorly during the iteration, and moves into planning the next iteration. The list of tasks for the project is called the backlog. Early in the project, tasks in the backlog are often vague and large (“support writing new content for the site”), because the team doesn’t have a good idea yet what they involve. In Agile these are called “epics,” and part of the team’s work in each planning session is to try to break some of the epics down into manageable pieces. During planning the team should also try to prioritize the backlog, putting the most important stories at the front to help in selecting the next ones to work on. It’s very useful if other stakeholders (the product owner, potential users) can weigh in on priorities, and this is also an excellent opportunity to practice user research techniques. Many tasks on the backlog come from the product owner or from team members, but ideally many of them come from users—what Agile calls “user stories.” Some practitioners even use a role/action/object form for these: “as a contributor, I want to edit my writing on the site”; “as a reader, I want to see a list of what’s new.” If the course can accommodate the kind of user research that can produce user stories, teams should be encouraged to collect them and put them in their backlog. Agile places great value on frequent demonstrations (and “releases,” as soon as workable software is available). Demos keep stakeholders engaged in the project and energize teams. They force teams to reassess their own work and elicit feedback—this is usually constructive, but if users are going to object to part of the design, it’s best to know as soon as possible—ask teams to demonstrate their work both internally, to other teams, and occasionally externally, to potential users or reviewers. Source change management is not usually considered part of Agile, but it’s crucial for collaborative software development and, as Karl Stolley, for one, has argued, should really be part of every software-based assignment.4 Change management lets students work on one codebase without overwriting each others’ changes; work on their own machines and commit updates to a central server; undo mistakes; see who made each change, and why; and implicitly back up their work. Agile in Practice In many ways, the iteration approach of Agile should be familiar to writing instructors. The early stages of user research, design documents, and mock-ups resemble prewriting techniques used to clarify a topic, gather sources, and outline the form of a paper. Agile’s focus on making a usable product as soon as possible resembles writing a rough draft that may be incomplete, incorrect, or incoherent, but is still readable and available for critique. Agile’s emphasis on demonstrations for an outside 4

See Stolley’s Web sites http://gewga.ws/git-for-writers/ and http://wiki.karlstolley.com/GitTutorial for more information on using Git, one popular free change management system. Another free change management package is Subversion (http://subversion.apache.org/). Both have active user communities, tutorials, and add-on-tools.

74

/

DESIGNING WEB-BASED APPLICATIONS

audience correlates closely to working with an editor or seeking “fresh eyes.” Agile invites us to take the competencies and expertise we have developed in writing instruction and transfer those to code instruction. Since Agile was designed for full-time professionals, it needs some adapting for the typical classroom, where most of students’ time is taken up with other concerns and schedules are necessarily much shorter than is usual in the corporate world. That means there can only be a few iterations, even if they’re short. Startup must be rapid—you can’t spend half the semester explaining the process—and there must be good technical support to prevent technical issues from derailing an iteration. With the Our Michigan Ave project, much of the infrastructure was created at the beginning of the first semester; that only succeeded thanks to a highly motivated instructor and excellent technical resources.5 The Speech Made Visible project ran over half a semester with 1-week iterations, using existing infrastructure.6 One advantage of Agile in the classroom is that it’s relatively easy to carry a project forward from one class to another in the next semester and present the new class with the existing software as a work in progress, the existing backlog of tasks, and any other materials generated by the previous class. The new class may continue working with the same sorts of feature teams as the old class, or they might take on different aspects of the project, or revise it entirely. The Our Michigan Ave project was originally developed by a technical communication/rhetoric class in Spring 2009, with additional content contributed by a professional writing class in the same semester. Then in fall 2009, a digital rhetorics class took up the project by conducting user research for the application and proposing and reviewing design changes to it. 7 One drawback of Agile is its traditional identity as a production philosophy, not a pedagogical one. It’s easy to let software creation eclipse other aspects of teaching when you use it in the classroom. It might be best to have students do most of their iteration work outside class so some class time can be reserved for other activities. Alternately, the scrum meeting can be used as a springboard for teaching; by identifying technical problems and gaps in understanding that represent impediments to student work, the scrum provides immediate feedback to the teacher on which topics to cover.

5

The instructor was John Monberg of Michigan State’s Writing, Rhetoric, and American Cultures department. He conceived the OMA project and taught all of the classes that have worked with it. The site was initially hosted and supported by MSU’s Center for Writing in Digital Environments (WIDE). It is now hosted pro bono by LiquidWeb, a local provider. Technical support was provided by Matt Katzenberger, Jim Ridolfo, and Michael Wojcik, and by some of the students with programming experience, including Matt Penniman and Zach Church. 6 Initial work on the SMV project was done on the developers’ personal computers. Around the third iteration it moved to a development server at the WIDE Center, using software already installed there for other projects. Michael Wojcik handled technical support issues such as configuring the SMV Web site and the Subversion repository. 7 The spring class did two full iterations over the course of the semester. They used a relatively long iteration cycle and spent the first few weeks getting infrastructure in place and learning to use it. The Fall class did one 6-week iteration of focused user research—longer than usual to allow for data collection—and then two 2-week iterations of design work.

CREATING COMPLEX APPLICATIONS WITH AGILE TECHNIQUES

/

75

Agile’s emphasis on users—user stories, demos, user feedback—suits communitybased learning and community engagement. Both of the classes that worked on the OMA application solicited community input with public demonstrations, and the second-semester class used it as the basis for several modes of applied user research: persona development, contextual inquiry, ethnography, and usability testing. And as we’ve already noted, this can expand the roles available on Agile teams, since noncoders can work to gather user requirements, test usability, and so on. Agile also works well outside the classroom. Speech Made Visible was developed partly to satisfy a class assignment, but it’s also a research project in its own right. Matt conceived it as an investigation into the traditional problem of representing prosody in print. We’ve presented it at one conference already, and it’s likely we’ll do so again as it progresses. The SMV software has also been published on SourceForge (http://sourceforge.net/projects/speechmadevis/). Similarly, a number of projects at MSU’s WIDE Center are being developed with a “loose Agile” approach. The somewhat different constraints of an academic research center, where participants are working on several projects simultaneously and schedules tend to be disrupted by meetings with clients and administrators, have made it difficult to conduct regular iterations. But WIDE is working on refining its development process to make it more manageable, and Agile techniques are at the forefront of that effort. Some readers may have heard complaints about Agile development from people in industry, particularly from technical communicators. There are organizations that have adopted Agile development in ways that make documentation work, in particular, very difficult: excluding technical communicators from the design and review process, presenting them with a continuously changing product with no stable user experience to document, and so on. In our view, this is a broken Agile process; feature teams should include technical communicators and need to account for their work just as they do with any other team member. But it’s also true that an Agile approach is not ideal for every project, and in some cases it may simply have been forced into the wrong situation. More importantly, Agile ideas and practices have to be adapted for each organization. Take the pieces that work for your project and don’t be tempted by ideological purity.8 Finally, if you do adopt Agile, be aware that there are tools that can help—either designed for it or adapted to it. For example, XPlanner (http://www.xplanner.org/) is an open-source Agile management tool that collects user stories, tracks iterations and tasks, and so forth. The commercial online application Rally (http://www.rallydev. com/) has a “community edition” that can be used free of charge for small projects. But often it’s helpful simply to use social media for virtual meetings, free screencast software like Wink (http://www.debugmode.com/wink/) or Jing (http://www.jing project.com/) for demos, and shared documents for project tracking. One of our OMA teams used a Google Docs spreadsheet for our backlog and iteration task list; team members put their names down beside items they were working on, and updated their status as they finished them. 8

We’d like to thank an audience member for our panel at ATTW 2010 for raising this point.

76

/

DESIGNING WEB-BASED APPLICATIONS

Agile and Writing It’s our belief that Agile software development is not just a useful approach for developing software in the writing classroom, but a potential component of writing pedagogy itself. Similarly, writing teachers who employ Agile techniques when they develop software outside the classroom should find that it fits with methods they already employ when creating intellectual products. We’ve already suggested that one correspondence between Agile and good writing pedagogy is the former’s emphasis on iterations, which we see as equivalent to drafts in writing. Obviously, iterative revision has long been a major concern in composition theory and practice. Betty Bamberg, for example, describes how “composing process research and theory over the last 30 years . . . reconceptualizes revision as a primary means of developing, elaborating, and shaping the intended meaning of a text” and calls revision “an important theoretical and pedagogical concept in composition” (p. 108).9 Nor are we the first to connect revision in writing with revision in software development, as for example “redesign” assignments in onlinewriting courses show. In a course described by Dyehouse, Pennel, and Shamoon (2009), the last of three projects is a Web site redesign, based on one created by Melinda Turnley. It includes “identifying, analyzing, and planning out revisions to existing websites” in order to understand technical work as part of an ongoing rhetorical process (p. W340). In a recent essay, Steve Parks and Nick Pollard (2010) have offered this pithy version of the call to revise: “Writing should be seen as an organic process where revision or responding to peer comments is a necessary stage in a piece’s development” (p. 488). We would describe software development the same way (aside from changing their “or” to “and”). Indeed, we’d echo the suggestion made by William Hart-Davidson and Michael McLeod, in their contribution to this volume, that the emphasis perhaps should be on review and revision rather than the initial creation of text (or code). Iterations, perhaps Agile’s greatest intervention into older software development methodologies, bring review and revision into the foreground. 10 Of course, revision in software is not identical to revision in writing, just as creating software is not identical to writing text. While there are numerous similarities (for example, Agile revision, like writing revision, focuses each iteration on a handful of suggestions that are felt to be particularly important or interesting), there are also differences. Much of software development involves writing code, and one audience for code is the machine—and a very tricky audience it can be, at once exacting and

9

Various volumes dedicated to revision, such as Donald M. Murray’s perennial The Craft of Revision (5th ed., 1998) and the collection Acts of Revision, edited by Wendy Bishop (2004), testify to its importance in the field. 10 The dominant software development approaches prior to the rise of Agile were unstructured ad hoc development, which was really the lack of any coherent methodology, and the “waterfall” method, which aimed to produce a complete design and specification before beginning implementation. See Wojcik (2009).

CREATING COMPLEX APPLICATIONS WITH AGILE TECHNIQUES

/

77

indifferent to rhetorical nuance.11 The mechanical nature of software makes it a more constricted environment than any human-language genre. And because software is usually interactive, reviews typically need to consider usability and user experience, much as they would for technical writing; this could be unfamiliar to students used to reviewing more imaginative forms. On a similar note, Agile teams are by definition collaborative, and so the revision process resembles that of collaborative writing rather than individual writing. For example, Agile revisions are guided by a combination of the team’s collective effort to prioritize the backlog, on the one hand, and each member’s choices (following Agile’s emphasis on self-organization) about what tasks to focus on for an iteration. This creates a multilayered review process for each iteration: after the postiteration demo and feedback from the audience, the feature team reviews the status of their project and the backlog (including any new stories generated from the demo). While contemporary composition pedagogy may have largely debunked the “lonely writer” myth,12 it still seems likely that many writing students mull over peer, instructor, and audience feedback and create their revision plans in private. Agile does not work that way. This last point suggests Agile also sits well with the pedagogical tenets that have emerged from social-constructivist composition theory.13 Social constructivism has led writing teachers to emphasize the social nature of writing, both within the classroom through exercises like peer review, and more importantly outside it by turning from the individual, introspective writing typical of the expressivist composition approach to assignments that explicitly incorporate social, cultural, and political engagement.14 In Agile, extensive teamwork, negotiation, and review make social interactions critical to the production of software. Meanwhile, Agile’s call to solicit requirements and feedback from users provides a natural avenue for engaging with a community outside the institution.

11

Many people erroneously feel the machine is the only audience for software source code. However, in practice non-trivial software must address a human readership as well, as Michael Wojcik has argued elsewhere (2009, March). 12 Most famously, perhaps, in Linda Brodkey’s well-known “Modernism and the Scene(s) of Writing,” (1987b). 13 We note that, in keeping with the inevitable (if constructive and necessary) cycles of celebration and critique that mark the history of composition pedagogical theory, social-constructivist writing theory is now being challenged on various fronts. See for example Patricia Roberts-Miller (2002). However, we believe the general ideas associated with it that we refer to here are still widely seen as important for the writing classroom. 14 Connections between a social-constructivist theory of writing and pedagogical emphases on writing in social scenes and incorporating various kinds of social interaction and engagement in the writing class appear in any number of well-known works on social-constructivist writing pedagogy. See, for example, Bizzell, Connors, Faigley, Hillocks, and Shriver (1989), or Brodkey (1987a). Agile philosophy, which is also very attentive to the individual skills, inclinations, and styles of team members, is perhaps closer to some of the hybrid writing theories that sought to acknowledge the importance of both social and individual contributions to the writing process, such as the one espoused by Berkenkotter (1991).

78

/

DESIGNING WEB-BASED APPLICATIONS

In the most general terms, the Agile approach to software development is one that tries to engage all stakeholders, repeatedly and substantially, in the creation of an intellectual work, even while it recognizes their diverse interests and competencies and seeks to maximize self-directed contribution to the project. It’s best described as a federated approach, where participants are not necessarily equal (and certainly not equivalent), but negotiate to reach appropriate roles. Returning to Parks and Pollard, we might argue that Agile is well-suited as the framework for the software-development equivalent of their call to create a federation in the writing classroom, though we have yet to consider thoroughly how their work could be incorporated into an Agile approach. Certainly the Our Michigan Ave project could be viewed as approaching what they describe as “writing projects with local . . . and worker-writer collectives . . . attempting to gain both the literacy and occupational skills that support larger struggles for representations and rights” (p. 478). OMA was created specifically to give community members a forum for various kinds of input on a tax-recapturing urban improvement zone in the Lansing area; its goal is to provide continuous community representation in the improvement process. These general aspects of Agile are difficult to grasp in the abstract, so we devote the remainder of this chapter to considering two specific implementations of these ideas, Our Michigan Ave and Speech Made Visible. Although different in scope, both projects reflect the organizing power of the Agile philosophy in making quick, iterative writing and coding feasible. OUR MICHIGAN AVE John Monberg, a professor in Writing, Rhetoric, and American Cultures at Michigan State, with a background in computer programming, communications, and science and technology studies, conceived the Our Michigan Ave (OMA) project for a course in Ethnography and Interaction Design in the spring of 2009 (see Monberg, 2009). This mixed undergraduate/graduate course was cross-listed in the Technical Communications and Rhetoric & Writing programs (housed in different colleges at MSU). The semester-long project for the entire class was to create a social networking Web site for a local community redevelopment program, built from scratch using Ruby on Rails and designed through user research, academic theory, and industrial practice. Since the students had a wide range of backgrounds, skills, and resources, the project included many kinds of tasks besides writing code: research, visual design, information design, documentation, content production, and so on. In the fall semester, students in Monberg’s undergraduate/graduate Digital Rhetoric course conducted further user research for the site and made design recommendations for the next version, and throughout the year some of his undergraduate writing students contributed content. 15 The home page from the second iteration of OMA (Figure 3) gives a sense of the site, a community portal designed specifically for discussions about the Michigan 15

Matt Penniman was a student in the Ethnography and Interaction Design class, and wrote some of the code for the first version of the Web site. Michael Wojcik helped create the development environment for the site, and was a student in the Digital Rhetoric course.

CREATING COMPLEX APPLICATIONS WITH AGILE TECHNIQUES

/

79

Avenue Corridor, a neighborhood near campus that has recently been granted taxcapturing status for improvements. It’s primarily a textual site, though it also has photo collection and mapping features. It’s implemented in Ruby on Rails using a robust model-view-controller architecture and a MySQL database for content storage. The prototype for the third iteration16 (Figure 4) shows how user research and design critique have influenced the evolution of the site: the static image below the menu bar replaced with an album of photos and captions; an explanatory slogan under the site title; improved login controls and menu bar; and links to the newest content on the home page. Contributors can write articles for the site about the Michigan Avenue Corridor, suggesting improvements in a number of categories appropriate for the neighborhood revitalization process. They can also vote on suggestions they favor, and the site ranks suggestions by votes (Figure 5). The site has a page that automatically aggregates articles from various local RSS feeds—a feature that’s easy to add using standard Rails components. This provides a news page that’s relevant to the site’s purpose (Figure 6). Other site features include a photo gallery and an interactive map of the corridor where site users can add points of interest. When the Digital Rhetoric class took up the OMA site in the fall semester, their first iteration involved performing various types of research in the user community and producing reports to be used in later iterations. Figure 7 is a small excerpt from the report of the Personas feature team, who developed four personas to represent archetypes of the site’s users, based on interviews and qualitative data (Albertus, Boyle, Hayes, Howes, Logan, & Wojcik, 2009, p. 32). The Ruby language and Rails MVC architecture used to build the OMA site looks arcane at first, but it’s quite simple to adapt and extend from a template in a book or tutorial, and it’s very powerful. Figure 8 shows the controller for article comments on the OMA site, and the view that creates the form for users to add new comments. Rails uses a “programming by convention” model, where coders only need to specify elements that are specific to a feature; generic parts of the infrastructure are implicitly inherited. In this way, the comments controller can be built with a few lines to identify which data elements are connected to comments (belongs_to, has_many) and a few more to define methods that can be called to affect comments (def). The form for entering new comments can dispense with most HTML code and use a common function, form_for, to build the form. This model also encourages iteration by making the core functionality of the code simple to make and organize, allowing for an easy division of duties across multiple coders. The OMA project illustrates many of the Agile virtues: teams with members in various complementary roles, multiple iterations (drafts), peer and stakeholder review, rapid prototyping and frequent releases of working software, transition to new teams, and so on. It also shows how writing code can be a writing assignment, particularly

16

The third iteration hasn’t appeared on the published site yet primarily because no class is currently working on the site. A larger university effort to revise the site and incorporate social media, known as The Ave, began in October 2011.

80

/

DESIGNING WEB-BASED APPLICATIONS

Figure 3. OMA home page, second iteration.

when students have to work in teams and create code that will accommodate the future efforts of other teams, and how it can support other kinds of writing assignments, such as user research reports. As a product, OMA is a polished, attractive community site for user-generated content. It’s essentially equivalent in a number of respects (aesthetics, ease of use, standards compliance) to much commercial Web-based software; and having complete control over the source code makes it potentially more flexible than even customizable packages. Of course, many customizable Web applications for user-generated content, such as Web forum and wiki software, are open source and so in theory could be modified just as OMA can be. In practice, though, extending code developed by another team requires significantly more effort than enhancing a locally developed package, given a similar degree of code sophistication and quality. And OMA’s design is quite clean, a classic implementation of the Rails framework. It shows student Web projects that emerge from writing classrooms can be technologically sophisticated, even if the developers don’t have substantial knowledge of the technology, and relevant to the local community. OMA was an ambitious class project, but it succeeded, in part through hard work and excellent technical resources, but also thanks to the use of an Agile approach that let students work efficiently, effectively, and iteratively.

CREATING COMPLEX APPLICATIONS WITH AGILE TECHNIQUES

/

81

Figure 4. OMA home page, third iteration.

SPEECH MADE VISIBLE Unlike OMA, which was always an instructor-led project, Speech Made Visible (SMV) was entirely student-driven. In the fall of 2009, Matt Penniman conceived the basic goal of SMV—representing prosody by styling text—as the final project in an undergraduate/graduate Multimedia Authoring class. The other team members, classmates Michael Wojcik and Chris Huang, joined the project after Matt’s brief presentation outlining the idea, in good Agile self-organizing fashion. The aim of SMV is to use modern computer technology to improve on the various ad hoc representations of prosodic features (pitch, speed, intensity) of speech in text, for example in chant notation. Matt reasoned that the typographic possibilities of HTML/CSS—font face, size, and weight; letter positioning; color—could convey those properties, and the dynamic nature of scripted Web pages would let the reader

82

/

DESIGNING WEB-BASED APPLICATIONS

Figure 5. OMA transportation page.

experiment with representations. Currently, SMV is a Web application that takes as input a recording of speech and a transcript of the recording. It analyzes the recording to try to identify word breaks, and measure relative pitch, speed, and intensity for each word. An editing phase lets the user adjust the analysis to the transcript. Then it creates an XML file with the transcript and analysis data. Finally, a display page reads the XML and renders the text using various stylesheets. While SMV is still just a prototype, it provides an interactive illustration of the theory. SMV was created in a series of short iterations over a few weeks. Some work, such as basic research and presenting work to the class, was shared across the team. Matt wrote most of the rendering code; Michael wrote most of the analysis code. Chris documented the project, collecting various materials (including screencasts of the programming process, for example) and interviewing the other two team members, and eventually produced the short video about the project mentioned earlier. The earliest versions of the code were bits of technology cobbled together with scripts, and mockups (Figure 9) of the proposed Web-based implementation. Those were replaced in the next iteration with the actual Web pages (Figure 10). In fact, the first iteration of the SMV software wasn’t a Web application at all, but a collection of experimental, ad hoc scripts. Figure 11 is one of our first scripts for the Praat prosody analysis engine. For our demo at the end of this iteration, we ran the scripts manually (while projecting the desktop so the audience could

CREATING COMPLEX APPLICATIONS WITH AGILE TECHNIQUES

/

83

Figure 6. OMA news feed page.

watch) and explained their output. This relatively simple, short segment of code is far from perfect; as shown in the comment lines, it uses an inferior pitch detection function and a rough heuristic word detection algorithm. However, it functions well enough to demonstrate the purpose of the code and provide a starting point for further improvement. The current iteration of SMV uses PHP on the Web server to produce pages and drive a Praat script (which evolved from the one shown previously) for analysis. The rendering page (Figure 12) does most of its work on the client (the browser) in Javascript. Figure 13 has excerpts from the PHP and Javascript code. This code illustrates, again, the “just enough” approach of Agile—both PHP and Javascript are optimized for readability and modularity, rather than speed or efficiency, to permit further revision and development. And by wrapping an updated Praat script in PHP (using PHP’s “exec” function), we took a working piece of code from one iteration and created a new kind of application—Web-based rather than commandline—for the next iteration. These pieces were initially developed independently and simultaneously (by Michael and Matt, respectively), using the previous manual-script-based SMV application to generate input and test output. The code excerpts also illustrate the simple XML file format, based on the one used by the Elan tool, that we used between the analysis and rendering components; that intermediary layer let us add new features separately to each piece without breaking the other, while still being easy to work with. Agile development facilitates this

84

/

DESIGNING WEB-BASED APPLICATIONS

Figure 7. From the OMA user personas report.

sort of division of labor by explicitly encouraging breaking projects down into small steps and systematizing communication and transparency among team members and across teams. SMV also involved the creation of a number of peripheral products. We had to make regular reports to the class about our progress, so there were demos of underlying software and experimental apparatus, presentations, and so forth. We also did a usability review in class with an early working version of the site so we could gather feedback. Like OMA, it illustrates how software projects can produce many other kinds of writing and involve peer-group work and other kinds of audience interaction. SMV has been a durable project. We made the prototype implementation source code available as a SourceForge project and have presented on it at one conference to date (Penniman, Wojcik, & Huang, 2010).17 We plan to continue development and present further findings as the software evolves.

17

This presentation was at EDGES, the graduate research conference of the College of Arts & Letters at Michigan State University. Our presentation was part of an exhibition session; it included a traditional poster, a live demo of the software for the audience to try, and a loop of Chris Huang’s short documentary video about the project. Photos, including one of the poster, are available at http://www.flickr.com/photos/maleamichael/sets/72157623349248165/.

/

85

Figure 8. Excerpts from OMA source code.

CREATING COMPLEX APPLICATIONS WITH AGILE TECHNIQUES

/

DESIGNING WEB-BASED APPLICATIONS

Figure 9. SMV edit page mock-up.

86

/

87

Figure 10. SMV edit page, first iteration.

CREATING COMPLEX APPLICATIONS WITH AGILE TECHNIQUES

88

/

DESIGNING WEB-BASED APPLICATIONS

Figure 11. Early SMV Praat script.

It has also been very well received as a project, even in its prototype stage. Linguists, of course already familiar with prosodic analysis, have been interested in it as a prosody visualization tool that’s accessible to nonspecialists. Rhetoricians have found it engaging in part because of resurgent interest in oratory and the relationship between speech and text.18 Perhaps more importantly, it’s an example of a 18

One recent example was Elbow and Greaves’ 2010 CCCC panel, which included William Greaves, “Intonation in English,” and Peter Elbow, “Harnessing Intonation for Writing: Revising by Reading Aloud.”

CREATING COMPLEX APPLICATIONS WITH AGILE TECHNIQUES

/

89

Figure 12. SMV rendering page.

possible future direction for rhetoric: a field of computational rhetoric, analogous to computational linguistics and similar areas, which would use computers not just as tools for conventional rhetorical activity but to develop and implement algorithms from rhetorical theory itself. This capacity is not widely available in commercial software today; it’s a field that must be developed by rhetoricians writing software. AGILE FOR THE WIN In this chapter, we’ve mostly focused on the pedagogical advantages of Agile software development—using Agile techniques to create Web applications in the classroom. We would also like to emphasize, though, that we feel Agile development can advance software development in the discipline, whether we’re creating Web applications as research projects (like SMV) or as practical tools for academic work, be it teaching, research, administration, editing and publication, archiving, community engagement, or technology transfer. Faculty and students who are not professional software developers can write highquality, innovative software that incorporates the knowledge and skills of our fields. But even if we do not need to be professional developers, we can learn from the software industry and adapt approaches such as various Agile methods to help us create better software faster. Agile’s recognition of different competencies and

90

/

DESIGNING WEB-BASED APPLICATIONS

Figure 13. Excerpts from SMV source code.

CREATING COMPLEX APPLICATIONS WITH AGILE TECHNIQUES

Figure 13. Cont'd.

/

91

92

/

DESIGNING WEB-BASED APPLICATIONS

emphasis on teamwork and frequent reassessment helps avoid oppressive feelings of technical incompetence and frustration with seemingly intractable bugs. Its call to work with users appeals to the outreach mission of many institutions and grounds software development work in its real-world use. And importantly, the “good enough” theme of Agile—releasing software to users as soon as there’s something they can try, always looking to provide a usable tool today rather than an ideal one tomorrow— helps us find the sweet spot between making do with the software that’s already there and trying to create polished commercial software to rival it.

REFERENCES Albertus, A., Boyle, I., Hayes, C., Howes, F., Logan, L., & Wojcik, M. Personas for the Our Michigan Ave website: User archetypes for gauging usability and inspiring improvement. Unpublished report. Bamberg, B. (2003). Revision. In I. L. Clark (Ed.), Concepts in composition: Theory and practice in the teaching of writing (pp. 107-140). Mahwah, NJ: Lawrence Erlbaum. Berkenkotter, C. (1991). Paradigm debates, turf wars, and the conduct of sociocognitive inquiry in composition. CCC, 42, 151-169. Bizzell, P., Connors, R. J., Raigley, L., Hillocks, G. N., & Shriver, K. (1989). What are we doing as a research community? Rhetoric Review, 7, 223-289. Brodkey, L. (1987a). Academic writing as social practice. Philadelphia, PA: Temple University Press. Brodkey, L. (1987b). Modernism and the scene(s) of writing. College English, 49, 396-418. Dyehouse, J., Pennel, M., & Shamoon, L. K. (2009). “Writing in Electronic Environments”: A concept and course for the writing and rhetoric major. CCC, 61, W330-W350. Elbow, P., & Greaves, W. (2010, March). What is intonation in speech, what role does it play in grammar, and what role might it play in writing? Presented at the Conference on College Composition and Communication (CCCC), Louisville, KY. Huang, C. (2009). Speech Made Visible: Introduction [Windows Media video]. Retrieved from http://dev7.wide.msu.edu/smv/Introduction.wmv Monberg, J. (2009). Welcome [online]. Retrieved from https://www.msu.edu/~jmonberg/ 491/Welcome.html. Parks, S., & Pollard, N. (2010). Emergent strategies for an established field: The role of worker-writer collectives in composition and rhetoric. CCC, 61, 476-509. Penniman, M., Wojcik, M., & Huang, C. (2010, February). Speech made visible. Poster session presented at the EDGES conference, East Lansing, MI. Roberts-Miller, P. (2002). Post-contemporary composition: Social constructivism and its alternatives. Composition Studies, 30(1), 97-116. Stolley, K. (2010, March). Technical communicators and open source development. Presented at the Association of Teachers of Technical Writing (ATTW) Annual Conference, Louisville, KY. Wojcik, M. (2009). Introduction to agile [PowerPoint presentation]. Retrieved from http:// ideoplast.org/rw/portfolio2009/agile-narrated.ppt. Wojcik, M. (2009, March). Writing code PDF document . Presented at ATTW, San Francisco, CA. Retrieved from http://ideoplast.org/code/ Wojcik, M. (2010, March). Agile development in the writing classroom [PowerPoint presentation]. Presented at ATTW, Louisville, KY. Retrieved from http://ideoplast.org/attw2010/ agile-in-classroom.ppt

http://dx.doi.org/10.2190/DWBC6

PART 2

Individual, Standalone Applications à à Ã

CHAPTER 6

Visualizing Knowledge Work with Google Wave Brian J. McNely and Paul Gestwicki

Nardi and O’Day (1999) suggest that “it is in the spaces between things—where people move from place to place, talk, carry pieces of paper, type, play messages, pick up the telephone, send faxes, have meetings, and go to lunch—that critical and often invisible things happen” (p. 66). Their concern was to foreground the ways in which technologies and activities contribute to social practices and norms where significant interactions are often invisible. This chapter begins from the premise that student collaboration in professional and technical writing courses will often involve interactions in the spaces between classes, study sessions, work, and play, and that the particular affordances and proliferation of social software and Web-based communication (Spinuzzi, 2009) suggest that much of that collaboration is taking place in writing activities that can be aggregated and made visible in new and productive ways. In this sense, we are interested in how curricular and pedagogical instantiations of new and widely available enabling technologies such as Google Wave can improve student collaboration by making such work more intentional and visible—by bringing 93

94

/

DESIGNING WEB-BASED APPLICATIONS

together in one environment much of the critical collaborative work that has been previously fragmented or even invisible. In their discussion of activity theory and interaction design, Kaptelinin and Nardi (2006) contend that “people act with technology” (p. 10), and that such activity occurs within “a rich social matrix of people and artifacts” (emphasis in original; p. 9). They argue that in observing (that is, in making visible) these activities, we can ground our research and development of interfaces and applications in human-computer interaction. Students working on projects in professional and technical writing courses have always been embedded in these kinds of rich, technologically mediated social matrices. But the formative work they do is not always reflected by assessment of a final deliverable. By encouraging students to see their learning and collaborations as knowledge work, the importance of the sometimes invisible collaborative activities themselves may be foregrounded. Moreover, such an approach necessarily moves writing activities to the center of people acting with technology, since, as Grabill and Hart-Davidson (2010) suggest, “knowledge work looks like writing (indeed, often is writing) or is substantively supported by writing” (p. 1). This chapter discusses our attempts to make these practices more visible and tangible for students; one approach is to collect as many kinds of collaborative activities as is feasible in a collaborative Web-based environment such as Google Wave, where applications that we’ve developed to interoperate with Wave can trace and visualize student knowledge work. We argue that by positioning students as knowledge workers in concert with an application that explicitly visualizes such work, we can better attend to issues of formative assessment and student metacognition. Our approach to educational interface design is the result of collaboration between scholars in rhetoric and writing studies and computer science. We observe that collaborative knowledge work is held together through complex sociotechnical networks (Spinuzzi, 2007), and stakeholders, such as students, teachers, and community members, approach collaboration with different mental models. These differences are often unacknowledged and difficult to articulate, and few collaborative interfaces provide affordances for resolving potentially conflicting mental models in meaningful and productive ways. We contend that information visualization techniques may help to clarify the integral processes and patterns of collaborative knowledge work, thereby enabling users to make informed decisions about such work. Leveraging the synergy between visualization as a cognitive activity (Spence, 2007, p. 5) and writing as an epistemic activity, we argue, can inculcate reflective practice and metacognition among collaborators (Schön, 1983). We begin with a review of recent scholarship in collaborative knowledge work, articulating such theories with collaborative pedagogies from related disciplines. We then discuss some of the curricular and pedagogical concerns involved with knowledge work approaches and the enabling technologies that help comprise the rich social matrix of student knowledge work. These discussions ground our efforts with Google Wave, and we provide a description of the application we’ve developed by illustrating how it works within a typical professional and technical writing assignment scenario. Finally, we argue for some implications of our work and suggest future directions for similar learning technologies.

VISUALIZING KNOWLEDGE WORK WITH GOOGLE WAVE

/

95

EXPLORING NEW FORMS OF COLLABORATIVE WRITING WORK The growth of applications enabling computer-supported collaboration has provided significant new affordances for tracing and visualizing many forms of collaborative activity. Collaboration occurring through previously ephemeral or distributed practices such as backchannel communication, sketching and prototyping activities, and conversations around the sharing of files (actualized via e-mail, for example) is now more easily enacted within a single Web-based environment—initially by way of Learning Management Systems and more recently through systems such as Google Wave. Among the most relevant features of these systems are the ability to maintain and visualize an ongoing record of project development and peer feedback for all participants, thus providing strong opportunities for modeling student work and encouraging metacognition. Additionally, these applications hold promise for enacting more meaningful and ongoing formative evaluation of student collaboration. Much of the collaborative work that takes place in such environments occurs in and through writing activities that have long been seen as explicitly epistemic (Emig, 1977, 1982; Lauer, 1982), fostering the development of new knowledge through the ongoing negotiation of provisional knowledge. The notion of knowledge work has received increased attention in recent years, growing out of research in professional communication, technical writing, activity theory, and management studies (Spinuzzi, 2006, 2007). Johnson-Eilola explicitly links concepts in distributed knowledge work to Reich’s (1992) figurations of the symbolicanalytic, where professionals work “within information, filtering, rearranging, transforming, and making connections to address specific, specialized problems” (JohnsonEilola, 2005, p. 19). Spinuzzi defines knowledge work as “work in which the primary product is knowledge, information that is continually interpreted and circulated across organizational boundaries” (2006, p. 1). He also argues that knowledge work “tends to be organized in distributed, heterogeneous networks rather than in modular hierarchies” (p. 1). Increasingly, our students’ work mirrors that of professional knowledge workers as they grapple with information sources that are varied across geographies, cultures, and disciplinary or professional domains. Spinuzzi (2007) notes that this kind of work is “deeply interpenetrated, with multiple, multidirectional information flows” (p. 268). Most importantly, professional and technical writing scholars such as Grabill and Hart-Davidson (2010) attend to “what writing does” as an “epistemologically productive” activity (p. 1); attention to networked writing practices—what writing does—is therefore paramount to our understanding of the collaborative knowledge work of students. From a curricular and pedagogical perspective, a knowledge work approach may be seen as an integration of participatory pedagogies such as contributing student pedagogy (Hamer, Cutts, Jackova, Luxton-Reilly, McCartney, Purchase, et al., 2008), studio-based learning (Hundhausen, Narayanan, & Crosby, 2008), and participatory education (Jenkins, Purushatma, Weigel, Clinton, & Robison, 2009). These approaches share a philosophical foundation in constructivist, community-based learning. Hamer et al. define a contributing student pedagogy (CSP) as one that “encourages students to

96

/

DESIGNING WEB-BASED APPLICATIONS

contribute to the learning of others and to value the contributions of others” (2008, p. 194). Like the figurations of knowledge work described above, CSP is sensitive to the expectations of industry, where constructivist learning and communities of practice are organizational realities in distributed work environments. Studio-based learning (SBL) pedagogies apply techniques from art and architecture studios to create collaborative learning environments (Hundhausen et al., 2008). SBL is characterized by formal and informal formative evaluation by peers and experts, as well as students’ constructions of their own representations. While pedagogically significant in themselves, these approaches have meaningful implications for the design of curricula in fields beyond computer science and technical communication. Participatory education is a recent constructivist pedagogy based on theories of participatory culture, and it has seen increasing implementation in humanities curricula. Jenkins et al. (2009) provide the foundation for an understanding of participatory culture, a phenomenon that includes characteristics such as informal mentorship, strong social connections, and mutual validation of peer work. This view of participatory education may be productively articulated with knowledge work, CSP, and SBL approaches, where participation is always already grounded in collaborative literate activity, particularly in writing work. CSP, SBL, and participatory learning emphasize the role of collaborative communication activities (and the enabling technologies that support them) for making student contributions and peer feedback more visible and traceable. The ability to better trace and visualize these activities by developing applications that interoperate with a robust platform such as Google Wave affords significant opportunities for meaningful formative evaluation. ENABLING TECHNOLOGIES AND STUDENT KNOWLEDGE WORK A knowledge work approach to professional and technical writing must be enacted, at least in part, in digital environments that allow meaningful participation from relevant stakeholders. In these kinds of environments, opportunities for collaboration extend beyond coursework, foregrounding the need for students to be continually and explicitly metacognitive; that is, aware of how they model knowledge-sharing for and with others, online and off. The enabling technologies for these environments also establish multiple opportunities for formative evaluation, where peer feedback, instructor feedback, and even relevant community feedback can all be traced in realtime through epistemic writing work. For Hamer et al., “technology supports collaboration and communication and the development of attitudes and skills” (2008, p. 198). Perhaps more importantly, the enabling technologies of knowledge work should afford more robust surfacing and tracing of collaborative activities as a way to increase opportunities for formative evaluation. Google Wave, a platform explicitly designed to foster small-group collaboration via a wide variety of Web-based activities, affords specific advantages for knowledge work, namely, synchronous small-group collaboration, the persistent real-time visualization of writing work, and a pliable software-development environment. Backed by a robust developer community, an already large and growing ecosystem of Wave

VISUALIZING KNOWLEDGE WORK WITH GOOGLE WAVE

/

97

extensions (software plug-ins that interoperate with Wave), and the recent release of the Wave Data application programming interface (API), the development environment for enhancing educational uses of Wave is already rich (and, moreover, explicitly supported by Google’s Wave development team). More importantly, the latter two affordances have bearing on student metacognition and modeling practices. As a potentially synchronous writing environment, Wave can shape metacognition differently than asynchronous writing; this is akin to the differences in interaction that occur in face-to-face exchanges as opposed to an e-mail exchange. When students know that anyone can see them working in real time, they may think about their writing very differently. Moreover, writing within Wave is tangible and persistent. Students can return to examples provided by instructors or other students again and again, using the “playback” function to visualize the evolving character of knowledge work. Despite these affordances, Wave is limited. The playback feature, we have found, can be unwieldy when waves contain a large volume of content (which take the form of “blips”—self-contained, collaboratively editable chunks that may be comprised of writing, videos, files, or any combination thereof). Moreover, the playback feature gives one a sense of progression, but not a strong, easily identifiable sense of participation and interaction. Our work intends to visualize student knowledge work in ways that can be immediately grasped by all participants. In the way that a well-executed infographic might provide a concise snapshot of the scale and scope of contemporary advances in data storage (from kilobytes to yottabytes, for example), we’re developing visualizations that would provide participants in a given project with a concise representation of collaborative activity—who is contributing, how they are interacting with one another, and in what kinds of ways. By visualizing knowledge work in this manner, an instructor in a professional or technical writing course can swiftly move in and out of a series of collaborative student projects while knowledge is being made, with concomitant opportunities for formative assessment. Likewise, students can easily get a sense of their contributions and that of their peers, a step toward valuing each other’s work (Hamer et al., 2008). The application we’ve developed to attend to these aims is called Writing the Wave (WtW). .

LEVERAGING GOOGLE WAVE In professional and technical writing courses, there is a variety of student knowledge work scenarios where an enabling technology such as Google Wave can facilitate robust collaboration between several stakeholders within a single Web-based environment. In this section, we describe more specifically how we’re leveraging Google Wave by building applications that interoperate with Wave and Google App Engine, and how those applications provide a visualization layer that can help all parties better visualize project development, individual contributions, group collaboration, and the creation of knowledge. We begin this section by describing a specific use case for a professional writing course, moving from this typical curricular and pedagogical scenario into a discussion of the applications we’re developing, a rationale for why we are developing them, and a description of how they work.

98

/

DESIGNING WEB-BASED APPLICATIONS

Professional/Technical Writing Use Case Among the many use cases we envision for student knowledge work within Wave, collaborative research and writing with community involvement is especially trenchant since it involves coordinating the work of individuals with varying perspectives from potentially distributed domains (see Figure 1). Moreover, as we suggest above, the applications we’re developing specifically afford ample opportunity for formative evaluation from the instructor’s perspective. Take the following collaborative white paper assignment typical in our program’s undergraduate Professional Writing course, for example: Scott and Jean are students working collaboratively on a small-scale, 3-week research project exploring the specific writing practices of a community member, Bobby, on his mobile device. This is Scott and Jean’s first experience working directly with a research participant; using Wave, they work together to develop and implement interview questions, share notes from their respective observations of Bobby’s mobile writing practices, and discuss when and how to invoke outside sources alongside their primary research when writing their final white papers. In this scenario, Scott and Jean have started a new wave that houses all of the documentation associated with their project—from the original IRB protocol and informed consent, to PDFs of secondary

Figure 1. Distributed stakeholder participation within Wave.

VISUALIZING KNOWLEDGE WORK WITH GOOGLE WAVE

/

99

research, to videos and photographs of Bobby’s writing practices. Scott and Jean have added both Bobby and the instructor to their wave. Most importantly, the wave is not only a place to store and interact with data, it’s a way to manage versions of that data and to enable searchable, archived discussions of the data. In this way, many of the interactions that might have previously taken place across production channels (e-mail, IM, text editors, video editing applications) can be collected and continually referenced within a single wave. Throughout their process of contextual inquiry, Wave allows the direct participation of the research subject Bobby. Further, while Scott and Jean provide feedback to each other through the variety of media and conversations collected in the wave, they can also easily deploy member checks with Bobby throughout the process, thus validating their research claims by incorporating his direct involvement and feedback. Pedagogically, Wave provides the ability for the instructor to continually engage Scott, Jean, and Bobby throughout the research process. Our preliminary wave visualizations, for example, can allow an instructor to obtain a palatable update of progress, helping them to make more productive pedagogical interventions during, rather than after, the construction of knowledge. With this scenario in mind, we turn to a discussion of how the applications we’re developing operate within this general framework of Google Wave. Developing Web-Based Applications for Visualizing Student Knowledge Work Writing the Wave (WtW) is a software application that engenders real-time, continuous formative evaluation in collaborative creative processes. The system is an integration of several technologies, although the most critical component is Wave. From a software development perspective, Wave is best described as a contemporary reimagining of e-mail, newsgroups, and the collaborative Web. Wave blends conversation and collaborative document editing into one real-time environment: the team sees what is created as it is created, as intimated in the use case described above. For example, Figure 2 shows Wave in use by two authors who are collaboratively writing a conference proceedings paper. Wave allows anyone to write extensions that augment the core rich-text functionality. Existing extensions available to all Wave users include applications that provide translation services, e-mail notifications, collaborative diagramming environments, and comment moderation services. It is important to distinguish between Wave, which is a communications protocol, and Google Wave, which is a free Web application that allows anyone to use the Wave protocol. The relationship between Wave and Google Wave is analogous to the relationship between e-mail and an individual client that uses the e-mail protocol, such as Microsoft Outlook, Google Mail, or Mozilla Thunderbird (Klensin, 2008). Wave is an open protocol that anyone may implement (Baxter, Bekmann, Berlin, Lassen, & Thorogood, 2009), and so neither data nor services are tied to Google. This is significant since it is the open nature of Internet protocols that propelled the rapid software changes of the late 20th century. The Wave protocol also allows for

/

Figure 2. Screen capture of Google Wave interface.

100 DESIGNING WEB-BASED APPLICATIONS

VISUALIZING KNOWLEDGE WORK WITH GOOGLE WAVE

/

101

institutions to operate their own secure Wave servers with fine-grained access controls, which is important for both commercial and academic applications. Figure 3 shows the software architecture of our system, which can be explained in the context of the use case discussed above. Scott creates a new wave and invites Jean, Bobby, and the instructor as collaborators, which is the norm for small-group projects in Wave. The team then adds the Writing the Wave Robot as an additional collaborator. In Wave, a robot is a virtual collaborator, a software agent that can participate according to its programmed behavior. In this instance, the WtW Robot is a silent collaborator that collects interaction data in real-time. The four human participants continue to interact with Wave normally, using it to discuss the project as well as collaboratively edit the primary deliverable, all while the WtW Robot records activity to a data store. The WtW Robot itself is a Java application that runs on Google App Engine, Google’s public cloud computing service. This means that there is not one physical server on which the WtW Robot exists; rather, it is distributed throughout Google’s global network. This gives us scalability and robustness well beyond the capacity of most academic computing systems. Data collected by the WtW Robot is presented back to the users via interactive visualizations (see Figures 4 and 5). Information visualization techniques leverage human perception and cognition to help people make decisions based on data (Spence, 2007). In our Writing the Wave application, there are two contexts for interactive visualization: the WtW Gadget is embedded directly into a wave while the WtW Dashboard is viewed through a Web browser. Both are Web services that, like the WtW Robot, run on Google App Engine. The gadget contains compact visualizations that

Figure 3. Software architecture.

102

/

DESIGNING WEB-BASED APPLICATIONS

Figure 4. Preliminary chart of contribution activity.

Figure 5. Preliminary chart of contribution activity with conversational granularity.

allow a collaborator, at a glance, to understand the history and status of the wave. The dashboard is a complementary view that contains multiple visualizations (such as those above), each designed to highlight different aspects of the collaboration. The dashboard can be configured to show the status of multiple waves, and so it is equally useful for active collaborators as well as other stakeholders such as instructors and community partners. The Writing the Wave prototype contains several experimental visualizations based on contemporary theories of collaborative knowledge work. The design and evaluation of effective information visualization techniques requires significant qualitative

VISUALIZING KNOWLEDGE WORK WITH GOOGLE WAVE

/

103

analysis of the affordances and impact of Wave on writing. Visualization can both benefit from and contribute to the theories of real-time collaborative writing. An example of this phenomenon can be found in history-flow visualizations, designed to clarify the behavior of Wikipedia authors. The visualizations were based on functional properties of wiki technology, and the visualizations themselves revealed unforeseen collaboration patterns (Viegas, Wattenberg, & Dave, 2005). In a similar fashion, our work implements iterative design thinking approaches in which the theoretical models and visualizations evolve together and complement each other—a dynamic in which student knowledge workers are also explicitly involved. The multidimensional, in-depth, long-term case study approach described by Shneiderman and Plaisant (2006) provides a reference model for visualization evaluation within this research methodology. IMPLICATIONS AND FUTURE WORK Since our work is currently in the prototyping and testing stages, we have much to consider moving forward. We suggest, however, that one of the primary implications for embarking on this project is the focus it brings to the complex ways that students collaborate with technology—ways that increasingly foreground the centrality of writing activities to contemporary knowledge work. We also suspect that, by training student focus on the ways that they collaborate, that is, by promoting knowledge work as a curricular and pedagogical approach, and by making that activity explicitly visible and traceable, we can more effectively foster metacognition and reflective practice. Schön’s (1983) reflective practice is a way for participants to intentionally and deliberately reflect on their activities in order to improve future action. Schön argues that “Through reflection, [one] can surface and criticize the tacit understandings that have grown up around the repetitive experiences of a specialized practice, and can make new sense of the situations of uncertainty or uniqueness which [one] may allow [oneself] to practice” (p. 61). One way to encourage this kind of surfacing and criticizing of experiences is by visualizing the work that they do, some of which they may not be cognizant of until it is actualized through writing work. Schön (1983) argues that “when someone reflects in action, he becomes a researcher in the practice context. He is not dependent on the categories of established theory and technique, but constructs a new theory of the unique case” (p. 68). If Writing the Wave can help foster these kinds of reflective practices, then students interacting with the system would be well on their way to becoming knowledge workers in the main. Perhaps more importantly, we see our project—and similar software development projects in technical and professional communication—as a way to tap into the movement toward undergraduate research within our respective fields. When students are positioned as knowledge workers by curricula and pedagogies that ask them to attend metacognitively to their collaborations with others in and through their writing work, they have real opportunities to study writing itself—and writing with enabling technologies such as Google Wave—as complex mediated activity (Hart-Davidson, 2007). And in studying writing technologies, as knowledge workers, students may pursue real opportunities to make contributions to the field (see McNely, 2010). In this

104

/

DESIGNING WEB-BASED APPLICATIONS

way, by attending explicitly and metacognitively to the “rich social matrix of people and artifacts” (Kaptelinin & Nardi, 2006, p. 9), students have the means and opportunity to reflect in action (Schön, 1983) and move forward as researcher-students. In our project, for example, we have already involved undergraduate honors fellows and other undergraduate researchers in computer science to assist in the development of the Writing the Wave prototype. Positioned as knowledge workers at the confluence of technical communication and software development, these student researchers have the opportunity to do more than simply learn; they are expected to contribute meaningfully to the development, testing, and improvement of WtW. In doing so, they may not only bolster their theoretical and practical understanding of software development and collaborative knowledge work, they can contribute to the fields of technical communication and computer science. As these students collaborate with us in the development of WtW, their own reflective practice becomes the final step in undergraduate scholarship, following the standards established by Glassick, Huber, and Maeroff (1997, p. 35). Furthermore, the usage scenarios for WtW promote scholarly collaboration and creativity among broader groups of end users as well. Developing Web-based applications for the technical writing classroom and beyond, therefore, is viable scholarly work for undergraduate students, graduate students, and faculty. The understanding of writing and collaborative knowledge work as heavily mediated technological activity has long been acknowledged and championed in the fields of professional and technical communication. In designing and building Webbased applications, students, practitioners, and faculty in the field are contributing to that understanding in new and important ways, seeing the interfaces and applications that mediate knowledge work from the inside out. In doing so, we hope to contribute to even richer understandings of people acting with technology. Our future work consists of developing an evaluation plan for WtW and reflecting upon our own collaboration as a kind of meta-evaluation of an interdisciplinary approach that combines research in writing, education, software development, and information visualization. We are also interested in moving beyond the pilot studies we have planned for use in our own university to see how our application might work in larger scales. Improvements to the Wave interface for writing is also a concern, such that we move beyond building extensions that interoperate with Wave to actual changes in the user interface. Finally, we feel that a knowledge work approach with enabling technologies such as Wave can have a meaningful impact on education at-large via opportunities for immersive learning experiences that bring together multiple, real-world stakeholders from beyond the classroom. REFERENCES Baxter, A., Bekmann, J., Berlin, D., Lassen, S., & Thorogood, S. (2009, July). Google Wave Federation Protocol over XMPP, draft protocol specification. Retrieved from http://www. waveprotocol.org/draft-protocol-specs/draft-protocol-spec Emig, J. (1977). Writing as a mode of learning. College Composition & Communication, 28(2), 122–128. Emig, J. (1982). Inquiry paradigms and writing. College Composition & Communication, 33(1), 64–75.

VISUALIZING KNOWLEDGE WORK WITH GOOGLE WAVE

/

105

Glassick, C., Huber, M., & Maeroff, G. (1997). Scholarship assessed: Evaluation of the professoriate. San Francisco, CA: Jossey-Bass. Grabill, J., & Hart-Davidson, W. (2010). Understanding and supporting knowledge work in everyday life. Language at Work. Retrieved from http://www.languageatwork.eu/ readarticle.php?article_id=31 Hamer, J., Cutts, Q., Jackova, J., Luxton-Reilly, A., McCartney, R., Purchase, H., et al. (2008). Contributing student pedagogy. SIGCSE Bulletin, 40(4), 194–212. Hart-Davidson, W. (2007). Studying the mediated action of composing with time-use diaries. In H. McKee & D. N. DeVoss (Eds.), Digital writing research: Technologies, methodologies, and ethical issues (pp. 153–170). Cresskill, NJ: Hampton Press. Hundhausen, C. D., Narayanan, N. H., & Crosby, M. E. (2008, March 12–15). Exploring studio-based instructional models for computing education. Proceedings of the 39th SIGCSE Technical Symposium on Computer Science Education (pp. 392–396), Portland, OR. Jenkins, H., Purushotma, R., Weigel, M., Clinton, K., & Robison, A. (2009). Confronting the challenges of participatory culture: Media education for the 21st century. Cambridge, MA: MIT Press. Johnson-Eilola, J. (2005). Datacloud: Toward a new theory of online work. Cresskill, NJ: Hampton Press. Kaptelinin, V., & Nardi, B. (2006). Acting with technology: Activity theory and interaction design. Cambridge, MA: MIT Press. Klensin, J. (2008). Simple Mail Transfer Protocol request for comments 5321. Network Working Group. Retrieved from http://tools.ietf.org/html/rfc5321 Lauer, J. (1982). Writing as inquiry: Some questions for teachers. College Composition & Communication, 33(1), 89–93. McNely, B. (2010). Cultivating rhetorical dispositions through curricular change in technical and professional communication. In L. Grobman & J. Kinkead (Eds.), Undergraduate research in English studies: A sourcebook (pp. 229–244). Urbana, IL: NCTE. Nardi, B., & O’Day, V. (1999). Information ecologies: Using technology with heart. Cambridge, MA: MIT Press. Reich, R. (1992). The work of nations: Preparing ourselves for 21st century capitalism. New York, NY: Vintage Press. Schön, D. (1983). The reflective practitioner: How professionals think in action. London, England: Temple Smith. Shneiderman, B., & Plaisant, C. (2006, May 23). Strategies for evaluating information visualization tools: Multi-dimensional in-depth long-term case studies. Proceedings of the 2006 AVI Workshop on BEyond Time and Errors (pp. 1–7), Venice, Italy. Spence, R. (2007). Information visualization: Design for interaction (2nd ed.). Upper Saddle River, NJ: Prentice-Hall. Spinuzzi, C. (2006). What do we need to teach about knowledge work? [White Paper]. Retrieved from http://www.drc.utexas.edu/research/what-do-we-need-teach-about-knowledge-work Spinuzzi, C. (2007). Guest editor’s introduction: Technical communication in the age of distributed work. Technical Communication Quarterly, 16(3), 265–277. Spinuzzi, C. (2009). Starter ecologies: Introduction to the special issue on social software. Journal of Business and Technical Communication, 23, 251–262. Viegas, F., Wattenberg, M., & Dave, K. (2004, April 24–29). Studying cooperation and conflict between authors with history flow visualizations. Proceedings of the SIGCHI Conference on Human Factors in Computing Systems (pp. 575–582), Vienna, Austria.

http://dx.doi.org/10.2190/DWBC7

CHAPTER 7

Students Playing as Scholars and Selves: Academic Synthesis as Conversation Game David Fisher and Joe Williams

In his classic article “Inventing the University,” David Bartholomae argues that writers entering the university find themselves submerged in a number of new communities, each replete with its own language and customs. In significant ways, these students are outsiders, working at the periphery of the community as they “try on peculiar ways of knowing, selecting, evaluating, reporting, concluding, and arguing” (2003, p. 623). At least part of our role as teachers of composition, then, is to help these students extend themselves, by successive approximations, into the commonplaces, set phrases, rituals and gestures, habits of mind, tricks of persuasion, obligatory conclusions and necessary connections that determine the “what might be said” and constitute knowledge within the various branches of our academic community. (2003, p. 634)

Bartholomae theorizes the role into which students (and all academic writers for that matter) extend themselves as a position of privilege or authority: We “must imagine for [ourselves] the privilege of being ‘insiders’—that is, the privilege both of being inside and established powerful discourse and of being granted a special right to speak” (2003, p. 631). Imagining this position is not easy for any writer in unfamiliar disciplinary or generic territory, regardless of prior experience or number of years of schooling. For example, Barbara Kamler and Pat Thomson write about the difficulties advanced graduate students have as they attempt to inhabit a position of authority while writing their dissertations. “Doctoral students,” they observe, “fret about whether they are interesting or persuasive; they fear that they will not make a contribution to knowledge” (2008, p. 508). Kamler and Thomson add that 107

108

/

DESIGNING WEB-BASED APPLICATIONS

these stressors often surface in student writing but are frequently misunderstood as poor writing when what is at stake is the difficulty of writing as an authority when one does not feel authoritative. So for example, when students write literature reviews, they may describe, rather than evaluate, the work of expert scholars; they may mask their own opinions and arguments with layers of who said what about what and with what effects, because they lack confidence and are afraid of taking a stand. (2008, p. 508; emphasis in original)

Writing in and for an academic community, then, is not just an issue of cognitive sophistication, but also involves a significant amount of identity work: a writer establishing who she is, why she is speaking, and why she (rather than someone else) has the authority to evaluate the work of other community members. Kamler and Thomson see text work and identity work going hand-in-hand: “texts and identities are formed together, in, and through writing. The practices of doctoral writing simultaneously produce not only a dissertation, but also a doctoral scholar” (2008, p. 508). This development of an academic identity through writing is borne out by a number of rhetorical scholars (Bazerman, 1988; Berkenkotter & Huckin, 1994; Dias, Freedman, Medway, & Paré, 1999; Prior, 1998; Thomas & Brown, 2007). The project we discuss in the following essay sprung from a desire to provide novice writers (writers new to the university, new to a major, or new to graduate-level studies in a discipline) a tool for thinking about, playing with, and peripherally participating in the discourse that composes the community they are entering. In short, our Web application, which we call “Article—The Game,” enables students to build a game in which, among other things, they dramatize scholarly conversations. It should come as no surprise that the driving metaphor behind the application’s design is the Burkean parlor, a notion developed by Kenneth Burke as he argued that we can understand all human action in terms of ritual drama. For him, ritual drama is “the Ur-form [of human action], the ‘hub,’ with all other aspects of human action treated as spokes radiating from this hub” (1973, p. 103; emphasis in original). In this drama of human action, people within a group create a “social structure of meanings” or a “collective revelation” that acts as a tool for charting (“sizing up real obstacles and opportunities in the world”) paths of action for the group and for forming the identities of the individuals in the group. Burke holds that this collective revelation is continually under development through a “cooperative competition” during which ideas are refined. Materials for this drama come from the “’unending conversation’” that’s taking place at the point in history in which we’re born or (for our argument here) when we seek entry into a community. In the following oft-quoted passage, Burke evokes this unending conversation: When you arrive, others have long preceded you, and they are engaged in a heated discussion, a discussion too heated for them to pause and tell you exactly what it is about. In fact, the discussion had already begun long before any of them got there, so that no one present is qualified to retrace for you all the steps that had gone before. You listen for a while, until you decide that you have caught the tenor of the argument; then you put in your oar. Someone answers; you answer him; another comes to your defense; another aligns himself against you, to either

PLAYING AS SCHOLARS AND SELVES

/

109

the embarrassment or gratification of your opponent, depending upon the quality of your ally’s assistance. (1973, pp. 110-111)

Part of our job as composition instructors, then, is to scaffold our students’ experiences of deep reading (“listening”), analysis and evaluation (“catching the tenor”) and writing (“putting in an oar”) which Burke mentions above. We believe that “Article—The Game” supports students as they work at discovering and inhabiting the position of authority posited by Bartholomae as well as Kamler and Thomson. At the same time, we see our Web application as contributing to the ongoing effort to help instructors integrate computer gaming and writing more completely in their curricula. This effort has a long and complicated history connected with the basic concepts of game and play. For instance, Johan Huizinga (1955) argues that in the area of communication, the Sophists were perhaps the original game players (and game teachers), treating the sphere of language as a competitive arena in which players (students) should use any means necessary to achieve victory. In the early days of composition, we can find evidence of interest in games and play as pedagogical activities as well (Troyka, 1973; Troyka & Nudelman, 1975). However, objections to the presence of games, play, and the imaginary (simulation) in pedagogy have made progress difficult. On this issue, Colby and Colby (2008) make three relevant points: 1. “In postindustrialized societies, the instantiation of capitalism has led to a ‘crisis of leisure time’ (Schor, 1992, p. 7) to the extent that games, play, and leisure are pastimes not only separated from work but not held in the same esteem.” 2. In the academic world and the sphere of education more generally, the separation between work and play is severe and constantly reinforced, as, among other cues, “years of children being told that homework must be finished before play perpetuates this distinction.” 3. Education continues to focus on “disciplining bourgeois subjectivity,” which “neglects activities not associated with serious self-improvement.” Computer and video games face the added challenge that they are often perceived as dangerous, even in the more general world of play (Reisinger, 2007). Thus, despite justifications for the use of computer and video games in literacy learning— justifications which show that learning through gameplay is highly effective (Colby & Colby, 2008; Fisher, 2006, 2007; Gee, 2003; Lacasa, Mendez, & Martinez, 2008; Sheridan & Hart-Davidson, 2008)—more is needed to legitimate a place for games in the writing curriculum. We believe our game contributes to this effort by enabling instructors as well as their students to dramatize disciplinary conversations, thus creating a bridge between the perceived worlds of work and play. WRITING WITH A GAME By now, many educators are familiar with the argument that video gaming embodies “a new kind of literacy” that “combines significant elements of traditional reading and writing with new literacies that pertain to accessing and evaluating information,

110

/

DESIGNING WEB-BASED APPLICATIONS

constructing complex narratives, decision-making, and navigating rich multimedia environments” (Owston, Wideman, Ronda, & Brown, 2009, pp. 977-978). Nevertheless, instructors who wish to use games in the classroom often have to find clever ways to work around “limited content alignment” between the game and existing curricula and teaching preferences (Lieberman, 2010, sec. 1, para. 6). One way to address this disconnect is for instructors and students to create their own games, which more fully embody course content. While several scholars (Lieberman, 2010; Owston et al., 2009; Prensky, 2008) point out that teachers and students may not have the expertise to produce a high-quality video game, Owston et al. suggest using “web-based game shells” as a means for closing the expertise gap: “Game shells do not require any sophisticated hardware or software, and developers do not need to perform complex programming tasks in order to create games using these shells” (2009, p. 979). “Article—The Game” is one such shell. It requires only that users have a browser with cookies and javascript enabled. In other words, all authoring and gameplay take place in the browser window. Playing “Article” Though there are several scenarios, we envision that our application could be of use in high school and university classrooms (among them, dramatizing historic events and developing interactive fiction), because of our research program, we have deployed the application in classes where the main focus is on integrating a number of sources in a synthesis paper or researched argument. In all our work thus far, we’ve used game building as an exercise leading up to the development of a traditional expository (bibliographic synthesis) or argumentative paper. The Studies The classes in which we are conducting our research are located in a 4-year public, metropolitan university in the South. At the time of the studies to which we refer in this chapter, the university had 12,209 students, including undergraduate and graduate. The student population was 64% White, 26% Black, 2% Hispanic, 1% Native American, 3% Asian, with 4% reporting unknown or nonresident alien. Examples and student feedback appearing in this chapter come from our pilot run of the application. This trial took place in a master’s-level course in our department’s Professional and Technical Writing program during the spring semester of 2010. The course is called Composition Theory (note that Composition Theory is not our teaching practicum course), and it focuses on familiarizing students with theory and research about studying and teaching composition. There were 14 students in the class and 6 volunteered to participate in the study. Ages of the participants ranged from 24 to 64 years. Of these participants, five were female and one was male. The purpose of this pilot study was to usability test the software and to gauge how students felt the use of the software impacted their learning with respect to course content and competency in assembling a number of sources.

PLAYING AS SCHOLARS AND SELVES

/

111

Data gathered for this pilot trial included pre- and post-interviews, as well as video and screen captures of sessions in which students talked aloud as they constructed parts of their games. We collected drafts and revisions of the synthesis papers students wrote during and after their game-building projects. We also archived the students’ games. The assignment for the game-building project and the related synthesis paper appears in the appendix. As of this writing we are also conducting research in sections of Composition II, the second course in our first-year composition sequence, which emphasizes research and documentation aimed at producing a 5- to 10-page-long researched argument. For this trial, we are examining the student papers to determine whether or not the game-building activity helps students better incorporate and synthesize sources. Specifically, we are comparing the work produced by students in two sections of composition taught by the same instructor. In one section, the instructor includes the game-building activity. In the other, he uses activities suggested by the course textbook (Brenda Spatt’s Writing from Sources, 2010). The Game “Article—The Game” is simple to play. Players1 try to make their way through a series of interconnected rooms. To move from room to room, a player has to collect keys that unlock the doors to adjoining rooms. The player discovers these keys by engaging in dialogue with avatars that occupy each room. In game parlance, these avatars are called “speakers.” Speakers can represent scholars, sources, or the game author acting as a guide. During her quest, the player may also interact with “media objects” that appear in each room. These media objects are images, videos, web sites, and other documents to which speakers refer during the conversation. Figure 1 shows a room from one of the games authored by a student in our pilot study. In this room, a number of scholars debate the validity of think-aloud protocols. We introduce students to the application and the game-authoring experience by having them play one or more sections (section is analogous to a floor of the building in which the game takes place) of a demonstration game, which embodies some element of course content. So, for example, for a first-year or persuasive writing course, the demonstration game includes rooms where discussions of logos, ethos, and pathos take place among the authors of the text we’re using for the class (e.g., Everything’s an Argument, “They Say/I Say,” or Writing from Sources), Aristotle, and a fictitious student. Another section of this demonstration game is a dramatization of Plato’s “Allegory of the Cave.” A third demo section is a series of rooms in which a number 1

In the following description of the game, we make the distinction between elements of the “player interface” and the “author(ing) interface.” The player interface (see Figure 1) is where players (readers) interact with the content. The authoring interface(s) are where people go to generate the content that appears in the player interface. The authoring interface is somewhat analogous to the toolsets that allow people to create new campaigns, adventures, or spaces in a dialogue-heavy role-playing game like Neverwinter Nights. Game authors move back and forth between the player and author interfaces as they construct, play, and test their games.

112

/

DESIGNING WEB-BASED APPLICATIONS

Figure 1. Player Interface—A room. This is a room from a conversation game about cognitive-process debate. Important player interface elements are numbered above and described below. 1. Speakers present in the room: A player clicks on these speakers to initiate conversations. 2. Conversation space: Conversations develop as an online chat might. Dialogue lines appear one after the other, and the timing of their appearance is based on the length of the line (i.e., longer lines, which would take longer to type in an online chat, take longer to appear in the conversation space. 3. Journal: A bit like a travelogue, the journal tells a player where she’s been so far. The journal includes information about what percentage of the rooms in the game have been visited and acts as a running bibliography of the speakers/sources encountered. Figure 4 shows the journal generated once a player reaches the room depicted above. 4. Navigation: Section (globe) and room (compass and room schematic). A lock on the compass represents a locked door. The player must engage in conversation in the room to obtain a key to unlock the door. A circled arrow on the compass represents an unlocked door. A player can click on the circled arrow to move to the next room. 5. Media objects: Media objects associated with speakers can help elaborate points using video, external web sites, images, or PDF files. 6. Player responses: Players shape conversations and determine the arc of the game by periodically selecting from choices presented here. These choices can result in a player obtaining a key that unlocks one of the adjoining rooms.

PLAYING AS SCHOLARS AND SELVES

/

113

of scholars discuss the literary canon and whether or not we should bring literature into the first-year composition class. In addition to exposing students to course content reenvisioned as dialogue, playing through parts of this demonstration game gives the class an opportunity to discuss “Article’s” game mechanics (i.e., exploring—sections and rooms; selecting—speakers and player responses; collecting—speakers and keys). As we proceed with students in examining how the demonstration game is made, we consider the following set of questions (Table 1).

Table 1. Questions About Demo Game Objective

• What is the object of this game? • How would you describe the way the game works to a friend? In other words, what do you have to do to complete this game?

Organization and Mechanics

• What are the organizational units of this game? • How do these units relate to each other? • How have the game authors organized this particular game using these units? • How might the demo game be organized differently? • What impact would reorganization have on the playing (reading) experience? • Describe how a room “works.” • What sorts of things can you do in each room? • How can you move to another room? • How do you know when you can move to another room? • What other actions are associated with your learning that you can move to another room?

Content

• Do speakers address each other directly? Do they clarify to whom they are talking to when they speak? What linguistic clues do they provide? • Do speakers frame their quotes as coming out of the works they have written? • In what ways do the speakers adhere to what you have come to know as traditional ways of quotation, paraphrase, and citation? • In what ways have they taken liberties? • Is there someone you’d consider a main character in each room? Why do you think this person is a main character (what does she/he do to make you think this)? • Are you surprised by any of the characters who appear in the game? Why? • How are media such as images, video, and external web sites incorporated into the game? What role do these objects play in the conversations taking place?

114

/

DESIGNING WEB-BASED APPLICATIONS

The questions suggest one of the central themes of the assignment sequence of which the game is a part: Discovering and using meaning-making resources afforded by a system or community. Throughout the discussion, then, we press students to think about the relationship of the (multimodal) texts they encounter in the game and how they mean vis-à-vis the traditionally configured texts that they have confronted in the course thus far. One specific example is signposting and transitions. Because the game works partially on a spatial logic rather than a strictly sequential one (like printed text), we encourage students to notice how the demo game authors orient players to the game spaces using visual and textual cues (these often happen in conjunction with key discovery during gameplay). We consider signposting and transitions as essential elements of game play and discuss how these strategies also contribute to readers’ understanding in other genres. Our hope, obviously, is that the game playing and building experience makes the need for signposting and transitions salient for students. We also believe that game construction provides student authors with a chance to practice these strategies. Building with “Article” Authoring within “Article—The Game” involves dramatizing the reading experience for those who play the game. Game authors create a series of rooms, fill those rooms with interesting and opinionated people, develop a conversation among them, and determine how much or what parts of that conversation should enable players to move to other rooms. It follows, then, that the authoring toolset has interfaces for creating and linking sections, rooms, and speakers into a conversational adventure. Spaces: Sections and Rooms Game authors create and rearrange sections using a list that allows them to drag and drop section titles to change their order (i.e., the order in which players encounter them in the game). Authors use a grid interface to create and rearrange rooms. Figure 2 shows the interfaces for working with sections and rooms, in turn. The Room Editor enables authors to drill down into room content to edit dialogue. They can also playtest (i.e., access the player interface shown in Figure 1) the room by clicking on the room title. Sources: Speakers and Media Objects Game authors enter speakers and media objects using a form that enables an avatar image and bibliographic information to be associated with a speaker or source. As we’ve shown above in our overview of the player interface and will explain in more detail below, speakers actually “speak” or are made to speak when the author identifies them as the producer of a dialogue line (i.e., an utterance in the conversation taking place in the room). Figure 3 shows the form for creating a speaker. “Article” is not a bibliographic management application, so authors must format their bibliographic entries themselves. During our trials thus far, we’ve asked students

PLAYING AS SCHOLARS AND SELVES

/

115

Figure 2. Authoring Interface—Section Editor and Room Editor. Section Editor: Game authors drag and drop section titles to change the order in which players encounter them. Room Editor: Authors drag and drop room (boxes) to change the layout of the rooms within a section. Red padlocks indicate doors between the rooms.

to use Zotero (a free Firefox extension) in conjunction with “Article” for creating, maintaining, and formatting bibliographic entries for their games. In fact, we view introducing students to bibliographic software as an important part of the work we do with “Article.” Source information appears when the player clicks on the Journal icon (Figure 4, upper-right corner) during gameplay and displays a list of all the sources/speakers encountered thus far. Conversations: Dialogue Lines Conversations take place within each room. Players initiate conversation by clicking on one of the people who are in the room (the avatars appearing on the left side of the

Figure 3b. Player Interface—Journal: A bit like a travelogue, the journal tells a player where she’s been so far. The journal includes information about what percentage of the rooms in the game have been visited and acts as a running bibliography of the speakers/sources encountered.

/

Figure 3a. Authoring Interface—Speaker Editor: Speakers utter dialogue lines that comprise the conversations taking place in each room.

116 DESIGNING WEB-BASED APPLICATIONS

PLAYING AS SCHOLARS AND SELVES

/

117

Figure 4. Authoring Interface—Dialogue Line Generation: This dialogue line corresponds with the line appearing in the Chat area of Figure 1. 1. List of speakers generated using the form shown in Figure 3a. 2. Dialogue line itself: What the speaker is saying. 3. Media objects (entered using a form similar to the one for speakers shown in Figure 3a) and keys associated with this dialogue line.

player interface shown in Figure 1). As we noted above, the conversation takes the form of an online chat among the people in the room. Game authors need to decide how they want to dramatize the conversation. For example, the student author whose work we use throughout this chapter decided to use a scholar (Beverly Zimmerman) as a guide or discussion leader. She then used a combination of paraphrase and direct quotation from the sources she consulted as the dialogue lines spoken during the conversation. Other students fabricated panel discussions in which each speaker made a series of short speeches. Finally, some opted for the conversational free-for-all, in which people—speaking words from their publications, but also using words and gestures most decidedly not from their publications—argued their points. Game authors create dialogue lines using the form shown in Figure 4. To enable players to move from room to room, game authors must assign keys (“Doors this line opens,” Figure 3, #3) to dialogue lines. When the player reads these lines, she is then given access to the adjoining room unlocked by that key.

118

/

DESIGNING WEB-BASED APPLICATIONS

As we mentioned in the previous section, dialogue associated with unlocking other rooms gives student authors practice with signposting and transitions. For example, one game author (Student A) was very careful to associate summing up statements with the dialogue line that accompanied the discovery of a key: “You’ve heard a lot about the literary canon now, so you might want to explore the relationship between reading and writing. That door is open now, if you want to head east.” Obviously this is not the kind of signposting we would expect to see in an academic genre, nevertheless, it is signposting, which is an important writing strategy that students need to learn, especially as they move into developing longer pieces of writing. It also shows that the student is developing a sense of what her audience needs in this particular context to understand what it is they should have learned from the room and what to do next. In addition to lines uttered by speakers, the game affords the ability to enter stage directions and to create “Player Responses,” which are the choices presented to players at various points in the conversation. Both of these functions are also handled by the interface shown in Figure 4, #1. However, rather than selecting a “Speaker” as the Line Generator Type (Figure 4, #1), the game author selects “Game Robot.” In the application’s current instantiation, there are two kinds of game robots: “Game Info” and “Player Response.” Game Info enables authors to write stage directions or other notes to players without having to place those words in the mouth of a person in that room (i.e., a speaker). Figure 5 shows how a Game-Info line appears in the Chat area of the player interface. Player Responses appear at the bottom of the player interface (see Figure 1, #6). Once the game author creates a dialogue line and optionally associates it with media object(s) or key(s), she’s returned to the list of all the dialogue lines produced for the room thus far. This list of lines is the interface for organizing the dialogue lines into conversations. Figure 6 shows part of this list for the room depicted in Figure 1. Here, each of the people in the room (those whose avatars appear on the left side of the player interface—Figure 1, #1) is represented by what we call a “root” dialogue line. This line can serve as the provocative opening salvo in a conversation or can suggest that the player go talk to someone else in the room before interacting with this particular avatar.

Figure 5. Player Interface—Stage Direction: The game author creates stage directions by entering text uttered by a special kind of speaker, the Game Robot (Student E).

PLAYING AS SCHOLARS AND SELVES

/

Figure 6. Authoring Index—Dialogue Arrangement: Conversation that ensues when player clicks on speaker M. Cooper. Authors can rearrange these entries by dragging and dropping them within the nested list. 1. 2.

Conversations collapsed under first speaker. Dialogue takes the form of a nested list. Replies are indented.

3. Indicators about keys and media objects associated with the dialogue line. 4. & 5. Dialogue branches after a player response.

119

120

/

DESIGNING WEB-BASED APPLICATIONS

This line amounts to the first utterance in a conversation that starts when the player clicks on this speaker’s avatar. Other speakers’ rejoinders to this root line and to those who have spoken before them in this conversation are nested beneath, with each subsequent contribution to the conversation indented a little further. In game parlance, then, each room has as many “conversations” (i.e., chats started by clicking on an avatar) in it as there are speakers present in the room, or root dialogue lines in the interface shown in Figure 6. To change the order in which the lines appear in a conversation, the game author drags and drops a line onto another under which (immediately after which, in gameplay) she wishes that line to appear. Authors can also duplicate lines and drag them to other conversations in the same room. This feature helps with creating complex dialogue trees. CONCLUSION By having our students build and play, rather than exclusively play, a video game, we’re following the lead of scholars like Owston et al. who note that “giving students opportunities to input their own content into a game can be a powerful motivational tool that contributes to a sense of pride and accomplishment, and facilitates learning” (2009, p. 979). While we are still early in our process of gathering data about the impact “Article—The Game” has on students and their writing, we share below a few preliminary observations about how students have used and responded to the game. As we’ve suggested above, building a conversation game changes the students’ relationship to the scholars and texts they’re using while still involving them in reading and writing practices thoroughly related to the curriculum. As our data tentatively shows, shifting from a classroom space to a game space (Colby & Colby, 2008) creates what Huizinga (1955) calls a “magic circle” (p. 10). In the magic circle, the rules for behavior and relationships change. Players are given permission to take on roles that they would otherwise not consider permissible. In the classroom space, our students saw scholarly texts as objects to be accessed for bits of knowledge. In the game space—the magic circle—they felt permitted to treat the texts as other human inhabitants of the magic circle: arguing with them, debating them, questioning their ideas, and even poking fun at them. Roger Caillois (2001/1958) argues that the same mask-wearing that takes place during Carnival and other cultural festivals where authority systems are inverted is present in play forms involving simulation. It is the ability within the magic circle to challenge (and, at the extreme, even to mock or destroy) authority that our students found liberating. Also, for several of the students in our courses, the role of game author proved more comfortable to inhabit than that of student writer. A student from the graduatelevel pilot course represents this view when she says, “Since I like technology and I’m on the computer way too many hours of the day anyway, I though it made research . . . a lot more fun. To frame it as a game, as a technology thing, made the research less intimidating to me.” When pressed about what she meant by

PLAYING AS SCHOLARS AND SELVES

/

121

“less intimidating,” she said, “These [scholars] are just people talking, like on Facebook” (Student B). Treating the learning space as a magic circle, and treating scholarly texts as scholarplayers in that circle rather than objects appears to have another benefit. Because students have to recast essays they read as dialogue among people, they are forced to act with (rather than only be acted upon) scholars and their texts. The magic circle not only allows students the liberation to challenge authority, which Caillois argues that mask-wearing makes possible, it also allows them to recast texts as other mask wearers, viewing them as avatars representing people with minds rather than decontextualized objects. Because of this, our current research project explores whether, in addition to reinforcing disciplinary content, creating dialogue adventures aids students in moving beyond a “search-and-abstract” approach to literature review and enables writing that exhibits fuller competency with analysis, synthesis, and evaluation. The way one student described her experience makes us hopeful that such is the case: I have a character . . . take a stance and then I’d have to like oh, well what about this other character? How do they respond? And so I go back to the research, you know, and find something that they [the responding character] could say to respond to that, and then the dialogue goes, and then the second point comes up, and I’m like, oh, well, how are they going to respond to that, so I’m like [laughs] back to the research and just to have them talk to each other. And sometimes I even had to kind of guess based off what . . . ’cause they weren’t explicit in everything they believed. And they’re not addressing each other specifically in their articles, and so I would just have to kind of say they believed this and this and this, so they probably believe this point too. And I just made an educated guess. (Student A)

This student is not just synopsizing sources. Engaging in the process of dramatization has impacted her reading process, the way she encounters and thinks about her sources. Not only does she seem to be developing an understanding of how people contribute to disciplinary knowledge, she’s seems to be developing her ability to extrapolate, an ability that’s essential for building and applying theory. Finally, as we continue with our research, we’re refining the design of the “Article” application itself. Chief among our goals is making the player experience more gamelike (beyond its current feel of interactive fiction) by elaborating the existing mechanics of exploring, selecting, and collecting, and by experimenting with new ones that seem to fit with the dramatic metaphor that informs the application. One such mechanic might involve players generating reviews or rejoinders (critical or summary texts) about the conversation that takes place in each room and rating reviews/rejoinders created by other players. Activities like this, we believe, would further help our students understand not only the relationship of play to our game, but to the academic writing “game” more traditionally conceived.

122

/

DESIGNING WEB-BASED APPLICATIONS

APPENDIX Assignment Sheet from Composition Theory Class: Game Invention/Synthesis Essay Assignment

Background A strong research article usually begins with an exploration of what a number of sources have said about an idea by placing those sources into a scholarly conversation. We opened the course with an excellent example of this kind of scholarly conversation when we read Nystrand et al.’s intellectual history of composition studies. Nystrand and his colleagues effectively created conversations among linguists, psychologists, literary theorists, and educational theorists. For this assignment, you’re going to develop a synthesis essay about some aspect of composition studies, preferably one that helps inform the development of your plan for a first-year composition course. The goal of this essay will be to synthesize what several sources observe, suggest, prove, etc., about one or more aspects of composition theory. Possible topics for research include • Developing effective writing assignments • Assessing student papers • Using peer review • Using literature in the composition course • Teaching grammar • Teaching multiple Englishes (i.e., Ebonics, etc.) • Working with English as a second language (ESL) students • Working with basic writers • Choosing an appropriate textbook To help with invention for your synthesis essay and to make the product of your research interesting for your peers, you’re going to use a web application that lets you develop scholarly conversations as games that others can play.

Game Planning The article-builder web application you’ll use for this assignment enables you to develop a kind of conversation game. You’ll build conversations among people who occupy a series of rooms within a building.

PLAYING AS SCHOLARS AND SELVES

/

123

You can think about game construction with the help of the following questions. Question

Game Heuristic

What are the key ideas you need to address in your synthesis of this topic?

Key ideas become the theme of a conversation taking place in a room.

Who has said important things about this idea?

Important thinkers become the speakers in your room.

What have people said and how do their ideas relate to each other? How are they similar? Different?

These varying “takes” become the material of the conversation. Are speakers having a heated argument? Does someone come to the rescue by providing a new “take”?

What do you (as game adventure designer) have to say to/about these speakers and what they are saying?

You (as guide) can also be a speaker in the room.

What role do you want your reader to play in determining the path the conversation takes?

Readers decide who initially speaks. Readers can help direct a conversation through choices presented to the readers in the middle of the conversation.

Asset Gathering As part of the game development process, you’ll need to do some research and gather some assets. Of course, you’ll need to read articles. But you will also need to assemble a compliment of graphics that can serve as avatars for the speakers in your game. For example, if one of your speakers is Andrea Lunsford, you’ll need to find a picture of her or a picture of something you think visually represents her. The article-builder software also allows you to include what we call “media objects” in your game. So, for example, if you want to have one of your speakers talking about a particular YouTube video, website, or image, you can include a link to that object in the part of the conversation in which the speaker refers to the artifact. Deliverables Game: At the very least, you should create three rooms fit for other people in the class to play through. Essay: During or after development of your conversation game, you need to develop a synthesis essay in which you inform readers about the areas you’ve researched. Sections of Nystrand et al.’s article are pretty good examples of what this essay might look like, as are the literature review sections of the articles we’ve read in Cross Talk in Comp Theory and A New Literacies Sampler. This document should be at least five-pages, not including your works cited page and should follow a common citation format (e.g., APA, MLA).

124

/

DESIGNING WEB-BASED APPLICATIONS

REFERENCES Bartholomae, D. (2003). Inventing the university. In V. Villanueva (Ed.), Cross-talk in comp theory: A reader (2nd ed., pp. 623–653). National Council of Teachers of English. Bazerman, C. (1988). Shaping written knowledge: The genre and activity of the experimental article in science. Madison, WI: University of Wisconsin Press. Berkenkotter, C., & Huckin, T. N. (1994). Genre knowledge in disciplinary communication: Cognition/culture/power. New York, NY: Routledge. Burke, K. (1973). The philosophy of literary form: Studies in symbolic action (3rd ed.). Berkeley, CA: University of California Press. Caillois, R. (2001). Man, play, and games (M. Barash, Trans.). Urbana, IL: University of Illinois Press. (Original work published 1958.) Colby, R. S., & Colby, R. (2008). A pedagogy of play: Integrating computer games into the writing classroom. Computers and Composition, 25, 300–312. Dias, P., Freedman, A., Medway, P., & Paré, A. (1999). Worlds apart: Acting and writing in academic and workplace contexts. Mahwah, NJ: Lawrence Erlbaum Associates. Fisher, D. (2006). Remediating the professional classroom: The new rhetoric of teaching and learning. Retrieved from http://129.186.1.120:81/ipac20/ipac.jsp?uri=link=3100014~ !3278220~!3100001~!3100002&profile=parks Fisher, D. (2007). CMS-based simulations in the writing classroom: Evoking genre through game play. Computers and Composition, 24(2), 179–197. doi: 10.1016/j.compcom.2006.06.004 Gee, J. P. (2003). What video games have to teach us about learning and literacy. New York, NY: Palgrave Macmillan. Huizinga, J. (1955). Homo ludens: A study of the play element in culture. Boston, MA: Beacon Press. Kamler, B., & Thomson, P. (2008). The failure of dissertation advice books: Toward alternative pedagogies for doctoral writing. Educational Researcher, 37(8), 507–514. Lacasa, P., Mendez, L., & Martinez, R. (2008). Bringing commercial games into the classroom. Computers and Composition, 25, 341–358. Lieberman, M. (2010). Four ways to teach with video games. Currents in electronic literacy, 2010: Gaming across the curriculum. Retrieved from http://currents.dwrl.utexas.edu/2010/ lieberman_four-ways-to-teach-with-video-games Owston, R., Wideman, H., Ronda, N. S., & Brown, C. (2009). Computer game development as a literacy activity. Computers & Education, 53(3), 977–989. doi: 10.1016/j.compedu.2009.05.015 Prensky, M. (2008). Students as designers and creators of educational computer games: Who else? British Journal of Educational Technology, 39(6), 1004–1019. doi: 10.1111/j.14678535.2008.00823_2.x Prior, P. A. (1998). Writing/disciplinarity: A sociohistoric account of literate activity in the academy. Mahwah, NJ: Lawrence Erlbaum Associates. Reisinger, D. (2007). Video games are almost as dangerous to public health as cigarettes? CNET News. Retrieved from http://news.cnet.com/8301-13506_3-9826609-17.html Spatt, B. (2010). Writing from sources (8th ed.). Bedford: St. Martin’s. Sheridan, D. M., & Hart-Davidson, W. (2008). Just for fun: Writing and literacy learning as forms of play. Computers and Composition, 25, 323–340. Thomas, D., & Brown, J. S. (2007). The play of imagination: Extending the literary mind. Games and Culture, 2(2), 149–172. Troyka, L. Q. (1973). A study of the effect of simulation-gaming on expository prose competence of college remedial English composition students. Dissertation Abstracts International, ED090541. Troyka, L. Q., & Nudelman, J. (1975). Taking action: Writing, reading, speaking, and listening through simulation-games. Englewood Cliffs, NJ: Prentice-Hall.

http://dx.doi.org/10.2190/DWBC8

CHAPTER 8

Designing, Implementing, and Evaluating a Web-Based Instructional Application for Technical Communication Classes David Chapman

Many of the advantages of Web-based learning are equally relevant for in-class learners as for distance learners, and there is a growing trend to incorporate a Webbased component into the traditional classroom environment. At a fundamental level, Web enhancement allows classes to “combine the advantages of synchronous learning with asynchronous learning” (MacEntee & Lewis, 2004, p. 951). Whereas asynchronous learning environments allow scheduling flexibility, may lead to increased active knowledge acquisition (MacEntee & Lewis, 2004), and can preserve a degree of anonymity, synchronous learning environments (i.e., traditional classroom environments) may have a higher degree of social presence (Richardson & Swan, 2003). A number of studies have shown that Web-enhanced classes can result in higher student satisfaction (Buckley, 2003), increased learning (Sanders & Morrison-Shetlar, 2001; Tuckman, 2002), and improved critical-thinking skills (Sanders & MorrisonShetlar, 2001). Although many studies indicate the positive learning value of Web-enhanced classes, the literature has focused primarily on the use of course management software or content delivery through the instructor’s Web site as the Web-enhanced tools of choice (e.g., Jiang & Ting, 1999; MacEntee & Lewis, 2004; Rivera & Rice, 2002; Sanders & Morrison-Shetlar, 2001; Schmidt, 2002; Swan, 2001). A number of learning theories and empirical studies can inform the design of novel, custom-built Web-based applications that can be used within the classroom environment. The key to designing successful Web-based instructional applications is to “incorporate the unique advantages of the technology rather than simply mirroring that of conventionally taught courses” (Tuckman, 2002, p. 261). The purpose of this study was (a) to use existing learning theories and empirical research on Web-enhanced content delivery to inform the design and implementation of an interactive Web-based instructional application that is appropriate for an 125

126

/

DESIGNING WEB-BASED APPLICATIONS

undergraduate technical communication class, and (b) to evaluate the application in an undergraduate technical communication class to gain an understanding of successful design considerations for this environment. In the evaluation phase, this study sought to understand the undergraduate technical communication students’ perceptions of the Web-based instructional application based on the four parameters of class relevance, perceived learning, motivation, and overall value. APPLICATION DESIGN The initial design process focused on identifying potential features that would facilitate learning in an undergraduate technical communication course. The general outline was conceived prior to the literature review process and was based on informal observations of students in technology-enabled classrooms. The existing theoretical and empirical literature was reviewed to either corroborate or modify the initial design decisions to reflect the current knowledge of effective Web-based instruction. The primary design considerations that emerged from this process were the inclusion of equivocal tasks, anonymous peer evaluation, and class discussion and instructor feedback as separate, sequential steps in the application. Equivocal Tasks Equivocal tasks are tasks that require a high degree of critical thinking and active engagement. The decision to focus the students’ efforts on equivocal tasks was based on the assessment that engaged learning “involves active cognitive processes” (Kearsley & Schneiderman, 1998, p. 20), and the inclusion of equivocal tasks is supported by both engagement theory and cognitive-load theory (Kearsley & Schneiderman, 1998; Sweller, van Merrienboer, & Paas, 1998). Equivocal tasks, rather than tasks that have predefined, correct answers, were also necessary to support subsequent steps of the application. Because one of the subsequent steps requires students to comparatively evaluate their peers’ task responses, nonequivocal tasks were determined to be unsatisfactory. Highly equivocal tasks benefit from a mix of high- and low-richness delivery media. If the media is not rich enough, the equivocality of the task cannot be sufficiently communicated, whereas if the media is too rich, the extraneous cognitive load on students inhibits learning (Robert & Dennis, 2005). Although in this application the tasks are presented in a text-based format (low richness media), the culmination and synthesis of the learning process occurs afterward in an instructor-led class discussion (high richness media). This mix of high and low media richness appropriately reflects the nature of the tasks and should aid the learning process. Anonymous Peer Evaluation Anonymous peer evaluation was determined to be an effective way to include a collaborative component in the application. Collaboration is one of the key aspects of engagement theory, and peer evaluation is specifically mentioned as a form of collaboration within the context of this theory (Kearsley & Schneiderman, 1998). The

DESIGNING, IMPLEMENTING, AND EVALUATING

/

127

peer-evaluation portion plays multiple roles in the students’ learning process. First, it exposes the students to their peers’ task responses and the different points of view of their peers. This exposure can immediately result in learning as students evaluate the effectiveness of their peers’ responses and as they construct cognitive schemas that help them understand their peers’ task-completion strategies. Second, although peer evaluation is a form of collaboration and interactivity among students in the class, designing the application to present the peer evaluation as a private, anonymous process, may be especially motivating for introverts (MacEntee & Lewis, 2004). By routing the evaluation process through the computer, students are removed from direct contact with each other, which should motivate students who would be uncomfortable orally critiquing other students’ work. Class Discussion and Instructor Feedback To take advantage of the face-to-face presence of the students and the instructor, a concluding class discussion step was incorporated. The class discussion centers on the results of the anonymous peer evaluations in the previous step. The design concept was that all of the individual peer reviews would be aggregated to produce an anonymous ranking of the students’ task responses, as evaluated by the students in the class. Because all of the students will already have invested themselves in the review process, individuals who would normally be reticent to participate in an oral class discussion may be more intrinsically motivated to do so. By incorporating both forms of interaction (anonymous in the evaluation step and face-to-face in the discussion step), the application may also appeal to a larger number of students than if only one form of interaction was used. And, as noted above, the high richness of the face-to-face discussion complements the low richness of the task-completion step. Instructor feedback is critical to keeping the students focused on the true learning objectives—students may feel that a particular task response was effective, but the instructor may feel otherwise. By guiding the class discussion, the instructor has an opportunity to evaluate the students’ progress and to give them a learned perspective. Therefore, the design should allow the instructor not only to respond to the students’ selections but also to discuss other task responses that the students may not have found effective. Web-based applications that focus on student interaction and contribution may successfully aid the learning process (Abbitt, 2007). Therefore, the class discussion step may be especially important because it allows the students and instructor to actively contribute to the class’s knowledge building. In addition, the learning that results from the class discussion is expected to inform the students’ task responses and peer evaluation in subsequent uses of the application. IMPLEMENTATION Implementation of the application was guided by the design considerations developed earlier. The application consisted of an interface for the students, a separate interface for the class instructor, and a central database and associated code that was hosted on a commercial Web server. The database acted as the central information

128

/

DESIGNING WEB-BASED APPLICATIONS

repository that stored class-relevant tasks, tracked students’ task responses, tracked students’ anonymous peer evaluations, and stored the “state” information associated with each session. The technologies used to create the application were all freely available: MySQL for the back-end database, phpMyAdmin as a Web-based front-end database development tool, XHTML and CSS for the Web page markup, and JavaScript and PHP for the clientside and serverside scripting. AJAX (asynchronous JavaScript and XML) was used to achieve interactivity without requiring the user to initiate actions on the site and without requiring full-screen refreshes after each completed action. AJAX creates a more responsive environment with which the user can interact, which may play a role in user perception of the interactivity level of the application (i.e., the degree to which a meaningful dialog exists between the student and the application; Sims, 2003). Numerous other technologies could have been used to create the application. For example, rather than PHP and MySQL, the serverside portion of the site could have been designed with ASP.NET and SQL Server. Alternately, the site could have been written as a Java applet. Because of the range of options available, implementation of a Web-based learning tool for use in one’s own classroom is perhaps best completed using technologies that are familiar to the implementer. I chose PHP and MySQL because I had some prior experience with them, and I wanted to minimize development time by avoiding learning new programming languages and database tools. With amateur-level programming skills and copious use of online forums and tutorials, I was able to write the application code in a month on nights and weekends. However, no antihacking measures were implemented, making the site vulnerable to attack. If the site had been deployed to the public, it would have required a more robust code base and a skilled implementation team. Detailed Overview The following overview assumes the application would be used in a computerenhanced classroom setting. It is possible to use the application in an online class, but certain timing and class discussion details would be slightly different from what is presented here. The application’s home page consisted of a login area for students and a separate login area for instructors. After login, the instructor is taken to a class management page, which displays a list of the classes the instructor has registered with the site. To add a new class, the instructor provides some basic class information, such as the class name, begin and end dates, and the class roster. The roster is used by the system to track the responses of the individual students when they log in to complete exercises. After adding a class, the instructor adds a session to the class, which refers to a distinct exercise in which the students will participate. For the purposes of this research, the instructor only had the option to create an “open response” session, in which the students were free to submit freestyle responses and vote on their peers’ responses. An example of the instructor’s screen, after adding a class and four sessions, is shown in Figure 1.

DESIGNING, IMPLEMENTING, AND EVALUATING

/

129

Figure 1. A class and its associated sessions. The session named “Exercise #1” is open and ready for the students to complete.

After an instructor has opened a session, the students can log in to the site and begin the exercise. Sessions that the instructor has marked as “open” are visible to the students when they log in. In Step 1 of the exercise, the student is given a class-appropriate task to complete (Figure 2). In the example shown, the student reads the task prompt and then responds in the text box. Once the student has entered a task response, the student clicks “next step.” If other students in the class are still working on their task responses, the system will notify the student that the session will automatically advance to Step 2 once everyone’s task responses are received. Meanwhile, the instructor is logged into the system and is monitoring the students’ progress in the session (Figure 3). For the first step, the instructor is shown a list of the students in the class, indicating which of the students have already responded to the task. As students submit their responses, the system automatically updates the instructor’s page. This status page allows the instructor to quietly monitor the class’s progress, which could lead the instructor to allow more or less time to complete the step. In addition to monitoring the class’s progress, the instructor also has the option of advancing the session to the next step at any time. This is useful if the instructor has a set time the students should have their responses completed by. Once all of the students have responded to the task and the instructor has advanced the session to Step 2, all of the students’ browsers automatically load the content for Step 2. In Step 2, the students are shown a series of random pairings of their peers’ task responses and are instructed to vote on one or the other in the pair (Figure 4). The instructions from Step 1 are shown at the top of the page for reference, and a status indicator at the bottom of the page shows the students how much progress they have made in the current step. In the example shown, the student

130

/

DESIGNING WEB-BASED APPLICATIONS

Figure 2. The students’ view of Step 1. The task response shown is a quotation of a study participant’s response.

is voting on the first of nine task pairs that will be displayed. After the student submits her vote, the vote is registered with the system, and the system loads the next random pair of task responses for the student to vote on. The number of votes that each student must complete is dependent on the total number of task responses that were submitted to the system by the class in Step 1. As implemented, each set of pairwise task responses is voted on once by a randomly chosen class participant, though other voting algorithms are possible. Students were never asked to evaluate their own task responses. As the students complete their votes in Step 2, the instructor’s status page displays each student’s progress (Figure 5). As in Step 1, the progress indicator bars automatically update when the students submit their votes, so the instructor is kept up-to-date with the students’ progress. In addition to the status report, the instructor is also shown each student’s task response. While the students are engaged in the voting process, the instructor can read the individual responses and select any of the responses that the instructor wants to comment on in Step 3 (the class discussion step). The instructor is free to use whatever criteria seem appropriate (e.g., excellent responses, problematic responses, or a combination of excellent and problematic responses). As in Step 1, when the entire class is finished voting, or if a time limit has been reached, the instructor advances the session to Step 3.

DESIGNING, IMPLEMENTING, AND EVALUATING

/

131

Figure 3. The instructor’s session status page, showing the status of Step 1.

Step 3 is a summary of the voting results, and the student and instructor pages for this step are identical (Figure 6). At the top of the page, the original task instructions are displayed for reference purposes. Immediately beneath the task instructions are the task responses that received the most student votes. The results are color coded according to first, second, and third place. There is no overt indication of the standing of the entries; this was a purposeful decision to deemphasize the potentially competitive nature of the session. Below the responses that received the most student votes are the responses that the instructor selected for further discussion. The primary purpose of the Step 3 screen is to act as a visual reference during an instructor-guided class discussion. The students can discuss their voting rationales, and the instructor can lead them through the discussion and talk about the responses that he or she picked in Step 2. The format of the discussion is entirely up to the instructor. If at the end of the class discussion the instructor would like the class to begin another session, the students can click “start another session” at the bottom of the page; otherwise, they can click “log out” or close the browser window to leave the application. Clicking “start another session” will bring them back to the page that lists all of the sessions for that class. Already-completed sessions are displayed in the Finished sessions section. Clicking a finished session will bring the student back to the Step 3 summary page for that session; keeping these pages available allows the students and the instructor to review past sessions.

132

/

DESIGNING WEB-BASED APPLICATIONS

Figure 4. The students’ view of Step 2. The task responses shown are quotations of the study participants’ responses.

IN-CLASS EVALUATION To assess the effectiveness of the application in a classroom setting and to gain an understanding of its strengths and weaknesses, the application was evaluated in a technical editing course at Minnesota State University, Mankato in spring 2008. The study participants consisted of a convenience sample of the 19 undergraduate students enrolled in the class (12 male, 7 female). All of the study participants provided their informed consent prior to commencement of the study. Two in-class evaluation sessions were conducted on separate days. After each evaluation session, the study participants completed a written survey designed to measure their attitudes toward (a) the relevance of the application to helping them achieve their learning goals, (b) their level of motivation to learn the material that was presented, (c) their perceived learning from use of the application, (d) the overall

DESIGNING, IMPLEMENTING, AND EVALUATING

/

133

Figure 5. The instructor’s view of Step 2, showing the students’ voting progress as well as the complete list of student responses from Step 1. The instructor can check which responses she wishes to discuss with the class later in the exercise. The task responses shown are quotations of the study participants’ responses.

value of the application for their education in the class, and (e) the three individual components of the application (e.g., the task completion step, the anonymous peer evaluation step, and the class discussion step). In addition to the surveys, one-on-one interviews were conducted with a voluntary subset of the study participants to elicit more detailed feedback than was possible from the written surveys. A total of 6 out of the 19 students participated in an interview. Participants were asked to talk about their rationales for their survey responses and were encouraged to discuss specific features of the application. The interviews followed a loose script, and follow-up questions were asked whenever elaboration or clarification of the participants’ responses was needed.

134

/

DESIGNING WEB-BASED APPLICATIONS

Figure 6. Step 3 session summary. The task responses shown are quotations of the study participants’ responses.

Evaluation Procedure The tasks the students were asked to complete in Step 1 of each session were designed to complement other recent class activities. For example, one of the tasks in the first evaluation session was to describe the responsibilities an editor has to the author, a topic that is central to the technical editing class; and the tasks given in the second evaluation session involved editing university policies, which was an activity the students had recently been exposed to in the preceding weeks of class.

DESIGNING, IMPLEMENTING, AND EVALUATING

/

135

The evaluations were conducted in a computer-enhanced classroom—every student and the instructor had access to an Internet-connected computer with which to access the application. At the beginning of the evaluation sessions, the students were instructed to navigate to the application’s Web site (no longer active), log in, and begin the first exercise. The students worked quietly on steps 1 and 2, while the class instructor and I monitored their progress using the instructor’s interface. While the students completed Step 2, the instructor evaluated each of their task responses from Step 1 and selected specific responses to discuss later in Step 3. After all of the students completed Step 2, the session summary displayed by the system was used as a visual reference during an instructor-led class discussion about the students’ voting results and the instructor’s response picks. After completion of the class discussion, the students were instructed to log in to a second exercise. The procedure for the second exercise was identical to the first, except that the students were given a different class-related task to complete in Step 1. After the second class discussion, the students were given the survey to complete. After collecting the completed survey forms, volunteers for one-on-one interviews were solicited. The one-on-one interviews were conducted on the university campus. Each student was shown his or her responses to the two surveys to prepare themselves for the interview. Afterward, the interview proceeded according to the general plan established in the interview script. RESULTS AND DISCUSSION The primary purpose of evaluating the application in a classroom environment was to determine whether or not the design and implementation resulted in an application that the students felt had relevance and value, was motivating, and resulted in classrelated learning. A discussion of each of these factors is included below, along with discussion of additional elements that emerged during the data collection process. Motivation After the first evaluation session, approximately 74% of the students indicated that they were motivated to learn the material presented in the exercise, whereas only 53% felt motivated during the second evaluation session. During the interviews, students discussed numerous motivating aspects of the application. Some students felt motivated by working on tasks that were relevant to the class. Two students identified the competitive aspect of the application as a motivating factor. Specifically for one student, the rankings in Step 3 motivated him to write a response in Step 1 that would be well-liked by his peers. Students also pointed to demotivating aspects as well. Two students noted that their lack of motivation stemmed from the difficulty of the class in general for them. They felt that they didn’t fully understand the material, which prevented them from thinking that they would be able to create high-quality task responses. Multiple students felt that there was no incentive to try hard on the exercises because they weren’t being

136

/

DESIGNING WEB-BASED APPLICATIONS

graded for the class. These students felt that this lack of incentive resulted in a minority of the class not taking the study seriously and not writing quality responses in Step 1. Overall motivation levels also may have been affected by the topic-based rather than project-based focus of the tasks they were asked to complete. Although a modest attempt at authenticity was made by phrasing each task as a real-world scenario (e.g., “The director of the university’s Placement Office has asked you to edit the following section of a status report . . . ”), in hindsight it is unlikely that this small attempt at authenticity was motivating. Because of timing restrictions during this study, it wasn’t possible to integrate the use of the application into a real-world project. This may have significantly lowered the perceived value of the application and the motivation level of the students to learn from its use. Relevance Approximately 74% of the students felt that the instructional application was relevant to helping them achieve their learning goals in the class—a percentage that was consistent from the first evaluation session to the second. One student felt that the relevance of the application was low because the tasks were not technical enough and because the students did not have to refer to their books for guidance. Two students felt that the task completion step was similar to other assignments they have completed in the class, which increased the relevance of the application for them because they were already familiar with that type of exercise. One student stated that the application was motivating because it was relevant, another student stated that the competitive aspect of the application was relevant because it was motivating, and a third student noted that the relevance depended on how motivated other students were in the class. The way the students chose to describe the connection between motivation and relevance—with motivation being alternately the cause and the result of relevance—speaks to the diversity of perspectives that can exist in within a single class. If an instructional application can be designed to be motivating, then it may, by corollary, be relevant to some students; and if it can be designed to be relevant to the class, then some students will derive motivation from that. Perceived Learning The primary goal of any instructional tool is the facilitation of learning. Therefore, measurement of students’ perceived learning through use of the application was critical to assessing its success or failure. After the first evaluation session, approximately 68% of the students reported that they had learned from the exercise, and after the second session, approximately 74% of the students reported that they had learned. Almost all of the interviewed students commented that they learned from the interactive class discussion in Step 3. Three students noted that they learned from seeing the student task responses that the instructor selected and from hearing him discuss his reasons for choosing them. Two other students stated that seeing how the class voted and listening to the instructor’s discussion helped them learn why some responses were more effective than others. And one student noted that the class discussion step had a reinforcing effect on them—it confirmed that they were “on the right path”

DESIGNING, IMPLEMENTING, AND EVALUATING

/

137

and gave them further confidence in their own task responses in subsequent sessions with the application. Overall, a large majority of learning-related comments made by the students during the interviews were related to the positive effects of group interaction. This result supports the arguments made by Kearsley and Schneiderman (1998) that engaged learning is most effectively promoted through collaboration. It also supports the notion that the distributed cognition of the group plays a role in developing individual cognition and schema formation. Value After the first evaluation session, approximately 68% of the students felt that the application had value for their education in the class, and approximately 63% felt that it had value after the second session. When asked about the value of the individual steps of the application, the students responded more favorably than they did to the application as a whole. Approximately 90% of the students felt that the task-completion step had value after the first evaluation session, 74% felt that the peer-evaluation step had value, and 74% felt that the class discussion step had value. These results were similar after the second evaluation session. However, after the second session, 21% of students strongly agreed that the class discussion step had value, which was the highest percentage of students who strongly agreed to an application-related question on either survey. Comments about the value of the application tended to concentrate on one aspect of the application in particular: that it exposed students to different perspectives. One student remarked that the class discussion during the second evaluation session had more value because students were engaged more in the discussion than they had been during the first evaluation session. The different perspectives the other students brought to the conversation were valuable to this student. Another student added that the instructor increased the value of the class discussion when he was able to convince students to speak about their opinions and rationales for voting the way they did. Interface Issues Multiple students wished that the task-completion step allowed the use of rich-text processing rather than plain text. As implemented, students could not use italics, bold, color, lists, or any other rich-text elements in their task responses. This was a weakness of the application and may have interfered with the students’ learning process. Rich-text capabilities were not included primarily because they were thought to be too technically difficult and time-consuming to implement. However, it was later determined that freely available libraries, such as the Yahoo! User Interface Library (Yahoo!, 2008), could have been incorporated into the application to enable rich-text capabilities with little extra development effort. In addition to rich-text capabilities, another commonly requested feature during the interviews was a “neither” button on the peer evaluation pages. Multiple students responded that for some of the pairs of task responses they were asked to evaluate, neither of the responses were effective. They would have preferred to vote for neither of

138

/

DESIGNING WEB-BASED APPLICATIONS

the responses rather than being forced to vote for a response they didn’t like. Incorporation of a neither button would be straightforward from an implementation point of view and would have a side benefit of reducing the number of votes received by less satisfactory task responses. Effective Use of Technology The majority of feedback received during interviews indicated that students felt the application was an effective use of technology, because it allowed them to interact with their peers on a whole-class basis rather than in small groups. One student stated that the ability to respond individually but also to compare results as a class in a “live session” was unique. This echoes the remarks of another student who appreciated the immediacy of the feedback received, as opposed to waiting a week or more for written feedback from the instructor (at which time the assignment would not be strongly remembered by the student). CONCLUSIONS This project demonstrated the viability of creating custom Web-based instructional applications that help students achieve their learning goals and make effective use of the computer technology that is commonly available in many college classrooms. The task completion step allowed students to apply their knowledge to complete a class-related assignment. The voting step and the class discussion step engaged the students in an interactive exercise, the value of which was dependent on the engagement all of the students in the class and the class instructor. Students responded especially favorably to the class discussion because it exposed them to diverse perspectives and allowed them an opportunity for critical evaluation and synthesis, which enabled them to respond more effectively to subsequent tasks. Motivation to engage with the application could be potentially increased by grading the task responses after the exercise is completed, incorporating the use of the application into a larger projectbased assignment and adding minor interface improvements such as rich text and a “neither” button in the voting step. It was found that implementation of a Web-based application is best completed using technologies that are familiar to the implementer. Numerous methods are available for the creation of interactive Web sites, and many of them would result in a similar end product. For this project, only freely available tools were used: HTML, CSS, JavaScript, PHP, MySQL, and phpMyAdmin. The text editor Notepad++ was used to write the code, the Firefox extension Firebug was used to troubleshoot errors in the code as development progressed, and numerous online forums and tutorials were consulted when my programming knowledge was not sufficient to move forward. Free tools and resources such as these can be a blessing when developing an instructional aid within the constraints of an academic budget. The only costs associated with this project were the domain name registration fee and the monthly fee paid to a commercial hosting company to provide a Web server and hard drive space for the site. Both of these costs can be avoided by hosting the site on a school Web server;

DESIGNING, IMPLEMENTING, AND EVALUATING

/

139

however, for those not familiar with Web site configuration, paying a third-party host to configure the site properly may be a worthwhile investment. Although Internet-connected computers are commonplace in technical communication classrooms, the potential of this network to facilitate group learning is often underrealized. Off-the-shelf course management software has a place in the modern classroom, but there are times when an application tailored to the specific needs of the class is desirable. Instructors may be inspired to create an application that fills these needs but may lack the technological expertise to implement their ideas. Collaborations between the instructor and faculty or students from the computer sciences can help bridge this knowledge gap. Implementing a small-scale interactive Web site is well within the ability of many computer science students, and they may be able to receive internship or other class credits for participating in such a project. Faculty and students often become siloed within their own departments, and a project such as this could help facilitate dialog between individuals in different fields. Based on the findings of this project, the development and use of interactive Web-based instructional applications for Web-enhanced or online courses should be encouraged, as long as they are thoughtfully integrated into the courses. When properly designed and deployed, Web-based instructional applications enhance the entire class’s ability to construct knowledge frameworks by presenting and storing classrelated exercises and by mediating the communication of the class participants. Because of this, Web-based instructional applications can play an integral role in the cognitive development of students.

REFERENCES Abbitt, J. T. (2007). Exploring the educational possibilities for a user-driven social content system in an undergraduate course. MERLOT Journal of Online Learning and Teaching, 3(4), 437–447. Buckley, K. M. (2003). Evaluation of classroom-based, Web-enhanced, and Web-based distance learning nutrition courses for undergraduate nursing. Journal of Nursing Education, 42(8), 367–370. Jiang, M., & Ting, E. (1999). A study of students’ perceived learning in a Web-based online environment. Proceedings of the 1999 conference of the Association for the Advancement of Computing in Education (pp. 575–580). Chesapeake, VA: AACE. Kearsley, G., & Schneiderman, B. (1998). Engagement theory: A framework for technologybased teaching and learning. Educational Technology, 38(5), 20–23. MacEntee, V., & Lewis, B. (2004). Web-enhanced course. Issues in Informing Science and Information Technology, 1, 951–964. Retrieved December 8, 2007, from http://proceedings. informingscience.org/InSITE2004/121macen.pdf Richardson, J. C., & Swan, K. (2003). Examining social presence in online courses in relation to students’ perceived learning and satisfaction. Journal of Asynchronous Learning Networks, 7(1), 68–88. Rivera, J. C., & Rice, M. L. (2002). A comparison of student outcomes and satisfaction between traditional and Web based course offerings. Online Journal of Distance Learning Administration, 5(3). Retrieved December 8, 2007, from http://www.westga.edu/%7Edistance/ ojdla/fall53/rivera53.pdf

140

/

DESIGNING WEB-BASED APPLICATIONS

Robert, L. P., & Dennis, A. R. (2005). Paradox of richness: A cognitive model of media choice. IEEE Transactions on Professional Communication, 48(1), 10–21. Sanders, D. W., & Morrison-Shetlar, A. I. (2001). Student attitudes toward Web-enhanced instruction in an introductory biology course. Journal of Research on Computing in Education, 33(3), 251–262. Schmidt, K. (2002). The Web-enhanced classroom. Journal of Industrial Technology, 18(2), 1–6. Retrieved December 7, 2007, from http://www.nait.org/jit/Articles/schmidt011802.pdf Sims, R. (2003). Promises of interactivity: Aligning learner perceptions and expectations with strategies for flexible and online learning. Distance Education, 24(1), 87–103. Swan, K. (2001). Virtual interaction: Design factors affecting student satisfaction and perceived learning in asynchronous online courses. Distance Education, 22(2), 306–331. Sweller, J., van Merrienboer, J. J. G., & Paas, F. G. W. C. (1998). Cognitive architecture and instructional design. Educational Psychology Review, 10(3), 251–296. Tuckman, B. W. (2002). Evaluating ADAPT: A hybrid instructional model combining Webbased and classroom components. Computers and Education, 39, 261–269. Yahoo! (2008). YUI Library. Yahoo! Developer Network. Retrieved April 20, 2008, from http://developer.yahoo.com/yui/

http://dx.doi.org/10.2190/DWBC9

CHAPTER 9

Supplementing a Professional Writing Course with an Interactive Self-Learning Document Design Tutorial Suguru Ishizaki, Stacie Rohrbach, and Laura Scott

Technical and professional communication programs have embraced the importance of visual communication in recent years as the professional writer’s need to communicate visually has increased significantly. A survey of technical and professional communication programs in the United States, for example, revealed that the majority of programs offered document design and visual rhetoric courses (Allen & Benninghoff, 2004). A survey of professional writers published in 2007 also found that many writers were responsible for the visual aspects of communication design (Brumberger, 2007). Nonetheless, contemporary students, majoring in subjects other than design, such as science, technology, humanities, and fine arts, have numerous course requirements within their discipline. Thus, even though the benefit of having visual communication skills is widely acknowledged, most students simply lack time in their schedules to take a course focused on visual communication. This situation makes it difficult to provide the majority of non-design majors an opportunity to acquire visual communication skills in a university setting. Our project addresses this problem through the making of an interactive self-learning tool that strives to help students develop foundational knowledge and skills for creating effective visual communication materials. Unlike typical online or video tutorials, this learning tool incorporates frequent interactive components that allow students to reflect on what they are learning through self-assessment questions and answers as well as hands-on exercises that immediately provide students automatic feedback on the work they produce. This tutorial is designed for integration into existing courses where students are currently asked to create visual communication artifacts, for example, a professional writing course and an engineering project course. Prior to beginning the design of a visual communication artifact, instructors can ask students to spend roughly 141

142

/

DESIGNING WEB-BASED APPLICATIONS

1 to 2 hours using the tutorial to learn the basic visual communication skills that they will need for that project, creating a just-in-time learning opportunity. Students acquire knowledge and skills, and apply what they learn to real projects precisely when a need arises. This approach also creates a learning environment where an instructor can focus on teaching rhetorical aspects of visual communication as opposed to foundational skills and knowledge. This chapter describes the structure of the initial, experimental version of our tutorial, and reports the results of a pilot study that examined the effectiveness of the tutorial in a professional writing course. THE TUTORIAL Overview The goal of the interactive design tutorial is to teach fundamental knowledge and skills associated with visual communication design. Therefore, rather than focusing on prescriptive guidelines or domain-specific rules, which are unfortunately more frequently available for novice designers, we focused on introducing design principles that are applicable to a broad range of design problems. For instance, instead of presenting guidelines like “The same font should be used throughout the whole report, unless a second font is chosen for headings and tables” (Winckel, Hart, Behrend, & Kokkinn,, 2002, p. 5) or “Title [of a spreadsheet] must be centered and prominent” (Jeter, 2002), we address the principles of selecting fonts and how visual hierarchy can be established by controlling visual variables. In order to create a tutorial for easy integration into an existing course, we limited the content to essential elements, such as visual hierarchy and readability so that it can be completed within 2 hours. This allows instructors to incorporate the tutorial into their course without making major changes to their initial course plan. The courses that already require readings on document design may replace them with the tutorial without instructors increasing their students’ workload. We have also employed a user-centered design approach to ensure that the interfaces of the learning modules are highly usable so that students can focus on the content. In particular, we have used heuristic evaluation as well as think-aloud protocols during our iterative development process. In order to make the tutorial relevant to the students, we also incorporated tasks and examples that would be familiar and interesting to contemporary undergraduate students. For example, the current tutorial uses as content, documents that explain recent technology inventions, such as fingerprint scanners and Internet security. Our long-term goal is to create a tutorial that addresses a broad range of visual design challenges. However, due to time constraints and our interest in measuring the validity of our approach prior to building multiple components, the initial tutorial focuses on teaching basic typographic skills that are commonly used in designing technical documents. Figure 1 presents the outline of the current tutorial, which was implemented using the technological infrastructure developed by Carnegie Mellon’s Open Learning Initiative (Carnegie Mellon University, n.d.).

SUPPLEMENTING A PROFESSIONAL WRITING COURSE

/

143

Figure 1. Organization of the Document Design Tutorial. Note: There are three main units, each of which includes multiple sections.

Components The tutorial consists of three types of learning components that are presented to students sequentially. First, each section of the tutorial begins with a 2 to 3 minute audio-visual presentation (Figure 2) of a key topic that focuses on a key topic, such as visual hierarchy or readability (see Figure 1). Audio-visual presentations are intended to introduce factual knowledge (e.g., vocabulary) as well as conceptual knowledge (e.g., design principles) associated with document design (Krathwohl, 2002). The presentation combines a recorded voice that describes a design principle, corresponding examples of well- and poorly-designed documents with written annotations, and text that presents important related terms and their definitions. The student is able to pause the presentation or jump back and forth between subsections within the presentation. As we developed and tested these presentations, we consulted Mayer’s Multimedia Learning (2001) and Clarks and Mayer’s E-Learning and the Science of Instruction (2003) for the design principles of instructional multimedia presentations. Second, each audio-visual presentation is followed by a set of 3 to 4 interactive self-assessment questions (Figure 3) that reinforce key learning outcomes associated with the audio-visual presentation through multiple-choice responses. This approach follows the principle of learning that suggests that frequent low-stake assessment enhances students’ learning and understanding (e.g., Butler & Winne, 1995; Cook, Thompson, Thomas, Thomas, & Pankratz, 2006). The interactive self-assessment questions provide students an opportunity to verify that they learned the facts and concepts, which they previously viewed in the corresponding audio-visual presentation that appeared above on the same screen. As soon as the student selects a response to an assessment question, the tutorial provides immediate feedback that describes its correctness. This allows the student to go back to the audio-visual presentation if further review of the concepts is necessary.

144

/

DESIGNING WEB-BASED APPLICATIONS

Figure 2. An example of the audio-visual presentation.

Finally, each unit is concluded by a hands-on exercise (Figure 4). In each exercise, students are asked to solve a series of simple document-design tasks using our proprietary automated critiquing system, called the Interactive Design Lab (IDL). For instance, students may be given an unformatted page of text and asked to manipulate the size and weight of the type to create effective visual hierarchy. This component is modeled after the method of desk critiquing that is common to studio-based teaching, where the instructor provides each student with personalized comments on their progress. Each time a student completes a task predefined in the IDL, its critiquing component provides written feedback on the solution entered. The critiquing component is designed with the general architecture of constraint-based intelligent tutors (Lynch, Ashley, Aleven, & Pinkwart, 2006; Mitrovic, 1998), where a learner’s knowledge relative to a specific task is represented in terms of constraints, or rules. For example, in our system, a constraint for a visual hierarchy exercise may include Heading must be more visually prominent than subheading. Each of the constraints in the tutorial is based on one or more design principles (i.e., conceptual knowledge) that are introduced in the audio-visual presentations in the currently or previously viewed unit. The IDL hands-on exercises enable students to practice what they learn by applying design principles to actual design problems. In addition, when any number of constraints are violated, the system

SUPPLEMENTING A PROFESSIONAL WRITING COURSE

Figure 3. An example of multiple-choice self-assessment question.

/

145

146

/

DESIGNING WEB-BASED APPLICATIONS

Figure 4. An example of a hands-on exercise with the automated critiquing component.

infers the problematic aspects of the learner’s skills or understanding of a certain concept and provides them with written feedback that helps them improve their design solution. The authoring component of IDL can be used to explore and create a wide range of small-document design exercises. The structure of the exercises enables students to focus their attention and practice on the design principles they just encountered in the audio-visual presentations and self-assessment questions. The authoring tool achieves this goal by providing the instructional designer the opportunity to control the set of visual variables (e.g., type size, margins, indentations, etc.) with which students interact. While the idea of computer-based critiquing for document design was already discussed in the 1980s (Schriver, 1989), no successful critiquing system has been developed for visual communication design, and no systematic research attempts have been made to create such a system. Consequently, no ready-to-use software tools were available for us to use when we started the project. Since we felt that the hands-on exercise is critical to the learning of visual communication skills, we decided to develop our own experimental critiquing system. We began our effort by reviewing the literature on automated design critiquing systems (e.g., Fisher & Morch, 1988; Robbins, 1999) and intelligent tutors (e.g., Koedinger & Corbett, 2006; Lynch et al., 2006); and created the system described above. Although it is primitive, it has helped us to develop a more explicit understanding of how instructors critique. Our long-term goal is to make the critiquing responses richer and more relevant to each student. For example, we plan to incorporate a computational model of individual students that will allow the system to tailor its critiquing comments to individual students. We are

SUPPLEMENTING A PROFESSIONAL WRITING COURSE

/

147

also interested in incorporating visual elements into the system’s critiques. For example, a textual critiquing comment may be accompanied by arrows that reference relevant areas in their work. USING THE TUTORIAL IN THE CLASSROOM Background During the early stage of its development, we conducted a small pilot study that focused on the visual hierarchy unit of the tutorial using a quasi-experimental pre-post experiment with a control group involving 10 participants (Ishizaki, Rohrbach, Tzucker, & Clarkson, 2008). The results of this study suggested that the tutorial would improve students’ skills in solving document design problems, as well as their ability to verbally critique documents. While the pilot study was small, the results were encouraging. Their posttest responses demonstrated noticeable improvement in both their design and critiquing skills. This was especially significant to us since the participants used the tutorial for only about 30 minutes, and there were no human-given instructions. Thus, we decided to complete the tutorial as we had planned, adding the two sections introduced earlier in this chapter. The completed tutorial has been tested in both a classroom setting as well as in a more controlled laboratory setting throughout the past two semesters. This chapter reports the procedures, preliminary observations, and results from the first round of study that we conducted in a professional writing course for non-English majors, titled Writing for the Professions. Overview of the Course Writing for the Professions targets juniors and seniors who are not pursuing degrees granted by the Department of English, such as Professional and Technical Writing majors. The course is intended to help students develop the writing skills that are expected and deemed necessary in the professional world. Students are asked to complete four projects during the semester—a job application package, a proposal, technical instructions, and an oral presentation, as well as small homework assignments and quizzes throughout the semester (Werner & Schnakenberg, 2010). Three to four sections of the course are offered every semester and are usually taught by PhD students in the Rhetoric program. All of the instructors share the same syllabus and assignments, which were originally developed by a faculty member in our program who also oversees the training and monitoring of the instructors. Most instructors of the course do not have prior professional experience in visual communication design or have never taken a visual design course. Thus, for many years, students have acquired document design skills through supplemental readings that cover the design principles addressed in the courses (e.g., Felici, 2002; Markel, 2010) and project-based assignments. However, some instructors mentioned that they felt less comfortable teaching visual design than teaching writing, which is understandable, based on their backgrounds.

148

/

DESIGNING WEB-BASED APPLICATIONS

Methods and Procedures Prior to the beginning of the semester, all instructors completed the tutorial and agreed to use it in their classes. Once the semester began, the students were assigned the use of the document design tutorial for the résumé project, which was assigned during the first week of the course. Students were given roughly 2 weeks to complete this assignment. Before they began the project, one of us visited each section of the course, briefly explaining the purpose of the study and distributing the consent form approved by Carnegie Mellon’s IRB. Signed consent forms were collected thereafter by the instructors. Once the project ended, from each student who participated in the study we collected and analyzed their original and revised résumés and three written reflection statements. Figure 5 illustrates the detailed process of the résumé assignment. We compared the two résumés (original and revised) that each student created to see if improvements had been made through the application of the design principles covered in the tutorial. We also looked at each student’s written reflections on the original and revised résumés. Written responses were analyzed in terms of the frequency and accuracy of wording used in describing the visual design of the résumés. We also received informal feedback from the instructors. Preliminary Results and Discussions In the initial written reflection, where students were asked to comment on the writing and design of their original résumé, most students focused on whether or not they liked the content of their résumé (e.g., whether or not they were satisfied with their GPAs and job experiences). Some students described the organization of their résumés as either positive or negative. In terms of document design, students consistently used terms like, “simple,” “clean,” “messy,” “interesting looking,” or “professional” to describe why they did or did not like their design. But predictably, most of them did not refer to specific design issues. However, the students indicated some concern for readers, stating that viewers should be able to understand the information on their résumé easily. In the second written reflection assignment, students were asked to select five terms they learned in the tutorial and critique their original résumé from those five viewpoints. In other words, students were expected to use the concepts from the tutorial as a way of critiquing their original résumé. Table 1 presents the terms students mentioned in their writings and the frequency of their use. Students’ written reflections tended to focus on what they did more than what they needed to improve. However, students who did mention improvements provided suggestions for how to eradicate problematic aspects of their design. Overall, their reflections demonstrated their awareness of how visual variables affect each other (e.g., margins and type size affect the line length) and how they impact the effectiveness of the document (e.g., type size can be used to establish visual hierarchy). We also found that some students used terms incorrectly. In most cases, they were pointing out valid issues using the wrong terms. For example, a student referred to a problem with leading (space between lines) as a kerning problem (adjustment of space

SUPPLEMENTING A PROFESSIONAL WRITING COURSE

/

149

Figure 5. An Overview of the Résumé Project.

between characters). Other terms that were misused by some students include visual hierarchy versus visual grouping, and legibility versus readability. This confusion is understandable since linking the terms to principles requires some memorization, and many of the students did not refer to the tutorial while completing the assignment. A simple, printable reference sheet that summarizes key concept and terms may be useful in the future.

150

/

DESIGNING WEB-BASED APPLICATIONS

Table 1. Terms Selected by Students in the Second Reflection Assignment Terms mentioned

Total

Positive

Negative

Paragraph spacing

14

9

5

Type size

12

7

5

Line length

12

5

7

Indentations

11

6

5

Typeface

11

5

6

Visual hierarchy

10

6

4

Leading

10

4

6

Legibility

9

6

3

Visual consistency

8

7

1

Widows

8

5

3

Type weight

8

2

6

Readability

7

1

6

Margins

6

2

4

Grid

6

2

4

Visual grouping

5

5

0

Orphans

3

1

2

Rivers

2

2

0

Color contrast

1

1

0

Tight lines and loose lines

1

1

0

Page layout

1

0

1

Note: The value in each cell indicates the number of students who selected the term. The positive and the negative columns show whether or not students used the term to describe the positive or the negative aspects of their design.

After the second reflection assignment, students were asked to revise their résumés and write a final reflection statement that explained how they changed their designs. In the final reflection, students focused more on how they improved the design problems they noticed. The frequencies of the terms used in the final reflection are summarized in Table 2. The most noticeable difference between the first and final reflections is the length of text and the details of their writing. Figure 6 shows typical written responses for the first and the third reflection assignments. Many of the writings indicate that the students’ understood how adjusting the design of visual elements alters the effectiveness of other components of a document. For example, students appeared to grasp the effects of visual variables on the overall visual hierarchy, grouping, and consistency of a document; and how those concepts, in turn, affect

SUPPLEMENTING A PROFESSIONAL WRITING COURSE

/

151

Table 2. Terms Used by Students in the Final Reflection Writing Terms mentioned

Total

Terms mentioned

Total

Type size

13

Leading

8

Margins

13

Visual grouping

7

Type weight

12

Widows

6

Readability

12

Grid

5

Line length

11

Orphans

5

Paragraph spacing

10

Legibility

3

Indentations

10

Rivers

2

Visual hierarchy

10

Color contrast

1

Visual consistency

10

Tight lines and loose lines

1

Typeface

9

Page layout

1

Note: The terms found in the second reflection assignment were used. The value in each cell indicates the number of students who selected the term.

the readability of their résumés. Students also explained how their résumés had or had not become more visually appealing. While the tutorial does not address the issue of aesthetics, many students seemed to consider it an important aspect of their résumé design. In addition to analyzing students’ reflection writings, we compared each of the original and revised résumés that they created. In general, we observed clear improvements in nearly all students’ work. Most of the revised résumés included better visual hierarchy of the content with clear section titles and distinct visual grouping. We also noticed that their final reflective writings generally corresponded to the improvements they made. For instance, Figure 7 shows the original and revised résumés created by the student whose reflective writings are presented in Figure 6. Notice that the revised design separates sections better than the original document by using white space more effectively, and headings are much more distinct because of the use of sans serif typeface. The student also used the entire page more effectively in the revised document by aligning dates and locations to the right margin. All of the instructors reported that the tutorial met their expectations for introducing both factual and conceptual knowledge to their students. They reported that not only did the students use the vocabulary and concepts from the tutorial during the résumé project, they voluntarily used the terms and principles throughout the semester to critique the various documents they created. Instructors also received some negative comments from the students regarding the tutorial. Some students complained that the tutorial was too long. Others stated that it was too basic, so they skipped around and didn’t view all of the components or perform all of the activities included in the tutorial. Some students thought the tutorial didn’t

152

/

DESIGNING WEB-BASED APPLICATIONS

Figure 6. A reflective writing for the original résumé prior to completing the tutorial (left), and a reflective writing on the revised résumé.

represent their progress effectively. One instructor reported that students in her class expressed an interest in having a printable summary of the tutorial as a reference guide for other assignments that they completed later in the semester. The students’ comments suggest that they did not retain some of the knowledge components presented to them in the tutorial throughout a semester, although they did recognize the need for the knowledge to complete some of their later assignments effectively. CONCLUSION We have introduced the interactive self-learning document design tutorial and reported on the preliminary results of our ongoing study that examines its effectiveness. The results suggest that the students made improvements in their ability to generate and verbally critique visual aspects of a document. In addition, the use of the tutorial

SUPPLEMENTING A PROFESSIONAL WRITING COURSE

/

153

Figure 7. An original résumé and its revision by the Student 8 (see Figure 6 for this student’s reflections). In the revised design, categories are visually more distinct and the entire page is used more effectively.

during the first assignment equipped students with a common vocabulary that they used to discuss visual aspects of the assignment throughout the semester. Compared to the same course taught in the previous years where the interactive tutorial was not used, we did not find significant problems in the sections taught with the tutorial. This suggests that the interactive tutorial could help students learn how to design effective documents at least as well as the traditional printed materials. However, we hypothesize that the interactive tutorial may potentially be a more effective learning tool because it encourages active learning through self-assessments and hands-on exercises. Nonetheless, further studies are necessary in order to validate this hypothesis. The next step, therefore, is to conduct more focused studies that examine the differences between the components within the tutorial, as well as the advantages, if any, of the interactive tutorial over the traditional handout. At the time of writing, we have a series of follow-up studies underway. We conducted a controlled study that involved 120 participants separated into three experimental groups. Each group used different combinations of the three components in the tutorial, which we believe will enable us to examine the impact of individual components on students’ learning. We also conducted a classroom study that involved a control group that used the traditional paper handout instead of the interactive tutorial. We are currently grading and analyzing the data collected from these studies.

154

/

DESIGNING WEB-BASED APPLICATIONS

REFERENCES Allen, N. J., & Benninghoff, S. T. (2004). TPC program snapshots: Developing curricula and addressing challenges. Technical Communication Quarterly, 13(2), 157–185. Brumberger, E. R. (2007). Visual communication in the workplace: A survey of practice. Technical Communication Quarterly, 16(4), 369–395. Butler, D. L., & Winne, P. H. H. (1995). Feedback and self-regulated learning: A theoretical synthesis. Review of Educational Research, 65(3), 245–281. Carnegie Mellon University. (n.d.). Open learning initiatives. Retrieved June 11, 2010, from http://www.cmu.edu/oli/ Clark, R. C., & Mayer, R. E. (2003). e-Learning and the science of instruction. San Francisco, CA: Pfeiffer. Cook, D. A., Thompson, W. G., Thomas, K. G., Thomas, M. R., & Pankratz, V. S. (2006). Impact of self-assessment questions and learning styles in Web-based learning: A randomized, controlled, crossover trial. IT in Medical Education, 81(3), 231–238. Felici, J. (2002). Complete manual of typography. Berkeley, CA: Adobe Press. Fisher, G., & Morch, A. I. (1988, June 23–27). CRACK: A critiquing approach to cooperative kitchen design. Paper presented at the International Conference on Intelligent Tutoring System, Montreal, Canada. Ishizaki, S., Rohrbach, S., Tzucker, J., & Clarkson, M. (2008, July 13–16). Teaching visual design without instructors. Paper presented at the IEEE International Conference on Professional Communication, Montreal, Canada. Jeter, S. M. (2002, June 16–19). Using a generic checklist for teaching and grading the format, composition, and production qualities in laboratory report writing. Paper presented at the 2002 American Society for Engineering Education Annual Conference & Exposition, Montreal, Canada. Koedinger, K. R., & Corbett, A. T. (2006). Cognitive tutors: Technology bringing learning sciences to the classroom. In R. K. Sawyer (Ed.), The Cambridge handbook of the learning sciences (pp. 61–78). New York, NY: Cambridge University Press. Krathwohl, D. R. (2002). A revision of Bloom’s taxonomy: An overview. Theory into Practice, 41(4), 212–218. Lynch, C. F., Ashley, K. D., Aleven, V., & Pinkwart, N. (2006, June 26–30). Defining “illdefined domains”: A literature survey. Paper presented at the Eighth International Conference on Intelligent Tutoring Systems (ITS 2006), Jhongli, Taiwan. Markel, M. (2010). Technical communication (9th ed.). Boston, MA: Bedford/St. Martin’s. Mayer, R. E. (2001). Multi-media learning. Cambridge, MA: Cambridge University Press. Mitrovic, A. (1998). Experiences in implementing constraint-based modeling in SQL-Tutor. LNCS, 1452, 414–423. Robbins, J. E. (1999). Design critiquing systems (Technical report UCI-98-41). Irvine, CA: University of California, Department of Information and Computer Science. Schriver, K. A. (1989). Document design from 1980 to 1989: Challenges that remain. Technical Communication, 36(4), 316–331. Werner, N., & Schnakenberg, K. (2010). Syllabus for English 76-270: Writing for the professions. Pittsburgh, PA: Carnegie Mellon University. Winckel, A., Hart, B., Behrend, M., & Kokkinn, B. (2002). Report writing style guide for engineering students. Mawson Lakes: University of South Australia, Division of Information Technology, Engineering and the Environment, School of Natural and Built Environments.

http://dx.doi.org/10.2190/DWBC10

CHAPTER 10

Developing a Web-Served Handbook for Writers Stephen A. Bernhardt

Over the past 5 years, I have been working with publisher Bedford/St. Martin’s to develop an electronic handbook for writers. While I write this chapter, we have a full, working beta version of Writer’s Help—an XML-based, Web-served handbook—which is being piloted in classrooms. By the time you read this chapter, the book (to favor the traditional term) will be for sale and in use in writing classrooms. You can see the marketing page at writershelp.com. From there, you can request a log in to test drive Writer’s Help. The name reflects a product that crosses a writing handbook with a help system. Our goal was to create a reference handbook that addresses a known and very common problem: students can have information at hand about grammar, usage, or citation practices, but still not be successful at accessing and using that information to address their own needs as writers. They may not overcome the inertia that prevents them from getting a book off the shelf and figuring out how to use it. If students do crack a reference book, they may struggle to define their writing questions in ways that match the terminology of the book. We know students have trouble using the technical grammatical terms of a reference handbook, and we know they are often confused by the complexities of academic citation styles. We also know that students frequently find what they think is an answer or a model, but mistakenly alight on the wrong information. If students look for answers online, they may be overwhelmed by what they find. Like the rest of us, students are increasingly conditioned to Google their way to all knowledge, even if Google tends to return thousands of targets, some relevant and many not. We should not underestimate the difficulty of fixing a writing problem using a handbook, whether print or online. Reference handbooks are written in language about language—essentially metalinguistic abstractions about a highly abstract symbol system. Each reference book organizes myriad and complex topics in both systematic and often arbitrary ways, with many local decisions about how to organize and map the content. Students need to develop a mental map of the book and of their own query that matches that of the authors of the reference source. Students have to call upon 155

156

/

DESIGNING WEB-BASED APPLICATIONS

sophisticated knowledge and control of terms to define a problem, search for an answer in a handbook, match their problem to explanations and examples in the text, and then port the referenced information back to their problem space, where they apply the advice to their own language. There are opportunities for missteps at every stage: in coming to terms with their problem, in formulating the search target, in knowing whether an example is a good match, in understanding explanatory text, and in applying information to a text passage. Our thinking has been that an electronic, Web-based resource might be able to address the problems that students experience when using reference handbooks as they work on their writing. • We could move rich, layered content online, into the browser, so students have access as they are writing. • We could develop an intelligent search engine, one that would use the language of both students and teachers to help students target a limited pool of topics likely to be helpful to writers. • We could implement tagging, electronic notes, search traces, and other features to help a writer keep track of and return to valuable help. • We could implement social tools so students can see what other students are doing, and so that instructors can make good classroom use of the resource. • We could create a product that would grow with its users over time, one that would be increasingly responsive to their needs and of ever-increasing value. In this chapter, my purpose is to highlight the development process, demonstrating how we have worked to create an application that is well-suited to the ways students think about writing, that addresses the kinds of help they need, and that takes advantage of the affordances of an electronic resource. One of the pleasures of this project has been the experience of true teamwork. When I write “we” in this article, I am referring to the development team. The team brings together Bedford developers and editors, building on their deep handbook experience. New media specialists have contributed their expertise to interface design, usability testing, XML coding, and e-book design. Talent external to Bedford has been recruited to assist with programming search and navigation, while design consultants have contributed to the interface and display of content. Importantly, authoring the kinds of tools explored in this collection typically involves teams working to realize a shared vision. Sometimes those teams coalesce around open-source learning materials, sometimes around software or a Web site to support a department writing program, writing center, or university initiative. In this case, the collaboration is commercial, but the project triggered the best kinds of team effort, problem solving, and cooperative, participant-centered design. THINKING ABOUT ELECTRONIC TEXTBOOKS It is evident that the textbook market is changing rapidly. A recent report (Reynolds, 2010) suggests that electronic textbooks will grow by 100% per year over the next 5

WEB-SERVED HANDBOOK

/

157

years, followed by another 5 years of 30% annual growth. The same report notes that major changes are on our doorstep: Over the next five years, digital textbook sales in the United States will surpass 18% of combined new textbook sales for the Higher Education and Career Education markets. This increase will boost revenues for digital textbooks to more than $1 billion and necessitate a general overhaul of traditional textbook production processes. The growth will also create avenues for new content publishers to enter the textbook market, lead to fundamental shifts in purchasing patterns around learning materials, and expedite the formal adoption of open educational resources to augment premium digital content. (para. 1)

A report from EDUCAUSE suggests that we are finally “nearing the end of the era of hype” with regard to e-books in higher education, with more college students looking for lower-cost texts in portable format (Nelson, 2008). Barnes and Noble, Amazon, and Apple are all zeroing in on the expanding textbook market created by e-readers. There are many reasons the movement to e-textbooks has been stuttering: e-books did not have the affordances of print to support the kinds of reading and studying that students do (note taking, for example), simple conversions of books to pdf or other reader formats did not support a satisfying user experience, and the limitations of the reader hardware itself made extended reading less than comfortable or efficient. All of these limitations are rapidly being addressed. We are optimistic that Writer’s Help can find a niche in this changing market. We are working on the assumption that the book is not “one-and-done,” that students will continue to use Writer’s Help because they develop the expertise to use it and a reliance on it in their first-year composition class. We know many students hang on to their handbooks, so there is good potential for continued use among students in business and technical writing classrooms and in writing-intensive classes across the disciplines. With the right framing, an online handbook could also benefit audiences of working adult writers. If well-designed with appropriate content, the handbook could move with the writer across situations of composing. Early in the planning stage, we debated whether we needed new content from the ground up, or whether we might rework existing content. Bedford is justifiably proud of its best-selling handbook, A Writer’s Reference, by Diana Hacker and Nancy Sommers (2010). The book has a loyal following of teachers across many campuses, in both community colleges and universities. The content has been thoroughly tested and refined over multiple editions. The achievement of the book is the careful, direct, and precise language, which offers explanations that students understand. Additionally, the original design was innovative among handbooks—a spiral-bound, tabbed, highly modular book with clever visual cueing of content and examples. The book took the market by storm and has dominated since. We made an early decision to base the new electronic Writer’s Help on the existing, classroom-tested, effective content of A Writer’s Reference. From the beginning, we agreed it would be critical to preserve the best features of the existing book while taking full advantage of the dynamic possibilities of an online presentation.

158

/

DESIGNING WEB-BASED APPLICATIONS

The team at Bedford committed substantial resources to the development process: for gathering information on how students and teachers use handbooks, for collecting user feedback and conducting formal usability testing, and for reviewing and piloting the resource in classrooms. At every step of the way, we sought confirmation for our design decisions, advice about content and organization, and feedback from our user community: • Web-based surveys of over 850 students at three universities and three community colleges • Focus groups with eight groups of teachers and writing program or center directors (42 total participants) over 5 years at the CCCC conferences • User testing with approximately 250 students on six campuses to gauge their interaction with the emerging prototypes • Formal testing with ten students during spring 2009 and nine during spring 2010 in the usability lab at Texas Tech University under the direction of Prof. Brian Still • Reviews of an advanced, fully functional prototype by 25 writing instructors at various colleges and universities • Meetings with graduate teaching assistants to review and comment on content and design • Beta testing in classrooms before commercial release (ongoing as I write) The flow of information from student and teacher testers, who performed representative tasks on both early and advanced prototypes, shaped all our decisions. We followed an iterative, participant-centered design process: developing wireframes, getting user feedback, and talking with instructors and program directors to show them our ideas and get their responses before going back to a new round of redesign and content revision. Internally, many eyes were on the product throughout development, with weekly discussions and team decision making. The process relied on deep collaboration. ACCOMMODATING STUDENTS IN THE INITIAL DESIGN To make Writer’s Help as useful as possible, we were determined to get to know our audience. We wanted to learn how students currently use reference handbooks, how such tools figure into their writing processes, and what sorts of things they tend to look up in their handbooks. We surveyed over 850 students from seven institutions. In general, we felt certain from student responses that we were on the right track with our product development. We knew that students would be in a position to use a Web-served Writer’s Help, and that they would be able to migrate their existing practices from print to online, or from existing online resources to a new, more targeted resource. The survey responses from students support the following generalizations. (The ranges in these 2007 data represent the range of student responses for the seven schools.)

WEB-SERVED HANDBOOK

/

159

• Most students (about 90%) write papers on their personal computers, almost always with Internet access. Students at one community college were more inclined to draft on paper (35% always draft on paper; 29% frequently do so) and not to have Internet access while writing (though 73% always or frequently have access). Even among this group, composing while connected is the norm or will soon become the norm. • While writing, students frequently look for online help (45–85% of the time). Students also frequently consult a print handbook (36–42% of the time). • Students frequently consult a handbook for advice on (a) organizing papers, (b) following documentation styles, (c) using and evaluating sources, and (d) revising and editing. • Students less frequently consult a handbook for (a) advice on topic choice and thesis statements, (b) drafting, (c) choosing visuals, (d) writing job-application materials, or (e) preparing presentations. • Community college students are more likely than university students to consult a handbook for advice on (a) grammar, (b) punctuation, and (c) document design and format. • Students suggest that all handbook features are useful: headings, explanations, examples, charts, model papers, and citation models. Very few describe any of these features as not useful. • Students find all navigation features useful, with very few describing these features as not useful (see Table 1). • Students say they are most likely to use e-book features such as tables of contents, indexes, and search. They say they are much less likely to use previous/next arrows. • Students are more likely to buy a print handbook (68%–91%) than a Web version (9%–32%). These data suggest that significant numbers of students rely on both print handbooks and Web searches to find information they need as they compose online. The data were useful in suggesting that the conditions of composing are such that an electronic handbook would have a potential audience, and that the audience would be poised

Table 1. Navigation Feature Usefulness Feature

Always or mostly useful

Index

80%–97%

Table of contents

46%–100%

Tabs

42%–88%

Color coding

46%–82%

Codes your teacher uses

19%–53%

160

/

DESIGNING WEB-BASED APPLICATIONS

to take advantage of both the content and the features of a well-designed online handbook. The data also confirmed that different learners value different features, and that it would be prudent to translate useful features of the print handbook into the online version whenever possible.

A QUICK TOUR A few screen shots offer a good idea of the design of this new e-book. Writer’s Help uses a three-panel design (Figure 1). Search is prominent at the top center of a window that is always open. Content is displayed immediately below, with links embedded in the text. The left panel contains navigation options, with tabs allowing access to search results, the index, or the table of contents. The right panel holds all social and individual customization tools: tagging, content highlighting and notation, settings, and search frequencies. The left and right panels can be closed, leaving only the content panel in view. To facilitate quick scanning, the content has been revised and chunked into smaller units, keeping the explanations brief; focusing on examples; and avoiding extended, unbroken text. We made section and subsection headings as helpful as possible and created many new headings to ensure that important advice is easier to find. To create a fluid user experience and take advantage of the online environment, we incorporated linking on every content page—to other sections, to charts and checklists, to documentation models, to model documents, and to exercises. To facilitate navigation, we incorporated one or more links off every panel. Models, exercises, and related-topics

Figure 1. Three-panel layout.

WEB-SERVED HANDBOOK

/

161

links appear on many panels, typically in a segmented area at the bottom of the content panel (Figure 2). We know that students frequently seek handbook help with citation styles, and so we paid particular attention to rethinking the sections that describe MLA, Chicago, and APA styles. Most handbooks separate attention to in-text citation from end-of-text citation—both topics need to be discussed and exemplified. In this case, we realized we were not restricted by space and printing issues, so we could offer both in-text and endof-text examples together wherever it would be helpful to see both in one place. Our thinking is that seeing both in one place will allow students to compare the information and see the in-text and end-of-text citations as working in complementary fashion. Throughout the book, but especially in citation styles, we privileged examples over explanations. If students can identify the appropriate target and follow the example, the handbook has done its job. Some students will want to see an annotated example, calling out the parts, so we provided those as pop-ups that persist until the student closes the example. Students can position the pop-ups on their desktop so they can examine the example alongside their word processing window with their text (Figure 3). Frequently, further explanations or pop-ups can be called with a

Figure 2. Content panel with links.

/

Figure 3. Citation model with pop-up.

162 DESIGNING WEB-BASED APPLICATIONS

WEB-SERVED HANDBOOK

/

163

click (Explain or Show Me), but they are one layer down so as not to clutter the clean examples. We have worked to make it easy to get in and out quickly. A feature we call Quick Help (Figure 4) serves as a top panel to organize more detailed content a layer below. Quick Help focuses on examples, and sometimes a brief generalization, with links to more detailed content panels. We hope students will often be able to quickly find the help they need and get back to their writing. User testing and feedback have been essential to designing these panels, and incremental refinement of the display conventions has led us to an increasingly simple, uncluttered, minimalist presentation. Throughout development, we have focused on building a resource that resides alongside the primary workspace, the student text under construction. Writer’s Help is work support—a tool that rests on the desktop until needed, that comes up quickly, and that just as quickly gets out of the way when no longer needed. BUILDING STUDENT LANGUAGE INTO SEARCH One development goal has been to build a tolerant search engine so that students can use vague or imprecise language and still have successful searches. We know that students frequently do not know the formal terms involving grammar or citation

Figure 4. Quick Help on parallelism. A number following targets indicates that the category can be expanded to show x number of subtopics.

164

/

DESIGNING WEB-BASED APPLICATIONS

practices. We also suspect that search will be the predominant approach to looking for information in Writer’s Help (as opposed to indexes or tables of contents or other listing structures). Thus, throughout development, we have focused extensive energy on creating a responsive, student-centered search engine. From open-ended items on our student surveys, we were able to harvest a rich list of student terms. We have been using this term list, augmented by subsequent user data, to develop and tune our search engine. After reducing the redundancy, we had a core list of over 170 words or phrases that students are likely to use as they pursue questions or topics in a grammar reference. Some of the queries are quite specific and well-formed: • supporting my opinion with evidence • writing for a specific audience • whether to use a colon or semicolon • overusage of pronouns like I and we • finding sources • formatting a business letter • sentence faults When talking about writing, students frequently use common words and phrases rather than the carefully defined terms of a grammar handbook: • choppy, smooth flow, using only words that have to be there • getting unstuck, introduction starters • writing my educated opinion in a more formal tone • sticking to ideas, making sense • punctuation following sentences • how to stay in third person • formatting my writing style to fit the professor’s instructions Such phrases need some interpretation or special handling by the search engine to direct the query. For example, writing ideas needs to point to something like topics or tentative thesis statements or idea generation. The phrase getting unstuck needs to point to entries on writer’s block, free writing, drafting strategies, prewriting, or invention. The open-ended questions also gave us some insight into how inventive students are with spelling. Misspellings of punctuation included these forms: puction, puncation, punchuation, punctation, punction, punctuitions, punctutation, puncuation, puncutation, puntuation, puntuattion, punuation. Obviously, we would need a search engine that would be highly tolerant of variant spellings. Our search engine, developed in partnership with Ken Haase of BeingMeta, uses a broad set of terms with established linguistic relationships to build what we call “a semantic cloud.” The cloud includes our specialized handbook of index terms as well as the vocabulary that we’ve collected in our research about how students search for help with writing. When a user searches the handbook, the semantic cloud maps potential relationships between the search phrase and any index terms that target

WEB-SERVED HANDBOOK

/

165

relevant pages in the handbook. A relatedness score is computed by the search algorithm, based on overlap of terms, closeness in meaning, or co-occurrence frequency in natural language. This relatedness score then ranks the returns so the top returns in the list should be the closest match to the search phrase. The system is programmed to tolerate variant spellings (see Figure 5). With an editorial interface, we are able to test and edit how a wide variety of search terms interact with the semantic cloud. When searches fail to generate expected results or produce irrelevant matches, we can edit the semantic relationships in the cloud to eliminate the undesired matches or to establish synonyms that apply to the world of writing. The process is a bit tricky at times. Consider a word like topic, which might refer to subject of a paper, the topic sentence of a paragraph, the topic/comment structure within or between sentences, or the rhetorical term denoting the common places of argument. Style is another term with a daunting range of definitions and contexts in the discourse of writing. Our approach has been index-centric: we built out the original book index of Writer’s Reference to be much more inclusive of topics and variants, attempting to include all words that might arise in a writing classroom. To ensure relevant search results for writing-relevant content that is not represented in the print counterpart, we created

Figure 5. A fairly complex set of search returns on argument.

166

/

DESIGNING WEB-BASED APPLICATIONS

an expansive glossary of definitions and examples so that, at a minimum, a student gets some useful information from any writing-related term. As the product develops in use, we will be able to monitor searches, with the goal of providing manageable lists of well-targeted returns for an increasingly high percentage of student queries. Tuning search is an ongoing task. We know search is critical to the success students have in finding what they want, even if their ability to name what they want is dicey. We have the advantage of working in a small world of potential terms—the language of a writing classroom—so we are not in Google space. Nonetheless, the Goldilocks conundrum still represents a challenge: not too many returns, not too few returns, but just right. It is reassuring to know we can refine, redefine, prune, associate, and adjust search returns. Our search analytics provide a stream of data that allows us to tune the handbook to student ways of working. Figure 6, for example, shows a current history of searches and tags (for all searches by all users), a dynamic item called up on the right panel, visible to users. As students use Writer’s Help, we will know the most frequent, the most unusual, or the failed queries. We will be able to determine whether search provides too many or too few returns and make adjustments accordingly. A Web-based, centrally served reference work offers the potential to tailor a product to the particular ways that students and teachers work while writing. We hope that server data will allow us to create a handbook that is truly responsive to student ways of working. Having user data at hand should permit us to improve the resource in ways that have never been possible with print books. FACILITATING CUSTOMIZATION AND INTERACTIVITY To use a handbook successfully, students need to interact with the text. In our teaching, we encourage students to be active readers through annotating a text, posing questions in the margin, and bookmarking important pages. Part of the problem that has limited adoption of e-books to this point has been the lack of tools for doing what active readers do. With Writer’s Help, we saw the potential to use existing tools from prior Bedford e-books and to add tools that would increase the value of the tool to students and teachers, through individualization and through social tools. Figure 7 shows the right-hand panel, where these tools appear. Tools you might expect to see are the highlighting tools for marking passages of text in grey or yellow and a tool for sticking notes to pages. The student can show all notes in a list with links to content. It is also easy to share a link to a page with someone else. A scorecard tool will keep track of student performance on the various exercises that are part of the handbook, reporting results to the student and/or the instructor. One new tool we added allows students to add tags to pages. The tags associate related pages under a common term. For example, a student-assigned tag “my grammar errors” or “backing up my arguments” could link together any number of related pages. Students (and teachers) can build out tag sets that will help organize content around their individual ways of thinking. Tags can be viewed as a list or as a cloud (showing

WEB-SERVED HANDBOOK

/

167

Figure 6. Searches and tags history.

graphically the ways the student organizes content in multiple tag sets). Tags can also be shared with the class, and a teacher can share a tag set with her students. Thus, if a teacher wants students to visit a series of topics in relation to a given assignment, she can create a tag set and share it with her students. Other tools allow the student to see recent searches, top searches, and popular and recent tags for the whole user community. All tags and lists have click-and-go links. Individual and class tags appear in search results. Taken together, these individual and group tools should encourage a sense of ownership and control on the part of the student. Seeing popular tags or top searches displayed will cue students on content that they might benefit from examining. Seeing the terms should provoke learning the technical vocabulary of the writing classroom and trigger more productive searches. Adding notes or pages of new material should help students feel possessive about their individualized help systems.

168

/

DESIGNING WEB-BASED APPLICATIONS

Figure 7. Tools for customization.

Many of our reviewers have indicated they want to be able to use Writer’s Help in the classroom, which we believe is an important key to helping students become expert users. We have created various displays that work well if projected—the kinds of teaching objects that are useful from time to time (invention strategies, model documents, charts of grammatical categories, directories to citation styles). These objects appear within their own windows, which can be sized and moved. The class tools in the right panel also make it possible for the instructor to push content links to individuals or the full class, making it easy for students to link into assignment-relevant content. A teacher can “assign” a section of Writer’s Help to the class by tagging a section of the table of contents. Any such teacher-created tags will automatically appear on the students’ home page. We have also developed a guide to best practices, with suggestions for working in classrooms with an instructor media station, as well as in wireless classrooms or computer labs. Our goal is to encourage frequent shared use of the handbook, so students get better at knowing what content is valuable, how to find it, and how to return to previously viewed content.

WEB-SERVED HANDBOOK

/

169

BUILDING IN THE EXPERTISE OF FOCUS GROUPS, USABILITY TESTING, AND REVIEWERS Part of building a tool that is responsive to users involves getting to know those users through participatory design. We wanted to tap into the expertise of those people who are close to the student experience. In important ways, teachers and writing program administrators drive the textbook selection process, so a new e-book needs to appeal to an intermediary—the instructor or program administrator or selection committee—in addition to the ultimate customer, the student. Certain issues emerged as prominent among our reviewers, and we have attempted to address these issues during development. • The product should follow students across their careers at school. It should not be limited to a single term, and the license should not expire, at least not at the end of term. Students should be able to use the Writer’s Help in subsequent writing and disciplinary courses. • The product should be developed to work across platforms, to be integrated into classroom-management software (such as Blackboard or Sakai), and to be site-licensed as well as individually licensed (writing center, writing program, department, university, library). Students don’t work at one machine, so the product needs to follow them. • The product must start up fast and provide fast returns. There should not be a complex log-in or cumbersome front-end experience. • A strong, flexible search tool is critical. As the primary entry point, search should reflect the language of students and teachers and respond to queries that are not well-defined. • Quick, targeted help is important. The product should find ways to allow students to quickly see examples and brief explanations that answer their questions and get them back to writing. There should be lots of clear examples that can be understood and applied. • Grammar-heavy terminology and verbal denseness will be a liability. Search results or screens that look complicated or dense will be a barrier. The product should be designed to be highly visual. • Frequent cautions were offered about overestimating the “always online” population. Not all students have good access to technology and connectivity. There were also many cautions about not overestimating the technological expertise of students. Many are not good at search or indexes or solving problems using online resources. Support for teachers and students to help learn to make best use of the product is critical. Some opinions were mixed, suggesting the need for a product that would support different teaching styles. For example, some teachers want exercises or would assign sections to read; others expect students to use a handbook on an as-needed basis, primarily outside of class. Some respondents thought that social or interactive features would be valuable—that a user community could coalesce around those using Writer’s

170

/

DESIGNING WEB-BASED APPLICATIONS

Help. Others thought it was a definite stretch to imagine anyone wanting to join a community of grammar handbook users. We are trying to accommodate the wide range of needs or desires as indicated by our reviewers. Because the work is electronic, it can be expansive. There is no particular reason to eliminate content just because relatively few teachers want it; in fact, it makes sense to keep it even for a limited subset of users. To the extent possible, we have developed the product to be responsive to such varying wishes. The formal usability testing also turned out to be quite informative. Writer’s Help scored well (> 77) on the System Usability Scale (SUS) Satisfaction Survey, which asks users to indicate overall satisfaction with a product. However, the usability testing also showed that some students needed quite a few clicks to get to information and that they were frequently unable to complete tasks successfully. The testing provided rich data on where students tended to go wrong and why they failed at the tasks. The improvement from round one to round two testing showed us that our interface and search were working better for students. The usability test reports made specific suggestions to enhance the product: making some features work in more intuitive ways, improving search, changing the screen language, and reconsidering the hierarchy of the table of contents, among other suggestions. The testing also suggested that there is potential for creating a useful community of student users and recommended further development of the social tools that are part of the product. The overall conclusion was that Writer’s Help has the potential to be a truly groundbreaking product. These kinds of data from formal usability testing are valuable in several ways. They suggest that we need to make continued improvement in the interface design and search operations so student success is closer to 100% and so they are able to retrieve accurate information quickly with fewer clicks. Such testing also gives us a video and audio record of what goes on as students attempt to use the product, and every test generates surprises of one sort or another. This kind of testing is relatively novel for a textbook. We know of similar testing by Tharon Howard in the usability lab at Clemson, the results of which he has reported in the Journal of Usability Studies (2008). His testing compared two print handbooks, using abbreviated, excerpted text, not the full books. Howard found that users failed in several ways: they frequently believed they had found the right answer to a question, but were, in fact, looking at information that did not match their defined problem (p. 198). The users in Howard’s study also failed to recognize the complexity of their situations. They quickly alighted on the first example that looked right, or they scanned text and skipped the explanations that would allow a precise choice of alternatives (p. 199). Determining the precisely correct ways to structure a citation or punctuate complex clauses is tricky business. It might not surprise readers here to know that the student test subjects had such difficulties, since we see evidence in every class we teach, with whatever reference materials we use. It is important to remember too that our usability testing, as Howard’s, was conducted with new users in a lab setting. Performance is likely to be much improved among experienced users.

WEB-SERVED HANDBOOK

/

171

Life Cycle Planning Moving forward, we will be able to make continuous, incremental improvements to Writer’s Help. Because the product is online and centrally served, we have an advantage that has not been available to textbook writers in the past. As the product is classroom tested, we will know how students use the product, what they search on, and where they visit frequently. We will have a feedback loop that will allow us to adjust the language, capture student terms, and generate productive searches. We will discover problems and be able to fix things on the server side so the user experience improves without any fuss on the user side. We’ll get to know if students use the tools provided for customization and whether they are looking for new ones. We will have an easier time gathering instructor and student feedback since they will be online and able to send us notes on their experiences. We will be able to provide teachers with data on student use. Having a product out and functioning will allow us to incorporate new content into Version 2.0. We have a list for enrichment of content, with increasing attention to electronic and visual rhetoric, more expansive treatment of genre and style, and more on the specialized discourses of various academic and workplace communities. Importantly, expansion will be based on the kinds of help that students are looking for and the kinds of added pages that teachers create. We also anticipate further customization. For example, it might be useful if users could turn off or hide information that they never use, such as one or more of the documentation styles. If a student in chemistry (or a chemist in the lab) never uses MLA but relies on Council of Science Editors style, then adding a CSE module and suppressing all MLA, APA, and CMOS content from display and search would streamline presentation and not force the user to filter out irrelevant content. Similarly, users might choose to hide information on sentence fragments if they never make such errors. We also anticipate enhancements to the social and interactive features. There is an interesting tension in the product between the book’s function as an e-book reference tool versus a tool that facilitates interaction and social convergence in a writing class. It may turn out that teachers and students want more social tools, such as those found in classroom management systems (chat, whiteboard, discussion forums, blogs). Perhaps instructors would like some form of networking for their teaching concerns, materials, or strategies. Perhaps users will want more links to external resources on grammar, usage, or style. We might provide some sort of grammar hotline or blog. There is much to be said for a limited reference tool that is not overloaded with features. But there is also something attractive in imagining how Writer’s Help might evolve as a site for classes and composing in addition to being a help system with information about writing. Collaborating on Texts and Applications In figuring out how to create this new product, it has been immensely helpful to have a team of people with different areas of expertise and different perspectives. From a personal viewpoint, I feel lucky to have become part of this project. The work has pulled together various elements of my teaching and research interests: writing,

172

/

DESIGNING WEB-BASED APPLICATIONS

grammar, and style; information design and usability; visual and electronic rhetoric; professional and technical communication. Most of the time, when we work on a project, we focus on a particular area of understanding or expertise. We stop doing one thing to concentrate on another. But this project has called upon multiple areas of long-term interest, representing present and past inquiry, and in many ways the project feels nicely culminating, confirming that the various directions my career has tracked could actually converge in a single project. Another point of confirmation has been the opportunity to get to look inside the workings of a major, successful publishing house. When we write books, if we are lucky, we get to work with a good development editor and a good copy editor. When all goes well, the process is collaborative and rewarding. But it doesn’t always go well. As department chair at the University of Delaware for 5 years, I witnessed declining levels of support for faculty authors from university and trade academic presses. Many faculty were expected to prepare their own visuals or photographs to accompany their books, and they frequently had to pay per visual for the production work. Many faculty had to do their own proofing, with very little editorial support, and most had to create their own indexes or pay a professional indexer. One faculty member, working on a collection of essays of literary criticism to be published by an academic trade publisher, found that she was expected to prepare the full manuscript to be camera ready, including all page formatting, table of contents, index, and everything else. There was no editorial support whatsoever at this academic publishing house. That’s a grim situation, the worst that I witnessed. As chair, I worked to find sources of funds for publishing subventions, sometimes paying for the costs associated with preparing a manuscript, but also sometimes paying for a portion of the print run for the publisher. These may all be signs of an academic publishing industry in decline. My experience with Writer’s Help has been just the opposite. Inside Bedford, I found people with deep and informed interests in student writing, in the teaching of writing, and in information design. They embraced this project with gusto. They were eager to hear from students about how they write and work, and they maintained continual dialog with teachers and opinion leaders in our field. When we conducted focus groups at CCCC, various people from Bedford (editors, sales, marketing) wanted to be part of the discussions, and we had to limit who could attend so that most of the people in the room were our targeted participants, not company-internal people who were fascinated by the prospect of a new online handbook. The project called upon expertise at Bedford that cut across divisions, with people contributing from all directions. From the start, there was an atmosphere of excitement and enthusiasm, a real interest in creating something special. When the team ran up against the limits of their own expertise, Bedford was willing to go outside and hire consultants to help with interface and search function design. The team would critique new designs or test the search results, working on a very collaborative model of group critique, where different approaches were heard, different approaches tried out in prototype, and different prototypes tested with students and teachers. When the timeline for getting the product to market called for more internal resources, a new XML author was hired and other resources were devoted to the project. I’ve been fortunate to work in similar situations in other work I have done,

WEB-SERVED HANDBOOK

/

173

particularly in new drug development. When a product is important to a company, and when the project is complex, it is a great experience to be a member of an interdisciplinary, cross-functional team, working to bring a new product to market. Our shared challenge has been to understand what students and teachers want, how they work, and how an e-book might fit into their classrooms. The generous participation by students and teachers in the design process and the commitment of a talented team have led to a resource that reflects what our users want and how they work. We are optimistic about this new tool, Writer’s Help. REFERENCES Hacker, N., & Sommers, N. (2010). A writer’s reference. Boston, MA: Bedford/St.Martin’s. Howard, T. (2008). Unexpected complexity in a traditional usability study. Journal of Usability Studies, 3(4), 189–205. Nelson, M. R. (2008, March/April). E-books in higher education: Nearing the end of the era of hype? EDUCAUSE Review. Retrieved August 10, 2010, from http://www.educause.edu/ ero/article/e-books-higher-education-nearing-end-era-hype Reynolds, R. (2010). Digital textbook sales in U.S. higher education—A five-year projection. Xplana. Retrieved April 20, 2010, from http://blog.xplana.com/wp-content/uploads/2010/ 04/DigitalTextbooks_Report_04_19_10.pdf

http://dx.doi.org/10.2190/DWBC11

PART 3

Open-Source Modifications à à à CHAPTER 11

Peersourcing the PIT Journal: The Technosocial Pedagogical Hooks and Layers of Collaborative Publishing The PIT Core Publishing Collective

In Dreaming in Code, Scott Rosenberg examines the ways in which large technology projects come to fruition, explaining that people “make mistakes, and they correct them. They test and fix. They iterate” (2007, p. 298). Rosenberg extends this emphasis on iteration by equating software development with composition, suggesting that “programming today remains an act of writing” (p. 298). This analogy rings true for writing instructors who will recognize the suggestions that technology projects can be seen as creative (p. 299), social (p. 300), and emergent (p. 338). Rosenberg borrows from writing to help explain software development. We’d like to return the gesture, reversing the currents flowing through the programming-writing analogy and taking from software development insights like the value of reusable code and of thinking in layers. Rosenberg cites the “Lego dream” (2007, p. 93) to explain the benefits of building on the work of others. Programmers can rely on shared conventions and codes that act as plug-ins rather than rewriting everything from scratch. The challenge for writing instructors is the way in which many of our shared concerns, our Lego pieces, are implicit. Nevertheless, in practice, we build our teaching around such reusables. Some 175

176

/

DESIGNING WEB-BASED APPLICATIONS

of these bits of code in writing instruction have reached something like core plug-in status, for instance, writing is a recursive process. Other plug-ins are less recognized or more specialized, for instance, authentic writing yields internal motivation or format your final draft using double-spaced paragraphs. The Drupal content management system (CMS) calls these reusables “hooks.” Functions are written into the modular chunks of code that make up the Drupal CMS, while hooks link information between Drupal modules. Hooks represent reusable plug-ins and open themselves up for extension. To that end, we offer below a set of three hooks. Hooks that themselves are linked with discussions of teaching writing using technology. From technology projects, we also wish to borrow the insights offered by layers. Rosenberg explains, “software . . . is a thing of layers, with each layer translating information and processes for the layers above and below. At the bottom of this stack of layers sits the machine with its pure binary ones and zeros. At the top are the human beings, building and using these layers” (2007, pp. 280–281). Layers enable us to entertain the complexities inherent in thinking about writing and teaching. Like programs layered over operating systems layered over assembly languages, we can imagine our own concerns and entities co-informing one another—a composition, an author, an idea, a teaching tenet, a social context, shared conventions, and so on. We can talk about reusables or layers to understand writing and culture, much as Bruno Latour posits plug-ins as intellectual “clamps” (2005, p. 207) that enable us to trace among entities and concerns using an activity akin to writing: To obtain “complete” human actors, you have to compose them out of many successive layers, each of which is empirically distinct from the next. Being a fully competent actor now comes in discreet pellets or, to borrow from cyberspace, patches and applets, whose precise origin can be “Googled” before they are downloaded and saved one by one. (p. 207, emphasis in original)

We can borrow reusables and plug them in as a means of tracing among the layers that make up teaching and technology projects. Layers encapsulate tracings that sit among one another. But we suggest that layers also can overlap and mix. (Or perhaps we make adjustments in their opacity.) As Rosenberg puts it, “software’s layers are its essence, and they are what drive progress in the field, but they have a persistent weakness. They leak” (2007, p. 281). For our purposes, this kind of leakage is to be expected; exploring a plug-in like motivation, for instance, yields overlap with layers like authenticity or collaboration. Perhaps as a final gesture of borrowing from software, then, we will call this spillover not a weakness but a feature. Below we list our three hooks for exploring teaching, writing, and technology projects. We sketch briefly some of their key characteristics, but our full understanding of these plug-ins will become clear as the layers of exploration emerge throughout the rest of this essay. • Motivation: Helps understand or promote engagement with writing projects. The key distinction between internal and external motivation reveals layers related to creativity, enjoyment, and engagement.

PEERSOURCING THE PIT JOURNAL

/

177

• Authenticity: Can characterize and authorize writing projects. Can be connected with relevance and is often difficult to achieve in writing instruction. Connected with higher stakes for writing projects. Also linked with engagement and motivation. • Collaboration: A core plug-in for writing instruction. Extends to the dictum that writing is social and plays out in classroom practices like peer review. In contemporary technology discussions, collaboration surfaces in Web 2.0 communities and can be figured with the concept of “crowdsourcing.” PROJECT OVERVIEW We want to begin by making explicit the overlap between tinkering with technology and tinkering with writing. The term “tinkering” here implies the many activities grouped under paradigms of emergence and craft—iteration, experimentation, serendipity, creativity, fixing, and so on. This innovation, revising, tweaking, and tinkering is the basis of a Do It Yourself (DIY) approach in which reusables, both pedagogical and technological, can be cobbled together and re-iterated, especially when we teach with technology.1 The subject of this chapter, the PIT Journal, reveals key facets of this emergent tinkering including motivation, authenticity, and collaboration; facets that hook into the concerns of writing programs and compositionists. For instance, most writing instructors are interested in heightening student engagement. But scholars in the field of rhetoric and composition have not focused on the often-problematic nature of student engagement as much as we might assume. Few articles in the last 25 years have extensively explored the importance of student engagement. Compositionists J. D. Williams and Scott D. Alden pointed to this research gap in 1983. Today, this gap persists; writing instructors need additional pedagogical strategies for heightening student engagement in support of common rhetorical learning goals. A related concern is the insular nature of most writing courses. We believe that students value discovery and learning, enjoy being challenged, and are capable of producing interesting and exciting scholarship. But in most instances, “student writing is most often read only by instructors and classmates,” as John Benson and Jessica Reyman observed in their 2009 study (para. 1). When the audience of a single instructor assigning a “good grade” becomes the controlling factor in motivating student writers, the higher-order rhetorical concerns of more experienced writers—along with the potential impact of the student’s scholarship—are diminished. We thought that starting a journal to publish undergraduate scholarship might help us find a way to improve motivation and instruction by giving students an authentic public audience outside of their instructor who, to paraphrase one of our students, gets paid to read what they write. To provide an authentic public audience for student work, we created a peer-review platform using the open-source content management system known as Drupal. Drupal offers built-in functionality for multiple user accounts, roles with varying degrees of 1

For more on tinkering, see Anderson, 2009, Crawford, 2009, and Edbauer-Rice, 2008. Also follow the work of Computers and Writing scholars like Stephanie Ceraso, Ashley Hall, Jentery Sayers, and Derek Van Ittersum, among others.

178

/

DESIGNING WEB-BASED APPLICATIONS

permission to post and edit content, and an array of optional modules contributed by other Drupal users, which can be plugged in to extend the core’s functionality. Drupal is highly extendable and customizable, yet also comes with a basic core functionality for the management of users, the creation of content, and for facilitating social interaction. The basic steps involved in setting up an iteration of a Drupal site entail (a) creating a database using the open-source MySQL system, (b) installing the files that make up the Drupal software on a Web server (and associating the Drupal installation with the database), and (c) customizing and extending the Drupal installation by adding modules and adjusting settings. Practically, the steps involved in setting up a Drupal installation vary from institution to institution. For our project, we ultimately developed three installations as our needs evolved. Through our university IT systems, we created the public face of the journal (pitjournal.unc.edu). This installation required less customization, as it primarily serves to host the published issues of the journal and is more focused on delivering content. This installation hinged mostly on coordination with technology entities on campus, and then required a basic understanding of installing and customizing Drupal. But we also needed a platform for facilitating peer-review activities. To this end, we installed another version of Drupal using a private Internet Service Provider (ISP). On one hand, most ISPs make it easy to set up content management systems by supporting one-click interfaces that create the MySQL database and install the necessary Drupal files. On the other hand, most ISPs also allow more freedom to customize installations and experiment than one might find on a university system. In fact, this ability to experiment with installations led us to create two versions of our peer-review platform: one is a “sandbox” version where we experimented freely with new modules or customizations, and the other is our official peer-review site where we developed the platform that facilitated the posting of papers and responses by submitters to the journal.2 We chose Drupal over other content management systems with similar functionality for several reasons. Our central and most practical reason was that two members of our team, those who would ultimately be responsible for designing, building, and 2

Navigating the institutional territory involved in setting up such a site can be a challenge. At UNC, our work was made possible in two key ways. First, we had to establish healthy relationships with technology entities on campus. These relationships operate on multiple levels, with faculty frequently communicating with IT leaders about needs and support, and with faculty and instructors and developers coordinating with IT support staff to implement specific solutions. Key was coordination that gave two members of our team permission to install, develop, test, and maintain the PIT Journal’s Drupal platform. At institutions where obtaining this sort of administrative access is more complicated, a low-price commercial option may be preferable, considering factors such as speed, automated installation options, ease of use, and technical support offerings. Ultimately, our decision to use institutional resources and a private space for the project represents the benefits and challenges of both options. The university-based options provide sustainable institutional support and affiliation (but can be more limited in terms of experimentation and may require more coordination). The private ISP offers a near-instant means of setting up the space and puts fewer limits on experimentation (but also calls for more independent work from developers and lacks the benefits of institutional affiliation).

PEERSOURCING THE PIT JOURNAL

/

179

maintaining the online peer-review and publishing engine, already had extensive experience working with basic Drupal sites. The rich quality of modules contributed by the open-source community was another desirable feature, giving us many options to explore. And finally, the hooks built into the core Drupal code base allow developers who write their own modules to quite easily customize and extend the functionality that Drupal offers out of the box using logic similar to “the callback method” associated with event handling protocols (Butcher, pp. 11–14). This extensibility affords us with a long-term benefit by helping us imagine future iterations of our peer-review and publishing platform containing custom modules that we hope to design and then offer back to the open-source community, especially to those composition instructors who may want to embrace the DIY spirit of designing a robust Web-based application for their composition course without starting from scratch by writing all original code. The practical advantages of not starting from scratch while retaining great ability to modify and customize an installation of Drupal are immense. After investing only a few hours into setup and configuration, we created the public face for our journal, consisting of a half dozen informational pages. By default, Drupal supports multiple user accounts differentiating user permissions by role; creating roles for students, instructors, editors, and site administrators and assigning increasing levels of permissions to those roles completed the first phase of our semester-long iterative development. The time we saved by customizing Drupal’s core modules instead of writing our own code for these basic functions allowed us to focus our attention on the features we might want or need, leading us organically into the second phase of our project. We approached the development of our online peer-review and publishing platform very much like a draft of a writing project. The first phase entailed working primarily in our sandbox space while we figured out our goals and practiced a kind of invention. In some instances, this involved nothing more than enabling or configuring one of Drupal’s core modules, such as the blog module. In other cases, inventing and composing meant searching drupal.org for modules contributed by other developers that we could install, customize, and tweak to suit our needs. And in at least one case, it meant creating a module with original code. Like we do when we write, our invention process spilled over into planning and goal setting, then recursively moved back to more exploring and inventing as we worked. Our sandbox site served somewhat as a rough draft of our composition. As our work progressed, we did very little development in the sandbox and focused our attention on the peer-review platform. We still maintained an iterative approach, installing new modules and customizing as one might do in the middle stages of a writing project. While developing the PIT project, we kept tinkering, bringing together what we knew from the realms of writing instruction and technology, especially current thinking about Web 2.0 communities. Projects like Wikipedia, communities like flickr, and phenomena like online activism demonstrate the power of community knowledge, sharing, and action (Shirky, 2008). Jeff Howe describes the work of these groups as “crowdsourcing” (2009). Layering the pedagogical wisdom of peer review, which emphasizes its social components and collaborative nature, together with ideas about

180

/

DESIGNING WEB-BASED APPLICATIONS

networked social groups as collaborative, spontaneous, and powerful revealed a crosscurrent and a key concern driving the development of the journal: “peersourcing.” Peersourcing plugs online social tools into the practice of peer review, constructing a richer experience for student writers than just publishing a few of the best submissions in an online journal would accomplish. Integrating rating, commenting, and social networking features into our submission process hooked into pedagogical and technological layers simultaneously (see Figure 1). A staple of Web 2.0 communities, the rating tool enables a group to collaboratively develop evaluations of an item (e.g., Digg’s up/down diggit rating or five-star tools from Netflix and Amazon). As Jeff Howe puts it, such a tool “employs [a] crucial element of crowdsourcing—the crowd’s collective opinion—and it can be terribly effective” (2009, p. 158). We borrowed this collaborative functionality and modified a five-star rating module. We arrived at three possible ratings: not ready, almost ready, and ready to promote. We reasoned that our ratings choices would replicate the authenticity of the responses one might receive when submitting to a professional journal: reject, revise and resubmit, or accept with revisions. A promotion queue (see Figure 2) collected the submissions rated the highest (most ready) by our community of peersourcers. Our implementation of ratings represents a specific instantiation of a larger effort at blending Web 2.0 and pedagogical methodologies through peersourcing. Under peersourcing, a tool for composing, reviewing, and publishing student writing should also facilitate the interactions among readers and writers, should be “a hybrid of tool and community” (Shirky, 2008, p. 136).

Figure 1. A comment form and submission rating tool.

PEERSOURCING THE PIT JOURNAL

/

181

Figure 2. Promotion queue showing submissions promoted by reviewer ratings.

This layering can be seen in the deployment of a user-points module hooked into our “write one, read one” credo. To help create a community of writers and readers, we articulated a number of philosophical credos; statements like “write one, read one” meant to signify a communal contract among PIT participants. These credos help counter a potentially naïve assumption that a Web 2.0 platform will automatically lead to authentic engagement and better pedagogy. As Shirky puts it, “revolution doesn’t happen when society adopts new technologies—it happens when society adopts new behaviors” (2008, p. 160). For our purposes, pedagogical change is more likely to happen when new tools and new behaviors are adopted simultaneously. We needed to ensure that students were fully participating by posting reviews in addition to submitting, so in order to track (and encourage) this behavior, we automatically assigned one point for every comment a student posted.

182

/

DESIGNING WEB-BASED APPLICATIONS

Figure 3. User points earned for submitting reviews.

A core tenet of peersourcing is that reviews are as key to the writing and publishing process as are submissions. This was reflected in our point system that gave 1 point for every review and 10 points for reviews chosen as the “best.” A point has no intrinsic value, but quality reviews matter pedagogically. Our customization of the points module allowed us to instantiate this belief in the architecture of the teaching tool by giving users more points for the best reviews as determined by a paper’s author. When we layered points with roles (e.g., power reviewer and super reviewer) and badges (i.e., icons symbolizing different roles), a tool meant to track behavior linked into our hook of motivation. We installed the points module and the best-reply module separately before we realized that we could connect them by using yet another module—“rules”—to automate assigning points as a result of the “action” marked by a user choosing one comment as the “best reply.” Assigning points to the best reviews represents the kind of “happy accident” one often finds in DIY pedagogy facilitated by technology. Technological and pedagogical possibilities often open up serendipitously and simultaneously, and when they do, developers move forward to refine and implement them. Andrew Pickering figures this process nicely as “the intersection of the human and the non-human, in a trial-and-error search process that is open ended and forward looking” (2008, p. 3). Again, hooks and layers provide a good way of understanding this technological and human co-emergence. A technical layer, like a points module, might hook into a concept like motivation or collaboration. Through an extended process of this kind of trial and error, of hooking and layering, we developed and refined elements of the PIT platform and pedagogy. In the sections that follow, a collection of students and instructors who participated in launching the PIT Journal will report on three of the preliminary outcomes of the project: (a) heightened student motivation, (b) the construction of an authentic public audience for student writing, and (c) the potential to rethink how we approach peer review in the writing classroom. Although the following sections focus primarily on one of these

PEERSOURCING THE PIT JOURNAL

/

183

hooks at a time, the layers will bleed into one another, as will our voices. But remember, we consider this not a weakness but a feature. MOTIVATION, REWARDS, AND RISK Want to get published? This is the question we plastered on posters, blasted through listservs, posted on Facebook walls, and recited in classes during the first few days of the spring 2010 semester. Our immediate goal for all this publicity was to get students hooked; that is, to interest them in submitting to the PIT Journal. Linda Parker explains the success of this phenomenon for motivating local community members to write for a new feature in the online version of the Cincinnati Enquirer: “For some reason, ‘GetPublished’ [sic] were the magic words,” garnering many responses, where the phrases “tell us your story” or “become a citizen journalist” had failed to attract any hits (Howe, 2009, p. 106). Our own experience confirms the allure of a publication opportunity. First-year students Kandis Morgan and Mariana Lucena affirm that they were excited about the opportunity and challenge of becoming published. Mariana reported that, “the idea of sharing my work with others in hopes of ultimately being a published author caught my attention immediately.” For Kandis, the project seemed like it could be “a means for me to possibly be published, which was something I normally only thought of professors or grad students doing.” She adds, “The prospect of being published inspired me to excel in ways I never had before in my writing. It made me want to take a lot of pride in my opinions and my writing.” Why were students motivated by the possibility for publication? Kandis points to the ways in which the prospect of publication went beyond just a “line on the resume.” While the potential to be published got students’ attention, they did not see composing for the PIT Journal in order to get published as merely a means to an end. Rather, the students saw publication (and the process that went along with it) as an end in itself; an accomplishment they could take pride in. Kelly German captures these sentiments in her reflections on the project (responses reproduced verbatim): Before this class even began, I didn’t really want to be a part of it. English isn’t one of my strong points, or something I even enjoy, for that matter. Having said that, within a matter of weeks after the semester began, I felt so glad that I had been placed into the PIT class. I really developed a genuine interest in what we were doing and working on. I found my attitude shifting from “How quickly can I get this done?” to “How can I make this project the best that it can be?” One of the things I really enjoyed doing near the beginning of the semester was writing field notes. I felt like I was actually working on something that was enjoyable and showed that I really cared about what I was working on. I spent so much time interviewing students and filming that I am truly proud of the final video my group came together to make.

These possibilities for associating academic work with enjoyment and for discovering motivation that transforms impressions of time bring to mind the work of Mihaly Csikszentmihalyi, who discusses the balance between skill and challenge required

184

/

DESIGNING WEB-BASED APPLICATIONS

to enter the state of “flow,” which enables us to experience work as intrinsically rewarding. According to Csikszentmihalyi, the ability to cultivate entry into an almost meditative state of challenge, during which the rest of the world fades away helps us “to question the necessity of drudgery and anxiety” and “shows us that the boundaries between work and play are artificial” (2000, p. 190). Ideally, of course, this level of engagement happens in every writing classroom, but the students seemed to intuitively understand why it might be more of a challenge and thus more rewarding to try to get their composition published. This emphasis on the means over the end hooks into scholarship concerning internal motivation. As Marcy Bauman explains, “extrinsic motivation does not lead to intrinsic motivation. Once the extrinsic reward is removed, people do not generally continue to engage in the behavior for which they were rewarded” (1997, p. 166). We sought avenues to hook into internal motivation in ways that might yield layers of pride and accomplishment and turn publication into a more transformative experience. Again, we called on peersourcing. As Jeff Howe explains, the best online communities “[eschew] traditional forms of compensation” (2009, p. 180). Instead, they provide “a social environment [that] gives creative production a context in which the labor itself has meaning” (pp. 180–181). Participants in such environments find motivation in demonstrating skills among a community that acknowledges the quality of their ideas. “Others naturally strive to meet or exceed the standard set by the most talented of their peers, a tendency that effectively increases the overall quality of the work produced by the community” (p. 181). Jill, a developer and undergraduate editor, and Heather, an editor and PIT instructor, both recognize in the project an energy generated from dialogue and carried through the entire publishing process. A large part of this energy hooks into concerns of engagement and experimentation. Writing linear papers for an audience of only the teacher and peers begins to seem like busywork to students who do not already see writing as a craft open to experimentation and personalization. As a result, students’ desire to invent is subsumed by their desire to please the instructor and thereby earn a high grade. Unless they are explicitly built into the grade incentive system, tinkering and play become risky. Because purely grade-motivated students are risk-averse, it becomes far safer for them to simply discern what constitutes an instructor’s ideal paper and attempt to perform accordingly. Here, motivation again hooks into concerns familiar to writing programs. The concept of a “student-centered classroom” and the words “active learning” spring readily to mind. We do have concepts with which to discuss students being inspired enough to take an active lead role in their own learning process. And yet, judging from commonplace writing instructor complaints, these philosophies of engaging students seem often to remain stuck in the scholarship, at the theoretical level. During the 1960s and 1970s, Ken Macrorie (see especially “To Be Read,” 1968; as well as Telling Writing, 1970a; and Uptaught, 1970b) wrote copiously about student motivation, yet we continue to hear tales of students writing in what Macrorie called “Engfish” or poison fish, and we continue to read papers that open with some variation on “since the dawn of time,” or “in today’s society.” These stock openings represent the antithesis of what we might find in compositions characterized by experimentation and risk. In

PEERSOURCING THE PIT JOURNAL

/

185

contrast, a peersourcing approach hooks into the possibilities for experimentation and tinkering. For instance, Heather’s Science Writing students began to see how they might approach writing like an experiment: start with a problem, make observations and use models, formulate a hypothesis, tweak with this, mess with that, and see what kind of response you might get out of your audience. Revise, and repeat. Again, as Csikszentmihalyi explains, whether writing a poem or conducting a scientific experiment, “the experience tends to improve in proportion to the level of investment in it,” such that heightened challenge combined with the ability to tinker creatively leads to both “excellence and style,” which are inherently rewarding (1996, p. 349). What’s more, because they would be publicly available, with the potential to reach beyond the classroom, students ideas would continue to generate wider discussion, which also mimicked the scientific model of knowledge-making. Here, the project hooks begin to link experimentation with more “authentic” challenges and rewards.

THE CONSTRUCTION OF AN AUTHENTIC PUBLIC AUDIENCE Jill found that the PIT project encouraged even the youngest undergraduates at UNC to step outside of the student bubble, to “share [their] opinion with others in a scholarly manner” (see below). This scholarly perception is a core hook related to authenticity. It can be difficult to pin down exactly when or how an activity transitions from what might be called artificial into what we would celebrate as authentic. Matthew B. Crawford points us in a possible direction by linking authenticity with engagement. Crawford asks us to consider craft practices, “practices that entail skilled and active engagement: one’s attention is focused on standards intrinsic to the practice, rather than external goods that might be won through practice” (2009, p. 180). Where we find internal motivation and arrive at standards not prescribed by a class or teacher, but by the work itself, we find authenticity. And this authenticity pulls from social hooks: “the work is improved through relationships with others” (p. 187). And such work yields an authenticity that is emergent, resulting in activities that “contain their end within themselves; they enact that end, in ‘real time,’ as we now say” (p. 193). Authenticity is characterized by multiple layers that easily hook into peersourcing—intrinsic rewards, collaboration, iteration, and craftlike tinkering. Our students explain how they benefited from these authentic layers: Kelsey Smart Writing for the PIT presented itself as a very “hands-on” learning experience. This was by far the most extensive learning I have ever had in terms of the writing process. This learning, however, wasn’t learned through Ashley lecturing me about the “real” revising process; I went through all the steps on my own, with more than just my teacher and even my classmates helping me. I learned this information with other UNC students and through their feedback.

186

/

DESIGNING WEB-BASED APPLICATIONS

Mariana Lucena I went beyond the limits of what was asked for in the class, and I was more inclined to read other PIT members’ work in order to reach a higher level as a reviewer. More guidance would have been helpful, but at this stage of our careers (college students), I think the less instruction we have the better writers we will become as we get to have our own experience and not be “taught by the book” in some formulated manner. Kandis Morgan A difference in writing for the PIT and not just for a grade was that I was actually contributing to a larger conversation that others are a part of. My writing became more than a way to get a good grade; it became a way for me to share my opinion with others in a scholarly manner. This changes a great deal of things. For one, I was more motivated to actually make my writing count for something. I didn’t want to simply seem like a freshman writing a paper about something I really knew nothing about. I was motivated and inspired by the fact that I actually had something to contribute about a topic other scholars are writing about. Michelle Moore I liked being able to see the profile of the person who left the comment. One of the people who critiqued my paper is a law student here at UNC. It made me feel good that she had good things to say about my paper, and I feel like her advice is credible.

Responses suggest that students were able to play and improvise in innovative and emergent ways through the social interactions with an authentic audience facilitated by the PIT Journal. And their “hands-on” learning experience enabled a deeper engagement with the writing process and led to their desire to experiment rather than ask (as students so often do) what the teacher wants them to do. Kandis’s explanation that her “mindset of writing was completely different” affirms that the PIT platform helped students to take their educational experience into their own hands and play with it while finding greater authenticity as part of an online community of writers. Their experiences also confirm what Heather saw happening among her students, which was less procrastination, accompanied by more internal motivation stemming from the anxiety and excitement that others outside the classroom would be engaging with their ideas. Students understood for whom they were writing and could clearly articulate their purpose for writing, including the development of specific revision goals and strategies for achieving those goals. One student described the experience in this way: Since we were writing for a real audience instead of some arbitrary made-up audience, I was motivated to make my paper the best it possibly could be in an attempt to possibly even get it published in the journal. I was able to get feedback from real people, a real audience, not just the person sitting next to me in class who is forced to read my paper and come with things to tell me that may or may not actually fix it. Using the PIT Journal Web site, I received focused feedback that allowed me to truly understand the weaknesses in my paper and to develop strategies for fixing these problems. This can be seen in my revision plan posted on Blackboard, something that I have never done before.

PEERSOURCING THE PIT JOURNAL

/

187

This student’s comments remind us of the problems caused by the insular and often artificial nature that seems to persist in classroom experiences. Susan Lang suggests that as writing instructors, “we prefer to keep the concept of audience manageable in terms of whom we think our students are capable of writing for” (2003, p. 266). Instead, she argues, we ought to “conceive of an audience as a dynamic contributor to an interpretive act” (p. 266). The student’s description of his PIT Journal experience shows how the audience became a dynamic, real, and essential part of his composing and revising process. For many PIT Journal participants, the once-vague concept of audience was transformed by the authenticity of potential publication and the conversational practices that emerged in this online experiment where students, instructors, and developers shared the feeling that they were collaborating together in a new and interesting composing experience. RETHINKING COLLABORATION AND PEER REVIEW Like many first-year composition programs, UNC emphasizes peer revision and group work in order to provide students with feedback on their writing and to encourage students to see writing as a social endeavor. Still, students can seem unwilling to buy into the idea that knowledge is produced in a community of writers and readers, not by a “solitary writer alone in a cold garret working into the small hours of the morning by the thin light of a candle” (Brodkey, 1987, p. 396). At the same time, students are often too willing to hand over authority to their instructors. And, no matter how thoroughly we emphasize holistic review, many of us still find our students marking commas, misspellings, and split infinitives in their peers’ texts. Nancy Sommers calls this sort of feedback the “appropriati[on]” of a student text. Instead of fixating on the minutiae that really should be reserved for final polishing, we ought to be encouraging students to go back to the “chaos” of an earlier draft, and work on substantially clarifying their ideas, deepening their research, and re-articulating their arguments. (1982, p. 152)

The PIT Journal’s rating and comment tools help students to “comment as a reader about effects rather than as an editor trying to fix the text” (Elbow, 1999). The tools compel readers to engage with the whole text in terms of its ideas, argument, and structure, and to look for ways to improve the text on the macrolevel rather than getting sidetracked by spelling errors or punctuation problems (see Anderson, 2003, p. 192). The open-endedness of the PIT comment feature helps students move away from the “teacher-mandated concerns” that tend to take over guided peer-review sessions (Di Pardo & Freedman, 1988, p. 127). The PIT platform hooks into the philosophy that the reader’s job is not to “fix” the text but to respond to it thoughtfully. Further, the social nature of the platform helps to engage students in a process of iterative collective revision. When submitting their work to the PIT Journal, writers committed themselves to both giving and receiving substantial peer feedback on the submissions, and they were aware that publication would depend somewhat on the extent to which

188

/

DESIGNING WEB-BASED APPLICATIONS

they were willing to work with peers to improve one another’s papers. By removing response and revision activities from a classroom setting where readers and writers have shared contextual experiences, student reviewers necessarily approached the text as readers interested in helping a paper to become a document of interest to a public audience. Again, this peersourcing hooks into writing program goals by layering together authenticity and peer review. The cadre of PIT reviewers essentially functioned as an enormous reading group— a wide and varied audience (in large part self-selected) for writing. This collaboration was facilitated by our customization of the bookmarks module that we modified to enable users to “follow” one another’s submissions as they moved through our peer-review and publishing cycles. A student reader who opts to follow a piece is kept apprised of any changes or revisions made to the original through a custom dashboard we designed using the “home box” module. In this way, writers and reviewers can easily stay connected through a series of exchanges that are displayed within each user’s customizable dashboard, akin to adding widgets and RSS feeds to iGoogle or MyYahoo: a writer uses the dashboard as a portal to find other submissions to review and as a point of access to track and read the feedback offered on her own submission. Ideally, the author would use these comments to revise her piece and respond to her reviewers by posting a comment explaining her revisions. Reviewers would then reread the piece and affirm what the writer had done or suggest further revisions. The dashboard displaying ratings and comments on one’s own submission along with updates to submissions the user is following or reviewing helps to sustain an ongoing electronic conversation between readers and writers. Not only does this model more accurately mimic the way professional writers and editors work (often corresponding via e-mail), but by deemphasizing final products in favor of conversation and negotiation, the model reinforces ideas about writing as a continuous and social process (Figure 4). The bookmarks module we customized to enable readers to follow selected submissions reminds students that an important goal of public, academic writing is, simply, to appeal to and attract readers. We agree with Elbow when he claims that “only if we like something will we get involved enough to work and struggle with it” (1999, p. 189). So by valuing students’ choices and enabling their long-term engagement with one another’s work, we confer another kind of authority on student readers. And we promote the kind of iterative commitments between readers and writers that lead to more effective reviews and revisions, yielding motivation, authenticity, engagement, experimentation, and collaboration. Again, we can see these layers in student reactions to the project: Kelsey Smart Getting feedback from others and seeing their opinions allowed me to get a variety of perspectives on my work. I liked receiving feedback from other UNC students in addition to just my in-class peers because I feel like since I didn’t know the people commenting on my work, they were giving me their honest opinion on the changes they felt I should make. It made the whole experience more interesting and helped me in my revising process.

PEERSOURCING THE PIT JOURNAL

Figure 4. Comments generated by a peer following a submission.

Mariana Lucena As far as the PIT rating system goes, I actually did enjoy the way I was able to give and receive criticism. Prior to being an active member of the PIT Journal, the feedback I gave or received wasn’t as thorough as what the PIT allowed. Having the power of giving others feedback and having the authority to reject the essay or promote it to the next level was, I guess, a psychological way of feeling more power than if it would have been a regular class assignment. Kandis Morgan Participating in PIT also changed the way I revised. I would say writing for the PIT gave me a taste of how lengthy and complicated the actual revising process is. And was I in for a shock. My revisions for my article were pages of more writing, not just correcting a grammatical error here and there. The difference in revising my PIT article and other writing assignments for other classes was that I actually wanted to make these changes. Before, I would probably see that something needed

/

189

190

/

DESIGNING WEB-BASED APPLICATIONS

more to it, but knew based on a grading scale, I could get away with not adding something I should. With my PIT submission, I actually wanted to make my article better. Yes, the revisions were hard, and effort into revising was very timeconsuming, but I actually wanted to make paper as strong as I possibly could because others would be reading it, not just my teacher.

As evidenced by student comments, our peersourcing model worked well. The comments and ratings that the students gave one another seemed very consistent with the PIT editors’ impressions of the submissions. Initially we had doubts that the best work would always meritocratically rise to the top, which was part of the reason why we instituted an editorial final review process, but ultimately the peersourcing model of qualitative plus quantitative feedback seemed to result in selections that mirrored our own judgments. What’s more, as Kelsey’s, Mariana’s, and Kandis’s responses indicate, most of our student feedback confirmed our prediction that the PIT Journal’s design would help students gain the confidence to assert their own authority, as both readers and writers, over their texts. CONCLUSION Ultimately, the PIT process (from initial submission to peer-review activities to eventual publication) resulted in more autonomous and engaged student readers and writers. And participation in the PIT Journal’s peersourcing model resulted in more extensive and iterative revisions, which ultimately led to higher-quality pieces. The students who put the most time into rewriting their papers reaped the corresponding reward of being promoted to the editor’s queue, and most of these compositions were very thought-provoking, nuanced, and polished. As Jill notes, the editors’ work as a selection committee didn’t come about until well into the process, after the early rounds of reviewing, dialogue between peers, and revisions. The community audience was therefore literally of “first and foremost” importance. And the peersourcing community provided the editing team with an immense set of feedback, which largely informed acceptance decisions. The real audience for the contributor’s writing included everyone from the earliest commenters and voters to the editors of the PIT team to the interested reader browsing a published article on our Web site. Just as the students themselves affirmed that their writing took on a different feel when they knew it might be read by an audience beyond the classroom, we also experienced this at the developer, instructor, and editorial level by hooking into layers of innovation and engagement. We all wanted our first journal issue to be something that we could take pride in, something that we had created collaboratively, something well-crafted and authentic. Even though this process took longer than we had imagined, in the end it was worth the wait, and it was exciting to see how the final versions came together, complete with pictures, abstracts, and an introductory preface (Figure 5). The students who collaborated in our first review and publishing cycle offered their own patterns of critique, their own dynamic feedback loop pointing toward ways that we can revise the project in the future. Some students, for instance, still demonstrated in their responses more focus on surface-level correctness than we would like to see. Some

PEERSOURCING THE PIT JOURNAL

/

191

Figure 5. The Table of Contents for the inaugural edition of the PIT Journal.

students reported confusion over some of the PIT layers such as the point-based tiers of user roles (reviewer, power reviewer, super reviewer) that we tried to implement. One student explained, “I still have no idea what the point of the points was.” Similar concerns were raised about the rating system: “A lot of the time I thought the paper was really close to ready but still needed to revise. Maybe a system of five ratings rather than three or something.” This comment reflected a pattern that showed up among other students who indicated that the three-level rating system was not nuanced enough for them, both as reviewers and as authors. Such sentiments were also shared by editors who factored peer ratings and comments into their selection process. All of these suggestions plug into our deliberately inclusive, democratic, and iterative approach to developing the PIT project. We have learned a great deal from our collaborators. We have enjoyed creating an engaging and authentic composing, reviewing, and publishing experiment. And we are ready to keep tweaking.

REFERENCES Anderson, D. (2003). Web-based peer review. In J. R. Galin, C. P. Haviland, & J. P. Johnson (Eds.), Teaching writing in the late age of print (pp. 185-198). Cresskill, NJ: Hampton Press.

192

/

DESIGNING WEB-BASED APPLICATIONS

Anderson, D. (2008). The low bridge to high benefits: Entry-level multimedia, literacies, motivation. Computers and Composition, 25(1), 40–60. Anderson, D. (2009). Yes and yes-and: Time in the compshop. Currents in electronic literacy. Retrieved October 20, 2009, from http://currents.cwrl.utexas.edu/2009/Anderson Bauman, M. (1997). Upsetting the apple cart: What grades do for us and how to do without them. In S. Tchudi (Ed.), Alternatives to grading (pp. 162-178). Urbana, IL: NCTE. Benson, J., & Reyman, J. (2009). Learning to write publicly: Promises and pitfalls of using weblogs in the composition classroom. Computers and Composition Online. Retrieved from http://www.john-benson.net/blogstudy/ Brannon, L., & Knoblauch, C. H. (1982). On students’ rights to their own texts: A model of teacher response. In R. Staub (Ed.), A sourcebook for responding to student writing (pp. 117–128). Cresskill, NJ: Hampton Press. Brodkey, L. (1987, April). Modernism and the scene of writing. College English, 49(4), 396–418. Butcher, M. et al. (2010). Drupal 7 Module Development. Birmingham, UK: Packt Publishing. Csikszentmihalyi, M. (1996). Creativity: Flow and the psychology of discovery and invention. New York, NY: HarperPerennial. Csikszentmihalyi, M. (2000). Beyond boredom and anxiety: Experiencing flow in work and play. San Francisco, CA: Jossey-Bass. (Original work published 1975.) Crawford, M. B. (2009). Shop class as soulcraft: An inquiry into the value of work. New York, NY: Penguin. DiPardo, A., & Freedman, S. W. (1988, Summer). Peer response groups in the writing classroom: Theoretic foundations and new directions. Review of Educational Research, 58(2), 119–149. Edbauer-Rice, J. (2008, December). Rhetoric’s mechanics: Retooling the equipment of writing production. College Composition and Communication, 60(2), 366–387. Elbow, P. (1999a). Ranking, evaluating, and liking: Sorting out three forms of judgment. In R. Staub (Ed.), A sourcebook for responding to student writing (pp. 175–196). Cresskill, NJ: Hampton Press. Elbow, P. (1999b). Options for responding to student writing. In R. Staub (Ed.), A sourcebook for responding to student writing (pp. 197–202). Cresskill, NJ: Hampton Press. Fishman, J., Lunsford, A., McGregor, B., & Otuteye, M. (2005, December). Performing writing, performing literacy. College Composition and Communication, 57(2), 224–252. Howe, J. (2009). Crowdsourcing: Why the power of the crowd is driving the future of business. New York, NY: Three Rivers Press. Lang, S. (2003). Why write and to whom? Revisiting concepts of audience and purpose. In J. R. Galin, C. P. Haviland, & J. P. Johnson (Eds.), Teaching writing in the late age of print (pp. 265-275). Cresskill, NJ: Hampton Press. Latour, B. (2005). Reassembling the social: An introduction to actor-network theory. Oxford, England: Oxford University Press. Macrorie, K. (1968, May). To be read. The English Journal, 57(5), 686–692. Macrorie, K. (1970a). Telling writing. New York, NY: Hayden. Macrorie, K. (1970b). Uptaught. New York, NY: Hayden. Marick, B. (2008). A manglish way of working: Agile software development. In A. Pickering & K. Guzik (Eds.), The mangle in practice: Science, society, and becoming (pp. 185-201). Durham, NC: Duke University Press. Pickering, A. (2008). Preface. The mangle in practice: Science, society, and becoming. In A. Pickering & K. Guzik (Eds.), Durham, NC: Duke University Press. Rosenberg, S. (2007). Dreaming in code: Two dozen programmers, three years, 4,732 bugs, and one quest for transcendent software. London, England: Crown.

PEERSOURCING THE PIT JOURNAL

/

193

Sawyer, R. K. (2006). Explaining creativity: The science of human innovation. Oxford, England: Oxford University Press. Sawyer, R. K. (2007). Group genius: The creative power of collaboration. New York, NY: Basic Books. Shirky, C. (2008). Here comes everybody: The power of organizing without organizations. New York, NY: Penguin. Sommers, N. (1982). Responding to student writing. College Communication and Composition, 33(2), 148–156. Williams, J. D., & Alden, S. D. (1983). Motivation in the composition class. Research in the Teaching of English, 17(2), 101–112.

http://dx.doi.org/10.2190/DWBC12

CHAPTER 12

Blogs as an Alternative to Course Management Systems: Public, Interactive Teaching with a Round Peg in a Square Hole Steven D. Krause

A “kludge” (or “kluge”) is a workaround to a technical problem, often ad hoc and cobbled together, generally inelegant yet effective. It tends to have negative connotations, though as any enthusiast for duct tape, repurposed wire hangers, shoes turned hammers, or other initially temporary but ultimately permanent solutions will attest, there is a certain satisfaction in getting around the sanctioned solution with a kludge. After all, one person’s ineffective and sloppy kludge is another person’s simple solution and, in the case of course management systems, vice-versa. This chapter is about using blogging software as an alternative to institutionally sanctioned content/course/learning management systems (CMS) for teaching online. Specifically, I will discuss my choices and experiences in opting out of my institution’s CMS in order to escape that software’s numerous limitations and to take advantage of the power, ease, and flexibility of the popular and open-source software, Wordpress. While it is generally thought of as a software for blogging, Wordpress is a powerful enough software to manage the kind of content that is typically used for teaching an online or hybrid college course. I’ll begin by discussing the problems of CMSs, focusing on the inflexibility and closed nature of these systems. Then I will discuss some of the questions and issues anyone interested in moving away from an institutional CMS needs to consider before taking the plunge. I close this chapter with a discussion of the largely positive but still double-edged nature of the “public online class.” WHAT’S WRONG WITH COURSE MANAGEMENT SYSTEMS? Blackboard has the worst discussion board I have ever seen, and it is untouched in Bb9. It is so bad that in one class the students rebelled and created their own discussion board. . . . I can’t believe they can actually sell this product. It is so lame. 195

196

/

DESIGNING WEB-BASED APPLICATIONS

It’s pretty discouraging that a software application we’ve used for six years is almost completely unusable by someone with a willing spirit and open mind who just wants to do the most mundane of tasks. Rather than becoming more intuitive in newer versions, it’s less so, perhaps in order to inspire universities to buy constant updates and pay additional money for customization. —Two recent complaints about Blackboard from an electronic mailing list and follow-up e-mail discussions, quoted anonymously with permission.

Complaints about CMSs, like these about Blackboard, are easy to find, and while Blackboard has often been singled out as “the worst” because of its enormous market share, it is far from the only CMS that many users love to hate. While my primary purpose here is not to dwell on these problems, I think it’s important to consider some of these issues since the problems are what compel faculty to seek alternatives. After all, if these applications worked as well as they should, the complaints and the motivations for seeking an alternative would be minimal. I want to focus on two global issues with institutionally supported CMSs, even the best configured, best supported, and best intentioned systems. First, CMSs, because of their limited options and large scale, rigidly shape the pedagogical approach of the course—instead of the other way around—and that approach is often at odds with current pedagogical assumptions with the teaching of writing. As Lisa Lane (2009) writes in her First Monday Web site article “Insidious Pedagogy: How Course Management Systems Impact Teaching,” “The built–in pedagogy of the big systems is based on traditional approaches to instruction dating from the nineteenth century: presentation and assessment.” Metaphorically, CMSs construct virtual spaces of neat rows of desks filled with students sitting upright and attentive, listening to the teacher speaking from a podium at the front of the room. “The genetic weakness of the contemporary CMS,” Van Weigel (2005) wrote in Educause, “stems from its uncritical acceptance of the traditional features of the classroom model” (p. 55). It is as if CMSs are created as the software developers might imagine how teaching works as depicted in an ahistorical television drama. To be fair, this structure probably works for courses where instruction is based less on interaction and more on lecture, or courses that rely on standardized quizzes and tests to measure success. Further, as Lane (2009) points out, a lot of the problem is not with the capabilities of the software but the lack of willingness of instructors to take advantage of the improved capabilities CMS developers have added in recent years. Many don’t move beyond the basic default templates of the CMS because it is too difficult to do so, but I think it is more significantly because many instructors’ lack of awareness or concern of how the CMS shapes their pedagogy. Kevin DePew and Heather Lettner-Rust (2009) discuss this issue at some length concerning a number of teaching settings, including online teaching, in “Mediating Power: Distance Learning Interfaces, Classroom Epistemology, and the Gaze”: Few would argue that the media chosen to teach distance learning—from the postal service to video conferencing—influence the way instructors teach the course. But

BLOGS

/

197

with our most recent iterations of distance learning mediated by digital technologies with more expansive repertoires of communicative media, this claim about the changing nature of distance learning may be parsing the difference between course management and the epistemological philosophies that inform the course curriculum’s pedagogical design. For instance, digital technologies provide several pedagogical affordances, such as the ability to teach courses at a desired pace (as opposed to one dictated by the postal service), to correspond with distance students synchronously through writing and video, and to distribute information quickly on a large scale. In spite of these affordances, many instructors in disciplines across the campus disseminate their knowledge much like a lecture presented through the interface of the traditional face-to-face classroom. Later in the semester, students demonstrate their reception, or sometimes understanding, of this knowledge through examination. By applying this approach that Paulo Freire (2003) coined “the banking concept of education,” certain instructors and administrators conceptualize the technology as a mere tool that facilitates the distribution and reception of the course rather than an opportunity for conceptualizing new pedagogical practices based upon the new affordances digital interfaces offer. This is particularly important when instructors teach writing at a distance. As instructors who teach writing know, the banking model of instruction is rarely conducive or appropriate for their curriculum. (p. 175, emphasis mine)

I’m not arguing that Wordpress as an alternative to institutionalized CMSs is inherently a solution to problematic teaching. If instructors have not critically examined the ways in which the institutional CMS has restricted their teaching, then it is likely that an alternative like Wordpress will also be used as a “mere tool” for delivery. And simultaneously, I would also argue that if instructors critically examine the limitations and problems of their institutional CMS, they will be better able to use that tool for teaching beyond mere delivery. Nonetheless, for teachers who have engaged in a thoughtful consideration of the implications of CMSs on their teaching, it is difficult to deny the pedagogical assumptions and inflexibility of CMSs. And, as I hope to demonstrate, the power and flexibility of an alternative like Wordpress allows teachers to better shape the technology toward a more contemporary pedagogy. The second global problem of CMSs is their place behind firewalls and their inaccessibility to readers on the “real” Web. Now, there are some practical and important reasons for this, most notably individual student grades, which should (and must, according to U.S. federal law) remain a private matter. However, the firewalled CMS reinforces the metaphor of the closed classroom, and I believe these closed CMSs are at odds with most of the basic presumptions of contemporary writing pedagogy; presumptions that are common to the point of being “mantras” among writing teachers. It is hard enough in a conventional, “face-to-face” classroom to teach students that writing is a social process and that students should aim for an audience of real readers beyond “the class” when that teaching takes place in a classroom obviously cut off from the real world and where students write solely in response to an instructor’s assignments and grades. It is even more difficult to get this message across in an online class taught with a firewalled CMS since, in an online class, students literally complete the assigned work of the class alone, generally in front of their own computer and in the privacy of their own home. And, because of the security of that firewall, students rightfully believe

198

/

DESIGNING WEB-BASED APPLICATIONS

that their writing and learning will remain a “private matter” between them and the instructor; the social interactions assumed to be a part of the writing process are all but eliminated. To take Freire’s famous banking metaphor to another level: firewalled CMSs honor an online banking and purchasing metaphor, one where learning to write is as private a matter as paying bills online or placing orders with amazon.com. The other notable problem of the closed CMS is that it is difficult to bring in “real-world” participants into the class. In the face-to-face classroom, bringing in an outside participant (a guest speaker, community members, etc.) is as easy as extending an invitation. In contrast, bringing in outsiders—invited or otherwise—into an online class locked behind a closed CMS is complicated. Weigel (2005) notes this in his article and in his vision for the next generation of CMS capabilities, when he calls for a “360 degree out-of-the-course capability.” Part of what he is imagining is a CMS that could incorporate “community educators” from outside of the class; educators who could serve as respondents to online seminars or outside evaluators of students’ work (p. 63). As I discuss in the last section of my chapter, this real and public participation in an online class is facilitated and even encouraged with Wordpress as a CMS, though bringing a class completely into the public is a power that ought to be used carefully. Of course, “what’s wrong with CMSs?” begs the question, “what’s right with Wordpress?” or any other “do-it-yourself” alternative. I’ll return to this issue later in the chapter, but I think David Parry (2010, para. 3) sums up nicely the basic “pros” of Wordpress in his ProfHacker Blog post “WordPress a Better LMS”: • You can get an instance of WordPress hosted for free. • It is super simple to set-up. • It looks like the rest of the web, i.e., students find it much easier to use. (Indeed the fact that I don’t use Blackboard is one the most frequent and positive comments I receive from students on evals.) • It is open, i.e., it makes it really easy to share my material with other instructors around the web, and for me to see what other instructors are doing. • If you are hosting your own, i.e. not on the university’s servers, you own your own course material, making it easier to take with you when you go. • Did I mention that it is free? Think of how much money this would save your school. LEAVING THE CMS AND GOING TO WORDPRESS: THE QUESTIONS TO ASK THE “POWERS THAT BE” AND YOURSELF As the subtitle implies, this section discusses the four basic questions I think you need to ask yourself before making the shift away from an institutional CMS to Wordpress. Obviously, there are many other options similar to Wordpress—Blogger, tumblr, MoveableType, and Typepad immediately come to mind—and there is no doubt that by the time this chapter actually reaches press, other options will be available. However, I am focusing on Wordpress because I think it is the best CMS-like solution currently available, and also because it is the software I have used and am thus

BLOGS

/

199

most familiar with. Also, keep in mind this is not a “how to” guide for setting up Wordpress, though I offer suggestions and links along the way as to where you will be able to get more detailed information and instructions. Wordpress is similar to other blogging and CMSs in that it allows a user to easily enter in content with minimal technical expertise that is then consistently displayed on the Web. For readers unfamiliar with Wordpress and similar blogging software options, here is a very basic example of what I am getting at: Figure 1 is a screenshot of the Wordpress.com “dashboard,” the interface where users enter in content. As you can probably guess by the buttons on the left, there are a variety of different controls and functions possible on this page; but basically, a user enters in text and content into the window above and pushes the “Publish” button on the right side of the screen. Figure 2 is a screenshot of how this content is displayed on the Web. This is how the current content looks on the Web (this example is at http://blogs ascmsexample.wordpress.com), and it literally took me about 5 minutes to get working. As I will get to in a moment, there are many different ways to customize the way this content looks, and there are some slight differences with the version of Wordpress installed on your own server space. Question 1: Will my institution allow me to do this? Is there an official policy and/or unofficial understanding? While I am unaware of any studies or surveys, my own sense from discussing the matter with colleagues at other institutions while at conferences and via e-mail over the years is that there is no consistent or easy answer to this question. Some universities prohibit any use of anything but the official CMS, while

Figure 1. Screenshot of the Wordpress dashboard.

200

/

DESIGNING WEB-BASED APPLICATIONS

Figure 2. Screenshot of Wordpress blog.

others are open and even supportive of faculty seeking alternatives. But most seem to address the problem on a case-by-case basis, or even with nonpolicies I can only describe as “don’t ask, don’t tell.” Some of my colleagues report that they asked and received special permission to use Wordpress and similar do-it-yourself solutions to teach, and other colleagues reported they simply ignored the official CMS and set up their own solutions without telling anyone in charge. I will dispense with discussing the merits (or lack thereof) for these official policies and unofficial understandings; I will only note that this is clearly a very local problem that requires local answers and solutions. The other problem is that these rules are often rather fluid. For example, at my institution, Eastern Michigan University, the “powers that be” allowed me to teach online with Wordpress, in part because I had demonstrated previous experience and expertise, and also because I am a tenured professor and thus more “empowered” than an adjunct or tenure-seeking assistant professor. Frankly, if the circumstances were different, that is, I was unknown to my colleagues in Continuing Education or I was a part-time instructor, I am not sure my move away from the institutional CMS would have been supported. The only condition I was given is the need to link to my course site from the CMS course shell, which thus allowed both late students and EMU support staff to find my course. Question 2: How am I going to handle grading and copyright-protected materials? Some content, like grades and copyright-protected material, needs to be behind a firewall and not in a public space. Once again, local conditions for how to handle this will vary.

BLOGS

/

201

At Eastern Michigan, I use our library’s electronic reserve system for distributing copyright-protected/on-reserve readings electronically. The system requires a password, and conveniently, I can link to this resource from my Wordpress site. While I could maintain my own grade book with a spreadsheet and communicate grades to my students via e-mail, my preference is to use the grade book function on my institution’s CMS. I find this convenient because students can access comments and grades I submit to this system without the extra step/labor of me e-mailing them; and in the case of grades, the extra layer of security in the institution’s sanctioned and protected system makes sense. Besides, the grade book of the CMS at EMU is one of the few features I find useful. Question 3: Which version of Wordpress do I want to use: wordpress.com or a self-supported installation from wordpress.org? By “Wordpress” in this chapter, I am actually thinking of two different but similar options: the service and blogs available from Wordpress.com, and the open-source software available from Wordpress.org. Wordpress.com offers “free” and “upgraded” blog hosting using a version of Wordpress that is more limited than the open-source and self-hosted version. It’s easy to set up and use, and it is quite robust: 3 gigabytes of storage space (more than enough for thousands of text files and hundreds of images), a variety of theme designs, some customization options, multiple blog and authoring options, and so on. Wordpress.com also allows a variety of privacy options; for example you can password-protect specific posts or pages, and you can even limit the visibility of the entire blog to 35 users. Domain names for the free version always include wordpress.com; for example, techforteach.wordpress.com. Free Wordpress.com sites also include some minimal advertising. The upgrades of Wordpress.com vary in price based on the particular upgrade, and options include increased storage space, video publishing, and an unlimited number of private users. On the other hand, Wordpress.org is the homepage for the free and open-source software option for Wordpress. Users download the software from the site and install it on a suitable Web-hosting service provider. Many Internet servers are capable of supporting Wordpress installations, and there are thousands of companies that provide these services for a fee, generally less than $100 a year. The advantage of this option over Wordpress.com is that it is much more flexible and customizable, and your domain name and storage space configurations are limited only by your Web host. Instead of around 100 theme designs available via Wordpress.com, there are over 1,000 different themes available from Wordpress.org to install and customize, and more available from other Web sites. With your own Wordpress set up, you can install a wide variety of plugins, which are essentially additional bits of computer code you can use to customize a variety of different functions of your blog. And with your own installation of Wordpress, your domain name is also your own (e.g., a site associated with your institution if they support software like Wordpress, or your own domain name, such as engl516.stevendkrause.com). Which Wordpress solution to choose? That depends. For me, the advantage of using Wordpress on the server space that I lease is in the software’s flexibility and functionality, not to mention my own sense of electronic identity, ownership, and

202

/

DESIGNING WEB-BASED APPLICATIONS

control over the site. However, this option is not free (since my institution does not have server space to support my class pages), and running a blog with your own installation of Wordpress on your own does take significantly more technical expertise than it does to run a blog on Wordpress.com. This is not to say you have to be a trained systems administrator to manage Wordpress on your own server. It is easy to install, there is ample help documentation on wordpress.org, and there is a robust support community of developers and other Wordpress users to answer questions. But like all open-source software, maintaining your own installation of Wordpress is more demanding than having another service do it for you for free or a fee. Using myself as an example: while I’m not a “computer expert” per se, I am comfortable performing my own technical support, I upload and download files to server space using FTP/SFTP tools, I’m familiar with and teach the basics of XHTML and CSS, and I know enough about how software like Wordpress works to recognize what I should and shouldn’t tinker with and how to ask for help. So, at the risk of being a bit snarky, if you have never installed software on server space before or if you have to ask “do I have the technical expertise to run Wordpress by myself,” then you probably should begin with the free version available at Wordpress.com. While I prefer the self-supported and open-source version of Wordpress, I have previously used the “.com” version instead of an institutional CMS, and I routinely have my students use Wordpress.com as a blog space and as an “ePortfolio” of sorts. My students post drafts and revisions of their individual essay projects and some other class writing projects on their own blogs, and I link to them on the class Web site/blog that I maintain. Having students set up their own blogs with Wordpress.com is an easy way for them to be introduced to a modest technical skill (e.g., how to set up your own blog via one of the major free providers), it allows students to have more control and responsibility for the work they publish, and it eases my “technical support” burden. Question 4: Am I willing to take on the responsibility of moving away from the institutional CMS? Obviously, the answer to this question for me is “yes.” After all, I have been teaching online and face-to-face courses with Wordpress instead of my institution’s CMS for some time now, and I wrote the essay advocating this move that you are reading right now. For me, the technical demands of Wordpress are manageable, and I think the reliability of Wordpress options (either through Wordpress.com or a reputable Internet service provider that can support your own installation of Wordpress) is at least as high as most institutional CMSs—perhaps higher. However, I can understand why a college instructor considering a move away from a less-than-satisfying institutional CMS might not be willing to move to their own blog as a solution. After all, if there is a problem with the institution’s CMS, then it is the institution’s responsibility; if there is a problem with an instructor’s Wordpress installation, then it is the instructor’s responsibility. So while I think that the potential problems are far outweighed by the benefits of using Wordpress, I can understand why others might see this differently. If the answer to the responsibility question is closer to “maybe,” it seems to me that there are many ways to seek middle ground by migrating some but not all CMS functions to a Wordpress site. For example, someone experimenting with Wordpress.com

BLOGS

/

203

might begin initially by having some course materials—perhaps the syllabus, schedule, major assignments, some class discussions, and so forth—available on a Wordpress site while still retaining and using the institutional CMS for other functions—presenting copyright-protected materials, collecting and passing back student work, posting grades, and so forth. In other words, it is not an “either/or” choice, and I think that using a combination of official and unofficial solutions can resolve most instructor’s potential responsibility concerns. WHAT IS RIGHT ABOUT WORDPRESS? Let me return to the benefits of Wordpress I introduced earlier with David Parry’s (2010) bulleted list and offer a more detailed discussion as to how I see Wordpress solving the two global CMS problems that I discussed in the “What is Wrong About CMSs?” section. I’ll begin by explaining this screen image (Figure 3) from the course blog for a graduate course I taught in Winter 2010, “Computers and Writing, Theory and Practice.” This is a Wordpress installation that is at http://engl516.stevendkrause.com. For the layout, I’ve chosen a free “theme” called Carrington. With this theme, I could have

Figure 3. Screen capture from “Computers and Writing, Theory and Practice.”

204

/

DESIGNING WEB-BASED APPLICATIONS

chosen pretty much any color combination for the various elements of the page. At the top of the window, “Links to static course documents” link to pages I have set up within the blog that are not chronological and link to documents important to students throughout the term. Within Wordpress, “pages” differ from “posts” in that pages are static and are not posted by date. The classic example (as explained on Wordpress.com’s support forum) is an “About” page on a blog, but I use these static pages to post important course documents that are separate from the ongoing discussion and are unlikely to change much. In my example here, I have a schedule, the class final, the syllabus, and two of the major assignments for the course: the book review and the research project. Pages also allows for “Page/Subpage” relations, that is, I can create a page about an element having to do with one of the major pages and have it appear beneath one of these main pages. Below that, the class conversation takes place within posts in the part labeled “Typical Posts and Discussions,” which is the chronologically updated portion of the blog. I begin the conversation for a reading or writing assignment by creating a post, and students discuss by posting comments. For example, “Discussing Maranto’s and Barton’s ‘Paradox and Promise’” and “A series of readings/texts in the ‘popular press’ about Facebook and Twitter” are both examples of the posts that I initiated for discussions. I have adjusted the settings on this blog so comments are “threaded,” that is, commentators can respond to particular comments and not just the post as a whole. The discussion continues with comments from students, myself, and from an occasional visitor, as I discuss in the next section of this chapter. On the right side of the window, I have links to other important items for the course that are hosted elsewhere, that is, each student kept their own Wordpress.com blog for the class (listed under “Class Blogs”), the “Course eReserves” for distributing some copyrighted material was under the “Class Links” subhead, and so on. In this example, I have made only a few basic tweaks to the look of the Carrington Theme, and I have only installed two plugins, one that displays links I post to my delicious.com account on the site, and one that allows users to edit their comments for a limited amount of time. But again, with the thousands of different plugins and extensions available via Wordpress.org, the flexibility and potential of the server-supported and open-source version of the software is extensive. From a design perspective, I think what is “right” with Wordpress is exactly the opposite of what I described as being “wrong” with institutional CMSs. Wordpress is obviously more flexible than even the most robust CMSs in terms of colors, fonts, and layout. If the CMS is analogous to an ahistorical classroom of neatly arranged rows of desks bolted to the floor, the Wordpress kludge is a classroom where teachers choose the color of the walls, the presence (or absence) of windows, the furniture (chairs, couches, bean-bag chairs, whatever), and the arrangement of it all. Not everyone agrees that this is a good thing; in fact, one of the arguments routinely made in support of institutional CMSs is that students find the consistency of the interface across different courses useful, that is, Blackboard looks the same for a student’s English class as it does for that same student’s History class. But given that students routinely face inconsistencies in teaching in face-to-face classrooms—different grading scales, different modes of delivery, different instructor expectations, and so on—it

BLOGS

/

205

seems to me the significance of the same CMS is minimal. And while I can only speak from my own teaching, the majority of my students who have had other online classes tend to prefer the Wordpress interface and interaction. They describe it as “easy,” “flexible,” and more user-friendly than the EMU CMS. Also, I’d argue that a course supported with a Wordpress blog actually seems more “familiar and consistent” to most students since Wordpress and similar blog interfaces are much more common on the Internet than any institutional CMS. But besides the design flexibility and features, I think the openness and public presence of the Wordpress-hosted site is more like the face-to-face classroom, and it makes more sense in teaching the writing process. Again, I am assuming here the mantra of writing being a social process and one that takes place in an exchange that goes beyond a dialog between student and teacher and that reaches to an audience beyond the classroom. In my teaching, I think the Wordpress blog facilitates a more open (albeit more messy) exchange between students through posts and comments to the class blog and also to individual students’ blogs. Instead of being analogous to Internet commerce, these public blog discussions between students about reading and writing assignments are more similar to all sorts of writing that students read and write online—social networks, blogs, and so forth. Of course, a Wordpress course blog is similar to other Internet Web sites because it is on the Internet and not behind a firewall. The “publicness” of class blogs was a phenomenon I was familiar with before I used Wordpress as a CMS. Will Richardson (2006) relates an anecdote in Blogs, Wikis, Podcasts, and Other Powerful Web Tools for Classrooms about his high school students using blog spaces to collaborate with others beyond the classroom: “Pulitzer Prize-winning journalists, elementary school kids in Georgia, high school students in Poland, theater troupes in Oklahoma, and the list goes on” (p. 25). A few of my students had had similar experiences when they received comments from beyond the class in response to one of the assigned prompts they posted to their own blogs. But it wasn’t until Fall 2009 that I experienced firsthand the ways in which my online class taught on a Wordpress blog made connections beyond the class. That fall, I taught a graduate course called “Rhetoric of Science and Technology,” and the course included a discussion in the class of Lloyd Bitzer’s essay (1968) “The Rhetorical Situation” and Richard Vatz’s rebuttal to Bitzer, “The Myth of the Rhetorical Situation” (1973). Much to my surprise, I received an e-mail from Vatz in which he commented favorably on the class discussion and where he recommended a more recent essay for the class to read and discuss. My students and I were simultaneously pleased and surprised that one of the authors whose work we were reading—and a seminally important piece of work at that—looked in on our online class conversation. That unexpected authorial encounter inspired me to more specifically invite authors into the Winter 2010 section of “Computers and Writing, Theory and Practice.” I assigned several essays from the then in-press book RAW (Reading and Writing) New Media, edited by Cheryl E. Ball and James Kalmbach (see Hawkins, 2010), and I contacted many of the authors of these essays to let them know we would be discussing their work in my online class. In a few instances, the interactions between authors and students were fascinating.

206

/

DESIGNING WEB-BASED APPLICATIONS

Before I go further, I want to offer a brief apology regarding my reliance here on anecdotal and intentionally nonspecific references. I don’t refer to specific students or their posts because my discussion is based on past and nonexperimental teaching experiences, results that have not passed through any sort of Institutional Review Board process. Of course, most of what I discuss here is available via the Wordpress blogs that I link to from stevendkrause.com, and I did ask for (and receive) permission to quote from the authors I discuss below. Nonetheless, in part because of some of the reservations I have come to have about making the online class completely public, I feel it’s best to err on the side of caution. Early in the term and before I think my students had fully adjusted to the idea that the class was public, we discussed Ames Hawkins’ (2010) “Manifesting New Media Writerly Processes.” This is an essay from RAW which is, as a manifesto should be, provocative and challenging, especially in terms of rethinking the ways in which new media ought to be taught and the presumptions we make about the binaries between “new” and “old” media. As the discussion online got rolling, one of the students posted a comment that was a bit flip and dismissive of Hawkins’ arguments. Several students commented on this student’s comment, and then the site was visited by Hawkins herself, who (gently) took the student to task, concluding her comment with “Betcha didn’t actually think you’d get a response, eh? Isn’t this the point of the digital world?” When students realized that Hawkins was “present,” the online conversation simultaneously took on a tremendous energy (the discussion was one of the most active of the semester in terms of number of posts and details of response), and it became more careful and respectful. Seeing a “teachable moment,” I wrote, I don’t think that Ames or any of the other writers we’re going to read this term will mind constructive criticism. If you disagree with her, go ahead. But here’s the thing: you’ve got to have respect for the texts and the authors, and you have to engage thoughtfully. Sure, you should do that because authors like Hawkins might be reading; but I’d say the same thing about entering into a dialog with Plato or [Walter] Ong or whoever.

I then went on to remind students of some of the strategies I had raised earlier for entering into a dialog with complex texts—to first read for understanding, then to ask questions and make notes, and then to form an opinion and respond. Once the reality that we were not alone in our online class sank in, I think our conversations and interactions with the readings progressed exceptionally well. The illusion of privacy had been broken, and we all knew that it was at least a possibility that others, including the scholars whose work we were discussing, might be looking in. For the most part, this was a good thing. For example, I think the Hawkins discussion set the tone for the discussion of another essay from the RAW collection, Michael Salvo’s (2010) “Cinders, Ash, and Commitment: Database Pathos in Six (Million) Parts.” Like Hawkins, Salvo’s essay is a departure from genre of “computers and writing” essays in that Salvo takes a decidedly personal and autobiographical approach to illustrating the emotional power of the databases available from the United States

BLOGS

/

207

Holocaust Memorial Museum. It’s a challenging reading on several levels (albeit a satisfying and powerful one), and, while I have no way of proving this, I am convinced that the level of care and respect my students took with the piece was the result of our earlier discussions and the realization of the publicness of the class. Happily, these interchanges seem to have been of value to the authors as well. I received e-mails during the course of the term from several writers who looked in on the class discussion even though they declined to participate in it. In an e-mail exchange about this chapter, Hawkins wrote, When I was challenged from behind the scenes, with comments that felt to me like the way people talk about you behind your back, I felt violated in some way. I had to reflect on what I sound like when I talk about pieces of writing in class—or what I used to sound like as a grad student. I admitted to myself that I have slammed some authors before precisely because they weren’t there. So, I took a moment and decided to actually try and respond to the issues that were brought up. . . . The educational potential here is absolutely amazing. Imagine if you and I would have had the opportunity to actually chat with the authors of the pieces we had read—to hear what they think. I wouldn’t want students to be told ahead of time who may be online, but only to be reminded that authors might be online. The exchanges felt authentic to me and, most importantly, playful. (personal communication, July 2010)

I would further argue that this “authenticity” and “playfulness” also inevitably disrupts the online student’s perception of learning alone, that is, instead of being the “learning alone” environment where the online class is analogous to online banking or online shopping, our class, an online environment where scholarly authors and graduate students interact with each other in a real space, was more akin to a social network like Facebook or Twitter, an Internet environment predicated on interaction, sociability, and publicness. CONCLUDING WITH A CAVEAT FOR SOME PRIVACY Of course, as is also the case with social networks like Facebook and Twitter, interaction, sociability, and publicness have potential costs. Besides the loss of privacy, the “firewall-less” classroom potentially has the effect of making an online class hosted with Wordpress as a CMS a little too “deferential” and “polite” because of potential outside-of-the-class onlookers, and thus—perhaps ironically—a little less honest than the more private online course. In our e-mail exchange about this chapter, Michael Salvo’s response about his exchange with my Winter 2010 students hinted at this: Through your class site, I had immediate and useful audience response, and perhaps due to its content, had some very strong responses. Yet few students really engaged me with its content: they were either congratulatory or quiet, although I don’t know what other backchannel discussion was happening. (personal communication, July 2010)

208

/

DESIGNING WEB-BASED APPLICATIONS

In other words, I think its fair to say that while Salvo was happy with the interaction and response from my students, he was not entirely sure it was as honest or forthcoming as it could have been. Most writing teachers have seen similar phenomenon with interactions among students, notably in editing and writing workshop work: more often than not, students are overly polite, sparing feelings in the name of civil human interaction and at the expense of honest and actually useful advice on writing projects. Or, to extend my social network metaphor: most social network users exercise a certain level of self-censorship because of potential less-than-ideal readers or worse yet, because of direct experience with such readers in the form of students, relatives, or employers. Indeed, I think a lot of the angst over privacy that arises cyclically with sites like Facebook has as much to do with its users having second thoughts about what they have shared and their willingness to “friend” relative strangers as it does with Facebook’s actual (and admittedly problematic) disregard for the rules governing its users privacy settings. These concerns are not a reason to not use Wordpress as an alternative to institutional CMSs for teaching online, and there are some easy technical and pedagogical solutions to privacy problems. Wordpress has numerous settings that restrict access to the site to registered users, which would essentially put portions of the class back behind a firewall. But I think the most effective solution is to simply remind students repeatedly about the public nature of the Wordpress-hosted course. Besides being a more simple solution that maintains the openness of the software, I think the fact remains that the nonfirewalled online class facilitates a real opportunity for students to write for an audience beyond the teacher and beyond classmates. For writing students, particularly for those who have aspirations of being professional writers, the advantages of those lessons far outweigh any of the downfalls. Using a blogging software like Wordpress, either through the commercial service or through a homegrown and open-source software installation, might strike some— particularly university information technology professionals—as a pretty sloppy solution to the problems of institutional CMSs. But given what users can’t do easily with institutional CMSs and what they can do with solutions like Wordpress, it seems inevitable to me that the tools we will use in the near future to teach online will look a lot less like the officially sanctioned software and a lot more like the blogging software kludge. REFERENCES Bitzer, L. (1968). The rhetorical situation. Philosophy and Rhetoric, 1(2), 1–14. DePew, K. E., & Lettner-Rust, H. (2009, September). Mediating power: Distance learning interfaces, classroom epistemology, and the gaze. Computers and Composition, 26(3), 174–189. Hawkins, A. (2010). Manifesting new media: Writerly processes one really bad flash piece at a time. In C. Ball & J. Kalmbach (Eds.), RAW (Reading and Writing) New Media (pp. 19–32). Cresskill, NJ: Hampton Press. Lane, L. M. (2009, October 5). Insidious pedagogy: How course management systems impact teaching. First Monday, 14(10).

BLOGS

/

209

Parry, D. (2010, March 18). Wordpress a better LMS. ProfHacker/The Chronicle of Higher Education. Retrieved June 7, 2010, from http://chronicle.com/blogs/profhacker/tag/ wordpress/page/3 Richardson, W. (2006). Blogs, wikis, podcasts, and other powerful Web tools for classrooms. Thousand Oaks, CA: Corwin Press. Salvo, M. (2010). Cinders, ash, and commitment: Database pathos in six (million) parts. In C. Ball & J. Kalmbach (Eds.), RAW (Reading and Writing) New Media (pp. 67–81). Cresskill, NJ: Hampton Press. Vatz, R. (1973). The myth of the rhetorical situation. Philosophy and Rhetoric, 6(3), 154–161. Weigel, V. (2005, May/June). From course management to curricular capabilities: A capabilities approach for the next generation. Educause, 40(3), 54–67.

http://dx.doi.org/10.2190/DWBC13

CHAPTER 13

Developing a Course Wiki for Accessibility and Sustainability Karl Stolley

In this chapter, I describe my customization of WikkaWiki, an open-source wiki engine that I have adopted for powering my course Web sites. I will focus my discussion on customizations at the structural/XHTML level that address accessibility and sustainability: two concerns that have guided and emerged from my work in course Web site development. I use the word “accessibility” for convenience and simplicity; what I am after in my design work might be more accurately labeled “universal design”: “The design of products and environments to be usable by all people, to the greatest extent possible, without the need for adaptation or specialized design” [http://www.ncsu.edu/www/ ncsu/design/sod5/cud/about_ud/udprinciplestext.htm] (Connell et al., 1997). The way I use the term “accessibility” includes but exceeds simply ensuring that basic features of Web sites, such as images, have a textual equivalent for people with low vision. Accessibility also includes browser- and device-neutral page design and even the performance of the pages that make up a site, including the speed of dynamic page construction in database-driven systems such as wikis and the responsiveness of any JavaScript-based page features. However, all of the fancy stuff—page design in CSS, interactivity with JavaScript—depends on a solid structural foundation in XHTML. Sustainability is a matter that I address largely as a condition of accessibility (after all, what’s the point in sustaining an inaccessible design?). Modifying somewhat the definition of sustainability arrived at by the World Commission on Environment and Development [http://www.un-documents.net/ocf-02.htm] (1981), sustainability represents an attempt to meet present needs of a custom design without precluding or sacrificing future needs. More simply, sustainability is about avoiding customizing a piece of software into a corner. Particularly for open-source projects that are in active development, it’s better not to need to start over from scratch when performing customizations for subsequent releases. And when a change does come from the main open-source project (as I describe with WikkaWiki’s menu system below), it’s important to be agile in responding to change in ongoing customization work. (And work such 211

212

/

DESIGNING WEB-BASED APPLICATIONS

as that detailed by authors throughout this book is always ongoing.) As I describe below, structure is the place that sustainability takes root. I change visual designs on my course wikis from semester to semester, but the underlying structure is comparatively stable from design to design. To contextualize the customizations I have made to WikkaWiki, I want to cover how my approach to creating custom course Web sites developed prior to running WikkaWiki. And because one of the primary roadblocks to both accessibility and sustainability in this kind of writing more generally is a development environment, I take the time to describe how I set up mine and suggest how others may set up their own. A NOTE ABOUT SOFTWARE DETAILS IN THIS CHAPTER When possible, I will abstract my WikkaWiki customizations to general development principles that can be applied to WordPress, Drupal, and other open-source, database-driven Web site platforms. But despite the general principles here, I believe that it is essential to talk about software-specific details. As anyone who’s done this kind of custom development work knows, the details often matter far more than vague generalizations. A vague generalization might help properly orient thinking about this kind of work, but it has been my experience that overlooking even seemingly insignificant details can derail entire customization projects. To put it another way: I’m not hopeful that this chapter will make everyone want to rush out and use WikkaWiki and apply the detailed information directly (which will change anyway, though see the next paragraph). My intention is only to reveal, through details, the levels of depth and complexity that this kind of custom development work entails under the general umbrella of issues such as accessibility and sustainability. As a means of reinforcing my arguments in this chapter (and of enabling others to run course wikis using my customizations), I have made available for download the work detailed here. The latest as well as past versions can be found at a GitHub repository at http://github.com/karlstolley/course-wiki. Part of writing this chapter involved me meeting a long-standing goal of publishing and releasing this custom WikkaWiki work as free and open source under the GNU General Public License [GPL; http://www.gnu.org/licenses/gpl.html] (Free Software Foundation, 2007). Because I have released this work under the GPL (in keeping with WikkaWiki’s own GPL licensing), it is free for anyone to download, modify, use, and/or redistribute. (Note that the repository only includes the customized elements; it will still be necessary to download WikkaWiki itself from http://wikkawiki.org/downloads/) I routinely update my WikkaWiki customizations in preparation for each new semester, so the odds are great that some details presented in this chapter will change. Anticipating that, I have provided in the repository additional documentation for understanding and using or further modifying my customizations, as well as notes regarding updates or changes; see the README.md file, which is rendered toward the bottom of the repository’s home page.

DEVELOPING A COURSE WIKI

/

213

MY BACKGROUND WITH CUSTOM COURSE WEB SITES To properly frame how I go about the work of customizing WikkaWiki, I need to offer a brief account of how I have created course Web sites throughout my teaching career, marking some of the major milestones, Web standards in particular, that foregrounded accessibility and sustainability in my design approach. One place to begin this account is to answer the question that all of the contributions to this book are attempting to answer: why would someone want to pursue custom Web design and development for delivering course Web sites? Given that it is a rare thing to find a university that doesn’t offer some kind of Web-based course-content system, such as Blackboard, why build your own? My answer to the question involves how a custom site establishes my ethos as an instructor. Course Web sites are not just a replacement for the copy machine, despite the model that Blackboard and similar systems often impose. By that I mean, the impetus for developing a custom course Web site should not simply involve building another system to distribute course material. Rather, a custom site should be both a reflection and extension of course pedagogy. Web writing and design have been a part of all of the courses that I have taught, even including first-year writing, and in some cases are the topics of the course, as in my graduate-level course Standards-Based Web Design. To teach courses even with only a single assignment or unit in Web writing and design while relying on infrastructure provided by Blackboard is an untenable contradiction. But even beyond that simple contradiction, as an instructor I prefer to leave as little to chance as possible: I want to know as much as I can about all of the infrastructure that supports my classes. Not only do I want to know about it, I want to be able to fix it immediately. If students have a problem with a course technology that I require them to use, I want to provide more of a response than a dumb look or the promise of making a personal call to the campus IT group (which are pretty much the two best options in the face of the “mystery-meat” systems that the likes of Blackboard represent). For that reason, I go so far as to host all of my course Web sites on my own enterprise-grade server space, where I also host my personal Web sites and other things driving my research. More than once I’ve overheard colleagues complaining that the campus system was down, while mine ticked merrily away. (After I wrote that sentence, I ran the uptime command on my server; it has been running continuously for the last 425 days, 4 hours, and 31 minutes.) One final reason for creating custom Web sites: openness and, by extension, accessibility. Although it has only been in the last few years that I’ve been able to articulate my stance on openness, having delved into the theory and practice behind open source and read widely about projects such as Creative Commons made me realize that I do not want my courses cloistered away for only my students and, on certain occasions of professional review, my senior colleagues to see. But offering Creative Commons licensing and an open Web site is really just an empty gesture, unless careful attention is paid to the open formats and open standards that make up an open, standards-based Web site. But openness in all of those forms came later in the game for me. For the first several years of my teaching career, I built sites using FrontPage (yes, it’s true) and later,

214

/

DESIGNING WEB-BASED APPLICATIONS

Dreamweaver. Those sites were the epitome of poor software-controlled Web design practices of the day; they freely intermingled HTML display attributes and CSS, and relied on table tags for all page layout. But, of course, they were pretty easy to make: I didn’t really have to learn anything new. The skills that I’d developed using Word and different page design programs were sufficient enough to make what, under specific conditions, were acceptable Web pages. A representative example of that particular development approach is the site for an introductory writing course (see Figure 1) that I taught in Fall of 2003 which is the oldest course site that I have posted to the open Web. It’s not a bad-looking site, all things considered (although the type is way too small, at least as it appears now on a Mac). But it is representative of my exclusive use then of Internet Explorer and corresponding ignorance of how sites function in other browsers, including nongraphical environments. Where that design reveals its limitations is in Lynx, a text-only Web browser that’s an essential tool that I use now to help determine a site’s accessibility (see Figure 2). That the top of the page is littered with references to images and includes no sort of branding (what site is this?) are both major accessibility problems. Imagine this page being read aloud to a low-vision user (or even indexed by Google): the cues are all there, visually, on image-capable devices. But the page contains no textual

Figure 1. Non-standard course Web site built in Dreamweaver.

DEVELOPING A COURSE WIKI

/

215

Figure 2. Nonstandard course Web site as viewed in Lynx.

equivalent. Not only is that a concern for basic accessibility; it’s a sustainability problem too. Were I to wish to revise this page’s design, I would have to go back to an image editor to make new images or get rid of the images and put in the text that should have been there in the first place. The design worked for what it had to be that semester; having met that present need, I ignored any future needs, simply because I didn’t know any better. Dependence on software does that. Web Standards Web standards changed how I thought about Web design and also how I practiced it. As part of my work redesigning the Purdue Online Writing Lab beginning in 2004, I started to dabble with PHP, a recursive acronym for PHP Hypertext Preprocessor. PHP is a popular open-source scripting language that runs on a Web server (versus a scripting language like JavaScript that typically runs in a Web browser). Attempting to learn PHP threw what, in hindsight, was an important wrench into my carefree/careless use of Dreamweaver: PHP could not be composed in a WYSIWYG, which meant that any pages produced using PHP would have to be handwritten (the same is true for dynamic systems such as WikkaWiki). But I had no idea how to write Web pages by hand. Reading through some of the PHP documentation at PHP.net, I kept encountering little announcements that certain PHP functions were “XHTML compliant.” I knew

216

/

DESIGNING WEB-BASED APPLICATIONS

what HTML was, but XHTML and the meaning of “compliant” were both mysterious. A quick search on Google for “XHTML” returned an article in A List Apart by Jeffrey Zeldman (2002) titled “Better Living through XHTML,” which explained that “XHTML is the standard markup language for Web documents and the successor to HTML 4. A mixture of classic (HTML) and cutting–edge (XML), this hybrid language looks and works much like HTML but is based on XML, the Web’s ‘super’ markup language.” A little Googling on Zeldman’s name turned up the Amazon page for his now-classic book, Designing with Web Standards (2003), which as of 2009 is in its third edition. The idea behind Web standards is pretty simple, even if the details are more complex: there are official versions of the Web’s languages and protocols, most of which are developed and maintained by the World Wide Web Consortium (W3C). Those official versions are the standard by which pages ought to be composed, rather than to the previous ad hoc “standards” of individual browsers or to the view of a page as rendered in a WYSIWYG editor. As official versions, they are intended to withstand technological changes brought about by individual browser makers; even as new-fangled markup languages such as HTML5 are developed, standard versions of older languages (XHTML, HTML 4.01) continue to be accessible and therefore sustainable. Although many of my favorite examples have been edited out of subsequent editions of Designing with Web Standards (2003), the first edition showed the markup of a range of different popular Web sites, in all its hideous glory. A pretty-looking site in the browser could be a complete disaster right below the surface, at the source code level, which is where I knew I would have to write to use PHP effectively. Zeldman showed how such “tag soup” could be cleaned up by adhering to Web standards, particularly XHTML and Cascading Style Sheets (CSS). Better still, pages written by hand might actually be written in a way that makes the XHTML and CSS source intelligible to the writer and to others. And although Zeldman was careful not to explicitly damn WYSIWYG editors (or those who use them), parts of Designing with Web Standards made it clear that the Web had become the inaccessible, unsustainable mess it was (and still is) in part because of bad authoring tools. As a user of those tools, I was contributing to the mess. As a teacher of those tools in my classes, I was teaching others to contribute to the mess too. Starting with the Web site (Figure 3) to support an immersion course I had taught in Technical Writing in May 2005 (which actually used the W3C recommendations documents as a major part of the course’s content in technical writing), I began to write all of my course Web sites’ XHTML and CSS by hand—a practice that I still engage in and now also teach. The expressive freedom that attended writing pages in XHTML and CSS by hand made it possible for me to leverage PHP and MySQL to introduce a dynamic “Course News” page that I could update via a Web browser (rather than having to FTP content, as the static pages required). Despite that dynamic element, the core content pages of the course Web sites—the syllabus and calendar, project descriptions, and so on— remained static XHTML because they changed so little, and because I knew that the loading speed and performance of simple, static XHTML pages would always be

DEVELOPING A COURSE WIKI

/

217

Figure 3. A standards-compliant course Web site; structure in XHTML, design in CSS.

superior to a PHP/MySQL hybrid, which requires serverside processing instead of simply handing over a file, as with static XHTML. Through the end of graduate school, I continued to develop standards-compliant course Web sites on the same static/dynamic hybrid model. Web standards made their way into my teaching, particularly in a class on Multimedia Writing that I taught while a graduate student and in my first classes on Web design that I taught as faculty at my current institution. Web standards brought a missing rigor to what I was teaching when it came to the Web: instead of just turning students loose to go make pretty things with Dreamweaver, students learning the standards could talk critically and intelligently about design and page construction according to Web standards. Students could also write their pages directly and learn to value, as I do in my own work, external, nonvisual tools for assessing designs: the W3C’s XHTML and CSS validators [http://validator.w3.org, http://jigsaw.w3.org/css-validator/] (World Wide Web Consortium, 2009, 2010), which check the markup and CSS of a page or Web site against the standards themselves. I spent no small amount of time on those sites; learning standards-based design approaches is not exactly an afternoon-long project. However, what’s important to note is that, as a graduate student, both my work on the Purdue OWL and the work in

218

/

DESIGNING WEB-BASED APPLICATIONS

my dissertation became focused on open standards and formats, a trajectory that my research has continued to follow now that I am faculty. Building sites the standards-based way isn’t simply an extra task tacked onto all the other responsibilities I have; it’s an expression and extension of the research, teaching, and service that I do. Although I don’t discount the fact that I am fortunate to have been able to pursue a research agenda that lends itself to my teaching, it is important to note that the expertise that I’ve developed in these areas is the product of more than simply putting together Web sites as part of course preparation. Enter the Wiki In spring 2008, my second semester as faculty, I had the opportunity to teach a course in Knowledge Management (KM). A number of the books that I selected for that class discussed wikis, so it was pretty obvious that the readings would be better reinforced if students had access to an actual wiki. Because Tapscott and Williams’ Wikinomics discussed Wikipedia and its MediaWiki software specifically, I decided to set up a MediaWiki installation that students could use to complete one of the course projects. It was an out-of-the-box (OOTB) installation; all I changed was the logo, which was a simple matter of swapping out the default image file that ships with MediaWiki. Although MediaWiki did not supplant my usual static/dynamic course Web site, which only provided a link to the wiki, the enthusiasm with which those graduate students took to MediaWiki that semester came as a surprise to me. Not only were students using it to complete the course project as assigned, but many were keeping their reading notes and other course-related materials there, without any prompting for me (thick-headed as I can be, such uses never entered my mind). Toward the end of that semester, we had a small class discussion about whether students in classes other than KM would find a wiki useful and whether it would be better to create one mammoth, ongoing wiki that would be used across multiple classes or if it would be better to start fresh and have a dedicated (and essentially empty) wiki for each class. Most students expressed their preference for the latter. I recall some students saying that, were they to have come to the wiki already containing tons of content, it would have been that much more overwhelming to learn and use. But either way, they thought the wiki was a good idea. I thought it was a good idea to include a wiki in future classes too, but I was still operating under the assumption that I would do my usual static/dynamic hybrid course sites and just link to a wiki as an additional, separate part of the Web infrastructure for each class. My primary reason for thinking that way was that I wanted to continue to create lightweight, standards-compliant pages that would be stable and always available. The idea of moving to a completely dynamic database-driven system, based on an open-source project, seemed overly ambitious. More philosophically, given the nonstandard markup that I had observed some wikis generate, using a wiki seemed like a step backwards from providing accessible, standards-compliant course Web sites.

DEVELOPING A COURSE WIKI

/

219

The Switch to WikkaWiki Then again, it was clearly unsustainable (not to mention silly) to start maintaining two-part course Web sites: a static/dynamic hybrid in addition to a separate wiki. And even though MediaWiki had been popular with the KM students, I knew it to be a mammoth piece of software “designed to be run on a large server farm for a Web site that gets millions of hits per day” [http://www.mediawiki.org/wiki/How_does_ MediaWiki_work%3F] (MediaWiki, 2011). MediaWiki’s core purpose of driving Wikipedia meant that it had a far more complex feature set than what I felt—and still feel—is necessary for a course wiki. MediaWiki is too big and, given the multiple other projects I have running on the server I use to host course Web sites, too resource intensive. So I spent part of the summer that followed the Knowledge Management course evaluating different open-source wiki engines to power my course Web sites. I had three basic criteria: • it had to be lightweight (no mention of server farms, no mile-long pages of features) • it had to be customizable, ideally in a very simple way (no Drupal-like mazes of template files) • it had to be standards compliant or, through customization, achieve standards compliance Ultimately, I decided to experiment with WikkaWiki, which its creators describe as “a flexible, standards-compliant and lightweight wiki engine written in PHP, which uses MySQL to store pages” that has been “designed for speed, extensibility, and security” [http://wikkawiki.org/HomePage] (WikkaWiki, 2011). Besides striving for standards compliance, WikkaWiki seemed to require a relatively minimal investment of my time to do some basic customizations to prepare WikkaWiki for classroom use. But I knew from past work on dynamic sites that I needed to set up a development environment that supported customization work before deploying this new wiki to my live Web server. SETTING UP A TESTING AND DEVELOPMENT ENVIRONMENT The first thing to know about testing, developing, and customizing a database-driven system that also relies on a Web server is that the usual rules of Web design don’t apply: meaning, you can’t just open the files on your desktop and view them, as files, in the Web browser. Unless you are going to test and develop directly on a live Web server (which is universally a bad idea), it’s important to set up an environment specifically for testing, development, and design. My own preference is to distribute development over a couple of different computers. This is a luxury, I realize, but it is one of the better ways to keep accessibility and sustainability in mind: if a project can only be worked on from one computer or even one operating system (Mac, Windows, or Linux), one must question just how sustainable the project is. Regardless of the computer, three kinds of tools are essential to this kind of work: an editor, a good

220

/

DESIGNING WEB-BASED APPLICATIONS

development browser, and a local Web server. And I’ve recently discovered the importance of running a fourth kind of tool: a version control system. Editors Open source requires nothing more than a simple text editor to make custom edits. While it’s possible to use Dreamweaver in its Source View, plenty of simpler, lightweight (not to mention free) text editors are available. The most important feature of any editor is its ability to highlight syntax; that is, to color different parts of a given language (such as PHP, XHTML or CSS) based on the part’s function. Linux distributions, such as Ubuntu (http://www.ubuntu.com/), have a wide variety of editors available. My own preference to use the command-line editor vim (http://www.vim.org/) or the gedit editor (http://projects.gnome.org/gedit/) that ships with Ubuntu for the GNOME desktop (http://www.gnome.org/). For Mac, its hard to beat TextWrangler (http://www.barebones.com/products/textwrangler/), the free version of the more feature-rich BBEdit (http://www.barebones.com/products/bbedit/). And on Windows, Notepad++ (http://notepad-plus-plus.org/) is a solid editor, not to be confused with the Notepad program that Windows ships with, which should be avoided because of its lack of syntax highlighting and its mishandling of advanced character sets. Web Browsers Whether on Mac, Windows, or Linux, Firefox is the Web browser best suited for development. Although ultimately it’s important to test a site in as many browsers as possible, for development, Firefox is a fine choice, particularly because of extensions such as Chris Pederick’s Web Developer Add-on (https://addons.mozilla.org/firefox/ addon/60) or Firebug (http://getfirebug.com/), which make it possible to do things such as edit CSS within the browser (and therefore return some of the instant gratification of seeing visual changes that WYSIWYGs afford). The Web Developer Add-on also allows a page to be rendered under a variety of different conditions, such as with JavaScript or CSS turned off. Those features make the Web Developer Add-on a great tool for testing for accessibility too. A Local Web Server: The Lamp Stack Running a local Web server makes it possible to view Web work in progress at a special URL, http://localhost/. Depending on the configuration of the network that your computer is connected to (such as a firewalled home network), other machines can also view the pages by IP address. For example, I can look at the Web pages served from my Linux box using my Mac by hitting http://192.168.1.3/, provided the computer is connected to my home network. (In other words, don’t try hitting that IP address unless you’re at my house.) I prefer to run my development server on Linux. Ubuntu is an excellent choice for first-time Linux users, as it is based on the Debian distribution of Linux and therefore both stable and well-documented. Linux also makes it very easy to install the remaining parts of the LAMP stack (LAMP standing for Linux, the Apache2 Web

DEVELOPING A COURSE WIKI

/

221

server, the MySQL database, and PHP) required by WikkaWiki, WordPress, Drupal, and many other open-source database-driven Web site platforms. To develop directly on the Mac or, on rare occasions, Windows (rather than through my Linux box), I run XAMPP [http://www.apachefriends.org/en/xampp.html] (Apache Friends, 2011), which is a self-contained Apache distribution that provides a very easy way to run a development-friendly Web server on Mac and Windows. Given its simplicity, I often instruct my students to run XAMPP for their own development work. Like a true LAMP installation, XAMPP also utilizes the http://localhost/ URL and is accessible via the XAMPP computer’s IP address, given the right networking conditions. Version Control Systems A recent addition to my development environment has been Git, which is a distributed version control system available on Linux, Mac, and Windows. Git enables writers to maintain a history of the changes to a project, such as my WikkaWiki customization, and to share the history of changes along with the files themselves across multiple computers (or with multiple people). Git is what makes it possible for me to easily share changes to my GitHub account, where someone can actually browse the history of my changes. Git, in coordination with GitHub, also helps me share changes with myself when I’m developing on multiple computers. But more importantly, Git lowers the stakes in customization work. If I screw up—rather, when I screw up—I can run a few commands in Git to return to earlier versions of my work, even when my mistakes are spread across multiple files (which is typical for the kind of customization work WikkaWiki and other software demands). CUSTOMIZING WikkaWiki The WikkaWiki templating system uses what I think of as a sandwich model: a header and a footer, between which is sandwiched the output from the wiki engine itself. WikkaWiki also provides a system for creating dynamic menus based on the page being viewed and the class of user (an admin, a registered user, and everyone else). Because the menus are written in the same wiki markup as a regular page in the wiki, they enable the inclusion of a special bit of markup for including custom actions, such as displaying links to view the history of a page or revert it to an earlier version. In the sections that follow, I will cover the structural customizations to each of those components—header, footer, menus, and actions—as they relate to accessibility and sustainability of the wiki pages they generate. Customizing header.php The header begins with a bunch of initialization instructions for WikkaWiki. For anyone wishing to use this template OOTB, only lines 6 and 7 of header.php need to be edited to match the name of the course and a brief, one-sentence description. The remaining lines of the header file, while also editable, should work based on the content and settings established upon installing WikkaWiki. There are some custom

222

/

DESIGNING WEB-BASED APPLICATIONS

variables that use information passed from the WikkaWiki API, for the page tag (or slug) and the title of the page, as determined by the first heading on a given page in the wiki. (In the absence of a heading in the wiki page, the slug will be used instead.) Other variables are assigned for system messages, the current user, and the base URL of the WikkaWiki installation. The idea behind setting all of those variables is to keep the template from firing requests to different API objects each time a bit of information—the slug, the page title—is needed to construct the page, thereby speeding up page construction: a slow Web site just feels inaccessible, whether it is or not. So for example, the $cw_name and $cw_title variables set on these lines: /* Custom variables. Edit these two lines to match the name and brief description of your course. Leave the quotation marks. */ /*Course name:*/ $*cw_name = "Course Name Here"; /*Brief description:*/ $cw_tagline = "A one-sentence description of the course."; /*Custom variables that rely on the WikkaWiki API:*/ $cw_tag = $this->GetPageTag(); $cw_title = $this->PageTitle();

make their first appearance in the actual output of the page, in the tag, which most browsers render on tabs or at the very top of the browser window: . In addition to establishing some custom variables, I define a series of constants that WikkaWiki can use for menu construction. OOTB, WikkaWiki puts square brackets around the link text for functions such as editing a page, viewing the page’s editing history, and so on. Using punctuation marks in that way, as a design element, can be both a stumbling block to accessibility (screen readers may literally read out “square bracket edit square bracket”) and a pain in the neck to design CSS around. So, rather than have link text appear as [Edit] or [History], I define the constants up front to be text only: Edit and History: define('EDITLINK_TEXT', 'Edit'); define('HISTORYLINK_TEXT', 'History'). The constants (EDITLINK_TEXT, HISTORYLINK_TEXT) are built into WikkaWiki, and the define(): syntax [part of PHP; see http://php.net/manual/en/function. define.php] (PHP.net, 2012b) provides a straightforward means to give the links a more effective title without having to dig around in the action files themselves (which I describe later). Actual button appearance, such as borders and boxes, can be added in the CSS later. Page Construction: The Area After all of that initialization, the generation of the page actually gets underway at line 26, beginning with the XHTML 1.0 Transitional DOCTYPE, required of all

DEVELOPING A COURSE WIKI

/

223

standards-compliant XHTML pages, followed by some basic metadata in the area of the page. To make the template easier for others to set up, lines 52 through 70 dynamically generate links to CSS, JavaScript, and site icon (favicon) files. However, because those links are exactly the same across all pages of the wiki, I always copy those lines from the source view of my browser and paste them back into header.php. That cut-and-paste move replaces all of those different, dynamic script calls into static XHTML. This results in a considerable improvement on how quickly a page renders. Rather than having the PHP scripts query the location of the theme (via the $this->GetThemePath(): method) on each page load, send those paths down to the browser, and then wait for the browser to ask for the files the paths point to, the paths are simply hard-coded as XHTML into header.php. On subsequent pages, the browser should read from its cached copies of the CSS and JavaScript files and not hit the server again. However, were the dynamically generated paths to remain, the server would still have to figure out where everything is—a big performance hit. Rounding out the area of my custom template is some code to generate the RSS feed links that report changes across the entire wiki and to individual pages. There are also some lines of PHP, which I have commented out so that they are not processed by the server, which would load additional lines into the area. Generally, this is only needed when using certain third-party plugins for WikkaWiki. Because I prefer a lean and mean WikkaWiki installation, I have commented this code out. But removing the opening comment, /*, on line 87 and the closing one, */, on line 95 will make this part of the template active again for those who wish to use plugins that generate additional content in the area. Page Construction: The Area As with any XHTML document, where the bulk of content appears is in the area. I have set up a fairly complex opening body tag. It automatically receives a class based on the page slug. So, for example, the page on my wiki at http://courses.karlstolley.com/530/CourseHome will open with a body tag that looks like ; the PHP I have written captures the page slug (in this case, CourseHome) and transforms it to lowercase (to make referring to it in CSS easier; I don’t have to remember how it is capitalized—it’s just not). The PHP then appends the slug to page-. That might seem like a useless thing, because it does not change anything about the immediate experience of the page. But what that class does is allow someone to style certain pages uniquely using CSS, or even apply special JavaScript in the presence of a certain class. When a page is being edited on the wiki, my template also adds a special being-edited class to (see Figure 4). Like the special page-slug class, the being-edited class provides a structural hook for use with CSS. When a

224

/

DESIGNING WEB-BASED APPLICATIONS

Figure 4. Course Web site running in WikkaWiki.

given page is being edited, for example, as is the case in Figure 5). I use CSS to hide certain page elements: .being-edited div#header h1, .being-edited div#header p.tagline, .being-edited div#footer { display: none; }

The absence of the site title, tagline, and footer results in a physically larger text box when editing the page. Just inside the body tag is a division tag with the unique ID of page, . That division is only there to provide an additional bit of structure for page positioning for designs tht might need it. The first part of visible page content begins at line 114 of header.php, with a division of ID header. In that division, the name of the course and a link to the main page of the wiki appears in a first-level heading tag, as well as the course description in a paragraph tag. That makes the site more accessible simply by enabling someone to click on the course title to return to the main page of the site, a fairly standard convention on Web sites.

DEVELOPING A COURSE WIKI

/

225

Figure 5. Same page as in Figure 4, but in edit mode; site title, tagline, and footer are hidden from view in using CSS.

Immediately following the course title and description is an unordered list with a class of accessibility; this list contains two links for jumping to the page content or to the course navigation. Those two links improve the experience of users on certain older mobile phones and also users who rely on assistive technology: Rather than having to listen to the items in the course menu on each page or to scroll down a line at a time (as some older phones do), those groups of users can simply follow the link to jump to the content of the page. The remaining lines of header.php are devoted to the course menu and user menu, which I discuss in the Menu Generation section below. An extra division, , opens at the very end of header.php, and its only purpose is to provide, like above, another little piece of structure that can be used for styling the region around the wiki engine’s generated output. Customizing footer.php Compared to the header, the footer is very short and simple. The footer opens with two additional menus for page ownership and editing and manipulating the page;

226

/

DESIGNING WEB-BASED APPLICATIONS

these menus both appear in the that opened at the very bottom of header.php. That division closes immediately after the two menus that open the footer. The rest of the footer includes a little function for calculating page generation time (which is output as an XHTML comment; you must choose View > Source in a browser in order to see it) and an actual footer division () that provides some small print as well as links to validate the XHTML and CSS on the site. The footer division closes, then the division, followed by the closing and tags, to make the structural page complete. Menu Generation One of the recent additions to WikkaWiki has been a special menu-generation system. Prior to the current system, menu links were actually stored in the wikka.config.php file in the root directory of any WikkaWiki installation. It was clunky and inaccessible, because unless you were willing to fill up the config file with a bunch of XHTML by hand, any links were simply output as a series of anchor tags. A better, more accessible navigation would utilize an ordered or unordered list and list items to provide additional structure. The new menu system does exactly that and removes all of the old clutter from the config file. Now, menus can be created by writing up to three sets of files, using the pattern menuname.admin.inc, menuname.user.inc, and menuname.inc. Predictably, the .admin.inc menu will be displayed for wiki users who are administrators; the .user.inc menu for all registered users; and the .inc for anyone else. When the template calls the MakeMenu(); method, for example, , WikkaWiki will load cw_user_menu.admin.inc for admins; cw_user_menu.user.inc for all other registered users; and cw_user_menu.inc for everyone else. There are three sets of menus for the template that I’ve released: cw_user_menu (which outputs either a login link or a short welcome message for users who are logged in); cw_owner_menu (which provides information about who owns the page and when it was last edited); and cw_page_menu (which provides controls for manipulating the page). I’ve prefixed all of those custom menus with cw_, meaning “course Web site,” so that they do not conflict with the page, owner, and user menus that ship with WikkaWiki by default (although my template never calls up the default menus, its use of a custom cw_ prefix makes copying the menu files into the WikkaWiki config/ folder easier, as a computer won’t complain about overwriting any existing files there). Inspecting the different menu files reveals that they are quite spare, particularly for users. The content of the page menu (cw_page_menu), for example, is only three lines: {{editlink}} {{clonelink}} {{historylink}}

DEVELOPING A COURSE WIKI

/

227

The double-curly braces are WikkaWiki syntax for loading particular wiki actions; in the case of {{editlink}}, a link will be provided for editing the page, assuming that the user trying to do the editing has the proper permissions to do so under WikkaWiki’s access control lock (ACL) scheme. For example, I use a special ACL on the page containing course policies to prevent anyone but administrators from editing it. Because I am the only administrative user on the wiki, that essentially means that I am the only one who can edit that particular document. Customizing Menu Actions When I first started using WikkaWiki, to change any of the actions (e.g., editlink.php or clonelink.php) meant editing them directly in the actions/ directory of the WikkaWiki installation. That was problematic for sustainability, because any upgrade to WikkaWiki would have to be handled very carefully: forgetting which action files had changed meant that an upgrade would copy over the customized files. Now, WikkaWiki provides an actions/ folder inside of plugins/, where any customized actions or customizations to default actions can reside, which makes future upgrades to the wiki much easier (just keep a copy of the plugins/ folder and replace it after the upgrade). My custom template includes two customized actions: ownerlink (referred to by the cw_owner_menu) and revisionlink. The revisionlink action is a little more interesting to consider, because it shows how a little extra care can make the content output by the wiki slightly more readable and user-friendly. By default, the revision link outputs the last revised time in ISO 8601 format, for example, 2011-08-27 13:01:42. While this format is excellent for internalization of time as well as machine manipulation, it’s not particularly readable (and therefore accessible) to student audiences. Plus, it just looks unfinished. So my revisionlink.php file uses some different PHP functions to output the date in a format like “Friday August 27, 2011 at 1:01PM”: /*Make a nicer looking date for the pages.*/ /*Grab the page time:*/ $cw_pagetime = $this->GetPageTime(); /*Convert the string to a manipulable time data type:*/ $cw_pagetime = strtotime($cw_pagetime); /*Format the time nicely:*/ $cw_nicepagetime = date('l F j Y \a\t g:iA',$cw_pagetime);

I grab the page time from the wiki, convert the string into a time data type so that it can be used with the PHP date(): function for formatting dates (see http://php.net/manual/en/function.date.php), and then use the variable that gets assigned the nicer-looking time ($cw_nicepagetime) to output the owner and date information. Notice that, as in the template files, I prefix my variables with cw_; this is a sustainability move that anticipates any conflicts that might

228

/

DESIGNING WEB-BASED APPLICATIONS

arise from WikkaWiki using or changing a native $pagetime or $nicepagetime variable. Using Static Menus All of the menus that my template dynamically generates utilize WikkaWiki actions, which are more complex in function than simple hyperlinks to different pages. It is possible to use the WikkaWiki markup to create static links (e.g., [[CoursePolicies Policies]] creates a link to the course policies page and displays Policies as its link text). The problem is that this creates unnecessary overhead and load time on the server; I have a course menu on all pages that links to the core course documents: the calendar, the policy statement, the home page, and so on. But those links should appear for everyone, on all pages, and are always the same for everyone on all pages. There is no need to bug the wiki engine and thus load down the server to dynamically generate them on each and every page. They are always the same. So for the course menu, I opt to create a menu directly in XHTML in header.php:

• Home
• Calendar
• Projects
• Policies
• People
• All Pages

Just link the dynamic menu system, each link is placed as a list item in an unordered list; the dynamic menu’s unordered list tag takes an ID that matches the menu’s file name. For example, the cw_owner_menu.inc menu will be presented in an unordered list

that looks like:
. Those unique IDs can be used in the CSS to style each menu a little differently, including the owner and user menus, which don’t appear like lists at all. My static course menu goes a step further and places a unique ID on each list item. That makes it easy to write CSS such as: body.page-coursehome #cw_home a { background-color: #0DF; }, which will highlight the Home link on the

DEVELOPING A COURSE WIKI

/

229

CourseHome page, providing a small accessible wayfinding mechanism. If one of the course menu links is lit up with a background color, it indicates that the user is already on that page. CONCLUSION: TIME AND SUPPORT With all of these modifications in place, I have provided a rich, sustainable, and accessible page structure that includes a wide range of structural hooks—from the being-edited class on the body tag to the different wrapper divisions on the entire page and wiki content areas. These can be leveraged with CSS to enable the site’s design to change from semester to semester without my ever having to return to the structural components. When I do make changes to the structural components in the header or footer files, the menus, or the wiki actions, it’s usually only to make slight performance improvements or to make use of an improved API developed by the WikkaWiki team. Of course, I haven’t mentioned anything about the time required to take on custom development of this nature. Now that I have released these customizations as free and open source via GitHub, it will be somewhat easier to track the time that I spend working on my sites; the page at http://github.com/karlstolley/course-wiki/commits/ master/ gives a complete history of all the changes, including the dates and times that I made them. Such a record provides at least the potential to demonstrate to tenure and promotion committees the time that goes into this kind of work; publications, such as this book demonstrates, have the possibility to demonstrate, in a very traditional but important way, the intellectual merit of this work. While I would not be able to identify any direct institutional support for doing custom course Web site development (in terms of things like release time to pursue the work), the indirect support I have received has been phenomenal. Specifically, I recently received substantial resources from my dean to assemble a 19-station computer lab plus a server to further pursue the teaching and research into open formats, open source, and open standards that are both reflected by and the topic of the courses that I teach. While it isn’t possible for me to claim that the course Web sites I build themselves played a direct role in securing support for the lab, as an extension, reflection, and expression of the kinds of work that I do, they have been absolutely essential. REFERENCES Apache Friends. (2011). XAMPP [Software]. Available from http://www.apachefriends.org/ en/xampp.html Connell, R. B., Jones, M., Mace, R., Mueller, J., Mullick, A., Ostroff, E., & Vanderheiden, G. (1997, April 1). The principles of universal design. Retrieved from http://www.ncsu.edu/ www/ncsu/design/sod5/cud/about_ud/udprinciplestext.htm Free Software Foundation. (2007). GNU general public license. Retrieved from http://www. gnu.org/licenses/gpl.html MediaWiki. (2011). What is MediaWiki? Retrieved from http://www.mediawiki.org/wiki/ Manual:What_is_MediaWiki%3F Mozilla. (2012). Firebug (Version 1.10a4) [Software]. Available from http://getfirebug.com/

230

/

DESIGNING WEB-BASED APPLICATIONS

Pederick, C. (2012). Web Developer (Version 1.1.9) [Software]. Available from https://addons. mozilla.org/en-US/firefox/addon/web-developer/ PHP.net. (2012a). date. Retrieved from http://php/net/manual/en/function.date.php PHP.net. (2012b). define. Retrieved from http://php.net/manual/en/function.define.php Tapscott, D., & Williams, A. D. (2006). Wikinomics: How mass collaboration changes everything. New York, NY: Portfolio-Penguin. WikkaWiki. (2011). Welcome to WikkaWiki. Retrieved from http://wikkawiki.org/HomePage World Commission on Environment and Development. (1987). Our common future, chapter 2: Towards sustainable development. Our Common Future: Report of the World Commission on Environment and Development. Retrieved from http://www.un-dodcumens.net/ocf-02.htm World Wide Web Consortium. (2009). CSS Validation Service. Retrieved http://jigsaw.w3.org/ css-validator/ World Wide Web Consortium. (2010). Markup Validation Service. Retrieved http://validator. we.org/ Zeldman, J. (2002, February 15). Better living through XHTML. A List Apart. Retrieved from http://www.alistapart.com/articles/betterliving/ Zelfman, J. (2003). Designing with Web Standards. Berkeley, CA: New Riders.

http://dx.doi.org/10.2190/DWBC14

CHAPTER 14

An Interface for Interaction Design: Using Course Wikis to Build Knowledge Communities Steven T. Benninghoff

Design is not just what it looks like and feels like. Design is how it works. —Steve Jobs

Writing courses are tools. I do not mean “tools” in the common way of thinking— that tools are “instrumental”—separable from contexts of use. Rather, consider tools as constructive of their contexts of use for a moment. Tools are meant not simply to perform the existing tasks but to enable the imagining of new adaptations, new possibilities, and their creation. In 2003, Rob Walker wrote “Guts of a New Machine” for the New York Times magazine, an in-depth article about the then 2-year-old iPod, its creation and design, its prospects, and its creators. In his piece, Walker projects a common view of the typical techie—highly interested in the details and the “guts” of the product—and finds to his surprise that Steve Jobs is not focused on the innards of the product or on its features. Rather, Jobs’ laser focus is on simplicity in basic operation matched with a systemic, adaptable deployment. Indeed, it is easy to read Jobs’ quote and not really get what he means. His emphasis on user experience means imagining the tool as part of, and transformative of, people’s lived experience. To use a Web metaphor, the value lies less in the node, the interior, and more in the link, the application and usefulness in context. Transferring this thinking to the worlds of rhetoric and composition, technical communication and professional writing, writing teachers are, in this view, interaction designers who design their courses to mediate, for students, strategies for comprehending and analyzing writing situations, and for responding by designing their own communication “tools” (documents of many stripes) as mediating interfaces for their own audiences in turn. Chances are, if you’re reading this collection, you may already 231

232

/

DESIGNING WEB-BASED APPLICATIONS

be onboard with this sort of understanding of what it means to design courses and teach composition or technical and professional writing. But if you’re not quite there yet, I hope you’ll consider this story of how I’ve adopted and adapted the use of a wiki software (PmWiki in particular) to serve as the central interface for my courses, as an example of writing teachers responding to the writing problems of the 21st century, in a not-so-purely technical way. How do we help students build their awareness of writing and communication as knowledge negotiation, ethically engaging audiences and “others,” with not just an eye on the short-term success of their careers, but both their own long-term success and that of their communities? HOW IT WORKS, AND HOW IT WORKS I’ve used a wiki as the central course content management system for almost all of my courses, both online and face-to-face, for the last 5 years or so. While part of the impetus for using them was online teaching, and some of the benefits of it are more important in the online context, the initial use was in support of face-to-face classes, and it has had significant benefits there as well. DIFFERING WIKI ARCHITECTURES AND ASSUMPTIONS When most people think of wikis, they probably think of Wikipedia, which is only natural, as it is one the most-used and highest profile resources on the Web. But the model of a group of people (even a huge group) writing, negotiating, and maintaining a repository of knowledge, where what is in the articles is the focus— the “storing” of expert-verified information—is not the model of use for my classes. Instead, for each class, we have a course wiki that forms a “shell,” and inside that, each student has his/her own course home space. Course information, assignments, links, and more are out at the shell level (see Figure 1), and each student has a subnode, “under” their own home page, where they can create pages, links, and can upload documents (see Figure 2). Beyond this basic architecture and goals, differences in the way Wikipedia and my course wikis “work” are in their software and their “openness.” Wikipedia is notoriously “wide open”-anyone can edit a page (though how long an edit stays and the process of negotiating whether it does is different). My courses are password protected on multiple levels. Students (or others) need to have a password to get into the site, another to make edits, and a third to attach or upload files. BACK-END SET UP The software I use for my class wikis is also different from the MediaWiki (mediawiki.org) that Wikipedia uses. I use PmWiki (pmwiki.org), which is, like MediaWiki, an open-source, free software (PmWiki was originally developed and trademarked by Patrick Michaud, see http://www.pmichaud.com/wiki/Pm/ Professional Career). I originally chose PmWiki in part because it was simpler to deploy and

AN INTERFACE FOR INTERACTION DESIGN

/

233

Figure 1. A course home page.

manage than MediaWiki. As I was initially running these sites off my own office server and had to administer the system myself, this was no small consideration. And while I had been working with Web pages, html, CSS, and more, for years, my knowledge of MySQL was limited. So the fact that PmWiki stored everything as “flat files” meant I could perform back-ups by simply making a copy of all the files and folders, while MediaWiki, storing its data inside MySQL databases, seemed much more intimidating at the time. Effectively, installing and setting up an instance of PmWiki was a matter of copying the files into the appropriate folder on the server, working through the installation and set up walk-through, and then modifying the configuration file. Here too, while my knowledge of PHP is beginner level, the sample configuration PHP file provided with the PmWiki software includes a variety of options, some of which are deactivated by being marked as comments, and activating them was a simple matter of “uncommenting” some commands by deleting the “##” at the beginning of the line. Setting up passwords was a simple matter of replacing the dummy passwords in the config file and uncommenting them. Now, while of

234

/

DESIGNING WEB-BASED APPLICATIONS

Figure 2. A student home page template.

course mileage will vary, I found PmWiki to be generally pretty easy to figure out and implement for a relative beginner. THE FRONT END INTERFACING— THE WORK THAT MATTERS MOST Now, I teach most of my courses in a technical communication concentration, but I contend that while my wiki use applies for such courses, it can be also effective for writing courses of other emphasis as well. Indeed, while most of my courses are technical communication ones, they come in significantly different flavors—the service course face-to-face, the intro to the major, the service course online, technical editing, and computer documentation—and the variations in each have led to different developments and uses for the wiki. Classroom and pedagogical developments are often, rightly, local developments to meet the needs of local problems. My initial uses of PmWiki for my courses developed out of a string of related conditions—problems of students mediating, capturing, and sharing insightful readings, class discussions, and group work; combined with the complexity of developing html portfolios crash-course style.

AN INTERFACE FOR INTERACTION DESIGN

/

235

PORTFOLIOS AND CAPTURING PROCESS In our technical communication and professional writing concentration’s capstone course, students develop employment portfolios, reworking and arranging pieces written in earlier classes. Several years ago now, there was more and more push and interest in developing online portfolios, so in my precapstone courses, at the end of the term, we would have a crash course on html and develop Web-based course portfolios. These gave students exposure to online portfolios and html, as well as ideas about how portfolios work for different audiences, online versus print, and finally considerations of the difference between educational portfolios and job-seeking portfolios. But while students found the early portfolio training and the html crash course were needed and helpful, we were running into issues of material complexity and time constraints. It was that semester that I remember a student explaining, “When we’re in class, I feel like I understand, but then when I get home after working a long shift, I feel like I’ve lost the thread and can’t make it connect anymore.” The student had said this in class after we had had a marvelous discussion of Lee Brasseur’s article on Florence Nightingale and the Rose Diagrams, and this good student felt she’d lost much of what we’d collectively built the session before. It was comments like this that initially led me to try out using a wiki in my technical communication classes. There was a need for a typical process way of capturing at least some of the discussion. There clearly was a need, in a similar vein, to capture work from small-group discussions in class in ways that made those discussions captureable and shareable. The wiki allowed, in this early stage, a multiple-birds-with-one-stone response. I had found that, with the html crash course, students were generally way too concerned with the html and developing the “back end” of their portfolio, to the point that they simply could not focus on developing the explanation and value of their projects in the way that was needed. The wiki offered a valuable tool to respond to this problem. First, developing wiki pages, with their simplified markup, was relatively easy compared to html. Second, as the students would be using it through the term as a working space, they would be even less worried about the coding aspects of their portfolios, and they could concentrate on what they were trying to say. Third, the use of the wiki to write up group work responses in class or record bits after valuable classroom discussions would go a long way toward enabling those discussions not only to stick over the weekend, but to make them available in the same online resource they would use for their project explanations and reflections in their eventual portfolio. And putting as much of this kind of tacit classroom knowledge development into the wiki also had the benefit of making it shareable, with students able to learn and develop from others’ group work or discussion notes. (And, as an aside, other courses where students could acquire html knowledge became more available, so students had less need for the crash course.) See Figure 3 for an example of a portfolio template page. Finally, this shift in method for the portfolio development, in making it easier and allowing students to focus, also allowed for much more consideration of portfolios in

236

/

DESIGNING WEB-BASED APPLICATIONS

Figure 3. Course portfolio page template.

different forms and framed for different audiences. Being able to think about, and discuss, how portfolios work for outsiders and potential employers was an eye opener for the students and engaged them in explaining and relating their learning in the course in ways that argued for the value of their learning. That these framings and targetings, not just the technology aspects of the activity, constituted a valuable technical communication experience in itself, was also a key point. Using the wiki as a mediating tool was clearly allowing the courses, in a way parallel to Jobs’ conception of design, to focus on and consider exterior aspects of use.

BUILDING COMMUNITY AND KNOWLEDGE COMMUNICATION Technical communication is, of course, complicated. That’s kind of its raison d’être. But it’s more than just that the information someone wants to share is complex and contingent. Most of the time, technical communication is also across communities, which have their own sets of common knowledge, terminology, assumptions, and perspectives. Writing teachers have long known the importance of developing a sense of community in the writing classroom to build a constructive and developmental environment. It’s no less important in a technical communication course, but the problems of community, group membership, and knowledge

AN INTERFACE FOR INTERACTION DESIGN

/

237

communication are exacerbated, and for three different course situations, in different ways. In technical communication service courses, where students of a variety of majors take a technical communication course, the students tend to be acutely aware of their group memberships and relative areas of knowledge. Made up of a variety of nonmajors, students know the course is not “in their field,” and feel suspect about the level of their knowledge both in their major field (how far through their program are they?) and in writing/technical communication. This combination problem of disciplinary knowledge and discipline mix was well-illustrated in my services courses at a previous institution. Positioned as “398”, or end of junior/beginning of senior year, the mix of different flavors of engineers in my class would usually be around half who had had an internship and half who had not. The half who had not had an internship would express frustration in having to take a course out of their major and that they would “never need this,” while those who had had an internship would say, “I wish I’d had this class sooner”—an excellent illustration of the conflicting invisibility and value of our field. At my current institution, the service course is positioned earlier (324), which might add to the lack of knowledge in the students’ chosen disciplines, though many take the course later in their programs than the number would indicate. But surprisingly, this kind of problem also presents itself for our students in the major at my current institution. Because of the program structure, our students take the service course first, which can’t, given its mixed audience, function as an introduction to the discipline of technical communication for majors. Therefore our students come into the real introduction to the field at the 400 level—late in their degree programs, feeling, like the nonmajors in the service course prior, somewhat like novices, and with more “attachment” to other areas of writing knowledge and social groups than their major. A third way that community-building is a more obvious problem is in online instruction. I’ve been teaching an online version of the service course for 4 years now, and it is in this environment that the value of the wiki as a mediating tool becomes most obvious, because it has to stand in for, not merely supplement, the normal face-to-face class activities. In a situation like this, having students develop a home page of their own, with a photo and information about their backgrounds and experience, which is always available (and required reading), has been a valuable first step in building an idea of a class community. Students in the sections have responded positively to this, explaining that it has been a rare experience that their online courses work to build a community this way. But in the face-to-face courses, as well as online course, the use of the wiki to develop a base understanding of each other as members of the group is only the beginning. KNOWLEDGE COMMUNITY CONSTRUCTION It has been more than 11 years now since Susan Harkness Regli wrote “Whose Expertise? The Technical Writer’s Expertise in Inventio” (1999), which asked a troubling question: if experts are the source of all content, what it is that writers

238

/

DESIGNING WEB-BASED APPLICATIONS

contribute, just what do we bring to the table? The answer lies, in part, in refiguring where the value lies. Like the analogy to the iPod, the value is in the deployment and changed sense of possibility that seeing and imagining across situations and contexts can provide—invention. Regli explains that knowledge should be understood as an activity rather than a commodity, explicitly points out that knowledge is a collaborative activity across disciplinary boundaries, and calls this action “elaborate communication.” While the point and situation of this question, with technical writers and subject-matter experts, is central to technical communication, it clearly resonates for writing courses and situations of many kinds. The recognition is that value, in knowledge as action, is tied to it’s adaptability—its linking—as much as its nodes. With that in mind, let’s return to the wiki as constructing an interface for such action. In getting the semesters rolling, and getting students to begin building knowledge relationships, early assignments in the wiki ask students to list areas of experience and knowledge. The goal for listing work experience, areas of interest and knowledge, hobbies, sports, and extracurricular activities, cultural and place knowledge, is for students to recognize, and make more conscious, the experiential knowledge they already have. From these, students are asked to identify and list a number of activities and/or processes, and particular knowledge needed or gained from them. Finally, they choose two to three of these activities to write short examples of how technical communication is involved, in varied and embedded ways, in their lives already. Follow-up assignments from these explorations have students reading each other’s varied areas of interest and knowledge, and in particular ways, the explications of how technical communication is involved in particular activities or processes in them. The goals of the assignments are expressly to (a) make knowledge conscious and (b) demonstrate how technical communication and knowledge processes can be understood in parallel ways in different areas of experience and in different fields. It is consciously a knowledge-silo ameliorating activity, and students resist it either because they believe the have no “silo credentials” yet or because as budding majors, they’ve bought into the idea that their value lies inside the silo. Follow-up assignments either in class or in online discussion spaces then can discuss and relate technical and knowledge communication activities across varied areas of student experience. Students need to become more consciously aware of the relative expertise they do have and the myriad ways that their many roles, knowledge, and experience can be brought to bear—made relevant—to the new knowledge and roles they are pursuing. Beyond that, they must become conscious of the connective actions they are performing to make this happen. Using the wiki, where students can easily share and read and respond to each others’ work, is certainly not the only way to do such an activity, but carrying it out in a shared class space, that is an assemblage of individual student home spaces, presents an interface representative of the very goals of the class and activity. It should be clear that using a wiki as a class CMS is different from the way Wikipedia works. Wikipedia, while it does work through massive collaboration, and through a different process of authorization of information, still does work toward a relatively fixed model of the genre of encyclopedia article: the ultimate value—the goal—is the node. This is an interesting point, because the value of Wikipedia writ large

AN INTERFACE FOR INTERACTION DESIGN

/

239

is much more a consequence of its more Web 2.0 aspects—nearly universal access, massive collaboration in content production and verification, and correspondingly massive scope. The use of the wiki in my classes does, like Wikipedia, value the experience and knowledge of individuals who don’t necessarily have normal authority credentials. And the exercises I’ve heard colleagues describe—of assigning the editing of Wikipedia pages and of observing the negotiation of knowledge on Wikipedia discussion pages—these are good things. But often these exercises still feel separated from students because they tend to be different from engaging their own experience and knowledge in thinking about how discourse and knowledge function in their own workplaces, teams, and organizations. These activities, in turn, through focusing on the participatory integration of knowledge and experience students already have, with goals and aspirations of the course and for their careers, map well with key theoretical foundations for the field. Regli (1999) has argued that invention—as present in the analogical comparison these assignments are calling for—is the core competency of technical communication, and its ability to bridge silos of disciplinary boundaries is vital. And if, as Carolyn Miller (1989) posited long ago, we need the practicality of technical communication to be understood as a kind of ethic of conduct, working to improve not only performance but also the greater good, we must engage students’ own interests and concerns, and enlist these into communal knowledge practices. DOING, BUT ALSO KNOWING WHAT WE DO This chapter has sought to put the employment of a wiki as a CMS into a context that reveals the complexity of goals and usages of such a system and interface. It certainly only has scratched the surface. While it discusses and analyzes the goals and workings of the assignments and the use of the wiki with the technical communication majors, the critical awareness of process is always an ephemeral thing. In their new reflection on “The Politics of the Interface,” Cindy and Dickie Selfe (2009) reiterate “the ideological contexts of technology design decisions are still being rendered invisible” (p. 37), and it seems inescapable to me that this will continue to be true. But this is also a key to our value, and the value we contribute to our students. In a way, like Steve Jobs, we’re in the position of practicing invention, and less like him, of teaching it. Understanding how to operate an interface can be quite separate from understanding of the task, goals, or purposes for doing so, and that adaptability is the point, our purpose. And while companies may hire entry-level employees based on transmission and operational facility, the goal of higher education ought to empower students beyond initial employment. Facility at the task analysis, process design, and interface design are skills and attitudes needed in the 21st century. Workers who design the work, renegotiate its goals, relationships, and its success, are those who will advance in our new economy. The idea is that there is a simple, uncomplicated bottom line, and that companies and workers can continue to focus short-term needs to be explicitly belied by educational experience, even if it will never be able to say, for certain, what the adaptations and developments in the future will be.

240

/

DESIGNING WEB-BASED APPLICATIONS

REFERENCES Miller, C. (1989). What’s practical about technical writing? In B. E. Fearing & W. K. Sparrow (Eds.), Technical writing: Theory and practice (pp. 14–24). New York, NY: Modern Language Association. Regli, S. H. (1999). Whose ideas?: The technical writer’s expertise in inventio. Journal of Technical Writing and Communication, 29(1), 31–40. Selfe, C., & Selfe, D. (2009). Reflections on “Politics of the Interface: Power and Its Exercise in Electronic Contact Zones.” In S. Miller-Cochran & R. L. Rodrigo (Eds.), Rhetorically rethinking usability (pp. 35–38). Cresskill, NJ: Hampton Press. Walker, R. (2003, November 30). Guts of a new machine. New York Times Magazine. Retrieved from http://www.nytimes.com/2003/11/30/magazine/301POD.html

Contributors

Ron Balthazor received an M.Div. from Emory University in 1987 and completed his Ph.D. at the University of Georgia in 1999. His publications include “Digression and Meaning: A Reading of ‘In the Miro District’” (Critical Essays on Peter Taylor), and “To Play Life: Thoreau’s Fabulous Reality” (ATQ). His most recent publication, with Christy Desmet, Caroline Barratt, and Kristen Nielsen, is “Collaboration Is Key: Librarians and Composition Instructors Analyze Student Research and Writing” (Portal). Balthazor currently teaches composition and is the lead developer of the project, a web application for the complete writing process. Steven T. Benninghoff is an associate professor of written communication at Eastern Michigan University. He teaches courses in technology and style, technical communication, computer documentation, technical editing, and research methods. His research interests revolve around design and the social impacts of rhetoric and technology—usability, interaction design, and pedagogy. Benninghoff coauthored “TPC Program Snapshots: Developing Curricula and Addressing Challenges” (Technical Communication Quarterly). Stephen A. Bernhardt holds the Andrew B. Kirkpatrick, Jr. Chair in Writing at the University of Delaware, from which position he promotes strong writing and communication skills across the university. He finished a five-year term as chair of English in August 2009. He teaches courses in scientific and technical communication, first-year composition, computers and writing, and grammar and style. Bernhardt is widely published in leading journals, with research interests centering on visual rhetoric, computers and writing, workplace training and development, and the teaching of scientific and technical communication. He is past president of both the Council for Programs in Technical and Scientific Communication and the Association of Teachers of Technical Writing. He just began a term on the editorial board of College Composition and Communication, recently completed similar service on the board of Technical Communication Quarterly, and continues to serve on the editorial board of the Journal of Business and Technical Communication. Bernhardt is past director of two National Workplace Literacy Demonstration Projects, funded by the U.S. Department of Education. As Senior Consultant for Scientific Services, McCulley/Cuppan LLC, Salt Lake City, he has consulted widely with the pharmaceutical industry on designing large documentation sets using global teams and technologies, developing training programs, and improving written communication as a part of new drug 241

242

/

DESIGNING WEB-BASED APPLICATIONS

registration. He taught at New Mexico State University for 14 years and at Southern Illinois University–Carbondale for 6 years. He received his Ph.D. at the University of Michigan. His website is at www.english.udel.edu/sab David Chapman is a fixed-term instructor of technical communication in the English Department at Minnesota State University. He has 10 years experience in the fields of environmental consulting, data analysis, and scientific communication. After earning his B.S. in entomology from The Ohio State University in 2000, he worked as a biologist and environmental planner for a consulting firm in Sacramento. In 2002, he walked the Pacific Crest Trail from Mexico to Canada, where he met his future wife, Cara. After moving to Minnesota in 2003, he worked for the EPA laboratory in Duluth on aquatic toxicology and asbestos-related projects. In 2008, he completed an M.A. in technical communication at Minnesota State University, Mankato. For his thesis, he investigated web-based instructional tools for computer-enabled classrooms. Chapman currently works from home in Mankato, MN, and spends most of his free time playing with his 2-year-old son, Arlo. Christy Desmet is a professor of English and director of the University of Georgia First-year Composition Program and Writing Center in Park Hall. She is a member of the initial team that developed the project, and, as First-year Composition director, in 2005 she introduced ePortfolios and ePort pedagogy into the First-year Composition Program. Her coauthored publications include: “Re-visioning Revision with Electronic Portfolios in the University of Georgia First-year Composition Program” (Electronic Portfolios 2.0: Emergent Findings and Shared Questions, 2009); “Collaboration Is Key: Librarians and Composition Instructors Analyze Student Research and Writing” (portal: Libraries and the Academy, 2009); and “Reflection, Revision, and Assessment in First-year Composition” (Journal of General Education, 2008). David Fisher is an assistant professor of rhetoric and writing at the University of Arkansas at Little Rock. His research focuses on using digital media, games, and simulation to teach basic, critical, and professional literacies. He has designed and built experimental applications currently used in post-secondary classrooms, including one that leverages ESL placement essays to help teach basic English grammar (iWrite) and one that enables professional communication instructors to deploy dynamic workplace writing scenarios in their classrooms (MyCase). Articles about this work have appeared in CALICO Journal, Kairos, Computers and Composition, and IEEE Transactions in Professional Communication. Paul Gestwicki is an assistant professor in the Computer Science Department at Ball State University. He holds a Ph.D. in computer science and engineering from the University at Buffalo for his work in interactive visualization of object-oriented program execution. His research interests include information visualization, software design, and computer science education. Jeffrey Grabill is a professor of rhetoric and professional writing at Michigan State University and co-director of the Writing in Digital Environments (WIDE) Research Center. His research focuses on how groups inquire, learn, and communicate in order to engage publicly. Grabill has published two books on community literacy and articles in such journals as College Composition and Communication, Technical Communication Quarterly, Computers and Composition, and English Education.

CONTRIBUTORS

/

243

William Hart-Davidson is an associate professor of rhetoric and writing at Michigan State University and co-director of the Writing in Digital Environments (WIDE) Research Center. He teaches courses in technical communication, interaction design, and research methods. His research interests lie at the intersection of technical communication and human-computer interaction in such areas as visualizing knowledge work processes, information, and user experience design. His writing has been published in such journals as Technical Communication, Technical Communication Quarterly, Computers and Composition, Kairos, and Journal of Software Documentation, and in various edited collections. Robert Hudson is a research associate at Texas Tech University and an adjunct professor at Towson University. He has a B.S. in information systems from York College and an M.S. in professional writing from Towson University. He has worked as a software and database developer for 14 years and as an adjunct business writing instructor for 4 years. He is interested in distributed assessment, online writing centers, and women’s roller derby. In his spare time he referees for the Dutchland Rollers, a league in Lancaster, PA. Suguru Ishizaki uniquely combines scholarly and practical qualifications with a track record of more than 20 years of experience in interaction design, visual design, and basic research on visual and verbal communication. He is currently an associate professor of rhetoric and communication design in the Department of English at Carnegie Mellon University, where he is responsible for developing and teaching courses on visual/multimedia design and visual rhetoric that target professional and technical writing students, at both the graduate and undergraduate levels. He also co-directs the joint Masters Program with the School of Design in Communication Planning and Information Design. Before this appointment, he worked at QUALCOMM on the research and development of mobile user interfaces and, prior to that, was on the faculty of the School of Design at Carnegie Mellon. He received a Ph.D. and M.S. from MIT’s Media Laboratory and a B.F.A. in art and design from Tsukuba University, Japan. He is the author of Improvisational Design: Continuous Responsive Digital Communication (MIT Press, 2003) and a coauthor of The Power of Words: Unveiling the Speaker and Writer’s Hidden Craft (Erlbaum, 2004). Steven D. Krause is a professor in the Department of English Language and Literature at Eastern Michigan University. Most of his teaching, including his online teaching, focuses on the relationship between writing and technology. He has published articles in Computers and Composition, Kairos, and other journals, and his essay “When Blogging Goes Bad” was included the third edition of T. R. Johnson’s Teaching Composition: Background Readings. Susan M. Lang is an associate professor of technical communication and rhetoric and director of first-year writing at Texas Tech University. She has published in College English, Computers and Composition, and assorted anthologies. She is currently working with Dr. Craig Baehr on a manuscript on data mining. Michael McLeod is an adjunct faculty member in the Rhetoric and Writing Program at Michigan State University and the user experience researcher and designer at the Writing in Digital Environments (WIDE) Research Center. His research interests lie primarily in the field of technical communication, specifically in the areas of

244

/

DESIGNING WEB-BASED APPLICATIONS

information architecture, interface design, information visualization, usability, and user experience design. Brian J. McNely was an assistant professor of rhetoric and composition in the English Department at Ball State University and a faculty fellow with the campus-wide Emerging Media Initiative. Hi is now at the University of Kentucky. His research explores knowledge work in digital writing environments, and he has published articles and chapters on design of communication, visual discourse, and professional writing curricula. Mike Palmquist is associate vice provost for learning and teaching, professor of English at the University of Kentucky, where he directs the university’s Institute for Learning and Teaching. His scholarly interests include writing across the curriculum, the effects of computer and network technologies on writing instruction, and new approaches to scholarly publishing. His work has appeared in such journals as Computers and Composition, Written Communication, IEEE Transactions on Professional Communication, Journal of Engineering Education, Kairos, Council of College Teachers of English Studies, and Social Forces, as well as in edited collections. Since 1992, he has coordinated the development of Writing@CSU (http:// (http://writing.colostate.edu) and its web-based learning environment, the Writing Studio. He is also founding editor of the WAC Clearinghouse (http://wac.colostate.edu). Matthew Penniman is a master’s student in Digital Rhetoric and Professional Writing at Michigan State University, with a particular interest in community and digital literacies. He is also a technology consultant for several local nonprofit organizations, facilitating technology planning, website creation, and effective software practices. His work has been published in the collection New Liberal Arts. Penniman currently works as a writer and web developer for MessageMakers, a media production company based in Lansing, MI. The PIT Core Publishing Collective is a publishing collective formed at the University of North Carolina at Chapel Hill. Its members include undergraduate students from the university at large who seek an audience for their scholarship, students in classes who are writing for the journal, instructors who are integrating publishing activities into their pedagogy, and a mix of graduate students, undergraduate students, and faculty exploring possibilities for publishing and promoting undergraduate research and scholarship using open-source Web 2.0 technologies. Stacie Rohrbach is an associate professor in the School of Design at Carnegie Mellon University. She teaches studio- and seminar-based communication design courses at all levels of the undergraduate and graduate curriculum. She is interested in the way people perceive and process information and how their ability to learn may be improved by translating complex, abstract information into concrete, experiential forms. Rohrbach also studies design pedagogy in professional and general education settings and explores the relationships between print and dynamic mediums. Before her current academic appointment, she worked professionally in both print and digital media as an art director, designer, and researcher, developing identity systems, corporate standards manuals, interactive websites, and product packaging. Rohrbach earned a B.F.A. in graphic design from Carnegie Mellon University in 1996 and a master’s degree in graphic design from North Carolina State University in 2003.

CONTRIBUTORS

/

245

Sara Steger received her Ph.D. in May 2009 from the University of Georgia, where her scholarly and pedagogical interests focused on nineteenth-century British literature and humanities computing. She is one of the developers for the project, a digital writing environment that aggregates and transforms student writing and peer/instructor feedback into information-rich document displays. Karl Stolley is an assistant professor of technical communication in the Lewis Department of Humanities at Illinois Institute of Technology in Chicago, where he teaches graduate courses in web design, knowledge management, and information architecture. Stolley also directs Gewgaws Lab, an open-source design and development research lab investigating humanized approaches to digital communications technology. Gewgaws Lab is part of his broader research into open-source development, web standards, and source-level digital literacy. Stolley’s publications include articles in EEE Transactions in Professional Communication, Journal of Business and Technical Communication, and Kairos: A Journal of Rhetoric, Technology and Pedagogy, and his book-length treatment of standards-based web design, How to Design and Write Web Pages Today (Greenwood Press, 2010, in Greenwood’s Writing Today series). His website is at http://karlstolley.com Robin Wharton is a Marion L. Brittain Postdoctoral Fellow at the Georgia Institute of Technology. She received her Ph.D. from the University of Georgia, where she has been working as a researcher and developer on the project since 2005. Her research interests include digital pedagogy, medieval and early modern law and literature, and critical legal studies. Wharton also holds a J.D. from the University of Georgia, and she continues to consult and publish on matters involving the influence of intellectual property law on the development of new and traditional media. Joseph John Williams is an associate professor of rhetoric and writing at the University of Arkansas at Little Rock. His current research focuses on the relationship between writing and game design. Specifically, he looks at the connections between the writing process and the design process, as well as the effects of automated, interactive systems on writing and reading experiences. Additionally, he builds games and other experimental interactive systems, both to explore the concepts he researches and to provide digital tools for writers. Williams is currently working on a project that combines a game with a scholarly article. His research has appeared in Computers and Composition and Kairos. Michael Wojcik is a master’s student in digital rhetoric and professional writing at Michigan State University, specializing in computational rhetoric, and is a principal software systems developer at Micro Focus International plc, working primarily on middleware, security, and emulation. His work has been published in Works and Days and the Dictionary of Literary Biography.

Index

Agile software development, 4–5, 69. See also One Michigan Ave advantages, 89, 92 agile and writing, 76–78 agile in practice, 73–75 backlog tasks, 73 classroom adaptation, 74 classroom advantage, 74 demos, 73 drawback, 74 elements, 72–73 iterations and, 72–73 outside classroom, 75 philosophy, 71–72 tools, 75 user emphasis, 75 virtues, 79–80 AJAX, 33 Amazon, 2 “Article-the Game.” See computer, video games Audience, 6 Authenticity, 177

Balsamiq Mockups, 46, 47f Balthazor, Ron, 34–35 Bartholomae, David, 107 Benchler, Yochai, 15–16 Bitzer, Lloyd, 205 Blackboard, 195–196, 204, 213 Blogs, content management systems (CMS) vs. 195–198. See also Wordpress Blogs, Wikis, Podcasts, and Other Powerful Web Tools for Classrooms (Richardson), 205

Burke, Kenneth, 108–109 Byram, Charlotte, 30, 30f, 31f

Cascading style sheets (CSS), 216–217 Cincinnati Enquirer, 183 Cinders, Ash, and Commitment: Database Pathos in Six (Million) Parts (Salvo), 206 CMS. See content management systems Collaboration, collaborative writing work, 5, 177 enabling technologies, student knowledge work, 96–97 Google Wave, 93–94 new forms, 95–96 PIT Journal, 187–190, 189f Writer’s Help, 171–173 Writing@CSU, Writing Studio, 62, 62f Computer, video games “Article-The Game,” 111–114 authoring interface, 115f, 116f, 117f, 119f building with “Article,” 114 conversations, dialog lines, 115, 117–118, 118f demo game questions, 113t dialog arrangement, 119f dialog line generation, 117f pedagogical objection to, 109 player interface, 112f, 118f playing “Article,” 110 research studies, 110–111, 120 scholar-players, 107–108, 120–121 section, room editors, 115f sources, speakers and media objects, 114–115, 116f

247

248

/

DESIGNING WEB-BASED APPLICATIONS

[Computer, video games] spaces, sections and rooms, 114, 115f stage direction, 118f writing a game, 109–120 Computer-Assisted Instruction in Composition: Create Your Own (Selfe), 3 Computers and Composition, 3 Computers as environments, 2 Content management systems (CMS). See also Drupal Blackboard, 195–196, 204, 213 blogs vs., 195–198 firewalls, accessibility, 197–198 instructors and, 196 problems with, 196–198 Contributing student pedagogy (CSP), 95–96 Course management system (CMS) shortcomings, 21 Courseware complaints, 1 Crowdsourcing, 179–180 CSP. See contributing student pedagogy CSS. See cascading style sheets

DePew, Kevin, 196–197 Designing with Web Standards, 216 Document exchange, dropbox method, 21 Document Type Definition (DTD), 20, 22–23 Dreaming in Code (Rosenburg), 175 Dreamweaver, 214, 214f Drupal (CMS) content management system. See also PIT Journal bookmarks module, 188 comment form, submission rating tool, 180, 180f hooks, 176 installation steps, 178 project overview, 177–183, 180f, 181f, 182f promotion queue, reviewer ratings, 180, 181f selection reasons, 178–179 user points, review submissions, 182f

EDUCAUSE, 157, 196 Electronic Word, The (Lanham), 21 Eli object structure of review, 11–15

Eli, users comment interaction, 15t

adding documents with one click, 27f AJAX and, 33 assessment piece, 32–33 development team, 20 ePortfolio interface, biography, list of documents, 28f funding, 34–35 home-made XML editor, 22f institutional imperatives, research and assessment, 30–33 interface evolution, 19–20 jEdit as XML editor, 24–25, 26f LMS functions, 25–26 LMS redefinition, eDocs development, 33–34 OpenOffice and, 25–26 software goal, 4 user base, 19 XHTML display, 23, 24f, 25f XML editor and, 20–25 emma, ePortfolio advantages, 27 Byram’s cartoon biography, 30, 30f Byram’s introductory reflective essay, 31f grading interface, 29f interface, biography, list of documents, 28f pedagogical imperatives, 26–30

First Monday (website), 196

GitHub, 212 Google Docs, 13 Google Wave advantages, 96–97 collaboration and, 93–94 distributed stakeholder participation within, 98–99, 98f interface screen capture, 99, 100f leveraging, 97–103 limitations, 97 professional/technical writing use case, 98–99, 98f Wave Data and, 97 Writing the Wave (WtW), 99, 101–103, 101f, 102f Guts of a New Machine (Walker), 231

INDEX

Hacker, Diana, 157 Hall, Cheryl, 205 Hawkins, Ames, 206–207

Insidious Pedagogy: How Course Management Systems Impact Teaching (Lane), 196 Interactive Design Lab, 144, 146 Interactive self-learning document design tutorial, professional writing course, 141 audio-visual presentation, 143, 144f components, 143–145, 143f, 144f course overview, 147 future studies, 153 hands-on exercise, 144, 146f Interactive Design Lab, 144, 146 methods, procedures, 148 multiple-choice self-assessment question, 145f original, revised student résumés, 151, 152f, 153f preliminary results, discussions, 148–153 résumé project overview, 149f terms selected by students, final reflection assignment, 150, 151t terms selected by students, second reflection assignment, 148, 150t tutorial in classroom use, 147–152 tutorial organization, 143f tutorial overview, 142 Inter/National Coalition of Electronic Portfolio Research, 31–32 Interweb, 5 Inventing the University (Bartholomae), 107 IReport, 2

Journal of Computers and the Humanities, 3

Kalmbach, James, 205 Kindle, 2 Kludge, 195 Knowledge work. See also Google Wave; Writing the Wave contributing student pedagogy (CSP), 95–96 curricular, pedagogical perspective, 95–96 enabling technologies and, 96–97

/

249

[Knowledge work. See also Google Wave; Writing the Wave] participatory education, 96 research on, 95 studio-based learning (SBL), 96

LAMP stack, 220–221 Lane, Lisa, 196 Lanham, Richard, 21 LeBlanc, Paul, 3, 8 Lego dream, 175–176 Lettner-Rust, Heather, 196–197 A List Apart (Zeldman), 216 Lynx, 214, 215f

Manifesting New Media Writerly Processes (Hawkins), 206 Mediating Power: Distance Learning Interfaces, Classroom Epistemology, and the Gaze (DePew, Lettner-Rust), 196–197 MediaWiki, 218–219, 223 Metaphor, role of, 56–57 Microsoft vs. Eli review object model, 14f Microsoft Word review, track changes features, 10–11 motivation, 176

New York Times Magazine, 231

Object structure of review, Eli, 11–15 One Michigan Ave (OMA), 69, 70f home page, second iteration, 80f home page, third iteration, 79, 81f news feed page, 83f as product, 80 source code excerpts, 85f transportation page, 82f user Personas report, 84f Online Writing Center, 53–56, 53f, 54f 55f Online writing environments Eli, users comment interaction, 15t Microsoft vs. Eli review object model, 14f object structure of review, Eli, 11–15 peer review and, 8, 10–11 reauthorizing review, new activity model, 11

250

/

DESIGNING WEB-BASED APPLICATIONS

[Online writing environments] review as social practice, 12f rhetorical objects, 16–18 rhetorical objects, planar process model, 17f software-as-theory, reimagining writing activity, 15–16 user-centered design, interface, 8–9 W3C Document Object Model, 7 writing classrooms, peer review, 8, 10–11 writing interventions at organizational scale, 9–10 OWLs (Online Writing Labs), 52

Parry, David, 198 Pedagogical goals, 2 Peer review, 8, 10 new activity model, 11 as social practice, 12f Peersourcing, 180, 182, 190 PHP, 215–216 PIT Journal, peersourcing, collaborative publishing. See also Drupal authentic public audience, 185–187 collaboration, peer review and, 187–190, 189f motivation, rewards, risks, 183–185 PIT process results, 190–191 project overview, 177–183, 180f, 181f, 182f student comments, 185–190 Table of Contents, inaugural edition, 190, 191f PmWiki, 232–234 Politics of Interface, The (Selfe), 239 ProfHacker Blog, 198

Raider Writer .NET, 4, 43–45, 44t. See also TTOPIC RAW (Reading and Writing) New Media (Hall, Kalmbach), 205 Regli, Susan, 237 Reusable code, 176 Rhetorical objects, 16–18 Rhetorical objects, planar process model, 17f Rhetorical Situation, The (Bitzer), 205 Richardson, Will, 205 Rosenburg, Scott, 175–176

Salvo, Michael, 206–207 SBL. See studio-based learning Security, 42 Selfe, Cynthia, 3, 239 Selfe, Dickie, 239 SMV. See Speech Made Visible Software layers, 176, 181 Software workflows, 1 Software-as-theory, reimagining writing activity, 15–16 Sommers, Nancy, 157 Speech Made Visible (SMV), 69, 70f, 81–84 edit page, first iteration, 87f edit page, mock-up, 86f rendering page, 89 SMV Praat script, 82–83, 88f source code excerpts, 90–91f St. Martin’s Handbook, 34 Studio-based learning (SBL), 96

Tapscott, D., 218 Technical, professional literacy, 2–3, 141 The Myth of the Rhetorical Situation (Vatz), 205 TTOPIC, 4 original application, 37–38 original database, 39–40 redesign, redevelopment, replacement, 38–39 redevelopment, 42–45 security problems, fixes, 40–42 technological, pedagogical rigidity, 39–42 TTOPIC, development approach Balsamiq Mockups, 46, 47f new procedures, 45–46 process, 45–46 research implications, 46, 47f TTOPIC, redevelopment effective database design choices, management, 43–44 error handling, 43 page layout, design, 42–43 Raider Writer .NET, 43–45, 44t scalable, growth-oriented systems, 45 script languages, enterprise environment migration, 44t stabilization, migration, 43

INDEX

Ubuntu, 220 user-centered design, interface, 8–9

Vatz, Richard, 205 Visual communication skills, 5

Walker, Rob, 231 Wave Data application interface (API), 97 W3C Document Object Model, 7 Wealth of Networks, The (Benchler), 15 Web standards, 215–218 Web-based instructional application, technical communication class anonymous peer evaluation, 126–127 application design, 126–127 class, association sessions, 128, 129f class discussion, feedback, 127 complimentary technologies and, 138–139 detailed overview, 128–130, 129f, 130f, 131f, 132f effective use of technology, 138 equivocal tasks, 126 evaluation procedure, 134–135 implementation, 127–132 in-class evaluation, 132–135 instructor’s session page, 131f, 139 instructors view of Step 2, 130, 133f interface issues, 137–138 network utilization and, 139 perceived learning, 136–137 results, discussion, 135–138 session summary, 131, 134f student motivation, 135–136 student relevance, 136 task response, 129–130, 130f value, 137 Web-enhanced application advantages, 125, 139 Whose Expertise? The Technical Writer’s Expertise in Inventio (Regli), 237 WIDE. See Writing in Digital Environments Wikinomics (Tapscott, Williams), 218 Wikipedia, 232, 238–239 Wikis. See also MediaWiki; PmWiki architectures, assumptions, 232, 233f, 234f back-end setup, 232–234

/

251

[Wikis. See also MediaWiki; PmWiki] community building, knowledge communication, 236–237 doing, knowing what we do, 239 follow-up assignments, 238 front-end interfacing, 234 how it works, 232 knowledge community construction, 237–239 portfolios, capturing process, 235–236, 236f student home page template, 234f technical communication and, 236–237 WikkaWiki accessibility, universal design, 211 course web site, 223, 224f course web site, edit mode, 224, 225f customizing, 221–229 developer background, 213–217 editors, 220 footer .php customization, 225–226 header .php customization, 221–222 LAMP stack, 220–221 local web server and, 220–221 MediaWiki software and, 218–219 menu action customization, 227–228 menu generation, 226–227 migration to, 219 page construction area, 223–225 page construction area, 222–223 software specific details, 212 static menu use, 228–229 sustainability, 211–212 testing, development environment, 219–221 time, support, 229 version control systems, 221 web browsers, Web Developer Add-on, 220 Williams, A. D., 218 Wordpress, 197 benefits, 203–207 blog screenshot, 200f .com vs. .org version, 201–202 dashboard screenshot, 199f design, flexibility features, 204–205 ease of use, 199 free, open-source software and, 201 grading, copyright-protected materials and, 200–201

252

/

DESIGNING WEB-BASED APPLICATIONS

[Wordpress, 197] institutional approval, official policy, rules, 199–200 migration from CMS to, 202–203 openness, public presence, 205 privacy concerns and, 207–208 pros of, 198 screen capture, 203f WordPress a Better LMS (Parry), 198 World Commission on Environment and Development, 211 World Wide Web Consortium (W3C), 7, 216 Writer’s Help, 155, 157 citation model with pop-up, 161, 162f, 163 content panel with links, 160–161, 161f customization, interactivity, 166–168, 167f, 168f focus groups, usability testing, reviewers, 169–173 initial design, student responses, 158–160 life-cycle planning, 171–173 navigation feature usefulness, 159f Quick Help feature, 163, 163f quick tour, 160–163 search engine, student language, 163–166, 165f, 167f texts, applications collaboration, 171–173 three-panel layout, 160, 160f writer’s identity work, 108 A Writer’s Reference (Hacker, Sommers), 157 Writing classrooms, peer review, 8, 10–11 Writing in Digital Environments (WIDE) research center, 9, 17–18 Writing interventions at organizational scale, 9–10

Writing Teachers Writing Software: Creating Our Place in the Electronic Age (LeBlanc), 3, 8 Writing the Wave (WtW), 99 contribution activity chart, 101, 102f implications, future work, 103–104 software architecture, 101, 101f WtW Robot, 101, 102f Writing@CSU, Writing Studio, 4, 57–58, 57f beta version, 58f communication, collaboration, publication tools, 62, 62f composing, project management tools, 61, 61f course management system, 62–64, 63f, 64f current status, 58–64 customized personal page, site resources, 59f, 60f developer reflections, 64–65 future development plans, 65–66 home page, 52f instructional content, 60–61 origins, 51–55 site resources, architecture, 59–60

XAMPP, 221 XHTML, CSS, 23, 24f, 25f, 216–217, 217f XML (eXtensible Markup Language), 20 XSLT (eXtensible Style Language Transformations), 20

Zeldman, Jeffrey, 216