Subscribe to Updates

Click here to subscribe to new posts by email. We use Google FeedBurner to send these notifications.

Archive for the ‘Company Insights’ Category

You Might Need a Magnifying Glass…

Posted on: April 21st, 2010 by Craig Rairdin 27 Comments

I think I’ve mentioned before that the “iPad Version” of PocketBible is going to be what Apple calls a universal app. It’s not really iPad-specific. It will run on either an iPhone or an iPad. It decides at run-time which user interface to present and which features to enable. This differs from our Windows Mobile apps, which decide at install time which configuration to install (generally, a “PDA” version or a “smartphone” version).

We’ve been doing our development work on the iPad because that’s where the new features are. Yesterday Jeff installed to his iPhone just to see how we were doing. Everything worked fine, but we ran into a couple places where we forgot to do the “iPad Test” and as a result the iPad user interface was running on the iPhone. The result was the smaller of the two screen shots below.

Five panes on the iPad. Nice. Five panes on the iPhone with the font size set to 8 points. Ouch!

What’s cool is that it works fine. The tiny navigation overlays even pop up in each pane when you tap them in the center. It’s tough to hit the links, but then at 8 points, they’re tough to hit even with a full screen of text.

This points out a couple interesting facts about this project. First is that there are several features we created for the iPad that will “accidentally” start working on the iPhone, either in the next release or very soon after. For example, we’ll make it so you can open two panes (either two views into the same book or two books). And as I mentioned in connection with the video posted last week, some speed improvements that we made while developing for the iPad will affect the iPhone as well.

The other interesting thing is somewhat related. We share a lot of code between the iPhone, Palm OS, Windows, and Windows Mobile. So today when I was working on showing you a list of all your user-created notes, it was trivial to add the ability to search your notes because that’s a feature we added in PocketBible for Windows Mobile a couple years ago and it’s just been sitting in the shared code, waiting for a user interface on the iPad to expose it. (There won’t be any UI for it on the iPhone in the next release, but it could show up any time.)

The code that does note searching displays its results as a list of Bible verses. That is, if you have a note on John 3:16 that says “God loves me” and you do a search for “me” in your notes, you’ll see the text of John 3:16 in the results instead of seeing your note. So while I was in that code this morning I changed it to display the text of your note. In that case, the advantage goes the other direction — next time we build PocketBible for Windows or Windows Mobile it will automatically start showing the text of the note instead of the Bible in the search results.

I’m really liking the note-taking process on the iPad. With the new control panel, the entire application is still available while you’re writing a note. So just tap the “lock” button so your note editor stops synchronizing with the Bible text as it moves, and you can perform searches, follow cross-references, and copy passages without losing your place in your note. Leave that “lock” function active and you can follow a series of links from a note without having to go back to the noted verse and recalling the note. Again, this is an iPad-only feature in this case, since the iPhone is so much smaller. But it’s cool.

I don’t want to sound like an Apple zealot or iPad fanboy, but I’m starting to think the iPad is the platform for mobile Bible study. I know, I know — you’d like to make that decision for yourself. We’re getting close. It will be worth the wait.

PocketBible for iPad

Posted on: February 3rd, 2010 by Craig Rairdin 38 Comments

Apple announced its long awaited iPad tablet device last week, and like you we were all anxious to see it.

What we’re being told is that it will run most iPhone apps unmodified. They will only take up about 1/4 of the screen, since the iPad screen is significantly larger than the iPhone. We don’t have any reason to believe PocketBible won’t run on the iPad, but we’re doing what we can to make sure.

While the SDK has been distributed to developers, it is only a beta and we are unable to build what Apple calls “universal apps” that will allow the same binary file to run on either an iPhone or an iPad. We also don’t have access to pre-production devices, so we can only run in the emulator that is built into the development tools. So we have some reason to believe that PocketBible will work as-is but can’t be absolutely sure at this point because we’ve never seen it run on a device.

There are some simple user interface changes we’ll be making in the short term to better take advantage of the iPad’s capabilities. In addition, there are some new capabilities in the iPad version of the OS that aren’t yet in the iPhone that we’d like to investigate — what Apple calls “Core Text” is at the top of that list.

It’s not obvious from the end-user point of view, but PocketBible pushes the limits of the iPhone’s abilities when it comes to displaying text. PocketBible is exactly the type of application that the iPhone OS was not designed for — that is, an app that does sophisticated text rendering. The new iPad, with its bigger screen and potentially more usable keyboard, invites applications like word processors that need sophisticated layout capabilities. PocketBible is in that camp.

