Thanks for your comments on my last post. They were very informative and confirmed a number of things that I was thinking about the Android platform as a relative n00b. My only disappointment is that nobody commented on my really cool graphic of a silhouetted Android android listening to his iPod and dancing like one of those Apple ads. Oh, well.

One interesting overall observation was that comments tended to come from people who were more than techie, more than early adopters, but were developers themselves. This is consistent with the perception that Android is a more technically complex platform as compared to iPhone. The comments bore this out as well.

I summarized the comments this way. I divided them into comments from a consumer perspective, those from a programmer’s perspective, and comments related to unique features of the platform that we should look at.

Consumer Perspective

• Android Pros
  • Hard buttons (menu, back, search, etc.)
  • Apps are more collaborative
  • Implicit multitasking
  • Widgets
  • More customizable
  • Free integration with G-apps
• iPhone Pros
  • Apps are more polished
  • Apps are more similar - easier to learn
  • Overall easier to use
  • Apps are more trusted (Apple-vetted store)

Programmer Perspective

• Java!
• Simple background processes
• Other minor programming tasks may be easier to handle
• No App Store police
• “Intents” to communicate with other apps
• Ability to install outside App Store

Unique Features (not already mentioned)

• Speech-to-text; text-to-speech
• Publish a “Look up verse” intent
• “Verse of the day” widget

I, too, like the hard buttons. Right away I’m thinking we don’t have a toolbar like the iPhone app but instead rely on the menu button to cause a standard menu to be displayed. From there we can use a “more” button to expand the range of options that can be chosen from the menu. This will simplify the ui and provide more space for text without having to change any settings like you have to do on the iPhone.

I definitely agree with all the iPhone “pros” that were pointed out. There are small things about the iPhone that just make it feel better. For example, the little bounce you get at the end of a list to indicate that you’re at the end. You don’t notice how nice that is until you don’t have it on Android. And overall the operation of the device feels smooth and effortless.

I’m not a flaming Java fan yet. I’ve been programming in C and C++ for about 28 years. While Java is a descendant of C++, I don’t agree that the differences are necessarily better. They’re just different. For example, while I agree that there’s no real reason to separate the interface description of a class (i.e. the C++ .h file) from its implementation (the .cpp file), putting them together (in the .java file) necessitates the use of a separate “JavaDoc” tool to pull documentation out of the code. In C++ your .h file serves as the class documentation and typically contains no implementation to get in the way — it’s all about documenting the interfaces to your class. Again, not a big deal, but just different.

I’m also not sold on the necessity of eliminating the unsigned integer types. Seriously? I use unsigned ints all the time to indicate specifically that I don’t expect this value to be negative and to subsequently double the range of values that can be stored.

On the other hand I love the fact that the bit-width of each of the integer types is fixed by the language. We share code between several platforms and compilers and have to define types like “Int32″, “Int16″, “Int8″ and their “UInt32″, “UInt16″ and “UInt8″ counterparts for each platform so the shared code will be guaranteed to work right.

And it’s probably the bit-twiddler in me, but I’m not fond of garbage collection. I realize some of you n00bs don’t know how to manage the memory you allocate, but we experts don’t have a problem deleting everything we allocate with “new” and not leaving pointers dangling or memory orphaned. The idea of having a process fire up at some undetermined time and take some undetermined number of processor cycles to do memory management is disturbing. Sure, it’s convenient and this is the last time I’ll complain about it, but I’m just saying it’s disturbing.

Thanks again for the input. I’ve closed comments on the other post since I used this one to summarize them, but feel free to comment here.

OK we’ve been playing with the Android for a while now and have begun to get a feel for it. After spending the last couple of years developing for the iPhone, we have begun to develop some opinions on how the two platforms compare. But today I’m interested in yours, because it will help me shape the way I think about certain aspects of implementation of this app. If you have significant experience with both Android and iPhone, I’d like to hear what you think of the two platforms.

If you gave up iPhone for Android, I’m not interested in how you were treated by AT&T or how bad their coverage or 3G performance is in your area or how much their data plan costs — that doesn’t help me get my head where it needs to be. Instead, I’m looking for your reaction to the platforms themselves. What makes one or the other better? Which is more pleasant to use and why? What makes the applications for one better than those of the other?

