Safari Flow and the EPPO-fication of Books

Summary: Safari Flow represents a move to Every Page is Page One navigation for books, but its success is limited when the content is not written in Every Page is Page One style.

At Tom Johnson’s suggestion, I have recently subscribed to Safari Flow. Safari Flow is a new take on the Safari Books Online concept which allows you to rent online access to a large library of technical books. What makes Safari Flow different? Essentially, it takes an Every Page is Page One approach to the navigation of the content it provides.

Whereas earlier services simply provided access to a library of books, pretty much on the model of a physical library, Safari Flow breaks books into pieces, recommending individual chapters based on you interests and reading patterns, and serving up a list of chapters from different books in response to reader searches. To put it simply, it provides a library of topics rather than a library of books.

This fits with the information seeking and consuming patterns that are summed up by the phrase “every page is page one”. That is:

  • People do not want to search in one resource at a time. They want to do one search across multiple resources and choose the best result from all resources.
  • People do not want large results, big compendiums that might contain the answer they are looking for somewhere, but small results in which the answer they want is easy to locate.
  • People want content to be up to date. Owning a shelf full of out-of-date books is not as useful as renting access to a library of current books. (An expression of the general principal that you should own appreciating assets and rent depreciating ones.)

A library of topics

Safari Flow search results and recommendations follow this pattern: searching across the entire library and returning sections and chapters rather than whole books. It is an attempt at the EPPO-fication of books.

Does it work? Sort of. It worked well enough in my 10-day free trial to make me (somewhat reluctantly) shell out money to subscribe. It works because it gives access to content not available for free. But the experience also highlights the problems that arise when you attempt to give EPPO-style access to book-style content.

One of the books I use all the time, and to date have used in paper format (my copy is beginning to disintegrate) is Michael Kay’s XSLT2 Programmer’s Guide. It is available in Safari Flow, and in an updated edition from the one I own. That was part of what sold me on the service. But in practice, I never end up using results from it in Safari Flow searches.

Some books don’t EPPO-fy well

Why not? Because Kay’s book is divided into a very few very long chapters. When Safari Flow attempts to serve its content EPPO-style, it serves one of those very long chapters. There are several other books on XSLT in the collection, some of which happen to be divided into shorter chapters. The results from those books get me much closer to the information I am looking for, and they are much more recognizably relevant results within the list of search results.

Search favors EPPO content

Are those books better than Michael Kay’s book? Perhaps not. Kay is one of the giants of the XSLT space, and an excellent technical writer. But his book is not designed in an Every Page is Page One style, and thus when I have the opportunity to search across multiple works, I end up using those books that work in a more EPPO-fashion. For the most part they are good enough for my immediate purposes. If they ever fail me, and if the need is sufficiently pressing, I might turn to Kay’s book as a last resort. But Safari Flow has turned it from my most consulted to my least consulted work in the blink of an eye.

Indexes and EPPO-fication

You may be asking, why not use full text search or an index to go right to the spot you need in Kay’s book. Safari Flow is not really set up that way. It is about delivering discrete chunks of content, not about narrowing down to individual words. (You can, obviously, search within a chapter once it is open in your browser.) And that’s fine. It is an EPPO-based navigation and as such it is delivering whole topics, not pointers into arbitrary locations in the middle of things. That’s a good thing.

The index itself is an older attempt at the EPPO-fication of books. By delivering you to an arbitrary location within a book, it is attempting to give you the page one you want rather than the page one the author choose. And this is why indexing has always been such a difficult art. If it were just about the occurrence of keywords, then indexing would be simple and mechanical. But good indexing is about the occurrence of substantial mentions of key concepts, and that is difficult to provide in a book that was written to be a consecutive narrative.

Must EPPO-fy the content, not just the navigation

Ultimately, then, indexes and Safari Flow both highlight the same flaw in the project of EPPO-fying books. It is not enough to EPPO-fy the navigation. You also need to EPPO-fy the content. If Michael Kay’s book were written and organized in more of an Every Page is Page One style, it would work much better in Safari Flow, and it would probably still be my go to work for XSLT questions. (Or rather, it would be my go to result within the search results of my go to work — Safari Flow).

And this is the really important point. When a book is used alone, as a paper book is, then the failure to support Every Page is Page One access effectively may be a problem for the reader, but it is not necessarily a fatal problem for the author. Once the reader has bought the book, they will continue to use it unless it is so bad that they are willing to shell out more money for the competition. But put it into an environment where it is competing with many other volumes each and every time the reader searches, and its lack of EPPO structure is going to punish it severely.

The market for technical information is now global. Your content is now competing with content from around the world in the Every Page is Page One arena of the Web. Whether it works as Every Page is Page One for the reader is going to determine how often it gets read, with all the consequences for your career and for the reputation of your company’s product that that implies.

Want to chat about what it takes to get there? Feel free to get in touch.

, , , , ,