This is not unique to the iPhone. Windows Mobile also lacks key text rendering capabilities that are present in its big brother, Windows on the desktop. For example, it’s not possible in Windows Mobile to accurately measure the width of a piece of text as it will be displayed on the screen. You can almost do it, but it doesn’t work right for bold and italics. So we’ve had to implement our own functions for this.

We could probably get into a lengthy discussion of whether or not this form factor is something the public will accept. I’ve seen everything from people who want it to replace their phone (assuming they can keep from knocking themselves unconscious when they answer it) to those who point out that tablet computers with full-blown operating systems have failed to capture consumer attention, which causes one to question whether a similar device with a mobile OS stands a chance.

That said, one of my long-standing complaints about devices such as the Sony Reader and the Kindle are that they don’t allow any kind of third-party software. (Or at least until recently when Amazon announced a “Kindle Developer’s Kit” for Kindle.) My Kindle is great, but it’s horrible for Bible study because the software simply doesn’t have the features you need to access an integrated Bible library, or even perform moderately sophisticated searches. Viewed as a souped-up e-book reader, the iPad may stand a chance. While it’s hard to imagine anyone beating Amazon’s selection of e-books for Kindle, if anyone has a chance of doing so it would be Apple.

The iPad could actually be the perfect electronic Bible study device. It’s just portable enough to be truly portable, while being large enough to facilitate convenient cross-referencing between titles.

From a developer’s standpoint there’s not a whole lot to complain about. It’s like a big iPhone, so everything we’ve learned about iPhone and Mac programming transfers painlessly to the iPad. We’re not crazy about the shortsightedness of some of their new features (“split views” being at the top of that list for you programmers) but we’ve also seen initial shortsightedness in the iPhone OS get repaired in subsequent releases. Unfortunately, like the similar issues that arose years ago on the Palm OS, by the time the official solutions are released everyone has already coded their own work-arounds to meet user demand.

What all this boils down to is that we fully plan to support the iPad and in fact enhance PocketBible over time to take advantage of unique iPad features. We think it could be an ideal Bible study platform for those who have the spare change to invest in one.

The Story Behind the PocketBible NET Bible

Posted on: January 11th, 2010 by Craig Rairdin 11 Comments

We’ve known about the NET Bible since its beginnings, and several years ago we licensed the NET Bible for use in our products. We knew the Bible had extensive notes but didn’t think that would be a problem for PocketBible.

We put one of our employees to work on it and after several months it became clear that the challenges it presented were going to be greater than the potential revenue we could gain from it would justify. The problems were related to converting the original language references in the notes from a variety of proprietary fonts into the standard Unicode notation we use in PocketBible. I don’t recall all the details but do recall a meeting in which we decided to just drop the project.

A year or so later we heard from a programmer who had extensive experience with the NET Bible and wondered why we hadn’t yet made it available. I explained the issues and he said he’d be happy to tackle it. I sent him everything he needed to tag the NET Bible and notes for PocketBible. He asked a couple questions over the next week or two, but then disappeared. The NET Bible had taken another victim.

Then last November I heard from David Richards. David is a long-time Laridian customer and a fan of the NET Bible. He had been experimenting with our BookBuilder program, which allows anyone to create reference materials that are compatible with PocketBible, and wondered if we had plans to publish the NET Bible. I told him the story and warned him of the bodies it had left in its path. He seemed undeterred, so we came to terms on a price for his work and he set out to work on it. I figured that would be the last we’d hear from him, and went about my business.

Surprisingly, when I heard from David it wasn’t to ask questions. It was to give me samples from what he had gotten done. Before long he had made it through all 60,000 notes. We ran a brief test with a group of testers left over from PocketBible for iPhone and after just one update the NET Bible was ready to ship.

I wanted to tell you David’s story for a couple reasons. First is that we’re pretty excited about finally having the NET Bible and know what an accomplishment it was for him. He deserves a little recognition for his efforts.

Second is that David’s is a story we’ve seen play out a couple of times in the past and we’d like to see it happen more often. We’ll be releasing a collection of reference books in the next couple of weeks that were tagged by another customer who got interested in BookBuilder a year or two ago and has since tagged a couple of projects for us after doing some of his own. Our A.W. Pink, F.B. Meyer, and Andrew Murray collections were tagged by a customer, as was the Dake Study Bible Notes.

