An Open Architecture for Annotation

(Still a draft)

Open Glosses is a lightweight architecture for open content annotation. It relies heavily on existing web standards but is designed to be versatile and scalable. I built it by taking beingmeta’s “gloss database” for storing glosses (notes, tags, links, etc) on sBooks and trying to come up with a system where beingmeta could still compete but not have a monopoly. Open glosses is the result.

A gloss is an annotation attached to a fine-grained web reference, typically below the level of a single document, for example a paragraph, quote, list item, etc. A gloss consists of a fine-grained reference (or multiple reference paths) to a ‘point’ in a web document. The reference is accompanied by a textual comment, creation and modification dates, an optional excerpt (encoded by both content and text range). It can also include any number of tags, links (URL references with titles), and outlets. An outlet is a tag with permissions: outlets are limited by who can assign them, see them, or search based on them.

The protocol for glosses is based around an HTTP(S) endpoint called a knotary; a given annotation consists of the endpoint followed by a UUID unique identifying the endpoint. For example, if the endpoint were https://www.archive.org/pubglosses/, a reference to an annotation might be https://archive.org/pubglosses/ab857636-ed6b-11e0-8515-040ccedb18d8.

In our current implementations and in this post, we’ll assume that the annotations themselves are represented using JSON. In a ‘grown-up’ implementation, it would presumably respond responsibly to HTTP ‘Accepts’ headers, but our implementation is still in middle school at this point.

Every annotation has a ‘refuri’ field and a ‘frag’ field identifying a web document and a passage within that document. The frag field can be an XML ID or it can use a different addressing scheme (see my post on How to Point To A Paragraph). We introduce the convention that a frag of the form:

#_scheme_schemedata

indicates a reference using a particular scheme, so that:

#_MD5WSN_xxxxx

references the passage whose MD5 hash of its “word segmented normalization” is xxxxxx.

In addition, a gloss can have a separate alturis field giving other URIs which refer to the same document and an altfrags field giving other fragment identifiers which refer to the same passage. Note that the frag reference need not be an actual ID, but coould be a derived reference as described above.

Finally, the gloss can include an altrefs fields whose URLs take the form url#FRAG and refer to the same passage. By implication, the altrefs include refuri#frag as well as the cross product of alturis and altfrags. Got that? (The main idea is that a gloss may have lots of different references to the passage it annotates).

glosses have a ‘note’ field for a comment (UTF-8, no formatting). They can also have an ‘excerpt’ field consisting of a string. Some implementations or content sources may choose to limit the size of the excerpt for intellectual property reasons. There are a handful of additional fields which I’ll describe shortly. But back to the endpoint and its semantics, which are based on HTTP.

The protocol uses HTTP GET/PUT/POST to access, create, and modify annotations (glosses). To create a new annotation, you just POST (with a JSON payload, other options in the grown-up version) to the endpoint+UUID and an annotation is created; to modify the annotation, you do a PUT on the endpoint+UUID.

GET, of course, just gets the (currently JSON) representation of an annotation given the UUID. Ideally, the endpoint honors HTTP headers like Modified-Since and whatever security promises are made by the endpoint.

To talk about the query mode, we need to introduce the extended but (still) relatively minimal field set for the model.

In addition to refuri, refuris, frag, frags, altrefs, and text, glosses always have:

• maker: who created the annotation; this can be a user object reference relative to some domain/database (that’s what sBooks uses), an email address or uri (ideally verified), or even a public key (for stable anonymous annotation);
• created: the date/time when the annotation was created;
• modified: the date/time which the annotation was last modified;

and optionally,

• signature: a computed value proving that the maker really created this particular annotation

As mentioned above, glosses have a text field which is a (typically short) comment associated with the annotation. They also have an (optional) excerpt and (optional) content field, together with tags, links, and outlets.

• The content field has more detailed content and the content_type field gives it’s mime type, which defaults to text/html.
• The tags field consists of tags associated with an annotation; we think it will be common to have annotations which are nothing but tags, providing alternative indices or orgnaizational schemes to existing content; tags are actually little knowledge base nodes using the knodules (www.knodules.org) syntax, which lets you specify terms, synonyms, relations, and all sorts of other cool relations.
• The outlets field determines who can see a given gloss but the details are determined by the endpoint implementation. The main points are: only certain people can add a given outlet to an annotation; only certain people can see that a post is associated with a particular outlet; and only certain people can find all glosses associated with a particular outlet.
• The links field is a collection of URLs and titles associated with a gloss.

The query mode allows applications or users to find glosses with particular properties. A query reference has the form:

endpoint?refuri=xxx&frag=xxx&tag=ttt

Many endpoints may require a refuri and a query may provide also multiple refuris for cases where a document may have many editions. Refuri parameters that include hashids are taken as direct references, while others are automatically combined with any frag parameters to find matching glosses. Queries can provide parameters like maker and outlet and the endpoint is expected to implement whatever semantics they’ve promised.

