What autosaving behavior do users expect?

Question

Hello Paratext community,

I have found that Paratext’s autosaving behaviour is different than what I expect, so I thought I’d ask you what behaviour you expect, and what expectations you have observed in others.

I am a 32-year-old American working with a Quechua translation team in Peru. For me, and what I think would be good for my team, Paratext’s ideal autosave behaviour would be the following:

• Projects autosave every time a verse is edited and the user goes elsewhere (a resource, the next verse). Notes and note comments are autosaved upon creation.
• This behaviour is default upon installation.

Alternatively, PT could automatically save every 15 minutes. This could be changed in the settings to every 5 minutes, every 30 minutes, every hour, or never… In this case, autosaving between books and chapters would also be good.

I recognize that these settings would present an increased demand on resources, so it may need to considered if it would be feasible for users who have limited computer memory.

Last year our volunteer backtranslator backtranslated an entire chapter of Genesis, and then her computer crashed. She lost the entire chapter and was so discouraged, that she didn’t do any more work for a week.

On a related note, I had activated “Autosave (Automatically save changes without asking when switching to a different book or chapter.)” in Paratext 8. Some time after upgrading to version 9.0, I realized it has been unselected. Just now, many months after updating to 9.1, I noticed that it had been unselected again.

Is there a way for this option to be default, and for the setting to be carried through PT upgrades?

I think most users today take autosave for granted, and don’t have the habit of clicking on the “3½ Floppy-A” icon.

What do you think? What autosaving behaviour do you expect? What do you see in your teammates?

Answer 1

I suggest that the “Yes”, “No” buttons be labelled more clearly, and that the “X” button be disabled. This follows best practises regarding UX design (see this page on UX StackExchange, for example).

image1169×747 51.5 KB

Users in my project often don’t read the confirmation dialog texts at all. That might just reflexively click “Yes”, or “Cancel”, or click the “X” in the top right corner. I’ve seen users click “X” in the top right corner and then wonder why the intended action didn’t happen. They then try to do the intended action again, they are prompted again, they click the “X” again to get rid of the annoyance, and then wonder why the intended action didn’t happen. At some point, they decide to call me and ask why “it isn’t working”. I’m personally convinced that clearer button labels would help. And I’m partial to the idea of more autosaving.

Comments

Great idea bit!

---

Yes, the “x” button shouldn’t be there.

Labelling buttons for their action has long been something I’ve wanted to do consistently in Paratext and we do it when we are able. There are a few reasons which make it difficult for us to do this as often as I would like (common code, localization considerations).

I completely agree that a message box which has a line of text which explains the meaning of the buttons is very far from optimal. We avoid this wherever possible and I don’t think you will find examples like that in more recently added UI. I’ll be saving it as a prime example of “what not to do” in our style guide.

Answer 2

I would like more frequent auto saving as well.

Answer 3

The reason for the current save behavior is because undo/redo stacks are lost during a save. If Paratext automatically saved, undo/redo would be severely limited.
Also, it doesn’t default to being enabled because many of our users don’t want autosave because there are frequent times they don’t want to save.

Paratext already saves when switching chapters/books.

anon094061:

Alternatively, PT could automatically save every 15 minutes.
…
Last year our volunteer backtranslator backtranslated an entire chapter of Genesis, and then her computer crashed. She lost the entire chapter and was so discouraged, that she didn’t do any more work for a week.

Paratext creates a “crash save” every minute. If Paratext does not shut down normally, this save should be loaded when Paratext is restarted. I’m not sure why it didn’t work in your translator’s case.

Answer 4

I did a test and found that if Autosave is turned ON in PT8, it does not stay on when I install PT9.0.

The same is true going from PT 9.0 to PT 9.1: if Autosave is turned ON in PT9.0, it does not stay on when I install PT9.1.

I reported this as a (potential) bug. It seems to me that setting should be “sticky” when a user has it turned ON. Maybe that’s an incorrect assumption, but I’ll report it so it’s on the radar.

james_post

Comments

james_post:

I did a test and found that if Autosave is turned ON in PT8, it does not stay on when I install PT9.0.

The same is true going from PT 9.0 to PT 9.1: if Autosave is turned ON in PT9.0, it does not stay on when I install PT9.1.

Going from PT9.0 to PT9.1 will not retain any user settings because of the switch to 64-bit. There isn’t much we can do about that. EDIT: This turned out to not be true.

Going from PT8 to PT9.0 should retain settings if you didn’t previously have PT9.0 installed (i.e. just uninstalling PT9.0 and reinstalling it will not work).

EDIT: I also want to clarify that having autosave off does not remove saving in any place where autosave happens, it just asks the user if they want to save each time instead of doing it silently.

---

anon291708:

Going from PT9.0 to PT9.1 will not retain any user settings because of the switch to 64-bit. There isn’t much we can do about that.

Thanks for the info.

I don’t want to presume anything on the developers as I know your time/resources are important and limited, but would it be possible to export certain user settings to a file before upgrading to 9.1, then reimport them during the upgrade?

james_post

Answer 5

