When autosaving my work, don't beachball Fusion 360

[michaelbuffington]

I'm on an early 2013 Macbook Pro - it's not a slow machine.

Yet whenever an autosave occurs Fusion 360 beachballs. The app becomes completely unresponsive until the autosave is complete. It doesn't care if you're right in the middle of working out a difficult sketch, or dragging an extrusion, if you're idle, or if you manually saved 2 seconds ago. You're stuck for at least 5 seconds.

Blocking all human interaction while an automatic process happens at regular intervals breaks just about every common-sense rule of human interface guidelines ever published.

The only time a user should ever know an autosave occurred is when the app crashes and they see the impact of the crash was negligible because autosave did its job. If autosave gets in the way of a user's design flow it encourage the user to turn it off.

In the case of Fusion 360, I see that beachball a lot. Because the app is prone to crashing (still), I have autosave set to save as frequently as possible. And because crashes are often preceded by beachballing, I never know what to expect. Is it autosaving, or am I crashing? Looks like it was an autosave. Now what was I just doing?

[roambotics_scott]

If the saves were deltas and atomically synced to disk continuously, autosave could be eliminated while maintaining a current and consistent design with minimal loss and complete undo history.

Also I hate to keep nagging about the stability thing*, but it's ridiculous.

I've said this before but if Word was guaranteed to crash with data loss every time you wrote something more substantial than a one page memo, nobody would use it. I still contend that you shouldn't be selling the product and should label it «beta» until it's rock solid - by which I don't mean «crashes 80% less» but «bulletproof and we've not seen any crash reports** for at least 1-2 months»

Even if stability is hard to achieve*** replacing the file format with something that supports continuous delta saves with atomicity to guarantee consistency even if a crash interrupts a write will ensure that users don't lose data and will be able to go back through their undo history after reopening. That's not nearly as good as not crashing, but with something like this you need a policy that users experience as close to zero data loss as possible and dumping even 5 minutes worth of work (let alone 15 or more) can be considerable, can break flow, and be enormously frustrating.

* it's not bothering me at the moment because I have someone else working on our designs in SolidWorks - which annoys me to no end because I had such high hopes for F360 but found that it's unusable for production.

*** I don't think it should be and remain convinced that you're doing something fundamentally wrong and focusing too much on symptoms and not underlying causes or general strategies - but still..

Also this forum software kinda sucks and should be replaced.

[promm]

Thank you for idea - this is getting archived due to lack of votes.  Blocking behavior is a trade off against losing user data.  We are working on improvements to the amount of time this takes for save.

Mike Prom