In addition, the query endpoint should at least handle the AFTER parameter to get glosses which have been created or modified after a particular time.

Introducing codex.js

I’ve implemented a lightweight Javascript library for breaking large HTML documents into a series of pages, obeying the stylesheet constraints (like page-break-before) provided by CSS. You can find the library, which is open-source, at codex.js. It’s technically part of the FDJT library, but it only depends on dom.js.

If you wonder why you might want something like this, take a look at my post on how The Page Isn’t Dead. For all sorts of reasons, it’s easier to read a large document when it’s intelligently broken into pages. Unfortunately, most browsers don’t do this themselves, and even most e-readers do it poorly.

The library works by constructing a series of div.codexpage blocks within a designated container. A stylesheet (codex.css) defines div.codexpage to be a fixed positioned element and users of the library can extend or modify this definition.

Using the library starts by instantiating an instance of the CodexLayout object, e.g.

  var layout=new CodexLayout();

You can set a lot of parameters, though it also tries to get defaults values in various ways. A more fleshed out call might look like this:

var layout=new CodexLayout({
  page_width: 500, page_height: 500, // dimensions
  // Where to add new pages
  container: document.getElementByID("MYPAGES"),
  // Prefix for page element IDs, e.g.
  //  page 42 would have id MYCODEXPAGE42
  pageprefix: "MYCODEXPAGE",
  logfn: console.log, // how to log notable events
  // Layout rules:
  //  Codex observes CSS declarations, but you can put
  //    additional constraints here:
  forcebreakbefore: "H1",
  forcebreakafter: "div.signature",
  avoidbreakinside: "div.code",
  avoidbreakbefore: "div.signature,div.attribution",
  avoidbreakafter: "h1,h2,h3,h4,h5,h6,h7",
  // There are some constraints which CSS doesn't include:
  codexfullpage: "div.titlepage",
  // Put this element on a page by itself, but don't
  // interrupt the narrative flow
  codexfloatpage: "div.illustration"});

Once you’ve got a layout object, you just add DOM nodes to it by calling addContent(node). It actually moves the DOM nodes, but you can always call the layout’s revert() method to restore all the nodes to where they came from.

The implementation works by duplicating the document hierarchy on each page, splitting the contents of container nodes and duplicating their contents if needed. For example, suppose a poem wrapped in a div.poem block needs to be split across multiple pages. Each page will have its own div.poem block and the first one will have a codexdupstart CSS class, the last one will have the codexdupend class, and any intervening nodes will have a simple codexdup class. By default, these CSS classes try to override any top or bottom definitions (margins, borders, padding), but designers may want to customize these definitions.

The library is agnostic about how pages are navigated. By default, div.codexpage has zero opacity and div.codexpage.curpage has an opacity of 1, making it easy to change pages by moving the curpage class around (it does a little fade-in/fade-out if supported by the browser). But users of the library can override these definitions to add (for example) sliding page transitions or other effects.

There is still work to be done, but it seems to be working pretty well and it’s not too slow. It uses the browser’s underlying geometry and styling engines, which limits how fast it can really go.

Enjoy. I’ll update here if there are minor changes and post news about more significant changes.

The Page Isn’t Dead

I once thought that the rise of electronic reading would mean the death of the “page” as part of the reading experience. I fully expected that the chop-chop-chop of paged media would be replaced with the smooth flow of endless scrolling. It seemed so much simpler and more elegant.

I was wrong, but the reasons are interesting. The chop-chop of pages are here to stay but the way documents are designed is due for transformation.

What we think of as paged layout was introduced in the first century. It’s called a ‘Codex‘ and it succeeded the scrolled media where a very long piece of printed material was rolled up and then selectively unrolled (typically between two spools) to expose a desired passage or fragment. The technology of the codex, which had significant advantages by itself, also attached itself to a quite prolific meme: early Christian texts were nearly all published as codices.

The codex solved two problems. First, it presents a reduced aspect of a long document which fits the visual field so that the text is readable. Second, it simplifies random access to the text, so that it’s very easy to go to a particular part of the text. (It would be interesting to speculate on the impact of random access on how people thought and read, but that’s not my current point.)

Advance several thousand years, and technology has made the random access problem go away: you can jump within a scrolled document in less time than it takes to say “Heraclitus.” However, the first problem. the reality of the human visual field and acuity, is still with us. Clark Kent might be able to read an entire book fit onto a single exposed surface (either a rampart-sized display or something with very tiny letters), but we can’t. The scrolling computer display works by presenting us with a slice of the text and letting us move that slice within the document (just like the old unrolling scrolls which predated the codex).

Unfortunately, it’s the way we move that slice which makes things complicated. While it works fine for short documents (e-mails, short news articles, advertising), it doesn’t really scale to longer documents. To see this, think about what your hand and eye are doing when you scroll forward to the next chunk of reading in a long document.

