<div dir="ltr">Interesting .. cross posting this from the eChalk list.<br><br>Regards Roland<br><br><div class="gmail_quote">---------- Forwarded message ----------<br><br><div dir="ltr">worth a read.<br><a href="http://kairos.technorhetoric.net/12.3/binder.html?topoi/stolley/index.htm" target="_blank">http://kairos.technorhetoric.net/12.3/binder.html?topoi/stolley/index.htm</a><br>
<h2>Manifesto</h2>
<dl><dt>1. Software is a poor organizing principle for digital production.</dt><dd style="border-top: medium none; border-bottom: medium none; overflow: hidden; padding-top: 0px; padding-bottom: 0px; height: 0px;">
<div>
<blockquote>
<p>"What program do you use?" is a question I often get about the slides
I use to present my work. I have concluded that the proper answer
to the question is to counter-suggest the asking of a different question,
"What <i>principle</i> do you use?" <cite><span>John Maeda,</span> The
Laws of Simplicity</cite></p>
</blockquote>
<p>As rhetoricians, we should resist allowing software, commercial or
otherwise, to signify entire digital genres. But compare the number
of results in a search engine for "rhetoric of PowerPoint" versus "rhetoric
of slideshows." The results are not encouraging—and suggest that "vendor
lock-in" has as much of a grip on discourse as it does on scenes of
production.</p>
<p>But consider a software-independent, lo-fi alternative to PowerPoint: <a href="http://meyerweb.com/" rel="external" target="_blank">Eric
Meyer</a>, CSS guru and design wizard, developed and <a href="http://meyerweb.com/eric/thoughts/category/tech/s5/" rel="external" target="_blank">released
into the public domain</a> a <a href="http://meyerweb.com/eric/tools/s5/" rel="external" target="_blank">Simple
Standards-based Slide Show System</a> (S5). Meyer's system uses the
lo-fi technologies of structural XHTML, media-specific CSS, and JavaScript
(languages usually encountered on Web pages) to deploy slideshows.
Unlike PowerPoint slideshows, which require either the PowerPoint
software itself or the <a href="http://www.microsoft.com/downloads/details.aspx?FamilyId=048DC840-14E1-467D-8DCA-19D2A8FD7485&displaylang=en" rel="external" target="_blank">Microsoft
PowerPoint Viewer</a> for optimal viewing, S5 slideshows function
in any modern web browser.</p>
<p>A lo-fi system like S5 is well suited to the rhetorical situation
of the slideshow, whose defining characteristic is uncertainty. Slideshows
are commonly projected on unfamiliar computers (often, it seems, with
dubious maintenance records) that a speaker might have access to only
shortly before speaking. Will that computer have PowerPoint installed?
The right version of PowerPoint, at that? If not, will the logged-in
user have sufficient privileges and a network connection to download
the PowerPoint viewer? If all else fails, will a reasonably competent
IT person be present to step in and help?</p>
<p>Such problems, rooted in the inflexible digital materiality of the
PowerPoint file itself, are easily avoided by lo-fi alternatives like
S5: even if the computer runs an outmoded browser (and what computer
doesn't have a browser installed?), S5 or other lo-fi slideshows will
operate more or less as planned—while still being editable (something
not possible in the bundled player-slideshow .pps format of PowerPoint).
Speakers can even keep their slideshow and a <a href="http://portableapps.com/apps/internet/firefox_portable" rel="external" target="_blank">portable
version of Firefox</a> on their USB drives (or CD-ROMs, as some über-paranoid
computer security policies restrict access to USB ports.)</p>
<p>The move away from the seeming inevitability of software like PowerPoint
or Flash brings the aims of the digital genre itself into focus: a
much more flexible, rhetorical approach to production than focusing
on the features and limitations of a given piece of software.</p>
</div>
</dd><dt>2. Digital literacy should reach beyond the limitations of software.</dt><dd style="border-top: medium none; border-bottom: medium none; overflow: hidden; padding-top: 0px; padding-bottom: 0px; height: 0px;">
<div>
<blockquote>
<p>The ability to "read" a medium means you can <i>access</i> materials
and tools created by others. The ability to "write" in a medium means
you can <i>generate</i> materials and tools for others. You must
have both to be literate. <cite title="Page 125"><span>Alan
Kay,</span> "User Interface: A Personal View"</cite></p>
</blockquote>
<p>Acts of digital production should contribute to a deeper literacy
than learning to point and click through an arbitrary set of menus
and dialog boxes. Production literacies of point-and-click, menu-driven
WYSIWYG software are not extensible: beyond exposing users to certain
visual conventions (clicking a 3.5-inch floppy disk icon to save? really?),
learning to navigate Microsoft Word has little bearing on future efforts
in PhotoShop or Flash, much less CSS or MySQL.</p>
<p>Adobe's <a href="http://www.adobe.com/aboutadobe/invrelations/adobeandmacromedia.html" rel="external" target="_blank">announcement</a> in
spring of 2005 that it had purchased Macromedia—the company behind
Flash, Dreamweaver, and other web production software—should have raised
serious questions about producing and teaching too closely with particular
software technologies, which can potentially evaporate as quickly as
the ink dries on a corporate merger.</p>
<p>Yet even adopting community-developed, open-source software is not
necessarily the best response to the inherent instability of corporate
software packages. True, the digital production literacies learned
through open-source software, like <a href="http://openoffice.org/" rel="external" target="_blank">OpenOffice.org</a>,
may be less prone to corporate mergers (though not necessarily corporate
buyouts—witness <a href="http://www.mysql.com/news-and-events/sun-to-acquire-mysql.html" rel="external" target="_blank">Sun
Microsystems' purchase of MySQL</a>, arguably the most popular open-source
database). But community-developed software, like the corporate counterparts
it often mimics, does not inherently provide for an "under the hood"
literate encounter with the materiality of digital production languages
and formats that lo-fi production methods do. Lo-fi operates at the
material level of technology (code); WYSIWYG software (which describes
Web editors as much as word processors, page design tools, etc.) keeps
code and file formats at arm's length by design.</p>
<p>Put another way, lo-fi production methods open access to the languages
that visual interfaces for digital production often obscure: no matter
what producers have to do to order Dreamweaver around, chances are
that Dreamweaver will be spitting out the same (bad) code it always
has.</p>
<p>Production literacies anchored to open, standardized languages have
a longer shelf-life than those tied to WYSIWYG software. Although languages,
like software, are subject to future versions, languages often retain
much of their essential character (e.g., SGML, HTML, and XML look and
behave very similarly—despite the fact that SGML was <a href="http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=16387" rel="external" target="_blank">standardized
in 1986</a>, and <a href="http://www.w3.org/XML/hist2002" rel="external" target="_blank">XML in 2000</a>).
Code written in earlier versions of a language are often viable even
after a revision of the language: producers can still write HTML 4.01,
even though XHTML 1.0 is preferable. But forget about trying to pass
a Word 1.0 document around.</p>
<p>The stability of languages is due, in part, to common ancestors. For
example, there are few scripting languages that are not at least influenced
by C/C++. Learning one language on a family tree prepares one to more
readily learn others. Even languages that are essentially unrelated
(say, CSS and PHP, or HTML and Ruby) share much of the same meta vocabulary:
lines of styles in CSS must be <b>terminated</b>, as must
lines of PHP code. <b>Nested</b> tags in HTML resemble statements
that are <b>nested</b> in Ruby. Prepared with this sort of
vocabulary, digital producers can develop mental models for how languages
operate. They can even leverage exacting Google searches to solve a
wide range of production problems.</p>
<p>Developer communities are the other component of a language's stability.
Multiple active developer communities surround any given open language:
not just in the language's use, but in its development (e.g., <a href="http://www.php.net/" rel="external" target="_blank">PHP.net</a>).
As digital producers develop proficiency in a language, they may be
able to shape the language's future development. Such is the case with
PHP, and in smaller, localized applications of languages, like microformats.
Production literacies should aim to prepare digital producers to talk
back to and shape the communities and technologies supporting digital
discourse.</p>
</div>
</dd><dt>3. Discourse should not be trapped by production technologies.</dt><dd style="border-top: medium none; border-bottom: medium none; overflow: hidden; padding-top: 0px; padding-bottom: 0px; height: 0px;">
<div>
<blockquote>
<p>In an extreme view, the world can be seen as only connections, nothing
else.<cite title="Page 12"> <span>Tim Berners-Lee,</span> Weaving
the Web</cite></p>
</blockquote>
<p>Too many software programs create "roach motels" for content and information:
the data checks in (via File > Import), but it never checks out.
Such digital artifacts—the PowerPoint, the PDF—are only marginal improvements
over the entrapped quality of analog/print information; and in some
ways (e.g., dependence on a specific piece of software to view the
artifact) are actually steps backward from the comparatively open access
that books and other printed matter provide.</p>
<p>The selfishness of closed, roach-motel formats and WYSIWYG software
is implicit in the acronym: What YOU See is What YOU Get. As though
YOU, the producer, were the only one who mattered in the digital rhetorical
situation (<i>if it looks good for me in Dreamweaver or FrontPage</i>,
so the logic goes, <i>it must look good everywhere for everyone</i>).
In a time when screens range between postage-stamp-sized cell phones
and 71-inch flat panel LCDs, it is lunacy to assume that what the producer
sees is what everyone, indeed <i>anyone</i>, else sees. Thoughtful
digital producers should be much more concerned about what audience
members GET than what they SEE.</p>
<p>What audiences should get is flexible, open discourse. The Web and
even the <a href="http://creativecommons.org/" rel="external" target="_blank">Creative Commons</a> are
efforts steeped in the promise of such openness. But a Creative Commons
(CC) license that allows for derivative works of, say, a Web-available
Flash movie is an oxymoron at best (just try to extract an image from
a Flash movie). At worst, the CC license emphasizes gestures of openness
over interrogating the materiality of technologies and their capacity
to support derivative discourse.</p>
<p>To genuinely make digital discourse friendly to derivative works,
it needs to be much more flexible (cut and paste does not count). Ultimately,
end users and their devices should be responsible for combining content
of different media elements—not software or file formats like Flash,
and really not producers, either. The producer's responsibility is
to reference and orchestrate elements that can be accessed in a combined
or piecemeal fashion: only then is a CC derivative-works license viable,
or even honest.</p>
<p>Any given digital artifact needs to be constructed not as a final
resting place for discourse, but as a pause in a stream of further,
unfettered access. A Web page listing an organization's members' names
and email addresses, for example, can be far more open through the
use of <a href="http://microformats.org/" rel="external" target="_blank">microformats</a>. Rather
than cutting and pasting the contents of the page, or returning each
time the page's information is needed, a user can, via the presence
of <a href="http://microformats.org/wiki/hcard" rel="external" target="_blank">the hCard microformat</a> and
a technology like <a href="https://addons.mozilla.org/firefox/addon/4106" rel="external" target="_blank">Operator</a>,
import some or all of the membership's contact information directly
into her own email address book. Once email address books become microformat-friendly,
the address book could query the URL containing the contact information
and update entries automatically.</p>
<p>Single-sourcing with lo-fi XML technologies and their microformat
cousins is an unprecedented and unparalleled method to structure and
openly share content. But dependence on WYSIWYG software has kept producers
in our field and elsewhere largely ignorant of XML. Even the XML backbone
to OpenOffice.org's implementation of the Open Document Type (ODT)
format is a limited use of XML. OpenOffice.org (OOo) appears to do
to XML what FrontPage and Dreamweaver have done to HTML: hacking up
the language to accommodate visual choices (XML is a structural, not
visual, markup language), and needlessly complicating what ought to
be human-readable code into something meaningful only to machines.</p>
<p>Producers command lo-fi technologies at the code level not in service
to machines, but in service to other human beings whose specific technology
access and physical ability are ultimately unknowable.</p>
</div>
</dd><dt>4. Accommodate and forgive the end user, not the producer.</dt><dd style="border-top: medium none; border-bottom: medium none; overflow: hidden; padding-top: 0px; padding-bottom: 0px; height: 0px;">
<div>
<blockquote>
<p>Don't make me jump through hoops just because you don't want to
write a little bit of code. <cite title="Page 164"><span>Steve Krug,</span> Don't
Make Me Think, (2nd ed.)</cite></p>
</blockquote>
<p>There is no better way to lose the good will of audience members than
to bombard them with a series of messages demanding the installation
or upgrade of software and plugins or, worse, to announce that their
equipment (and, perhaps, by extension, financial status or physical
ability) is wholly inadequate and beyond the producer's toleration.
Even worse still may be no message or warning at all: just a blank
screen or hopelessly malfunctioning digital artifact.</p>
<p>End users must be accommodated and respected, even at the expense
of the producer's ultimate vision for a digital artifact. Yet it is
often producers who are, or ought to be, begging for forgiveness (readers
just go elsewhere): posting unusual file types to email discussion
lists, creating Web pages whose hyperlinks only function in Internet
Explorer, building Flash movies when XHTML and CSS would more than
suffice.</p>
<p>Producers deserve no forgiveness for their technological shortcomings
or ignorance. None. A poor technological choice that denies access
to anyone, for any reason, is ultimately a rhetorical problem—particularly
when there are lo-fi technologies, like valid XHTML, that inherently
address issues of access. The time has come to hold our colleagues
and students accountable for their technological choices just as they
would be held accountable for any other rhetorical choice.</p>
<p>This is not about elitism; it is about raising our expectations of
one another to embrace and take responsibility for <i>all</i> of
the rhetorical concerns that comprise the digital medium—not just those
that are easy, obvious, or convenient. So long as producers are relieved
of their responsibilities, either by their audience or by the false
assurances of WYSIWYG software, digital production will only attend
to the question of "How to do this?" when the question ought to be,
"How to do this <i>best</i>?"</p>
<p>Lo-fi production technologies are able to deliver artifacts that are
editable everywhere, and accessible everywhere, too (at least to some
extent). Rather than developing after-the-fact alternative content
(e.g., to make up for a missing Flash movie), producing and inventing
in lo-fi technologies addresses the essential need for users to access
content regardless of their conditions, including physical ability.</p>
<p>Producing accessibile digital artifacts is neither an end in itself
nor a testament to the supremacy of technology over all other rhetorical
concerns. Rather, accessible artifacts arise from the equal application
of care and attention to detail that scholars, in particular, expect
of content.</p>
<p>Readers of accessible, lo-fi artifacts will appreciate not being told
what they must do (even if they are left blissfully ignorant of the
enhanced coolness they may be missing out on); and producers can develop
content and ideas in far less taxing lo-fi environments (compared to
Flash), in far more portable and extensible formats, like XML, with
far greater confidence in audience access than WYSIWYG software could
ever provide.</p>
</div>
</dd><dt>5. If a hi-fi element is necessary, keep it dynamic and unobtrusive.</dt><dd style="border-top: medium none; border-bottom: medium none; overflow: hidden; padding-top: 0px; padding-bottom: 0px; height: 0px;">
<div>
<blockquote>
<p>This is progressive enhancement: it works for everyone, but users
with modern browsers will see a more usable version. We are, in a
way, rewarding them for choosing to use a good browser, without being
rude to Lynx users or employees of companies with paranoid IT departments. <cite><span>Tommy
Olsson,</span> "<a href="http://accessites.org/site/2007/02/graceful-degradation-progressive-enhancement/3/" rel="external" target="_blank">Graceful
Degradation & Progressive Enhancement</a>"</cite></p>
</blockquote>
<p>Ultimately, there are production problems that lo-fi technologies
are not yet poised to solve: vector graphics (at least until the lo-fi
SVG standard is natively implemented in Internet Explorer) and 3D-modeling
are two examples. No browser has native support for sound or video,
which are accessible only through media players and browser plugins.</p>
<p>Even lo-fi typography solutions lag behind their hi-fi counterparts,
like Flash (whose font-embedding capabilities alone drew many in the
graphic design community away from HTML and CSS). Designing with pure
CSS entails limiting oneself to fonts commonly available on most operating
systems. While there are glimmers of hope that major Web browsers will
enable <a href="http://www.alistapart.com/articles/cssatten" rel="external" target="_blank">support
for TrueType Web fonts</a> (fonts that can be accessed over the Web
without requiring installation on an end-user's computer, as in the
case of basic TrueType fonts), for now the lo-fi-ish typography tool
of choice is <a href="http://www.mikeindustries.com/sifr" rel="external" target="_blank">Scalable
Inman Flash Replacement</a> (sIFR, pron. "siffer," currently in <a href="http://novemberborn.net/sifr3" rel="external" target="_blank">version
3</a>). sIFR relies on the lo-fi technologies of plain text structured
in XHTML and JavaScript and a small, empty Flash movie containing only
the font a producer wishes to use on a given Web page.</p>
<p>With sIFR, if a reader's browser lacks or has disabled JavaScript
or the Flash player, the lo-fi CSS styling or simple HTML text will
be displayed instead: a dynamic (and unobtrusive) improvement over
CSS <a href="http://www.mezzoblue.com/tests/revised-image-replacement/" rel="external" target="_blank">image
replacement techniques</a>—another typography work-around, but which
fails in an imageless CSS-enabled environment.</p>
<p>The use of any hi-fi technology should operate much like sIFR: taking
some readily available media element or text, and enhancing it with
extended functionality for properly equipped users—without punishing
lesser-equipped users.</p>
<p>Unobtrusive solutions like sIFR are rare, though. The videos on YouTube,
for example, are dynamically loaded into a shell Flash movie that contains
the controls for playing and pausing the video clip. However, if YouTube
were to be fully unobtrusive, it would offer links in the HTML to movies
in different formats (at least until an open, widely supported format
is available; see "Insist on open standards and formats" below)—not
just the proprietary Flash Video (.flv) format. In the absence of Flash
or JavaScript, YouTube will not function, rendering all of its content
inaccessible.</p>
<p>A dynamic and unobtrusive lo-fi media player solution like Scott Schiller's <a href="http://www.schillmania.com/projects/soundmanager2/" rel="external" target="_blank">SoundManager
2</a> takes simple HTML links to sound files, and makes them playable
on a Web page for users with both JavaScript and Flash enabled (in
the absence of JavaScript or Flash, users are able follow the links
and download the sound files for listening in their own media player).
Users with Flash are rewarded with an enhanced experience; users
without Flash are none the wiser, and can still experience the audio
presented on the page—which is all that the page's producer could
have hoped for. In fact, users without Flash have the added advantage
of being able to download the individual audio files, perhaps for
loading onto an iPod or other portable audio player.</p>
</div>
</dd><dt>6. Insist on open standards and formats, and software that supports them.</dt></dl></div></div><br>-- <br>Roland Gesthuizen - ICT Coordinator - Westall Secondary College<br><a href="http://www.westallsc.vic.edu.au">http://www.westallsc.vic.edu.au</a><br>
<br>"Never doubt that a small group of thoughtful, committed citizens can change the world; indeed it is the only thing that ever has." --Margaret Mead<br>
</div>