Again, the fact that Android is experiencing rapid market share growth is irrelevant to this question. The fact that iPhone is only available on one carrier doesn’t matter. The fact that you can get Android phones from a variety of manufacturers won’t help me. I’m looking for your reaction to the look and feel of the operating system and the best apps on each phone.

In order to be relevant, you should have more than just passing familiarity with both platforms. I’m not looking for input from those who are die-hard fans of one platform but who have only passing knowledge of the other. I’m hoping to find a few people who have spent a couple months or more using each of these platforms as their primary phone and who have purchased a few apps for each.

Along the way you’ll pick up our opinion I’m sure. But right now I’m looking for yours. Thanks for your help.

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.

We’ve received a lot of comments here in the blog and via email about Android. You obviously are interested in a version of PocketBible for Android and that is exciting. We’re interested in a version of PocketBible for Android, too.

The way we see it there are six important mobile platforms right now:

1. iPhone/iPod Touch/iPad
2. Android
3. Blackberry
4. webOS
5. Windows Phone 7
6. Symbian

We have a product for iPhone. It has rather quickly become our flagship product, given the demise of both the Palm and Windows Mobile operating systems. (Both Palm and Microsoft have abandoned their legacy operating systems in favor of webOS and Windows Phone 7, respectively. Old apps won’t run on these new platforms.)

We have a partnership with BEIKS on the Blackberry platform. It’s a great platform but it tends to be more of an enterprise device rather than a consumer device and as a result the demand for third-party software, especially in our niche, is less than what you might expect based on the size of its market.

We have a partnership with Bits of God Software on webOS. We decided not to do our own development for this platform because its market share is relatively small and it does not support traditional programming languages like C++ and Java that would allow us to leverage our existing code.

Windows Phone 7 is a big TBD. Obviously there are zero devices right now and it has zero market share. We include it in the list only because it’s Microsoft, so we anticipate it will be a player. In the meantime we continue to support and release new content for PocketBible for the old/current Windows Mobile operating system

Symbian has problems we’ve addressed before here in the blog. It’s very difficult to successfully market a Symbian product. We’ve attended more than one Nokia/Symbian developer’s conference. We know what’s involved. The problem is not developing, it’s selling. We don’t have any plan to do a Symbian product.

That leaves Android. I can tell you now that we intend to develop a version of PocketBible for Android. But we think there’s more you need to know to understand where we’re coming from.

Sometimes I think people get the impression that we’re bigger than we are. On the one hand, that’s good, because it implies that we’re providing customer service at a level you expect from a bigger company, but on the other hand it can lead to unfounded expectations.

When it comes to product development, there’s just me and Jeff Wheeler here. We have some talented part-time employees who, while they’re skilled at what they do, only add up to the equivalent of a little over one more person. We use some outside contractors for content development (Bibles and reference books). That’s it. Needless to say, that limits what we can do.

Jeff and I used to work at Parsons Technology. I wrote the original version of QuickVerse and brought it to Parsons in 1988. Jeff and I had previously worked together and I hired him in to work at Parsons 1989. He eventually took over QuickVerse development and was the lead programmer for QuickVerse for Windows.

From about 1994 until 1998 when Jeff and I left, he had 10-12 programmers working for him. Most of those were working on QuickVerse. There was a similarly sized group of editors who created new content (Bibles and reference books) for QuickVerse. I had a small marketing group (two people) and a sales group (three or four people). All told there were about 30-35 people just in the Church Software Division. In addition to those we had access to telemarketing, direct sales, support, production and shipping, human resources, accounting, and other departments which we shared with the rest of the company. At our peak in the late 90’s Parsons had about 1200 total employees and the Church Software Division was about 10%-15% of the company’s annual sales. So you could argue that we supported about 120-180 employees.

You can do a lot with 180 people. If something new comes along, you can put a small team on it and get it done. You can’t do the same with three people.

