If you want to think of this as a PocketBible 3 for Windows progress update, you wouldn’t be entirely wrong. You will surely be disappointed, but you won’t technically be wrong.
The Dingus
We’re experimenting with giving you access to AI-generated commentary and other tools in the Autostudy feature in PocketBible 3 using the ChatGPT API. You won’t have to have a ChatGPT account to use it; we’ll create the prompts and automatically submit them and get responses for you to include (if you’d like) in your Autostudy output.
ChatGPT uses Markdown in its responses. Markdown is an easy way to create formatted text with a plain text editor. PocketBible use HTML for this purpose, which is a very different and more difficult way to create formatted text. So we have to convert from Markdown to HTML to display ChatGPT results in PocketBible. This is not straightforward, as Markdown wasn’t “designed” so much as it was pieced together as needed.
When the nerds who power our tech economy were asked to come up with a “standard” for Markdown, they discovered that even its most formal definition was ambiguous. If someone asked, “What happens if you overlap bold and italic markers in the text?” the only way to find out was to try it and see what happened. In order to make it easy for users to experiment and deduce the rules, they produced what is known simply as “the CommonMark Dingus” — as in “that whatchamacallit on their website”. The Dingus lets you enter text using CommonMark syntax and it shows you how it will render and what HTML tags are required to get the same result.
The Laridian Dingus
After laughing about the CommonMark Dingus every time I used it, I realized the only way I was going to be able to interactively test my server-based Markdown to HTML converter was to write my own “dingus”. Turns out it’s actually not a bad idea. I see now why they created it.
The Gooberizer
While writing this, I (Craig) was reminded of some PocketBible code. Back around 2002, my programming partner, Jeff Wheeler, was working on the DailyReader app. At the time, daily devotional books and Bible reading plans were not a part of PocketBible, but rather, you needed a separate app called DailyReader.
Since DailyReader didn’t know how to read PocketBible books, and since Palm OS, the hot mobile operating system at the time, didn’t have a file system (!!!), we had to come up with a way to store the text of reading plans and devotionals in a way that would be compatible with a Palm OS database, would be quick and easy to decode, and wouldn’t be readable by humans.
Of the two of us, I was the guy who had experience with encryption. I had implemented a simple encryption algorithm that we were able to use on our website and in our apps when we needed something “secure enough” — not something you’d trust your credit card number to, but good enough to obscure other sensitive information that we don’t want you messing with. So Jeff came to me to figure out how to obfuscate his DailyReader data.
“I don’t need some kind of unbreakable encryption. I just want to goober up the text enough that it can’t be read by the average user,” he said. I picked up on Jeff’s goofy terminology and created the skeleton of code called “The Gooberizer“. I created a simple encryption algorithm with a symmetric key — as long as the producer of the encrypted file (his little program that created DailyReader books) and the consumer of it (the DailyReader app itself) use the same key, one can encrypt and the other can decrypt the data. In order to make it slightly more secure, the secret key is not something stored in the program, but rather is computed based on the data in the book. This made it harder for a nefarious (or curious) user to break the code and ungooberize the text for himself.
Jeff fleshed out the code from my design and DailyReader soon had fully gooberized text.
PocketBible and the Gooberizer
Three years later I was adding some code to PocketBible and needed a way to authenticate an LBK (Laridian Book) file. We had decided to release our BookBuilder app as a commercial product but didn’t want a rogue competitor to use it to reproduce our entire library and put us out of business. So we put information into the LBK file that tells us that the file was built by the consumer version of BookBuilder. We needed a way to verify that these imaginary rogue competitors (who were growing more vile and contemptible the more we thought about them) weren’t tampering with the info to convince PocketBible that their books came from Laridian.
Then I remembered the Gooberizer. I rejiggered the Gooberizer code so it could produce a one-way hash of any string you gave it. The idea is that BookBuilder would build a string based on critical values in the LBK file, then store the gooberized string in the LBK itself. When PocketBible opens the file, it builds its own copy of the critical-values string and produces its own gooberized representation of it. If the stored goober and the runtime goober match, you get to read the book.
But seriously…
It can be embarrassing when the terminology you use around the office to describe something makes its way into public. You casually refer to your experimental test page on the website as “that dingus” and the next thing you know it becomes the most important part of your project.
Fortunately, we don’t foresee any need to give the public access to the Gooberizer. So for now it’s our little inside joke. Until somebody decides to write a blog article about it.
When traveling near the speed of light, one experiences both the dilation of time and the contraction of distance. An astronaut traveling to a distant star at near light speed experiences less time than his friends back on Earth. He arrives at his destination sooner than expected because he also experiences less distance to that destination — as he accelerates toward light speed, his destination appears to be disproportionately closer to him than it would appear if he were at rest.
Then an interesting thing happens as he gets closer and begins to slow down — his destination gets farther away. This is due to the reduction in the effect of length contraction as he slows towards being stationary with respect to the destination.
We see the same thing happen in the software world. As we approach the end of a software project and find ourselves implementing fewer new features and solving fewer bugs, the release date appears to move farther away. The effect of taking 4 weeks at the beginning of a project to solve a major problem is relatively minor in the grand scheme of things. But taking 4 weeks on a single task at the end of a project makes it feel like it is never going to be completed.
Reactivity
One of the major challenges we’ve faced in the last couple of months is related to Vue — the user interface framework we use. Vue is a “reactive” system. That is, if you want to display some text on the screen, you don’t write code that moves to a particular (x,y) location and outputs the text in a particular font, but rather you define an area of the screen that will display text in a certain font, then attach a particular variable in your code to that area of the screen. Now when you change that variable, the screen is updated with its new value. In other words, the user interface reacts directly to changes in your data.
In order to know when it needs to update the screen, Vue wraps its own code around these reactive variables. It is very good at doing its wrapping. If you’re not careful, it can “infect” certain pieces of data with its reactive wrapper. The result is not only inefficiency (since a bunch of unnecessary code is executed when you change the value of a variable) but potential confusion as Vue believes you’re changing data at a time when you shouldn’t be changing it. In reality, Vue shouldn’t be paying attention to it at all, and everything it reports is nonsense.
One common problem is changing the value of a reactive object or variable while Vue is getting its value in order to render the screen layout. This seems easy to avoid (why would you change something while getting its value?) but in reality, it happens often. For example, the table of contents of a book is a static piece of data. But we don’t keep it all in memory at the same time. So when you want to display the table of contents on the screen, we have to read it from the book. Doing so changes the value of the file pointer that tells us where we are while reading the file. In other words, reading static data (the table of contents) changes a value (file position) in the object in our code that represents the book. If Vue has wrapped this object with its reactivity code, it believes you are changing the data while it’s trying to read it.
The other way this can happen is when accessing some piece of data from a book that needs to be constructed the first time it is accessed but is static after that. Consider the field where you type the name of a book of the Bible that you want to go to. That field needs access to a list of all the book names and the abbreviations of those names that are in this Bible. That information isn’t stored directly in the book file — we have to iterate over the list of all the books of the Bible that are in this particular Bible and generate a supplemental list of all possible names and abbreviations. Consider, for example, 2 John. You might enter “2 John”, “2 Jn”, “2John”, “2J”, “2Jn”, “II John”, “Second John”, etc. We keep a list of all possibilities so we can auto-fill the field. So the act of getting the list of book names for the first time will cause the list of names to be stored in the book object for use if you need it later. Storing the list in the book object that has been infected with reactivity code makes Vue believe you’re changing data while it’s trying to read it.
There are certain significant data structures in PocketBible that are susceptible to this unnecessary infection by Vue’s reactivity code. For example, we keep a list of books that you own. Some are open, some are installed but not open, and some are back on the server. We know a little about the ones on the server; more about the ones that are installed; and a lot about the ones that are open. What we know about each book is stored in an “object” that is the representation of that book in the list.
For the most part, this large list of book objects is not directly displayed anywhere on the screen and Vue doesn’t need to know about it. Our code will reference it when getting Bible text or when showing you the table of contents of a reference book. But you’re rarely looking directly at data directly stored in this list. As a result, this list is immune to being infected by reactivity code, and we’re free to change the data it contains whenever we want.
But because this list is so central to almost everything PocketBible does, it isn’t difficult to accidentally expose it to Vue, then have the result of the reactivity infection show up in a completely different part of the app.
We’ve spent a lot of time in the last 3 months chasing down a major bug related to this reactivity infection phenomena. We’ve been seeing the symptoms for quite a while but hadn’t taken the time to look into it until recently. We think we have it solved but it’s the kind of thing that can pop back up at any time.
New Bible Format Implementation
We continued and perhaps finished work on integrating the new Bible format that we’ve been talking about for the last year or so. In addition to the basic functionality we added some enhancements that allow us to see the version numbers of this Bible data and identify where it came from so that future troubleshooting should be easier.
Link Preview
We began work on the link preview function, where hovering over a link causes the target of that link to be displayed in a pop-up window. For example, hovering over a Bible reference will cause that verse to be shown as long as your mouse is hovering over it. The user interface portion of this task (tracking your mouse and popping up a window) is basically complete; now we need to implement code to get the text that populates the window.
We’ll also be adding code to activate the link preview pop-up on long press for touch-screen devices.
Delete Books
We implemented the ability to delete books installed on your machine. This is trickier than you might think, since you have to make sure the book is not left open in one or more panes after it has been deleted.
Miscellaneous
We fixed a problem with devotional start dates and at the same time, found a problem that might be related to 2024 being a leap year. Should be easy to fix once we take the time to look for it.
We fixed a problem when trying to find an installed book when you only know its publisher ID and book ID. This is rarely used but could have caused a hard-to-find bug had we not caught it when we did.
When looking for a Bible to handle a link (or, in general, any book to handle any link) errors were always being reported to the user even though there are some cases where we want to know there was an error but don’t necessarily want to show it to the user.
I told myself I’d write a progress update after the first of the year. Suddenly that’s where we’re at.
As you recall from updates 14 and 15, we had a bit of a crisis of our own creation happen toward the end of 2022 which required us to update both BookBuilder and PocketBible on every platform. We had to modify our Bible format and make sure all versions of PocketBible (with the exception of the old/current Windows versions) could read the new format.
We started with our BookBuilder and PocketBible apps for macOS, since these two share a lot of code and doing them at the same time gave us a platform on which to test our new Bible format. We held off on releasing BookBuilder in case we discovered anything we needed to fix as we rolled out the changes. We released the macOS version of PocketBible in May with updates following into June.
This allowed us to turn our attention to the Android version, which was problematic because of Google shenanigans. An initial version was released in September to address new Play Store requirements. We spent the next 6-8 weeks implementing the Bible changes and doing updates to fix various problems discovered after the release of the new version. This was our first update in 5 years for the Android app, so there were some issues.
That brought us to the Thanksgiving/Christmas season, which is our busiest time of year. There are two large tasks that I’m personally involved in because they impact code on the website — creating the 2024 editions of the Bronze, Silver, Gold, Platinum, and Emerald PocketBible Library collections, and implementing the end-of-year “name your price” sale. Because these tasks have to be done every year, some of the process is automated. But it still requires a bunch of my time.
Despite the distractions, progress was made on the Windows app during this time.
The app is very close to being feature-complete, at least for the standard (non-AFS) feature set. One of the next big tasks that, oddly enough, consists of a lot of unknowns is being able to build a Windows EXE suitable for distribution.
As I’ve explained before, we do all of our development and testing on macOS. We’ve done occasional debug builds for Windows, but we’ve never been able to generate a stand-alone EXE like we’ll have to do when we release the product. So even though we’re not quite there yet, I have someone looking into those issues.
This has taken us down two dark alleys. One was compatibility problems with the versions of the Electron and Vue frameworks we’re using in the app. In order to build an executable that works, I think we’re going to need to be running newer versions of those foundational tools. Electron isn’t much of an issue, but Vue has undergone breaking changes in its most recent major update. This requires that we make significant changes just to get our code to build with that version.
The second issue is code signing. Code signing is a process that is supposed to do a couple of things. First, it assures you that the software you download from our website really is from us and not some other company pretending to be us. Second, it assures you that the code hasn’t changed between the time we signed it and the time you downloaded it. This is meant to make you safer (or at least make you feel safer). But if you think about it, code signing is arguably pointless. No malware you’ve ever been a victim of is stopped by a code signing requirement. If this requirement were lifted, all the same malware would continue to work just fine.
Anyway, signing our executable and getting it to work after it is signed has been a challenge. But we’re working on it.
Meanwhile, I’ve been able to get back in my coding chair and have been porting the new Bible format to the Windows code. One unexpected benefit is that I’ve gotten to re-think the way we had ported this code from C++ to JavaScript in the first place and make some changes that will make it easier to maintain. I’ve borrowed some from the C++ (macOS and Windows) implementation and some from the Java (Android) implementation. This gives us good consistency between all platforms and will make maintenance easier in the future.
To sum up, after a detour to do a lot of work on other platforms, we’re back to work; we’re close to feature-complete (at least for the standard feature set); and we’re focusing on tasks that are necessary to move from development to beta to release.
Sometimes the things we think are obvious to the outside world aren’t.
In our last update, we explained in detail a problem we had encountered in the way that we encode Bibles for use in PocketBible. The TL;DR version is that we found it necessary to update every version of PocketBible, plus update the BookBuilder app, in order to accommodate necessary changes to the way we deliver Bibles.
As you know, PocketBible runs on four platforms: iOS, macOS, Android, and Windows. One of our points of pride is that PocketBible is a native app on each of those platforms. That is, we didn’t use a special tool that might allow us to create one app and run it on all platforms — we created separate apps for each. So when something like this comes up, we have to update PocketBible on all 4 platforms, and in this case, we also had to update our BookBuilder app.
We have a very small team of developers. We don’t have people assigned full time to each platform. So to work on one we pretty much have to stop work on others. That has meant that while we’ve been focusing on Windows, we haven’t been able to do much/anything on other platforms. It also means that if we need to work on iOS, macOS, or Android, we aren’t able to do much on Windows.
We kind of thought you guys all understood that, so we’ve been keeping you updated on our progress on the other platforms with the understanding that we would get back to Windows when these were done. Turns out that wasn’t clear. Hopefully now it is. Here’s where we stand on each of the other platforms with respect to this Bible format update.
BookBuilder and PocketBible for macOS
Because BookBuilder needed to be updated (of course) due to the Bible encoding changes, and because BookBuilder and PocketBible for macOS share so much code, we tackled both of these together. We did all the necessary changes to BookBuilder, then tested the output in PocketBible on the Mac.
While we were in the code, we did some necessary bug fixes and a few enhancements. We released PocketBible 1.4.2 on June 7, 2023 and it’s been pretty stable.
We did not release a new version of BookBuilder to the public because it’s possible we’ll discover problems related to the new format while working on all the PocketBible releases, and we’ll want to go back and make changes.
PocketBible for iOS
Version 4.16.0 went to a small group of beta testers about a month ago. Problems have been minimal and I anticipate we’ll approve it for the App Store soon. It incorporates the new Bible encoding changes and has a small number of improvements and quite a few little bug fixes.
PocketBible for Android
Android has been a challenge for a variety of reasons. Google changed the rules on us and required that we rebuild the app with the latest version of their tools for basically no reason. The app was working fine, but after telling us we had until August to upload a new version to Google Play, they decided to invalidate the app in May. This fell right in the middle of what we were working on for the other platforms. We opted to continue on our original plan of updating the Android app by the end of August. In the meantime, Android users were given instructions to side-load the app from our website and that worked fine.
PocketBible for Android has not been updated since 2018 and the changes required to get it compatible with the latest OS have been challenging. We released a build with minimal new features on August 29th and updates to fix some bugs on September 2 and 7. We anticipate at least one more small release to fix some additional issues; probably two more.
Once we get Android up to speed with Google’s new requirements, we’ll need some time to do the Bible encoding changes. This will involve porting a lot of code from the macOS/iOS apps and making sure it works. The Android app handles Bibles slightly differently from the other apps, so it’s not just a line-for-line translation from one language to the other, but rather it’s a concept-by-concept implementation using methods consistent with the way Android does things.
I’d like to tell you how long I think that’s going to take but I know I’ll just be wrong. Shouldn’t be too long, though.
PocketBible for Windows
Remember PocketBible for Windows? This is an article about PocketBible for Windows.
Once we get back to the Windows app I want to do a couple of things. First, I obviously need to port the Bible encoding changes from macOS/iOS into Windows. The JavaScript code in the Windows version follows the way the C++ code in macOS/iOS works pretty closely, so this should be easier than doing it in Android and Java. Second, while we’ve been working on getting the program finished, new versions of both Electron and VueJS have been released. We should refactor the app to use the new code so we’re not starting out already in need of an update.
We’re actually fairly close to having at least the standard features of the Windows app finished once we’re able to get back to it. There are some Advanced Feature Set features that haven’t been touched yet (Autostudy comes to mind).
Moving Forward with the “Native Apps on All Platforms” Plan in 2024
I want to take advantage of the fact that we’ve had to do recent re-releases of PocketBible on every platform and make it a goal to do some kind of small update to PocketBible on each platform every year. It’s easier to keep up with frequent, small changes than to have to absorb a massive number of changes to how to build and release apps when you do it every 4-5 years.
So that’s the status of PocketBible for Windows, told in terms of everything else that’s going on here. Anytime you see a blog article about any of the other platforms, count it as progress on the Windows app. 🙂
The last 3 months have been interesting. One of our ticking time-bombs exploded and we’re working hard to rebuild. Let me explain…
As we explained in the video that launched this project, when we originally designed PocketBible we put a lot of intelligence about specific Bibles into the program itself. This was done so that PocketBible could handle differences in versification between Bibles. A simple example is 3 John 14-15. These are two separate verses in some Bibles and are combined into verse 14 in other Bibles. As a result, if you highlight 3 John 15 in a Bible that has that verse but are reading a Bible that does not have that verse, we apply the 3 John 15 highlight to 3 John 14 (if it isn’t already highlighted), not because it’s the last verse of the chapter and there isn’t a verse 15, but because, in a 14-verse version of 3 John, verse 14 contains the contents of verse 15 and therefore is verse 15 (and verse 14).
3 John 13-14 (King James Version)
3 John 13-15 (New American Standard Bible)
13I had many things to write, but I will not with ink and pen write unto thee: 14But I trust I shall shortly see thee, and we shall speak face to face. Peace be to thee. Our friends salute thee. Greet the friends by name.
13I had many things to write to you, but I do not want to write to you with pen and ink; 14but I hope to see you shortly, and we will speak face to face. 15Peace be to you. The friends greet you. Greet the friends by name.
Some Bibles split 3 John 14 into two verses (or, if you prefer, some Bibles combine verses 14 and 15 into one verse and call it 14).
Solving issues like this was originally done in the code. So there’d be a whole sequence of steps like, “If this Bible references is in 3 John and the verse number is 15 but the Bible you want to map it to has a version of 3 John that only has 14 verses, then set the verse number to 14.” This was fine when the number of these cases was relatively small. But as we added more and more Bibles, there turned out to be hundreds of these.
The solution was to describe all the mappings in a table containing the “from” book, chapter, and verse, and the “to” book, chapter, and verse for each weird situation. The data tables that describe this mapping are huge and complicated. There are between 1500 and 2000 of these “special cases” in PocketBible. And this is just one of the required data tables. There is another table that tell us which version of each book of the Bible is in each of the Bibles (so we can tell if a particular Bible has the version of 3 John with 14 or 15 verses, for example). Another table maps each of these different versions of the books of the Bible to their names. (So that we can tell that both versions of 3 John should be called “3 John”.) A variety of other data tables help us deal with these issues.
The problem with putting this information into PocketBible (whether directly in the code in a series of “if this then do this” statements or in tables that can be iterated and processed by code) is that anytime we release a new Bible with a new versification scheme for one or more of its books, we have to update every version of PocketBible. Currently that list would include PocketBible for iOS, Android, macOS, Windows Store, Windows Desktop, and the new Windows Version — six different apps would have to be modified. Three of those six share the code that contains these tables. That is, they all use the same code in the same language to process Bible references, and it is written in C++. So once we add a new Bible to the C++ code, the iOS, macOS, and Windows Desktop products are done. But the Android app is in Java, the Windows Store app is in C#, and the new Windows app is in JavaScript. So that means the same changes have to be made in 4 different languages, then 6 different apps have to be rebuilt.
Building the app for every platform is tedious, error-prone, and time-consuming. On top of that, over time it gets to where it can’t be done. We were still supporting PocketBible for Palm OS long after it got to where it was impractical to build a new version of the app. Ditto PocketBible for Windows CE and Pocket PC. And then there was PocketBible for webOS and Blackberry that were created by outside developers. In other words, this was just a bad design.
So in 2015 we decided to redesign our LBK files so that these tasks were not performed in the code, but were all described in tables that could be packaged with each Bible. That way, the app could look at each Bible as it was installed and if it contained a more recent version of these tables than what the app already knew about, it would update its tables with those contained in the LBK file. This would allow a new Bible completely unknown to PocketBible to be released and it would function as if PocketBible knew about it all along.
When we contacted the developer of the Windows Store app about these changes, he wasn’t excited about making them because of the time involved. And when we started digging into the old (old at that time; older still now) Windows Desktop code, we realized it would be all but impossible to update that app to include compatibility with these new Bibles. (Remember also that at this time it was unclear whether the Windows Desktop app was even going to continue to be used because supposedly the world was transitioning to the awful Modern User Interface paradigm of Windows 8. So it was unclear whether or not it would be worth the time to update it.)
We decided to go ahead with the new LBK Bible format anyway. It would just mean that new Bibles wouldn’t work on the Windows platform — at least not until the Windows Store version was updated. What we didn’t know at the time was that it never would be.
As you know, this became one of the primary motivations to re-write PocketBible for Windows. The new version already implements compatibility with the new LBK format for Bibles.
Psalm 68:11-14 NASB
Psalm 68:12a-15 NAB
11The Lord gives the command; The women who proclaim good news are a great army: 12“Kings of armies flee, they flee, And she who remains at home will divide the spoils!” 13When you lie down among the sheepfolds, You are like the wings of a dove covered with silver, And its pinions with glistening gold. 14When the Almighty scattered the kings there, It was snowing in Zalmon.
12aThe Lord announced the news of victory: 13a“The kings and their armies are in desperate flight. 12bAll you people so numerous, 14awill you stay by the sheepfolds? 13bEvery household will share the booty, 14bperhaps a dove sheathed with silver, 14cits wings covered with yellow gold.” 15When the Almighty routed the kings there, the spoils were scattered like snow on Zalmon.
This is the same passage in two different Bibles. Verse division is completely different and involves the rearranging of the text and suffixes on the verse numbers.
What we didn’t realize is that we had been lying to ourselves about no longer needing to update the code in PocketBible when a new Bible was released. There were conditions under which that lie was definitely true. But there were still small, special cases scattered throughout the code and not handled by a data table in the LBK file. For example, some Bibles contain verses with suffixes, like Isaiah 14:25b and Psalm 68:12a, 12b, 13a, 13b, 14a, 14b, and 14c. In the apocrypha, Sirach has a chapter called “Prologue” that is called “Forward” in some Bibles. Esther has chapters A-F in addition to its numbered chapters. While we could map all of these verses to their corresponding verses in other Bibles using the tables that we had moved into the LBK file, when we wanted to print out the Bible reference “Psalm 68:12b” there was a piece of code that got called to look at the stored verse number (which was 14 in this case — 12a was 12, 13a was 13, and 12b was 14) and return the correct “spelling” of that verse number (the 14th verse in Psalm 68 is “12b”).
This all came to the boiling point with the pending release of several new and updated Bibles. While updating the data tables that would make these new Bibles work on any version of PocketBible including the new Windows app, I realized I would also have to deal with some of the special cases in the code itself. And that meant doing the very thing that we had told ourselves we’d never need to do again — simultaneously updating the iOS, Android, macOS, and new Windows versions of PocketBible.
The only reasonable plan forward is to finish what we started back in 2015. So for the last couple of months I’ve been working in both our BookBuilder app and the macOS version of PocketBible (since its code is easiest to work with while working on BookBuilder) to move special cases out of the code and into data tables, then adding code to write those data tables into the LBK file, then adding code to read them into PocketBible when necessary. For each special case in the code, the code has to be rewritten to use the data tables instead. All of this has to be tested and will have to be tested on each platform into which we roll this new code.
What this means is that once I finish doing this in the macOS version, I need to do the same in the iOS version (should be quick since it’s the same code that is used in both the macOS and iOS versions), then re-write it in Java for Android, then release all those new versions to their respective stores, then update the new Windows version (re-write for a third time, this time in JavaScript) and test it there.
So that’s what I’ve been doing so far this year. How’s your 2023 going?
Meanwhile…
In the meantime, we’re moving on to Advanced Feature Set features in the Windows version.
The ability to create saved layouts has been implemented similar to how it exists in the macOS version. You can create a new layout, give it a name, and it will appear as a tab across the top of the screen. These tabs can be dragged around to re-order them, and they can be renamed. This will get awkward if you have more than a handful of layouts, but should work for most people who would like to dedicate a screen layout to devotional reading and another to study.
Related to the above, we’ve added a toolbar button labelled “Today” that will activate a devotional and take you to today’s reading. If you have a layout named “Today”, this button will activate your layout named “Today” and show today’s reading in the active devotional. This is not unlike the same feature in the macOS version of PocketBible.
Quite a bit of progress has been made on implementing a “Speak” feature. The app uses the synthesized speech voices built into Windows to read to you. You can read the selected text, the selected verse(s), or start reading at the top of the page and continue until you tell it to stop. Toolbar buttons have been added to control this feature. You’ll be able to choose your voice and the rate at which it is speaking. Different voices will be available for English, Spanish, and Greek, assuming you have them installed. This will all be similar to the macOS version, which uses the synthesized voices built into macOS.
Some smaller tasks have also been accomplished:
Ability to remove an installed book.
Solved some very tricky issues related to date calculations in devotionals.
More tricky issues related to going to a particular place in a book (say the reading for today in a devotional) and the program getting confused about where it was at.
Better detection of AFS subscription changes and how that affects options you may have selected that require an active subscription.
It’s been a while since I posted an update. With the madness of Christmas weekend behind us, I thought I’d take a moment while the house was still quiet to go back through the last three months (yes, it’s been that long) and let you know where things stand.
First, let me say that this was a slow quarter for progress. It has gotten to where I (Craig) am usually the only programmer working on this project and the end of the year has required me to turn my attention to other things. Probably the biggest of these was wrapping up my 7-Minute Bible so that we could finally get that out the door. It was the result of several years of work that required reading all the way through the Bible multiple times, including a very interesting final pass (performed mostly in the 3 months prior to release) to add subject headings throughout the text. If you want an exercise in really learning the Bible, I suggest you create an outline of the entire text for the purpose of adding your own subject headings. I speak from experience.
During this same time I negotiated contracts for 2 new Bibles, 2 significant updates (NRSV and NET), and 2 minor updates. In addition I spent quite a bit of time trying to work with a new publisher (new to Laridian, not new to publishing) who refused to tell us whether or not digital files existed for any of the titles we wanted, refused to provide any sample files so we could understand how difficult they might be to tag, and refused to describe (even in the most basic terms) what value they have added to several public domain titles to justify licensing their version of the text vs. just finding a public domain source. We have been unable to work with this publisher, who insists that the other software publishers just sign the contract without asking any questions about what they’re going to get.
On top of this, 2 of the Bible contracts were perhaps the most poorly written I have ever seen. One wanted a fixed dollar amount per unit sold, to be negotiated later (we’re negotiating now — how about we include a discussion of what this is going to cost). They wanted to write the contract as being between Laridian, Inc. and a “nickname” they have for the imprint under which the Bible is published (that is, not a legal entity). In that situation, they would have no legal obligation to uphold their end of the deal.
The other poorly written contract required that we submit every new update to PocketBible to them for review before releasing it for you to use. And if we ever stopped selling their Bible, we’d have to stop distributing PocketBible. In addition, there were very specific guidelines for how they wanted their Bible formatted. Unfortunately, it was worded in a way so that it applied to every Bible we published. It wouldn’t have allowed you to control the widths of the margins, the font, or the font size. And wouldn’t have allowed us to distribute some Bibles at all. Their response to these concerns was, “Everyone else just signs this.”
Finally, this quarter is when we update our PocketBible Library Edition collections. This year we added a new Emerald Edition with a significantly expanded selection of books. This required both a review of available products that weren’t already in the Bronze, Silver, Gold, or Platinum libraries and a review of royalties and other contract restrictions. It also required revisions to the script that creates the comparison chart on our website. You would think this would be easy, and it isn’t bad. The hard part is that it automatically calculates your personal upgrade price, and that has to be carefully updated to include the new resources in the Emerald and other 2023 collections.
OK let’s get into this…
New Features
The active study tab was made to persist between sessions so that you can exit the app and relaunch it later and the screen should look like you never left.
We added a “new note” button for notes. This seems obvious, but on other platforms, you add a note by right-clicking (or long-clicking) on some text then selecting the option to add a note from the context menu that appears as the result of your right/long click. Adding a Journal note is only a little easier — a button appears on the note editor view. For the new Windows version, we expanded the behavior of that button so that it works for Bible and book notes as well as Journal notes. By default, the new note is added to the “current” verse for a Bible (the top verse on the screen), but you can also just type a Bible reference to add the note to any arbitrary verse.
Throughout development, searching has been a background process so that long searches can happen while you’re doing other things in the app. This has presented some problems related to being able to get this work in a production build of the app (that is, a build of the app that can run on your machine and not just one of ours). It works reasonably well in our internal development builds but since Electron apps are not really designed to be able to spawn new threads, it has been challenging to get a production build to work. To get around this, we moved searching into the main thread. This makes the program less responsive during searches, but searches don’t take very long. We’ll have to continue to work on this but at least we’re in a position where the program could be released as-is and it would be acceptable.
Last time I mentioned the ability to attach custom accelerator keys to most program functions. The user interface for this feature was enhanced significantly to make it easier to find the function you’re looking for.
The new app will have a selection of color schemes much like the iOS version of PocketBible. We took a couple days and finalized the full set of color schemes and divided them between standard and advanced feature sets. We made the custom color scheme feature only accessible if you own an Advanced Feature Set subscription.
One of the reasons we haven’t implemented a custom color scheme option on other platforms is that there are too many variables that have to be considered and too many colors that need to be defined. For example, the shade of red you choose for “words of Christ” could be invisible against a dark background. To help both you and us to create color schemes, we added a feature that displays the WCAG contrast level for each text or icon color along with an indication of its acceptability. There are three levels of acceptance: OK, bad, and bad for small text. This doesn’t address issues related to color blindness or other vision impairment, but we figure you can handle that on your own — if you’re able to distinguish the text from the background, then it must be OK. If you are unable to distinguish text from background in one of our built-in schemes and you don’t own the AFS (and therefore can’t customize the theme), you can probably find a different color scheme that will work.
Toward the end of this reporting period, significant progress was made on supporting multiple saved layouts if you own the Advanced Feature Set. Tabs are displayed for each layout, similar to the macOS version. Tabs (layouts) can be created, renamed, deleted, and re-ordered.
Finally, with respect to creating a production build, we made quite a bit of progress. We believe we can build the app in its final format, but we’ve yet to see it packaged into an exe that can be distributed to users. But we’re much closer to doing that than we have been to date.
Little (And Not So Little) Things
Many small tweaks were made throughout with respect to font sizes, colors, and wording of the user interface text.
Operations on selected verses (such as “copy” and “add bookmark”) were not retrieving the selected verses correctly.
The program was crashing while trying to update the title bar when no book was open.
Switching from having the study pane on the left to having it on the right resulted in corruption of the user interface. Ditto switching from right to left.
There were versification issues in bookmark lists, highlight lists, and note lists. These items could be appear to be attached to the wrong verse.
There were problems being able to consistently open “newer” Bibles (the ones that don’t work with the current Windows versions of PocketBible). This was related to the fact that they carry information with them that makes them work on macOS, Android, and iOS. This information was not always being interpreted correctly.
Features weren’t getting added correctly when you upgrade from the standard to advanced feature set or when your Advanced Feature Set expires.
The screen wasn’t being updated after searches were complete. Search hits that you could see on the screen were not being highlighted, and highlighted results from the previous search remained visible.
Interlinear rows and Strong’s numbers weren’t using the right color.
To-Do List
Since I posted this last time, here it is again…
Bugs
Thoroughly test back/forward. May be capturing view state for history too often, like after normal scrolling.
If book panes get too small, it’s easy to scroll well past the end and confuse the loader.
Go To pane doesn’t appear to scroll to the correct location for devotionals. Current reading is correct but may not be scrolled into view.
Handle versification issues when following links. Links that begin or end on verses that don’t appear in the active Bible should still get resolved.
Font size changes may not be being recognized when switching to the bookmark list.
Manage input focus throughout.
Not search appears to start a search on mount(); never finishes.
Note editor/viewer
(Low Priority) See if we can honor newlines in plaintext and retain those in the rich editor. Right now they are retained in the viewer but not the editor.
Note search
(Low Priority) Switch to enable/disable enhanced search (even for book searches where it defaults “on”)
Search
(Low Priority) Figure out how to move search back into its own thread; solve problem of syncing SourceManager and other functionality between threads.
User Data
Verify we’re tracking the last-synced customer and don’t sync when it changes.
Verify we’re always requesting data from the server when we need to and saving when we should.
Use the logged-in customer rather than the test customer.
Advanced Feature Set
We will release the standard “free” version before finishing AFS features.
Journal (partially implemented)
Handle AFS state changes.
Handle delete operation better.
Solve duplicate Journal notes problem.
Navigator
Autostudy
Listen (may not be possible due to weird Chromium “security” issues)
Library Search
Saved Desktops (partially implemented)
Today button
Preview when hovering over links
Prepare for Release
Finish resolving issues related to doing a release build
Search task
Locations of pre-installed books and images
Locations of image caches; rendering caches
Onboarding
Website
Add platform landing page and catalog page for the app.
Add catalog page for AFS subscription.
Remove other Windows platforms (consider leaving the desktop version for Win7 die-hards).
This isn’t an update on the new Windows project but rather we’re just moving the project FAQ here instead of having it be invisible as a dedicated page on our website. As we make updates to this FAQ we’ll bump its publication date so it ranks higher in the list of articles on our blog.
I haven’t seen an update for a while… Are you still working on this project?
Yes.
Don’t hesitate to post a question to tech support or in the comments below if you’re concerned about our progress or whether or not your favorite feature is going to be included. We’ve been trying to be very transparent about this project (even though you may not see updates here every day or every week) because you all contributed to it and thus made it possible.
Can I help with testing?
We’ll announce a call for testers once we get to the point where we can use them. Those who supported the project during the fund-raising period will be the first to know.
Will I need to have Internet access while using PocketBible to be able to use my Bibles and reference books?
No. And we apologize on behalf of our friends at other popular Bible software companies who have designed their apps to require full-time Internet access. “Forgive them, for they know not what they do.”
Obviously, you need access to the Internet to initially download the PocketBible app and an of your Bibles and reference books you want on your device. Once you have done that, you don’t need Internet access to use the program. The exception is when you’ve chosen to sync your notes, highlights, and bookmarks to our server for synchronization to other devices you own. Obviously you need Internet access for that. But even then, if the program discovers you’re disconnected it will just wait and sync once you reconnect.
Is PocketBible for Windows going to be a subscription service?
No. As it is on all platforms (Android, iOS, macOS, and Windows), the new PocketBible for Windows will be free.
We will offer an Advanced Feature Set (AFS) containing additional features such as Autostudy. The Advanced Feature Set is a subscription service. It gives us a way to generate revenue from our apps. Despite the fact that developing our apps is our single greatest expense, realities of the marketplace make it impossible to charge anything for software these days. The AFS gives us a way to do that without resorting to more intrusive monetization schemes, like putting ads in the program.
The current version of PocketBible for Windows Store shifts a couple very important and very basic features into its AFS: The ability to install more than 20 books, and the ability to sync notes/highlights/bookmarks with our server. These will be part of the free features in the new version, and the features of the AFS will match those of PocketBible running on other platforms.
Will my current Windows Store Advanced Feature Set subscription apply to the new version?
Your current PocketBible for Windows Store Advanced Feature Set Subscription will apply to the new version. However, if you own the Permanent Subscription to the Legacy Advanced Feature Set, which you purchased before the AFS became a subscription, you will only be entitled to the features of the new version that are in your current Advanced Feature Set. Some of those features will be moved into the standard features in the new version. Here’s a break-down:
Current Legacy Advanced Feature Set features that will become standard features:
Install more than 20 books at a time on your device
Split the screen up to five times to view multiple books at once
Quick access to recent verses
Add your own notes to any verse
Highlight verses in a variety of colors
Synchronize bookmarks, notes and highlights to the Laridian Server and between your other devices
Undecided:
Quickly download all the books you own
These will remain AFS features:
Save and re-use multiple layouts, enabling you to save the layout (panes and books) exactly as it was and come back to it
Listen to Bibles and books
If you own what we call the Permanent Subscription to the Legacy Advanced Feature Set, your existing AFS will only give you access to those features listed under “These will remain AFS features”. Most of the other features that are currently in the subscription will become standard features. Within the new program, we will refer to this as the Advanced Feature Set for PocketBible 2.x for Windows. The new version will be referred to as version 3.
Again, if you have an active Advanced Feature Set Subscription, it will be honored on the new version.
When you say you’ll “start with the Windows desktop version” does that mean you’re going to make it difficult to use on tablets?
We’re not starting with the user interface elements of the Windows desktop version, but rather we’re starting with the internals of that version of the program — the stuff you don’t see that makes PocketBible do things like search, store notes, sync with our server, read our LBK files, etc. The user interface for the new version will borrow from concepts in the macOS and iOS versions to be more usable on both the desktop and mobile devices.
There is no code from the current Windows Store version in this new version, nor is any code in the new version based on code in the current Windows Store version. We think of this as an upgrade to the older Windows Desktop version that takes the latest version of the code for that program and adds to it a new user interface inspired by our more recent editions of PocketBible.
Let’s just dive into what’s been done since I last posted an update….
Modal Dialog Component
With this new-to-us technology stack, we continuously discover that a lot of what we expect to be already done for us has to be created ex nihilo. For example, while there is a “context menu” component available to us in Electron, it isn’t very sophisticated and can only handle the simplest tasks. So we had to create context menu functionality for ourselves.
Similarly, there’s a generic “message box” dialog to use for error messages and to ask simple yes/no questions, but we found ourselves frequently needing to get input from the user, such as entering the name of a new bookmark category or choosing whether or not to clear daily reading progress when changing the start date of a devotional book. The built-in message box can’t do that.
We ended up creating a generic modal dialog that could be used to display error messages, ask simple questions, or gather (and validate) input. This is a little harder than you might think, but taking the time to do it allows us to standardize the way input is gathered in the app and gives us control over the appearance of the dialog so it can match the rest of the app. It also makes it very quick and easy to create a fairly complicated data collection dialog when we need it.
This generic dialog can be used for simple messages with OK/Cancel or complex data entry forms.
Once we had that component, we went back and made use of it in several dozen places. Some were easy and some required a little more work. But we’re happy with the results. This is the kind of task that takes a long time in the moment but makes future enhancements to the code significantly easier and faster. And it gives the user a much-better experience.
Bookmarks, Highlights, and other Study Panel Features
Since the last update we rounded out the features of bookmarks in the app by giving you the ability to create new categories and move the bookmarks from one category into another. We added a (somewhat dangerous) feature that allows you to delete all your bookmarks in one operation. We used our new modal dialog component (described above) to ask you 2 or 3 times if you’re sure you want to permanently delete all your carefully created bookmarks.
Reorganized the bookmarks pane and re-implemented the category management functions using the new modal dialog component.
We added the ability to change all the highlights in one color to another color. We changed some existing features to use our new modal dialog, and, like we did in the Bookmarks pane, made sure we were using the user’s global font size preference in the Highlights pane.
With our new modal dialog in-hand, we changed the implementation of some existing features to use it. And we made sure the Study Panel panes were using the global font size we’ve talked about in previous updates.
Accelerator Keys
“Accelerator keys” are the keystrokes displayed next to the application menu items that can be used as shortcuts to that menu item. Many of these you do without thinking about it, like Ctrl+C (Cmd+C on a Mac) to copy and Ctrl+V (Cmd+V) to paste. Others you discover when you realize you’ve been selecting an item from a menu over and over and wish there was an easier way.
Since the last update, we’ve implemented the ability to assign virtually any combination of modifier keys (such as Control and Alt) and a letter or number key to any operation in the program. So if you find it easier to remember Ctrl+S for “search” instead of Ctrl+F for “find”, just reassign Ctrl+S to the “Find” operation in the menu. If you find yourself repeatedly turning verse numbers on and off and get tired of selecting “Hide Verse Numbers” from the “View” menu, just assign Ctrl+Shift+H to that item. Now one key will toggle your verse numbers on and off.
New Accelerator Keys preference page lets you select different keyboard shortcuts for menu items, or assign shortcut keys for menu items that don’t have them.
Part of implementing this feature was making sure that everything you might want to do in PocketBible is present in the menus somewhere so that it can be assigned to a key. We discovered, for example, that we hadn’t yet implemented “Next/Previous Pane” and “Next/Previous Book in Pane”, so we added those to the “View” menu and implemented them in the code.
Not every key can be reassigned. Some are just too well-integrated into the way some of the built-in functionality of the code works to be changed. We manage that for you and warn you if you’re trying to do something that isn’t going to work.
Layouts
We’ve been enduring problems with splitting and resizing panes since the beginning of the project. During this period we attacked these problems.
Let me digress briefly to talk about how programming has changed since I started doing this 40 years ago. Back then we wrote our own code. When we had to, we would purchase a “library” that implemented something hard, like managing a database. These libraries were written by knowledgeable, professional programmers, thoroughly tested, and only updated when necessary to add major new features.
Today, the Internet makes it possible both to distribute and to discover little components that supposedly make programming easier. Yes, there are major components like database managers, but there are also tedious little components that do nothing more than remove leading or trailing spaces from strings. It can be easier to import someone else’s code than write it yourself.
You don’t know the pedigree of the people who write these components. Often they write some complex thing (like the virtual list and context menu components we use in PocketBible) then just vanish into obscurity, leaving you to maintain their code and fix the bugs they left in it (like the virtual list and context menu components we use in PocketBible).
The component we chose very early in the project to manage the splitting and resizing of book panes has been both a blessing and a curse. It definitely saved us some time. At least up until earlier this month.
Example: One of the things it does is notify the app that the user has dragged a splitter between two panes and changed their relative sizes. The sizes are expressed in percentages. So the original size might have been 50/50 and now the new sizes are 30/70. That’s great. PocketBible records the new sizes so that it can restore them the next time you run the app. So far so good.
The problem is that it uses the same notification message to tell you that it has internally changed the size of a pane part-way through an operation. So if you have two panes split 50/50 next to each other, and the left pane is split 30/70 vertically (one above the other), and you close the top left pane, it will notify you that you now have a left pane of size 70 and a right pane of size 50. It doesn’t tell you that the left pane is 70% high and that the right pane is 50% wide. Nor does it tell you that in just a few milliseconds it’s going to reorient and resize the panes, and further, that it’s going to do that incorrectly, leaving your left pane occupying 58.33333% and right pane 41.66667% of the screen where they used to be 50/50 before. (Exercise for the reader: Why those weird sizes?)
One of my tasks recently has been to attack this issue and try to resolve it. I believe it’s mostly conforming to my wishes but it took some doing.
Splitters between panes can be dragged to resize the pane and now have a subtle “handle” to suggest they can be moved.
While messing with the screen layout, I made the splitters between the panes a little thicker to make them easier to find with your mouse (or your finger tip if you’re using a touch screen). I gave them little visual “handles” to make it more obvious that they can be dragged to adjust their size.
Book Panes
Speaking of the screen layout, other changes were made to the book panes.
We discovered that closed panes were still “alive” in some respects and were frantically trying to do things in the background as if they were open. This had no visible impact on the app but made it run terribly slow after a while.
We completely re-implemented the book tabs at the bottom of each book pane. They were trying too hard to look all fancy and clever and as a result they didn’t always work correctly. While we were in there we made sure the tabs adjust their size to your chosen font size so you don’t end up with nice, readable Bible text and tiny, unreadable tabs.
When the text is small (top), the tabs are proportionally smaller. When text is large (bottom), tabs are larger.
The pop-out tooltip that tells you where you are as you drag the scroll bar scroller was getting stuck in the “on” condition. That’s been fixed.
We’ve been ignoring problems with interlinear books like our Greek NT’s and the NIV with Goodrick-Kohlenberger Numbers. Some of the interlinear attributes weren’t being displayed. Now they are.
Interlinear books weren’t working until recently. This is the NIV with Goodrick-Kohlenberger numbers, Strong’s numbers, inflected forms, and lemmas displayed between the lines.
Text Selection
First, the “easy” part: We now automatically calculate a good color to use for text selection (when you drag your mouse to select text). If you think about it, this isn’t straightforward. It needs to be visible against both the background and the text color. Both of those are user-configurable and can be anything. So you can’t just choose a pleasant shade of blue and call it good. The program now finds a color using an appropriate hue from your chosen color scheme that will work for text selection.
The selection color starts with the dominant hue in the color scheme. In this case, this dark color scheme uses a shade of purple for toolbars and buttons, so text selection is indicated by a lighter tint of the same hue that contrasts both with the text color and with the background. This is one of those things that is way more complicated than the average user might think.
The real challenge was handling “select all” in a book pane. It’s simply not realistic to support the ability to hit Ctrl+A (Command+A on a Mac) then Ctrl+C (Command+C) and expect to copy an entire 400 MB commentary to the clipboard (in both plain-text and rich-text HTML). The copyright owners from whom we license texts wouldn’t like it, and it would present some real programming challenges.
On top of this, there’s the fact that PocketBible does not keep the entire book displayed all the time. We just make it look like it is. In fact, it works more like Facebook, where we render additional paragraphs of text as you scroll farther and farther into the book. So when you say “select all”, we actually only select the portion of the text that has already been rendered, which consists of 1 or 2 screen heights above and below what you can see.
A similar problem happens when you start selecting in the middle of the book and drag off to the right of the pane. Selection will extend toward the bottom of the book. (If you drag off to the left, it extends toward the top of the book.) Again, the rest of the book isn’t really there.
The best answer we could come up with was to just make sure we highlight and copy what is rendered. This has the benefit of limiting the amount of text you put on the clipboard, satisfying both our copyright owners and making it so you don’t have to wait while we render an entire Bible into your clipboard.
Miscellaneous New and Updated Features
Changed the Journal icon (AFS feature).
Adjustments to the way bookmarks are handled in the context menu. It can’t realistically handle the situation where dozens of verses are selected, because it lists options for each selected verse. So if you select 100 verses, you can bookmark them all, but you won’t see each one of the individual verses listed on the context menu.
Cloud Library wasn’t showing all owned books. Made changes mostly on the server to deal with this.
Fixed user interface misbehavior of icons on buttons when the buttons got smaller.
Fixed a database initialization bug that was causing tables to constantly be recreated, which would fail after the first call. This resulted in the database operation also failing.
Bookmarks in the context menu when a large number of verses are selected. In this case 78 verses are selected. Individual controls are provided for the first 15 selected verses.
Schedule
I haven’t talked about this for a while, and a few of you have asked. There’s a very common belief that writing software is like baking a cake. If you break down the tasks and and add the amount of time each takes, you’ll get the total time and can accurately predict when it will be ready to eat.
But it turns out it’s more like writing a college textbook for a subject you know well, but doing it in a language you’ve never learned using publishing tools you may have to create yourself. You can quickly learn bits of the language and maybe write an initial draft that looks pretty good. But as you write, you learn more about the language and have to go back and make corrections to previously written chapters. Then you have to decide on where illustrations are needed, figure out how to create them and how to arrange them in the text. Then there’s choosing paper, fonts, ink colors, cover design, binding style, dust jacket design.
Some parts of our probably ill-considered textbook analogy will be easy; other parts will be hard; and some of the hard parts will have to be re-done 2-3 times until you get them right. You might be able to predict completion dates for portions of it, but it’s pointless to try to predict a completion date for the entire project because you don’t really know what needs to be done until you do it.
People don’t believe me when I say we literally don’t have a planned release date for this product. You’d think after 40 years of writing software for business and pleasure, I’d know how long something is going to take. Instead, what I’ve learned in 40 years is that the “ship date” question is one that has no answer. If you try to answer it along the way, you’ll only disappoint people.
That being said, I felt going into this project that it was going to take 12-18 months. However, the further we got into it, the more we didn’t know.
The good news is that I feel like the to-do list is getting shorter. The bug list grows about as fast as we shrink it by fixing things, but those tend to be small tasks. In the interest of total transparency, I’ve included my list of remaining tasks below.
Interestingly, in the process of capturing screenshots for this article, I had to add items to the to-do list.
As you can see, a lot of these tasks are fairly minor; there’s just a lot of them. Some are harder or more unknown than they look.
Remaining Tasks
Bugs
When multiple verses are selected, the reference isn’t formatted correctly in the context menu.
When multiple verses are selected, the last verse appears before the first one in the context menu bookmark list.
Dragging a book into a new pane results in an infinite render loop.
Moving study pane to the right side (or moving it back to left side) causes the resizing controls to be lost.
When moving study pane to the right, the book panes are not getting refreshed.
Thoroughly test back/forward. May be capturing view state for history too often, like after normal scrolling.
Verify that we’re loading the latest book ordering database when we see newer Bibles.
Verify scroll by line and scroll by page is working. Not sure of the latter
Manage input focus throughout.
Implement date-sync for devotionals; save last date sync so we can use it when opening devotionals to the last synced date.
Consider an option to make pane splitters narrow for mouse ops or wide for touch ops.
If book panes get too small, it’s easy to scroll well past the end and confuse the loader
Go To Pane
Consider moving book names to top of Go To pane for all book types.
Note editor/viewer
Make it look better when empty.
Consider “add note” that adds at current location in active book. There have been serious problems with that on other platforms.
Deleting Journal notes doesn’t refresh the list correctly. (AFS)
Can sometimes get duplicate Journal notes somehow. (AFS)
See if we can honor newlines in plaintext and retain those in the rich editor. Right now they are retained in the viewer but not the editor.
Note search
Low priority: Switch to enable/disable enhanced search (even for book searches where it defaults “on”)
Preferences: Color Theme
Settle on color themes for free version and for AFS.
Search
Consider moving search back into main process.
Verify we’re using global ui styles in the study tab.
User Data
Verify we’re tracking the last-synced customer and don’t sync when it changes.
Verify we’re always requesting data from the server when we need to and saving when we should.
Preferences
Use standard font sizes in preferences.
Accelerator Keys
Code review
Organize the list of functions
Advanced Feature Set
Consider whether or not to release the base version before finishing AFS features
Journal
Navigator
Autostudy
Listen
Library Search
Saved Desktops
Today button
Hover Tooltip over Links
Prepare for Release
Resolve issues related to doing a release build
Search task
Locations of pre-installed books and images
Locations of image caches; rendering caches
Onboarding
Website
Add platform landing page and catalog page for the app.
Add catalog page for AFS subscription.
Remove other Windows platforms (consider leaving the desktop version for Win7 die-hards).
Surprisingly, we weren’t sure what our Windows app would look like in Windows.
Running the Windows App on a Windows PC
We spent some time this month bringing the program up on a Windows machine to see how it’s working. This may seem odd, since it is a Windows app, after all. But the fact is that we’ve been doing all our development and testing on our Macs. We can do this because even though the app is being developed for a single platform (Windows) it’s being done with tools that support Windows, macOS, and Linux. That works great for us since we’re 100% Mac-based here.
One of the things we wanted to verify was that the application menu was functioning correctly on Windows. As you may know, app menus on macOS are “disconnected” from the application’s window. And every application has a special menu identified by the name of the app. So PocketBible for macOS has a “PocketBible” menu that is where you’ll find “About PocketBible”, “PocketBible Preferences”, “Check for Updates” and other application-level commands. Windows is different. There is no standard place for some of these items. So we spent some time organizing the way the menu appears on Windows.
Windows also handles “keyboard shortcuts” differently. These are the key combinations that are assigned to certain operations of the app, like Ctrl+C to copy and F10 to activate the menu. On the Mac, you define these by associating them with menu items. The operating system allows you to redefine which shortcut keys go with which operations in any of your apps. Not so in Windows. So we spent some time verifying that we could handle keyboard shortcuts correctly and coming up with simple ways to route these commands through the app.
Back-End Server Updates
When we release PocketBible for a new operating system (what we generally refer to as a new “platform”), we have to populate a database on our server with all the books and Bibles that will be available for it. It’s a bit of a milestone to have created those new database records, which has happened since we last met. Prior to this, the new Windows app had been pretending to be the macOS app every time it talked to the server to either shop in the in-app store or view a list of all the books owned by the currently logged-in user. With this database update, the new app can drop the charade and just be itself.
Added the new Windows platform to the back-end database.
Highlights
Basic highlight functionality was already working. We took some time to take a close look at the highlights study panel pane to make sure everything was there that we needed. We added functionality to remove all the highlights of a selected color, and to change highlights in one color to another color. While removing highlights of a selected color, we also added a way to remove all your highlights from the entire Bible. I don’t think we’ve implemented these features on other platforms.
In the right-click or context menu, we added a “most-recently used colors” list to the top of the menu to make it easy to get to the colors you use most often. This is something we implemented first in PocketBible for iOS. Again in keeping with the iOS version of PocketBible, we moved the highlight eraser to the top of the list of colors to make it easier to find and get to.
If you own the Advanced Feature Set, you’ll be able to rename your colors. Even though we’re delaying AFS features to the end of the project, we went ahead and implemented that one while we were working on highlights.
Bookmarks
We also reviewed the status of bookmarks. We implemented “create a bookmark category” from the bookmarks pane in the study panel and will have it implemented from the context menu by the time you read this.
We added a feature to move bookmarks from one category to another. I don’t believe this feature exists in any other version of PocketBible. We also added a feature to remove all your bookmarks. This is something we have had to do for people on the server before; it will be much easier if you can do it yourself.
Menus and Toolbar
While we were looking at menus, we also looked at the toolbar, since toolbar buttons and menu items are handled similarly in the app. We compared the new Windows app to the current macOS app to make sure we had thought of everything and added some menu items and toolbar buttons we hadn’t yet implemented.
Among these were the following. Unless otherwise noted, we added a keyboard shortcut, a toolbar button, and implemented the functionality:
About This Book – Shows information about the active book.
Toggle Word Attributes (Strong’s Numbers) – Implemented and also added a “toast” — a brief message that is shown to indicate the state of this option (on or off).
Sync Bibles/Commentaries to Active Bible – When the global setting is turned off, this menu item/toolbar button will allow you to tell your Bibles and commentaries to sync up to the current verse in the active Bible.
Sync Now – Sync your data with the server manually whether automatic sync is on or off at the time. Also added a progress bar on the Account Preferences screen and an indicator on the toolbar to show this activity is happening.
About PocketBible — Version, build date, copyright and other info about the app.
Help — Show the User’s Guide (either open it or make it active if it’s already open).
Help on the Web — Related to opening the User’s Guide, this option takes you to the FAQ on our website.
Start Each Verse on New Line
Hide Verse Numbers
Toggle Sync Bibles/Commentaries
Footnote Style — control whether you want to display just asterisks in the place of footnotes, show the entire note, or hide footnotes entirely.
Toggle Words of Christ in Color
Copy Passage — Added a toolbar button. This was already implemented and connected to the menu and context (right-click) menu.
Mark Current Reading as Complete
Go To Today’s Reading — This was already implemented as a button on the Go To… pane. In addition to adding the toolbar button and menu item, we implemented the feature that allows you to go to today’s reading in all your open devotionals when you go to today’s reading in the active devotional.
On the subject of the toolbar, we made some adjustments so that right-click on the toolbar allows you to customize it, and turned the Preferences (or Settings) button into a “Close Preferences” button when you are in the Preferences screens.
On the subject of menus, we created a way for menus to be adjusted when your Advanced Feature Set subscription is enabled or disabled. The AFS features themselves haven’t been implemented yet but we need to support the mechanisms you use to activate those features.
Other Miscellaneous Features
Implemented a way to choose “preferred books” so that when you select a Bible link with no Bibles visible, we know which Bible to try to use. Similar behavior happens with commentaries and dictionaries.
The “expand pane to fullscreen” feature was temporarily removed. I think it’s going to end up being an AFS feature and will be implemented similar to how we do it on the Mac. The way we were planning to do it for Windows just won’t work.
Made links to Web pages and email addresses open the appropriate external app.
When opening a book in a pane where that book is already open, we just activate the existing tab instead of creating a second one. Similarly, if you drag a tab from one pane to another, if the book is already open in the target pane we remove it and replace it with the dragged tab.
Since the last update we wrapped up work on managing bookmark categories (add, rename, delete, etc.).
One of the things we’ve been working on are various display-related settings. “Settings” is not something you implement all at one time as a separate task. We have been doing them as we need them. One of the tasks we’ve undertaken in the last month or so is to make sure we’ve remembered all of them and that we’ve saved them so they can be restored the next time you run the app. This task will continue in the next month or so to make sure we have everything on the toolbar and menus that you’ll need.
In-App Store
One of the background tasks that has been going on here for some time is a revamping of our website. I could write a whole series of blog articles on that task, but suffice to say that the new design separates the data (like all the “catalog text”, screen shots, and book previews for each product) from the way it is presented. We’ve been able to use people who know Web design to do the “front end” development that the user sees, and use database developers to write the “back end” that provides all the data to the front end. It does this through an API (application programming interface) running on the server.
The initial plan for the in-app bookstore in this new version of PocketBible was to do it the way it’s done on Android, iOS, and macOS. On those platforms, the app has an embedded website viewer that opens a mini version of our website inside the app. As we contemplated how to do that in the Windows app, we had a different idea. Instead of making a little website and figuring out how to get it to interact with the app, we could use the existing API for the new website. All the code and user interface would be inside the app. It would use the API to get the data it needs.
The problem with doing it this way comes up when considering how to handle payments. Securely handling your credit card and PayPal transactions is hard to get right. (Unlike most other e-commerce sites that use third-party shopping carts, Laridian has a custom solution that interacts directly with the credit card processor and PayPal.) Doing it from inside the app creates security issues that we didn’t want to take the time to solve. So instead, when it comes time to check out, we securely transfer you to our website through your existing browser. You finish the transaction there then come back to the app to download your purchases. It all works pretty smoothly and it drew a nice boundary around what we had to implement in the app, saving us some time.
Accessibility
As our customer base ages we have heard more and more about the necessity to think about being able to control font sizes throughout the app. That means in menus and dialog boxes — elements normally controlled by the operating system, not PocketBible — in addition to book and Bible text. Each operating system on which we run presents us with different challenges. Most handle accessibility very badly. The way it’s done in iOS, for example, makes it virtually impossible to create any kind of data input form. If we adopt iOS’s way of doing things, we don’t really know how big any text is. They just take over and make it as big as you ask them to. It creates a real mess for every app.
Because of the development environment we’re working in, we have significantly more control. But with great power comes great responsibility. We have to be thinking about accessibility — especially text size — constantly. The problem is that there is a lot of text in a lot of places in the app — window/pane titles, button labels, section labels, instructive text, dialog boxes, and more. Rather than giving you control over the size of text in every context, we’ve decided to tie what we think of as “user interface text” to the sizes of your book text. You have one control that sizes the text in your book window and we base the size of other text in the app on that choice.
To demonstrate both the in-app store and accessibility features, I put this little video together. I don’t normally record video in the office because we get a lot of background noise from the restaurant below us and the street in front of our building. And because our offices are in a 19th century building with brick walls, original wood floors and 14-foot ceilings, there are a lot of echos. But I got here before anyone else this morning and thought I’d give it a try. 🙂
PocketBible for Windows accessibility demo.
One of the fun things about the way we develop here is that it is very iterative and nothing is ever final. While making this video I discovered that the range of font sizes I was allowing both for books and for user interface text was not wide enough so I made some adjustments. I also realized that it was hard to tell which switches on the preference page where you set the font size were on and which were off. I made a couple small changes so now switches turn green when they’re on.