Subscribe to Updates

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

Archive for the ‘iPhone’ Category

iPad Update

Posted on: March 27th, 2010 by Craig Rairdin 26 Comments

With the WiFi iPads shipping for delivery in less than a week, I thought we should update you on our status.

Today (March 27) is the last day to submit apps to the App Store and be guaranteed they’ll be available on the iPad App Store on its official release date (April 3). For a while that was our goal, but as time went on we realized it would be in everyone’s best interest if we had a chance to see what PocketBible looked like on the actual hardware. The emulator we run on our Macs is good, but it’s not the real hardware. We’re concerned about performance and simple things like the usability of the user interface, given that we can’t really tell how big our buttons are or what it’s going to “feel” like on a real device until we have one in our hands.

So, we won’t release a product to the App Store until we have a chance to see it running on real hardware. So that means sometime after April 3.

The great thing about the iPad is that it runs our iPhone code pretty much as-is. The bad thing is that it runs our iPhone code as-is. The experience of running an iPhone app on the iPad will be less than optimum, but it at least will give the iPad a couple hundred thousand apps on day one. Ideally, every iPhone developer will be customizing their apps for the iPad, and that’s what we’ve been doing.

While the iPad is a mobile device, it has the screen real estate of a desktop or laptop device (1024 x 768). That means while we’re using our iPhone code as a base, we have to think like we’re developing for the desktop. Not a desktop computer with a mouse and a real keyboard, though, but a desktop computer you operate with your fingers and type on a pop-up keyboard. So the interface is an interesting intersection of desktop and mobile paradigms.

So what will be new or different on the iPad? First, You’ll have plenty of space on the screen for some controls to be present all the time, just like on your desktop where menus and toolbars are generally always there. This makes it easier and more intuitive to get around.

Second, the bigger screen means there’s room to split the screen and show you more than one book at a time if you want.

Third, we’ve taken advantage of this opportunity to add a frequently requested feature: The ability to search your entire library at one time. The larger screen means there’s room to give you both a search results browser and a library browser at the same time. We think this is going to be a great addition to the program.

Finally, you can expect changes to how you open books and navigate within books. It should take fewer touches to find your way around your library.

We’ll post some more details as we get closer to releasing the product. With the actual release of the iPad itself coming up, we just wanted to give you some advance notice of what’s coming. We think you’re going to like it.

It’s iPad Ordering Day!

Posted on: March 12th, 2010 by Craig Rairdin 19 Comments

Apple started taking orders this morning (March 12) at 7:30AM CST for the new iPad. The WiFi version ships in time to arrive at your home on April 3, while the WiFi+3G version ships in late April.

You can place your order at store.apple.com. The 16GB WiFi version is $499. 32GB is $599 and 64GB is $699. Add $130 to each of those prices if you want 3G. You’ll have to pay for a 3G data plan separately, of course.

As we’ve said before, we don’t talk about what may or may not be under development. But you can expect some new iPad-specific features in PocketBible that we think will make it an even more compelling application than it is on the iPhone and rival what we offer in PocketBible for Windows. We’ll get more details out as we get closer to a ship date.

And don’t worry about migrating your notes, highlights, bookmarks, and reading progress to the iPad. Before it arrives, we’ll have an update that will allow you to synchronize or backup your data to our server, then synchronize or restore it to PocketBible on your new iPad. Of course this feature will also let you move any user-created data you had on your old Palm or Windows Mobile phone to your iPhone assuming you have PocketBible for Windows running on your desktop or laptop. You’ll sync your Palm or WinMob phone to PocketBIble for Windows, then sync PocketBible for Windows with our server. Then sync your iPhone with the server and you’re done.

So if you want to be the first on your block to own an iPad, get your order placed as soon as you can. By the way, you can ignore the temptation to pay for expedited shipping. Your new iPad will be shipped in time to arrive on April 3 and the shipping is free. The 2-3 shipping option applies only to the accessories you order with your iPad, which will ship later.


PocketBible for iPad

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

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

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

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

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

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

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

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

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

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

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

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