In some respects this doesn’t bother us. We left Parsons Technology in order to be small. (See this article from Christian Computing Magazine which appeared on an old version of our Web site in 2001.) We’ve been big. We know what that’s like. We choose to be small. We enjoy what we do and wouldn’t have it any other way. But realistically, it affects what we can get done in a given period of time. We understand that.

We actually “started working” on an Android version of PocketBible a while back. But then Apple announced the iPad. We felt it was important to make sure that our existing PocketBible app would work well on the iPad. At first we were assured that would not be a problem (all well-behaved iPhone apps work on the iPad) but when we researched it further we realized we’d need to make some changes to optimize our performance on the iPad. We both dropped what we were doing and started work toward getting an iPad-aware version of PocketBible out the door.

This has proven to be challenging. We realized in order to take advantage of the cool new features of the iPad we’d have to re-architect the PocketBible user interface to better take advantage of the larger screen. At the same time, when we’re done the same code needs to run on the iPhone. So all of this has to be done carefully. (You’re going to love the iPad app by the way.)

So when I say “we intend to develop PocketBible for Android” you need to understand that doesn’t mean it will be done next month. It might not even be started by next month.

Furthermore, when we went from developing for Palm OS and Windows Mobile to developing for iPhone, we were able to bring along a lot of code from our previous projects because the iPhone “understands” the language in which it is written. We cannot run any of our existing code on Android. So we’ll be starting from scratch.

To put this in perspective, it took us about a year to release the first version of PocketBible for iPhone when we started with our existing code. It’s been almost two years now and we’re almost (not quite) done implementing all the features of our Windows Mobile app for the iPhone.

For Android we’re starting from nothing. I can’t say at this point how long it will take to develop PocketBible for Android. It’s probably not the case that it will take the year it took for the iPhone program plus the time to write the code we borrowed from our older programs. But at this point I can’t say.

While we are saying we intend to develop for Android, you also have to understand that we have lots of other requests and ideas on our to-do lists. Our Memorize! users would really like to see that app on the iPhone. Our PrayerPartner users are going to want us to port it to the iPad. So even once we start on Android, it might not be the only thing we’re doing.

This all helps explain why we don’t like to talk about what we may or may not do in the future. If we had told you on the day we started working on Android that we were working on Android, we’d have to tell you shortly after that that we had abandoned our work on Android to work on iPad. And now we’re telling you we “intend” to do an Android version but the schedule is unknowable. This won’t be a problem for those of you who are familiar with software development and understand what all is involved, but for those of you who are unfamiliar with software development you’ll probably get the wrong idea about the schedule — either thinking it will take us longer than it will or that it will be done sooner than is physically possible.

For a small company like ours these are exciting times. Back when Palm OS and Windows Mobile ruled the mobile space, we were riding pretty high. Things have changed quickly, and we’re working on responding to the changes. Thanks for sticking with us. We hope you’ll continue to do so.

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.

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.

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.

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.

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.

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.

This 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.

One 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!

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.

From time to time we’re approached by (or we approach) a publisher with a Bible or reference title they’d like to distribute through Laridian at no charge. That’s fine with us, of course, especially if they do all the work to create the title with BookBuilder. But some of these folks have second thoughts when they find out that we charge for our reader software. They feel uncomfortable having their work supporting a for-profit company. (Of course if they knew how little profit was in it, perhaps they’d change their minds.)

I used to use a biblical argument to support the idea that the “laborer is worthy of his wages”. Paul asks “Who serves as a soldier at his own expense?” (1 Cor 9) However, I found that people couldn’t follow this argument. It wasn’t that they thought it didn’t apply in our situation, but rather they just didn’t understand what the passage was even talking about.

So now I take a different tact: It’s OK for people to go to Best Buy and pay $1000 for a computer or $300 for a mobile phone on which to run Bible software. And it’s OK that $50-$100 of that purchase goes to Microsoft or Apple or some other company to pay for the operating system on that computer or phone. When they get the computer home, it’s OK to pay Qwest for high-speed internet access for the computer on which you’re going to do Bible study. Computers require electricity, so it’s OK to pay the local utility company for power to keep the computer running while you do your Bible study. Assuming we’re talking about a home user, and realizing that most people have a mortgage, it’s OK to pay interest to J.P. Morgan Chase or some other big bank for the privilege of having a roof over your computer.

Everyone agrees there’s nothing unbiblical about paying for your computer, operating system, internet access, electricity, and mortgage interest. However, next you want to install Bible software. But God forbid that we should pay the fellow believers who dedicate their lives to creating software to help people study the Bible! Sure, we’ll pay Best Buy, Microsoft, Apple, Qwest, the power company, and the bank — we all know how selflessly dedicated these companies are to advancing the goals of the Kingdom of God — but we’re certainly not going to pay fellow believers to create our Bible study software! That would violate our deeply held Christian principles!

I know that 99% of you reading this blog agree with my argument. It’s great that there are brothers and sisters who donate their time to advancing the Kingdom. But there are some of us who have no other means of support other than what we do to help others understand and apply the scriptures. If we “donate” our time, our kids go hungry. We all think this is obvious, but not everyone does. I thought you might find it interesting that there really are Christians out there who have no trouble supporting secular programmers but balk at supporting their brothers and sisters.

And if you’re in the “Bible software should be free” camp I hope you’ll take a minute to think about who you willingly give your money to (your grocer, mortgage holder, utility company, doctor, plumber, paper boy, internet service provider, mechanic, movie theater, dentist, garbage man, and others) and who you think should go without (your brothers and sisters in Christ) so that you can have cool stuff.

It’s been a long six weeks since we released Beta 1 of our native version of PocketBible for iPhone. At the time I said we were expecting the beta period to be short. Needless to say I was wrong.

A Wrench in the Works

Two major things happened to really slow us down. First, we have been really struggling to get adequate performance out of our code to allow you to be able to smoothly scroll through the Bible like you would a Web page in Safari on the iPhone. Safari has the advantage of being able to render the entire page. Once that is done, scrolling around on it — even zooming in and out — is pretty easy with the features of the iPhone OS. In our case, however, we can’t render the entire Bible while you wait. We have to load it into memory in pieces. Unfortunately, computers can only do one thing at once and while it was busy loading the next chunk of text it needed to display, the scrolling would get clunky. It wouldn’t keep up with your finger motions.

We actually got to the point where it was working pretty well. We were loading text in a separate thread and drawing during otherwise idle times (say, while the graphics processor was busy animating the motion of the text). But then we installed the OS 3 SDK and things fell apart.

We couldn’t afford to take the time to figure out how and why the new version was causing us problems. Suffice to say that the particular functionality we were taking advantage of was rewritten for version 3, and in so doing the handling of touch events changed in ways that may not be significant to some applications but were significant to us.

As a simple example, when you’re tracking a touch event, the system can send you a “cancel” message. This means the phone is ringing or some other event has happened and your program needs to stop what it’s doing and let something more important take over. Well, with version 3 we’d be happily tracking a touch event and suddenly we’d get a “cancel” message. It seems the system was watching the touch events and had decided that the touches weren’t doing anything it cared about, so it told us to cancel our handling of those events. We could’ve ignored the “cancel” message (knowing it was just the OS trying to take over touch handling) but since the “cancel” message also means “really — the phone is ringing — you need to stop right now” we couldn’t afford to make that assumption.

Anyway, the end result was we threw out about six months worth of work and in about a day I coded a replacement that doesn’t depend on a lot of fancy background threads, idle-time drawing, or system touch event handling. The new user interface is simple, practical, and best of all — it’s done.

As if That Wasn’t Enough…

So as we’re recovering from that crisis, the 3GS is released. Now, when you’re developing for the iPhone there are some strict procedures you have to follow to install your program on your phone. Apple wants to make sure all program distribution happens through the App Store, so they limit how many devices you can install your app on outside the App Store. Every time we distribute a beta version (or even one of our own builds we do internally and install on our own phones) we have to identify exactly which phones it will run on. Apple lets us install on no more than 100 devices outside the App Store.

