The Lo-Fi Manifesto did not fail to deliver the cringeworthy experience I usually have when reading my own writing. But I didn’t let that deter me from writing the commentary below on the original version of the manifesto. –KS

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.

This is an opener that sounds good (The time has come!), but it really doesn’t say much. It also seems to suggest that if you haven’t already adopted lo-fi technologies and approaches, there’s no hope for you. But that’s not true at all: a lo-fi approach can be chosen at any time, with each new project that comes along. It’s never too late.

I also think the expensive consumer/prosumer stuff is less of an issue than it once was. Now I’m more concerned by hosted stuff beyond users’ control, or monolithic systems that are deployed without much exploration of alternatives, things like Drupal and WordPress. Cost is sort of beside the point, and constrained budgets have certainly helped to force the turn to ready alternatives.

Maybe worst of all, digital discourse is an unnecessary mouthful. It’s writing. Just writing. All of it. So I should call it that. No one is going to come running for help because they have detected a problem in their digital discourse.

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.

Ugh, digital scholars.... It makes for a nice self-important pairing with digital discourse, doesn’t it? There’s just something so off-putting about that. Maybe it’s the original motivation behind this sentence, which was my pursuit of tenure and trying to make the argument that the kind of digital work I do is scholarship. But given how far and wide Lo-Fi has gone, naming a specific category of people just rings hollow and kind of elitist in ways that make me feel embarrassed now.

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.

...that digital scholars line sets up the we and us here and throughout to feel even more like an in-group thing. I’m trying to cut we and us out of my writing, anyway. I don’t mean them in the royal sense, and I should know better than to try to be a spokesperson for anyone but me.

But as to the point of that third paragraph: people still struggle with the words they need to talk about digital production. I just don’t know, however, if what it takes to make and talk about sophisticated digital work can be accurately called literacy. Introducing terminology like that can make for additional confusion. Literacy is a familiar, comfortable, and high-value word in and around rhetoric and writing studies. But it’s also a troublesome binary: someone is literate, or not. That’s not useful to me. I’ve come to use learning where I would have used literacy in the past, if only because learning doesn’t lend itself to that binary. Learning also suggests, at least to me, something that is always ongoing. No destination, no minimum or maximum level of competence. Not the same can’t be true for literacy, but with learning, I don’t think there’s any ambiguity.

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.”

That last paragraph illustrates the really serious weakness of the original Lo-Fi Manifesto: it was long on pronouncements and very short on guidance. I suppose that is typical of manifestoes generally, but it feels irresponsible to me now to call have called out teachers and not have followed up with some better, actionable specifics. To actively work to provide... is about the weakest pedagogical directive I can think of now.

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

That list is still good, although it strikes me that the part most obviously needing revision is the list of editors. Windows’ default editor Notepad is almost as bad as OS X’s TextEdit. Yes, they are text editors, but no one in their right mind should use them except as a desperate last resort. Not now, and not back when the original manifesto came out, either. Delicious irony, being burned by the same proprietary software that the rest of the manifesto rails against.

So why did I include them in the first place? Probably just to illustrate that some lo-fi tools are already available on most operating systems. (And if you’re cool with command-line editors, you’re going to opt for Emacs or vim, not vi, and look down your nose at pico/nano.) I’m not certain of the situation on newer versions of Windows, but Notepad through at least XP was unable even to edit in UTF-8/Unicode. Forget about syntax highlighting. And TextEdit out of the box looks more like a word processor than a plain-text editor, because it defaults to Rich Text Format. It takes a lot of configuration to get it to edit plain text in a plain-text way. And even then it still lacks syntax highlighting.

But that raises another quality I should have included in addition to stable and free: lo-fi technologies are modular and swappable. They can be talked about in general categories rather than by brand name. It’s actually a good exercise to work across different pieces of software for the same project. Sometimes one editor will make obvious a feature that’s really useful, but carefully hidden, in another. But more than that, I find working across multiple different pieces of software to be just the reinforcement needed that what matters most is what you can research and learn, not what you have installed.

On another point that is here and throughout the manifesto: I’m far less of an XML fanboy than I used to be. Lighter weight and more forgiving data serialization formats, like JavaScript Object Notation (JSON), can do XML’s job without the overhead of an XML parser and its preference to shut down when it encounters even a single error.

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).

That paragraph was a big mistake. It was really irresponsible of me to suggest that making something like Gmail or working with AJAX is possible with just plain text and an editor. Lo-fi production requires a much richer environment for writing and testing, including Unix-like operating systems that make it easy to run network services or even a basic web server behind a firewall and on your own local-area network. The list of technologies here, from that perspective, is incomplete.

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:

I promised principles in that paragraph, but what follows is really just more technology stuff: particular side-effects and outcomes of lo-fi technologies, maybe, but not really any principles that go into making things. Everything in the LOFI acronym is an adjective, but principles are actually nouns. Of course, as they are written, these are really four qualities of technologies, not production principles.

  • Lossless: Discourse presented through lo-fi production technologies neither degrades nor becomes trapped in the production itself. Text migrates and transforms from a single source (e.g., XML, or an application of XML) to any number of other devices and artifacts; images, video, and other media elements maintain their integrity as individual files that are orchestrated with one another at a reader’s moment of access, not at the producer’s moment of File > Import or File > Save.

    Beyond being a technology point, that treatment of losslessness is misleading. Lossless, uncompressed files should be preserved, especially for media elements, but those are probably not the same files that should be presented to casual readers. That’s especially true in an age of mobile Internet access that is still often slow and costly.

  • Open: Lo-fi artifacts’ source code and media elements are available for inspection, revision, and extension outside the scope of any one piece of production software and any one producer. Openness includes and encourages end-user/reader customization and repurposing.
  • Flexible: Discourse artfully and rhetorically created with lo-fi production technologies can be experienced unobtrusively in multiple ways by different users equipped with a wide variety of conventional, mobile, and adaptive devices—all from a single artifact. No plugins, special downloads, or device-/reader-specific artifacts are required.
  • In(ter)dependent: Lo-fi production technologies direct orchestration (like a recipe), not composition (like a TV dinner), allowing users and their devices full control to render (or not) and perhaps repurpose the media elements that constitute a digital artifact.

    Interstitial parentheses drive me bonkers. I’m sorry that I included them here. It should have just been independent. See? It’s better just to pick one, and go with it. Don’t offload the tricky work of qualification onto punctuation marks.

    That apology out of the way, most of the stuff under Independent could be a part of Flexible. It’s really basically the same thing, the way I outlined them here.

    But to genuinely make these items into actual principles that matter to me in 2016, I would rewrite the acronym as Learning (not Lossless); Openness (to keep a noun form going, which also invites thinking about the quality of openness in general, versus the open/closed binary); F can still be Flexible, but as its noun form Flexibility. And because the idea of Independence can be split up between Openness and Flexibility, it makes room for another, more important principle: Iteration. Multiple versions, careful revisions. That might be the most important principle, because it ties the other three together and makes an ongoing pursuit of them possible.

Manifesto

Quick commentary just on the basic manifesto points, taken together.

Points 1, 2, and 3 are saying basically the same thing: Don’t think about production just in terms of software that limits what you can learn and traps what you make.

Point 4 is just harsh. The running text is even worse.

Point 5 still makes some sense, maybe, but as the now 100%-obsolete running text proves, the principle isn’t too sound to begin with. It would be better to question more thoroughly whether a hi-fi element seems necessary, and to fuel that investigation with some serious research.

Finally, Point 6 is little more than another way of saying or leading into what is behind Points 1, 2, and 3.

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

I'm still a big fan of the Maeda epigraph here. It says what this manifesto point can only elaborate on.

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.

More in-group stuff. The problem of software defining the scope of production belongs to more than a single group. It’s everywhere, for everyone. And honestly, who other than people who study rhetoric search Google for rhetoric of slideshows? Perhaps there is a more common search phrase with similar results to those.

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.

S5 is still a viable project. And now there are even more impressive lo-fi-style systems available, like Reveal.js.

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.

Those closing three paragraphs contain some of the most solid stuff in the manifesto. Although it’s getting harder to find computers that still have optical drives in them, the rest of the issues raised here remain. And it’s not just slideshows that have those troubles, but any device anywhere that’s opening someone else’s digital work.

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”

I will always like Alan Kay and this epigraph, but as I mentioned earlier, I have not seen the term literacy work the magic I thought it would in motivating people to learn new things. Learning is what is really at stake, so it’s better to call it out directly.

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.

Flash is basically dead now, even though Adobe plans to push ahead with a new version of the software under a different name. Meanwhile, Facebook announced that it is dropping Flash-based video in favor of HTML5.

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.

The bigger issue that goes unstated here is that WYSIWYG is a concept that originated with trying to align the onscreen representation of a printed document with the printed document itself. WYSIWYG is often championed for its supposed user-friendliness, but its status as a relic of print culture should not go unnoticed by those who want to create work across the range of screens that receive digital content.

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.

Most of this rings pretty true to me still. But as with much of the manifesto, there needs to be some actual guidance in play, not just lists of things that apparently pass some weird Stolley/lo-fi litmus test.

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

Weakest epigraph in the whole manifesto. What does that even mean?

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.

That paragraph is as true as ever. Licensing really is only one small piece of the puzzle of making something more open. It’s not just the end product, either, but its history and and false starts.

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.

