Blog RSS Feed

Archive for August, 2007

Visualization: Character Relationships across Religions

Friday, August 31st, 2007


A list of characters (‘Lord,’ ‘God’, and ‘You,’ are the most prominent) runs along the bottom, with arcs connecting them.

This visualization, by Philipp Steinweber and Andreas Koller, comes from the textual analysis of different religions’ holy books (red = Hinduism, yellow = Buddhism, green = Islam, blue = Judaism, purple = Christianity). Below each character is a list of verbs associated with him or her in each religion.

Their intent is (presumably) to show the commonalities among the different religions; I’m more interested in the technique behind the visualization itself. You could, for example, apply the technique to just the Bible and end up with a similar visualization. You could even do a similar color-coding, except with the Old and New Testaments.

Via Infosthetics, which has a few more examples of biblical visualizations in the comments. Tim Regan of Microsoft notes, “The whole area of abstract visualizations of books seems to be growing, and the bible seems to be a good testbed for these projects.”

Experimental Interface for Browsing Chapters in the Bible

Thursday, August 23rd, 2007

Try it out. (It works best in Firefox with at least a 1000-pixel-wide screen.)


A grid of Bible books divided into columns and rows.
A half-size (non-interactive) image of the interface.

A closeup of the mouse cursor hovering over Psalms, with the title of Psalm 23 appearing below.
Hovering toward the left side of the Psalms shows you the title of Psalm 23.

A closeup of the mouse cursor hovering over Psalms, with the title of Psalm 121 appearing below.
Hovering toward the right of the Psalms shows you the title of Psalm 121.


One challenge of developing a hierarchical Bible interface (going from books to chapters to verses) is the sheer number of options: 66 books = 1189 chapters = over 30,000 verses. Obviously you’re not going to show someone 30,000 (or even 1189) choices all at once; you need to prune the display somehow.

Often the approach taken by Bible interface designers is to divide the Bible into testaments (Old and New), then books, and finally chapters. This screenshot of the NET Bible iPhone application is typical of this approach:

The Old Testament and New Testament appear as options on the iPhone, with arrows indicating to tap to browse further in the hierarchy.
Tapping either the “Old Testament” or “New Testament” option leads to a list of books in that Testament, which leads to a list of chapters in each book, which leads to the text of the chapter. (This image comes from the blog This Lamp, where Rick Mansfield has the enviable job of reviewing Bible iPhone applications.)

One limitation with this approach is that the design has to accommodate the wide range of chapter counts in the Bible—from single-chapter books to the 150 Psalms. This variety makes certain kinds of interfaces hard to use. The NET approach above scales pretty well, though I wouldn’t look forward to all the scrolling needed to reach Psalm 150.

There’s nothing inherently wrong with this approach, however, especially if you think hierarchically. But I’m always eager to explore alternative interfaces that simplify things for at least some people.

Before I get into the specifics, I want to acknowledge an Ajaxian article on the .Mac Web Gallery as the inspiration for this interface.

How It Works

My goals with this project were:

  1. Expose the book/chapter hierarchy in the Bible without creating a deep hierarchical interface.
  2. Provide more information than simply the chapter numbers for each book.

The result is a 1000×479-pixel grid. Books appear in color-coded columns based roughly on genre. Similar books (e.g., 1 and 2 Samuel) appear next to each other to minimize the vertical space required for the display.

The size of each book’s rectangle generally corresponds to the book’s length. The New Testament takes up about three times as much space as it should when compared with the Old Testament. A New Testament at the same scale as the Old would be too small to be workable. People tend to read the New Testament more than the Old, anyway, so it probably makes sense to enlarge it, though perhaps not as much as I’ve done here.

Behind the scenes, a script vertically divides each box into the number of chapters in the book. Genesis, for example, has fifty vertical slices, one for each of its fifty chapters. Hovering over one of these slices shows all the headings contained in that chapter. Moving to the left shows you the headings for the previous chapter, while moving to the right shows the headings for the next one. Clicking a slice takes you to that chapter in the ESV Bible.

