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

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:

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 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 Update

Posted on: March 18th, 2009 by Craig Rairdin

If you’ve been a Laridian customer for a while you know that our policy has always been to avoid talking about products that we are working on until they’re actually available. Starting with the Web-based version of our iPhone product ( we made an exception to that rule and openly talked about our development activities for iPhone. We continued that with the native PocketBible for iPhone. We did this as an experiment to see how it would work out.

It’s been an interesting experience. We’ve received many positive comments and suggestions on the blog and by email. Several emails, though, attacked both our products and our personal character, and criticized our programming and management skills. Needless to say, these both consume our time as we try to address the criticisms and drain us of enthusiasm for the project. Even the positive comments often result in lengthy email exchanges.

We’re at the point, especially with the upcoming version 3 of the iPhone OS, that we need to return to the old way of doing things and allow ourselves to work undistracted by both incoming emails and the pressure to release information to the PocketBibleiPhone email list. I’ve removed a few articles from our blog and disabled comments on others. We will return to a “no comment” policy with respect to products which may or may not be under development, and reserve the right to read but not reply to your emails.

We do appreciate your interest but hope you’ll understand our need to focus.

Laridian’s Jim VanDuzer: First Responder

Posted on: February 11th, 2009 by Craig Rairdin 38 Comments

So we’re at Jim’s place in Pennsylvania this week, having our annual board of directors meeting and doing a little skiing at Blue Mountain. Jim’s on ski patrol there, which requires that he receive training as an Emergency Medical Service: First Responder. We’re on our way to the local Panera Bread to drink some coffee, tap their WiFi, and have our second session of meetings.

As we’re approaching the mall we come across a very fresh accident. The driver of a mini SUV has apparently run a red light and been clipped by a semi, causing the SUV to spin and the driver’s head to break out the driver’s-side window. Jim pulls over, grabs his med kit and heads to the scene to offer assistance. There he finds that the driver is covered with broken glass and is bleeding from a cut on her ear. Pictures after the break…


How Our Blog Came to the Rescue

Posted on: February 10th, 2009 by Craig Rairdin 1 Comment

If you’ve ever needed to contact us at Laridian for assistance, you’ve probably been fortunate to have been helped by Patty. If you go way back, you may have even talked with Patty on the phone. Patty has been our front-line provider of customer support for several years, is knowledgeable about our products, and genuinely interested in helping you resolve any problem that you might be having. (Well, maybe not any problem… but for sure any problem with a Laridian product :) ).

However, as competent as Patty might be, she’s still just one person. So, we recently began a search to find her some help.

As we were seeking a new person to help on a part-time basis with technical support and customer service, we knew we were looking for some one with a special set of talents:

  • Knowledge about our products,
  • Knowledge about our subject field (the Bible, mobile computing, etc.),
  • Excellent written communication skills,
  • Ability to follow instructions,
  • Desire to help our customers,
  • And, finally, patience, because (as difficult as it might be to believe) sometimes the frustrations of an unexpected problem can bring additional challenges to a support situation.

Knowing that we were looking for some one special, we chose to advertise for our part-time position in three venues:

  1. craigslist
  2. our local newspaper
  3. here at this blog

Additionally, in order to test written communication skills and the ability to follow instructions, the application process included some very specific instructions.

For some (as yet unknown) reason, the ad never appeared on craigslist. So, we didn’t receive any applicants from that source.

The ad in our local newspaper did generate some responses. However, none of these applicants followed the specific instructions that we provided. As a result, these applicants didn’t receive any of our attention. After all, if one cannot follow the application details, how will one perform at a detail-oriented job? (Hint: if you ever apply for a position with Laridian, or even as a beta tester, make sure you follow all of the provided instructions. That’s always our first filter, and it is surprisingly effective.)

Fortunately, the article here in our blog did generate interest from several interested and qualified persons. Many, but not all, followed the instructions, and thus made it past the first step. The remaining applicants were all strong candidates. Plus, most were also customers, and therefore already had knowledge of our products.

The second step was a brief questionnaire, sent to each remaining applicant. The questionnaire was designed to further explore written communication skills as well as to obtain more information than what had been originally asked for.