Aww, you beat me. I was about to correct my .
I went back and verified what I said, and I was wrong. We did figure out a workaround for the 9.0 to 9.1 problem (I had forgotten).

However, the point about having things previously installed still stands. Unless the Paratext settings folders are deleted and all traces of the version of Paratext removed, the settings will not be upgraded when reinstalled. If you do the installation test on a freshly installed machine (where the versions of Paratext were not previously installed), it should work.

EDIT: Also note that if you ever reset your Paratext settings by holding down Shift while starting Paratext, that is one of the settings that is reset (as an explanation why it might have suddenly been lost).

Answer 6

Thank you so much @anon291708 and @james_post. I didn’t realize about the undo/redo stacks and the “crash save” feature. Even so, I wonder if there is a way to at least give users the choice of more frequent autosaves, such as the “___ minutes” option.

I also didn’t know that there were a lot of users that don’t want autosave. Perhaps someone in that camp can share why that is disadvantageous in your case?

In any case, I what more people in the Paratext community think about autosaving.

Thank you.

Comments

Some additional thoughts - UX wise - about autosave…

Autosave is usually great, if you have only one document open. It’s easy for the user to mentally track what document is being saved and how to undo changes if necessary. However, Paratext might have many editable documents open (or you might have your browser or email in view at the same time as Paratext). In this scenario, it is possible to type something in Paratext, thinking you’re typing something into another window and autosave becomes a liability. Someone with focus on a different window may type, “Kind regards, John” or “youtube.com” into a scripture project, without realising. “Youtube.com” will likely be caught by checks. “Kind regards, John” … well, that could sneak past checks and relies on proof reading. If there are many editable projects open,

Then there’s the auto-cleaning that Paratext continually does. This can help users discover that there is a problem with their project. If they continually see “Do you want to save changes” as they navigate to a new chapter when they’re pretty sure that they made no changes, it could be an indication that there are some invalid characters in the text which Paratext is tidying up. It’s a sign to look into the inventories or maybe the text encoding.

We’re continually thinking about whether we can provide something like autosave with safety nets specific to scripture editing. Currently, the save prompt in Paratext is deliberately intrusive. We want to know that you definitely intend to save the changes that were made, and we want to you to be aware that changes happened in this chapter. Translations have been published with unintended text amongst verse text, we want to avoid that!
I can imagine a mixed environment. It would keep the deliberate, prompted save model while also continually autosaving, The latter would provide a backup. If the user’s machine crashes - offer to restore view the backup version and provide an option to restore. If the user chooses not to save, keep the .BAK file with the extra material until they make other changes in that book -save - in case they immediately regret the choice to not save. A user who chooses not to save their hard work could still retrieve it from the .BAK file until they work in that book again. (.BAK files do already appear in the project folder, but I don’t know what causes them to appear.)

---

When the autosave dialog box comes on the screen, what about giving people an indication of what they are saving? Even the first 5 or 10 changed words could be helpful for catching some problems or identifying some automatic Paratext adjustments. Another button on the autosave dialog box could bring up a more detailed dialog box which allows users to see all their changes and accept or reject these changes one by one. Developers have tools like this to avoid committing garbage to the code repository.

PADev.

Answer 7

Good to know @anon291708.

@anon094061, one of the concerns with autosaving is if somebody accidentally deletes something (or selects texts and presses Enter, which deletes it), or does an accidental drag-n-drop and doesn’t realize it, autosave will save their unintentional change. So part of it is a balancing act between whether the user saves their own work (some save all the time, some just forget to) and whether they are observant enough to notice an unintentional change (some may notice right away, others won’t).

And then there’s always the random happenstance in between.

Answer 8

@james_post, ah good point. Autosaving with every verse + losing undo-redo stacks with every save would be a recipe for disaster! … But if there were a way to preserve those stacks between saves, perhaps it could work…

I believe that dragging and dropping is disabled by default, which I think is certainly a good move…

Answer 9

Hi @anon094061, very interesting question as it allow us to see what different users and perspectives exist. A little input from a dinosaur, IT-wise. Normally I hate anything automatic, unless it is very well documented, transparent and configurable (turn-offable included).

A desaster are those tools where they present a mix of concepts, where you have to complete or confirm certain work or configurations (with OK or ENTER) and other windows or parts there is “nothing” and no visual feedback and you just have to hope that your settings have been saved or applied. Or maybe you have just overlooked the tick-symbol which is not bottom-right where you expect it, but top-right. Sound familiar?

So far I am very happy with PT in this aspect and cannot remember ever having lost anything significant, workwise. Good habits, I suppose or good PT or course.

Just one detail: For the local team I have to say, that most of them have never used nor seen any of those “not-very floppy disks”. So the save-symbol in PT is outdated and not helpful here.

I was working for years in PT and never even knew about autosave. One day discovered the option to save when changing chapters. PT was always fair and proposed saving when changing chapters, so we always had to do those clicks. I understood those messages to mean “if you change chapters and do not save, your work would be lost”, so of course we mostly want to save in this case.

If there is more “autosave” in PT beyond the changing-chapters magic, I do not know. Several posts here just write “autosave”. What feature is meant by that exactly?