Burned again by specific software. Operator used to be a pretty great plugin on Firefox, but it has since gone to rot and I just get sad thinking about it. The Chrome version seems to be okay, at least. But the more important thing to note here is that microformats are now part of the HTML5 specification. There is always a worthwhile distinction to be made between the stability of thing you can write yourself with source code and plain text and the instability of any specific piece of software used to access it.

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.

Ah, single-sourcing. The content manager’s pipe-dream of the 2000s. Turns out that it is a lot easier to manage a single source than it is to plan for an open-ended, distributed number of destinations. And that is of course what really matters.

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.)

I should never have opened with that cranky quote from Krug, because it just helped me unleash the monster I became in this section. What can I say about my tone here? I was barely out of my mid-twenties when I wrote it. And I enjoy getting angry sometimes. But what follows is not helpful to anyone, especially the poor students who have been assigned to read this thing for class.

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.

Some good points here, buried in amongst all the drama of people begging for forgiveness.

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?”

Actually, I’m pretty sure that actually was about elitism. This whole section was such a missed opportunity to do some good and offer some help and guidance. I could have also been a bit more humble and direct about an important fact: I was once pretty awesome with Flash and Dreamweaver and a lot of other stuff that I disparage here. It was only through dissatisfaction with those technologies, and middle-of-the-night panics over how what I was teaching was so inextricably bound to them, that I came to discover that software is, beyond a certain narrow threshold, really an impediment to learning the things necessary to grow beyond that threshold. Bad as it now seems to me, that software was just the thing I had to experience first in order to learn the stuff I value now.

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

Nothing in this section is true any longer. You can ignore pretty much all of it. It does have some historical value, I guess, as it does show the sorry state of trying to do web typography or native audio solutions in the early 2000s. But it now reads like a testament to how quickly, if not how uniformly, web standards have evolved to solve these problems in the intervening years.

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.

SVG is here, and there are no shortages of polyfills for it, not to mention good-old image fallbacks for the few remaining browsers in use that don’t support it. WebGL and other web standards are making high-quality 3D rendering possible right in the web browser. CSS3 even has entire 3D-tranformation and animation modules.

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.

CSS @font-face is now widely supported, and works in tandem with the original CSS font properties to deliver rich web typography beyond old-school system fonts. Licensing is the primary sticking point with web typography, which is why services like Google Fonts, Adobe Typekit, and Fonts.com are so popular (that, and they prepare and serve the font-face stacks over their own content delivery network, CDN).

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.

Maybe. But really, the lesson now is to keep looking for a lo-fi approach to production. Something that now seems inevitable and hi-fi-only will eventually be replaced by an open, lo-fi counterpart.

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.

YouTube offers HTML5 embeds now, although it’s not yet possible to easily load YouTube videos with the <video> element directly. YouTube itself uses HTML5, and as I mentioned above, even Facebook has moved to HTML5 video.

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.

HTML5 introduced the <audio> element, which works with MP3 audio files. Browsers that do not support the element can still be presented with the MP3’s URL for download and playback elsewhere. Hi-fi elements are basically unnecessary. But they’re easily turned to in the absence of research to carefully frame a production problem.

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.)

I really was in love with XML.

Sadly, though, this whole section is sort of a five-paragraph essay’s fifth paragraph. It does not say much that the other points, especially the first three, don’t already say better. Had it begun with In conclusion, ..., it would have been perfect.

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.)

HTML5 (not HTML 5) became a W3C recommendation; XHTML 2 was abandoned, in large part because of its non-backward-compatible insistence on XML-based errorless purity. Media CODECs continue to suffer from lack of uniform implementation, largely because of patent issues. But there are lo-fi ways of working with and around those issues.

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.

Yeah, no. Most developers are not going consult specifications documents as part of the routine research needed to write HTML or any other language. Community-maintained documentation at WebPlatform.org or the Mozilla Developer Network is a much more friendly and useful resource. Save the specifications documents for settling nerdy barroom bets about whether a particular global attribute has been deprecated in HTML5.

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.

I regret putting in anything about IDEs. I did that because the nameless Reviewer #2 of the original manifesto made it a point to lecture me about how important IDEs are. Well, Reviewer #2, you were wrong, and I wish I hadn’t heeded your advice. Yes, there are still plenty of IDEs in the world, some of which you absolutely must use (like Xcode to build Apple iOS and OS X applications). But for most other things, IDEs are unnecessary and come with the same resource-hungry overhead as the worst WYSIWYG software. Skip the IDE. Bring your own text editor, your own version control system, and your own modular development and testing environments. You'll push the envelope just fine. Languages like Ruby demonstrate that you don’t need an IDE and probably will be much happier and more productive without one.

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.

I still like that idea. I don’t think it’s likely to happen though, at least until there is widespread respect for and engagement with the expertise and values that drive those communities already. There definitely is no need for the priest-like intercession that I appear to be calling for here.

References