March 21st, 2010

Given some of the oddness that I’ve seen in Sourceforge as of late, I’ve gone ahead and packaged up the full source code to Books 3. It’s not the cleanest or most well-organized code, but there should be enough there for folks wanting to take the Books 3 code and run with it.

Enjoy!

March 20th, 2010

I wanted to post a quick note about the state of Codex development. With the announcement of the iPad, I’ve put the development of the cataloging tool on hold as I waited and saw what Apple releases with the new version of iTunes. In short, it appears that iTunes is being tweaked to handle book content as well as music and videos. Since it’s conceivable that the cataloging interface will be a lot like the rest of the application, I wanted to wait and see what that looked like before putting together functionality that Apple would simply replicate. Since everything’s ePub in this brave new world, Apple may end up doing much of the hard work that I originally planned.

I’m still moving forward with using ePub as a record medium for physical books. To encourage myself to move a bit quicker on this front, I’ve stopped using Books 3 as a means for cataloging my weekly comic book runs and the growing pile of issues will serve as a good motivator for getting the ePub creation tools out sooner rather than later.

Thank you for your continued patience and I look forward to discussing more about where Codex fits in an ePub-enabled iTunes future.

January 31st, 2010

A few days ago, I posted a blog entry on my initial impressions of Apple’s iPad tablet device. I explicitly did not go into the reading implications as I wanted to save those thoughts for this post. I have a lot to talk about, so thank you for your patience reading this.

First of all, let me address the iPad from the Codex perspective. Overall, I think that the device is a net win for Codex given Apple’s adoption of ePub as the publishing format. In short, this means that content that you create in Codex should be accessible via iBooks (assuming a way to push unencrypted ePub files to the device). Instead of focusing on a native Codex viewer for the iPad, I can instead focus on making your book metadata as accessible as possible within the new iBooks application. (I’m kicking myself for not adopting and trademarking that name years ago.)

In terms of reading content acquired from the Apple online book store, Codex should be able to read the metadata and catalog any Apple-ePub files that you can transfer from your device to other platforms. Assuming that Apple has implemented their DRM in the same general manner as others (metadata is in the clear, images and book text are encrypted), iBook files will have the same level of accessibility as files purchased on the Nook or through Sony’s online bookstore.

While I am not initially prioritizing the creation of viewer for Codex-generated content on the iPad, there may be some potential for a portable editor. Since I have a full plate working on the desktop application, I am waiting until I have an iPad before making the decision to port Codex to the platform as an editor. However, I will keep the iPad in mind as I continue the Codex UI development so that I can minimize the differences between the desktop and mobile interface. Since the iPad sports a 1024×768 display, the only major deviations that I will tolerate are differences between the input methods (touch vs. keyboard & mouse).

Those are all the thoughts that I have now that directly pertain to Codex and the iPad. If you’re interested in my more general thoughts about what the iPad means for the electronic reading ecosystem, please continue onward.

January 27th, 2010

Since the most common e-mail complaints that I received about Books dealt with barcode scanning and quickfill, I thought that a post on the current state of these topics in Codex would be helpful.

Read more for updates and screenshots.

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.