4 Responses to Safari Flow and the EPPO-fication of Books

  1. Adam Witwer 2014/06/18 at 09:14 #

    Thanks for the thoughtful write-up about Safari Flow, Mark. As the product manager of Flow, I’d love to talk more about how we might make the product more useful to you and the experience generally better.

    I enjoyed your take on Flow and how a reader experiences its content, and I thought I’d provide some additional context. As you probably know, at Safari, we partner with publishers and have no direct influence over how they construct that content. But Flow’s recommendations and search results are influenced by historical usage data across our products. In other words, content that readers (or watchers, in the case of video) find most useful is “rewarded” and is therefore more likely to be seen by other users. As Flow matures and usage data accumulates, content that is constructed in a more EPPO-fied way could thrive in this ecosystem, which could in turn influence how publishers and authors develop new content. An interesting thought!

    Do your ideas regarding Every Page is Page One extend to non-technical content, too? We have (to name one example) business-related titles in Flow, and I’m curious to hear your impressions of how well Flow works for someone reading that type of content. But that might be a subject for another blog post. Thanks again for the post and for using Flow.

    • Mark Baker 2014/06/21 at 07:05 #

      Thanks for the comment, Adam.

      I find I do three kinds of searches, which we might call task-oriented, reference-oriented, and learning-oriented.

      Task oriented searches are questions like, how do I access a namespace declaration in XSLT? They relate to a specific problem I am trying to solve right now. For these, Google is unbeatable, and usually lands me on places like StackOverflow or a forum.

      Learning oriented searches are when I want to learn more about a specific subject. For instance, if I want to understand XPath better. For these, Safari Flow seems very well suited.

      Reference oriented searches are when I want definitive details on a particular feature, such as the exact operation of the XPath document() function.

      Google is not so great for reference searches, as there are not so many complete references on the Web and it can be hard to surface them. If all the content is Safari Flow were EPPO, it would be great for this, and where the content is EPPO, is works well. Unfortunately, for the reasons you point out, not all the content is EPPO, and when the content is not EPPO, Flow does not work well at all for reference searches.

      This leaves a Gap for the kind of search for which neither Google nor Safari flow is ideally suited. And when I am doing technical work, I do this kind of search — the reference oriented search — all the time.

      Since you don’t have much control over the content, I would suggest that the Flow experience for reference searches would be greatly improved by providing a list of search results from within each chapter you return — perhaps through a form of progressive disclosure. In other words, when you display the chapter in the search results, have a link that says something like, “See results from this chapter”, and then displays a list of search hits within the chapter.

      You could apply the same learning algorithm to these results to improve their quality over time.

      It seems to me that the long term success of Flow will depend on people choosing to search Flow over Google for their tech related questions. That’s tough, because it will never rival Google for the task-oriented questions. It will likely always win for the learning-oriented questions, but they are relatively few, and we do a lot of our learning hands on — relying on task and reference oriented questions to move forward. The battle ground, therefore, is reference-oriented questions.

      Today I am finding Flow frustrating for those questions, even though it often has better content than Google, because the content is hard to find. I’m not sure whether I will be renewing my Flow subscription if that frustration continues — I need to use Flow a lot to justify the subscription price.

      I hope that Flow does influence more authors and publishers to move towards a more Every Page is Page One style, and I think it might happen — but it will depend on how heavily it is used. I think improving its usefulness for reference searches will help it get the level of use necessary to start changing habits.

      EPPO applies to the task and reference uses of content on all subjects — the Web is a naturally EPPO medium. It also applies to learning in all subjects when people learn by doing. The linear model really only applies when people sit down for a good long read — which they still do for pleasure, but much less often for work than they used to do.

  2. Mark Nathans 2014/06/24 at 16:02 #

    Mark, good analysis of Safari Flow, which represents one of the best attempts by a publisher so far to re-package curated technical and how-to content into something that competes with, and sometimes vastly improves upon, content can be found for free on the web.

    I was initially excited to look at Flow when it first came out, but was disappointed to discover a repository of book chapters, rather than a library of self-contained, targeted topics. As Adam confirmed, they make no attempt to re-organize content into chunks that would be more suitable for short-form consumption, i.e. solving a problem, answering a question, or getting reference information on a specific subject.

    One irony here is that many books in this genre, like the Michael Kay XSLT book, are already authored with a decidedly EPPO approach to the content, due to an increasing awareness on the part of authors and publishers that very few of these books are read sequentially, cover to cover. A quick review of Amazon.com bestsellers like QuickBooks 2014, or Head First Java, or Scott Kelby’s Lightroom 5 book also reveals a structure that consists essentially of EPPO topics loosely organized into a sequence of chapters. It would be relatively easy for this content to be searched and presented by topic in Flow, rather than always display the entire chapter they happen to reside in.

    From what I can tell, Flow’s algorithms automatically adhere to a chapter orientation, regardless of the level of granularity with which the author originally approached his content. This applies even to O’Reilly and Pearson titles, the two publishing enterprises that originally joined forces to found Safari Books back in 2001.

    The other drawback is that none of Flow’s content seems to be accessible from a Google search, requiring the reader to first jump into the walled garden for their higher-quality content. As Inkling has demonstrated, displaying hits from their curated content (also unfortunately chapter-based) in Google’s search results makes it much more competitive with material that is freely available other websites. Once the reader clicks once or twice inside the Inkling book, they are required to log in or purchase the title.

  3. Mark Baker 2014/06/26 at 14:39 #

    Thanks for the comment, Mark.

    You are absolutely right. In many cases the content *is* in eppo format, but the engine just can’t recognize it.

    You are correct about Google too. A lot of the content they have is better than what is available via Google, but Google offers programmers, in particular, such a wealth of working code examples that solve particular problems that it will usually be their first point of search.

    That said, without EPPO organization, the content might not do so well in a Google search.