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.
After using PocketBible and literally hundreds of other iPhone/iPod Touch apps, for me, the issue is absolutely NOT if it should be paged or scrolled–that’s been settled, and it works and it works well. The issue is that the “tapping grid” is the real problem. Tapping in the middle of the screen shows the tappable regions on the screen and their functions. The problem is that the regions are not consistent from book-category to book-category. The behavior between Bibles and Commentaries differs enough to be quite annoying. Why should I have to constantly refer to a screen diagram when it could be made consistent throughout the app?
So, here’s my solution to making PocketBible more user-friendly:
1. Simplify the screen tap regions
Tap the left side to page back. Tap the right side to page forward. A left-swipe should take you to the previous chapter, and a right-swipe to the next chapter. Simple as that. Need to move to a speecific verse, why not just use the “Go To” feature? Simple and elegant.
2. Retool the bottom toolbar
The toolbar at the bottom really needs to be retooled. Ideally, it should be user-customizable, but some real thought should go into its functionality. For example, by all means, change the behavior of the left “Open” button! It should display all currently open books from which you can switch to whatever open book you want. Ideally, you should also be able to close a book from there as well as open other books from there, but that means some complexity in the programming, so see my suggestions about reqorking the “Menu” button.
You have a “Back” button but no “Forward” button. Not sure why. Seems like the addition of a Forward button would be a great way to toggle back and forth between views as well as to retrace your steps.
Remove the “Today” button. I don’t use it–ok, maybe I should be!–but I find it taking up valuable space that could be used bu more useful (to me, anyway) buttons.
3. Rework the “Menu” button
Reorder the sections to put the reading-based selections at the top and the settings at the bottom. For example, move the current “Books” section at the top followed by “Lists”, followed by “Settings”.
Do you really need the “Navigation” and “Find” sections when you have buttons for them?
4. Make paging animation user-definable
Provide a user-definable setting to modify the animation used in page turning and book changes. To me, it’s just the opposite of what it should be: Page tuning should have the “curl” animation and book changing should have the “slide” animation. Others may disagree, so make it customizable.
My intent in these suggestions is to both leverage the capabilities of the iPhone/iPod Touch platform, and maintain a sleek, elegant, efficient application that the user can tailor to his or her needs.
-Jim Barr
Craig,
I forgot to mention, GREAT posting! Lots of excellent and informative stuff. I think we can all agree that paging is the way to go for this app–PocketBible just needs some usability tweaking to make it solid and elegant.
Jonathan: I use “misuse” in the sense of people using tabs in Word to create tabular data instead of using tables. It’s 2009 and if you’re still using tabs to line up columns in Word, you’re misusing Word.
If you hold down the underscore key to create a line for people to sign on, you’re misusing Word.
If you write letters in Excel because it lets you put the return address block in the upper right corner, you’re misusing Excel.
Joel: Thanks for getting it.
Jim: I don’t normally leave suggestions in blog comments but I made an exception in your case.
Navigation Overlay: There are only two variations on the tap zones: Bibles and non-Bibles. For non-Bibles, the entire left and right thirds of the screen are previous and next page, respectively. For Bibles, add prev/next chapter and prev/next verse in the corners. There’s no such thing as “next verse” in a devotional or dictionary, and its meaning in the context of a commentary is harder to define than you probably think. So the only way to make them more consistent is to remove the chapter and verse navigation entirely. I’d be happy with that, but we’d get grief from the beta testers who originally demanded it and from those who use those features.
Once you get the idea that non-Bibles don’t navigate by chapter and verse, you can turn off the overlay.
A general comment on all your suggestions: You make these suggestions as if yours is the only way to look at the problem and that our failure was in not consulting you at the beginning. I choose to interpret your comments as suggestions and not in the black-and-white, right-or-wrong terms in which they were made.
1. Simplify the tap regions: We get lots of positive comments from people who love the power of having 8 functions available by tapping/flicking. Furthermore, if we did what you suggest there’d be no way to turn the page in books like Nave’s Topical Bible and NASEC/KJVEC that are dense with links.
2. Tool bar: I’ve already said in other contexts that the tool bar will eventually be customizable. I’ve also said that “features you see in our other PocketBible versions will find their way to the iPhone over time.” Both Windows and Windows Mobile versions of PocketBible have a reconfigurable tool bar.
If we made the Open button only show open books, we’d be duplicating existing functionality (try reading the Welcome document, then tap on the title bar to see a list of open books). And there’d be no way to open a book that wasn’t open. Right now you can ALWAYS tap the Open button to either open a book that isn’t open or one that is. And if you know the book is already open you can tap the title bar or use the top/bottom tap or up/down flicks.
I agree that we need more functionality for managing open books, installed books, and uninstalled books. For now you can close a book from the context menu. And I think from the main menu.
“Back” is on the tool bar, “Forward” is in the menu. We opted to do that based on our past experience with whittling down what goes on tool bars. When we had both Back and Forward on the tool bar in our WinMob app, many testers suggested we replace Forward with something more useful.
Ditto the Today button. YOU may not use it (sorry again that we didn’t come to you right away before making any design decisions) but many people do. It has earned its place on the tool bar based on our 20 years of experience designing Bible software.
Keep in mind we designed the tool bar with the knowledge that you’re eventually going to be able to customize it. We put what we felt were the most commonly needed functions on there to begin with but will eventually let you change it.
3. Reorganize the Menu button: You want settings at the bottom. That’s where they were until the beta testers suggested we move Settings to the top. After using the program a while I find I seldom use ANYTHING on the menu except Settings.
Navigation and Find sections are toward the end because we have buttons for many of those functions (though not all).
4. Customizable animation: The iPhone “curl” animation goes only up or down. There is no left/right curl animation. Since pages move from right to left or left to right (like a book), the curling animation doesn’t make sense for page turns.
In general I’m in favor of more customization. As I’ve said many times over the last year (i.e. since before we released the program) the current version is a work-in-progress. We appreciate your suggestions and maintain a prioritized to-do list based on everything we know needs to be in there plus feedback from users (which is often contradictory).
Thank you for keeping my suggestions in this blog. While you pretty much struck most of them all down, I’m not going to turn this into a bickering session of who’s right and who’s wrong–that’s not the issue here. Instead, I’ll simply say that Laridian has an excellent product in PocketBible for the iPhone. In my opinion, it could stand some usability improvements, primarily in the form of providing user-selectable settings for many of the issues discussed here. While this is obviously my opinion, know that I have assisted in the design and testing of quite a few applications over the years. I had hoped that some of my usability experience from both design and user perspectives could be helpful here.
When reading the passages in the Bible in a Year section pagination is far superior to scrolling IMHO
Craig, Thank you for all of the excellent work you and your team are doing. With the addition of notes and copy/pasting, I use this program almost exclusively for sermon prep and Bible study. I have used your program on WM then iPod Touch. I love it. Thank you for enhancing my Christian experience.
Whereas I cannot appreciate the finer aspects of programming, I know that those at Laridian have worked hard and moreover considered many details before choosing the page turning method. I have become accustomed to a scrolling Bible reader and at the time prefer it over page turning, however I will continue to use pocketbible in order to give it an opportunity to grow on me the way the scrolling reader has. Otherwise, I am confident that Laridian will continue to continually upgrade and fine-tune pocketbible as they did with MyBible. It will just take some time and continued communication between their customers and themselves, this blog for instance! : )
I’m upset – I use underscores to make blank lines (at least in OO.org)
. I think we are mostly in agreement though, that using things in a way that they are not designed for will often be sub-optimal.
There are a couple good ways to draw a signature line in Word. I set tab stops at the start and end of each line. The tab stop at the end is set to “right” with leading underline. So then tab-tab will move to the start of the line and underline to the end.
There’s probably also a way to do it with fields.
Erik,
Thanks for giving PocketBible some time to grow on you. I just want to clarify that we don’t consider paging to be something that needs to be “upgraded” or “fine-tuned”, nor do we think it will be fixed if we “take some time” and have “continued communication” about it. I wasn’t writing to apologize for it but rather to explain why we think it’s better than scrolling.
On the other hand, we’ve been known to implement sub-optimum features in order to quiet the feedback. The current “Search” dialog is an example. It’s over-wordy and the highlight and category fields aren’t wide enough in portrait orientation to display their contents. However, it was necessary to do this because people were misusing the search feature and instead of reading the help or contacting tech support, they assumed we happily shipped a product that didn’t do basic searching. So we dumbed-down the interface, making it a little awkward for those who get it, but making it a little easier on those who don’t.
Never really thought about it until Craig’s article. Now I have checked and my goodness, he is right. The left / right swipes to move page are a joy. I went back to my other bible program for my iTouch (on which I have spent over $160) and realised that linear scrolling is not as easy. First my finger gets in the moving it up and down the screen, it’s potluck as to whether you get a full screen of new text or you flick too hard and go over. With Laridian, it is an exact next page. Now if only Laridian can replace the Strong’s numbers feature with a different colour for the word that has a link, then we have a full replacement for the other software. Great job – nicely thought out on the page swipes.
Please keep the way you as the programmer want to do it. However, unlike ebooks there are links all over the place and I seem to accidently hit them on a continuos pattern when switching books or pages. I also keep accidently keep switching books when I want to switch pages. I think this is why many are complaining. We just don’t want to worry about getting sent somewhere we don’t want to go.
I trust this is what you mean by improving existing features. Thanks again for your hard work.
Bryant:
When you have a book with lots of links, use a right-to-left swipe gesture to turn the page. Then go back to the Welcome document and read about how to navigate in the program. You’ll probably learn a couple things.
I accidentally do things in all my iPhone apps, thinking they work a different way. Once nice thing about PocketBible over all my other apps, though, is that PocketBible has extensive built-in Help.
Well that did help. Because the “tap” menu says tap I thought that was the only way to switch pages. That info is in the welcome book. However, the welcome book only mentions tapping the bottom for switching books which causes me to jump to a linked verse. Just for a test I tried swipping up and down and it caused the books to switch too. So I will now swipe for pages and books. Then tap for links.
I tried swipping over linked areas and about 25% of the time it still switched to the link. So I have to make sure I swipe fast to make sure it works consistantly.
The Welcome document describes changes pages by both tapping and swiping. It also refers you to the Help document. Now that I got you to read the Welcome book, maybe you could look through at least the Quick Start Guide in the Help.
Swiping over linked areas works 100% of the time. You need to swipe some minimum distance (don’t remember how far it is, but it’s not far). So you can’t just move your finger from right to left while tapping. You have to actually swipe.
And it is possible to swipe too slow. If you just swipe across the screen and don’t TRY to break it, you won’t.
You’ve made a convert out of me Craig. I was one of those that was complaining when there was no scrolling and now and starting to realize the current ability to either tap forward or back a verse, page, or chapter, is far more convenient. I’m just more than a tad jealous of those using the 3GS, because they don’t have any delay when swiping whereas mine often takes a couple seconds to move on. I like it now.
One quick question, is there any way to display the time in the app other than enabling the system status bar to “always show”. Would be great if the overlay text or menu or something had a time display somewhere so it would be easy to see what time it is without having to enable the status bar showing at all times or closing the application and opening again. Thanks for all the work. I love it!
Craig.
I just want to say “thank you” for the program for the iPhone. I installed the program a few days ago. I had been waiting for more than a year for the program and was surprised to find out that it had been released.
A couple of comments.
The iPhone is my smart phone of choice. No other Bible program exists that is even close to the Laridian product. Having the program resident on the phone vs an on line program like “The Blue Letter Bible” is a quantum leap forward in terms of availability and speed.
Using the paging system vs the scrolling system took me a couple of days to get used to, but I find that it works just fine. As a matter of fact, what really makes it work is the speed that page turns. I can get to the middle of the chapter with just a couple of hits forward or backwards. Paging to the middle of a chapter with your pagination vs scrolling on another Bible program took the same amount of time.
To me, this whole argument of paging vs scrolling is really nit picking. Having a comprehensive resident Bible program (that really works!) for the iPhone far surpasses the issue.
Thanks for your explanation. I wasn’t even going to complain about no scrolling. I just wanted something that actually worked. Your explanation makes a lot of sense (to a non programmer), and I am quite comfortable with your decision process.
By the way, remember all the turmoil about having no separate keyboard for the iPhone? Apple has chosen their way of entering text, and we all now accept it. The reason that we do is because the iPhone is such a brilliant device.
I accept your choice. Now that I understand the reasons for your choice, I accept the choice even more.
A question craig. Will the notes that one has generated (or bookmarks, etc.) transfer to another iPhone if my iPhone crashes and I have to get another one?
I recently had to exchange my iPhone because my iPhone failed. To my dismay resident notes that were generated in my non-Apple applications vanished. Only Apple applications were saved and installed on my new iPhone.
I noted (too late) that one program used an on line way to save the files generated in their program. I discovered this too late.
Can you comment?
Apple gives both you and us very little control over the data on the phone. There’s not a way for us to move data from one phone to another using our app on your phone or using iTunes. This is very much unlike other platforms.
As I understand it, when you sync your phone with iTunes it makes a backup of the data on the phone. I don’t know what Apple does when you replace one phone with another. I don’t know if you have a way to restore not only your old apps, but the data that was backed up from those apps.
We’ve said here before that we plan to integrate PocketBible for iPhone into our synchronization system that lets you take your user-created notes, highlights, bookmarks, and reading progress and move it between our various platforms. That’s coming in a future release.
In the meantime, as you’ve discovered with ALL your non-Apple apps, we’re all at Apple’s mercy when it comes time to upgrade devices or replace a damaged one.
wow, thanks for the explanation but it seems awkward to have to give a long-detailed excuse not to give customers want they would want.
I purchased Laridian for Pocket PC before version 3 and was happy with the scrolling feature, until version 3 confined me to the Paging feature. I unhappily complained but was told something about the paging feature being more “intuitive”.
In all fairness, I can see the benefit of taking time to get used to the paging method when the software is given for free. After a few moment in practice (because it does take time to learn the features) then I can see why it is not so bad.
Do I still like to page? No, but it was free and I appreciate the charitable attitude when so much work has been put into it.
Can I convince you to change your mind? No, but I can thank you, nevertheless, and say that the app is still in my iphone and is useful in my biblical research.