4f. Socially prominent electronic media and platforms
The web browser continues to be one of the most significant socially prominent platforms for electronic text, reflecting and guiding assumptions about texts and reading. With the rise of the World Wide Web, text-based browsers such as Lynx, Mosaic, and early versions of Netscape became the most common venues for everyday users to experience hypertext — as opposed to hypertext fiction or digital library interfaces, contrary to some predictions. As browsers began to support a range of media types beyond linked text alone, authors of web pages could integrate images, sounds, movies, and animations into electronic texts without the need for advanced coding. As Netscape Communicator and Microsoft Internet Explorer became the dominant browsers of the late 1990s, their support of scripting languages meant that designers had access to an electronic text publishing system, combined with a multimedia interface, combined with a reasonably advanced programming environment, all in software distributed over the Web for free. Most browsers supported Javacript and Java; in addition, Internet Explorer supported scripts in the proprietary language Visual Basic. Although the prototype-based language Javascript is sometimes seen as a limited language compared to the class-based language Java, both are now used to deliver application-level software via web browsers. For example, the Ajax architecture uses Javascript to integrate several web technologies in web applications that use the browser as their main venue — quite different from the simple text delivery for which browsers were originally conceived (see Garrett).
Of particular consequence to computing humanists is the browser’s handling of interface and functionality, normally viewed as separate components elsewhere. The interface and the underlying functionality that manipulates the data may be closely integrated in a browser-based application, written in the same language (Javascript) and located in the same files. Browser-based tools for software building such as Ajax are not the first to offer this integration, but Kirschenbaum suggests why this kind of integration is important: with much existing technology, “from a developer’s perspective, the interface is often not only conceptually distinct, but also computationally distinct” (2004b, pp. 524-5, emphasis in original); “it wasn’t until the comparatively recent advent of languages like Visual Basic that it even became practical to program both a user interface and an application’s underlying functionality with the same code" (2004b, p. 525). For this latter point Kirschenbaum draws upon Carroll, who notes that in past research on user interface software and tools “an early objective was the separation of the user interface and application functionality into distinct layers. This approach modularized the user interface in user interface management systems [...]. However, layering entrained limitations on the granularity of user interface nteractions" (Carroll, 2002, p. xxxii) We can place Ajax within recent general developments that Carroll describes: “Current approaches favor developing user interfaces and functionality in the same language, either in new languages invented for this purpose, like Visual Basic, or through extensions to standard languages for implementing functionality, such as libraries and toolkits for C++ or Java" (Carroll, 2002, p. xxxii). Perhaps the most important term here is Carroll’s word “granularity,” which implies a level of complexity in text-reader interactions that approaches literary scholarship’s treatment of form and content. Such developments merit the attention of computing humanists as well as web developers.
Browsers are also significant to humanities computing because of their implementation of the OHCO model of textual structure (i.e. text as an ordered hierarchy of content objects). The OHCO thesis and the debate surrounding it are usually associated with text encoding (see DeRose et al., 1990; Renear, 1997; Schreibman, 2002; and Buzzetti and McGann). But it is important to note that the standard Document Object Model (DOM) of web browsers also assumes an underlying tree structure in all texts, where logical nodes cannot overlap. The DOM, as implemented in Explorer, Firefox, Safari, and most other recent browsers, is a programming interface to documents assumed to be pure logical structures, and thus provides many web technologies (such as Javascript and XML) with a shared system for manipulating parts of a document. Without the DOM, browser-based web applications would be impossible to implement.
The DOM is a noteworthy aspect of browser development because of the trade-off it represents to computing humanists: its manipulable logical structure for text allows designers to further integrate functionality with interface in a manner that Kirschenbaum suggests is consonant with humanistic ideas of integrated form and content. Yet the DOM can only provide this structure by embodying a model of text that is far from epistemologically neutral, as the OHCO debate has shown. While most of the discussion of the OHCO thesis has focused on text markup, a surprisingly small amount of attention has been given to the ways in which the OHCO model stands behind every single web page – including some of the very web pages that refute the OHCO thesis (see Buzzetti and McGann, and the online version of McGann’s “Rethinking Textuality”: <http://jefferson.village.virginia.edu/%7Ejjm2f/old/jj2000aweb.html>). Web browsers neither validate nor disprove the OHCO thesis and the positivistic view of textuality it represents; browsers do, however, suggest that questions of fundamental importance to computing humanists are woven into even the most ubiquitous of software applications.
Various plug-ins have made the browser more reader-friendly, notably Adobe's Acrobat plug-ins for reading PDF (Portable Document Format) files that offer the look and feel of the printed page in addition to various modes of navigation, powerful search possibilities, highlighting and commenting capabilities. Acrobat has been integrated with a plug-in from Macromedia that gives a sophisticated rendition on screen of the turning of the page, making the reading of the digital text closer to the actual experience of reading a book. For an example, see <http://www.lemonde.fr/> and click on the link under "Journal électronique". A similar development is the extension system of tools for Mozilla-based browsers such as Firefox. (See the Mozilla Developer Center portal for extensions: <http://developer.mozilla.org/en/docs/Extensions>).
However, we would like to implement new metaphors in order to give the users more control on their reading activity. One conspicuous issue that has not been addressed is "continuous reading", exemplified by the novel whose reading may continue over many days or even months. Some other metaphor-based tools that would be useful to develop in the HCI-Book project are:
- a library metaphor, as a complement to the desktop metaphor for organizing reading activities and maintaining visible the documents being read or that the user plans to read soon. At least two types of bookmarks should be available; various intuitive marks should make it easy to spot the most frequently used;
- a visual tool, which should reveal the importance of a document, how much has been read and how much is left to be read; and,
- a series of icons indicating possibilities of reformatting the text in various ways, depending of the type of text and the goals of the reader; in the printed world, there is a variety of formats, each of which accomodates the nature of its contents; a newspaper is not formatted like a book, and a scholarly book is not formatted like a novel.