<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<title>Zotero Report</title>
<link rel="stylesheet" type="text/css" href="bibliography_files/detail.css" />
<link rel="stylesheet" type="text/css" media="screen,projection" href="bibliography_files/detail_screen.css" />
<link rel="stylesheet" type="text/css" media="print" href="bibliography_files/detail_print.css" />
</head>

<body>
<ul class="report combineChildItems">

<li id="i42" class="item journalArticle">
<h2>The Lo-Fi Manifesto</h2>
<table>
<tr>
<th>Type</th>
<td>Journal Article</td>
</tr>
<tr>
<th class="author">Author</th>
<td>Karl Stolley</td>
</tr>
<tr>
<th>Publication</th>
<td>Kairos</td>
</tr>
<tr>
<th>Volume</th>
<td>12</td>
</tr>
<tr>
<th>Issue</th>
<td>3</td>
</tr>
<tr>
<th>Date</th>
<td>2008-05-15</td>
</tr>
<tr>
<th>URL</th>
<td><a href="http://kairos.technorhetoric.net/12.3/topoi/stolley/">http://kairos.technorhetoric.net/12.3/topoi/stolley/</a></td>
</tr>
<tr>
<th>Accessed</th>
<td>Monday, 21 February, 2011 14:48:34</td>
</tr>
<tr>
<th>Date Added</th>
<td>Monday, 21 February, 2011 14:48:34</td>
</tr>
<tr>
<th>Modified</th>
<td>Sunday, 08 May, 2011 11:41:19</td>
</tr>
</table><h3 class="tags">Tags:</h3>
<ul class="tags">
<li>Design Standards</li>
</ul>
<h3 class="notes">Notes:</h3>
<ul class="notes">
<li id="i228">
<p>Stolley argues that "digital scholars" should create online work that
 is "free and open source" and "software- and device-independent". In 
particular, he argues against creating online texts using proprietary 
formats. Further, digital scholars should be able to talk about "the 
intricacies and methods of digital production". He extends this to a 
pedagogical argument: students should be taught these same values and 
knowledges.<br /><br />The model he advocates revolves around "lo-fi 
production technologies", which are distinguished by being compatible 
with a wide range of tools. For example, where feasible, they should use
 plain-text file formats so that they are human-readable and can be 
viewed and edited using any plain-text editing software. Dense media 
(audio, video, etc) that can't reasonably be encoded as plain text 
should use open formats.<br /><br />Stolley is careful to note that lo-fi technologies can produce "hi-fi" results, so expressive power isn't lost.</p>
<h3>Emphasize the Source</h3>
<p>Stolley is not directly concerned with the question of how deeply 
technical an HTML author should be for most of the piece, though his 
argument requires at least a theoretical understanding of technical 
issues. At times, though, he does refer to the question, for example 
when he suggests pedagogy should "emphasize the *source* in 'free and 
open source'".</p>
<h3>The LOFI Schema</h3>
<p>He augments his general appeal for lo-fi production with a 
more-specific theoretical schema represented by the acronym "LOFI": 
Lossless, Open, Flexible, and In(ter)dependent. The middle two terms 
should be familiar to practitioners, but the first and last may need 
some explanation. By "lossless" Stolley recommends production 
technologies that do not need to alter their constituent elements (text,
 images, etc) but "orchestrate" them for the audience; an example is how
 HTML documents include images by references to the original files, not 
by incorporating them into an opaque structure (as, for example, 
Microsoft Word does). Similarly, his "in(ter)dependent" refers to the 
affordances such orchestration gives users, who can decompose a lo-fi 
production into constituent elements, treating them differently or using
 them for new purposes.</p>
<h3>Minimal Manifesto</h3>
<p>"The Lo-Fi Manifesto" ends with its eponymous position statement - a 
set of six principles. (The presentation of the manifesto exemplifies 
Stolley's position: it uses scripting to expand each point into a longer
 discussion when, and if, the reader clicks on a claim. If the user has 
scripting disabled, or is using a UA that doesn't support it, the 
document degrades gracefully, by always showing the additional content. 
This combination would be difficult to achieve using proprietary tools.)<br /><br />Of those the first three are directly relevant to the question of "teaching the tech":</p>
<p>1. Software is a poor organizing principle for digital production.<br />2. Digital literacy should reach beyond the limits of software.<br />3. Discourse should not be trapped by production technologies.</p>
<ol> </ol>
<p>In different ways, all three recommend a turn away from tools that 
enfold, and thus inevitably limit, the possibilities offered by the 
technologies of digital discourse.</p>
</li>
</ul>
<h3 class="attachments">Attachments</h3>
<ul class="attachments">
<li id="i174">The Lo-Fi Manifesto</li>
</ul>
</li>


<li id="i229" class="item webpage">
<h2>What does "WYSIWYG" stand for?</h2>
<table>
<tr>
<th>Type</th>
<td>Web Page</td>
</tr>
<tr>
<th class="author">Author</th>
<td>Luke Franci</td>
</tr>
<tr>
<th>Website Title</th>
<td>What does "WYSIWYG" stand for? @jefflin explains. on Twitpic</td>
</tr>
<tr>
<th>URL</th>
<td>http://twitpic.com/4ur3as</td>
</tr>
<tr>
<th>Accessed</th>
<td>Sunday, 08 May, 2011 12:33:35</td>
</tr>
<tr>
<th>Date Added</th>
<td>Sunday, 08 May, 2011 12:33:35</td>
</tr>
<tr>
<th>Modified</th>
<td>Sunday, 08 May, 2011 13:59:20</td>
</tr>
</table><h3 class="notes">Notes:</h3>
<ul class="notes">
<li id="i231">
<p>Luke Franci's photo of a slide from a Jeff Lin presentation is a 
typical example of the hostility toward WYSIWYG tools in the tech 
community.</p>
</li>
</ul>
<h3 class="attachments">Attachments</h3>
<ul class="attachments">
<li id="i230">What does "WYSIWYG" stand for? @jefflin explains. on Twitpic</li>
</ul>
</li>


<li id="i232" class="item webpage">
<h2>The Future of the Book: Time to Learn Some HTML/CSS</h2>
<table>
<tr>
<th>Type</th>
<td>Web Page</td>
</tr>
<tr>
<th class="author">Author</th>
<td>Charlie Lowe</td>
</tr>
<tr>
<th>Website Title</th>
<td>Kairosnews</td>
</tr>
<tr>
<th>Date</th>
<td>2011-02-18</td>
</tr>
<tr>
<th>Short Title</th>
<td>The Future of the Book</td>
</tr>
<tr>
<th>URL</th>
<td><a href="http://kairosnews.org/the-future-of-the-book-html-css">http://kairosnews.org/the-future-of-the-book-html-css</a></td>
</tr>
<tr>
<th>Accessed</th>
<td>Sunday, 08 May, 2011 13:06:47</td>
</tr>
<tr>
<th>Date Added</th>
<td>Sunday, 08 May, 2011 13:06:47</td>
</tr>
<tr>
<th>Modified</th>
<td>Sunday, 08 May, 2011 13:07:58</td>
</tr>
</table><h3 class="notes">Notes:</h3>
<ul class="notes">
<li id="i234">
<p>In this short blog post, Lowe argues that because ebooks are expected
 to become the dominant book publishing format, and because epub (ebook 
publishing) standards rely on HTML for content, CSS for formatting, and 
XML for metadata, technical writers in particular will need to be fluent
 in those technologies. Lowe claims that existing tools do not handle 
epub well, and while they may be sufficient for ebooks with simple 
formatting requirements "like a novel", they are not suitable for 
technical publishing.</p>
</li>
</ul>
<h3 class="attachments">Attachments</h3>
<ul class="attachments">
<li id="i233">The Future of the Book: Time to Learn Some HTML/CSS | Kairosnews</li>
</ul>
</li>


<li id="i235" class="item journalArticle">
<h2>The Design of Web 2.0: The Rise of the Template, The Fall of Design</h2>
<table>
<tr>
<th>Type</th>
<td>Journal Article</td>
</tr>
<tr>
<th class="author">Author</th>
<td>Kristin L. Arola</td>
</tr>
<tr>
<th>Abstract</th>
<td>In a time when Web 2.0 technologies dominate web experiences, and 
when the media by and large sings the praises of the personal 
empowerment afforded by such technologies, it is important to bring a 
critical lens to the design of Web 2.0. Although there are many 
empowering and engaging features of user-driven content, this article 
explores the downside to template-driven design. Through tracing the 
decline of homepage web authoring (where users had control of visual 
design choices) alongside the rise of social networking sites (where 
users have little to no control over the visual design of their 
representation), I call for a renewed attention to the rhetoric of 
design.</td>
</tr>
<tr>
<th>Publication</th>
<td>Computers and Composition</td>
</tr>
<tr>
<th>Volume</th>
<td>27</td>
</tr>
<tr>
<th>Issue</th>
<td>1</td>
</tr>
<tr>
<th>Pages</th>
<td>4-14</td>
</tr>
<tr>
<th>Date</th>
<td>March 2010</td>
</tr>
<tr>
<th>DOI</th>
<td>10.1016/j.compcom.2009.11.004</td>
</tr>
<tr>
<th>ISSN</th>
<td>8755-4615</td>
</tr>
<tr>
<th>Short Title</th>
<td>The Design of Web 2.0</td>
</tr>
<tr>
<th>URL</th>
<td><a href="http://www.sciencedirect.com/science/article/B6W49-4Y8G1PH-2/2/3510a4a077f5d3aad056d3630d6420b0">http://www.sciencedirect.com/science/article/B6W49-4Y8G1PH-2/2/3510a4a077f5d3aad056d3630d6420b0</a></td>
</tr>
<tr>
<th>Accessed</th>
<td>Sunday, 08 May, 2011 13:58:48</td>
</tr>
<tr>
<th>Library Catalog</th>
<td>ScienceDirect</td>
</tr>
<tr>
<th>Date Added</th>
<td>Sunday, 08 May, 2011 13:58:48</td>
</tr>
<tr>
<th>Modified</th>
<td>Sunday, 08 May, 2011 13:59:38</td>
</tr>
</table><h3 class="tags">Tags:</h3>
<ul class="tags">
<li>Design template</li>
<li>Identity</li>
<li>Interface</li>
<li>Screen design</li>
<li>Social networking</li>
<li>Visual rhetoric</li>
<li>Web 2.0</li>
<li>Web design</li>
</ul>
<h3 class="notes">Notes:</h3>
<ul class="notes">
<li id="i241">
<p>Arola's position here is that excessive reliance on templates for 
creating web content, which she sees as particularly common with "Web 
2.0" sites that build pages by inserting content fragments into 
templates and dynamically-generated populated structures, reduces 
opportunities for design. The form/content split which has always been a
 theme of markup languages, at first because they separated content 
creation from separate rendering and presentation stages in the 
toolchain, and later as an explicit design principle; but, Arola argues,
 the increasing incorporation of layout templates and 
content-marshalling software in newer web applications has tended "to 
render form standard and invisible". To put it another way, Web 2.0 
encourages us to let our tools dictate the conventions of our genres. 
Arola characterizes this in various ways, such as a shift from 
"homepage" to "post" as the quintessential personal web contribution.</p>
<h3>Design, not Engineering</h3>
<p>This is an interesting tech-over-tools argument because it does not 
rely primarily on any of the usual claims or warrants. Arola does not 
found her position on technical correctness, browser compatibility, 
consistency for the sake of machine processing or alternative use (eg 
accessibility), or even engineering elegance and ideological purity 
(often present, if not so often acknowledged, among the warrants for the
 pro-tech side).</p>
<p>Instead, what is at stake here for Arola is design affordance. This 
is an aesthetic argument, and a rhetorical one, and a pedagogical one; 
and beneath all those, it is a question of creative freedom and 
individual choice - attributes that the cheerleaders of "new media" 
universally espouse.</p>
</li>
</ul>
<h3 class="attachments">Attachments</h3>
<ul class="attachments">
<li id="i236">ScienceDirect Full Text PDF</li>
<li id="i237">ScienceDirect Snapshot</li>
</ul>
</li>


<li id="i238" class="item webpage">
<h2>Road Trip</h2>
<table>
<tr>
<th>Type</th>
<td>Web Page</td>
</tr>
<tr>
<th class="author">Author</th>
<td>Lynda Rutledge Stephenson</td>
</tr>
<tr>
<th>Website Type</th>
<td>Text</td>
</tr>
<tr>
<th>Date</th>
<td>2011-01-15</td>
</tr>
<tr>
<th>URL</th>
<td><a href="http://kairos.technorhetoric.net/15.2/praxis/stephenson/index.html">http://kairos.technorhetoric.net/15.2/praxis/stephenson/index.html</a></td>
</tr>
<tr>
<th>Accessed</th>
<td>Sunday, 08 May, 2011 14:04:56</td>
</tr>
<tr>
<th>Date Added</th>
<td>Sunday, 08 May, 2011 14:04:56</td>
</tr>
<tr>
<th>Modified</th>
<td>Wednesday, 11 May, 2011 18:52:06</td>
</tr>
</table><h3 class="tags">Tags:</h3>
<ul class="tags">
<li>cyberliterature, e-lit, coding, templates, praxis</li>
</ul>
<h3 class="notes">Notes:</h3>
<ul class="notes">
<li id="i240">
<p>In "Road Map", the introductory autobiographical narrative process 
reflection for this piece, Stephenson explains how she developed her 
web-content creation process; largely self-taught, she was unaware of 
the existence of WYSIWYG tools. But citing Kristin Arola's "The Design 
of Web 2.0" (<em>q.v.</em>), she suggests that there is value in 
creating content directly with code. Though Stephenson claims she "is 
not nor ever will be a computer programmer, new media designer, or 
technology professor", she feels knowing some technical details is both 
intellectually and creatively rewarding.</p>
</li>
</ul>
<h3 class="attachments">Attachments</h3>
<ul class="attachments">
<li id="i239">Kairos 15.2: Stephenson, Road Trip- Home</li>
</ul>
</li>