Your eye is on a line somewhere near the bottom of the screen and you’re caught up in the argument, or the thrill, or the emotional tension, but you’re near the bottom, so you have to scroll up. You then use some physical device — mouse in your hand, finger on a trackpad, thumb on a trackball — to move the content within the display.

Your eyes follow the line you’re reading and, when it nears or passes, the top, you abruptly stop whatever physical motion is driving the display change. To pick a metaphor from physical sports, the line is the ball, the top of the display is the basket, and you’re trying to score. Every time you turn the page. Now what were you reading about?

All of the human pieces of this little game are organic and subject to fatigue with time and repetition, which is why scrolling is less objectionable for shorter texts than longer documents or books.

Traditional scrolling of longer texts is both tiring and and disruptive of narrative flow. What’s amazing is that brilliant writing and compelling stories can survive these interruptions so easily. We are a lucky race of media consumers. But what’s tragic is that it’s not necessary.

Just press PageDown! Many of my more astute readers have probably just said “why don’t you simply push page down (or space) and move your eyes to the top!”

That is a huge improvement and the remark is the perfect segue to my second point. One button/key scrolling is what I usually do when I need to scroll, but many people don’t even think of it. Even when we manage to remember the possibility, it reveals the obvious fact that scrolled information is already broken into pages by the size of the display, but it’s just broken into pages BADLY.

In the worst case, a line of text is split across the bottom of the display or window, so that we see only head or feet of a line at the bottom or top of the scrolled page. It is a testament to the miracle of visual perception that we can often read a line that’s lost it’s head or feet, but it slows us up even when it doesn’t stop us in our virtual tracks. Better software always scrolls by whole lines (when it can identify them), which is better, but the problem runs deeper.

Texts aren’t just series of lines. They includes blocks and heads and hierarchies, and the whole purpose of their design is to guide our attention and understanding. When a display arbitrarily imposes stops and breaks, it doesn’t help the flow, the attention, or the understanding. Think of it as cogitus interruptus. Not fun.

Almost any printed book has had attention paid to where the page breaks fall, doing so in such a way as to minimize the disruption to the reader’s experience. Don Knuth, famous computer scientist and digital typesetter extraordinaire, used to rewrite sentences in his books to avoid awkward line and page breaks. Unfortunately, we can’t make those adjustments by hand in this modern web world where anyone can adjust their page dimensions or font size long after the author or publisher has left the building.

To its credit, the web has a partial solution, in that CSS has properties, like page-break-before, that let authors or designers provide constraints which layout engines can try to honor. Though intended originally for printed layout, they’re equally helpful (when honored) for codex-style electronic display.

Unfortunately, most eBooks ignore this information, leading to cases where headings appear at the bottom of pages and thought-sized chunks of text are split across boundaries. It’s distracting, confusing, ugly, and unnecessary.

The page isn’t about to die. In fact, it’s becoming more alive, as its dimensions and attributes change across devices and purposes. The page is fundamentally about providing an eye-sized window into a text; what’s changing is that the character of that window is now a fluid and lively aspect rather than a fixed and frozen window. This is an extraordinary opportunity, where the reader’s experience has more dimensions and publishers will be able to add more kinds of value than they had in the past. The page isn’t dead. It’s about to be reborn.

WSN: Why Be Normal?

WSN, or Word Segment Normalization, is a simple way to get canonical representations of paragraphs. It can be used for identifying passages within a document for purposes of annotation or reference or as a part of other algorithms which might (for example) be trying to align passages in different editions of the same document.

A simple open source (LGPL) Javascript implementation can be found on github at wsn.js. The underlying idea is to normalize strings for case, whitespace, and modifier characters (in Unicode) and to use this as the basis for further normalization.

The basic WSN form splits an input string at whitespace+punctuation runs but leave embedded punctuation where it is, so that a string like:

the 'look-alike' scores were 3.5, 2.7, and 1.2 respectively

becomes the canonical string:

the look-alike scores were 3.5 2.7 and 1.2

Once, a WSN string has been generated, it can be used as the basis for hashing to get a more compact unique representation. So the MD5 hash of the above string, represented as hex would be:

8cfc45dcea529b6f1177ed71e58c463b

This hash value can then be used in generating unique IDs of the kind I discuss in How To Point to a Paragraph.

Fuddled normalizations

In addition, we can generate a fuddled representation by taking the words in the WSN string and modifying and/or sorting them according to some function. In most cases, we’ll also want to remove duplicates after sorting.

Why fuddle a WSN string? First, fuddling may further normalize the string in useful ways. For example, simple rewordings would map to the same fuddled string. Also, if we were to sort on something like word frequency (rarer words sooner) or a proxy to frequency (like word length), the fuddled string could provide a good representation for finding identical passages across editions or renderings.

