Ebooks, Libraries, and Feelies

by Daniel Punday

Suddenly, reading has the become subject of broad public excitement and debate - sprinkled as it's been with the magic pixie dust of consumer electronics marketing. How will we read in the future when books, like every other type of media, have become fully digital? Not a day passes, it seems, when some new ebook reader is announced. This month at the Consumer Electronics Show, Steve Ballmer made his pitch for Windows-based tablet computers by demonstrating their ability to run a Kindle ebook reader. What a strange moment, when books are the hot topic of electronics marketing.

Electronics companies, reviewers, and technology writers all seem to agree that books will eventually - and perhaps even quite soon - be read primarily on some electronic device, which will manage our personal library and allow us to carry 1,500 books (as the Kindle currently promises). The only question is what this device will look like. Will it have a keyboard? A color screen? Will it support video and web surfing, or remain focused narrowly on the long-battery-life but limited-display-range of E Ink? Will the screen imitate the large-format of a glossy magazine, the somewhat smaller size of the textbook page, or the personal proportions of the paperback? Whoever manages to find the right combination of features, the thinking goes, will not only sell millions of the thing, but will have the opportunity to create a marketplace for ebooks equivalent to iTunes, which in 2008 pulled off the equally unlikely trick of becoming the leading seller of music in the U.S.

It's not hard to understand why this topic has caught the public's attention, since it has all of the elements that U.S. audiences love in their business stories: a clear set of mutually adversarial players (PC vs. Mac, Coke vs. Pepsi, and now Kindle vs. Nook), the promise of some technological innovation that rejuvenates an old product, and, most important, something to buy.

Unexamined in this race to make the best ebook reader is the role of the electronic library, which is supposed to be the heart of the device and its appeal to the consumer. It seems inevitable that an ebook reader will contain a "library" of books organized for easy browsing, from which the reader will select one to read at a time. In fact, for most people writing about ebooks, the device-library link is the essence of electronic reading. This might come as a bit of a surprise to readers of ebr and those of us who have been following the fortunes and peregrinations of electronic textuality from Afternoon to Inanimate Alice - none of which fit into a "library." For writers and critics of such works, electronic writing means many things - reader participation, multimodal experience, community involvement in the creation process - but not integration of the work into a library.

I'd like to suggest the relationship between the library and electronic text is a fundamental fault line that will shape the landscape of reading in the near future.

1.

The concept of the library seems like a happy point of convergence between literary and computer culture: books on a device for reading are like books in a physical library. The analogy quickly breaks down, however. One of the nagging problems in library-based electronic devices is the concept of "lending" a digital text. To a large extent, public libraries exist to lend books out, and the process of books coming and going through the library's doors is one of the surest signs of the vibrancy of the institution. There have been several attempts to extend the concept of lending to electronic libraries, with limited success. Microsoft attracted general derision when it promised that the Zune would improve on the iPod because it has the ability to "squirt" a song from one player to another. This form of digital sharing is an odd mixture of old-fashioned lending (since the two Zunes between which the song moves have to be physically close) and uniquely digital qualities: the song does not leave the original Zune (the original user can still listen to it) and the squirted song is laden with DRM restrictions (it remains on the Zune for only three days or three plays). The Nook ebook reader integrates a similar lending structure for books, with similar quirks. As with traditional libraries, books that have been lent cannot be used by the lender while they are "gone." But the Nook limits lending to a single instance per book; each book may be lent only once, ever.

Probably the single best example of the problem of digital libraries is the snafu over Amazon's decision to remotely remove copies of Orwell's 1984 from Kindles when it discovered that it was inadvertently selling an unauthorized copy of the book. Annotations users had made to the book vanished, prompting threats of a lawsuit and hasty apologies from Amazon's CEO Jeff Bezos. The possibility that an item, whether purchased legitimately or not, might simply disappear from a library has no equivalent in a physical collection of books, and suggests that beneath the metaphor of the Kindle holding a "library" of books is a very different relationship between device and electronic services.

