eBriefing is an enterprise app developed by some of my friends and colleagues at MetroStar. It is a system comprising a Builder (a SharePoint-based web tool to help people build digital briefing books) and a Reader (a free mobile app that lets people consume digital briefing books). I will confine my thoughts here to the Reader, which I downloaded and explored on my iPad. I have not yet seen a demo of the Builder.
Although eBriefing bills itself as “the first and only electronic briefing book designed for the needs of government and enterprise,” I’d argue it’s the only/first commercial electronic briefing book. That’s because I work in government IT and I know of two other electronic briefing book systems currently in use. The difference is that these systems were developed in-house, whereas eBriefing is available as a commerical product for any government agency to procure. Their description is great:
Say goodbye to old-fashioned paper briefing books. eBriefing transforms the way intelligence is generated, organized and delivered within the enterprise.
So I’m all for transforming the old-fashioned paper briefing book process, but I don’t think that eBriefing truly does this. It does modernize it very nicely, and it’s a nice app, but it doesn’t transform it. Here’s why:
Much like Microsoft SharePoint, this app is genius in that it allows people to continue doing things the old way, but with the satisfaction that they’re using the latest technology. Of course, a tablet is much easier to tote around than a big, honking 3-ring binder. But underneath the hood, not much has changed: we’re still working with a document-based model of content production that has been in place since Gutenberg started making it easy to print books. There is no way to mash up any of the data in these files. The true tragedy is that an app like this doesn’t make use of the affordances of the technology: we’re still limited to the metaphors of a book. Simulated pages simulate turning. We can end up with tables of content that aren’t interactive. But I understand why the designers have used the book metaphor: it’s what we know, and frankly, it’s hard to change our mental models.
And yet sometimes the metaphor becomes tortured. Here, I find this is the case with “bookshelf” and “library,” which are the two main overviews of the app. “Library” is a view of all the books available to you, but still residing on the server. “Bookshelf” is a view of all the books you’ve downloaded and have available to you in an offline mode. While the offline reading mode is an excellent (and necessary) feature, I struggled a bit to figure out the difference between “library” and “bookshelf.” At work, we’ve also been struggling with the “library” metaphor in our app-building efforts, but we’ve conceived of the library as all books available on the device (at rest). I suspect the problem is with the library metaphor in the first place: if you think of library as your town or college library, then it is most like the books-on-server model: you can go get them, but they’re not at home on your bookshelf yet. However, with digital distribution models for books, our sense of “library” has changed, and now it’s much easier to “move” a book from the “bookstore” to your “shelf” with little more than a whisper. So I propose we consider alternative metaphors for use in these applications.
Ok, enough of skeuomorphs. Here are some other observations about usability and the interface design of eBriefing:
- Multi-platform: it’s available on the iPad and Windows tablets (8/RT).
- The graphics are lovely.
- The interface for adding notes and marking up the text is elegant and uncluttered. The notes feature is relatively “flat” (if flat is the opposite of skeuomorph).
- Search works well within a single book.
- The first-time-use, in-app tutorial is nice, but a little overkill: I know that a button labeled “bookshelf,” for example, will take me to something called “bookshelf.” It would have been a better use of space to say what the bookshelf is or does.
- The pinch gesture is enabled, so that I can zoom in and effectively make the text larger. While this is great, esp. for older readers who need larger text to read, I found a compatibility problem with the page-turning feature. See cons, below.*
- From what I can tell, each “book” is one long document with the ability (via the table of contents) to jump to a particular section. There aren’t linkages amongst the content of different books. There is no granular metadata on the content, only the reader’s interaction (bookmarks, for example).
- No library-wide search.
- Although the images in the table of contents are eye-catching, I’d imagine it could be hard and/or time-consuming for staffers to find graphics for each chapter, especially for dry subject matter. Plus, I expect that when I jump to the beginning of a new chapter, I’d see that same image recalled in the book — but I don’t. The visuals in the table don’t match the actual content.
- While I like the interface for the notes feature, I wish I had the option to enable autocorrect. It helps me type faster on the iPad. It’s also a problem that I can’t see the notes at the same time I see the entire page, unless the page is in portrait mode. The notes cover part of the content on landscape-mode documents.
- *Here’s another limitation of the page-turning metaphor: it only works when the entire page is wholly in view. This means that if I zoom in to read, even a little, I must first zoom back out before I can advance to the next page. I think this is the largest UX problem I’ve found with this app.
In sum, I think this is an elegant app that could help government agencies reduce paper (and help officials reduce the bulk they have to carry), but I think it’s an interim step in that modernizes the process, but doesn’t truly transform it.