We were looking for the Future Book in the wrong place. It’s not the form, necessarily, that needed to evolve—I think we can agree that, in an age of infinite distraction, one of the strongest assets of a “book” as a book is its singular, sustained, distraction-free, blissfully immutable voice. Instead, technology changed everything that enables a book, fomenting a quiet revolution. Funding, printing, fulfillment, community-building—everything leading up to and supporting a book has shifted meaningfully, even if the containers haven’t. Perhaps the form and interactivity of what we consider a “standard book” will change in the future, as screens become as cheap and durable as paper. But the books made today, held in our hands, digital or print, are Future Books, unfuturistic and inert may they seem.
I’ve been thinking about this as I work on a piece of digital fiction, and realize that it gets better every time I take away an opportunity for interaction.
I was also thinking about this reading Robin Sloan’s print mailings, which you can get if you sign up for his newsletter. Sometimes they come on thin pink paper, printed with a Risograph and folded in thirds. The latest one came in an envelope and on paper that felt very much like a junk mailer, which Sloan explains was of necessity but also part of the fun, since it came from a fictional bureaucracy. In each case, he runs the Ruby scripts, does the care and feeding of the AI, gets ink on his hands, or whatever else needs to be done for you to receive something delightful in your actual physical mailbox with no double-click to install, no log in, not even an ‘on’ button.
I see a parallel here between the technical burden that Sloan shoulders, and that the book printers and distributors that Mod refers to do, and a particular trend in web development: doing more work earlier in the process, in order to make what you send to your reader lighter and less complex. That can mean server-side rendering, doing most of the computation on the sending end rather than the receiving end so that the reader receives the simplest bundle of text possible. Or even before code hits the server, doing more work at compile time. Rich Harris, the maker of one such tool called Svelte, argues that “complexity, like energy, can only really be converted from one form into another” and he would prefer to take on the complexity rather than make his reader or customer or whoever is waiting at the end of the process deal with it. Shifting more of the effort sooner in the assembly line.
What you as a creator lose in that bargain is often not a loss at all. You may give up some novel or flashy presentation, but do your readers want that, or do they want to escape from it? And making it easier on the readers might make it harder up front for the people making the thing—but it’s always hard to make something that feels easy, always complicated to make something the feels simple.
Some of the time—maybe most of the time—the fancy tech does not belong in the hands of the reader. Too often it results in irrelevant cognitive load for the reader or too much computational load on the reader’s device—two analogous problems that often go hand in hand. Respectful tech helps get a piece to the reader in a way that feels light and simple and elegant, as with a restaurant that keeps all the complexity hidden behind the door to the kitchen, so that guests might have a simple, quiet, concentrated, respectful experience. (Snow Fall is Benihana.)
It feels like people take as a given that interactive widgets and lots of motion are what it means to use the native tools of the web, when in fact those are the tools of advertising, the problematic funding source for most of the web, which is built around the goal of diverting your attention rather than aiding your concentration. What would a web that prioritized readers over buyers look like? I suspect the difference would be greater than just an absence of ads, or even an absence of clickbait.