Of course tagging books isn’t for everyone. It usually requires extensive use of what’s called “pattern matching”, “regular expression”, or “grep” search-and-replace operations to convert a book from whatever format it might be to begin with into our HTML-based format for BookBuilder. You need to have a head for details and it doesn’t hurt to have a little programming background.

David and each of these other taggers are being compensated in some way for their work. We’d love to add you to our list of available taggers for new projects. You can get the standard BookBuilder program for $29.99 and see if it’s something you want to try. We have an inexhaustible list of books that need to be tagged. Maybe you have a favorite commentary series or reference title you’d like to see in PocketBible. Rather than wait for us to get around to it, why not volunteer to do it yourself?

Feel free to contact me directly if you’re interested: craigr@laridian.com.

Why We Don’t Talk About What May or May Not be Under Development

Posted on: December 14th, 2009 by Craig Rairdin 34 Comments

A recently posted comment questioned the wisdom of our policy of not talking about what may or may not be under development here. I thought I had discussed that policy here but apparently I haven’t.

As you know, before we started Laridian 11 years ago (October 1998) we spent ten years working at Parsons Technology. It was great to be able to make our mistakes at someone else’s expense before launching our own company. One of the things we learned was not to talk about our release dates before we were ready to ship a product.

There are two main reasons we’ve kept this policy over all these years and through two different companies. First, we don’t want to signal our plans to our competitors. We all compete for a limited number of customers. If we signal our intentions it helps other Bible software companies know how to allocate their limited resources to better compete with us.

The second reason we keep quiet about what we may or may not be working on is to avoid the extra work it creates. If we announce a product, we start getting calls and emails from people who want to know when it’s going to ship. If we announce a date and miss it (which is about a 100% probability in our business) then we have to deal with the customers who call or write to ask what’s going on. They always want to know an updated ship date, though if we missed it the first time I’m not sure why they think we’d get it right the second, third, or fourth time.

If we ignore those requests we’re perceived as unfriendly to our customers. So we have to take time to respond. You might argue that we have the same problem when we choose not to comment on what we’re doing. I can tell you, though, that it’s significantly different. When I can say, “We don’t talk about what may or may not be under development, but we appreciate your suggestions” it brings the discussion to a close. In fact in Tech Support that’s a predefined response that we can just paste into our reply and move on quickly. On the other hand, once we’ve opened the box and projected a ship date, we can’t easily close the box.

We have tried lifting this policy at various times. We did it for iPhone and it was OK for a while but when we ran into some technical issues that delayed the project by six months we ended up having to just shut off the flow of information for a while until we could figure out how to handle the issues. The combination of not really having anything helpful to say and having to answer a few customers who were downright nasty was difficult to deal with.

This raises the point that plans often change or are disrupted. I can’t tell you how many times we’ve completely changed our direction in an afternoon. Our decision to develop the original Web-based app for the iPhone (back when that was the only way you could do iPhone apps) was made on July 3, 2007 and a large amount of development on it happened on the July 4 holiday. Projects we had previously been working on were abandoned or delayed while we dedicated people to iPhone development. However, because none of this was public information, there was no time wasted explaining this massive change of direction to anyone. We didn’t have to apologize for missing a ship date, or reveal our plans for this new platform until we were completely ready to do so. (We actually hinted at it on July 5, but we didn’t really formally announce it until about three weeks later, when most of the work was done.)

I think part of our problem is that we want to be friendly and accessible. I think we’re way more accessible than most other software companies. I reply to every email sent to me, and we reply to all our tech support email in a timely fashion. (Just don’t call me at home. I mean, seriously, some people have no boundaries.) I reply to comments here on the blog. So the more information we have available and out there to talk about, the more time it takes. If we limit the information it helps us also limit the amount of communicating we have to do.

For example, I haven’t been tempted to give a long dissertation on the Android. It’s sufficient to say we may or may not be working on it. If you want to argue that it’s the Next Big Thing and that Google is obviously taking over the world and that we should just get over it and develop for Android, I can end the conversation by saying “we may or may not already be working on it”. I don’t have to get into a discussion of the relative size of the Android market vs. other platforms, the technical challenges of porting to Java, the state and maturity of the SDK, etc. I may or may not already agree with you. There’s no need for me to go into more detail. If I disagree with you, saying so might reveal our plans for the platform. If I agree with you, that also might reveal our plans. And I might be working on it while disagreeing with you on how great the platform is. Or I might not be working on it now, but agree with you and have plans to do it in the future. No matter what the situation is, commenting on it could lead you to the right or wrong conclusion, and now we’re back to the problem of signaling our intent to competitors and having to take time to communicate about it.