These problems of bringing lending to the electronic library suggest the limitations of what seems like a natural analogy. I think, however, that there is a deeper and even more problematic tension between the understanding of the word library in biblio- and computer-centered environments. When we speak about a library that holds physical books, we understand that both the building and the more abstract library institution are secondary entities that serve to organize independent objects. That is to say, books exist before the library, can be moved from one library to the next, and even if every library in the world somehow disappeared, our reading life would largely be the same - if somewhat more cluttered. Books are independent of libraries.

Of course, I'm putting the matter simplistically. Most books published today include Library of Congress and Dewey Decimal categorizing information on their copyright page. Furthermore, books are written and, especially, published because they fit into recognizable and marketable categories. These are institutional conditions that pre-exist and shape books. Books are not like species discovered in the wild and categorized by biologists; instead, the categories themselves in part define the books that are written, published, and read. Still, we recognize in a commonsensical if somewhat naive way that books are separate from libraries: if we discarded the Library of Congress categories or dismantled the public library system, the physical book would remain and not disappear from our shelves like Amazon's Kindle version of 1984.

The use of the word library in a computing context is strikingly different on this point. Modern programming languages work by reusing vast chunks of standardized code; in fact, it is a principle of good programming to make any code as general and thus re-useable as possible. Sometimes this is done within a single program, where one particular bit of code might be invoked multiple times to perform the same function in different contexts. Sometimes code is reused by an individual programmer or software company, where the same bit of code might be used in different projects. The concept of code reuse is built right into modern programming languages. These languages each have what is referred to as a standard library of commands, types of data objects, and functions. This library is usually so large that all of it is not automatically included in every program; instead, programmers have to issue some command to copy the parts of the library that make the necessary objects and functions work. Here for example is a very simple program written in the common programming language C (borrowed from an online tutorial):

#include <stdio.h>

int main()
{
int this_is_a_number;

printf( "Please enter a number: " );
scanf( "%d", &this_is_a_number );
printf( "You entered %d", this_is_a_number );
getchar();
return 0;
}

All this program does is ask you to input a number and then display it back; it's a simple example of how a C program handles input and output of variables, which is why it is used at the beginning of this tutorial. But even this simple program depends on the command "include" at the beginning, which imports information from a file called "stdio.h." This file contains information about how to display output and receive input from the keyboard; because that's included in this file, the programmer doesn't have to tell the computer what commands like printf and scanf mean. The file "stdio.h" is one part of the standard C library, and there are many other files that include routines such as the handling of character strings in "string.h," time values in "time.h," and so on.

It is easy to see why programmers like the reuse of code, which can radically streamline the creation of complex software. The existence of a standard library of programming code is one of the reasons why programs written for a particular operating system tend to look and work the same. Apple OS X, for example, provides a standard library of functions that draw windows on the screen, open dialog boxes to save and load files, and so on. Most individual programmers have little first-hand experience with the code to create these visual elements; they simply need to know which elements of the library to include and which routines to use to have the elements created.

It seems natural to refer to this resource of pre-written code as a library. It is a larger body of material on which an individual programmer may draw; and like a physical library, it depends on categorization and, especially, standardization. It is precisely because this code is organized into recognizable chunks that it can be "included" in a program. But we should also recognize how radically different this programming library is from a physical library. As with all of the electronic libraries that I have already mentioned, a central departure of this programming library from a library of books is the fact that there is an infinite number of copies of its items. In a library of books, the individual copies can be only one place; if a library has a single copy of a book, only one patron may have it at once. The principle of the programming library is quite the opposite: anyone can include "stdio.h" who needs it. The possibility of infinite "copies" of a library item is, of course, precisely what makes the restrictions on lending books in the Nook or squirting songs on the Zune so strange.