This interface lets you discover a lot of information with minimal effort:

  • The order of the books in the Bible.
  • Genre groupings.
  • The rough size of each book compared with other books.
  • The number of chapters in each book.
  • The subjects of each chapter.
  • An overview of a book’s subjects if you flip through the book quickly.
  • The text of the chapter if you click.

The Code

Concerning the code and markup, the page is valid XHTML 1.0 Strict, with a preponderance of ids as hooks for the Javascript but otherwise pretty clean. The Javascript is unobtrusive, so someone without Javascript can still get to the first chapter of each book. (A page with truly accessible fallbacks would place all the chapter headings in the HTML and use a script to hide them and then show them on demand, however.) All the chapter headings appear in the code; I figured AJAX calls would be too slow to give the instant feedback the application needs.

The application uses the base2 Javascript library to iron out some of the differences between browsers. I like this library because it doesn’t do things for you the way some frameworks do, but it removes a lot of the headaches for developing cross-browser applications (attachEvent vs. addEventListener, anyone?).


It requires some precise mouse coordination to get to a specific chapter. It’s not great for people who have poor mouse control or who are using a low-quality mouse. It might make sense to expand the horizontal area allotted to each chapter.

There’s no reason the books have to be in a grid; it would work fine if they were sequential. You could then precisely allocate the width for each book based on the number of chapters it contains.

You could show more than just the headings in the chapter—you might show the first part of the chapter, pick out a few key verses, or even attempt to show the complete text of the chapter in the popup.

I’m not crazy about all the different colors. It’s not bad for demonstration purposes, but I’d probably choose a more-restrained palette in a production environment.

It probably doesn’t work right in Opera, Safari, and IE6 and below. It also won’t work on an iPhone since iPhones don’t send the necessary JavaScript events. It probably wouldn’t work that well as-is on an iPhone anyway; it requires too much precision. Indeed, the straight hierarchical interface model might be best for an iPhone.

The URL in the status bar doesn’t change when you hover over different chapters in the same book. It’s not a big deal, but it’s irksome.


I hope you find the interface useful (or at least intriguing) and that it inspires you to create a Bible-browsing interface of your own. Leave a comment and a link if you do—it’s always fun to see new ways of looking at the Bible. (Creating a mockup, a low-fidelity prototype, or even just a word picture is a great way to test ideas; you don’t need to develop a full-fledged application to show off your concept.) Comments on this application are of course welcome, too.

Indexing English Place Names to the Original Languages

Sunday, August 19th, 2007

Jason asks whether it’s possible to index the English geocoded place names to their original Greek and Hebrew equivalents via Strong’s numbers:

I’m the developer for and i’ve been planning to integrate geocoded places into the app for a while. I ran across your kml, and though its really useful the way it is now, i was wondering if you had considered adding strongs number to the entries.

The reason i suggest it is, having that number would provide an easy way to distingish between identically named places and would also provide a very fast way to index and cross reference those coords with other xml bible documents. I’m having to run a script that matches the entries by word, but differences in spelling, spacing, and special symbols makes that kind of match a little inaccurate, or at least incomplete.

Answer: I can’t think of a good way to do something like this automatically. To do it accurately, you’d have to have programmatic access to an ESV-Strong’s alignment (since the ESV was the starting point for the geocoding work). The ESV Reverse Interlinear New Testament from Logos has Strong’s numbers, but the Old Testament equivalent doesn’t. And even if it did, I’m not sure how to extract the Strong’s numbers programmatically—or even whether it would be legal to do so. (Probably not.)

Straight string-matching with the KJV text gets you 717 of the 1176 distinct ESV names, or 61%. You might be able to statistically interpolate some of the rest by looking at Greek and Hebrew words that appear in every verse where the name occurs. Unless Crossway releases a Strong’s alignment through their API, however, you’re probably stuck with doing manual work to create an ESV-Strong’s place-name alignment.

If you want to produce one, of course, go for it. Any readers with suggestions about how to create this kind of alignment should feel free to speak up in the comments. (Hey, it never hurts to appeal to the lazyweb, no matter how obscure the request.)