The third step was to further filter our qualified applicants. Craig and I independently reviewed the resumes and responses, then independently ranked the applicants based upon our own individual criteria. When we compared our results, we found that while our rankings weren’t exactly the same, we did seem to be in general agreement.

For the fourth step, I then conducted telephone interviews with the top few applicants. During a 60 to 90 minute conversation, we discussed the company, the position, and the candidate.

The result? If you need to contact us for assistance, you might still be fortunate to be assisted by Patty. But if not, you’ll probably be fortunate to be assisted by Brett. Brett has been an ardent Laridian customer for several years and is excited about the future of mobile computing and its impact on Bible study.

Plus, we learned that “advertising” here in our blog is an effective way to seek candidates for job openings. You all are a remarkably qualified and diverse group!

ESV Study Bible Clarification

Posted on: February 2nd, 2009 by Craig Rairdin 6 Comments

There has been some confusion about the status of the ESV Study Bible for PocketBible/MyBible. We frequently get asked when it will be done. The answer is we don’t know, because we’re not doing the development work for it.

As you know, Laridian is the only mobile Bible software company that offers a complete publishing solution that allows the owners of Bibles and Bible reference materials to self-publish in our format, and we’re one of very few non-mobile Bible software companies to do so. When we were approached by Crossway to publish the ESV Study Bible notes, one of the options we presented to them was self-publishing using BookBuilder. This was the option they chose.

In order to save the time and effort of learning our system, Crossway is actually using a third-party to create this product. The company doing the work is one that we also use. They know our system inside and out and have tools that make it easier for them to publish books for us than it would be for Crossway to do it on their own.

The result of all this is that we aren’t in control of the schedule for this product. We hear it’s coming soon. Unfortunately not everyone at Crossway (and maybe not even everyone at Laridian) understands how this project is being done, so there’s been some confusion when customers contact them (or us) and ask about the status. So this is the official word: This is a Crossway project, not a Laridian project. We hear it will be done “soon” but don’t know the exact schedule. When it is done, we’ll post a message here on the blog and send out an email to all our customers to let them know. You’ll be able to purchase it right here at the Laridian Web site.

Happy Anniversary to Us

Posted on: October 21st, 2008 by Craig Rairdin 17 Comments

It was ten years ago today that Laridian was incorporated. Time flies!

I started working on Bible software for Windows CE in April of 1998 while I was still at Parsons Technology. Parsons had decided it wasn’t interested in software for PDAs. That didn’t really matter since the sale of Parsons to Broderbund in 1997 had accidentally left me under no non-compete nor any intellectual property agreement of any kind. So I was free to launch a Bible software company even though it looked a little questionable.

(Interestingly, this would get tested in 2002 when the stockholders of Mattel sued Mattel and its executives over the lack of due diligence in the purchase of The Learning Company, which at the time was the owner of Parsons Technology. I was a witness for the plaintiffs (the shareholders) and was deposed for a day and a half. A team of lawyers went through my notebooks and phone logs covering the last couple years I was at Parsons. When they discovered I had started Laridian before leaving Parsons they really dug in — looking for a way to discredit my testimony. They were unable to find any evidence of any wrong-doing on my part, and eventually the shareholders won the suit and received several million dollars from Mattel.)

We incorporated on October 21, 1998 and our first sale was on November 28, 1998. I resigned from Parsons on December 11. Jeff Wheeler and Jim VanDuzer followed me in January.

The product now known as PocketBible for Windows Mobile was our first product. At the time it was called PalmBible and Windows Mobile was called Windows CE. Sometime in 1999 or 2000 some idiot at the US Patent and Trademark Office granted Palm, Inc. a trademark on the word “Palm” pretty much in any imaginable context. Palm started flexing its newly found power and threatened everyone using the word “Palm” in the title of their software. We received a letter saying we needed to change the name of our product. Microsoft had just come out with a new type of device it was calling “Pocket PC” and promised not to trademark the word “Pocket”, so PalmBible became PocketBible.