Another reason to fuddle strings is to obscure the content itself. Suppose that we want to refer to a passage in a copyrighted text but don’t want to expose the original text in our reference. We can use a fuddled WSN to refer to a passage precisely (or even approximately) using a fuddled representation, but the fuddled string itself would be nearly useless for actual consumption (unless it were very short).

Fuddling can extend beyond sorting to actually remove words (like stop words) or transform them (for example by stemming or soundex coding).

The Javascript library

The library is released under the LGPL (and some other licenses) and can be downloaded at wsn.js. While it is part of the FDJT Javascript library, it doesn’t depend on any other components, except that it can use the fdjtHash object to generate hash values if desired.

The function WSN(arg) takes a string or a DOM node and generates the WSN normalization of its textual content. The function WSN.Hash(arg,hashfn) applies hashfn to the WSN normalization and the functions WSN.md5ID and WSN.sha1ID generate hashed values for the content using the specified algorithms (represented as hexadecimal strings). These functions require the fdjtHash utility or you can just set WSN.md5 or WSN.sha1 to use your own implementations.

WSN takes extra arguments, particularly WSN(arg,sortfn,wordfn,keepdups):

sortfn is the function used to produce a fuddled representation; if sortfn is true rather than a callable function, it sorts first by length and then lexicographically. This yields strings which generally differ sooner than other sorting methods.

wordfn, if not false, is applied to every word in the WSN representation. If it returns false, that word is deleted, otherwise, the is replaced by the result of wordfn. This can be used to use (for example) stemmers or other normalizers to generate even more normal forms. special note: if the wordfn ends up yielding no words at all, it is ignored.
wordfn special cases: if wordfn is a number, it excludes all words shorter than the value; if wordfn is a non-callable table/dictionary/hash/object, it is used to map words to alternate words or to the empty string to indicate the word should be deleted.

keepdups indicates that duplicate words should be kept in the fuddled WSN representation. The removal of duplicate words happens after the wordfn is applied.

All of the hash generating WSN functions take the same extra arguments as WSN. The default values of these arguments can be set by setting the corresponding properties of WSN, e.g. WSN.sortfn.

If the argument to WSN is false, it assumes that it is being used as a constructor and creates an object whose attributes specify the other parameters. This object’s normalize method then uses those defaults. This object also supports the Hash method, which computes a hash value based on the objects .hashfn attribute (which defaults to MD5 if it’s available).

DOM walking

The library is mildly clever as it walks the DOM when it generates the input text for the WSN algorithm itself. In general, the textual form is simply a concatenation of any underling TEXT nodes, with two caveats, based on the each node’s CSS style information:

1. any nodes whose position is not static are simply ignored;
2. any nodes whose display attribute is not inline have newlines inserted before their content, though the newlines will be normalized away by the WSN algorithm.

As a final feature, WSN provides a Map method which takes a set of nodes (or strings) and generates a table from their WSN normalizations to the nodes (or strings) themselves. This can work with an array or a node list, so (if you’re using something like jQuery), you can just say:

WSN.Map($("P"),WSN.md5)

to get a table mapping WSN MD5 ids to paragraphs. The second argument specifies a hash function to apply to the WSN normalizations, and the normal WSN parameters (sortfn, wordfn, etc) can follow the hash function.

How To Point To A Paragraph

If commentary or discussion about online content is going to get beyond ‘Like’ and ‘Hate,’ there needs to be a way to make comments or annotations fine-grained below the level of the document itself: at least to the paragraph or even to the sentence or other excerpt. However, this isn’t as easy as it might appear.

The problem is that references to paragraphs (for example) need to be stable even as the rendering of the paragraphs changes across devices or displays. Page and line numbers, for example, are the centuries-old solution to this problem which don’t work when readers (human and digital) change page dimensions or type sizes with regularity. So what’s the solution?

The easiest solution is to simply attach some kind of unique identifier to paragraphs or other passages. This is what the Bible does, for instance, with chapter and verse numbers that are stable across editions and translations. This scheme is a pretty old one and now close to universal. The trick is to have production and reproduction processes which create and sustain these identifiers and it helps (as with the bible) to have the content itself be relatively stable without many edits. This is what we do with sBooks (www.sbooks.net) where we assign unique XML element IDs and have various ways to sustain these identifiers across edits and versions. Not rocket science, but not always easy either.

Unfortunately, we don’t always of the luxury of unique identifiers so sometimes we need to be a little more clever. One approach is to use the structure of the document to define identifiers, so that a paragraph might be identified as “the third paragraph in section 5 of chapter 3″. This is the approach used by the most recent version of EPUB3, though it has gotten some flak. The problem is that it uses the document hierarchy for encoding identifiers and consequently assumes that the narrative hierarchy and flow of the document is consistently transformed into the XML containment structure. Change the XML structure, and all your references break. Whoops.

Another approach is to use the actual content of the paragraph to identify it semi-uniquely. In the simplest version of this, an annotation just quotes the entire paragraph. This works pretty well in general but fails for paragraphs (such as ‘This is left as an exercise to the reader’) which may occur repeatedly in a document. However, in these cases, we can provide some context or other information to help disambiguate the reference.

Unfortunately, the use of the text itself has a few other problems of its own:

• it’s wordy and takes up space;
• it can vary between renderings (think whitespace, line breaks, hyphenation) or edits;
• it exposes the content which may offend or frighten some rights-holders.

There are two things we can do to address these problems: normalize the content and hash the normalized version.

With sBooks and our open annotation standard (Knotes), we’ve been using a simple normalization scheme called word segment normalization (WSN) which basically breaks the content at whitespace, strips off non-embedded punctuation, and then glues the words back together into a string where words are separated by single spaces. This works pretty well because most rendering and minor edits affect punctation and whitespace but not the words themselves. To be even more normal, we also decompose the content’s Unicode characters and then strip out all of the modifiers. And (in case you were wondering), if the content contains embedded markup, we strip out the markup tags (but not their embedded content) before applying the WSN processing.

(It turns out that the WSN representation can also be helpful for identifying stable text ranges, but that’s the topic for another post.)

Once we have a normalized string, we can hash it with MD5 or SHA1 or however you like to hash your strings. Unless you have more disruptive edits (fixing typos, for instance) or have to deal with genuine duplicate content (‘exercise for the reader’), this works pretty well. It is fairly compact and hides the actual content from anyone who has the reference but hasn’t paid for the content.

There is an interesting variation which hides the content while allowing smart fuzzy matching of references. The idea is to start with the WSN vector and then sort the words using some context-free criteria like alphabetical order, word length, or frequency in some external corpus. It’s then possible to use a little vector algebra to match similar passages automatically, but the exposed word vectors are relatively useless for reconstructing the original paragraph.

The real message here is that there is no silver bullet (besides unique initial IDs) to point to paragraphs. This leads to the idea of using multiple identifiers for any given passage and expecting that applications will use and choose among those identifiers to do the right thing in a particular context.

For example, an sBooks annotation stores the unique paragraph identifier (if there is one), along with the WSN vector sorted by word length, and the vector’s MD5 hash (WSNMD5), both by itself and together with WSNMD5 hashes of other paragraphs in the document. Finally, if the document was converted from a scanned document, we also use the page+lineno for where the original paragraph started in the printed book. The philosophy is that the more pointers you have, the more likely you are to be able to connect an annotation with the content.

One of the systemic consequences of cheap computing and bandwidth is that the rendered forms of ideas have gotten more diverse in vacuous but annoyingly idiosyncratic ways. These methods are ways to reduce this problem so that the important stuff, conversations about ideas and real issues, can proceed. I hope it helps.

Should an iPad be my eReader?

Over the past few weeks, I’ve had many friends and colleagues ask about using Apple’s new iPad as an e-reader.  Many of these folks had been thinking about a Kindle or a Nook but the iPad (and rumors of the iPad even earlier) offers an intriguing alternative.  Of course, the iPad is far more than an e-reader: it’s a portable media player, a mobile browser, and a possible netbook replacement.  But here’s how it stacks up as an e-reader, especially in contrast to current e-readers like the Kindle or Nook.

In a nutshell, current e-readers (like the Kindle or Nook) offer longer battery life and easy reading in natural light but are limited by a static grayscale display and an awkward interface.  The iPad offers a dynamic color display which supports video and animations and a touch-based interface but is limited by a relatively short battery life and screen readability issues, especially in natural light.   Apple is generally brilliant when it comes to user experience, so I expect that interface will be simple and natural in surprising and pleasant ways.

On the content side, it looks like Apple is signing up with all the big publishers, just as Amazon and B&N.  Apple has also said that they will be priced the same as the Kindle, though that might happen by publishers demanding (as they already have) that Kindle prices be raised.

As I’ve said before, the big content issue with e-books (on all the major platforms) is that they are more like software applications than books: they can’t be moved among vendors, due mostly to proprietary copy protection schemes (Amazon’s, Apple’s, or Adobe’s).  This won’t be an issue for the iPad, however, if the Kindle (etc) iPhone/iTouch apps work on the iPad.  This “big if” depends on Amazon (etc) being willing to support the iPad and Apple being willing to accept the applications.  It also isn’t known how readers will add their own e-books to the iPad, though it might be as simple as adding your own MP3s to an iPod using iTunes (and leaving Linux users out in the cold).

Outside of the content questions, then, the big downsides of the iPad are (relatively) short battery life and a display which (a) can’t be read in sunlight and (b) may have eyestrain issues for extended reading.

