The logic here doesn’t quite hold: “It shouldn’t be too easy to accidentally overwrite user data, so the solution is to automatically overwrite user data all the time.”
Color me skeptical.
That’s why I said ‘combined with powerful versioning and persistent undo’ - also non-destructive workflows have a part to play.
These kinds of things is where things are headed over time.
In fact, some pro apps already work this way (see Final Cut Pro)
For what it’s worth, I didn’t say it couldn’t work, just that I’m skeptical. There are a number of applications on phones that I simply won’t use (or only use begrudgingly when required by others) because they autosave without a clear path to previous revision milestones.
Automation like this can be good for many general use cases, but it’s not particularly good at catching corner cases and requires another layer of management for handling/navigating revisions. Like you said, user data is sacred. There were need to be a lot of design and testing before I would personally be comfortable ceding control over when my data gets overwritten.
1 Like
I find the current “red input” behavior to be both unclear and broken. Select an existing file and it will show red, as designed. Click the “+” and it will increment the file name and then will not show red. But do this manually, as in add characters that make the filename unique, and it continues to show red even though there is no duplication.
For me the biggest problem with it is that it seems to be indicating that the filename itself is in error, which is never the case. We should be warning about a possible future action, not indicating a current state of error.
It might be worth considering changing it to make it work as it seems. For example, if the user enters a “>” or “%” or “:” in a filename (depending on platform) then that input should turn red, indicating that the name is in error. And leave the “Save” button disabled
And then for warning of the possibility of overwriting an existing file, move that to the action button:
7 Likes
Why not just use an “overrite file dialog” popup, the same way the operating system does? Would it be too hard to implement something like that? 
2 Likes
No, it would be dead-easy to add an “are you sure?” popup there. I am mostly trying to stick within our paradigm of limited popups.
I am personally annoyed by confirmation dialogs most of the time, except for the few times they matter. LOL.
What I mean is that fundamentally it comes down to asking the user if they want to continue with an action that they have already explicitly indicated. And most of the time the answer is “well, yes stupid, that is why I selected that, stop bothering me”
To further explore this, consider a time when we would NOT consider such a dialog. You work on a new scene, then save it. Do some more work, then click File / Save. It does so immediately, as expected. But there is the exact same danger here as elsewhere that is equally in need of confirmation. My intention could just as well had been to save with a new filename and clicking “save” was not what I wanted to do. So the system could have asked me to confirm overwriting an existing file, but did not. We don’t want it to.
“Save As” isn’t that different from “Save”, yet we are asking for a confirmation of action. So when I select “Save as”, then explicitly click on an existing filename, I would be irritated to be asked “are you sure?” since I just clicked on the damn name. I would only not be irritated if I got the confirmation when typing the name, versus selecting it. And that is inconsistent, I know. But sometimes I want a warning and other times I want the computer to just bloody do what I tell it to.
So the above was an attempt to give a warning that does not require added action and therefore does not slow you down. The changing of the button color would be hard to miss. But repeated “boy who cried wolf” confirmations are easy to ignore until too late.
4 Likes
Then why not have it as an option that can be enabled in the preferences? 
And yeah, that yellow button is better than the red input field, but it’s still more dangerous than the regular dialog popup…
2 Likes
In the end, any option is equally dangerous, if you’re considering windows. just click the popup and/or press space and your work is overwritten. Muscle memory is equally dangerous since is the same effect popup or not. Ask any office/cad/cam operator.
For robust automatic save, there was a time certain software known as microstation has that feature. You didn’t need to save manually to the file. Every operation has solid undo/redo and once you close the application, files were autosaved. Nice isn’t??. NO. One of the most requested features that paying clients ask to Bentley is to remove “that feature from hell”. Bentley had to capitulate as of Microstation XM. (uses a strategy similar to what blender does now, autosaves every x minutes). Unfortunately access to the forum is behind paywall/licensing and that’s big bucks.
The optimal solution IMHO for file deletion and overwriting is to forcefully delay the decision. Make the user press the OK or ACEPT button for at least 1 or 2 seconds full. (some games already does that, for savegame deletion). Harley’s solution can be usefull if the user keep pressing the button and the button fill with a red color from 0 to 100, and when reach 100, the operation is done.
Seems like a reasonable solution.
Although do note that not all platforms are stuck in the early 1980s in terms of file name conventions and limitations.
A versioning system (with .diff files) might seem like an interesting and cutting-edge way to balance the need to save with the desire for the option to start over from a certain point. However…
- It should be an optional feature and turned off by default.
- It should be as automatic and as easy to use as possible, no need to download additional software or make online accounts.
- It should allow people to write definitions for the ‘commits’ they do.
- It should allow the user to define a maximum amount of disk-space the project is allowed to fill up, deleting the oldest revisions when the space is full.
- Rolling back should be as easy as opening the folder with the commit log and double-clicking on an entry (ie. like opening a file), then one can invoke an operator to remove newer revisions.
I could see this working well with game engines too, where making a commit is literally as easy as pressing the ‘save’ button and writing a note.
Computing and modern document models are moving in this direction in general. The way we manage files and versions is stuck in the early 80’s. However, some OS’s and cloud storage providers already enable most of this, and over time, this is a change that will occur.
While I can imagine that doing it automatically might appeal to people, I can’t see that for me. I always want to have full control over when to save a file I’m working on, where to save it, what filename it gets, how many backup versions I want etc. I wouldn’t be comfortable with an application that takes that kind of control from me.
1 Like
What I am referring to cannot accurately be described simply as ‘automatic saving’. It’s a different paradigm, which would need many changes. You could call it ‘persistent, reliable computing’: persistent undo stack which is kept when you re-open, a versioning system, a clearer way to browse backups. It’s these kinds of things that, in aggregate makes it less likely that users will lose work, and act more like real-world items which don’t require the famous ‘save twitch’ to stay permanent.
This is a direction we are headed in general - it’s not specific to Blender. Many consumer apps work something like this, and some pro apps too now.
As an aside, computing in general requires less manual labor. You no longer manage which app gets what amount of memory, you don’t manually define which sectors on your hard drive to populate, you don’t manually manage threads. These kinds of things get in the way of focusing on the primary end-user task.
1 Like
Thanks for details, sounds interesting for those who would like it. I still don’t. I like to have full control over my own data files and file/directory organisation.
As for the thread topic, I very much like Harley’s proposal. I doesn’t get in the way like a popup, but still makes it very clear what is about to happen. Or maybe even have both, red filename background and overwrite button.
To be honest, making Blender rock stable and more intelligent (as to which operation could accidentally cause a long or infinite freeze) is just as important. Oftentimes, the famous ‘save twitch’ is a response that develops when a program’s quality declines and becomes unstable under the weight of bloat and feature creep.
A UI-based versioning system would still be useful though, in the case where you try a destructive idea for your scene and you hit a dead-end a few days later.
1 Like
I find the idea an interesting thing to think about but I really wouldn’t rush into it.
At the very least it would need to be thought through. With it we are saying that some actions are more important and therefore a button performing such action needs a “warning” state. That fits nicely in this particular case. The button text changes to “overwrite” and you can’t miss that change because it is accompanied with the change to yellow warning color.
But find me other areas where we would use such a thing. And why. And why would we not use it in other situations?
In this case we are saying that it is really important that we warn about copying over an existing file. But if I simply select “File / Save” from the menu I am also overwriting an existing file with new changes and we wouldn’t expect that menu item to be yellow.
Similarly, make changes and then try to close Blender. You are then asked if you want to save before closing. The “Don’t Save” option seems similarly worthy of warning yet I wouldn’t add a yellow highlight there.
So I am just saying that the idea is interesting but would need to be fleshed out with rules on how and when it would be used. If only used in this one place then that is an inconsistency that I don’t like.
Yeah, I understand and agree. There should be a reason to have a warning in one case and not in another where the same thing happens.
Let’s see. One could say that in the case of “File / Save” it is expected that the current file gets overwritten, so no warning is necessary. Same with save prompt on close.
“File /Save As” is often used (in my workflow at least) when the user wants to save under a different name. If I accidentally mistype, using a filename already present, the warning would then be beneficial and useful, I think. If I do want to use a filename already present, the warning would be informative at best and only mildly annoying at worst, contrary to a popup.
I may be wrong about expectations of people when using one or the other save action, but that would be my take on it.
Yes, that all makes sense. I guess in the end the need and appeal of that yellow caution state isn’t really about how important the operation is.
I think the central issue is that the importance of that “save” process changes dynamically and quickly. It is perfectly safe and benign one moment and then you select an existing filename and suddenly it is important. So changing the text and color would signal that change.
But I still don’t like the thought of making some special thing that is only used in one place. But still worth considering. We currently have a “redalert” state we can put on forms and buttons (hardly used), so adding a similar “caution” one isn’t too much of a stretch.
We can simply use ‘redalart’ here too. No need to add another state.
I can relate to that, I don’t like that part of it either. For me personally, the red background is enough and gets my attention fine. But if people are actually losing work, it might be an acceptable compromise.