But I don't think that this is the most important point on which the print and computing understandings of the word library differ. Much more important, I think, is the different identity of the components themselves. As I suggested before, books are generally (although not entirely) independent of the libraries in which they might be included. Programs, however, are entirely dependent on their libraries. Indeed, computing libraries make programs dependent on larger community structures. A program may be written to do one thing and function perfectly well; if the library on which it depends changes, the program could end up doing something quite different - or, much more likely, fail to work. The program itself - at least the part that programmers have written directly - has not changed, but the library upon which it depends has. Dependence on libraries in fundamental ways takes the operation of the program out of the hands of any individual programmer, and makes it subject to the conditions and quirks of the library. In this sense, the computing library turns programs into fractured and contingent objects. While we might imagine books without a library, we cannot write, understand, or compile programs without their libraries.

2.

I would like to offer these two models of the library as a fundamental division that organizes our understanding and use of digital media objects now and in the future. One model emphasizes the independence of the component elements; let us call this an accumulative library. The other makes those elements dependent on the larger library structure; let's call this the modular library. And when we refer to an ebook library - as news reports, advertising, and commentary within the tech community has done so much over the last year or two - we are often blurring these two ways of thinking about the library.

It's probably no surprise that the general evolution of the handling of digital media objects over the last decade has been towards the model of the modular library, and away from that of the accumulative library. In a general way, the model of dispersed identity and dependence of item on library emerges any time institutions and mechanisms achieve broad acceptance. This is why the Library of Congress and Dewey Decimal codes can be integrated right onto the copyright page of newer books. Digital artifacts tend to be integrated into libraries when a format for doing so achieves general acceptance.

So far, I've described these issues in pretty abstract terms. But let's take a very specific and concrete example. If you go to your computer and examine the folder containing iTunes music, you'll see a file structure that looks something like this:

This is actually a relatively transparent list, in which information about the library is stored in this XML file, and the individual song files appear inside the "iTunes Music" folder. We could say that the individual songs that make up your music collection remain relatively autonomous here. Sure, they require specialized software to play, but we could make a case that the iTunes library is more or less the sum of its parts - that is, it is relatively accumulative. But even here, the structure of the library is not exactly mirrored in the structure of the files; we have to go through the XML file to make much sense of playlists, for example. This XML file represents the point at which the iTunes library becomes something more than just a collection of individual files.