<li id="i242" class="item presentation">
<h2>Mindful Design:  An Anishinaabe Approach to Multimedia Production</h2>
<table>
<tr>
<th>Type</th>
<td>Presentation</td>
</tr>
<tr>
<th class="presenter">Presenter</th>
<td>Kristin L. Arola</td>
</tr>
<tr>
<th>Date</th>
<td>2 May 2011</td>
</tr>
<tr>
<th>Place</th>
<td>Michigan State University, East Lansing</td>
</tr>
<tr>
<th>Short Title</th>
<td>Mindful Design</td>
</tr>
<tr>
<th>Date Added</th>
<td>Monday, 09 May, 2011 16:08:52</td>
</tr>
<tr>
<th>Modified</th>
<td>Monday, 09 May, 2011 16:09:59</td>
</tr>
</table><h3 class="notes">Notes:</h3>
<ul class="notes">
<li id="i243">
<p>In contrast to her 2010 "Design of Web 2.0" (<em>q.v.</em>), Arola 
made something of an argument against the strict-tech position in this 
presentation. It was a nuanced argument and presented as a suggestion 
rather than a thesis (and was only a small portion of a longer composite
 discussion); and it was not necessarily an argument for the use of 
tools to replace understanding of the technology. Nonetheless, it stands
 out both as a rare example of an expert in the area making some 
allowance for the use of black-box tooling, and as a complication and 
elaboration of her pro-tech position in the earlier work.</p>
<h3>WYSIWYG vs. Code</h3>
<p>In a relatively short interlude between two longer segments, Arola 
presented a copy of an IM conversation she'd had recently with her 
husband, as he helped her troubleshoot some issues with a page she was 
creating under some time pressure. She titled the interlude "wysiwyg vs.
 code", which is more or less an alternative form of the dichotomy this 
bibliography attempts to capture. And that's interesting, because from 
the content of the conversation that tension is not entirely apparent.</p>
<p>In the course of the conversation, Arola notes that some aspects of 
the page are not working correctly (link mouseovers, for example) 
despite the fact that the page "validates" - that is, it has been 
programmatically found to comply with (some version of) the HTML and 
other standards. A validator, while a "tool" in the generic sense, is 
typically used by white-box content creators, coders, those who believe 
in the importance of knowing the technology. Her husband corrects a 
usage (self-closing A tags) which validates but does not work (for 
reasons we need not get into here); be he also makes changes (removing 
empty paragraphs used for vertical spacing) which do not affect the 
correctness or appearance of the page, but are not approved of by web 
purists.</p>
<p>In other words, Arola's narrative in this segment is that despite her
 technical competence, she has deviated from the path of pure tech and 
employed a kluge - for which she is gently chided by her husband, here 
the voice of the pro-tech hard line.</p>
<h3>Git 'er done</h3>
<p>It is at this point, in Arola's subsequent reflection on her text, 
that the WYSIWYG tools reference becomes clear. Arola suggests that the 
coder ethos, know-the-tech ideological purity, can be an obstacle to 
simply creating and publishing content. And while that obstacle may be 
productive for many people, it can also be oppressive for those with 
more-limited access and resources. For such creators, or for creators 
who need to publish under otherwise less-than-ideal conditions, the 
reigning imperative may be to "git 'er done", as Arola puts it, and 
worry about correctness later.</p>
<p>Equally importantly, the endorsement of "right" and "wrong" ways to 
create viable content threatens to turn a technological regime into a 
moral one, and foreclose on the possibilities of other ways of 
conceiving of and using that technology. If there can indeed be an 
"Anishnaabe approach to design" on the web, we don't want to impede it 
by making a shibboleth of spacing paragraphs.</p>
</li>
</ul>
</li>


<li id="i244" class="item journalArticle">
<h2>Technical Writing as Textual Coordination: An Argument for the Value of Writers' Skill with Information Technology</h2>
<table>
<tr>
<th>Type</th>
<td>Journal Article</td>
</tr>
<tr>
<th class="author">Author</th>
<td>Shaun Slattery</td>
</tr>
<tr>
<th>Abstract</th>
<td>Slattery examines the core competencies of technical communication 
while foregrounding the role of mediating artifacts, the myriad of texts
 and the tools used to manipulate them. He describes the mediated 
writing practices of technical communicators and identifies some of 
their techniques of using mediating artifacts that might serve as a 
basis for discussing computer-mediated literate activity.</td>
</tr>
<tr>
<th>Publication</th>
<td>Technical Communication</td>
</tr>
<tr>
<th>Volume</th>
<td>52</td>
</tr>
<tr>
<th>Issue</th>
<td>3</td>
</tr>
<tr>
<th>Pages</th>
<td>353</td>
</tr>
<tr>
<th>Date</th>
<td>Aug 2005</td>
</tr>
<tr>
<th>ISSN</th>
<td>00493155</td>
</tr>
<tr>
<th>Short Title</th>
<td>Technical Writing as Textual Coordination</td>
</tr>
<tr>
<th>Library Catalog</th>
<td>ProQuest Legacy</td>
</tr>
<tr>
<th>Date Added</th>
<td>Wednesday, 11 May, 2011 18:19:25</td>
</tr>
<tr>
<th>Modified</th>
<td>Wednesday, 11 May, 2011 18:19:47</td>
</tr>
</table><h3 class="tags">Tags:</h3>
<ul class="tags">
<li>Core competencies</li>
<li>Information technology</li>
<li>Literacy</li>
<li>Skills</li>
<li>Technical communication</li>
</ul>
<h3 class="notes">Notes:</h3>
<ul class="notes">
<li id="i246">
<p>He does not explicitly address the question of tools versus tech, but
 Slattery indirectly makes an argument against pursuing that argument — 
at least against pursuing it too far.</p>
<p>Slattery describes an empirical study of technical communicators, with a view to understanding the "<em>relationship</em>
 between tool skill and ... higher-order competencies" such as cognitive
 skills and domain knowledge (353, emphasis in original). For Slattery's
 purposes here, technical knowledge of markup languages and facility 
