Logos Data Backup

I would not expect local backup and cross-platform synchronization to co-exist in an application. And enough people run backup and mirroring software that those who truly need a local backup probably already have it covered. Yes, I can think of scenarios where for a tech-savvy user it would be useful to have a local backup so I wouldn't discourage people from making them. But as a system need justifying the expense and added fragility ... I think not.

From nearly six years ago ... and the problem of syncing has only gotten worse with the growth of the tablet market:

Bob Pritchett said:

I feel like this has already been beaten to death, but since it just won't go away, I'll take one more shot.

First, let me say that we do listen to our customers. Even when we say "we're not planning to do that," we keep listening. The evidence shows we change our minds when necessary, if not every time you want.

Now, the simple explanation. I believe that the future of consumer applications is simple, convenient and in the cloud. I know everyone doesn't agree. I know everyone doesn't like it. I just think it's going to be "the ways things are" in the near to mid-term future.

For the record, I have zero photos on Flickr, only use Gmail as a throwaway address, and generally don't use cloud apps. I have a technical person's aversion to data out of my reach. Except I'm lazy, and I'm finding the few cloud apps I do use to offer a really compelling benefit in the way of convenience and simplicity.

So no amount of anti-cloud articles from the technical press or enterprise analysts is going to mean much to me. I already dislike the cloud. It's just that it's so useful and popular, I can't help it. :-) Call me when your friends stop using Facebook and Flickr.

So I see a future in which consumer applications (like Logos Bible Software) are, by definition, cloud applications. For example, Gmail is a consumer email client, Google's attempts to sell it to business not-withstanding. Nobody complains that Gmail runs on Google's servers. It's a cloud service. Even the availability of a desktop client wouldn't cause the world to clamor for Gmail that stored all its data on your hard drive. Nobody is surprised when your email messages are archived on Google's server. That's what cloud apps do, so you can access them from other machines, have online backup, etc.

Logos was a desktop only app, and it's moving towards being a cloud app. It isn't there yet, and may be a hybrid for a long time, or even forever. So I understand that this change is catching some people off guard, and upsetting others. Not everyone will even agree that it's a good idea. I've had the same experience with other apps myself. (Family Tree Maker used to be something I had a purely offline experience with. Now Ancestry.com is the new "cloud" solution they're pushing towards. Weird change at first, but now I appreciate it.)

Yes, your data is your data. And so we are working on better copy, export, and print features. These are literally being coded right now, and you'll have them soon. I'm sorry they weren't in the first release, but for that excuse I'll refer you to any number of "why did you release it now?" forum threads back in November. :-)

As for the argument that allowing people to simply turn of sync for certain document types is just 20-30 lines of code, my answer is: true. But those  would be the most troublesome and expensive 20-30 lines of code in the app.

More than 20 years in software development has taught me that there's no association between "easy to code" and "a good idea." As a formerly very geeky programmer (now just mildly geeky), I was a big fan of an option for everything. Total control for the user of every conceivable controllable thing. Secret .INI files and registry settings to allow changing those other settings considered too obscure for even the Tools > Preferences > Advanced dialog box.

Stupid, stupid, stupid.

Every setting and option is one more way your system can be different from everyone else's, and from the one technical support is using to try and help you. Every setting is one more thing to preserve, import, upgrade in the next version. One more thing to document, test, and maintain. One more thing to make the application scary and overwhelming for the very non-technical user.

Let's look at the implications of this particular proposed change:

Scenario A: We put in code to let users turn off prayer list syncing. User loses laptop, installs on new machine, is delighted to find all their books, licenses, notes automatically restored from the server. Phone call: "Where is my prayer list?"

Scenario B: To avoid Scenario A, we implement a local backup option. Lots more than 20-30 lines to write backup option. (We have to make a special, separate data store for just the non-syncing data, apart from the syncing data, which we don't want in the non-syncing backup. Then we have to write code to read in "restored" backups. Have to make sure it's version aware, in case you choose not to restore for years, and expect future versions to import old backups. Etc.) Now we need code to remind you to backup. Or else we have to trust you to do it. (Real world: nobody does it.) Or we have to tell you when you call, "Sorry, no way to restore those. It's your fault."