Battery life. In his introduction of the iPad, Steve Jobs cited an iPad battery life of 10 hours, which is pretty impressive and largely due to the fact that Apple built their own CPU for the iPad.  In an exchange with Walt Mossberg after Jobs’ presentation, Jobs commented that “nobody reads for 10 hours straight” which might be true now that the Harry Potter series is completed.  But the 1o-hour battery life means that you will probably need to recharge your iPad every night.  Depending on the individual, that might be easy to forget at home or hard to sustain when traveling.

However, ten hours is pretty miserable compared to the days and weeks of battery life provided by e-Ink based readers like the Kindle. For example, I once forgot my Kindle’s charger over a week’s vacation but finished all the novels I’d brought without a glitch (though I did turn off the Kindle’s wireless for the duration).

Reading outside.  On that same vacation, I often read outside, which would have likely been impossible on the iPad.  The iPad has a striking LCD display based on IPS technology (in-plane switching) which allows a broad viewing angle together with vibrant and accurate colors.  IPS also requires a strong backlight, which means the display is unlikely to be readable in sunlight.  I was personally disappointed that Apple didn’t go with Pixel Qi‘s low-power sunlight readable display technology.  This technology, which was originally developed for OLPC’s so-called $100 laptop, is featured in (for example) Notion Ink‘s Android-powered Adam tablet.

Eye strain? Computer displays have gotten much easier on the eyes over time, especially as their “refresh rates” have become imperceptible and as anti-aliased fonts have become more common.  But it’s not clear how the iPad display will stack up for e-reading.  Eye strain comes from how the eyes move, which can vary tremendously with task and context.  In a fascinating New York Times piece, I learned that our eyes make 10,000 movements/hour while reading.  Many of these motions are involuntary and can depend on “optical ergonomics” such as contrast or page width or typeface or spacing.

In this regard, the Kindle’s e-ink display is close to ink-on-paper (though the paper is a little grayish) which I find very easy on the eyes. I can read it for hours with no particular problems, providing the ambient light is adequate (as with ink on paper).

On the other hand, reading books on my iPhone, as I often do  waiting in lines, gets tiring after twenty or thirty minutes (as does the waiting in line!).  However, this might be do to the page width, or the screen glare, or any number of other factors.  It remains to be seen how the iPad will function in this regard.  (Stay tuned to this station).

In conclusion, the iPad will probably be an adequate e-reader and has the potential for much richer content and interaction than “traditional” e-readers.  For example, the sBooks experience will be much more satisfying on the iPad than it is on the Kindle or Nook.  The iPad may be especially appropriate for kinds of reading (magazines, colorful textbooks, graphic novels, etc) which current readers handle poorly if at all.

At the same time, the relatively short battery life (10 hours), the difficulty of outdoor reading, and the possibility of eyestrain issues will probably make it inadequate as a “read anywhere” device to replace your physical books.

What is an sBook?

An sBook is an enhanced and personalized ebook which has been subtly enriched with context and conversation from multiple sources.  sBooks can change the way that readers and communities engage with extended content (books, essays, stories) and the knowledge and inspiration which they contain.

Concretely, an sBook differs from a conventional ebook in two ways:

• readers can share rich notes with their friends, their communities, and other readers;
• an extensible embedded knowledge base helps readers search and explore the book’s content.

Sharing. Most e-books have ways to add and save simple notes for personal use, but sBooks makes it simple to share those notes with friends, colleagues, or communities, even engaging in conversations “in the margin” of books we care about.   sBook notes, called glosses, can also include references, rich media, and tags which can make the book easier to search and navigate.  Third parties can also use glosses to metapublish against an sBook, creating sets of notes, tags, or references that enhance the book’s value and evolve with time.

Searching. Most e-books also have some kind of full text search and (sometimes) a version of the printed index, but an sBook uses a compact embedded knowledge base — a knowlet — to combine those functions.  When searching an sBook, the reader doesn’t need to know the exact words used by the author and can even search for abstract concepts or themes.  The book’s built-in knowledge base can be further extended by the tags and knowledge created by the reader’s friends, communities, or interested third parties.

These distinguishing features of sBooks are based on three key ideas: that content and meaning matter more than form and flash, that technology can change (for the better) how we engage with complex information, and that publishers (large, small, and tiny) need to focus on editorial added value to remain relevant and sustainable in the digital age.

To explore more, you can visit sbooks.net, read some sBooks, or experiment with converting your own documents into sBooks.  Let us know what you think!

Beautiful e-Books

“All aesthetics is functional, even if simply for our souls.”

Printed books are beautiful things.  Even the cheapest paperback, if you look closely, has the hallmarks of a process where individuals made thoughtful choices to enhance the reading experience.  From the chosen typeface to the page breaks to the spacing and separators, books are made to be read.  To see the importance of those choices, just send a large raw text file to your printer and try to read it!

In contrast, many e-Books are especially ugly even given the limitations of their form.  Early in my life as a Kindle owner, I bought the e-book of Poul Anderson’s “Brain Wave,” one of my favorite science fiction novels.  I was disturbed to find that the e-book rendering lost many structural cues, such as the appearance of breaks between sections within a chapter.