RomansRoad eTract Available for iPhone

Posted on: January 21st, 2010 by Craig Rairdin 10 Comments

A few weeks ago (around the turn of the year), I answered a technical support query about whether any of our eTracts for the Pocket PC had been published for the iPhone. They haven’t been, so it was an easy question to answer. However, that question planted a seed, which sprouted and leads to today’s announcement: our RomansRoad eTract is now available for the iPhone.

RomansRoad eTract is a Scripture-based discussion guide to help you share your Christian faith. Based upon the familiar “Romans Road” series of verses from the book of Romans, this witnessing tool uses a unique question and answer format to provide a framework to help you share your faith. As each new key verse is presented, probing questions and explanatory answers are also provided to help you both explain the Scripture and answer common questions that arise.

For example, Romans 3:23 states that all have sinned. Upon presenting this key verse, the RomansRoad eTract provides the following questions:

  • What is sin?
  • Who has sinned?
  • Does that include you and me?
  • Not convinced that you are a sinner?

Answers to these questions are provided using everyday language.

This format — presentation of a key verse with concise, clear commentary in a question and answer format — provides a framework allowing you to share your faith while personalizing your discussion. Since it is discussion-based, you are able to listen and respond to the questions you receive, and be sensitive to God’s leading.

An individual page or all pages can be emailed, facilitating both further consideration and follow-up at a later date.

If you find the RomansRoad eTract a helpful resource in sharing your faith, we’d love to hear from you. Leave a comment on this article and/or post a review on the App Store with your experiences.

Find It On the App Store

The RomansRoad eTract is available on the App Store for 99 cents. Click here to go to the iTunes App Store now.

The RomansRoad eTract is fully stand-alone. It does not require PocketBible nor any other Laridian product. So, even if you use some one else’s Bible software on your iPhone (though you should try PocketBible, it’s free!), you can still use the RomansRoad eTract.

Some More of the Backstory

I first wrote and published this eTract for use on the Pocket PC. Since then, the text has been revised and expanded several times. I’d estimate that this is really the fourth or fifth edition of the text. I’ve published previous editions in paper format as well.

Last week, I posted the RomansRoad eTract icon on our facebook “fan page” and invited guesses about the program. Several were close, and a few were exactly right!

If you follow me on Twitter, this is what I have been referring to as my “#newsecretiphoneproject”.

Screen Shots


Sample Screen

 


Preferences

AT&T vs. Verizon 3G Speed

Posted on: January 18th, 2010 by Craig Rairdin 24 Comments

A few months ago Verizon started running some pretty obvious ads for those of us who use both Verizon and AT&T. They compared their 3G coverage map to AT&T’s. AT&T came up wanting.

AT&T fired back, saying that their 3G network covers 97% of cell phone users, and that it’s faster. They further brag that AT&T users can surf the Web while they’re on the phone.

I’m sitting here this morning using a Verizon 3G modem connected to my MacBook, writing code for the iPhone in my pocket. On a whim I went to speedtest.net on both the Mac and iPhone to see what the results would be.

Speedtest.net on the iPhone took me to the App Store to download their free native app. On the Mac, Speedtest.net runs in your Web browser. I downloaded the app to my iPhone and made sure both the Mac and iPhone were connecting to the same server in Kalamazoo, MI.

The results of three tests tests on each device are summarized below:

  Verizon AT&T
  Download Upload Download Upload
Run 1 790 Kbps 60 Kbps 205 Kbps 233 Kbps
Run 2 230 Kbps 60 Kbps 105 Kbps 130 Kbps
Run 3 430 Kbps 110 Kbps 70 Kbps 190 Kbps
Average 483 Kbps 77 Kbps 127 Kbps 184 Kbps
Overall 280 Kbps 156 Kbps

AT&T has an upload advantage, but most mobile Web surfing and email activity depends on download speed, not upload speed. Furthermore, AT&T’s overall speed (average of upload and download) is lower. So even if you did an equal amount of uploading and downloading (which would be very unusual), Verizon is faster.

