I was debating over Job or Jonah for the second book, and decided on Jonah because it’s shorter. This doesn’t mean I’m lazy, it means I don’t want to dedicate a very large amount of my time to a new book when I don’t feel fully satisfied with Genesis. However, with the reader in a semi-stable state I’m ready to make the announcement.

There is still a large amount of work I want to do with the reader, but I have decided to create parallel readers. I made the mistake of updating the last reader in-place and took me three days to complete the new reader, during which the old one was unusable. So having different readers available will allow the user to read the text while I’m working on a new version. Yes, I know about revision control and test sites. I just don’t care — it’s a labour of love, not of money.

At any rate I should put a notice that the user has to click on the verse to get the notes. Or should I? I really like how the NET bible does things, but I also like the comparative columns view that biblegateway has. What I really want to do is merge those approaches, and I’m close — the new reader will combine the best features (in my mind, anyways) of both readers and then we will iterate on usability from there.

Why am I working so hard on the reader and not the text when people can just read the text on the wiki? Because having the notes beside the text allows me to easily edit the text and the notes together. This brings to light the following major issue, that of what exactly the NSV is. The NSV is not Rashi. I’ve merely attached Rashi to the translation as an added service. I have considered moving Rashi to it’s own separate document because of this but it is a very low priority thing.

I have also considered how the reader works. Right now it pulls the text in off the wiki in PHP and then converts it into a javascript array. Perhaps this approach is a little cumbersome. I like how Net has a streamlined view, but looking at things more simply a chapter by chapter view (ala biblegateway) or verse-section view is also fine. This insinuates that I don’t need to have clickable notes. There is also the major issue of formatting the page. This isn’t going to work well with Dokuwiki since the some bibles have special formatting for quotes and poetry, which might need to be replicated.

Ultimately DokuWiki is probably going to be the best solution for this and I will have to give up the idea of having it fully readable on dokuwiki. I have hacked out a dokuwiki parser to separate sections, handle italics and bold at times, and links — but some aspects of the bible such as linking notes are not supported by dokuwiki.  If I add newline processing to the mix, quote and font control, or rather as I do this, the document will become more and more unreadable on the Doku. I’ve resigned myself to this as the reader is a better experience. But the question remains precisely how the formatting will be done. And underlying all of this is the full knowledge that eventually everything will need to be moved into Javascript, to save server costs.

It’s a thorny problem and I’d rather not worry about it. But with no money to hire a developer to work on an endgame-quality reader, I am stuck with inching foreward like this.

I have some ideas, I should get coding! Look for the book of Jonah sometime in April.