Feature request (sorry): autosave

I never thought it would be me writing one of these… I’ve participated in these discussions before and told impatient people that everything they need will be released in due course. But I feel (perhaps erroneously) that this request is a bit different?

I can understand and excuse features which aren’t done yet, and (as is related to this post), I can certainly excuse bugs. Not only is it still new software, but for me at least it’s already more stable than Finale which is great.

The problem is though… Dorico DOES crash sometimes. It crashed on me today and I lost a good hour of work. Of course, I could be saving as I go but honestly, I shouldn’t HAVE to do that. I’m not angry about bugs and instability, but it seems like an autosave feature should be VERY high priority, as it mitigates the damage caused by all current and future bugs.

Anyway… I’m kicking myself for even writing this because I don’t want to be that guy, but I strongly feel that this should be included in the next update even though it’s just a general performance and stability update.

Hi WT Fruit. For what it’s worth I use ForeverSave 2 (mac) and have set backups to run every 10 minutes. It runs quietly in the background and I’ve never had a problem with it. I got it some time ago because the Sibelius backups weren’t working properly and it saved me a ton of time then. I’ve used it three, maybe four times with Dorico - in every case it’s restored what I lost. If I recall correctly it was about £20 or so.

That said, I think your point is spot on, and not just for the issue of bugs. Autosave functionality should be a given for any program where a lot of detailed work is involved.

I’m very sorry to hear that Dorico crashed and that you lost work. I agree that auto-save is a very high priority for us to add, and I do expect that we will add it soon, but I’m afraid it’s not expected to be in the forthcoming 1.0.30 update. The next update should contain an auto-backup feature (provided it passes internal testing soon), whereby Dorico will keep a (user-definable) number of copies of each project in a backup location, rotating them each time you save; this will guard against some kinds of problems (e.g. we have seen very rare instances of projects become corrupted) but obviously not losing data in an unsaved project due to a crash.

We will add auto-save as soon as we can; I would expect it to be part of the next update following 1.0.30.

David, thank you for that suggestion, I’ll look into it!

Daniel, thanks for the response! The funny thing is, with Finale I built the habit of saving after every adjustment I made - literally just subconsciously hitting the shortcut constantly (I know Finale has autosave but I wanted it saved in two files). This was easier in Finale though because there’s always annoying pauses slowing down your workflow anyway.

With Dorico… not only are the crashes more rare but also everything just moves so quickly that I get into a flow and I quickly lost that habit! Anyway, I look forward to this and all future updates! Thank you for all of the work you and the team have been doing!

I’m glad to hear a plan is in place, but I’m not sure what’s meant by storing copies in a backup location. Possibly the best solution would be for Dorico to hold a copy of current projects as separate database files internally (not formatted as project files), so that it can save changes with every action incrementally without saving an entire file (probably, hopefully it works this way internally anyway). This way when the program crashes, upon restart the database is simply queried and the unsaved work is found and presented to the user, which the user can then save in the form of a file if they want to. In any case I hope the worst case example of auto-save would be something like Word bringing up a progress bar which interrupts workflow will not be part of the future of Dorico. If it is, perhaps WIndows users won’t mind, but it would be a feature immediately turned off by virtually all Mac users, as interrupting the workflow is very annoying to us, a big no-no.

Aaron, you’re making pronouncements on behalf of a large group of people again. I too am a Mac user of long-standing, like you, and if I’m given a choice between having an auto-save feature that might occasionally interrupt my work versus having no auto-save feature and losing my work, I’m going to choose the pragmatic option every single time. I think it’s also unhelpful to distinguish Windows users as somehow having less discernment than Mac users. Please try and steer clear of this kind of thing!

As for the coming auto-backup feature, when you save, it simply copies the saved file to a known location, with a timestamp added to its name, and those timestamped copies are rotated each time you save: it keeps (say) five backups, and once there are five in place, the sixth time you save, the oldest backup is deleted, to avoid the disk usage growing unbounded. This doesn’t interrupt the flow of using the software, as making a copy of the saved project on disk after the save operation completes is very fast.