There are some great slides from Liza Daly which illustrate this problem (the names have been changed!) and make some points which I hadn’t originally realized.

One of the reasons for the ugliness is that e-book production is typically an afterthought on the print production process and is often out-sourced and based on unproofed versions of the text.  Furthermore, e-book renditions are often not proofed significantly by editors or publishers.

A deeper cause is that many print designers (and editors and publishers) have a prejudice about online design based on the ubiquity of bad design and the early days of the web.  But it doesn’t have to be this way.

Design is the process of thoughtfully making the choices you have around the choices you don’t.  Book designers have a huge number of design dimensions and  some significant constraints.  The constraints (beyond largely fixed content) are mostly financial in origin, such as the use of color, the size of pages and the linearity of their arrangement.  In the early days of online reading, the design space was nightmarish, because designers had very few choices and the choices they didn’t have were also variable, reflected in the diversity and adjustability of early browsers or display applications.

One of my friends and heroes at the MIT Media Lab was a graphic designer and visionary named Muriel Cooper.  Muriel was a character (in the best of senses) who had started the Visible Language Workshop at MIT after working as a book designer for MIT Press.  The work of Muriel and her students, starting in the 1980s, was about making new media (long before it was thus named) beautiful.

They started by fixing some obvious sources of ugliness: aliased fonts and crayola color models.  They went further to use the bleeding edge of technology to create new choices for designers, leveraging effects like three-dimensionality, translucency, or animated fonts.  Eventually, they developed models for how designs could automatically adapt to the devices or choices of readers.  These ideas found their way into online design by inspirational example, engagement with vendors, and passionate disciples.

Today it is possible to make beautiful online documents, even for the Web, using declared standards that are quickly converging towards ubiquity.  There are some lovely examples at the CSS Zen Garden and even some examples of e-books at the ePub Zen Garden.

There is no longer a good excuse for ugly e-books.

Let’s call them A-books

The iPad will apparently be using a proprietary Apple copy protection for its electronic books, according to an LA Times report which cites “anonymous publishing sources”.  This means that you won’t be able to read your Kindle or Barnes & Noble e-books on the iPad or your iPad books on other devices.

We should really refer to these products as a-books rather than e-books because they’re more like applications than books: they’re tied to a particular platform and vendor.  ”a-books” could also coincidentally stand for Apple-Books, Amazon-Books, or Adobe-Books, covering the three major flavors of DRM in use with digital books.  DRM stands for  ”digital rights management” and is (in all these cases) a kind of encryption used to prevent unauthorized copying and distribution.  The Sony and Nook e-readers both use DRM from Adobe Systems.  It isn’t yet known what kind of DRM will be used by Google Editions (though it might be interesting).

This isn’t really new, since most e-books already come with DRM which ties them to a particular platform, but there seemed to be some hopeful convergence on Adobe’s DRM with its adoption by multiple vendors, leaving Amazon as the odd man out with the proprietary DRM.  (Of course, the reliance on Adobe isn’t ideal either).  However, Apple’s decision changes all of this.

The iPad’s book reading application will reportedly use Apple’s own FairPlay DRM, which they use for movies and TV shows and (until recently) music.  This is distinct from the Adobe DRM used on Barnes & Noble’s Nook, the Sony readers, and other products.  It is also distinct from the DRM used on Amazon’s Kindle, though the Kindle also has an entirely different e-book format altogether, rather than the ePub format which everyone else seems to be using.

It will be interesting to see what happens to the existing iPhone reader applications, especially the offerings from Kindle and Barnes & Noble (and more interesting ones from other sources).  If Apple lets these applications work on the iPad, you will be able to read your Kindle and Barnes & Noble books on your iPad, just not with the native reading application.  It would also let creative developers come up with even better ways of using the iPad as an e-reader.

However, Apple has an explicit policy of barring applications which replace core functionality.  That was one explanation of Apple’s rejection of the “Google Voice” application which got some anti-trust attention last year.  It is also the reason that alternative web browsers are not generally available in the App Store.  Will this policy bar those kinds of applications not that there is new native functionality?  It would be a questionable move on Apple’s part, but certainly conceivable.  One interesting move would be to provide a way that those applications could connect to the native iPad “bookshelf” and to offer/require that purchasing on the iPad happen through Apple’s in-app purchase infrastructure (where Apple gets a cut).

In the long run, there’s a slightly more than philosophical argument that a given product is not “really” a book (with its connotations of durability and portability) if it’s tied to a device or vendor.  If that’s the case (and books continue to exist), these a-books are a transitional form awaiting either some kind of open and portable DRM (not an oxymoron) or the evolution of publishing beyond dependence on DRM (as has happened in music).  In this scenario, there’s a chance that early adopters (like myself) will end up as either victims (losing purchases to vendor evolution) or criminals (breaking the DRM on books we’ve purchased so we can read them on different devices).   But I’m hoping for a better outcome!