Otherwise translation work - or at least certain stages - can be done by entering several options (we often use several options next to each other with / symbols to separate them, when working as a team) and looking at them in writing and in context of the neighbouring verses. Then ideas will be shouted and the text on the screen is edited. This could be called “creative messing around until good”.

The verse-history and its “timing tags” is a deep mystery to me still. So instead of having maybe ten versions in a verse we might have dozens or hundreds with certain autosave features, if it were applied to our way of creative testing: may it never happen.

So my perspective for important work like driving a motor vehicle or translating scripture is still that a machine, even AI, can never know what is really happening. So it is the user’s role to concentrate and wisely save when needed. Or to use the option to go away and not save, if some draft ideas were considered and not-loved by the team.

I use some paid professional tools like editors and some let me assign a specific amount of RAM or disk space in GB for undo and for (auto)save purposes. Those are good features. I personally might be very conservative with autosave (but like it where those autosaves are put into specific folders or have specific suffixes to the file-names that I can configure myself). In contrast, I would normally give very generous allowances for undos, for those tools where I am confident that they really handle the art-of-undo well.

Comments

anon334662,
I’m not sure if I’m understanding you correctly, but Autosave is an option you can turn on in the main Paratext settings. If you search in help, you can find the following:

Screenshot 2022-02-18 08.03.34885×805 172 KB

---

If you all are just talking about “Autosave when changing to a different book or chapter”, then I have seen this from the beginning. I have mentioned it in my .

But in my thinking this is not a real “autosave” because it is not automatic. Not time or number-of-edits based. I have to “trigger” it myself by changing to another chapter. If trouble ever came (powercut, beast on keyboard, whatever) that would not save my work for x-hours inside one chapter. This is why I was asking whether there was “something else”.

Again: I have never needed much autosave and I am very happy with PT the way it is - in this aspect. I just want to know all the features that exist. The op was asking what we expect. I expect not much and so I am one happy user.

---

If a user can indeed stay in one chapter for a long duration and not trigger an auto-save, it might make sense to have auto-save auto-triggered every so often (once per hour?). As anon334662 said, if there was a power outage or something, a lot of work could be lost that way.

---

I agree with @anon334662 and @james_post here. It’s easy to spend hours or even more than a day in a single chapter- especially when working on a first draft.

Perhaps Paratext’s crash recovery backups would come into play here?

Even so, I would really like a true autosave.

How do new users come to know of the backup feature, and thus be able to use it? This is really goes into the vast territory of user training. The first idea that came to me was to implement a kind of splash screen for new Paratext installs. Something to the extent of, “if you suffer a crash and lose data, you may be able to recover it from a backup. Learn more by clicking here or searching “backup” in the top search bar.” But if you can justify a splash screen for that, you could justify one for all sorts of things, and then there would be so many popups… And what if a new user doesn’t start on a fresh install of Paratext? So many issues

… Or, what if new users are started on an automated email campaign in their LWC that gradually fed them basic and important info, tips and tricks… This would of course complement existing training systems. But maybe these two paragraphs should be in their own thread .

---

anon094061:

automated email campaign in their LWC that gradually fed them basic and important info, tips and tricks… This would of course complement existing training systems

We are hoping to help solve some of this issue with the online Paratext for Beginner’s workshop (was Paratext Boot Camp). The next one is coming up in June: https://paratext.org/paratext-training/paratext-beginners-training. There is hope/discussion to make this into a stand-alone course where users could take it individually at their own pace.

Answer 10

These are some good considerations and ideas.

An important factor of this conversation is how work can be protected and restored in the event of a crash.

anon094061:

Last year our volunteer backtranslator backtranslated an entire chapter of Genesis, and then her computer crashed. She lost the entire chapter and was so discouraged, that she didn’t do any more work for a week.

What is the user experience for restoring lost work? Is it like Word? They reopen Paratext and a dialogue comes up, asking if they want to restore what they were working on? Or do they have to drive deep into program folders, find the .BAK file, and do something with it?

If it’s more like the later, maybe the aforementioned volunteer’s work was saved, but she didn’t know it.

anon291708:

Paratext creates a “crash save” every minute. If Paratext does not shut down normally, this save should be loaded when Paratext is restarted. I’m not sure why it didn’t work in your translator’s case.

What could be reasons for this not happening?

I feel like the better the recovery options, the less necessary autosave would be.

Comments

anon094061:

What is the user experience for restoring lost work? Is it like Word? They reopen Paratext and a dialogue comes up, asking if they want to restore what they were working on? Or do they have to drive deep into program folders, find the .BAK file, and do something with it?

Assuming a “crash save” worked (I’ve never heard of it not working before this report), when Paratext is restarted, the user should see a dialog that says “Recovered unsaved text for {ProjectName}. Please review this window and save or discard text.”. The text can then be undone (using Undo) if the user does not want to keep it.

anon094061:

What could be reasons for this not happening?

No ideas come to mind. This is the first and only time I’ve heard of it failing. If someone can reproduce the failure, maybe we can figure out why it didn’t work.