I’m sure that when we implement auto-save, it will work in a similar fashion: it will perform a save operation on a timer, and put a complete, valid copy of the project in a known location. When the project is closed cleanly, the auto-save files for that project will be deleted. If when the application runs it finds files in the auto-save location, it can then prompt you to recover them.

Thanks for trying to help me avoid conflict, but you’ve read me wrong here. What I’ve noticed over decades is that Windows users are not bothered by lots of dialogs popping up, waiting for progress bars to complete, having to close windows and tabs, etc. while Mac users are annoyed by all those things because they have been long officially discouraged by the Apple HIG. That’s not insulting anyone; it’s a valid and important observation. When designing an x-plat UI, the competing habits of users must be carefully considered, and in this case what I’m saying is that if the auto-save feature works like Microsoft Windows, where a popup window shows a progress bar every few minutes in the middle of your work, virtually all (long-time) Mac users will be annoyed by it and will turn the feature off. Users already have built-in backup habits and on Mac there is also Time Machine built into the OS for that purpose. That’s not an overstatement, or an indictment of Windows users; it’s a fact worthy of consideration.

I’ve never seen a popup window when using autosave in Windows. Nor has it interrupted my work. And you did sound dismissive I’m afraid. We don’t like things that slow work down anymore than anyone else. Why in the world would we?

Good. I’ve seen popup windows when using autosave on Windows, and it has interrupted my work.

Sorry.

I don’t think that you or any Windows user would like to have the workflow interrupted (I changed “would like it” to “won’t mind” to be clear - by “it” I meant the feature, not the interruption). I’m saying that, over many years, I have observed that Windows users have a lot more tolerance for popup windows etc., because they are used to them, as they have been a standard part of the Windows user experience for decades. The Windows mentality is indeed different from Mac in this regard. It’s more tolerant. If anything, that’s a compliment, not a criticism. I’m less tolerant of such things because I’ve used Mac since the 90’s and popup windows have been officially discouraged by Apple since the codification of their Human Interface Guidelines. That’s just factual history.

Autosave has also become an important issue on Mac as opposed to Windows because Apple has made a move towards implementing autosave into its in-house apps (e.g. Pages), in a way that fundamentally alters users’ expectations. Specifically, the files themselves are saved directly, automatically without the user’s knowledge or consent. This was disastrous when it was introduced. Before Apple made this move, one could open a document, make changes without saving, decide the work was worthless, quit the app, and reopen the document later in its original state as it existed before the last discarded session. After Apple’s change, once the file was opened and changes were made, those changes were saved automatically to the file. Quitting without saving made no difference. Their reasoning was “just use Time Machine” since you can always go back and get the old version there. The only way to get the old behaviour back is to make a copy of the document before you start working on it. So, even though it doesn’t sound ideal from a speed standpoint, I was glad to read Daniel’s explanation of how auto-save is expected to work in Dorico. It won’t be either like historical Microsoft or like the recent Apple nonsense, and that’s good news.

[Disclaimer: as a developer I’m definitely Mac-centric. I work on a Mac, and I design for the work habits of that platform. I use Windows only because I have to in order to deploy on that platform, and I don’t like Windows conventions or employ them in the software I write. Other developers favour Windows, or consider both platforms equally and either write a lot of branching code to cater to the habits of both user groups, or strive to find a middle ground which can be extremely difficult.]

I’ve been using Windows for decades, and I have never seen any pop up auto saving progress bar in the middle of the screen- and I use auto save on all the applications I use. (well, except Dorico that is…)

For apps that don’t auto save, it’s only a simple ctrl-S needed each time a significant amount of work has been done, and with Dorico you can do this whilst Dorico is playing back - it’s just an invisible background task.