The obvious problem with this policy is that it may cost us some customers in the short term. However, if we’re not developing for a particular platform, then we plan to lose those customers anyway. If we are developing for the platform, we could still lose them in the time it takes for us to get our product out the door. So no matter what we do or plan to do, and no matter what we say, we still risk losing customers at any time. So if the other factors outweigh the benefits of talking about projects in advance, it’s worth not talking about them.

This isn’t always an easy rule to maintain, but every time we’ve broken it we’ve been stung by it sooner or later. We’re currently on a pretty tight-lipped phase after having been bit earlier this year. I’m sure we’ll loosen up again in the future and who knows, maybe our experience will be better. At least now you have some idea of our thought process on this policy and I hope that helps.

In the meantime, we may or may not be working on whatever it is you want us to be working on.

Paging vs. Scrolling on the iPhone

Posted on: November 17th, 2009 by Craig Rairdin 62 Comments

I guess I’m going to have to address this issue at some point, so here we go.

Apparently one of the more controversial decisions we made with PocketBible for the iPhone was to follow the other major eBook reader software like Kindle and eReader and present the text a page at a time rather than continuously scrolling. That is, to move through the text of a PocketBible Bible or book, you swipe right to left (or just tap on the right side of the page) to “turn the page”. The new page enters from the right.

The alternative is to present Bibles and books as a long stream of continuously scrolling text and allow you to use drags and flicks to smoothly scroll the text. This method is followed (with some variations) by some other Bible software programs.

You Only Think You’ve Seen Continuously Scrolling Text Everywhere

People tend to point to applications like Safari, which lets you flick around on a Web page to scroll up, down, left and right, and claim that “all iPhone apps let you flick to scroll”. This is true when you have a limited amount of text, but not when the text is virtually unlimited. For example, a Web page is a finite amount of text (and images and whatever). It can be rendered once into an in-memory buffer, then portions of that buffer can be moved onto the screen as needed. More importantly, the overall dimensions of the page are easily determined. The programmer can tell the iPhone “I’ll be scrolling around on a 1391- by 3287- pixel image of this page.” That way, the iPhone knows when you’ve hit the “top” or “bottom” of the page and can do that cool “bounce” animation it does when you try to go past the edges.

Even large scrolling lists — like your list of contacts or PocketBible’s search results list — have bounds that are easily determined. It’s easy to count your contacts or your PocketBible search results, multiply by the height of one contact or search result entry in the list, and tell the iPhone the result. So 25,000 search results times 80 pixels is 2,000,000 pixels. If you go past 2,000,000 the iPhone knows you’re at the end and stops asking for more (in this case it actually stops because you’re looking at the 25,000th item, but down inside the code it’s animating the end-of-list behavior based on the y-coordinate being greater than or equal to 2,000,000).

The iPhone needs to know how tall your view is going to be. The problem with the text in PocketBible is that it’s practically infinite in length, and the time it would take to calculate the height needed is probably measured in hours (or at least in minutes), not the milliseconds you expect when you open a book or change the font/size you’re using to display text. The iPhone needs to know this height and we can’t calculate it in a timely fashion.

There are ways around this, but because we can’t calculate the height in advance we’re violating a built-in assumption the iPhone has about scrolling views. So that means we have to code our own scrolling view or at a minimum do some nasty jury-rigging to fake the iPhone into believing it has a finite-length view when in fact it doesn’t.

You’ve probably run into apps like Facebook which shows you 25-50 items in a list then allows you to press a button to load more. Again, you think you’re seeing a long, continuous list but in reality you’re seeing a short, finite-length list and you have an option to see a longer, finite-length list. You just think it’s an infinitely long list.

When To Load the Text?

Because the text of the Bible or a reference book is so long, it’s impractical to load the whole thing into memory at once (both to determine its size and to have it available for continuous scrolling). So we use techniques that allow us to load the text in pieces. (In our case, one paragraph at a time.) The problem, of course, is that it takes just as long to load the whole book one paragraph at a time as it does to simply load the whole book into memory. To get around this, we make use of idle moments (such as while the view is “coasting to a stop” after a flick) to load some more text. Normally the processor isn’t doing anything during this time, so you don’t notice that we’re loading text at that time.

The problem is that it can take longer than that time to load a paragraph. And you may be furiously flicking through text, not giving us time to do any loading. In these cases, we end up using time that is normally spent to recognize your input gestures. As a result, the system seems to be slow to recognize your gestures, and the motion of the text gets jerky.

At some point, we have to draw the text to the screen, which also takes time. One option is to launch a second thread to draw text that has been loaded and decompressed. But since the iPhone has only one processor with one core, this second thread is no more efficient than the method described above (using idle time on the main thread).

Furthermore, there are limits on what kind of drawing you can do in a second thread. Because the iPhone is a relatively new OS and doesn’t have the maturity of, say, Windows Mobile (which, like iPhone OS vs. Mac OS, is also a subset of its desktop counterpart), there are significant missing components for drawing text in anything but the main thread. Apple assumes you’re going to do all your text rendering with its built-in Web view component. But it, too, is an immature component and doesn’t have all the features we need to support everything we need to do with and to the text. So they give us one really nice why to draw text, but limit it to only being used in the main thread of the application. The text functions that can be accessed from other threads are more limited in their scope.

A Little History

Our initial implementation of PocketBible used continuous scrolling. We released an alpha version (a preliminary release that was nowhere near feature-complete) to a small group of testers in January 2009 with the goal of releasing the finished product in March. Because of all the problems described above (and more), the scrolling was a bit clunky. I actually thought it wasn’t horrible once you got used to it, but the alpha testers hated it and sent us back to the drawing board.

For the next six months I tried variations on when to load text, how much text to load, what thread to load text in, when to draw, what thread to draw in, etc., eventually writing at least four complete, from the ground-up, implementations of loading, rendering, and scrolling text. Late in the process I threw it all away and started again and had a relatively good implementation. We released beta 1 and the testers weren’t happy with the scrolling performance.

This was pretty disappointing. We were tempted to just go ahead with this implementation, but when we tested with the newly released OS 3.0 the performance was significantly worse. Something had changed with the new OS and would have required starting over again.

What do the Other Guys Do?

At this point I paused and did a survey of other similar software. I wanted to see what kind of performance they were getting during scrolling, and if there was anything I could divine from applying a programmer’s eye to the use of their software. I opted to look at general ebook software like Kindle, eReader, and Stanza. I chose not to look at other Bible software because the general ebook readers have larger user bases and well-funded, professional development teams.

What I found was a constant use of a “paging” metaphor as opposed to “scrolling”. This was interesting. If they were “getting away with this” with their enormous customer bases then potentially we could do likewise.

User Fatigue and Reading Comprehension

Within a couple days I had a paginated user interface up and running and for the most part, the beta testers liked it. Sure, there were those who really wanted to scroll. But there were others who actually preferred the paginated approach. They found it required a lot less concentration on manipulating the text and allowed them to focus on reading. Their fingers weren’t in the way all the time. And when they tapped the screen they knew it was going to move exactly one page instead of flicking and having to figure out when/if to stop it from scrolling too far, then having to find their place.

This was encouraging because it gave us some very real benefits to the new approach. Paging required less interaction and less concentration on navigating, thus allowing more concentration on reading and comprehension. And the performance was adequate and the implementation simple.

At about the same time my daughter was complaining about a college class that required them to read hundreds of pages of PDF files from the professor’s Web site. The school made the case that this was part of their “green” initiative, but my daughter found that in order to easily read and mark up the text it was necessary to first print it, thus negating the green argument and costing her a fortune in paper and ink. (Ironically, whereas the school could easily have printed this material on a two-sided printer, my daughter could only print on one side, thus costing TWICE as many trees as the “non-green” solution.)

This led me to do some research on online reading vs. reading in print. It seems to be a consistent conclusion that offline reading (from paper) results in better reading comprehension. One of the reasons that was cited was that the eyes can easily go from line to line and from page to page in print, but when reading from the screen the eyes have to constantly adjust for the motion caused by scrolling. The difficulty of moving the screen to the next full screen of text resulted in the eyes and brain having to continuously re-locate their position in the text. The resulting diminished comprehension negatively impacts test scores and was one more point against my daughter’s school’s “green” initiative.