This seems to undermine AT&T’s argument that their network, while covering very little of the geographic area of the US, is faster. It appears to me based on my one sample location (Coffee Emporium in Hiawatha, IA) that this is not true.

And while I may be able to surf and talk at the same time with my iPhone, if you read the fine print you’ll find out that only applies when you’re in 3G coverage. The one time I’ve needed to do it in the last two years I was not in 3G coverage and therefore couldn’t surf while I was on the phone.

The iPhone is a great device and if you live in certain areas of the country very close to an ocean you have great coverage. And the connection speed, while slower than Verizon, is certainly adequate for mobile Web and email activities. I really like my iPhone and recommend them to everyone. However, AT&T is its weak spot.

PocketBible 1.2.0 Now Available

Posted on: December 29th, 2009 by Craig Rairdin 19 Comments

Features Devotional Reading Progress Tracking

PocketBible 1.2.0 has been approved by Apple and is available in the App Store.

The new version wraps up what we call our “user-created data” functionality. That is, the program now supports the creation of notes, highlights, bookmarks, and the tracking of your progress as you read through devotional (daily reading) books. This is a fairly major milestone for PocketBible. Initially we weren’t even going to ship version 1.0 until these features were implemented. Our early alpha testers convinced us to ship as soon as possible and wrap up the rest of the features in a series of point releases, which is what we ended up doing.

There are other minor improvements to the program as well. In particular, we took advantage of the extra space in landscape mode and added two additional buttons to the toolbar: “Forward” (the “Back” button seemed lonely) and “Bookmarks” (gives you a quick path to your list of bookmarks). And check out the new, very colorful, Go TO Verse screen.


New Features in 1.2.0

  • PocketBible now tracks your progress reading through devotional (daily reading) books like through-the-Bible reading plans.
    • Select a start date for each devotional book
    • Mark today’s reading, current reading, or selected reading as “completed”
    • Title bar turns green for readings you’ve read; red for those you need to read
    • Today button now activates new Devotional menu when selected while a devotional is active. Gives access to devotional features including new reading progress view and settings
    • “Catch Up” function lets you quickly adjust your reading plan to put you back on schedule
    • Open Book screen uses color coding to indicate which devotional books you need to read today to stay on schedule
    • Progress tracking is optional
  • Added frequently requested “Forward” and “Bookmarks” buttons to the tool bar when in landscape mode (where there is room for more buttons than in portrait).
  • Color-coded the book name buttons in the Go To Verse “Bk/Ch/Vs” selection process. Colors correspond to well-known sections of the Bible (Pentateuch, History, Wisdom, etc.) to make it easier to spot a particular book.
  • Added more “short-cut” buttons to the Go To Verse spinner corresponding to the sections of the Bible mentioned above.
  • Minor updates to the Context menu for non-Bibles to remove inactive choices.
  • Improved handling of saving your notes when the phone rings or you get a text (or simply exit the program) to eliminate potential loss of data.

Next up is providing you a way to sync your user-created data to our server and from there to your PC and other mobile devices. As usual there will be other improvements included in each update.

If you have suggestions, send them to me at craigr@laridian.com rather than posting them here in comments.

PrayerPartner for iPhone Updated

Posted on: December 28th, 2009 by Craig Rairdin No Comments

PrayerPartner for the iPhone has been updated to version 1.0.1, and is now available on the Apple App Store. Search for “PrayerPartner” in the App Store, or try this link.

This is a free update for all PrayerPartner owners. If you’ve previously purchased PrayerPartner, then either iTunes or your iPhone (or iPod touch) will notify you that the update is available.


New Features in 1.0.1

  • In response to customer requests, an optional passcode (PIN) requirement has been added. The optional PIN allows you to protect any sensitive information that you’ve added to your prayer list. (The PIN applies to the entire program, preventing access to all prayer requests if the PIN is not known.) Simply turn on the PIN requirement and select up to a 4-digit PIN. PrayerPartner will then prompt you for this PIN every time that PrayerPartner starts.
  • Automatic saving of data when PrayerPartner exits, such as when the phone rings or a text is received, has been improved.

