Chris J. Karr, January 11th, 2010

Lest I give anyone the wrong impression, Codex work has been progressing steadily, if a bit quietly. My last blog post on the topic described a user-interface scheme, which since I’ve abandoned in favor of a concept that simply works better than what I had in mind a month ago. No one ever said that software design wasn’t messy. :-)

The UI design that I’m previewing below addresses several issues that continue to plague the current Books interface:

1. Data availability. In the current version of Books, metadata is spread among several windows and tabs, making it difficult to review an entire record easily. The canonical metadata is in the details view, while the more readable overview (in the main window) only shows a small subset of the available data.
2. Printability. Printing out record data is more of a priority for users than I acknowledged in Books 3. The new UI drastically simplifies and improves the printability of book information.
3. Portability & scalability. When I created Books 3, I had no plans to target any platforms other than the Mac. Since that time, we’ve witnessed an explosion of fully-capable computing platforms that no longer fit the desktop mold. This new UI will be initially implemented on the Mac, but I have plans to port it to other platforms once the Mac app is released.

Please note that the following interface is intended for dealing with single records at a time. At a later date, I’ll be happy to share details about the interface that displays information across records (record browsers).

For screenshots and descriptions of the new interface, please read on.

In order to make book metadata more accessible, I’ve created a hybrid Cocoa/WebKit view for records that combines the ease-of-use & presentation efficiency of a traditional web page with the features and functionality of desktop-class UI toolkit. In the screenshot below, we have a custom web view displaying the metadata for a comic book in my collection. (I use comic books in my examples, because they are very rich metadata-wise and provide good complex record examples.)

Now, one of the limitations with web interfaces is the traditional form model. To update a value on a page, you typically needed to find a form, fill in the values, and submit the new information. This would travel to the server and return a new version of the page that the browser would reload. (Latency galore.)

In some of my recent client work, I’ve been using modern JavaScript toolkits that have greatly improved the usability (and programmability) of web pages. In the current template, I use jQuery to avoid the form-submit-reload paradigm. If you were to double-click one of the static text fields in the screenshot above, it would turn into a fully-editable text field:

When you click away from the field, it reverts to its original state with the newly entered value. This is convenient for editing existing metadata, but presents a problem for adding new metadata. I’ve solved this problem by introducing special links that invoke modal dialogs when pressed. If you press the “add contributor” link in the screenshot, the following panel drops down:

These specialized panels allow you to add new metadata to the record in a quick yet structured manner.

In order to better conform with the ePub specification, Codex no longer hosts dedicated fields for authors, illustrators, editors, and translators. You add this information by adding a contributor, specifying the name, selecting the role, and selecting whether the new contributor is a primary contributor/creator. This is much more flexible for keeping track of those who made your books in whatever roles they occupy.

With respect to the other metadata, I am splitting it into two major parts. “Standard details” map directly to ePub and other standard bibliographic fields. User-defined metadata is now located under the “Custom details” block. Here, you can define whatever key-value pairs you want to use to describe your record. This replaces the user-defined fields in Books 3 as well the fields in the “Copies” and “Reviews” tab.

I am replacing the Books 3 lending history with a more generic “Item history” section. This section allows you to define events associated with a record, including when you lent an item out and when it was returned. If you are a book collector and want to record when a book was purchased or sold, the history section is what you will use.

The screenshot above also shows the new “Content” block. This is a replacement for the Books 3 “Files” section and I am implementing an extension mechanism that allows you to open your content in other viewers, copy it to the pasteboard, or upload it to a variety of online sources. The available actions will vary based upon the type of the particular content.

In each of the screenshots above, a small pop-up button reading “Default” is visible in the bottom-left corner of the window. Since the bulk of the view is implemented in WebKit, an HTML-based templating engine is used to drive the display. (This is currently an immature engine implemented for testing that I will either improve or replace. I would like to integrate MGTemplateEngine as a replacement, but I’ll need to see how much of it must be rewritten for Tiger.) This templating system is the successor to the display plugins in Books 3 and it will make it much easier for end-users to adapt the display for their particular needs.

The final major change is that Codex is using the Cocoa document architecture to allow you to open more than one record at a time:

Books 3 only allows you to view one record at a time. This new arrangement permits side-by-side comparisons among other new options.

~

This work is still in its early phases and I don’t expect to have anything to release for a few more months. This new approach requires me to write quite a bit more code, but I think that the improvements are worth the delay. From my perspective, this new UI holds a lot of promise and should solve many of the major issues with the Books 3 UI without taking any major steps backward.

I’m interested in hearing any opinions on this new approach. Thumbs up or thumbs down? Does it solve any issues for you or does it create new ones? Let me know in the comments.