Interestingly, the results of this research could easily be applied to what we were doing on PocketBible. When you flick the text you have to stop and figure out where you’re at. When you turn a page you know right where to continue reading. If you avoid this by slowly scrolling as you read, your eyes can’t move from line to line as easily as they can when those lines aren’t moving. And your fingers get in the way.

So Where do we Stand?

In summary, the reason PocketBible doesn’t have continuous scrolling isn’t because we haven’t thought of it. It’s because we’ve tried several ways of doing it and none has resulted in acceptable performance.

While pagination started as a second-choice user interface, it turns out it’s used by all the large, well-funded, popular ebook reader software for the iPhone. And it turns out it has documented benefits when it comes to user fatigue and reading comprehension.

It cannot be argued that pagination is “not the iPhone way”. The large, continuously scrolling text often cited as examples of “the iPhone way” isn’t actually as large as our text. And there are lots of similar applications that don’t use scrolling as their user interface for books. So while it can be said that continuous scrolling is an iPhone way to interact with books, it cannot be said that it is the iPhone way.

I’m aware of the fact that other Bible software uses scrolling instead of paging. I’ve heard conflicting reports on whether they do this successfully or just “acceptably” in the opinion of their users. I’ve also heard that some do continuous scrolling within a chapter (thus avoiding the problem of having a large amount of text) but then have another gesture that means “next chapter”. This is great for Bibles but doesn’t solve anything for other types of reference books. And it creates a weird concept of “sometimes you flick to scroll and sometimes you have to do something else” to see the next bit of text.

I don’t have any insight into the other guys’ code so I can’t comment on why they may get acceptable scrolling behavior when we don’t. Maybe their standards aren’t as high. Maybe their code isn’t as feature-rich. Maybe they’re better programmers than we are. In the end it’s irrelevant. We are all playing the cards we were dealt. Knowing someone else at another table has a better hand than I do doesn’t mean I can win at my table. To continue but convolute the metaphor, you can either stay in the game with us or you can go play with someone else. We can’t control your behavior.

We have not disclosed our plans for any future features of PocketBible, other than to say we’re continuously working on it, and that the features you see in other versions of PocketBible will find their way into the iPhone version in the future. We have a long list of must-have features in PocketBible and a long-list of suggestions from all of you. We consider the must-have list to be the more important one at this time. We’ve been implementing little things from the suggestion list as we work through big things on the must-have list, but are prioritizing useful new functionality over simply changing the way things work.

Pagination is a feature that is not broken and doesn’t need to be fixed. While we may look at wasting another six months on scrolling in the future, we’ll do that at a time when it won’t cause other very necessary features to be delayed.

Before You Comment…

This article is meant to be informative, not to launch discussion. We already know that some of you would prefer to scroll rather than page through the text. If you’re just writing to tell us that, then you must not have comprehended this article very well. Try paging through it instead of scrolling. :-)

Furthermore, this article summarizes some complicated programming issues into imprecise layperson’s terminology. Like a paraphrase of the Bible, there is a lot lost in the process. If you are not a programmer and think you have an idea for doing this in a way we haven’t tried, don’t bother to comment. Chances are good you don’t really understand the issues and I won’t be able to tell you that without insulting you. If you’re a programmer and are sure you know how to do this better than we do, I remind you you haven’t seen our code so don’t know what we’re working with, then ask you to send completed, working code to me by email instead of discussing it here where we’ll only confuse the masses.

Comments are moderated. I will remove references to other iPhone programs. I will remove feature requests and off-topic posts. I will remove links to other sites. I may remove other things I haven’t thought of.

Now, other than the above, feel free to comment. :-)

Laridian’s Palm Pre Plans

Posted on: October 19th, 2009 by Craig Rairdin 104 Comments

We’re announcing today that we’ve signed a Memorandum of Understanding with Bits of God Software to be the exclusive provider of Bibles and other reference materials for an upcoming version of the popular Simple Bible application for the Palm Pre. Once completed, this will give current Laridian customers who have chosen the Palm Pre as their mobile platform access to the Bibles and reference books they already own for other platforms. It will also give new Simple Bible users immediate access to one of the largest collections of Bible-related content for mobile devices. The new program from Bits of God Software, currently referred to as Simple Bible Pro, will allow users to download new Bibles and reference content directly into the program from their account on Laridian’s site.

