__    __
         / /_  / /_    ___  __     ____            ______  ____
        / __/ / __ \  / _ \/ /    / __ \          / ____/ /  _/
       / /_  / / / / /  __/ /    / / / / ______  / /_     / /
       \__/ /_/ /_/_ \___/ /___ / /_/ / /_____/ / __/   _/ /  __
            /  |/  / ___/_____/_\____(_) / __/ /_/    _/___/ / /_  ____
           / /|_/ / / __ `/ / __ \  / / / /_  / _ \  / ___/ / __/ / __ \
          / /  / / / /_/ / / / / / / / / __/ /  __/ (__  ) / /_  / /_/ /
         /_/  /_/  \__,_/ /_/ /_/ /_/ /_/    \___/ /____/  \__/  \____/


      + - + - + - + - +   + - + - + - + - + - + - + - +
      | K | A | R | L |   | S | T | O | L | L | E | Y |
      + - + - + - + - +   + - + - + - + - + - + - + - +

Preamble

The time has come to reject expensive consumer and prosumer software that hinders the extensibility of digital discourse and limits digital production literacy to programs and file formats that are destined for disruptive upgrades or obsolescence.

Digital scholars in the loosely defined fields of rhetoric and composition, computers and writing, and technical communication should create free and open source artifacts that are software- and device-independent. Discourse posted on the open Web can hardly be considered free if access requires costly software or particular devices.

Additionally, the literacies and language we develop through engaging in digital scholarship and knowledge-making should enable us to speak confidently, unambiguously, and critically with one another about the intricacies and methods of digital production.

And as teachers, we should actively work to provide students with sustainable, extensible production literacies through open, rhetorically grounded digital practices that emphasize the source in “free and open source.”

Defining Lo-fi Technologies

Lo-fi production technologies are stable and free. They consist of and/or can retrograde to:

  1. Plain text files (.txt, .xml, .htm, .css, .js, etc.)
  2. Plain text editors (Notepad, TextEdit, pico/nano, vi, etc.)
  3. Standardized, human-readable forms of open languages expressed in plain text (XML, XHTML, CSS, JavaScript, etc.)
  4. Single-media files (image, audio, video) in open formats

Despite their humble, decades-old base technology (plain text), innovative uses of lo-fi technologies can be remarkably hi-fi, as in the case of AJAX (whose most famous application may be Google’s Gmail service).

Lo-fi is LOFI

“Lo-fi” describes a preferred set of production technologies that digital producers should strive to command, but as an acronym, LOFI outlines four principles of digital production that are essential for the advancement, extension, and long-term preservation of digital discourse:

Manifesto

1. Software is a poor organizing principle for digital production.

“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 principle do you use?” John Maeda, The Laws of Simplicity

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.

But consider a software-independent, lo-fi alternative to PowerPoint: Eric Meyer, CSS guru and design wizard, developed and released into the public domain a Simple Standards-based Slide Show System (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 Microsoft PowerPoint Viewer for optimal viewing, S5 slideshows function in any modern web browser.

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?

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 portable version of Firefox on their USB drives (or CD-ROMs, as some über-paranoid computer security policies restrict access to USB ports.)

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.

2. Digital literacy should reach beyond the limitations of software.

The ability to “read” a medium means you can access materials and tools created by others. The ability to “write” in a medium means you can generate materials and tools for others. You must have both to be literate. Alan Kay, “User Interface: A Personal View”

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.

Adobe’s announcement 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.

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 OpenOffice.org, may be less prone to corporate mergers (though not necessarily corporate buyouts—witness Sun Microsystems’ purchase of MySQL, 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.

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.

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 standardized in 1986, and XML in 2000). 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.

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 terminated, as must lines of PHP code. Nested tags in HTML resemble statements that are nested 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.

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., PHP.net). 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.

3. Discourse should not be trapped by production technologies.

In an extreme view, the world can be seen as only connections, nothing else. Tim Berners-Lee, Weaving the Web

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.

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 (if it looks good for me in Dreamweaver or FrontPage, so the logic goes, it must look good everywhere for everyone). 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 anyone, else sees. Thoughtful digital producers should be much more concerned about what audience members GET than what they SEE.

What audiences should get is flexible, open discourse. The Web and even the Creative Commons 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.

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.

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 microformats. 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 the hCard microformat and a technology like Operator, 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.

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.

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.

4. Accommodate and forgive the end user, not the producer.

Don’t make me jump through hoops just because you don’t want to write a little bit of code. Steve Krug, Don’t Make Me Think, (2nd ed.)

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.

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.

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.

This is not about elitism; it is about raising our expectations of one another to embrace and take responsibility for all 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 best?”

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.

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.

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.

5. If a hi-fi element is necessary, keep it dynamic and unobtrusive.

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. Tommy Olsson, “Graceful Degradation & Progressive Enhancement”

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.

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 support for TrueType Web fonts (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 Scalable Inman Flash Replacement (sIFR, pron. “siffer,” currently in version 3). 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.

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 image replacement techniques—another typography work-around, but which fails in an imageless CSS-enabled environment.

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.

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.

A dynamic and unobtrusive lo-fi media player solution like Scott Schiller’s SoundManager 2 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.

6. Insist on open standards and formats, and software that supports them.

Because they share a common parent and abide by the same house rules, all XML applications are compatible with each other, making it easier for developers to manipulate one set of XML data via another and to develop new XML applications as the need arises, without fear of incompatibility. Jeffrey Zeldman, Designing with Web Standards, (2nd ed.)

Digital artifacts should outlast the software that played a role in their creation. Insisting on open standards and formats, not software packages, is the only way to make this happen.

Software should not be selected based on its high-end features or the size of its installed user base in corporate settings. We should not trick ourselves into thinking we can better prepare students for the workforce by teaching exclusively the most commonly used word processor or page design software. Instead, we should provide students with a digital literacy that enables them to focus on the rhetorical situation of digital production, which includes familiarity with open standards and formats, and to command any production method, software-enabled or otherwise, that supports them.

Despite all of the open standards for text and images listed above, it’s astounding that there are not yet open standards for sound or video. The Ogg media container and its Vorbis and Theora CODECs, for sound and video respectively, are both promising solutions (especially because they are the preferred media formats on Wikipedia, particularly the Wikimedia Commons). Unfortunately, at present, Ogg formats require CODECs to be downloaded for use within other media players, adding an extra step beyond downloading Windows Media Player, QuickTime, or other audio/video players. (However, there is talk of native Ogg support within Firefox, meaning that Firefox could play Ogg audio without an additional plugin. At present, Firefox is expected to couple this functionality with the multimedia-oriented HTML 5 Draft specification, which is competing, somewhat, with the W3C’s more XML-like structure-oriented XHTML 2 draft spec. For a simple overview of HTML 5, see Hunt, 2007.)

There are any number of venues to consult regarding language and format standards. Standards for languages are openly available from the W3C (e.g., XML, XHTML, CSS) and ECMA (most notably ECMAScript, the standard version of JavaScript). But there are other standards, from character sets at ISO to file formats and MIME/Internet media types at IANA. And if all else fails, particularly regarding choices of single-media files, producers may wish to consult the United States Library of Congress’s developed and adopted standards.

Innovation in the digital medium is not to be found on the paved cow paths of point-and-click, template-driven, fill-in-the-blank WYSIWYG software. Indeed, much of the exciting work on the Web involves working beyond the relatively simple languages of XHTML and CSS; the Application Programming Interface (API) and the Integrated Development Environment (IDE) are where the real envelope-pushing action is. But without the kind of source literacy gained from basic languages like XHTML, members of our field and our students will be wholly unprepared to build or command APIs or function competently in IDEs.

Source literacy holds the key not only to more sustainable and accessible digital discourse, but to our ability to substantively contribute to the many open-source projects, like Drupal, Moodle, and even Firefox, which would no doubt benefit from the expertise and values that members of our field have to share.

http://kairos.technorhetoric.net/12.3/topoi/stolley/

References