To manage this, developers maintain a list of “unique device ID’s” (UDIDs) in their account on the Apple Web site. Each phone as a UDID that uniquely identifies it. We ask all of our beta testers for their UDIDs and enter those at the Apple site. When we distribute a new build we request a certificate from Apple that contains all the UDIDs we want the program to run on.

So as I was saying, the 3GS was released. Jeff bought one for us to test with. A bunch of our beta testers bought them. So anticipating the release of Beta 2, I started collecting all these new UDIDs so I could update our account on the Apple site and create the new distribution certificate with everyone’s new UDID in it. I got about half way through entering them and the site told me I couldn’t enter any more. It said I had already used my 100 devices.

I only had 82 devices in my list. Turns out when you change someone’s UDID it counts as a new device. I had added 85 devices, deleted 3, and made 15 changes. When you delete a device you don’t get its “slot” back, so from Apple’s perspective the total was 100.

After several email, support forum, and telephone conversations with Apple and other developers, we concluded that we were out of luck. We had to wait until our annual program renewed on July 12. At that time, Apple said our device count would reset. We could delete all our devices and start over. But once we started adding devices, we were stuck with those for a year.

One thing that meant is that we couldn’t have 82 beta testers. We needed to cut the list dramatically. I wanted to get down around 40 testers. That would allow us to add some people over the next year and have room for device upgrades. We should be able to struggle through until Apple figures out that its developers aren’t trying to rip it off; we’re just trying to test our software.

So last week we sent out an email “firing” about half our testers. It wasn’t pleasant, but we had to do it. I think we have a pretty good group left. I can tell they’re good because I disagree with them most of the time. It’s good to be challenged to look at things a new way, and these folks are definitely keeping us honest.

Beta 2 Features

There are some notable features in Beta 2 that the testers will be looking at over the next week or two. These include:

• Easily navigate to the next/previous page, chapter, or verse using simple taps and gestures.
• Rotate between open books and Bibles with a tap or a swipe.
• Hide all controls including the system status bar for full-screen reading, while having instant access to all the controls with a tap.
• Search for words, phrases, and combinations of words using Boolean logic. Limit searches to any passage, book of the Bible, or range of books. Limit searches to only verses you’ve highlighted in a particular color or bookmarked in a particular category.
• Add books from your Laridian account. Purchase books at our Web site and download them directly into PocketBible. Remove books as needed to free up memory (just download and install them any time you need them again).
• Select from any installed font and font sizes from 8 to 72 points.
• Lots of customization options, and many more features….

What’s Next?

There will be at least one more beta version before we submit PocketBible to the App Store. We’ll post an article like this one when Beta 3 is released, and another article when we send PocketBible to the App Store.

Once submitted, it will take a while for Apple to approve it. They might send it back and ask us to make changes. There’s no way of knowing how long that process will take. Sometimes it takes just a few days or a couple weeks. Other times it takes six months by the time you make all the changes they want and submit version after version for review. We don’t anticipate it will take that long but we have no way of knowing.

Any Bibles or books you buy today for any platform will be accessible from PocketBible for iPhone.

Actually, it should be “And the winners are….” We had so many great responses that we decided to choose three winners from each site. If you are one of the winners please let us know if you would like your library on CD or USB (both include the ability to download the files from the web site). Also, please make sure that we have your correct mailing address on your account (you’ll need to log into your account on our web site to make sure we have all your information).

The winner in each category will receive the Gold Library, the runner up, the Silver Library and the second runner up the Bronze Library.

Thanks to everyone who submitted an entry letting us know how you use PocketBible. This was a lot of fun to read and a great encouragement to all of us here at Laridian!

So…on to the winners!
(more…)

Laridian VIP Ed Hansberry posts the following on InformationWeek.com: Too Many Mobile OS’s Limiting Development For Companies.

Ed writes, “…there are a bewildering number of platforms and variations within the platforms to develop for. Enterprises will take the easy way out and just stick to one platform and a precious few models. Software developers that are selling their apps will have to have enough penetration for each platform to make development worthwhile. Each platform requires its own development team or at least a dedicated development process that takes time away from other supported platforms…. While phone carriers may support six or more mobile platforms, I am not sure the software industry will.”

We’ve been talking about this problem for some time:

• Palm Pre
• On the Problems of Designing User-Friendly Software for PDAs and Smart Phones
• The Hidden Complexity of the Cell Phone Market
• When is a Smartphone Not a Smartphone?
• …and any number of posts when the iPhone first came out.

Ed makes a good observation: There are at least six major mobile platforms. What if there were six desktop platforms? The software industry would be a significantly different place as companies tried to solve the huge problem of cross-platform development, multiple-platform development, and having enough market on any one platform to justify the incremental cost of maintaining or entering the market on that platform.

One thing you can say about Windows: By dominating the market Microsoft makes it easy for developers on desktop platforms. You can focus your development on one operating system. If you make it there you can consider Mac if you have enough users to justify the expense. Once you’ve covered Windows you have 80%-90% of the market. Whether you go for the 10%-15% represented by the Mac OS is a big decision, but at least it’s the only decision you’ll have to make.

For those of us writing software for mobile platforms there’s not only the issue of supporting a large number of platforms, but there’s the fact that the relative mix of market share on these platforms changes over time. Palm OS used to be our largest platform. Today the Palm OS is dead. Palm and Windows Mobile used to dominate the market; today iPhone and Windows Mobile hold the dominant share of customers. Deciding how we allocate development time and money is an ongoing process that changes a couple times every year.

Meanwhile Apple doesn’t make it easy to develop for the iPhone. I am having a major problem with getting the XCode programming tools to talk to my new 3G iPhone. The information at the Apple developer site is insufficient, and the developer forums they provide have numerous questions identical to mine that have gone unanswered for months. When you call “developer support” at Apple you get a guy in Great Britain who admits he has absolutely no idea how to solve the problem because he’s not a programmer and knows nothing about programming. He points me to the documentation, which is what I’ve been following to get me into the predicament I’m in.

It’s actually encouraging to see a major company like Yahoo make the decision to abandon all other platforms but the iPhone. (Actually, they’re supporting other platforms through customizations to their Web-based products.) It makes it easier for us to consider similar options.

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 (iPocketBible.com) 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.

Official Conference Portrait

Looks like I’ll be speaking at the BibleTech 2009 Conference in Seattle on March 27-28.

My session is the very first one on the schedule at 10AM Friday morning, March 27. I’ll be talking about our group SMS texting service for churches and demonstrating some features that are going to roll out right before that conference. Specifically, using the service for microblogging, voting, and receiving replies from your broadcasts. I’ll be demonstrating the service of course, but will also be opening the hood and talking about how it works. (Since this is a technical conference I have to include something for the programmers in the audience.)

Why am I not talking about Bible software at a BibleTech conference? The main reason is that I spoke on that topic last year; specifically about our synchronization feature that syncs notes, highlights, bookmarks and other personal data between our Windows desktop software and the various mobile platforms we support. And our friends from OliveTree will be there giving the same presentation they gave last year on mobile Bible software development. So I wanted to mix it up a bit and present something different.

Regardless of the topic of my presentation, though, I’d love to see you there and we can talk Bible software if you want. Visit www.BibleTechConference.com for details about the conference, and www.ChurchTextingManager.com for information about our group texting service.

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…

(more…)

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!

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.

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!

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 www.kcrg.com. Jeff has posted some pictures at www.accordingtojeff.com. 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.

A comment from one of our PocketBible 4 beta testers got me thinking about the nature of what we do and what users complain about. I’ve expressed this with respect to the iPhone but I haven’t put it into a larger context that might help people understand what software designers are up against when we implement a solution, regardless of the platform. These issues are especially true of the mobile device market but the same ideas apply to the desktop and other general-purpose computing platforms.

If you start from the beginning, you find a user with a problem. It might be: “How do I take my contact database with me?” or “How can I work on my spreadsheets on the train?” or “How can I browse the Web when I’m away from my computer?”. Hardware companies like Sony, Apple, HP, and HTC get together with software companies like Microsoft and whatever Palm is calling itself today and come up with a device and operating system software that address those problems. In the course of doing so, they create a way for third parties (that’s us) to create software for their new device/OS platform.

