Functionally-disjoint Design

I am one of those people. I annotate books.

By "annotate" I mean I copiously write on them. My history books are full of tiny scribbles that start on the inside of the front cover and, more often than not, end in a small stack of folded paper tucked in somewhere because I run out of space. I have a system for these notes, but the system isn't really important here, everyone who annotates books probably has their own system.

The fact that I can't annotate ebooks is the primary reason why I've continued to accumulate dead tree matter in my otherwise very cramped apartment. I don't want to but there are books that I like so much, that I find so interesting and I find myself consulting them so often that I end up buying the physical version. I mumble something about this totally being the last one, somehow squeeze it in my library, and then I say something nasty about modern user interface design practices.

Okay, "can't annotate ebooks" is a bit of a stretch. Most EPUB readers come with note support. My Kobo also supports notes. Unfortunately, the way this feature is implemented in most software out there is practically useless: the interface it relies on was built to accommodate a spec sheet, not the function it's meant to perform. I can guarantee that's the case because, if anyone had even bothered to look at someone perusing book notes, they'd have immediately realised their design was backwards.

The way this works in most readers is as follows. You highlight a section of text, and you get to write a note. Then you have a separate view for the notes, which usually shows a snippet of the text you've highlighted, and a snippet of your note. You click or touch an entry in this view and you get to see the note.

There are some variations on this theme, of course. Some software allows you to choose the highlight colour (how sophomoric!) Others, like Apple Books, also displays a small square next to the text, which you can click to see the note. None of these are particularly useful, since they all suffer from the same problems.

First, there is no way to see both the notes and the book's text.

The exact manner in which they don't allow you to do it varies. Apple Books "helpfully" pops up a modal window you can't move dead in the middle of the reader window. You can see some of the text around it, but not all, and you can't see other notes. In other cases the notes view is just completely disjoint from the text view, all you see in the "notes" view is the text you've highlighted and the note's text.

It makes a bit of sense for some devices. My Kobo's tiny e-ink screen probably can't accommodate anything fancier. The fact that Apple sells 32" displays but can't make a reader that can display both text and notes in those 32" is not a shortcoming of the hardware, it's a shortcoming of the design principles prevalent there (and pretty much everywhere) today.

But that's not all. Annotation is also strictly word-bound. Want to make a note with questions that a chapter raises? You can't just put that at the beginning of the chapter, it's bound to some text that you have to highlight. Maybe a word in the title, who knows. Want to add a note about other viewpoints regarding a topic in that chapter? Can't put that at the beginning of the chapter, either, you have to find some other word to highlight. Want to add notes about an image? You'd better hope it has a caption!

This breaks the note browsing view, of course. The note browsing view is usually indexed by the highlighted text, so you end up with a whole list of notes about words like "the", "a" and "Chapter".

On the rare occasions that I need to get by with annotating digital copies, I usually end up annotating PDFs using the generic, decade-old text-inserting features most decent PDF readers offer. It's not great, and it carries the limitations of the real-life device (you can't browse the notes, for example; you have to browse the document).

Ironically enough, it's community-built tools that tend to handle this best. Everyone likes to shit on the "inconsistent" design of open source tools, but Xournal++ runs circles around any of the "beautiful" book readers out there.

Twenty years ago, the main obstacle in our path towards better computer interfaces was that they tried to replicate their real-life equivalent to the point where they also replicated their arbitrary limitations. So they ended up performing their intended functions in exactly the same way, making any mismatch between the I/O capabilities of the computer and the real-life device a source of awkward interaction. Today, it's the opposite: interfaces are designed without an understanding of the function being performed, so they are optimised for computer-bound maxima, like implementation simplicity or generic visual appeal, rather than for what their users need them to do.

Back to blag archive

Back to blag index