[Yr7-10it] The Lo-Fi Manifesto

[Roland Gesthuizen]

Interesting .. cross posting this from the eChalk list.

Regards Roland

---------- Forwarded message ----------

worth a read.
http://kairos.technorhetoric.net/12.3/binder.html?topoi/stolley/index.htm
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 <http://meyerweb.com/>, CSS guru and design wizard, developed
and released
into the public domain
<http://meyerweb.com/eric/thoughts/category/tech/s5/>a Simple
Standards-based Slide Show System <http://meyerweb.com/eric/tools/s5/> (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<http://www.microsoft.com/downloads/details.aspx?FamilyId=048DC840-14E1-467D-8DCA-19D2A8FD7485&displaylang=en>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<http://portableapps.com/apps/internet/firefox_portable>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<http://www.adobe.com/aboutadobe/invrelations/adobeandmacromedia.html>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 <http://openoffice.org/>, may be
less prone to corporate mergers (though not necessarily corporate
buyouts—witness Sun Microsystems' purchase of
MySQL<http://www.mysql.com/news-and-events/sun-to-acquire-mysql.html>,
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<http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=16387>,
and XML in 2000 <http://www.w3.org/XML/hist2002>). 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<http://www.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 <http://creativecommons.org/> 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<http://microformats.org/>.
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 <http://microformats.org/wiki/hcard> and a technology like
Operator <https://addons.mozilla.org/firefox/addon/4106>, 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<http://accessites.org/site/2007/02/graceful-degradation-progressive-enhancement/3/>
"

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 <http://www.alistapart.com/articles/cssatten> (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<http://www.mikeindustries.com/sifr>(sIFR, pron. "siffer,"
currently in version
3 <http://novemberborn.net/sifr3>). 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 <http://www.mezzoblue.com/tests/revised-image-replacement/>—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 <http://www.schillmania.com/projects/soundmanager2/> 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.

-- 
Roland Gesthuizen - ICT Coordinator - Westall Secondary College
http://www.westallsc.vic.edu.au

"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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.edulists.com.au/pipermail/yr7-10it/attachments/20080819/6d5cd355/attachment-0001.html