By the time we consumer software companies (independent software vendors or ISVs) get our hands on these products, we’re no longer solving the original customer problem. Instead, we’re programming for a device, and the device is solving the problem. When we program for a device we have certain limitations imposed by the hardware and software. The screen is only so big. There may or may not be a keyboard. There may or may not be much memory. There may or may not be good internet connectivity. The tools provided by the OS software developer may not be very powerful. There are a host of these limitations, and we have no control over them. It is the sandbox in which we have to play if we’re going to play at all.

We might have solved the customer’s original problem differently. But that’s water under the bridge. We can only operate within the limitations of the platform.

Some of the limitations imposed on us are not necessarily firmly fixed in hardware. They might be user interface standards that are intended to give the user a common UI experience as he or she moves from application to application on the device. So we all put scrollbars on the right even though lefties might like them on the left. Menus, buttons, toolbars, etc. are generally drawn from a common source so they all look the same and are sized and placed the same in all applications.

Obeying the philosophical limitations is just as important as obeying the hardware limitations, even though the former is not as rigidly enforced. Depending on the platform, a device from another manufacturer might expect you to have followed the rules. It may implement new features, which, as long as you’ve followed the rules, fit seamlessly into your existing program with no changes. So it’s to our advantage (and by extension, our customers’ advantage) for us to play within all the rules.

So what does this all mean? It means that when you have an iPhone, you don’t have a clipboard. It’s not the case that iPocketBible doesn’t have a clipboard, it’s that your iPhone doesn’t have a clipboard. As of right now, it means that you depend on Internet access because all your third-party apps are Web-based. It’s not that Laridian screwed up by only providing a Web-based application for your iPhone, it’s that Apple screwed up by not supporting native, third-party apps right out of the box.

It means if you have a Nokia phone you can’t tell if software is going to run on it because it doesn’t tell you anywhere what version of the operating system you’re running. Yes, if you’re an expert user you already know you have an S60 or whatever, but the average person who reads the Bible and bought a Nokia phone “because it’s blue” isn’t going to be able to tell whether a particular piece of software will run on the phone or not.

It means that if you have a Pocket PC, it’s hard to operate programs with your fingers instead of a stylus. The buttons are too small, the keyboard input methods are too dumb, and many of the controls are simply impossible to operate with something as big as a man-sized finger. It doesn’t mean that PocketBible is hard to operate with your fingertip, it means that Microsoft expects you to use a stylus and designed their device that way.

Sure, we could make our buttons really big and give you all kinds of flexibility for defining how the d-pad buttons work with our program, but eventually you’re going to have to type a note on that little software keyboard that pops up at the bottom of the screen, or select an option from a little combo box or menu, or try to tap on just one Strong’s number in a sea of blue underlined links. We can’t do enough to overcome the limitations imposed on us by the underlying software and hardware, for which we have no responsibility.

It’s fairly common for people to complain to the wrong party about these things. Since we’re the last link in the OEM - OS - ISV chain, we get blamed for a lot of the problems of our software running on these devices — problems that actually are the result of limitations dictated to us by those who came before us. So if you have fat fingers or you don’t have WiFi at your church, I’m afraid we can’t help you. Someone else stuck you with a bad solution before we got to you. The best we can do is create software that works well on the platform you’ve chosen. Whether that platform is right for you is a decision you have to make, and one that the OEMs and OS developers are more responsible for than we are.

From time to time we’re asked how a person can contribute to our work here. They like what we do and they want to be a part of it. Frankly, we’re really touched by such requests and appreciate the attitude that is contained in questions like that.

Needless to say, we’re a commercial venture. We’re not a charity, nor a “ministry” except in the broadest sense of the word. We pay our bills by selling the product of our programming and editorial efforts. While we think it might be profitable to put a “Donate to Laridian” button on our Web site, we’re concerned about conveying the idea that we’re something different than we really are. We have competitors who are just as profit-minded as we are, yet organize themselves as non-profit organizations and even charitable organizations in order to be able to tug at people’s spiritual sensitivities and hopefully get paid for doing nothing. We don’t want to even come close to being seen that way.

While we make no secret of being a commercial company (and will defend that position from scripture if you press us), we really are humbled when people like what we do so much that they want to just give us money for being us and doing what we do. That’s pretty cool. So what we usually suggest is that they buy one of our CD-ROM or USB Drive collections and give it away. That way they bless us with their purchase and they bless someone else with an unexpected gift of software to help them better comprehend the Bible. Everybody wins.

Just got back from BibleTech:2008 in Seattle. About 90-100 developers, ministry leaders, academians, content-owners, and end-users met for two-days of in-depth technical sessions on the current state of technical challenges facing Bible software.

I handed out several of our Gold Edition USB Library devices to blog readers who were in attendance. Unfortunately I put the same serial number on all the devices, so they’ll have to contact tech support to get a fresh serial number. Sorry about that.

I did a session late in the day on Saturday on synchronizing user-created data and proposed the possibility that we could exchange notes, highlights and bookmarks (and potentially other user-created data) between various Bible software based on our model. There was some interest, but these things always sound more exciting when you’re right there than when you get back to your desk on Monday morning and there’s a pile of work to do. So it’s hard to say where that will go.

As part of my presentation I demonstrated creating a note and highlighting a verse on my Pocket PC, then sync’ing that to the desktop where it is displayed in PocketBible for Windows. I then edited the note and changed the highlight color and sync’ed to my iPhone over the internet. When I selected the verse number in iPocketBible I saw my note, which I then edited again. While I was there I changed the highlight color yet again, then sync’ed up to the desktop. There was my note, with all the edits from the Pocket PC, desktop PC, and iPhone; along with the verse highlighted in the color I’d chosen on the iPhone.

We made some good business contacts there and perhaps you’ll see something come of those in the future. However, I also took away a number of small points that are worth mentioning here.

• One publisher admitted that digital rights management (DRM) was a losing battle. He cited several cases where DRM schemes were defeated within days of a new product being introduced. He lamented the opportunities lost by publishers who are waiting for a perfect solution to security of their data. This is something we’ve been preaching for twenty years.
• The open-source/freeware community was chastised by one Greek professor in attendance for distributing and promoting “classic” commentaries from the 19th century. While her calls for publication of these materials to be suppressed were perhaps over-the-top, she makes a good point: We have so many more manuscripts and archaeological evidence today than we had 150 years ago that it’s a shame that we promote these dated materials just because there’s no royalties on them (they’re old enough that they’re in the public domain). Since the open-source/freeware guys aren’t in business to sell things (and thus collect and pay royalties) they tend not to have the more contemporary resources available to them that are the bulk of what we do here at Laridian and at the other commercial Bible software houses.
• Crossway gave quite a presentation on the marketing research they have done with respect to the English Standard Version (ESV). It was pretty impressive to see how much time they spend thinking about who their readers are and where, when, why, and how they’ll be reading the ESV. This allows them to better tune their product development and marketing to meet readers where they are instead of where Crossway wants them to be.
• The Crossway presentation also included a couple quotes from Business Week. One, from 1998, stated that “practical e-book devices have finally arrived”. None of those devices are available today. A second recent quote said the new Amazon Kindle is the “iPod of e-book readers”. We’ll see.
• The only commercial Bible software companies represented there were us, Logos, OliveTree, and e-Sword. I was disappointed not to see anyone from the major Bible software companies like Findex (QuickVerse) and Biblesoft (PC Study Bible). I realize these companies are not generally considered “leading edge” when it comes to technology, but it would’ve been nice to see them all again.

Ironically, a Logos employee won the prize for answering my trivia question correctly at the beginning of my presentation. Twenty years ago this month I started work on the product that would become QuickVerse. The question: What was the name of that program when I first started selling it in September, 1988?

Please note the date on this post. Read our more recent posts on the iPhone for more up-to-date information.

(more…)

Wow it’s been a month since my last article. Time flies. (more…)

I’ve found myself having to address this question several times in the past few months, mostly in the comments to these blog articles. For the convenience of all you Mac users, I’m going to put this in its own article. (more…)