PrayerPartner for iPhone

Posted on: December 15th, 2009 by Craig Rairdin 24 Comments

PrayerPartner for the iPhone is now available on the Apple App Store. Search for “PrayerPartner” in the App Store, or try this link.

For only $1.99 (you may have paid more for a cup of coffee today), PrayerPartner helps you manage an important spiritual discipline: prayer.

PrayerPartner helps you by maintaining lists of prayer requests, keeping track of which ones have been answered, which ones you’d like to pray for today, and which ones have already been prayed for today. Each request can be categorized, associated with a contact from your Contacts Address Book, and scheduled to be prayed for daily, on certain days of the week, or certain days of the month. Customizable email templates let you quickly mail a personal note of encouragement to a request’s contact. Plus, use the dated journal to record your thoughts as you pray.

Not Excited Yet? Keep Reading

Many of our PocketBible beta testers jumped on board to help with final testing of PrayerPartner. One common comment from them went something like… well, let’s hear from a few directly.

“PrayerPartner has given me the push I need to stay on top of other people’s requests. How many times do people specifically ask for prayer, and we somehow forget to ever petition the Lord on their behalf? This app is helping me make sure that I take their requests seriously, and it makes it easier to follow up with them when their prayers are answered.”
— Lawson C.

“I have found PrayerPartner to be indispensable. I did not know I had a need for an app like this until I started using it, and now it is on my home screen with the applications I use all the time.”
— Paul W.

“I didn’t know how valuable PrayerPartner would be until I started using it. Now I use PrayerPartner every day!”
— Mike O.

It’s interesting that a common theme developed: “I wasn’t really interested in a prayer-related program, but I found that it’s been good for me.”

Sort of like eating vegetables and flossing, I guess. :-)

Seriously, though, I’ve found this to be true for me as well. Now that I’m through developing and testing, I’ve been adding my requests. Here’s what I’ve added so far.

  • a daily praise, different for every day of the month
  • a daily prayer for my children, a different topic every day of the month
  • some friends to be prayed for weekly (some on Monday, some on Tuesday, etc.); I make notes of special needs or stresses so that I can remember to pray for them
  • prayer for our pastor, church and its ministries

Like our beta testers, I’m finding that PrayerPartner is helping me be both more focused and disciplined.

Screen Shots


PrayerPartner Home Screen


Adding or Editing a Request


Picking a Category


Viewing the Full Request

Still To Come?

If PrayerPartner proves successful, we have ideas that would allow sharing requests with others, even (potentially) PrayerPartner users on other platforms.

Coming Soon: PrayerPartner for the iPhone

Posted on: December 9th, 2009 by Craig Rairdin 10 Comments

PrayerPartner for the iPhone has completed beta testing and been submitted to the Apple App Store. We expect it to be available in the App Store “soon”.

PrayerPartner helps you manage an important spiritual discipline: prayer.

PrayerPartner helps you by maintaining lists of prayer requests, keeping track of which ones have been answered, which ones you’d like to pray for today, and which ones have already been prayed for today. Each request can be categorized, associated with a contact from your Contacts Address Book, and scheduled to be prayed for daily, on certain days of the week, or certain days of the month. Customizable email templates let you quickly mail a personal note of encouragement to a request’s contact. Plus, use the dated journal to record your thoughts as you pray.

When approved for sale in the App Store, PrayerPartner will be available with an introductory price of $1.99.

Paging vs. Scrolling on the iPhone

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

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

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

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

You Only Think You’ve Seen Continuously Scrolling Text Everywhere

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

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

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

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

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

When To Load the Text?

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

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

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

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

A Little History

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

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

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

What do the Other Guys Do?

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

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

User Fatigue and Reading Comprehension

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

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

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

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

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

So Where do we Stand?

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

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

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

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

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

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

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

Before You Comment…

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

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

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

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

©2014 Laridian