I recently wanted to delete the latest backup version of a job, and decided to d oit via web UI. This was the first time I was doing it, so it took a little adjusting to the logic of the web page where I select the different sections of the command line. At end, I decided to add --dry-run, but it had no effect, which was baffling. After some snooping around, I learned that it takes a value and that the default value is false. At the time when I was picking up the option, i was already ready to run the command, so I didn’t even realize that the selected option had not appeared anywhere on the page. If I had scrolled back up and selected to see the textual version, I would have noticed the wrong value, but my decision to use dry-run was a last-second thing.
In the end, nothing bad happened. I did want to remove that version, and it worked fine. But the experience with --dry-run was scary, to put it mildly.
This isn’t really unique to --dry-run. Whenever you select a new option from the dropdown list, it adds it to the list of defined parameters but the value is at the default. You always need to check the option and set it appropriately after picking it from the list.
I get it though…it can be a bit confusing the first time you do it. Glad it didn’t cause you any major trouble in the end.
What arrogance. If you expect the user to learn to avoid the traps of the UI, you clearly have been involved with Duplicati for so long that you have become blind to the user’s point of view.
This is a combination of the both UI’s failing the user.
On command line, the dominant convention is that Boolean options do not take value, so if I include an option on command line, its effect conforms with the name of that option. Against this convention, Duplicati accepts Boolean option without value, but sets its default value to false, which means that the effect of adding the option to command line without value is the exact opposite to the meaning indicated by the option name, violating user’s well established expectation.
When it comes to graphical or web UI’s then, any user’s expectation is that the UI is there to help the user and even let the user avoid pitfalls of the command line. If the web UI would require that a value is given to any option I choose to use – if I’d had to type in the value – the effect would have been what I expected.
The end result, as it seems, is that the both UI’s are determined to trick the user.
The Web UI advanced options do not exactly correlate to command line options. Maybe that’s what is leading to your confusion.
With the command line, there is only one “layer” of options being applied, so it is pretty straight forward.
The Web UI has two layers of options (global options and backup set options), and therefore must support that added complexity. By leaving an option “undefined” at a certain level (such as backup set level), it will inherit the setting in one of the underlying layers (global option level, or if undefined there, then ultimately the software-defined default value).
By selecting an option in the “Add advanced option” dropdown, that option becomes “defined” and will now appear in the area above the “Add advanced option” dropdown. Once defined this option now overrides what is defined in lower layers.
In the case of boolean options like --dry-run, it needs to be set either true or false at that moment. An argument can be made either way as to what the default should be - the software defined default, or the opposite - but I doubt one is objectively correct.
Circumstances are a bit different for string options. Merely defining the option doesn’t actually put it into effect until you provide a string value. It is considered undefined if left blank. For boolean we don’t have that ability - it’s either true or false.
Web UI options can be set back to “undefined” by clicking the blue X on the right side:
To me the way it is set up is very logical and reasonable, but I admit I’m a highly technical user. A more casual user may have trouble understanding it. This forum is a great way to explain how Duplicati works and to answer questions.
By this long writeup you just confirm what I already said. What you are proposing here is that the problem lies with the user not understanding the internals of this magnificent software. That has been the attitude of many generations of sw developers, and it seems there is no end in sight to this attitude.
It is okay if the command line exposes the user to some of the most relevant component’s interfaces, but it is not okay for the GUI or web UI to demand the user to have such knowledge. Period.
In order to propose something, I would need to dig deep into the architecture. In my past, whenever I have found myself typing user instructions for an idiotic user interface I designed, I always chose to fix the sw rather than explain how to user should bend backwards and forwards and kneel to kiss the earth under my feet to get their job done.
I don’t think that’s necessary. The message I posted above explains how there are multiple layers of options. How should it be presented in the UI?
Me? I’m just a user and a avid fan of Duplicati, hardly a core developer. I enjoy making minor contributions to the open source project when I can.
If the UI can be made simpler without sacrificing core functionality then we should do it. It will help more casual users without hindering power users.
Thank you for the clarification. Your relationship to the team has always been unclear to me. You seem to take a lot of the support pressure off the team, and sometimes it is good and sometimes bad. Sometimes it is not you I want to address my messages to.
Anyway, let me rephrase what I meant by my latest message. It is typical for sw developers / designers to think of the UI backwards. I know I have. But when tasked to write up user instructions, I am forced to look at it from a different angle and re-think a lot of what I do. For this reason, I often want to advice other developers to spend time writing instructions. Answering to support requests is not as effective, almost the contrary. Writing test cases is also an effective way to force oneself to see the design from a different angle, and that works on both internal and outer levels of sw. Dividing the work time between development and writing instructions or test cases should not be viewed as some superficial process policing thing forced upon you, although it sometimes is. Especially in open source projects, it really is an enabler, it is about the productivity of your own work, and it is all in your own power to help yourself.
But then, the “you” I am telling this is nobody, I suppose.