The End Of Ownership?

e-Books aren’t owned, they’re licensed.  There are various reasons for this policy (on the part of publishers) which has some serious consequences for both consumers and culture.  On the consumer side, it enables device lock-in and makes e-books more ephemeral (your device could die or your vendor could stop supporting it).  On the culture side, it largely erases books from physical history and diminishes the creation of “hybrid value” brought to books by readers and communities.

In most cases, when you buy an e-book, you are actually getting a license to read it, not genuine ownership.  This is the case with nearly all e-book distributors, including Amazon and Barnes & Noble.  Google, the coy elephant debutante of the e-book world, has been careful in their formal language to talk about “providing access” to books, rather than selling them, suggesting that their cross-platform cloud-based solution will take this even further.

There are many reasons for the trend away from ownership:

• publishers think digital copyrights are barely worth the paper they aren’t written on, believing licenses (together with DRM) give them more protection from revenue loss through piracy and fair use;
• special restrictions are more easily included in licenses (e.g. no resale, no robo-read-aloud, device limitations, etc);
• those restrictions can give more flexibility in pricing models, which is how publishers recover investment in a largely speculative business;
• licensing opens the way for other revenue models, like subscriptions, for publishers and distributors to explore;
• licensing is the norm in the software world and the rest of the digital media world, partially to restrict rights for consumers and liability for vendors.

It would be nice to believe that ownership and licensing are equivalent for consumers, since both come down to “you pay and you read”.  Unfortunately, it’s not the case.  Some of the consumer consequences include:

• vendor lock-in: I can’t read my Kindle book on my Nook (or my Linux netbook);
• 1984 redux: Amazon could (ironically) delete copies of 1984 from buyers’ digital shelves because those buyers (probably) lived in nations where they had fewer rights than people in other places (1984 is out of copyright in some parts of the world but not in the US, due to the Mickey Mouse Protection Act);
• no sharing: I can’t lend my e-book to a friend or family member; even the Nook’s much-touted sharing features are extremely limited (you can share a book exactly once and only if the publisher allows);
• ephemerality: if a vendor goes away (either entirely or in part) and your e-book is under DRM, you will have “access” to a very random string of bytes (of course, Google and Adobe and Amazon are too big to fail, right?)

Given these issues for the consumer, I’m surprised that I buy e-books in the volume that I do.  But the convenience is compelling (a roomful of books in my briefcase) and I’m gambling that the market will drive some of the deficits away while grandfathering in my digital investment to date.  But the end of ownership has consequences for intellectual culture that are more serious, especially the diminishing of intellectual history and hybrid value.

Book ownership is one foundation of intellectual history for both individuals and the culture.  The books on our shelves constitute a history of our learning and thinking; our own shelves can yield reflection, insight, and inspiration; browsing someone else’s shelves can offer us a glimpse of their minds.  Though browsing a digital shelf might give the same opportunities (or potentially better ones!) for reflection and disclosure, their reliance on cloud-based data could make that impossible.  Repressive regimes make a big deal out of burning books as a way to cement their domination, and the end of ownership will make that even easier (with a reduced carbon footprint, of course).

In his 2009 op-ed piece defending the controversial Google Books’ Settlement, Sergey Brin compared their effort to saving the Library of Alexandria.  Ironically, the swathes and swatches of knowledge which survived that ancient calamity did so because there were many copies (some translations) of the works in many places.  Ownership, physically at least, saved the day and gave us what survived.

A second casualty of the end of ownership is to the creation of hybrid value by readers.  When I buy a book, my rights to the book (to mark up, to lend, to hang on to, to be found by future generations, to resell), allow me to add value to that book for myself and my community.  A book that I can talk about with friends is more interesting than a book just for my personal enjoyment.  A book that I (or a student, child, or friend) can return to in 10 years has more value than is contained in the moment of reading.  The five musty volumes of “Tom Swift” I found in my grandparents’ attic touched me more than the complete set that I now have on my Kindle.  It’s not just about accessibility, but about personal relevance.

Hybrid value is what enables serious intellectual discourse.  Academic publication, with its lists and chains of references, was the original “remix culture” where the value of a contribution included the vitality of its intellectual offspring.  In principle, digital technologies should make this discourse even richer and, in the short term, technologies like “Google Scholar” have been boons to conversation and scholarship.  But the end of ownership puts the traditions of distributed intellectual stewardship at risk.

What to do?  Here are a few ideas and I’d love to hear more:

• embrace open and common standards for packaging (e.g. epub .vs. mobi/azw);
• insist on vendor-independent “survivable” DRM (often social DRM) or no DRM at all;
• create frameworks for capturing and sharing user added value (that’s what we’re trying to do with sBooks);
• personally backup your cloud-stored e-books in anticipation of either distributor disaster or improved openness.