with document-production applications are both types of "tools" in this 
relationship; he finds his subjects are required to use "a wide variety 
of IT" in various combinations in the course of their work.</p>
<p>This could be seen as an unwelcome conflation of core technologies 
and black-box tools that (depending on one's view) either obscure or 
instrumentalize them, or simply as neglecting the question of which is 
the royal road to technical document creation. But Slattery's final call
 to "help students develop a repertoire of information technologies and 
critical processes for selecting and using IT" (359) suggests the best 
approach might be to teach both tools and tech, and the critical insight
 to determine when to use each. Whether that's practical, of course, is 
another question.</p>
</li>
</ul>
<h3 class="attachments">Attachments</h3>
<ul class="attachments">
<li id="i245">Document View - ProQuest</li>
</ul>
</li>


<li id="i247" class="item journalArticle">
<h2>Technical communication, knowledge management, and XML</h2>
<table>
<tr>
<th>Type</th>
<td>Journal Article</td>
</tr>
<tr>
<th class="author">Author</th>
<td>J D Applen</td>
</tr>
<tr>
<th>Abstract</th>
<td>Applen describes how technical communicators can become involved in 
knowledge management. Applen examines how technical communicators can 
teach organizations to design, access, and contribute to databases; 
alert them to new information; and facilitate trust and sharing.</td>
</tr>
<tr>
<th>Publication</th>
<td>Technical Communication</td>
</tr>
<tr>
<th>Volume</th>
<td>49</td>
</tr>
<tr>
<th>Issue</th>
<td>3</td>
</tr>
<tr>
<th>Pages</th>
<td>301</td>
</tr>
<tr>
<th>Date</th>
<td>Aug 2002</td>
</tr>
<tr>
<th>ISSN</th>
<td>00493155</td>
</tr>
<tr>
<th>Library Catalog</th>
<td>ProQuest Legacy</td>
</tr>
<tr>
<th>Date Added</th>
<td>Wednesday, 11 May, 2011 18:31:36</td>
</tr>
<tr>
<th>Modified</th>
<td>Wednesday, 11 May, 2011 18:32:01</td>
</tr>
</table><h3 class="tags">Tags:</h3>
<ul class="tags">
<li>Extensible Markup Language</li>
<li>Knowledge management</li>
<li>Technical communication</li>
</ul>
<h3 class="notes">Notes:</h3>
<ul class="notes">
<li id="i249">
<p>Much of Applen's article is essentially theoretical, arguing for a 
perspective on knowledge management built from the sociology of science 
and sociological theories of knowledge organization. Based on this 
theory, however, Applen champions "XML code" (including cognate 
technologies such as XML DTDs, XLink, and XPointer) as ideal for the 
knowledge-management tasks that are bound up in technical communication.
 While Applen does not specifically address the tools-versus-tech issue,
 this proposal only works if technical communicators deal intimately 
with XML technology. Claims like "the very nature of XML allows 
technical communicators to think critically about knowledge" (311) imply
 that a key epistemological benefit is attached to knowing and working 
with the core technologies, rather than dealing exclusively with tools 
that abstract them.</p>
</li>
</ul>
<h3 class="attachments">Attachments</h3>
<ul class="attachments">
<li id="i248">Document View - ProQuest</li>
</ul>
</li>


<li id="i252" class="item journalArticle">
<h2>What do technical communicators need to know?</h2>
<table>
<tr>
<th>Type</th>
<td>Journal Article</td>
</tr>
<tr>
<th class="author">Author</th>
<td>George F Hayhoe</td>
</tr>
<tr>
<th>Publication</th>
<td>Technical Communication</td>
</tr>
<tr>
<th>Volume</th>
<td>47</td>
</tr>
<tr>
<th>Issue</th>
<td>2</td>
</tr>
<tr>
<th>Pages</th>
<td>151</td>
</tr>
<tr>
<th>Date</th>
<td>May 2000</td>
</tr>
<tr>
<th>ISSN</th>
<td>00493155</td>
</tr>
<tr>
<th>Library Catalog</th>
<td>ProQuest Legacy</td>
</tr>
<tr>
<th>Date Added</th>
<td>Wednesday, 11 May, 2011 18:54:38</td>
</tr>
<tr>
<th>Modified</th>
<td>Wednesday, 11 May, 2011 18:54:49</td>
</tr>
</table><h3 class="notes">Notes:</h3>
<ul class="notes">
<li id="i254">
<p>In this editorial, Hayhoe points to one of the issues that is often 
invoked in the tools/tech debate. On the one hand, he begins by 
dismissing fluency with specific tools from the category of "essential 
knowledge that all technical communicators must possess"; on the other, 
he admits that job listings "seldom list any other specific knowledge as
 a prerequisite" (151). Thus some instructors may advocate teaching 
tools purely as a pragmatic matter: their students need certain 
competencies to be employable.</p>
<p>Hayhoe later admits that tool knowledge, while "less important than 
communication skills and knowledge of subject domains", is still a 
necessary skill (152). At the same time, "we should not let the tools 
define us or distract us" (153), simply because knowledge of them is 
easier to measure. Ultimately, this piece is a mild argument for 
teaching tool skills, but one that qualifies that area as subordinate to
 what Slattery refers to as "higher-order competencies".</p>
</li>
</ul>
<h3 class="attachments">Attachments</h3>
<ul class="attachments">
<li id="i253">Document View - ProQuest</li>
</ul>
</li>


<li id="i255" class="item journalArticle">
<h2>The implications of single sourcing for technical communicators</h2>
<table>
<tr>
<th>Type</th>
<td>Journal Article</td>
</tr>
<tr>
<th class="author">Author</th>
<td>Joe D Williams</td>
</tr>
<tr>
<th>Abstract</th>
<td>Williams surveys four books that examine methods of single sourcing,
 including publishing tools, Extensible Markup Language, and content 
management systems. He reviews articles describing the role of writers 
and editors, the tool set and its implementation, and ways to make 
dynamic content more effective.</td>
</tr>
<tr>
<th>Publication</th>
<td>Technical Communication</td>
</tr>
<tr>
<th>Volume</th>
<td>50</td>
</tr>
<tr>
<th>Issue</th>
<td>3</td>
</tr>
<tr>
<th>Pages</th>
<td>321</td>
</tr>
<tr>
<th>Date</th>
<td>Aug 2003</td>
</tr>
<tr>
<th>ISSN</th>
<td>00493155</td>
</tr>
<tr>
<th>Library Catalog</th>
<td>ProQuest Legacy</td>
</tr>
<tr>
<th>Date Added</th>
<td>Wednesday, 11 May, 2011 19:04:43</td>
</tr>
<tr>
<th>Modified</th>
<td>Friday, 13 May, 2011 11:45:35</td>
</tr>
</table><h3 class="tags">Tags:</h3>
<ul class="tags">
<li>Technical communication</li>
<li>Writers</li>
</ul>
<h3 class="notes">Notes:</h3>
<ul class="notes">
<li id="i280">
<p>This is a literature review, and so is chiefly concerned with 
surveying the field rather than offering an original perspective. And 
the survey-article form doesn't give Williams much room to go into 
specific issues in depth; since his focus is single-sourcing, he only 
touches on some of the issues directly related to the question of tools 
and technologies.</p>
<h3>Points for Both Sides</h3>
<p>Nonetheless, those issues do come up several times. In reviewing Ann 
Rockley's work, for example, Williams describes a transition from 
"document-oriented to object-oriented" that also seems to imply a shift 
away from WYSIWYG tools, as it moves from "desktop publishing software" 
to "XML and a CMS" (321-322). It's not clear that understanding core 
technologies such as XML is <em>necessarily</em> part of following this 
shift — that this isn't simply a historical accident, where 
technology-abstracting authoring software simply had not (in 2003) 
caught up with the technologies used for single-sourcing. And Williams 
moves next to considering an approach described by Kurt Ament which, he 
says, "can be used with the most commonly used desktop publishing tools"
 (322). So at this point, and indeed for much of Williams' article, 
there's no clear advantage to tools or technological knowledge.</p>
<p>It's also worth noting that in reviewing Kevin Dick's <em>XML: A manager's guide</em>,
 Williams repeats without questioning Dick's claim that XML "requires a 
core set of skilled [software] developers with a thorough understanding 
of its mechanics". In fact, Williams elaborates on this idea, claiming 
that such developers will primarily be responsible for "creating a 
shared mental model and vocabulary" (323). It seems odd that Williams 
does not suggest this is a role that could be played by technical 
communicators; it's almost as if, at this point, he does not consider 
core technology a logical area for writers to be skilled in.</p>
<h3>The Technological Turn</h3>
<p>At this point, however, Williams turns to then-current articles 
specifically in technical communications on single sourcing, and there 
he finds a discernible turn toward technological expertise. He briefly 
cites Filipp Sapienza's recommendation to teachers and practitioners to 
become familiar with XML, for example. Most significantly, the final 
piece Williams reviews is the 2002 whitepaper "Modeling flexible 
document structures with XML schema" by Hart-Davidson, Moore, and Porter
 (<em>q.v.</em>), from which he derives his final recommendation: "If 
educators and practitioners of technical communication were to refine 
such rhetorically grounded 'homegrown' single sourcing solutions as 
Hart-Davidson, Moore, and Porter describe, I believe that many of the 
benefits of single sourcing and content management could be realized" 
(326). Since the approach described in "Modeling flexible document 
structures" is thoroughly technological — an XML schema informed by 
rhetorical theory — it's hard to see this as anything other than an 
endorsement of technological expertise by Williams as the royal road to 
dealing with the imperatives of single sourcing.</p>
</li>
</ul>
<h3 class="attachments">Attachments</h3>
<ul class="attachments">
<li id="i256">Document View - ProQuest</li>
</ul>
</li>


<li id="i257" class="item journalArticle">
<h2>Single source in practice: IBM's SGML toolset and the writer as technologist, problem solver, and editor</h2>
<table>
<tr>
<th>Type</th>
<td>Journal Article</td>
</tr>
<tr>
<th class="author">Author</th>
<td>Robert Kramer</td>
</tr>
<tr>
<th>Abstract</th>
<td>The promise of single sourcing has been the simplification of the 
technical writer's work through the streamlining of the technical 
process and the creation of dynamic, multi-author teams. Kramer 
describes how single sourcing adds layers of complexity, problem 
solving, and project management to the task of writers. He claims that 
single sourcing is often a response to a documentation requirement for 
the market, not to the writer's need for less complex tools.</td>
</tr>
<tr>
<th>Publication</th>
<td>Technical Communication</td>
</tr>
<tr>
<th>Volume</th>
<td>50</td>
</tr>
<tr>
<th>Issue</th>
<td>3</td>
</tr>
<tr>
<th>Pages</th>
<td>328</td>
</tr>
<tr>
<th>Date</th>
<td>Aug 2003</td>
</tr>
<tr>
<th>ISSN</th>
<td>00493155</td>
</tr>
<tr>
<th>Short Title</th>
<td>Single source in practice</td>
</tr>
<tr>
<th>Library Catalog</th>
<td>ProQuest Legacy</td>
</tr>
<tr>
<th>Date Added</th>
<td>Wednesday, 11 May, 2011 19:05:31</td>
</tr>
<tr>
<th>Modified</th>
<td>Friday, 13 May, 2011 11:45:41</td>
</tr>
</table><h3 class="tags">Tags:</h3>
<ul class="tags">
<li>Technical communication</li>
<li>Writers</li>
</ul>
<h3 class="notes">Notes:</h3>
<ul class="notes">
<li id="i275">
<p>Kramer's focus is not the question of knowing core technologies or 
possessing fluency with tools that abstract them. If anything, his 
argument is that in a single-sourcing environment, technical writers 
need both kinds of knowledge; drawing on IBM's documentation production 
as an extended example, he argues that under single sourcing the writer 
becomes even more of a technologist, and must be an expert user of a 
wide range of technologies and tools, many of which are not directly 
related to producing written content.</p>
<p>But in the kind of environment Kramer describes, at least tools of 
the WYSIWYG variety have little place, in part because of the increased 
distance between content production and document layout. "Semantic" 
markup languages like the IBM SGML toolset Kramer describes or various 
other DITA-based approaches are the antithesis of black-box WYSIWYG 
tools — authors don't deal with formatting at all. While it's certainly 
possible to have GUI authoring tools for semantic-style markup that 
avoid having to work with the actual markup code, users of such tools 
would still be working with a vocabulary and document model that refer 
to document elements, not appearance.</p>
<p>In this sense, Kramer's description of working in a single-source 
environment is an argument for teaching markup technology as a <em>fait accompli</em>: writers who work in such environments will have no choice but to understand the core technologies.</p>
</li>
</ul>
<h3 class="attachments">Attachments</h3>
<ul class="attachments">
<li id="i258">Document View - ProQuest</li>
</ul>
</li>


<li id="i259" class="item journalArticle">
<h2>On writing, technical communication, and information technology: The core competencies of technical communication</h2>
<table>
<tr>
<th>Type</th>
<td>Journal Article</td>
</tr>
<tr>
<th class="author">Author</th>
<td>William Hart-Davidson</td>
</tr>
<tr>
<th>Abstract</th>
<td>Hart-Davidson argues that writing is the core technology that all 
information technology (IT) systems attempt to leverage to make these 
systems more valuable. He also argues that technical communicators have a
 central role to play in IT systems consonant with their core 
competencies.</td>
</tr>
<tr>
<th>Publication</th>
<td>Technical Communication</td>
</tr>
<tr>
<th>Volume</th>
<td>48</td>
</tr>
<tr>
<th>Issue</th>
<td>2</td>
</tr>
<tr>
<th>Pages</th>
<td>145</td>
</tr>
<tr>
<th>Date</th>
<td>May 2001</td>
</tr>
<tr>
<th>ISSN</th>
<td>00493155</td>
</tr>
<tr>
<th>Short Title</th>
<td>On writing, technical communication, and information technology</td>
</tr>
<tr>
<th>Library Catalog</th>
<td>ProQuest Legacy</td>
</tr>
<tr>
<th>Date Added</th>
<td>Wednesday, 11 May, 2011 19:13:41</td>
</tr>
<tr>
<th>Modified</th>
<td>Wednesday, 11 May, 2011 19:14:06</td>
</tr>
</table><h3 class="tags">Tags:</h3>
<ul class="tags">
<li>Information technology</li>
<li>Professional responsibilities</li>
<li>Technical communication</li>
<li>Writing</li>
</ul>
<h3 class="notes">Notes:</h3>
<ul class="notes">
<li id="i261">
<p>In a special issue where several of the authors lament a focus on 
tools in the technical-communication workplace, literature, etc., and 
the rapid turnover in tools for technical communication, Hart-Davidson 
offers an interesting innovation. The question for him is not to what 
extent technical communicators should be consuming tools, or what sort 
of tools they should be consuming, but whether they should be actively 
involved in <em>producing</em> those tools. (Hart-Davidson's answer, unsurprisingly, is yes.)</p>
<h3>Theory and Practice</h3>
<p>Perhaps surprisingly, this practical conclusion arises from a call 
for theory — specifically, a theory of technical communication and its 
"orientation to our work with information technology", with the specific
 goal of "mak[ing] leadership in the IT field seem reasonable, possible,
 and desirable" (146). This is in large part a rhetorical move: it 
establishes grounds for recognizing the roles technical communication 
plays in knowledge and data management, decision making, and so forth. 
It is also a call to demystify concepts such as "talent" which are 
impossible to measure, and to make "the core expertise of technical 
communication explicit" (147).</p>
<p>From this starting point, Hart-Davidson adopts some of Derrida's 
central ideas to show, first, that writing is an information technology,
 and thus that technical communicators are already technological 
experts; and second, that theory need not be abstruse, difficult, and 
disconnected from everyday practice.</p>
<h3>Technical Gardens</h3>
<p>Hart-Davidson ends with an extended metaphor of "gardening" in the 
domain of technical-communication technologies. Treating the collection 
of technologies and information tasks as an ecology, he suggests that 
technical communicators can move between technologies <em>per se</em> 
and their applications in the workplace, improving both in the process. 
The most desirable outcome of such a stance is that workplaces would 
develop their own IT suited to their particular situations, and 
technical communicators would be an intimate part of that process.</p>
<h3>Tools and Tech Stewardship</h3>
<p>This might not seem, at first blush, to be especially relevant to the
 tools-versus-tech argument; if anything, it appears to take a more or 
less holistic view of both core technologies and the tools constructed 
atop them as co-participants in the IT ecology.</p>
<p>I would suggest, though, that for technical communicators to really 
participate in the creation of IT tools, they'll need to be conversant 
in the core technologies involved. Furthermore, I believe that if we are
 to have a rigorous theory of technical communication under a regime of 
complex information technologies, that theory cannot be satisfied with 
black-box tools; it will have to inquire into their inner workings, 
which again implies an understanding of core technology.</p>
</li>
</ul>
<h3 class="attachments">Attachments</h3>
<ul class="attachments">
<li id="i260">Document View - ProQuest</li>
</ul>
</li>


<li id="i262" class="item journalArticle">
<h2>From Writer to Designer: Modeling Composing Processes in a Hypertext Environment.</h2>
<table>
<tr>
<th>Type</th>
<td>Journal Article</td>
</tr>
<tr>
<th class="author">Author</th>
<td>Beverly Kolosseus</td>
</tr>
<tr>
<th class="author">Author</th>
<td>Dan Bauer</td>
</tr>
<tr>
<th class="author">Author</th>
<td>Stephen A. Bernhardt</td>
</tr>
<tr>
<th>Publication</th>
<td>Technical Communication Quarterly</td>
</tr>
<tr>
<th>Volume</th>
<td>4</td>
</tr>
<tr>
<th>Issue</th>
<td>1</td>
</tr>
<tr>
<th>Pages</th>
<td>79-93</td>
</tr>
<tr>
<th>Date</th>
<td>Jan 1995</td>
</tr>
<tr>
<th>Language</th>
<td>English</td>
</tr>
<tr>
<th>ISSN</th>
<td>1057-2252</td>
</tr>
<tr>
<th>Short Title</th>
<td>From Writer to Designer</td>
</tr>
<tr>
<th>Library Catalog</th>
<td>ERIC</td>
</tr>
<tr>
<th>Date Added</th>
<td>Friday, 13 May, 2011 11:39:41</td>
</tr>
<tr>
<th>Modified</th>
<td>Saturday, 21 May, 2011 01:15:14</td>
</tr>
</table><h3 class="tags">Tags:</h3>
<ul class="tags">
<li>Higher Education</li>
</ul>
<h3 class="notes">Notes:</h3>
<ul class="notes">
<li id="i287">
<p>This relatively early piece (the Web had only been around for about 
five years when it was written; the W3C had only just been formed) 
discusses hypertext composition using a now-obsolete proprietary system.
 For my purposes, what's interesting about the article is its emphasis 
on the different and far more complex process of composing hypertext 
documents, as compared to writing linear prose. Kolosseus <em>et al.</em>
 emphasize that hypertext composition is not like using a conventional 
word processor. We see here that even in 1995, technical communicators 
were aware of the complexities of hypertext authoring and the 
deficiencies of the word-processing WYSIWYG model for it.</p>
<p>bibkey:kolosseusbernhardt</p>
</li>
</ul>
<h3 class="attachments">Attachments</h3>
<ul class="attachments">
<li id="i264">Kolosseus.pdf</li>
<li id="i263">ProQuest HTML</li>
</ul>
</li>


<li id="i265" class="item journalArticle">
<h2>Toward a Post-Technê-Or, Inventing Pedagogies for Professional Writing</h2>
<table>
<tr>
<th>Type</th>
<td>Journal Article</td>
</tr>
<tr>
<th class="author">Author</th>
<td>Byron Hawk</td>
</tr>
<tr>
<th>Publication</th>
<td>Technical Communication Quarterly</td>
</tr>
<tr>
<th>Volume</th>
<td>13</td>
</tr>
<tr>
<th>Issue</th>
<td>4</td>
</tr>
<tr>
<th>Pages</th>
<td>371-392</td>
</tr>
<tr>
<th>Date</th>
<td>Autumn 2004</td>
</tr>
<tr>
<th>Language</th>
<td>English</td>
</tr>
<tr>
<th>ISSN</th>
<td>10572252</td>
</tr>
<tr>
<th>Library Catalog</th>
<td>ABI/INFORM Complete</td>
</tr>
<tr>
<th>Rights</th>
<td>Copyright Association of Teachers of Technical Writing Autumn 2004</td>
</tr>
<tr>
<th>Date Added</th>
<td>Friday, 13 May, 2011 11:45:11</td>
</tr>
<tr>
<th>Modified</th>
<td>Friday, 13 May, 2011 11:45:11</td>
</tr>
</table><h3 class="tags">Tags:</h3>
<ul class="tags">
<li>Education</li>
<li>Technical communication</li>
<li>Writing instruction</li>
</ul>
<h3 class="notes">Notes:</h3>
<ul class="notes">
<li id="i285">
<p>Hawk does not discuss web tools or technologies in this piece. What he presents here is a theory of <em>technê</em>, and specifically what he calls "post-<em>technê</em>", which he defines as "the combination of technique, the technical, technology, and <em>technê</em>
 that is grounded in posthumanism" (389). Hawk's pedagogical proposal is
 to rethink the relationships between human actors and their 
technological milieu and teach students to approach each rhetorical 
situation as an occasion for investigation, critical reflection, and 
invention.</p>
<p>As such, Hawk's theory points to one way of escaping dichotomies such
 as tools/technologies; in his scheme, both core web technologies and 
packaged tools that abstract from those technologies possess the aspects
 he calls "technique" (which includes strategies and methods), the 
"technical" (whatever is "both ordered and complex"), "technology" 
(abstractions and their relations), and <em>technê</em> (the 
"combination of art and technology in productive knowledge"). As noted 
above, it is the combination of these four aspects in a posthumanist 
regime that forms Hawk's post-<em>technê</em> (389).</p>
<p>Ideally, a rhetor following Hawk's model would be able to deploy web 
technologies and tools in a kairotic fashion, as appropriate for each 
situation, and do so in terms of a philosophically robust understanding 
of how those constituents interact in the "constellation" of a 
rhetorical response.</p>
</li>
</ul>
<h3 class="attachments">Attachments</h3>
<ul class="attachments">
<li id="i266">ProQuest PDF</li>
</ul>
</li>


<li id="i267" class="item journalArticle">
<h2>The Impact of the Internet and Digital Technologies on Teaching and Research in Technical Communication</h2>
<table>
<tr>
<th>Type</th>
<td>Journal Article</td>
</tr>
<tr>
<th class="author">Author</th>
<td>Laura J Gurak</td>
</tr>
<tr>
<th class="author">Author</th>
<td>Ann Hill Duin</td>
</tr>
<tr>
<th>Publication</th>
<td>Technical Communication Quarterly</td>
</tr>
<tr>
<th>Volume</th>
<td>13</td>
</tr>
<tr>
<th>Issue</th>
<td>2</td>
</tr>
<tr>
<th>Pages</th>
<td>187-198</td>
</tr>
<tr>
<th>Date</th>
<td>Spring 2004</td>
</tr>
<tr>
<th>Language</th>
<td>English</td>
</tr>
<tr>
<th>ISSN</th>
<td>10572252</td>
</tr>
<tr>
<th>Library Catalog</th>
<td>ABI/INFORM Complete</td>
</tr>
<tr>
<th>Rights</th>
<td>Copyright Association of Teachers of Technical Writing Spring 2004</td>
</tr>
<tr>
<th>Date Added</th>
<td>Friday, 13 May, 2011 11:46:52</td>
</tr>
<tr>
<th>Modified</th>
<td>Saturday, 21 May, 2011 01:02:42</td>
</tr>
</table><h3 class="tags">Tags:</h3>
<ul class="tags">
<li>Colleges &amp; universities</li>
<li>Impact analysis</li>
<li>Internet</li>
<li>Research</li>
<li>Teaching</li>
<li>Technical communication</li>
</ul>
<h3 class="notes">Notes:</h3>
<ul class="notes">
<li id="i279">
<p>This essay is primarily concerned with the relationship between 
academia and industry, and how it affects and should affect the teaching
 of technical communication. But Gurak and Duin do have a brief 
discussion of problems with tool-oriented pedagogy:</p>
<blockquote>[W]e used to say that it was acceptable to teach a specific 
tool and expect students to then learn the tool of choice when they got 
on the job. However, our programs cannot afford to become comfortable 
with one product ... [W]e must work harder to keep up (or lead!) in the 
classroom by offering courses that provide both the theoretical overview
 of an issue (theories of single sourcing and tag languages, for 
example) and also the hands-on training on tools that help students 
understand industry standards. (189)</blockquote>
<p>This is interesting in this context for a couple of reasons. First, 
it takes a somewhat stronger line against the "representative tools" 
argument sometimes used to justify the tool-oriented pedagogy, even 
though it does not go entirely over to the tech-oriented side. The 
second is that the authors contrast tool skills with "theories", 
including those of "tag languages", without suggesting that students 
could actually <em>use</em> the latter! There is an odd reluctance here to simply call for practical experience in web core technologies.</p>
<p>bibkey:guraktheimpactofthein</p>
</li>
</ul>
<h3 class="attachments">Attachments</h3>
<ul class="attachments">
<li id="i268">ProQuest PDF</li>
</ul>
</li>


<li id="i269" class="item journalArticle">
<h2>Worlds within which we teach: Issues for designing World Wide Web course material</h2>
<table>
<tr>
<th>Type</th>
<td>Journal Article</td>
</tr>
<tr>
<th class="author">Author</th>
<td>Mary F O'Sullivan</td>
</tr>
<tr>
<th>Publication</th>
<td>Technical Communication Quarterly</td>
</tr>
<tr>
<th>Volume</th>
<td>8</td>
</tr>
<tr>
<th>Issue</th>
<td>1</td>
</tr>
<tr>
<th>Pages</th>
<td>61</td>
</tr>
<tr>
<th>Date</th>
<td>Winter 1999</td>
</tr>
<tr>
<th>Language</th>
<td>English</td>
</tr>
<tr>
<th>ISSN</th>
<td>10572252</td>
</tr>
<tr>
<th>Short Title</th>
<td>Worlds within which we teach</td>
</tr>
<tr>
<th>Library Catalog</th>
<td>ABI/INFORM Complete</td>
</tr>
<tr>
<th>Rights</th>
<td>Copyright Association of Teachers of Technical Writing Winter 1999</td>
</tr>
<tr>
<th>Date Added</th>
<td>Friday, 13 May, 2011 11:48:55</td>
</tr>
<tr>
<th>Modified</th>
<td>Friday, 13 May, 2011 11:48:55</td>
</tr>
</table><h3 class="notes">Notes:</h3>
<ul class="notes">
<li id="i286">
<p>Though O'Sullivan's topic here is approaches to developing online 
courseware, not the question of what to teach technical communicators, 
her piece is a good example of the classic tech-over-tools argument. She
 looks at various "course-in-a-box" packages, and while she notes 
various useful aspects — instructors can create courseware quickly; 
non-technical instructors may actually have better control over a site 
created with course-in-the-box software than if they have to work with 
university IT — she ultimately concludes that "creating online 
instructional sties by hand ... is preferable to using course-in-a-box 
software" because the latter is constrained, and that course-creation 
"software should be seen only as a stepping stone" (70).</p>
</li>
</ul>
<h3 class="attachments">Attachments</h3>
<ul class="attachments">
<li id="i270">ProQuest PDF</li>
</ul>
</li>


<li id="i273" class="item journalArticle">
<h2>The technical editor and document databases: What the future may hold</h2>
<table>
<tr>
<th>Type</th>
<td>Journal Article</td>
</tr>
<tr>
<th class="author">Author</th>
<td>Michael J Albers</td>
</tr>
<tr>
<th>Publication</th>
<td>Technical Communication Quarterly</td>
</tr>
<tr>
<th>Volume</th>
<td>9</td>
</tr>
<tr>
<th>Issue</th>
<td>2</td>
</tr>
<tr>
<th>Pages</th>
<td>191</td>
</tr>
<tr>
<th>Date</th>
<td>Spring 2000</td>
</tr>
<tr>
<th>Language</th>
<td>English</td>
</tr>
<tr>
<th>ISSN</th>
<td>10572252</td>
</tr>
<tr>
<th>Short Title</th>
<td>The technical editor and document databases</td>
</tr>
<tr>
<th>Library Catalog</th>
<td>ABI/INFORM Complete</td>
</tr>
<tr>
<th>Rights</th>
<td>Copyright Association of Teachers of Technical Writing Spring 2000</td>
</tr>
<tr>
<th>Date Added</th>
<td>Friday, 13 May, 2011 11:50:54</td>
</tr>
<tr>
<th>Modified</th>
<td>Friday, 13 May, 2011 11:50:54</td>
</tr>
</table><h3 class="notes">Notes:</h3>
<ul class="notes">
<li id="i284">
<p>Albers is concerned with changes in the role of the technical editor 
that follow from a shift from monolithic documents to dynamic documents 
assembled from a content fragment database. This would seem tangential 
to the tools/tech debate, and in fact that debate does not appear in his
 argument -- until a few paragraphs into the final section, on 
pedagogical recommendations.</p>
<p>There, Albers inserts the following comment: "The rapid changes 
inherent in the XML and intranet tool market prohibit the attempt to 
teach tools, which has always been a bad idea anyway" (202). This is 
more or less an aside, not directly connected to anything in its 
immediate context. Nor does Albers return to the idea.</p>
<p>What's interesting here is how this interjection simply appears as an
 unsupported claim in the midst of a series of pedagogical 
recommendations, the rest of which are quite focused and follow directly
 from Albers' preceding discussion. It's symptomatic of the strong views
 some authors hold on the question of whether to teach tooling or 
underlying technology.</p>
</li>
</ul>
<h3 class="attachments">Attachments</h3>
<ul class="attachments">
<li id="i274">ProQuest PDF</li>
</ul>
</li>


<li id="i276" class="item journalArticle">
<h2>Thinking Critically about Technological Literacy: Developing a Framework To Guide Computer Pedagogy in Technical Communication.</h2>
<table>
<tr>
<th>Type</th>
<td>Journal Article</td>
</tr>
<tr>
<th class="author">Author</th>
<td>Lee-Ann Kastman Breuch</td>
</tr>
<tr>
<th>Publication</th>
<td>Technical Communication Quarterly</td>
</tr>
<tr>
<th>Volume</th>
<td>11</td>
</tr>
<tr>
<th>Issue</th>
<td>3</td>
</tr>
<tr>
<th>Pages</th>
<td>267-288</td>
</tr>
<tr>
<th>Date</th>
<td>Jul 2002</td>
</tr>
<tr>
<th>Language</th>
<td>English</td>
</tr>
<tr>
<th>ISSN</th>
<td>1057-2252</td>
</tr>
<tr>
<th>Short Title</th>
<td>Thinking Critically about Technological Literacy</td>
</tr>
<tr>
<th>Library Catalog</th>
<td>ERIC</td>
</tr>
<tr>
<th>Date Added</th>
<td>Saturday, 14 May, 2011 16:26:01</td>
</tr>
<tr>
<th>Modified</th>
<td>Saturday, 14 May, 2011 16:26:17</td>
</tr>
</table><h3 class="tags">Tags:</h3>
<ul class="tags">
<li>Higher Education</li>
<li>Technical communication</li>
</ul>
<h3 class="notes">Notes:</h3>
<ul class="notes">
<li id="i278">
<p>Breuch frames her discussion of "technological literacy" by defining 
it in terms of the tools-versus-technology debate. In her first 
paragraph, she describes a conversation at an academic/industry 
colloquium: "Interestingly enough, after some discussion industry 
partners unanimously agreed that there were no specific 'tools' that 
students should learn ... [but] they collectively voiced the expectation
 that students understand technologies and have the aptitude to learn 
them quickly" (267-268). It is this latter qualification that Breuch 
glosses as "technological literacy".</p>
<h3>Insufficient but Necessary</h3>
<p>In elaborating this point, Breuch cautions against a pedagogical 
overemphasis on tools, which she sees as arising from an early 
understanding of technological literacy as performance, or "how to use a
 computer". Besides the practical problems associated with a 
tools-oriented pedagogy — tool skills are narrow, and it's infeasible to
 keep updating labs with the latest tools — she agrees with a number of 
other scholars that such an approach tends to present technology in a 
neutral and uncritical fashion: "many scholars argue that a tools-based 
stance is dangerous because it suggests that technology is not 
problematic and does not require the involvement of instructors, 
students, or communicators employing the technology" (271).</p>
<p>On the other hand, Breuch sees some tool instruction as essential. 
She reports that industry partners want students to have some 
familiarity with tools so they know what kinds of facilities are 
available, and concludes that students should be exposed to at least one
 software package of each of several types, including "Web authoring" 
(271). In this sense, while Breuch argues against a strongly 
tool-oriented pedagogy, she does explicitly advocate for limited 
teaching of tools — which is more than she has to say about teaching 
underlying web technologies such as HTML. Teaching the tools may be 
insufficient, in Breuch's view, but it is also apparently necessary.</p>
<h3>Beyond Tools</h3>
<p>But this is only a small part of Breuch's vision for 
technology-literacy pedagogy. Far more important in her view is teaching
 the context of technology: political, social, cultural, economic, and 
other valences, seen through a critical gaze. As she puts it after 
reviewing the literature, "scholarship suggests we should consider 
context a great deal" (273). And among the questions she suggests for 
such a critical review of technological context is that of which tools 
are used and why, which in effect could bring the tools/tech debate into
 the classroom. Similarly, she suggests that questions of how technology
 affects our reading and writing practices and how we communicate should
 be part of the curriculum.</p>
<p>Breuch's final and broadest recommendation is that all of the 
perspectives she describes be brought together in concert in formulating
 pedagogy for computer-oriented technical communication. "I break with 
scholars who promote one issue of technological literacy over others", 
she writes (276); while this may sound so reasonable as to be hardly 
worth mentioning, a moment's reflection shows that it is indeed a break 
with many of the other participants in this debate. And by declaring "<em>pedagogy must drive technology</em>"
 (278, emphasis in original), rather than the other way around, she to 
some extent implicitly critiques the very basis of debates like tools 
versus technology.</p>
</li>
</ul>
<h3 class="attachments">Attachments</h3>
<ul class="attachments">
<li id="i277">ProQuest PDF</li>
</ul>
</li>


<li id="i281" class="item document">
<h2>Modeling Flexible Document Structures with XML Schema: Rhetorical Objects and Rhetorical Metadata</h2>
<table>
<tr>
<th>Type</th>
<td>Document</td>
</tr>
<tr>
<th class="author">Author</th>
<td>William Hart-Davidson</td>
</tr>
<tr>
<th class="author">Author</th>
<td>Victoria Moore</td>
</tr>
<tr>
<th class="author">Author</th>
<td>Joshua Porter</td>
</tr>
<tr>
<th>Abstract</th>
<td>With the adoption of eXtensible Markup Language (XML) on the rise, 
researchers in academia and industry are seeking to leverage the 
descriptive power of metadata to better understand the semantic 
structure of
information (e.g., see Berners-Lee, 1998). But most
interaction on the World Wide Web is what Geisler (2001)
calls “document-centered,” involving the exchange of
discourse a great deal larger and more complex than the
basic units of meaning that semantics deals effectively
with. As a result, the tools of semantics fall short of
providing adequate metadata schemes which capture the
most compelling features of effective discourse in any
medium: emotional and ethical appeals which work in
conjunction with appropriate logical and semantic
structures.</td>
</tr>
<tr>
<th>Date</th>
<td>2003-01-01</td>
</tr>
<tr>
<th>Language</th>
<td>English</td>
</tr>
<tr>
<th>Short Title</th>
<td>Modeling Flexible Document Structures with XML Schema</td>
</tr>
<tr>
<th>URL</th>
<td><a href="http://replay.web.archive.org/20030426201230/http://www.rpi.edu/%7Ehartdw/ro.whitepaper.pdf">http://replay.web.archive.org/20030426201230/http://www.rpi.edu/~hartdw/ro.whitepaper.pdf</a></td>
</tr>
<tr>
<th>Rights</th>
<td>Copyright © 2008 by EServer.org. All rights reserved.</td>
</tr>
<tr>
<th>Date Added</th>
<td>Saturday, 14 May, 2011 19:51:53</td>
</tr>
<tr>
<th>Modified</th>
<td>Saturday, 21 May, 2011 01:30:03</td>
</tr>
</table><h3 class="notes">Notes:</h3>
<ul class="notes">
<li id="i283">
<p>This whitepaper (unfortunately now somewhat difficult to find; as the
 URL above indicates, I had to resort to the Internet Archive's Wayback 
Machine to locate a copy) does not explicitly address the 
tools-versus-tech debate. What it <em>does</em> do is demonstrate a 
compelling argument against focusing exclusively on tools, because the 
work it describes -- creating an XML schema informed by rhetorical 
theory -- requires an understanding of the underlying technology.</p>
<p>Tools that abstract away from the underlying technology limit their 
users to the domain of those abstractions. Ideally those tools offer 
other affordances and efficiencies beyond those available by 
manipulating the core technologies directly; that's the benefit that 
justifies the tools' cost. But there will always be innovative projects 
like this one which begin by positing new uses of the technologies, and 
consequently cannot be expressed in tools that did not anticipate such 
uses when their abstractions were formulated.</p>
<p>bibkey:hartdavidsonmodelingflexibledo</p>
</li>
</ul>
<h3 class="attachments">Attachments</h3>
<ul class="attachments">
<li id="i282">WHD-XML-modeling.pdf<div class="note"><p>In this whitepaper --</p>
</div></li>
</ul>
</li>


<li id="i288" class="item email">
<table>
<tr>
<th>Type</th>
<td>E-mail</td>
</tr>
<tr>
<th class="author">Author</th>
<td>Shaun Slattery</td>
</tr>
<tr>
<th>Subject</th>
<td>Re: [techrhet] do HTML authors need to know HTML?</td>
</tr>
<tr>
<th>Date</th>
<td>2011-02-19</td>
</tr>
<tr>
<th>Date Added</th>
<td>Saturday, 21 May, 2011 13:48:33</td>
</tr>
<tr>
<th>Modified</th>
<td>Saturday, 21 May, 2011 13:49:21</td>
</tr>
</table><h3 class="notes">Notes:</h3>
<ul class="notes">
<li id="i289">
<p>In response to my query on the TECHRHET list regarding this topic, 
Slattery explained that while he is largely in agreement with Karl 
Stolley (<em>q.v.</em>), he is also "firmly in the both/and camp". Referring to his own "Technical Writing as Textual Coordination" (<em>q.v.</em>),
 Slattery suggests that technical communicators need to learn various 
"genres of software", and WYSIWYG HTML tools are among those genres. 
Thus there is a practical need to be acquainted with them, even if from a
 theoretical perspective they're somewhat lacking.</p>
<p>Slattery also notes in passing that because students and professional
 technical communicators often need to use content-management systems 
and template-based website software, teaching such systems in 
conjunction with web technologies and theory can better enable students 
to respond critically to them.</p>
<p>bibkey:slatteryretechrhetdoht</p>
</li>
</ul>
</li>


<li id="i290" class="item journalArticle">
<h2>Teachers Learning (Not Teaching) HTML With Students: An Experimental
 Lesson Plan for Introducing Web Authoring Into Writing Classes</h2>
<table>
<tr>
<th>Type</th>
<td>Journal Article</td>
</tr>
<tr>
<th class="author">Author</th>
<td>Steven D. Krause</td>
</tr>
<tr>
<th>Abstract</th>
<td>Web browsing software like Netscape has been widely available since 
about 1993, and I suspect all but the most devout of modern day Luddites
 in English departments have spent at least some time surfing the Web. 
However, all but a few enthusiasts in English departments have stayed 
away from creating Web pages of their own. While inadequate access to 
the proper computer accounts necessary for supporting Web pages remains a
 significant barrier for many teachers and students (a problem I will 
discuss in some detail in this essay), I suspect that many English 
teachers and scholars haven’t created their own Web pages or 
incorporated Web page composition into their pedagogy simply because 
they don’t know how. And when told that all Web pages are based on 
something called Hyper-Text Mark-up Language (HTML), many undoubtedly 
assume that this must be a complicated and impossible to understand 
computer language, certainly something well beyond the grasp of someone 
with no computer programming experience. The experimental lesson plan I 
describe in this essay is based on my belief and experience that this 
assumption is not true. Simply put, creating modest Web pages with text,
 links, and a few graphics is actually quite easy. It can be taught by 
teachers who are reasonably comfortable working with their computers and
 who are willing to learn more, and it can be learned by students with 
no previous experience.</td>
</tr>
<tr>
<th>Publication</th>
<td>Readerly/Writerly Texts</td>
</tr>
<tr>
<th>Volume</th>
<td>7</td>
</tr>
<tr>
<th>Issue</th>
<td>1</td>
</tr>
<tr>
<th>Pages</th>
<td>113-128</td>
</tr>
<tr>
<th>Date</th>
<td>Fall/Winter 1999</td>
</tr>
<tr>
<th>URL</th>
<td><a href="http://www.readerly-writerlytexts.com/RW_FW_99_Index.htm">http://www.readerly-writerlytexts.com/RW_FW_99_Index.htm</a></td>
</tr>
<tr>
<th>Date Added</th>
<td>Saturday, 21 May, 2011 14:09:54</td>
</tr>
<tr>
<th>Modified</th>
<td>Saturday, 21 May, 2011 14:12:10</td>
</tr>
</table><h3 class="notes">Notes:</h3>
<ul class="notes">
<li id="i291">
<p>Another early tangential contributor to (or precursor of) the debate,
 this piece by Krause is of interest mostly because it suggests some 
advantages to both students and instructors in learning HTML. As such it
 lays some of the groundwork that appears in later arguments in favor of
 learning core web technologies.</p>
<p>bibkey:krauseteacherslearningn</p>
</li>
</ul>
</li>


<li id="i292" class="item email">
<table>
<tr>
<th>Type</th>
<td>E-mail</td>
</tr>
<tr>
<th class="author">Author</th>
<td>Charlie Lowe</td>
</tr>
<tr>
<th>Subject</th>
<td>Re: [techrhet] do HTML authors need to know HTML?</td>
</tr>
<tr>
<th>Date</th>
<td>2011-02-20</td>
</tr>
<tr>
<th>Date Added</th>
<td>Saturday, 21 May, 2011 14:40:12</td>
</tr>
<tr>
<th>Modified</th>
<td>Saturday, 21 May, 2011 14:40:42</td>
</tr>
</table><h3 class="notes">Notes:</h3>
<ul class="notes">
<li id="i293">
<p>As with the Slattery email (<em>q.v.</em>), this message was in 
response to my TECHRHET query regarding teaching core web technologies. 
It's notable as one of the relatively rare contributions to the debate 
that argues for teaching more-abstract tools, at least in some 
circumstances.</p>
<p>Lowe distinguishes between technically-oriented and design-oriented 
student populations, and claims that for the latter knowledge of markup 
languages is a secondary concern: "it is the principle of markup and 
styling that is the important outcome I seek, not so much the ability to
 build websites with HTML/CSS". While he believes some familiarity with 
core technologies is important for understanding the basic design 
principles of web documents, most students, he says, will be working 
with content-management systems and other more-abstracted toolchains.</p>
<p>It's interesting to contrast this with Lowe's contemporaneous "The Future of the Book" blog post (<em>q.v.</em>),
 which makes almost the opposite argument. In both cases, though, Lowe's
 position arises from an assessment of the available tools and which 
ones a technical communicator is likely to use, at this particular 
moment in the development of web technologies. In other words, these 
contrasting positions both arise from a highly pragmatic, 
results-oriented view.</p>
<p>bibkey:loweretechrhetdoht</p>
</li>
</ul>
</li>


<li id="i294" class="item webpage">
<h2>When Revision Is Redesign: Key Questions for Digital Scholarship</h2>
<table>
<tr>
<th>Type</th>
<td>Web Page</td>
</tr>
<tr>
<th class="author">Author</th>
<td>Susan H. Delagrange</td>
</tr>
<tr>
<th>Website Title</th>
<td>Kairos 14.1: Delagrange, When Revision is Redesign</td>
</tr>
<tr>
<th>Website Type</th>
<td>Text</td>
</tr>
<tr>
<th>Date</th>
<td>2009-08-15</td>
</tr>
<tr>
<th>Short Title</th>
<td>When Revision Is Redesign</td>
</tr>
<tr>
<th>URL</th>
<td><a href="http://kairos.technorhetoric.net/14.1/inventio/delagrange/">http://kairos.technorhetoric.net/14.1/inventio/delagrange/</a></td>
</tr>
<tr>
<th>Accessed</th>
<td>Friday, 27 May, 2011 19:10:00</td>
</tr>
<tr>
<th>Date Added</th>
<td>Friday, 27 May, 2011 19:10:00</td>
</tr>
<tr>
<th>Modified</th>
<td>Friday, 27 May, 2011 19:37:49</td>
</tr>
</table><h3 class="tags">Tags:</h3>
<ul class="tags">
<li>Digital Scholarship, Revision, Redesign, Peer-Review</li>
</ul>
<h3 class="notes">Notes:</h3>
<ul class="notes">
<li id="i296">
<p>Here Delagrange reflects on an older <em>Kairos</em> piece ("<em>Wunderkammer</em>,
 Cornell, and the Visual Canon of Arrangement", 2007) she wrote as a 
Flash application. In particular, she describes how she proceeded after 
receiving the initial "revise and resubmit" response from the editors.</p>
<p>For my purposes here, the relevant portion is the "Code" section, 
where Delagrange considers the question "What are the affordances and 
constraints of learning and writing underlying code when designing the 
visual and conceptual interface of a multimedia project?". (Delagrange 
begins each of her sections with a question.) She begins: "I want to 
argue for writing code", opposing it explicitly to WYSIWYG software, and
 suggesting that working at the level of code is necessary to produce 
"an optimal user experience" and to "fit the design to the rhetorical 
argument".</p>
<h3>In Favor of Friction</h3>
<p>Delagrange challenges what she calls (following Nancy Kaplan, <em>q.v.</em>)
 "frictionless computing", where software provides a surface interface 
for some activity that attempts to relieve users of the need to develop 
new interpretive skills. She claims that "real learning requires 
significant cognitive engagement", that literacy skills cannot be 
developed without effort, and that such skills are necessary to adapt to
 technological change and important for producing new-media work.</p>
<p>She notes that while working on the redesign, she often asked whether
 "the default design choice [was] the best rhetorical or aesthetic 
solution", or "merely adequate". This echoes a classic argument in the 
debate over black-box document-production software: that it reduces the 
creator's options to whatever the software creator thought important (or
 convenient, etc).</p>
<h3>Coding as Inventing</h3>
<p>For Delagrange, writing code is a research and design activity, "a 
practice of intellectual inquiry". It is fundamental to the process of 
invention when working in computer-based media. Creating a new-media 
work at the level of code is not a matter of a creative stage followed 
by an implementation stage; the work continues to be shaped as the 
author writes code.</p>
<p>Furthermore, Delagrange notes the social and cultural aspects of 
creating software, both in its creation (for example in collaborating 
with other experts) and in its consumption. She sites Lev Manovich's 
caution that to ignore the details of software is to deal "only with its
 effects rather than the causes".</p>
<p>Though Delagrange is writing here about Flash and Actionscript, the 
same theory should apply rather directly to HTML, CSS, and other 
standard web technologies.</p>
</li>
</ul>
<h3 class="attachments">Attachments</h3>
<ul class="attachments">
<li id="i295">Kairos 14.1: Delagrange, When Revision is Redesign - Home</li>
</ul>
</li>


<li id="i298" class="item conferencePaper">
<h2>Knowing Practice: A More Complex View of New Media Literacy</h2>
<table>
<tr>
<th>Type</th>
<td>Conference Paper</td>
</tr>
<tr>
<th class="author">Author</th>
<td>Nancy Kaplan</td>
</tr>
<tr>
<th>Abstract</th>
<td>In this paper, I examine the pervasive quest for invisible 
computers, applications, and interfaces in order to make a case for 
resisting the pressure to standardize platforms for delivering on-line 
courses and other Web-based applications. We need to be especially wary 
of the argument that the ideal information resource or technology 
imposes no cognitive load on its users. Although usability experts like 
Jakob Nielsen present a cogent case for routinizing, for example, the 
colors of visited and unvisited links in HTML documents, such a strategy
 may fail to provide the cognitive scaffolding knowledge workers
will need to confront changing technological environments in productive 
ways. In other words, too great a reduction of the cognitive challenge 
in the present may prevent people from developing effective learning 
strategies they can apply to future technologies. Drawing on 
constructivist theories of learning, I argue that applications and 
interfaces must remain visible and accessible to knowledge workers if 
they are to develop new media literacies.</td>
</tr>
<tr>
<th>Date</th>
<td>2001</td>
</tr>
<tr>
<th>Conference Name</th>
<td>SSGRR</td>
</tr>
<tr>
<th>Place</th>
<td>L'Aquila, Italy</td>
</tr>
<tr>
<th>Short Title</th>
<td>Knowing Practice</td>
</tr>
<tr>
<th>URL</th>
<td><a href="http://iat.ubalt.edu/kaplan/ssgrr01.pdf">http://iat.ubalt.edu/kaplan/ssgrr01.pdf</a></td>
</tr>
<tr>
<th>Library Catalog</th>
<td>Google Scholar</td>
</tr>
<tr>
<th>Date Added</th>
<td>Friday, 27 May, 2011 19:38:09</td>
</tr>
<tr>
<th>Modified</th>
<td>Friday, 27 May, 2011 19:42:46</td>
</tr>
</table><h3 class="notes">Notes:</h3>
<ul class="notes">
<li id="i325">
<p>Kaplan makes an unusual and telling argument against what she calls 
"invisible computers, applications, and interfaces" (1), those designed 
to reduce the cognitive demands they put on users. She proposes that 
reducing users' cognitive load prevents them from developing the skills 
they need to learn and adapt to new technologies in the future.</p>
<p>She opposes this argument to a trend she sees in prominent usability 
theorists such as Donald Norman and Jakob Nielsen, who have argued for 
"invisible" or "frictionless" "appliance" computing, where IT is 
incorporated into devices designed to minimize the effort users have to 
make in order to accomplish specific tasks; and in the work of Brenda 
Laurel and Janet Murray, who make a similar argument for black-boxing 
technologies, though from an aesthetic rather than a usability 
perspective.</p>
<p>Kaplan suggests, though, that while there may be advantages to  
transparency or a "perfect fit" (2) between written language and 
readers, it is not certain those advantages apply to new media, and 
particularly not to the processes of creating new media. For new media, 
she believes, literacy includes both reception and production, in 
multiple modes. Whereas print technology offers only a narrow range of 
affordances for human action, and thus those affordances can safely be 
black-boxed, new media offer a vaster and ever-growing range, and any 
attempt to reduce those to a small set of abstractions will necessarily 
greatly limit both the understanding and capability of users.</p>
<p>Kaplan applies this theoretical stance to the question of courseware,
 explaining that web-course and learning-management systems like 
Blackboard cost educators the opportunity for innovation. She points out
 such commercial applications "prevent everyone from penetrating their 
mysteries, from understanding the ways code constrains what they can do 
within the system" (3). And this is not just an issue for educators, she
 says: "That which is unproblematic or routinized to the point of 
invisibility fails to provide grounds for learning" (3).</p>
<p>In acknowledging the pragmatic arguments in favor of tool use, but 
challenging the theoretical ones underpinning their value, Kaplan makes 
one of the strongest arguments to date in favor of teaching 
technological details rather than simply surface tools.</p>
</li>
</ul>
<h3 class="attachments">Attachments</h3>
<ul class="attachments">
<li id="i297">ssgrr01.pdf</li>
</ul>
</li>


<li id="i299" class="item webpage">
<h2>WYSIWYG vs. XHTML/CSS &lt; Teaching Writing in a Digital Age</h2>
<table>
<tr>
<th>Type</th>
<td>Web Page</td>
</tr>
<tr>
<th class="author">Author</th>
<td>Kory Ching</td>
</tr>
<tr>
<th>Website Title</th>
<td>Teachign Writing in a Digital Age</td>
</tr>
<tr>
<th>Date</th>
<td>2011-02-23</td>
</tr>
<tr>
<th>Short Title</th>
<td>WYSIWYG vs. XHTML/CSS</td>
</tr>
<tr>
<th>URL</th>
<td><a href="http://twinada.wordpress.com/2011/02/23/wysiwyg-vs-xhtmlcss/">http://twinada.wordpress.com/2011/02/23/wysiwyg-vs-xhtmlcss/</a></td>
</tr>
<tr>
<th>Accessed</th>
<td>Friday, 27 May, 2011 19:43:24</td>
</tr>
<tr>
<th>Date Added</th>
<td>Friday, 27 May, 2011 19:43:24</td>
</tr>
<tr>
<th>Modified</th>
<td>Friday, 27 May, 2011 19:44:26</td>
</tr>
</table><h3 class="notes">Notes:</h3>
<ul class="notes">
<li id="i301">
<p>This blog post is actually about the conversation I started on the 
TechRhet listserv about this bibliography. The sources Ching mentions 
are ones I have included here, but his glosses of them, and particularly
 the ensuing discussion, are interesting. In the latter, Cheryl Haynes 
wonders about course requirements, and Cynthia Carter Ching notes that 
Learning Sciences "went through this exact same discussion ... two 
decades ago" and describes some aspects of that debate.</p>
<p>bibkey:chingwysiwygvs</p>
</li>
</ul>
<h3 class="attachments">Attachments</h3>
<ul class="attachments">
<li id="i300">WYSIWYG vs. XHTML/CSS « Teaching Writing in a Digital Age</li>
</ul>
</li>


<li id="i302" class="item journalArticle">
<h2>Letter from the guest editors</h2>
<table>
<tr>
<th>Type</th>
<td>Journal Article</td>
</tr>
<tr>
<th class="author">Author</th>
<td>Ron Fortune</td>
</tr>
<tr>
<th class="author">Author</th>
<td>Jim Kalmbach</td>
</tr>
<tr>
<th>Publication</th>
<td>Computers and Composition</td>
</tr>
<tr>
<th>Volume</th>
<td>16</td>
</tr>
<tr>
<th>Issue</th>
<td>3</td>
</tr>
<tr>
<th>Pages</th>
<td>319-324</td>
</tr>
<tr>
<th>Date</th>
<td>1999</td>
</tr>
<tr>
<th>DOI</th>
<td>16/S8755-4615(99)00013-4</td>
</tr>
<tr>
<th>ISSN</th>
<td>8755-4615</td>
</tr>
<tr>
<th>URL</th>
<td><a href="http://www.sciencedirect.com/science/article/pii/S8755461599000134">http://www.sciencedirect.com/science/article/pii/S8755461599000134</a></td>
</tr>
<tr>
<th>Accessed</th>
<td>Friday, 27 May, 2011 20:03:27</td>
</tr>
<tr>
<th>Library Catalog</th>
<td>ScienceDirect</td>
</tr>
<tr>
<th>Date Added</th>
<td>Friday, 27 May, 2011 20:03:27</td>
</tr>
<tr>
<th>Modified</th>
<td>Friday, 27 May, 2011 20:03:27</td>
</tr>
</table><h3 class="notes">Notes:</h3>
<ul class="notes">
<li id="i327">
<p>In their introduction to this special issue of <em>Computers and Composition</em>
 on programming in the composition classroom, Fortune and Kalmbach begin
 by suggesting that there is a place in writing instruction for learning
 about relevant core IT technologies. The contributors here take up the 
question of programming in the writing classroom in various ways, from 
"teachers doing coding to create positive learning environments ... to 
involving students in the coding themselves" (322). The former, of 
course, does not necessarily imply any "teach the tech" aspect, except 
for those who intend to become teachers themselves, but the latter is 
clearly a call to incorporate the study of basic computing technologies 
in writing curricula. And while programming and HTML/CSS markup are 
distinct activities, it is not much of a theoretical leap from teaching 
one to teaching the other.</p>
<p>Fortune and Kalmbach suggest that the contributors, and other 
like-minded rhetoric and/or composition teachers, have come to feel 
programming is important in various ways. One is the conception of 
programming as rhetorical, as concerned with logic and syntax, with the 
conjoining of concepts and the arrangement of ideas. The authors see 
this as increasing with object-oriented programming, hypermedia 
authoring, and HTML; again this suggests that their arguments could 
easily apply to the question I'm investigating here.</p>
<p>Another argument they advance is that HTML has rhetorical 
affordances, and so should come under rhetorical study. "HTML coding on 
the World Wide Web has made both the rhetoric of code and the impact of 
that rhetoric on the effectiveness of web pages" apparent to the authors
 of those pages, Fortune and Kalmbach declare (322). For tech comm, this
 means learning HTML at the "code" level is a matter of learning 
rhetorical <em>techne</em>.<br /><br />To be completely frank, Fortune 
and Kalmbach, and people they cite, are not very technically accurate 
when they discuss programming (and particularly not on the history and 
nature of programming prior to, say, 1990); but they have useful 
insights about some of the ways programming can be rhetorical in their 
own historical moment.</p>
<p>bibkey:fortuneletterfromthegues</p>
</li>
</ul>
<h3 class="attachments">Attachments</h3>
<ul class="attachments">
<li id="i303">ScienceDirect Full Text PDF</li>
<li id="i304">ScienceDirect Snapshot</li>
</ul>
</li>


<li id="i305" class="item journalArticle">
<h2>Reading between the code: the teaching of HTML and the displacement of writing instruction</h2>
<table>
<tr>
<th>Type</th>
<td>Journal Article</td>
</tr>
<tr>
<th class="author">Author</th>
<td>Nicholas Mauriello</td>
</tr>
<tr>
<th class="author">Author</th>
<td>Gian S. Pagnucci</td>
</tr>
<tr>
<th class="author">Author</th>
<td>Tammy Winner</td>
</tr>
<tr>
<th>Abstract</th>
<td>The introduction of hypertext markup language (HTML) into the 
composition classroom often complicates traditional text-bound 
assignments. The process of incorporating HTML codes into writing can be
 frustrating because HTML is difficult to learn. More time spent 
learning coding skills may mean less time spent learning other writing 
skills. In many ways, learning HTML is like learning a second language. 
Unlike other pedagogical tools, though, HTML seems to blur the lines of 
our discipline. It turns the traditional composition course into a 
hybrid language/writing/computer course. This reshaping displaces 
traditional writing activities with technology-based instruction, thus 
challenging the notion of what constitutes appropriate curricular 
content within the composition classroom. This curricular change 
necessitates political action on the part of technology-focused 
teachers, for instance the establishment of new types of teaching 
collaboratives and the rethinking of departmental policies.</td>
</tr>
<tr>
<th>Publication</th>
<td>Computers and Composition</td>
</tr>
<tr>
<th>Volume</th>
<td>16</td>
</tr>
<tr>
<th>Issue</th>
<td>3</td>
</tr>
<tr>
<th>Pages</th>
<td>409-419</td>
</tr>
<tr>
<th>Date</th>
<td>1999</td>
</tr>
<tr>
<th>DOI</th>
<td>16/S8755-4615(99)00020-1</td>
</tr>
<tr>
<th>ISSN</th>
<td>8755-4615</td>
</tr>
<tr>
<th>Short Title</th>
<td>Reading between the code</td>
</tr>
<tr>
<th>URL</th>
<td><a href="http://www.sciencedirect.com/science/article/pii/S8755461599000201">http://www.sciencedirect.com/science/article/pii/S8755461599000201</a></td>
</tr>
<tr>
<th>Accessed</th>
<td>Friday, 27 May, 2011 20:04:31</td>
</tr>
<tr>
<th>Library Catalog</th>
<td>ScienceDirect</td>
</tr>
<tr>
<th>Date Added</th>
<td>Friday, 27 May, 2011 20:04:31</td>
</tr>
<tr>
<th>Modified</th>
<td>Friday, 27 May, 2011 20:04:50</td>
</tr>
</table><h3 class="tags">Tags:</h3>
<ul class="tags">
<li>collaboration</li>
<li>Composition</li>
<li>HTML authoring</li>
<li>Internet/World Wide Web</li>
<li>student publishing</li>
<li>technology</li>
</ul>
<h3 class="notes">Notes:</h3>
<ul class="notes">
<li id="i332">
<p>As their title suggests, Mauriello et al belong to that group of 
compositionists who are concerned that teaching web technology in the 
writing classroom diverts time and attention from traditional writing 
instruction. They describe their experiences in attempting to identify 
and address these issues in a collaborative teaching support and 
research group. Beside the obvious problem of limited time in a 
composition course, and the concomitant problem of trying to add web 
technology or any other additional subject to the syllabus, they offer 
some specific objections.</p>
<p>One is that HTML is "difficult to learn". While it's easy to object 
to this sort of generalization (what subjects are easy to learn? what 
factors make a subject easy or difficult?), there is some justice to it.
 Certainly the workflow, failure modes, and reward structure of 
constructing software (which, for these purposes, would include writing 
HTML, even though it's not programming in a strict sense) are 
substantially different from those for writing prose. Students without 
programming experience are likely to find their introduction to it a 
frustrating experience.</p>
<p>Their second major objection is that teaching HTML threatens 
disciplinary boundaries. This is a common and, again, fairly obvious 
complaint, and one that I admit I don't have a great deal of sympathy 
for. Are writing technologies not within the purview of writing classes?
 Still, I understand that there are institutional consequences for 
troubling the configuration of the disciplines, and that faculty members
 need to recognize and negotiate them.</p>
<p>The authors also suggest that students are uneasy, and find it harder
 to learn, when instructors employ experimental pedagogical techniques 
or introduce subjects they are themselves unsure of. And, they claim, 
because web work is usually public (the authors don't distinguish 
between web sites on the Internet and those confined to institutional 
networks), this problem is compounded by the potential for outside 
criticism.</p>
<p>They spend some time discussing the capabilities and potential of 
web-authoring tools, about which they're rather ambivalent. Early on 
they declare that "At present, to publish on the Web requires using HTML
 code" (411), which seems to dismiss tools as an option. But they go on 
to discuss template-driven web sites such as Tripod and Geocities 
(413-414), and HTML converters and WYSIWYG tools (414-415). They 
describe issues with all of these, and describe one solution which 
frankly, twelve years later, seems decidedly backward: students would 
write papers using conventional word processors and hand them in as 
softcopy, and instructors would convert them to HTML and publish them on
 a class web site (416). Though the authors claim both students and 
instructors like the results of this process, it was too much work for 
instructors, and some felt it was "disempowering" for students.</p>
<p>Ultimately the authors do not come out strongly in favor of teaching 
tools rather than technology. This was not the result of a theoretical 
stand in favor of teaching the tech, but a practical one: the group 
could not find a workable approach to an HTML writing curriculum that 
did not involve students writing HTML directly.</p>
<p>Beyond that, the authors call for special Web-based sections of 
writing courses; for institutional support for such courses; more 
research on teaching HTML; and a greater focus on collaboration among 
writing instructors and other faculty to deal with the challenges of Web
 writing.</p>
<p>bibkey:mauriellopagnucciandtammy</p>
</li>
</ul>
<h3 class="attachments">Attachments</h3>
<ul class="attachments">
<li id="i306">ScienceDirect Full Text PDF</li>
<li id="i307">ScienceDirect Snapshot</li>
</ul>
</li>


<li id="i308" class="item journalArticle">
<h2>The new frontier: conquering the World Wild Web by mule</h2>
<table>
<tr>
<th>Type</th>
<td>Journal Article</td>
</tr>
<tr>
<th class="author">Author</th>
<td>Morgan Gresham</td>
</tr>
<tr>
<th>Abstract</th>
<td>This article offers a close examination of the effects that teaching
 hypertext markup language (HTML) has on students' perceptions of class 
goals in a networked composition classroom. A networked classroom that 
requires students to send documents using a file transfer protocol (FTP)
 by command line and view the World Wide Web with a textual browser 
shifts the emphasis of the class from writing to coding. Helping 
students identify a balance between computer technology and writing 
goals becomes essential to a successful classroom.</td>
</tr>
<tr>
<th>Publication</th>
<td>Computers and Composition</td>
</tr>
<tr>
<th>Volume</th>
<td>16</td>
</tr>
<tr>
<th>Issue</th>
<td>3</td>
</tr>
<tr>
<th>Pages</th>
<td>395-407</td>
</tr>
<tr>
<th>Date</th>
<td>1999</td>
</tr>
<tr>
<th>DOI</th>
<td>16/S8755-4615(99)00018-3</td>
</tr>
<tr>
<th>ISSN</th>
<td>8755-4615</td>
</tr>
<tr>
<th>Short Title</th>
<td>The new frontier</td>
</tr>
<tr>
<th>URL</th>
<td><a href="http://www.sciencedirect.com/science/article/pii/S8755461599000183">http://www.sciencedirect.com/science/article/pii/S8755461599000183</a></td>
</tr>
<tr>
<th>Accessed</th>
<td>Friday, 27 May, 2011 20:05:16</td>
</tr>
<tr>
<th>Library Catalog</th>
<td>ScienceDirect</td>
</tr>
<tr>
<th>Date Added</th>
<td>Friday, 27 May, 2011 20:05:16</td>
</tr>
<tr>
<th>Modified</th>
<td>Friday, 27 May, 2011 20:05:30</td>
</tr>
</table><h3 class="tags">Tags:</h3>
<ul class="tags">
<li>computer classroom</li>
<li>HTML</li>
<li>practice</li>
<li>Theory</li>
<li>World Wide Web</li>
</ul>
<h3 class="notes">Notes:</h3>
<ul class="notes">
<li id="i328">
<p>Gresham expands on a concern that many writing instructors voice in 
casual discussion: how do we prevent the writing classroom from becoming
 solely about the technology? Or, as Gresham puts it, how do we avoid 
"the danger that our use of technology will not be balanced with our 
writing goals" (405)? Nonetheless, Gresham makes an argument for having 
students interact directly with HTML code: "teaching HTML coding ... 
could allow me the opportunity to examine those gaps present when 
technologies are not seamless and when the conventions that underlie 
online communications are not transparent" (397). Of course, in 1999 
there were relatively few choices for "transparent" HTML creation tools,
 but Gresham's argument remains relevant.</p>
<p>What's particularly interesting about Gresham's piece is that it 
arises specifically from the experience of teaching web-page creation in
 a class forced to use outdated and barely-capable hardware and software
 (the "mule" of his title). He suggests that the tensions of 
technological problems illuminate theoretical ones.</p>
</li>
</ul>
<h3 class="attachments">Attachments</h3>
<ul class="attachments">
<li id="i309">ScienceDirect Full Text PDF</li>
<li id="i310">ScienceDirect Snapshot</li>
</ul>
</li>


<li id="i311" class="item journalArticle">
<h2>Writing (online) spaces: composing Webware in Perl</h2>
<table>
<tr>
<th>Type</th>
<td>Journal Article</td>
</tr>
<tr>
<th class="author">Author</th>
<td>Cecilia Hartley</td>
</tr>
<tr>
<th class="author">Author</th>
<td>Ellen Schendel</td>
</tr>
<tr>
<th class="author">Author</th>
<td>Michael R. Neal</td>
</tr>
<tr>
<th>Abstract</th>
<td>In this article, we point to scholarship that helped us think about 
the ideologies behind Writing Spaces, a Web-based site for 
computer-mediated communication (CMC) that we constructed using Perl 
scripts. Our reasons for designing the site, rather than relying upon 
existing software to facilitate computer-mediated communication in our 
classrooms, are threefold: (a) we want to create online spaces that 
reflect our theories about language and learning; (b) we agree with 
researchers who encourage instructors in computers and composition to 
become more involved in shaping technology; and (c) we wish to situate 
ourselves as technology critics by examining the ideologies behind 
technologies as we construct them. In this article, we give an account 
of our processes in learning Perl and constructing the site--processes 
that reflect theories about learning that are rooted in social 
construction. We argue that writing teachers can and should shape online
 spaces to facilitate their individual pedagogies rather than allowing 
commercial software to limit their pedagogical choices.</td>
</tr>
<tr>
<th>Publication</th>
<td>Computers and Composition</td>
</tr>
<tr>
<th>Volume</th>
<td>16</td>
</tr>
<tr>
<th>Issue</th>
<td>3</td>
</tr>
<tr>
<th>Pages</th>
<td>359-370</td>
</tr>
<tr>
<th>Date</th>
<td>1999</td>
</tr>
<tr>
<th>DOI</th>
<td>16/S8755-4615(99)00016-X</td>
</tr>
<tr>
<th>ISSN</th>
<td>8755-4615</td>
</tr>
<tr>
<th>Short Title</th>
<td>Writing (online) spaces</td>
</tr>
<tr>
<th>URL</th>
<td><a href="http://www.sciencedirect.com/science/article/pii/S875546159900016X">http://www.sciencedirect.com/science/article/pii/S875546159900016X</a></td>
</tr>
<tr>
<th>Accessed</th>
<td>Friday, 27 May, 2011 20:06:16</td>
</tr>
<tr>
<th>Library Catalog</th>
<td>ScienceDirect</td>
</tr>
<tr>
<th>Date Added</th>
<td>Friday, 27 May, 2011 20:06:16</td>
</tr>
<tr>
<th>Modified</th>
<td>Friday, 27 May, 2011 20:06:32</td>
</tr>
</table><h3 class="tags">Tags:</h3>
<ul class="tags">
<li>collaboration</li>
<li>computer-mediated communication</li>
<li>discourse community</li>
<li>local-area network (LAN)</li>
<li>Perl</li>
<li>programming</li>
<li>social construction</li>
<li>Webware</li>
<li>World Wide Web</li>
</ul>
<h3 class="notes">Notes:</h3>
<ul class="notes">
<li id="i330">
<p>Another example of an essay which focuses not so much on the question
 of teaching web technologies, as of their employment by instructors; 
but it seems to me this necessarily implies a benefit to teaching them 
as well, for the benefit of future instructors, and by extension for 
students who may enter other professions where the same arguments apply.</p>
<p>Hartley et alia offer three major points in favor of using web 
technology. They support them through the example of a web site they 
created named <em>Writing Spaces</em>, which is not just static HTML 
(and related) content, but a web application written primarily in Perl. 
Creating such a site is significantly more involved than simply 
composing static pages, so on the one hand the authors are more or less 
compelled to gain technical knowledge and use web technologies 
directly—their options for employing black-box tools were limited, 
particularly in the late 1990s when the site was created. On the other 
hand, it means they had to become more informed about that technology, 
and learn how it fit with their theories about the importance of 
critical examination of technology.</p>
<p>The three arguments the authors advance are not unique to this piece,
 but they are solid and clearly formulated. One is simply that 
instructors who teach technology should understand it; a second, 
complementary goal is to gain sufficient understanding to offer robust 
critiques of those technologies, and in particular of the ideologies 
that underlie them. The third, which might be seen as following from 
those two, is to use that understanding to create web technologies that 
embody the theories writing instructors advocate.</p>
<p>As a final note, I appreciated the authors' description of their 
software-writing practice. They studied the Perl programming language 
enough to gain some literacy in it, and learned basic concepts of web 
application design. Then they found free-for-use Perl scripts online, 
customized them for their purposes, and integrated them into an 
application. This bricolage is reminiscent not only of much professional
 software development (which makes much use of free and commercial 
components), but reflects contemporary ideas about writing as well.</p>
<p>bibkey:hartleyneal</p>
</li>
</ul>
<h3 class="attachments">Attachments</h3>
<ul class="attachments">
<li id="i312">ScienceDirect Full Text PDF</li>
<li id="i313">ScienceDirect Snapshot</li>
</ul>
</li>


<li id="i314" class="item journalArticle">
<h2>The politics of the code</h2>
<table>
<tr>
<th>Type</th>
<td>Journal Article</td>
</tr>
<tr>
<th class="author">Author</th>
<td>Joel Haefner</td>
</tr>
<tr>
<th>Abstract</th>
<td>This article explores the software behind the interface of the 
programs we use in composition classrooms--the principles of Structured 
Programming (SP), file structure, and some other significant issues in 
programming--and places the production of software in a cultural 
context. Programming protocol is shaped by two major strands: the profit
 imperative and the hierarchical structure of corporate America. The 
assumptions and procedures of Structured Programming are critiqued, and 
hypertext, structured programming, and natural-language writing are 
compared. This article suggests that writing instructors think about 
ways to customize programs used in their composition classes and to 
understand the implications and limitations of the necromancy of 
software.</td>
</tr>
<tr>
<th>Publication</th>
<td>Computers and Composition</td>
</tr>
<tr>
<th>Volume</th>
<td>16</td>
</tr>
<tr>
<th>Issue</th>
<td>3</td>
</tr>
<tr>
<th>Pages</th>
<td>325-339</td>
</tr>
<tr>
<th>Date</th>
<td>1999</td>
</tr>
<tr>
<th>DOI</th>
<td>16/S8755-4615(99)00014-6</td>
</tr>
<tr>
<th>ISSN</th>
<td>8755-4615</td>
</tr>
<tr>
<th>URL</th>
<td><a href="http://www.sciencedirect.com/science/article/pii/S8755461599000146">http://www.sciencedirect.com/science/article/pii/S8755461599000146</a></td>
</tr>
<tr>
<th>Accessed</th>
<td>Friday, 27 May, 2011 20:06:54</td>
</tr>
<tr>
<th>Library Catalog</th>
<td>ScienceDirect</td>
</tr>
<tr>
<th>Date Added</th>
<td>Friday, 27 May, 2011 20:06:54</td>
</tr>
<tr>
<th>Modified</th>
<td>Friday, 27 May, 2011 20:07:11</td>
</tr>
</table><h3 class="tags">Tags:</h3>
<ul class="tags">
<li>ANSI C language</li>
<li>coding</li>
<li>file structure</li>
<li>hypertext</li>
<li>programming</li>
<li>scripting</li>
<li>Structured Programming</li>
</ul>
<h3 class="notes">Notes:</h3>
<ul class="notes">
<li id="i329">
<p>Haefner offers a cultural and political critique of programming 
languages and techniques such as structured programming. Frankly, I find
 his argument highly dubious; I find it technically suspect, 
historically underinformed (at least judging from the explicit evidence 
Haefner offers), and theoretically uncompelling. But it is an 
interesting position nonetheless.</p>
<p>Certainly Haefner is broadly correct in the sense that early and 
prolonged US (and to a lesser extent UK) dominance of commercial data 
processing has lasting cultural-imperialist effects, seen for example in
 the still-incomplete deployment of localization and 
internationalization features in commercial software. And these issues 
are inherent in some (though by no means all) programming languages. 
Whether they are inherent in programming practices, either at the time 
the article was written or now (dominant programming practices having 
changed substantially in the interval), is quite another question.</p>
<h3>Close Reading Code?</h3>
<p>Haefner is least successful when philosophizing on the nature of 
program source code, as in his attempt to "translate" Shakespeare to C. 
This is not a meaningful exercise, and the argument that emerges from it
 is not productive. The "simultaneous dichotomy" of "To be or not to 
be?" can't exist in his toy program not because the C language restricts
 him to a Boolean logic, as Haefner would have it, but because 
existential problems are not members of the conceptual domain of 
computer software. That dichotomy doesn't exist in a copy of <em>Hamlet</em>, either; it exists in the reader's mind.</p>
<p>Haefner also shows an unfortunate tendency to leap from correlation 
to causation, particularly in his analysis of structured programming. 
For example, he sees similarities in corporate management structure and 
program structure, and concludes the latter must derive from, or at 
least endorse, the former; but it is just as possible that both are 
simply examples of exercising the same tool.</p>
<p>Perhaps the greatest flaw in Haefner's argument, though, is his 
suggestion that the essences of programming languages and structure 
programming that he purports to have revealed somehow contaminate the 
use of computer applications for writing classrooms, which (he claims) 
would endorse different cognitive approaches. This is an old argument, 
with such illustrious predecessors as Audre Lourde's "master's tools" 
philosophy; but it is a bold and contended position, and one that needs 
rather more support than Haefner gives it here.</p>
<h3>Practical Problems</h3>
<p>Though Haefner's theoretical position (however interesting) is 
untenable,  he is more successful at pointing to practical problems with
 software for writing, such as the myriad features (such as they are) of
 Microsoft Word that are unhelpful in the typical writing classroom 
(333-334). He points out that customizing software often isn't a viable 
option for writing labs, since many students will typically use the same
 copy of the software, or lose their custom settings each time they log 
out. And though he commits another theoretical error (due in large part 
to his reliance on the work of Ted Nelson, a "visionary" not overly 
concerned with accuracy) in seeing a lack of support for revision 
history as inherent in hierarchical filesystems, he's correct that 
typical commercial word-processing software does not handle revision 
history well, if at all. And if like many of the authors I've listed in 
this bibliography he overstates the liberatory powers of hypertext, he 
is correct in noting its potential for simplifying collaborative work, 
for example.</p>
<p>Despite the problems with this piece, Haefner makes a number of good 
points. More than that, it's interesting as an early attempt for a 
writing scholar to come to grips with the technologies and practices of 
programming and their theoretical implications for users of software. 
Today, nascent fields such as software studies and critical code studies
 are introducing more trenchant, more accurate, more 
technically-informed theories of programming into our discussions; but 
in 1999 work like this was rare and daring.</p>
</li>
</ul>
<h3 class="attachments">Attachments</h3>
<ul class="attachments">
<li id="i315">ScienceDirect Full Text PDF</li>
<li id="i316">ScienceDirect Snapshot</li>
</ul>
</li>


<li id="i317" class="item email">
<table>
<tr>
<th>Type</th>
<td>E-mail</td>
</tr>
<tr>
<th class="author">Author</th>
<td>Karl Stolley</td>
</tr>
<tr>
<th>Subject</th>
<td>Re: [techrhet] do HTML authors need to know HTML?</td>
</tr>
<tr>
<th>Date</th>
<td>2011-02-19</td>
</tr>
<tr>
<th>Date Added</th>
<td>Friday, 27 May, 2011 20:13:02</td>
</tr>
<tr>
<th>Modified</th>
<td>Friday, 27 May, 2011 20:14:21</td>
</tr>
</table><h3 class="notes">Notes:</h3>
<ul class="notes">
<li id="i318">
<p>Stolley's reply to the TechRhet discussion (see also Ching, Lowe, 
Slattery) makes a few interesting points. First, Stolley suggests that 
little of the published work on the subject will advocate a tools-based 
approach. (While I did find some sources for that side, it's true that a
 majority favor tech.) He believes the pro-WYSIWYG position in 
particular is more often voiced in casual conversation or implicit in 
classroom practice.</p>
<p>Stolley also notes that the argument he most often encounters in 
favor of teaching tools is that instructors don't have time to learn to 
write code. He claims that his experience is the opposite — that keeping
 up with changing tools was too time-consuming, particularly for an 
activity that did not provide any other research benefit.</p>
<p>bibkey:stolleyretechrhetdoht</p>
</li>
</ul>
</li>


<li id="i319" class="item journalArticle">
<h2>Layered Literacies: A Theoretical Frame for Technical Communication Pedagogy: [1]</h2>
<table>
<tr>
<th>Type</th>
<td>Journal Article</td>
</tr>
<tr>
<th class="author">Author</th>
<td>Kelli Cargile Cook</td>
</tr>
<tr>
<th>Abstract</th>
<td>This article proposes a theoretical frame for tchnical communication
 pedagogy based on six layered literacies: basic, rhetorical, social, 
technological, ethical, and critical....</td>
</tr>
<tr>
<th>Publication</th>
<td>Technical Communication Quarterly</td>
</tr>
<tr>
<th>Volume</th>
<td>11</td>
</tr>
<tr>
<th>Issue</th>
<td>1</td>
</tr>
<tr>
<th>Pages</th>
<td>5-29</td>
</tr>
<tr>
<th>Date</th>
<td>Winter 2002</td>
</tr>
<tr>
<th>Language</th>
<td>English</td>
</tr>
<tr>
<th>ISSN</th>
<td>10572252</td>
</tr>
<tr>
<th>Short Title</th>
<td>Layered Literacies</td>
</tr>
<tr>
<th>Library Catalog</th>
<td>ABI/INFORM Complete</td>
</tr>
<tr>
<th>Rights</th>
<td>Copyright Association of Teachers of Technical Writing Winter 2002</td>
</tr>
<tr>
<th>Date Added</th>
<td>Sunday, 29 May, 2011 11:07:44</td>
</tr>
<tr>
<th>Modified</th>
<td>Sunday, 29 May, 2011 16:40:32</td>
</tr>
</table><h3 class="tags">Tags:</h3>
<ul class="tags">
<li>Integrated curriculum</li>
<li>Literacy</li>
<li>Technical communication</li>
</ul>
<h3 class="notes">Notes:</h3>
<ul class="notes">
<li id="i326">
<p>Though this widely-cited essay appeared before the tools/tech debate 
was particularly prominent, and does not directly address it, it was 
cited as formative by a couple of the respondents to my initial query on
 the Techrhet list. The "six layered literacies" around which Cook 
formulates her pedagogy form a schema that emphasizes teaching technical
 communicators multiple skills from multiple perspectives; Cook's 
position is that technical communication requires a wide range of 
skills, and no one approach is sufficient. Among the six is 
"technological literacy", about which Cook notes that it "strives to 
advance students beyond knowledge of software applications" (13). Cook 
expands on this point by describing technical communicators as mediators
 of technology, with roles in documentation, usability, and so forth. 
It's possible, though, to extrapolate from her position to conclude that
 technical communicators should understand the technologies that 
underlie those applications.</p>
</li>
</ul>
<h3 class="attachments">Attachments</h3>
<ul class="attachments">
<li id="i320">ProQuest PDF</li>
</ul>
</li>


<li id="i321" class="item journalArticle">
<h2>Analysis of the Skills Called for by Technical Communication Employers in Recruitment Postings</h2>
<table>
<tr>
<th>Type</th>
<td>Journal Article</td>
</tr>
<tr>
<th class="author">Author</th>
<td>Clinton R Lanier</td>
</tr>
<tr>
<th>Publication</th>
<td>Technical Communication</td>
</tr>
<tr>
<th>Volume</th>
<td>56</td>
</tr>
<tr>
<th>Issue</th>
<td>1</td>
</tr>
<tr>
<th>Pages</th>
<td>51</td>
</tr>
<tr>
<th>Date</th>
<td>Feb 2009</td>
</tr>
<tr>
<th>Language</th>
<td>English</td>
</tr>
<tr>
<th>ISSN</th>
<td>00493155</td>
</tr>
<tr>
<th>Library Catalog</th>
<td>ProQuest Research Library</td>
</tr>
<tr>
<th>Rights</th>
<td>Copyright Society for Technical Communication Feb 2009</td>
</tr>
<tr>
<th>Date Added</th>
<td>Sunday, 29 May, 2011 11:08:54</td>
</tr>
<tr>
<th>Modified</th>
<td>Sunday, 29 May, 2011 11:08:54</td>
</tr>
</table><h3 class="tags">Tags:</h3>
<ul class="tags">
<li>Qualifications</li>
<li>Skills</li>
<li>Technical communication</li>
<li>Writers</li>
</ul>
<h3 class="notes">Notes:</h3>
<ul class="notes">
<li id="i331">
<p>A survey of job postings for technical writers shows that employers 
want them to have technical skills, and are not particularly interested 
in knowledge of specific tools. This is a moderate pragmatic argument in
 favor of teaching the tech rather than the tools.</p>
</li>
</ul>
<h3 class="attachments">Attachments</h3>
<ul class="attachments">
<li id="i322">ProQuest HTML</li>
</ul>
</li>


<li id="i323" class="item journalArticle">
<h2>Do Curricula Correspond to Managerial Expectations? Core Competencies for Technical Communicators</h2>
<table>
<tr>
<th>Type</th>
<td>Journal Article</td>
</tr>
<tr>
<th class="author">Author</th>
<td>Kenneth T Rainey</td>
</tr>
<tr>
<th class="author">Author</th>
<td>Roy K Turner</td>
</tr>
<tr>
<th class="author">Author</th>
<td>David Dayton</td>
</tr>
<tr>
<th>Publication</th>
<td>Technical Communication</td>
</tr>
<tr>
<th>Volume</th>
<td>52</td>
</tr>
<tr>
<th>Issue</th>
<td>3</td>
</tr>
<tr>
<th>Pages</th>
<td>323-352</td>
</tr>
<tr>
<th>Date</th>
<td>Aug 2005</td>
</tr>
<tr>
<th>Language</th>
<td>English</td>
</tr>
<tr>
<th>ISSN</th>
<td>00493155</td>
</tr>
<tr>
<th>Short Title</th>
<td>Do Curricula Correspond to Managerial Expectations?</td>
</tr>
<tr>
<th>Library Catalog</th>
<td>ProQuest Research Library</td>
</tr>
<tr>
<th>Rights</th>
<td>Copyright Society for Technical Communication Aug 2005</td>
</tr>
<tr>
<th>Date Added</th>
<td>Sunday, 29 May, 2011 11:10:30</td>
</tr>
<tr>
<th>Modified</th>
<td>Sunday, 29 May, 2011 11:10:30</td>
</tr>
</table><h3 class="tags">Tags:</h3>
<ul class="tags">
<li>Core competencies</li>
<li>Curricula</li>
<li>Managerial skills</li>
<li>Public opinion surveys</li>
<li>Technical communication</li>
</ul>
<h3 class="notes">Notes:</h3>
<ul class="notes">
<li id="i334">
<p>Another article that falls into the "preparing for the job" category,
 "Core Competencies" surveys both technical-communication managers in 
the workplace and curricula from undergraduate programs, to see how well
 the two match.</p>
<p>Many of the skills revealed by the study are catholic and equally 
applicable to nearly any approach to teaching web authoring, such as the
 ability to collaborate or to write clearly. The authors list both the 
ability to learn new technologies (which others have suggested argues 
against overemphasizing specific tools in the classroom) and "skills in 
using technologies" (323) as desirable, which would seem to be one vote 
for each side; the latter is only a "secondary competency", but the 
former is a weaker claim, so they largely balance out. They do later 
conclude that "the ability to adapt to new situations and to learn new 
software quickly is far more important than knowledge of specific 
software packages" (333), but this is not the same as an endorsement for
 teaching web technologies.</p>
<p>While there's no strong argument for either side in this piece, the 
results of the study might be taken as a recommendation for a balanced 
approach, so that students get some exposure to popular tools but also 
enough understanding of underlying technologies to be flexible and quick
 to learn new tools.</p>
<p>bibkey:raineydocurriculacorresp</p>
</li>
</ul>
<h3 class="attachments">Attachments</h3>
<ul class="attachments">
<li id="i324">ProQuest PDF</li>
</ul>
</li>

</ul>
</body>
</html>