As we’ve said here before, programming for the Pre is a whole new challenge. Our existing code that runs on Windows Mobile, iPhone, Windows desktop, and Palm OS really gives us no leverage on the Pre. With that in mind we sought a partner, and when it comes to Bible software on the Pre, the guys at Bits of God are the best. We’re pretty excited about partnering with them.

Our current agreement is “an agreement to agree” so there are many details to be worked out yet. We’ve agreed in principle on most of the more difficult points of our relationship, so we don’t anticipate any problems. The important thing is that it looks like current PocketBible and MyBible customers will have a migration path if they choose the Pre, and that Simple Bible Pro will get a jump start over other Bible software on the device by having access to Laridian’s growing library of content.

Status Update – PocketBible for iPhone

Posted on: August 31st, 2009 by Craig Rairdin 34 Comments

We’re at one week since submitting the app to the App Store and I want to answer a few questions that have come up in email and in the comments.

  • We will not get any feedback from Apple until/unless the app is approved. The current status is “In Review” and that’s all we’ll know until they actually either approve or decline it. If they decline it, they’ll tell us why and tell us what to do to fix it. We don’t have any reason to believe they won’t approve it, or if they find problems, that they won’t approve it eventually.
  • We appreciate your offers to give us donations to cover the cost of development. We’ve thought about formalizing that process but at the same time you can “donate” by simply not using our discount codes when you place an order for add-on books. We’re embarrassed to even suggest such a thing and are humbled by your generosity.
  • We will be having some kind of site-wide sale once the new product is approved on the App Store. We’ll send an email out to current customers and probably post something here in the blog. If you’re interested in building your library, that will be a good time to do it.
  • You will have access to all your current Bibles and reference books from inside PocketBible for iPhone. I’m not sure how to make this more clear. Take a look at the first video here. All I’m doing is logging into my existing account using my customer ID and password (you can also use your email address instead of customer ID if you don’t know it). Once I’m logged in, I see a list of everything I’ve previously purchased for any platform. I can download any of those titles to the iPhone.
  • Memorize!, DailyReader for Palm OS, and the old PrayerPartner for Palm OS are programs, not reference books, and won’t be included in the titles you can download for iPhone. We have not announced our plans for a version of Memorize! or PrayerPartner for the iPhone. The features of DailyReader are built into PocketBible and will be enhanced in future releases of PocketBible for iPhone.
  • MyBible users will probably have the biggest transition to make. As you might know, MyBible was written by an outside developer who was a Palm employee at the time. We marketed it on his behalf. At the same time, we developed PocketBible for Windows Mobile in-house. It was the original product that Jeff Wheeler and I wrote starting back in 1998 and which motivated us to leave Parsons Technology in late 1998/early 1999 together with Jim VanDuzer to start Laridian. PocketBible for iPhone is based on the Windows Mobile code base and overall philosophy of operation. The differences are subtle but you may notice them. For example, MyBible lets you highlight a single letter in a word. PocketBible highlights entire verses.
  • Remember, this is version 1.0.0. Other versions are coming. If you don’t see a favorite feature, tell us about it, then wait. We’ll be constantly working on updates for the next few months. Those of you who got involved in iPocketBible.com in the very early stages remember that we issued updates every couple of weeks for a few months as we rounded out the feature list. We’ll be doing the same thing with PocketBible for iPhone.
  • If you can find it in your hearts, give us a nice review. Early reviews are important. If you can do us the favor of complaining to us directly by email instead of through your reviews on the App Store, that would be great. We’re going to do everything we can to be responsive and make sure PocketBible for iPhone is everything you want it to be. If people express their complaints through App Store reviews instead of directly to us, the product could fail before we have the opportunity to finish it.
  • We haven’t forgotten Windows Mobile. There will be a new release of WM next year and we currently plan to revisit PocketBible for Windows Mobile sometime before then and release an update. Nothing firm yet.

That’s it for now. I just checked and there’s no change in the status of the app as of this morning. I’m sure one of you will probably spot it before I do. :-)

PocketBible for iPhone Uploaded to App Store

Posted on: August 24th, 2009 by Craig Rairdin 42 Comments

PocketBible Splash ScreenThis afternoon I uploaded PocketBible for iPhone version 1.0.0 to the App Store.

Now we wait.