The iTunes library remains a minimally-modular library. In fact, it looks more like a collection of independent objects than most other digital libraries. In large part, this is the result of the very fraught relationship between Apple, music publishers, and consumers. Apple is clearly trying to talk a very fine line between consumers' desire to own their music and publishers' desire to control its (re)distribution (see, for example Steve Jobs very careful response to claims of Apple's monopoly in his 2007 post "Thoughts on Music"). In fact, despite Palm's claim that iTunes represents a monopoly and should be forced to allow other phones (like its Pre) to sync music, Apple has made the library structure of iTunes relatively transparent and easily read by a variety of programs, which can use the XML data to access the iTunes library.

If we stay in the Apple environment but move away from the politically-charged topic of music, we can see the logic of the modular library asserting itself even more forcefully. When I go to iPhoto on my Mac and look inside the "Pictures" folder, I see that the iPhoto library is represented as a single object with no separate files for individual pictures:

The visual contrast between this single iPhoto entity and the hierarchy of files that make up iTunes encapsulates the two models of the library that I've been describing. I can open this monolithic file by choosing the somewhat obscure command "show package contents," and get closer to individual files,

but the organization of this data is much muddier than in iTunes, and the identity of individual pictures is much harder to pinpoint. iPhoto saves individual images in several redundant places (in the "Originals" and "Data" folders) and abstracts out part of the image to make a separate file for face recognition. And, of course, like iTunes, iPhoto has organizational metadata that is contained nowhere within its on-disk file structure.

Integrated library files are hardly unique to the Apple OS environment. If you look for an individual email message that you received in Microsoft Outlook, for example, you will not find it as an independent entity on the hard disk; messages are not saved by that program as individual files, but instead as components of a single "Personal Folders" (.pst) file type that itself is stored in an "Application Data" folder within the "My Documents" folder for that particular user. And, of course, Outlook's file structure is even more complex when connected to an Exchange server, since data files on your personal computer are simply a local copy of the server data.

Although it is difficult to find an email program today that saves messages as individual files, it is certainly still possible to manage pictures on a computer as a system of JPEG files and folders. Of course, in doing so we give up much of the organizational power that a modern photo-management program like iPhoto brings to the task, including the automatic grouping of images and advanced features like the ability to sort by location or people who appear in the image. Most of us are willing to sacrifice the transparency of individual image file structure and identity for the convenience of these features. And it seems clear that the general evolution of digital media management is away from discrete files (for an image or song) towards programs that create libraries of these media. Libraries add organizational power, but make the individual media artifacts less and less autonomous.

3.

So, where does the ebook fit in this trajectory?

As we might expect, early ebooks were much like early TIFF and MP3 files: treated as independent items to be placed in folders on a hard drive, and interpreted using one (of many possible) programs. Even today, Project Gutenberg retains this transparent file structure, since it allows users to download books in many different file formats. Each of those books is simply saved to your hard drive, and how to organize these files is left up to the user:

Until the last couple of years, ebooks have had no iTunes-like major player that has offered to integrate these individual files into vast libraries. Plenty of software for the purpose exists, of course, like Sony's eBook Library, which will seek out individual ebook files in a variety of formats and integrate them into the library:

The hallmark of ebooks has been the dizzying diversity of sources and formats, and most ebook programs (and physical devices) make some effort at inclusion by reading a variety of formats.

For many book buyers, the degree to which ebooks remain potentially or actually independent of their libraries is purely academic, and only matters when they encounter some sort of restriction they are unwilling to live with. Although many in the tech community complained for years about Apple's DRM restrictions, for most everyday users these limitations were either invisible or trivial. The same is true of images as well: while the library structure of iPhoto makes individual images hard to find at the disk-level of the Finder, a simple export command and drag and drop control of the images makes the complexity of the library file structure usually invisible to users. It is for this reason that our interaction with the digital artifacts that we "own" - music, pictures, and to a lesser extent, movies - has been moving steadily towards the model of the modular library. Today we are much less likely to sort our music files at the level of the OS X Finder or Windows Explorer, and much more likely to depend on a specialized program like iTunes to do it for us.

There is, I think, a special reason to be wary about the model of the modular library being extended to ebooks, however. Throughout its history, the book is an object whose design has been relentlessly changed and refined: from scrolls to codex pages to HTML links. Even in the relatively recent past since the rise of cheap mass printing in the eighteenth-century, publishers, artists, and authors have constantly revised basic elements of book design. We might initially think of radical and one-of-a-kind book designs of the Artist Book movement, whose artifacts are frequently displayed in museum spaces. Likewise a number of avant-garde publishers come to mind like Something Else Press (1963-1974), which published Robert Filliou's Ample Food for Stupid Thought as a box of postcards. But it is a mistake to see design innovation as primarily a matter of literary high-art. Janine Barchas has noted that innovative play with typography was a fundamental part of early novels like Clarissa. More recently, the innovative design of Choose Your Own Adventure novels has brought such interface considerations to mass-produced genre fiction. Perhaps most tellingly, books written for children constantly redesign the means by which we encounter the text, from the mixture of word and image in Winnie-the-Pooh to the metafiction of the Sesame Street picture book, The Monster at the End of this Book. Design innovation is not a modernist tangent to the history of the book, but rather a fundamental part of it.

This is why no model of the ebook based on the modular library can be entirely satisfying - no matter what DRM restrictions or freedoms are included with it. It is the nature of modular libraries to insist on uniformity of its members. Because it has long been published in multiple formats (the 45, eight-track, the LP, cassette) music doesn't seem to raise as many concerns about the uniformity imposed by the digital audio file format. Even in the case of music, however, many have felt that the context-less purchase of single tracks has lost some of the experience provided by the whole album, upon which artists could impose more creative control. Apple's fledgling attempt to recreate the experience of the LP (including album art and lyrics) in iTunes LP suggests an awareness of this problem. The problem is even greater when extended to ebooks, since books routinely challenge and redefine their interface with the reader.

4.

I might seem naive in suggesting that books be allowed to retain their ability to redefine the experience of reading in a digital environment. After all, the benefits of creating a uniform library of ebooks seem to outweigh the occasional limitation on authors to create unusual designs. And, anyway, isn't this just the nature of the digital medium - to insist on uniformity and the integration of its objects into larger wholes? Surely there is no point in authors fighting against the inevitable.

There is, however, a kind of digital artifact that accomplishes exactly this resistance to library integration: computer games. Game designers - especially those working at high-profile, big-budget development studios - pride themselves on pushing the limits of available computer hardware and redefining the user's interaction with the system. It's not uncommon for gamers to upgrade hardware to take advantage of a new, high-profile game, and even games with more modest hardware demands frequently require players to download video-card drivers and updated graphics software like Microsoft's DirectX. Games like this frequently do not play well with each other, requiring settings that might have to be tweaked differently for each game. (Some games, for example, may benefit from running two graphics cards, while others may require that one be disabled to avoid crashes or slowdowns.) Graphics-intensive computer games are demanding, prickly digital objects that frequently only function smoothly on a wide variety of systems after multiple patches and tinkering by individual game owners.

In this regard, computer games are the antithesis of the unifying logic of the modular library: they demand to be treated like wildly individual objects, and pay the user back for this effort by (sometimes) reshaping the experience of the screen and its represented spaces. Of course, things were not always this way. Indeed, the dominance of the text-based adventure game in the early-1980s represents a path ultimately not taken by PC computer gaming. The text adventure game embraces the modular library. The descendant of these games, interactive fiction, shows all the hallmarks of such a library organization. This fiction is written using one of several formats (Inform, TADS, ADRIFT) that depend on another piece of software to interpret the story code for the reader. The text-adventure game or interactive fiction work is made up of multiple files, some of which are shared between individual works. For example, Lucasarts produced some of the most influential and popular early (graphic) adventure games like the Monkey Island series. Many of these games depended on a scripting language called SCUMM (Script Creation Utility for Maniac Mansion) through which the games were written. Because these games depend on this utility to organize the presentation of the basic locations and objects of the game world, programmers have been able to port these old games to newer platforms by creating a virtual SCUMM environment. It is precisely because these early adventure games are modular and depend on shared library structures that they can be ported to OS environments for which they were never intended.

Behind the SCUMM model is a fundamentally different attitude towards game design, one that emphasizes the relatively simple development of story content over the innovative redesign of user interface. This is even more the case with classic text adventures from Infocom, which depend on a uniform language and user-client. In fact, in 1996 Infocom gathered together 33 works to make a cross-platform CD-ROM Classic Text Adventure Masterpieces of Infocom; such a compilation captures the library-like quality of these games, and marks a striking contrast from subsequent game design.

Today, then, digital media objects seem to fall into two categories. In one category are objects like music and pictures, which have largely been integrated into modular libraries. We can expect that, increasingly, we will encounter these sorts of objects through specialized software that organizes and controls the way that we interact with them. In the second category are games, which remain messy individuals. To the extent that an avid gamer might have a "library" of games, this is clearly an accumulative library: a collection of objects that fail to conform to any systematic ordering. In fact, such a game library is likely to make incompatible hardware demands - some games requiring cutting-edge video settings while others need to be run in an emulation mode or even using a virtual OS like DOSBox. In contrast to the way that the modular library smoothly organizes the experience of digital media like music and pictures, such a game library is a messy affair in which the user of the library must organize the objects and define the conditions by which they are encountered. The overwhelming momentum within consumer electronics today is towards the integration of more and more of our digital media into libraries. Games remain the exception to this rule, the wild objects that defy integration into larger wholes.

I will resist the temptation to suggest that games in this regard have usurped the role that the book once had within culture - that books traditionally were the messy object that games are today. In fact, books have played many different roles since the advent of cheap mass production. At times they have been wildly unique objects, but there has also always been an underlying urge to integrate books into larger libraries. It was once common practice, for example, for owners of large private libraries to have their books bound or rebound to create uniformity and to show good taste. A nice example of this is Arthur Lee Humphreys's 1897 advice about bookbinding in The Private Library. For every time that an author has tried to reinvent the form in one way or another, there is a publisher bringing out another uniform Little Leather Library of the "Thirty World's Greatest Masterpieces" (Rubin 94). But it does seem likely that as books become a more routine part of our digital libraries, and as we encounter more of our reading through ebook library software, that this urge to reinvent the form will diminish and be marginalized to curiosities and gift books.

5.

Clearly, there is no easy solution to the problem of the ebook. Let's all be honest: for the vast majority of our everyday reading, our interface with the text isn't all that important. Most readers would gladly trade the pleasures of fine paper or interesting typography for the convenience of being able to carry around every book they own in a device that weights less than a pound. Once we have gotten used to being able to quickly search a PDF or Word file for a particular phrase, being unable to do the same thing for a printed book begins to feel cumbersome. I'm sure that I'm not the only person who has gone to Google Books to do a search for a word in a book that I had on my bookshelf, just because searching there was so much easier than combing through an incomplete index. As more of our books become electronic, the limitations of printed texts without search-copy-paste will rankle more and more. It is unlikely and probably undesirable that books should become the equivalent of computer games - finicky objects that demand attention and care before we can use them.

I am suggesting, instead, that we need to recognize that books are hybrid objects, quite literally half content and half form and used in different ways in different contexts. Our urge to integrate the objects into libraries is a natural embrace of the content that makes up the vast majority of our reading pleasure. But we need to keep alive the ability for books - even in an electronic environment - to break the design rules that the library might impose on them. We also need to recognize that readers use books in several different ways: sometimes enjoying design, sometimes quickly skimming for argument, fact, or plot.

Academics concerned about the future of the book have, to a large extent, rightly focused on the issue of a shared and open format. Calls for the widespread adoption of the EPub standard fight against publishers like Amazon, which sells its ebooks in the proprietary AZW format, locking purchases to the Kindle or Amazon-controlled environments for reading. Although many users may prefer the simplicity of using a single client and format for their reading - just as they might stay within the iTunes ecosystem for music - it is important that content purchases be transferrable between devices. But focusing the debate over the future of ebooks entirely on the issue of open standards concedes that the book will simply become one more item in a modular library, and this is something we should not accept once we recognize the importance of book design throughout the history of reading. We need to find a way to allow books to be integrated into libraries, while at the same time preserving authors' and publishers' ability to produce design innovations.

Fortunately the modular nature of the library also provides many opportunities for accessing the text. Indeed, the modular nature of modern digital objects - made up, as they are, of multiple files that represent different parts of the song, movie, or book - provide precisely the format for balancing the dual role as uniform object in the library and unique item that challenges conventional design. Consider the model provided by the SCUMM emulator. What this emulator does is separate the original program from its data files, disregarding the requirements of the original program (which frequently will no longer run on modern operating systems) in order to present the content of the story. This split, between original presentation to the player and data files that might be interpreted in convenient ways by a variety of clients, is one that publishers would do well to emulate. In this model, an ebook would actually be a combination of two different elements: a general data file (say, in the EPub or some other open format) and a designed interface for reading that data file. The data file might be integrated into some portable library structure, but we would recognize that such a library is merely an emulation of the original book. For many books, there might be little or no difference between the EPub content as it appears on a Kindle and the designed interface provided by publisher and author; in other cases, this designed interface might provide a significant depth to the content.

Although there are no technical limitations for designing ebooks of this sort, there are clearly many practical and cultural hurtles. If a book's EPub file can be accessed by a Kindle or other ebook reader, what technical device will be used to access the author-designed interface for that file? Web based java and HTML files provide a simple standard, but other authors may wish to present their books as executable files to be read directly on a computer desktop. The value of publishing works as applications has come up in debates about the role of publishing in Apple's impending tablet device. Andy Ihnatko argued that Apple should avoid creating an iTunes-like store for selling texts, and instead encourage publishers to develop individual applications for sale through its App Store. Neven Mrgan, conversely, has pointed out that such a structure creates a high technical barrier for publication. Still others might insist on a physical component to their works. In the golden age of text adventure games, Infocom packaged some of its stories with physical "feelies" - story props that ranged from there merely collectable, such as the paper ordering the destruction of the Earth in The Hitchhiker's Guide to the Galaxy, to a scratch-and-sniff card that provided players of Leather Goddesses of Phobos with clues about how to solve some of the game's puzzles.

We may come to see physical books as something of the same sort of feelie: a physical prop that is a supplement to the electronic data file that might be integrated into an ebook library. Such physical and digital elements that go beyond the simple core data file of the book need not be a component of all books, but could supplement a small number of works whose authors want to challenge or extend our reading experience. While standardization is essential for the data component of these books - since readers will want to integrate them into libraries - I see no reason to insist on standardization for the designed elements of reader experience. Some authors may choose to supplement their ebooks physically, others with stand-alone executable files, still others with HTML documents. Those elements may, ultimately, be transient - just as it is difficult today to find a computer on which to play the original Maniac Mansion game without an emulator. Such transience need, not, however, mean that these components are unimportant - merely that they are timely.

What is essential, however, is that such supplementary elements that challenge and redefine the reader's interaction with the text become part of the culture of book buying and reading as it moves into a digital age. The problems of implementing this model are not technical (based, as they are, on the 20-year-old technology used in Maniac Mansion), but involve a fundamental cultural struggle over how we think about the creation, selling, buying, reading, and storing of books in the future. At the moment, books are on the verge of being reduced to a file format: PDF, AZW, or (at best) EPub. We need to insist on authors' rights to design the interface through which readers encounter their books, and to advocate for the value of such individually-designed reading environments. If everyday readers think about every book as having these two components (even if they may really only attend to one of them for most of the books they read), we retain a space within our culture for the kinds of publishing innovations that have been a part of the history of reading.

Works Cited

Barchas, Janine. Graphic Design, Print Culture, and the Eighteenth-Century Novel. Cambridge: Cambridge University Press, 2003.

Classic Text Adventure Masterpieces of Infocom. CD-ROM. Cambridge, MA: Infocom, 1996.

Filliou, Robert. Ample Food for Stupid Thought. New York: Something Else Press, 1965.

Humphreys, Arthur L. The Private Library: What We Do Know, What We Don't Know, What we Ought to Know About Our Books. New York: J.W. Bouton, 1897.

Ihnatko, Andy. "Thoughts on what an Apple tablet should be - or not." Chicago Sun-Times. 7 Jan. 2010. Http://www.suntimes.com/technology/ihnatko/1980077,ihnatko-apple-tablet-microsoft-010710.article.

Jobs, Steve. "Thoughts on Music." Online posting. 6 Feb. 2007. http://www.apple.com/hotnews/thoughtsonmusic/.

Leather Goddesses of Phobos. Diskette. Cambridge, MA: Infocom, 1986.

Allain, Alex. "Lesson 1: The basics of C." Cprogramming.com. http://www.cprogramming.com/tutorial/c/lesson1.html.

Mrgan, Neven. "DIY, Pt. II." Online posting. 8 Jan. 2010. http://mrgan.tumblr.com/post/323938510/diy-pt-ii

Rubin, Joan Shelley. The Making of Middlebrow Culture. Chapel Hill: University of North Carolina Press, 1992.

Stone, Jon. The Monster at the End of this Book. Illus. Michael Smollin. 1971. New York: Golden Books, 2004.

Cite this Essay: