Often billed as one of the ebook’s marquee attractions, how well do in-book search tools really work?
Not all ebook search monocles are equal. Options range from non-existent (hey, Kobo! if there’s room in the programming budget for virtual reading awards like the Inverted Comma and the BookLover, then it’s time to spring for a search tool, too), to roughly implemented (Nook), and from nicely polished (Kindle, iBooks) to fully instrumented (Inkling).
To help make sense of what works versus what doesn’t consider first why readers search. If the title at hand is a reference or how-to book it’s often to look up a specific ingredient or procedure. But those kinds of books aren’t actually selling that well in eBookLand; publishing are turning those titles into apps. Instead, ebook fans are gobbling up narrative—fiction and non-fiction alike. Those titles all top the charts and so it’s worth refining that earlier question: For narrative-style ebooks, why do readers search?
Often it’s for a quick lookup: a character we’re having trouble remembering, a plot twist we want a refresher on, a memorable quote. In each of these cases the searcher’s goal is quite different than what takes place during, for example, a traditional web search. There, you want to leave Google or Bing or wherever. In a book, by contrast, you just want a quick answer…and then an equally quick return to where you left off.
So with that in mind, let’s start off with what I would argue is a not particularly good search implementation. Here’s what a reader sees when searching on the Nook iPad app:
How’s a reader supposed to decide which of these results is the one she wants? Think about how cumbersome it is to tap each item, get whisked off to its location, and then have to navigate back to the starting spot. What a pain. In a print book, at least you’ve got fingers, bookmarks, or a coaster to hold your spot as you leaf around (reviewing index entries, for example). But in an e-reader the disruption readers suffer from following a link is significant.
Especially for folks in search of a memory jiggle, the most important thing a search tool can do, then, is help quickly decide which result contains the answer they’re looking for. So this means designing a search tool that:
- returns accurate results (duh);
- presents these results with plenty of surrounding context;
- highlights the term clearly on the destination page; and
- makes it easy to quickly return to the original reading position
If 1) and 2) are done well, there are plenty of cases where the reader never has to deal with 3) and 4). So a big part of making a search tool helpful happens in the results list itself. Make it big enough and you bring joy to the reader: they get the memory nudge they need and can get back to the passage where they stopped reading. Some of this stuff is fairly straightforward and can already be found in a few of the more polished e-reading systems.
Consider, for example, the iBooks app on the iPad.
You get a generous sampling of text surrounding the found term (which is itself clearly visible in boldface) making it easy to skim the list and find the result you’re looking for. You also get a tally of the number of times the term was found. For students and other researchers this can be a big help, as they often want a search tool to function like a print book’s index: to help perform a comprehensive review of a particular person or concept. And once the reader taps a result, the page he arrives at displays the term highlighted in yellow. Nice.
But there’s more, still, that can be done. More that a morphable digital screen can do….all in the service of trying to maintain a reader’s flow and minimize the page flipping required on devices that have proven themselves to be pretty poor page flippers.
Here, for example, is one possible solution I’ve sketched out, modeled on the “page preview” feature popularized by Bing, and now used by Google and plenty of other Web search sites. (In case you haven’t seen it, it’s where you hover your mouse over any item on a typical search results page and up pops a small window showing the web page you’d see if you follow the search result link; it’s a great timesaver when you’re reviewing a list of results since it lets you do a quick visual skim before clicking any link.)
Rather than sending the reader to the search result, the idea here is to fetch the result for them. The results list appears just as it ordinarily does in, say, the Kindle app. But there’s that tiny “Show More” option; when tapped, it unfurls the result, increasing the viewable preview. In many cases that’s all a reader needs. For those who need more, the search term remains active and can be tapped to see the target page in full. By giving readers a quick way to review, temporarily, extra content like this, digital books can help preserve the immersive state that a great book induces.
Another way to improve the search results list: sortable search results. Here again progress made in the world of web search can improve how things work within a book. By letting the reader sort the results list in different ways a seemingly overwhelming heap can be reduced to something more manageable. iPad textbook publisher Inkling provides some handy design work in this area.
The tabs at top let the reader sort according to relevance (a software-driven guess at what’s most important), content order (where the result occurs, ordered from start of book to finish), and type (audio, video, text, and so on). At the bottom of the search pane two other tabs let the reader switch between chapters they own and the entire book (Inkling sells chapters individually). This last twist is clever—half reader service and half marketing. Because the tool lists a meaningful snippet of the found term, someone searching for, say, bassoon, might see that there’s a video demo of that instrument in a chapter they haven’t yet purchased. Good stuff.
My main takeaway: by all means, let readers search. But give ’em tools that let them get back to what they’re reading as quickly as possible.