Scenario C: You have a desktop and notebook. You have synced notes. You read a Newsweek article on the dangers of the cloud. You turn of syncing of your notes on your desktop. You forget to do it on your notebook the next day. You continue to work on the synced notes on the notebook, and the no longer synced notes on your desktop. Later you turn off sync on the notebook. Six months later you upgrade your desktop. How do we get your notes to your new desktop? What if you decide the cloud isn't so bad, and want to use it to make the switch convenient, so you just turn it back on. And you're getting a new notebook, too, so you turn it back on there. We have to code UI and conflict resolution algorithms for worst-case scenarios of merging long-detached note files. What if you edited the same note, then turn sync back on? What if you don't want sync back on, but had left it on on the notebook, used it on the new desktop, and now want to bring the unsynced old desktop's version of that same note file over to the new desktop? What's the UI?

Scenario All-of-the-Above: You call tech support and are on the phone for 2 hours.

Scenario Highly-Likely: You are not a very technical user, and didn't understand the implications of syncing or not. A friend said "they're reading your prayers! turn that off!" and you did, and now months later you just want your new machine to have all your prayer lists on it, just like it has all your notes, and you call to ask why just some of your data made the transition.

Are these problems solvable? Yes. Are they 20-30 lines of code with no implications for telephone support? I don't think so.

Will we do them, and suffer the hassle and inconvenience, if they are the top priority of a huge number of users?

Yes.

But I hope that's not the case, and so far the feedback we're getting is that sync, and automated (if time consuming) downloads are a welcome benefit. And when users install on new, or secondary, machines, they're positively gushing about the convenience and simplicity of the second installation.

And all this is before we even gets notes and prayer lists (and more) to your smart phone.

Logos 4 has already cut our support costs by a third. (They're actually up, but not as much as they'd be if they were the same ratio of sales as they had been.) And those savings are put to work for you: we're hiring more programmers, processing more books, creating more data, offering (free) new platforms like the iPhone, iPad, etc.

Is it less customizable? Yes. Will we have to adapt, in response to your feedback? Yes. Am I happy with the direction, and confident that it's the right call for the vast, vast majority of our users? Yes.

We have discussed things like private encryption keys, which could be used to encrypt your data before sending it to us. But even that has difficulties: you could lose the key, and we'd be unable to restore your data. If you synced a machine to encrypted data but hadn't yet entered the key, we'd have to make all those records read-only (and not show the encrypted content). Not impossible, but a lot more code, and UI to explain why a note was present but unreadable, etc. And what if you entered different keys, and typed different notes, into two machines using the same account, before they had a chance to sync? Which key should be used? New UI to coordinate the keys without transmitting them, to warn when you've already used a key on a different system, etc. etc.

(These are all obscure scenarios, but unfortunately we have to code for these "edge cases." Which is why we try to minimize complexity whenever we can.)

Which really gets to the bottom line: where do you want us spending our time? We've got a smart team. We can implement whatever grade of security and smart synchronization our users want. But my impression is that < 1% of our users care for more security than we presently offer, and the other 99% think that keeping deep, personal secrets out of their Bible software is a pretty small trade-off in order to keep the programmers building better Bible study tools instead of constructing yet-another digital vault.

Thanks for your patience, and for engaging us in discussion. It's great to have a user base that cares!

-- Bob

More on security:

Almost every web site at which I've created an account will email my password to me. This is terrible security; if I walk away from my computer while logged into email, any passerby can retrieve any password. If you can guess just one password of mine, you can retrieve nearly all of them. (I lock my workstation. Do you? Every time you get up?)

This is why my bank doesn't email my password. Try losing your bank password, and resetting it. Big pain. Probably involves snail-mail or a visit to the branch.

American Express is so secure that I just stopped using their site. I won't sign up for e-billing because it's much easier to mail a check in response to a paper bill. (Actually, I hate paper mail and writing checks, too. So what I really did is just stop using my American Express card. I only work with them on the corporate side, where I've got an accounting department they can annoy.)

I'm glad my bank won't email my password. However, I'm also glad all the other sites will. Because I don't keep anything terribly important at most of them, and value the convenience and simplicity that lets me come back months later and have the site "just work," even if I forgot my password.

 

JAL said:

When asking why beginning with Logos 4 a local backup and restore function was not included in the platform design

Which works easily if and only if you have Logos installed on only one device. Otherwise when you do a reinstall from backup the questions of your intent regarding changes made after that point becomes very ambiguous. Do you want all your installations rolled back to you reinstall point? Do you want you reinstall rolled forwards negating the need for you own backup? Do you want all installations frozen while you reload or do you want want you are doing on another platform .... you get the idea.

Jan Krohn said:

When it comes to disaster recovery (my main/only reason to be wanting a backup function), these questions are less relevant. I'd just take whatever data can be restored.

They are more important to you than you realize because of the potential for corrupted databases ... and I, for one, have had more than enough experience with Logos and corrupted indices. [:(]