Apple says it will take about two weeks. We’ll see. I know that uploading took me only 15 minutes, but that was after spending hours trying to find the right combination of options NOT to choose and titles I was NOT allowed to use for the program. So I’m not going to be surprised if approval takes longer than two weeks.

In the meantime we have a lot of work to do on the Web site to get it ready for the release. We’re going to try to make some changes to the way our e-commerce works at the same time. Hopefully we won’t break anything important.

I previously posted several videos of PocketBible in action. So if you’re curious, take a look at those.

One of the last things to come together was the program icon. We went through three major themes before finding a last-minute idea with promise. Our first idea was to lift the Bible icon from our Windows Mobile app. But when we looked at the 60 or more Bible apps on the iPhone, it seems over half of them had the same idea. So we were afraid we’d get lost.

So then we went with a version of our company logo. That had some fans, but suffered from being not very scalable as we release new programs (i.e. we only have one company logo but we expect to have more than one iPhone app). Plus it was boring.

While this was going on we had an artist work on a “Bible in a pocket” icon. The beta testers weren’t crazy about that one.

One of our testers is a fellow developer. He turned us on to his icon designer, who had the idea to used stained glass as a theme. We weren’t crazy about this at first but then I found a stained glass artist in Minnesota who had done some very contemporary looking work for a Lutheran church that seemed like it might work. We contacted the artist (Nicholas Markell) and he was willing to work with us. There were some interesting copyright issues, but Nick was a very reasonable guy and was pretty knowledgeable on the topic and we were able to work through those very painlessly.

So the program icon and splash screen (shown here) are based on a stained glass window entitled “Baptism of Jesus”. While the baptism of Jesus has little to do with our program, a little creative reinterpretation makes it work well. The Holy Spirit, represented here as a dove, illuminates the Scriptures for the believer. The water represents the “living water” (John 4) of the Word of God that gives eternal life through the cross, which is in the background of the image. Across the surface of the water runs the “scarlet thread of redemption” that ties the Bible together from the first verse of Genesis to the last verse of Revelation.

In addition to the obvious symbolic significance of this particular work of art, there’s the bigger symbolism of stained glass in a Christian context. Beyond its obvious beauty, stained glass windows served a valuable purpose in churches: They taught the stories of the Bible to a largely illiterate population. For many people in medieval times, church windows were their Bibles.

We like the meta symbolism of the medium of stained glass representing the Bible, and the specific symbolism of this piece as it relates to studying the Bible with our program. And besides, it looks really nice on the iPhone.

It’s unlikely we’ll hear any good news until the program is approved. We’ll pass along any bad news we receive just to keep you informed. Until then we have plenty to do to get ready. We appreciate all your kind words and prayers.

Laridian Logo Apparel Available at our Lands’ End Store

Posted on: August 21st, 2009 by Craig Rairdin No Comments

Laridian LogoOne of our PocketBible beta testers spotted a picture of Jeff in a Laridian pullover with me in a Laridian polo and asked if he could purchase Laridian apparel anywhere.

We have a long-standing relationship with Lands’ End going back to our days at Parsons Technology. I have a picture on my wall of the entire Church Software Division staff at Parsons in our purple Parsons polos from 1995, and for a couple of years I gave out Lands’ End gift certificates to them as Christmas gifts.

Lands’ End normally password-protects logos so that they won’t be used without permission. So I went fishing for a way that you can use our logos on your purchases there. Turns out they have a way for us to create our own store. We don’t get a commission, which is dumb, but you get to use our logos.

So here’s a link to Laridian at Lands’ End. There are two versions of the Laridian logo. One is the one you see here. The other has LARIDIAN in large type with a very small version of the flying book logo below it. That version is in black and looks good on most colors.

Note that you don’t automatically get the Laridian logo on everything you buy. You have to add it. Once you select your item, there’s an option to choose a logo and a location on the item to put the logo.

Like I said we don’t make a dime from these sales, but the quality is very good and customer service is excellent. We hope you’ll enjoy your Laridian apparel from Lands’ End!

PocketBible for iPhone Video Demos

Posted on: August 10th, 2009 by Craig Rairdin 10 Comments

I put a link to these videos in my last post but some of you may have missed it since I edited an existing blog article.

I’ve posted some videos of PocketBible for the iPhone in action on our YouTube channel. You can view those videos here.

These videos were created while running the program in the iPhone Simulator on the Mac. It makes for a nice video but the program runs faster on a Mac than it does on the actual device.

©2014 Laridian