Early Experiments

The ebook owning experience was—and still is—overwhelmingly underserved. As soon as I started acquiring and reading ebooks, I immediately felt disorientated. "What books do I have? Which have I read, and in what state of reading progress are they in? When did I read them, in what context?"

I also asked myself "why do I feel this way?" I realized then: these ebooks do not exist in my mental space-time map. Many thousands of years of cognitive evolution, giving us the ability to situate experiences in multiple dimensions of context—space, time, social, semantic—are left unaddressed. My mind is given no cognitive surface area to grasp and weave into memory.

For something as deeply important to human development as books, not to mention written knowledge, this feels like a problem.

Skeuomorphism #

Skeuomorph: A derivative object that retains ornamental design cues to structures that were necessary in the original. Cambridge, UK: Cambridge University Press. 1988

The forms of ornament demonstrably due to structure require a name. If those taken from animals are called zoomorphs, and those from plants phyllomorphs, it will be convenient to call those derived from structure, skeuomorphs. Henry Colley March, The Meaning of Ornament: Or its Archaeology and its Psychology, 1889

Before continuing, a few words about skeuomorphism. Simply put, in software interface design, skeuomorphism refers to an approach whereby the software tries to mimic the "physical world" experience it is digitizing.

With ebooks, this means something like representing a collection of ebooks in a UI that mimics physical bookshelves. The first versions of Apple Books did this, and some apps out there still do.

Often falling esthetically somewhere between kitschy and the uncanny valley, the use of full-on skeuomorphism is generally avoided now. Too often, however, the baby is thrown out with the bathwater and these deeper cognitive "hooks" I mentioned earlier are left unaddressed, unused, un-leveraged.

With libra.re, I try to explore all that, without resorting to faux-wood panelling, page curls and the like. The materials I want to sculpt digitally are time, place, relationships, context… any meaning we can put in form. Some of these already have established UI patterns: maps, timelines, social networks… But these don't feel "natural" to the domain of book. Besides, I feel like the possibilities are not yet exhausted, especially for multi-context, hybrid information situations.

For example: how to present in a quickly graspable way the history of my experience with a specific book? From the moment I learned of it (from whom, how, where), to acquiring it; the multiple sessions of reading and perhaps annotating it; the conversations about it or the ideas I gleaned from it; how it connects to a broader theme I was researching at the time.

---

Books & Space #

My first impulses were perhaps obvious: pull my ebook library into physical space, and sneak up behind skeuomorphism.

Book Cards as Totems of eBooks #

A physical book not only contains the knowledge and ideas within it, but it is also a totem of them in the physical world. We interact with the object constantly even when we are not engaging with the thoughts within it, i.e. reading it.

It is there, on the table, by the bedside, in your bag, on the shelf, in the corner of your eye…

The very first piece of code I wrote for this project generated a PDF of ready-to-print "collecting cards" of the ebooks in my library. The front of course displayed the book cover, with whatever available metadata & stats I had access to on the back side.

I could carry the card around, as a totem of what I was reading. Leave it lying around…

I could display these on my actual book shelf, with ebooks I was currently reading prominently showcased in a little card holder.

However, as neato! as it was, the overhead of generating and managing these cards was beyond what my motivation could muster. Especially as my collection exploded.

It was a great experiment, but as an everyday, real (and marketable) "thing"… the costs outweighed the benefits. This value would need to be fulfilled another way.

Perhaps to be revisited…

Proportional Representation of eBooks' Size & Heft #

At its base, libra.re is a web app that lists my ebooks and displays relevant information about each one in various ways. Some of the ways it does this are pretty standard—lists of books grouped and sorted according to criteria I set.

When you list a bunch of ebooks on a webpage, or in an app, it's pretty easy to just dump the cover image, title and author name on there and call it done.

But there's a glaring omission in basically every version of this out there.

How big is this book? Is it a real chonk that requires a real investment in time and effort? Something I can feel some accomplishment in saying "oh yeah I finished that beast"? Or is it something I can breeze through quickly?

Ebooks of course don't have any real size. They mostly flow into whatever form factor you read them on. File size is unreliable since it measures how much data is in the file, which includes things like cover images, fonts, styles. A short text of say 50Kb might have a 20Mb cover image (I've seen much worse). So the book's file size is not what we want to rely on here.

The sizes of physical books across editions can vary also depending on decisions made by the publisher and their designers. For example, a smaller pocket edition of a book has a reduced page size, which inflates the thickness and page count. Typography and layout choices like size, leading, kerning, margins, paragraph spacing all have an effect as well here. Book design takes into account many aspects, and there are some rough standards of what works—for general legibility, cultural forms, contemporary styles, or different genres and markets–but what we end up with, the book in our hand and our shelf, is our experience of that particular book. There is no set, absolute measure of a book's size.

However, the intrinsic quantity of a book lies in it's contents. The measure of a book's "weight and size" is necessarily based, no matter what, in how many characters—letters, spaces, punctuation—it is made of. "War and Peace" is just a big ol' book, no matter how it is packaged.

In digital world, it is trivial to get character and word counts for a text. And, interestingly, most publishers do actually indicate a page count, usually based on the paper version of the same edition. This metadata is often included or at least available, and there are tools which can calculate a rough page count.

I currently use such page counts. The sense that somewhere in the process some logical "real world" heuristic was applied is reassuring. How do I know that asking the computer to give me a brute letter count for an ebook won't include the HTML markup used in the code?

So ok what does this get me?

Based on page counts, I can scale the cover thumbnail sizes and give a sense of thickness.

This is the most obvious thing, but also one the most engaging. An audible gasp is usually the response when showing someone this for the first time.

I think it's easy to understand why: the development of human cognition around spatial perception and object recognition is several hundred thousand years deep. Displaying ebooks with size differences roughly matched to their content provides not only a sense of their intrinsic nature (a real tome vs. a pamphlet) but also provides another dimension–I call it "cognitive surface area"—for our minds to grasp and enmesh the object in our experience, and thus our memory.

This was the point why I started this exploration. I had no memories tied to my experiences with my ebooks, beyond what I may have retained from simply reading them.

I love gazing at my e-bookshelves just as much as I love gazing at my "real" bookshelves. The memories and thoughts and serendipity that both evoke are now roughly equal.