We didn’t know anything about electronic commerce at the time. Parsons sold a lot of products through its Web site but none of us were involved in the technical implementation of online sales so we didn’t know where to start. Fortunately Bob Parsons had started a Web hosting company in Phoenix by then so we called him up and had his company implement our Web store. As is normal with such things they did about 90% of it and called it good. We had to finish up a number of things, but that ended up being a good thing because it forced me to learn how the site worked and how to write VBScript and SQL.

Laridian was then and has remained a virtual company. We’ve never had office space; we all work from home. For a long time we sold our products only through the Web site, and only by download. So there wasn’t any inventory. We even provided our own computers for the first couple years (and worked without a salary), so the company didn’t even have any physical assets.

Over time that has changed a little bit. For a long time we distributed our physical products through distribution partners but we got burned three times by three different companies. So now that’s all handled in-house. Our “warehouse” is a storage garage, and we make trips there as necessary to replenish the stock of products one of us keeps at home for direct orders, or to put together larger orders for stores. (We sell our iPocketBible audio Bibles through Christian bookstores. Right now those are our only physical products.)

We’ve all had to make adjustments in our homes to work full-time from home. I had a small 9′ x 12′ office off our family room when the company first started, but I quickly outgrew it and needed more storage and work space. We ended up building an addition on the house so I could have a bigger space (and better sound-proofing). Now I have about a 14′ x 20′ office with a small storage room attached. This works great as I’m completely isolated from the rest of the house. This is important because we taught our five kids at home so there was always a lot of activity during the day. The kids were good about letting me work, but they still made a lot of noise. (My oldest three are married and out of the house now; the youngest two go to the Christian school run by our church.)

I worked ten years and two months for Parsons Technology, and that was my longest time at one job. In March I’ll have been working full-time for Laridian for that long. I think we’ve accomplished a lot and hope to keep doing it for another ten or more. We all appreciate those of you who have made us your PDA Bible software source over the years. You’re a big part of what makes it fun to do this job. Thanks for ten great years!

The Great Flood of 2008

Posted on: June 13th, 2008 by Craig Rairdin 5 Comments

A few of you have written to ask how we’re doing given all the flooding going on here in Cedar Rapids. We appreciate your concern. We’re all doing well.

A couple of interesting points. First is the media. Someone reported hearing one of the cable news channels refer to Cedar Rapids as “the city they said would never flood”. We don’t know who said that; the Cedar River overflows its banks fairly regularly in some areas of town. Normal level of the river is around 4′ at the point they measure it. Water begins affecting low-lying roads in some areas at 9.5′. The long-term prediction last month said there was as much as a 50-50 chance that we’d see water as high as 9.6′ this week based on just normal forecasted precipitation.

On the other hand, this is quite an event. Our last big flood was in 1993. 12′ is considered flood stage, with 16′ considered a major flood. In 1993 we hit 19.27′, which was just short of “the big one” which was 20′ in 1851. The river as I type is at 31.12′. That’s a lot of water.

Good Morning America was here this morning and reported that the entire city was under water. This came from a reporter (Sam Champion) who got in a fight with police because he wanted to stand waste-deep in the water to do his report. So clearly he could see dry land from where he was at, and that’s where the police wanted him to stand.

All this to say that you shouldn’t take the media seriously on anything they report.

My second point is political. After Katrina (clearly a more massive disaster than what we face here) there was a lot of complaining about the response of government. It was clear that the local and state government were completely unprepared for the scale of disaster they faced. Here in Cedar Rapids it is very clear that the local government, medical facilities, and utility companies are calmly executing their disaster plans. While a few idiots have had to be “rescued” from their houses after ignoring the mandatory evacuation orders, there is adequate shelter (including pets), transportation, and food to meet the need. I think it emphasizes the importance of handling local problems locally and not depending on the federal government to come in with their sledgehammer to fix problems better addressed with thumb tacks.

If you’re interested in seeing what’s happening, check out Jeff has posted some pictures at I have posted some aerial views at my personal Web site.

Thanks again for your concern and prayers. While we’ve had extensive loss of property there has been no loss of life of which I’m aware, not even any major injuries.

©2015 Laridian