Yes indeed - I think there are enough other places in blender where one needs to come up with new stuff - why not adapt a solution like everyone else is using for this and then call it a day and focus energy on more imporant things…?
Yes, what’s even more confusing is that literally everyone else here uses also other software alongside Blender. At the very least some simple notepad style text editor, MS paint style image editor, Web browser, and so on… And in all those pieces of software, the file overwrite prompt is more or less same and no one does mind. So why would these people want Blender to be one special snowflake in this regard?
1 Like
I also agree with everything you said up there, a dialogue box popup is really important in every software that writes data, it shouldn’t even promt a discussion. Its one of those things that’s the norm that every user knows what it’s for even if it annoys you, its there to help you.
The simple fact that a debate is needed for this is what scares me… 
It’s more than obvious that a “file overwrite prompt” dialog is highly needed… but we had this conversation before, so it’s highly unlikely it will ever happen, unfortunately…
2 Likes
I don’t understand it. Why isn’t it done yet, and quickly. This is not just some feature request. This is about data loss. That should always have a priority.
And yes, I also struggle to understand how can anyone argue for alternative ways to implement something that’s so incredibly widely standardized.
3 Likes
Where did you come across the data that users have a habit of ignoring confirmation dialogs specifically in context of file I/O operations? Is there any reliable source you can link to, or is that your subjective opinion?
I don’t believe that if that was truly the case, the file overwrite dialogs would be so incredibly common it’s borderline impossible to find a software that doesn’t have them other than Blender.
Can you also address the other points I’ve made, such as:
Given that you seem to be currently in charge of Blender’s UI, your lack of response for something as serious as data loss prevention mechanism is quite concerning.
1 Like
I don’t think Julian is “in charge” of the UI module, he’s listed as coordinator, while all the other modules have owners. Maybe that’s one of the reasons for perceived lack of UI progress, in that there is no module owner to take the lead in a structured way. But that’s just me making assumptions based on what I read.
Edit: there’s actually quite a lot happening on the UI front, most of it larger features: https://wiki.blender.org/wiki/Modules/User_Interface
1 Like
That and also as Paul wrote earlier - the code might not permit to add popups and warnings as easily as one might think for architecture reasons. Sometimes things that seem super complicated can be done quick and relatively easy and sometimes things that should be simple require you to bend backwards while juggling flaming chainsaws.
Either way I still find this to be so super damn important that it is necessary to actually discuss how it could be implemented, what’s the best way and what actually might prevent it. Making excuses like annoyed users is counterproductive and will most likely only sidetrack any discussion about it until the thread dies down.
Story time.
Probably the most drastic example of such an error was the false 2018 ballistic missile alert in Hawaii. The people of Hawaii received a push notification on their mobiles asking them to seek shelter immediately (“THIS IS NOT A DRILL”). TV programs were automatically interrupted to warn the
population.
An human pressed a wrong button. And then confirmed the choice in a confirmation dialog box.
I should add however that there is conflicting information about this. Some sources I’ve checked (including Wikipedia) say the person pushing the wrong buttons claims to have done so because of a misunderstood phone call. We’ll probably never know for sure. Either way, the system still failed to consider and deal with that error. And after it was done, undoing it was very hard.
The problems of modal confirmation dialogs are generally well recognized in design circles (although often ignored). Some sources:
-
From the Wikipedia Dialog Box article:
Usability practitioners generally regard modal dialogs as bad design-solutions […] a modal alert dialog […] which is dismissed automatically (because the user has developed a habit) will not protect from the dangerous action.
-
From Apple’s Human Interface Guidelines:
Users sometimes press Return merely to dismiss a dialog, without reading its content, so it’s crucial that a default button initiate a harmless action.
- Jef Raskin’s The Humane Interface (which played quite a role in the history of Blender design) covers this well IIRC, Aza Raskin (his son) also writes about it here.
- Jakob Nielsen, Confirmation Dialogs Can Prevent User Errors — If Not Overused.
Summary: 8 UX guidelines to avoid many serious user errors reduce the risk that people automatically agree to a warning without realizing the consequences.
1 Like
Note that I’m not arguing against a confirmation dialog for this case. I think this is a good example of where there should be one. What I’m saying is that such a thing is not sufficient to prevent data-loss and with little work we can drastically reduce the chance of this happening (see my “move to trash” idea).
This is one of those cases where I will keep on pushing against what is written in guidelines. It may not prevent data loss from ever happening. In fact I am sure it won’t. No matter what you do - as long as there is a human in front of the computer something will go wrong some day one way or another. We tend to do that like … all the time. 
It will however do two things:
- If I disregard a warning dialog I feel that I specifically screwed up here after dismissing it. When Blender overwrote my file without asking and I didn’t realize I wasn’t in import but export mode … I blamed the Program. Programs are supposed to ask in that case.
- Even your links seem to point to the conclusion that sometimes it is necessary. This is one of these cases.
The other case, BTW, being: “You are about to close a Blender document with some unsaved Datablocks. Are you sure you want to discard them now or should I mark them all for fake user now? (Cancel / Mark Fake User / Go Ahead - discard them).”
Another comercial app I’m using, for example, overuses warning dialogues. Even if you are able to suppress them. The program doesn’t let you selectively reactivate them. All or nothing. This isbad design, IMO, as one missed klick will screw up settings the user tuned over time. Another one I’m frequently using goes the “don’t ask again until you close this program or it crashes” route. This is also kinda annoying as it has to be tuned all over again every time
.
If using popups very sparingly is the design philosohy for Blender (which is a good one I think) then I’d be all for having a selection in the Settings which ones keep on popping up. If there aren’t too many then it’s a list that remains manageable while still satisfying the “I don’t want to know about it” users.
Though if there is a much better way that doesn’t involve dragging the file to recycle bin or something similar obscure - then sure! It has to be something extremely obvious, though. Moving a file is not. in fact I’d even say it can be dangerous if the user is working with very large files. If the user doesn’t know about how Blender does this different from evey other program then they might pile up data in the bin unknowingly. It’s kind of a hidden folder and it’s yet another separate one from the autosave files.
It would be better to maybe have a [filename].[ext].[versioning] backup created automatically like the .blend1 files. At least that’s immediately visible.
Still - in this case I think the standard way of doing it is the best one and should not be postponed any longer, any more. There comes a point where reading and theorizing about the best way will give so many possible options that nothing is chosen in fear of making a bad decision. All the wile doing nothing is actually even more harmful than doing something that maybe isn’t ideal.
1 Like
One option for input-surety that doesn’t have the desensitization issues that come with confirmation dialogs is to use a release-confirmed long-press with visual cueing and ESC key fallback cancelling.
It’s the nuclear option for surety, since it’s an un-skippable three-step that doesn’t auto-confirm, but it’s also the sort of thing that will feel like overkill to most people. That said, a less extreme long-press option might be worth exploring; even if it isn’t used in this specific situation, it could be a useful thing to have in Blender’s toolbox.
I am sorry, but I am so confused. I am aware of this story, but the issue there was completely different. The source of that disaster was ambiguous naming of multiple, different options. What I am proposing here is implementation of a confirmation dialog which is literally used anywhere else, in any other software.
And the fact no one has taken up my challenge to show me another piece of software which uses a GUI (not a command line), allows overwriting files and does not contain any confirmation dialog just reinforces my point.
Furthermore, I have mentioned this:
In one of my posts above. I absolutely 100% agree that the default highlighted UI element of such confirmation dialog should be the harmless one. In this case “Cancel”, not “Overwrite”. So that quick, chaotic Enter key press results in no operation.
I saw your move to trash idea, and I reacted to it with an example of it being actually worse data loss prevention that the confirmation dialog:
And you still have not addressed it directly. The fact that Blender’s data loss prevention mechanism would be unique and not consistent with all the other software out there would actually make it way worse data loss prevention mechanism, because it’s uniqueness would require user to first be aware of it, and that would require reading of some sort of external documentation. And if they did not, chances of accidentally emptying the trash with the file that’s supposed to be preserved are very high.
Look, the bottom line is that in a typical Blender fashion, you have a solution and you are looking for a problem. You are putting up arguments against a mechanism that has been reliably tested over the past 30-35 years in probably hundreds of thousands of pieces of software.
And your arguments are in favor of an obscure solution that I have not yet seen used anywhere in my life, and does not have nearly as good of a track record as the simple confirmation pop up. Is user data loss prevention really an appropriate ground for experimentation?
I am sorry, but I would go as far as calling it delusional to compare this kind of user interface:
To this:
3 Likes
I am generally against “are you sure” confirmations, and usually work to make them not necessary. But in this case we should probably have one. But there are currently some weeds.
We’d have to build a new confirmation function for this type of thing. We do have a “confirm” function now, but it is kinda sucky for this. Well, sucky in a bunch of ways, but more so for this in particular.
Consider deleting an object by pressing “x”. You get that little window. It always says “Okay” at the top no matter what is going on. And the single button always just contains the operator name. And it cancels if you move your mouse a bit outside of its bounds. So there would be cases where a user thinks they saved when they instead canceled by moving their mouse too far. In the case of deleting something, cancelling just leaves it alone. But not saving when you intended to can be catastrophic.
It was always my hope that once we had the “Quit” dialog with the new large alert images we could then replace the existing confirm and alert function with new ones following a similar pattern. So we could pass title, text, button names, which is default, etc and so would be more what we are expecting of those.
Might make a nice target for 3.0
3 Likes
What does prevent Blender from using the “Quit” confirmation dialog in this case as well?
Having looked a bit into this code a few days ago (as an interested user and non-Blender developer) I suspect it’s not so much reusing the dialog code for the buttons and such that’s the challenge, but the more complex control flow for the file overwrite dialog that will bring additional work. Handling the current quit dialog is relatively simple: Save = save current scene then quit, Don’t save = quit immediately, Cancel = simply hide the dialog. So in two cases Blender ends up quitting from the dialog after the user has chosen, and in the third case nothing needs to be done. So nothing really needs to be handled afterwards and the quit dialog is always shown in the same situation.
In contrast, the file save dialog code is pretty generic (it’s even used for picking a file to open) and used in lots of different contexts as far as I can tell, e.g. saving the scene, saving an image, picking the filename for exporting to, picking the image/animation render filename, etc. So the result of an newly added overwrite confirmation dialog needs to be handled differently depending on the context, which is all done using callbacks. Blender’s operator system adds another layer of complexity, as the act of saving a file can be triggered by a Python call (e.g. menu option, or call in an addon) or call in C. In the Python case when calling the equivalent of “save as” the overwrite confirmation dialog might need to be shown and its response therefore handled, but only when Blender is not running in GUI-less background mode. Also, if the call is made from another operator then that probably involves additional handling. Another example, the quit dialog currently shows the scene filename and a list of images that have been altered but that aren’t saved yet (and probably other stuff I’m not aware of). Those file names are relatively easy to get as Blender keeps track of them centrally itself. But what if you have an export addon that asks for an output file name and then writes multiple files based on the user’s choice, e.g. Wavefront OBJ export to a mymodel.obj and mymodel.mat file. If there’s no existing mymodel.obj file, but there is an existing mymodel.mtl file should the addon be able to ask for overwrite confirmation from the user, and how does it tell that to Blender? Just lots of different situations to handle. The current quit dialog had its fair share of tweaks and fixes after it was first introduced, including edge cases like showing from a minimized window and platform-specific stuff like different button order that might interfere with muscle memory.
More generally, when making these kinds of changes to such a fundamental part of the application that is currently working correctly (i.e. saving/overwriting a file) you really need to make sure the changes don’t cause regressions in what was working correctly previously, nor should you introduce any bugs. Causing data loss in extremely frequent scenarios (i.e. saving a file) due to bugs which were introduced in order to fix a much-less-common data loss scenario (i.e. inadvertently overwriting files due to a missing confirmation dialog) is an interesting risk-reward tradeoff. Most likely nothing an experienced Blender developer well-versed in the UI code can’t handle, but I suspect it’s not a walk in the park either and it will needs lots of testing before being released publicly.
2 Likes
Oh, the QuitSave dialog is extremely complicated and specific. Instead I think we just need some improvements to the current WM_operator_confirm().
You can try the above here: https://developer.blender.org/D10955
2 Likes
Looks promising…
I hope this will put an end on those annoying “OK?” dialogs that popup on the position of the mouse cursor… 
Yep, exactly… the tiny, misclick-awaiting, right under the cursor confirmation dialogs are the great example and justification of why Blender community is generally against them. It’s a proof that anything, even something as simple as this:
…can be done the wrong way if someone tries to reinvent the wheel instead of following the established conventions.
1 Like
Bumping this thread because I’ve lost several files because of this.
I often miss the mark then I want to import an object into the scene and hit export submenu instead.
Since Blender export the whole scene by default even if nothing is selected, it won’t pop a prompt to say that there is nothing to export.
and since there is no prompt to overwrite, it’l just let me hit the blue button and overwrite the file I wanted to import with the default cube and camera or even worse, it will even overwrite the file with an empty scene !!!
this combination of
-not being able to import files by drag-drop
-export and import submenu being adjacent to each other
-export all scene being at default
-no prompt if exporting default scene or empty scene/selection
-no prompt if overwriting a file
I find it very dangerous.
I also don’t see why it would be bad to have a classic overwrite prompt defaulted on “cancel”. especially for exporting files.
2 Likes