Hi there, forgive my ignorance and this might seem like a stupid question but I cannot seem to add a backup entry… the save option is greyed out any idea what this might be? I am using unraid.
You need to type in a name for the Backup ID.
Another UX issue. Why is this field not pre-filled?
Thanks buddy that solved an issue, my fault for not filling it out feel like a right donut, was just watching a tutorial and they managed to save without filling anything out, I guess it is now a required field. 
Nope. Not your fault. It is never user’s fault. Please stop blaming yourself and making excuses for poor human interface design. Be that a toaster or a Boeing cockpit controls — if user makes a mistake let alone can’t figure out what’s going on — it’s always a deficiency in the interface design.
In this particular case there should have been interactive prompts that should have unambiguously guided you thought the configuration, such as highlighting missing field when you attempted to proceed. There are a millions of things that could have been done (it’s a web ui after all!) to absolve you from needing to watch videos and post on forums just to perform a basic configuration for a one job this software exists for in the first place.
Sorry, but this my pet peeve, when software makes people feel inadequate and apologize for not being able to interface with it it’s wrong on multiple levels. There is a separate discussion in parallel threads on merits of good UI. Tagging @sevimo for visibility. This thread exemplifies the problems I’m trying to surface.
2 Likes
It shouldn’t be pre-filled IMO. I agree it should have a simple hint there and feedback for why the Save button is greyed out.
The app already knows the the source, and the target. Making a default name for the job based on the source and target is reasonable. Or just “backup 01”. If user wants to change it - they can. Most will just click a button and accept the default.
Why force the user to do work (come up with a name) when it is absolutely unnecessary? Little things like that is what contribute to positive user experience.
No, it’s not. Not when the source pathnames are near identical or non-descriptive, making these ‘generated’ IDs next to useless in many cases. Deriving from the target is pretty pointless too, when the backups go to multiple destinations.
It can provide hints, good examples, but until such time IDs can be renamed - ultimately, it requires the user to put a bit of thought into (because they WILL want to think about it, and not be treated like an Apple user).
Lol. of course it should be possible to rename the id! Oh wait, it isn’t. Another design bug. Who knew. ¯\_(ツ)_/¯
My point is that users brainpower can be better spent elsewhere, than wasted on coming up with a name that only needs to exist because of lazy design. Forcing user to do things that are not necessary and avoidable is disrespectful to their time.
Deriving from the target is pretty pointless too, when the backups go to multiple destinations.
On this specific web the name of the backup is supposed to describe or refer to a combination of directory and storage name. So just concatenate them and call it a day. It does not need a separate name. Just refer to both everywhere throughout the ui.
You mean, not treat user’s time with respect, not pay attention to usability, accessibility, discoverability, and generally disregard all principles of human interface design? Let user work and figure out things, read manuals, forums, and IEEE papers, understnad the design and thought process of the developer to be worthy of using this little backup utility. Really?
You know IDs are embedded in the snapshot files, which act as its database; there’d be a good deal of risk modifying those files directly.
It could be done safely (writing a new set of files to a new snapshot directory, leaving the original intact and fossilised out of the way), but that’s still a significant amount of work you’re brushing off as easy.
If you thought it was that important, the source is there, make a PR.
Oh no we can’t have people engaging their brain when protecting their own data, can we.
Only someone who doesn’t practice 3-2-1 would suggest that. 
1 Like
User-facing string is baked in into every file is also a design bug. There could be another file mapping snapshot ID to user facing strings. Either way, it’s an excuse, and not a customer’s problem.
I don’t want to, I cannot, I want to pay money and gave a working solution; I am a customer, my volunteering interests are elsewhere. I already have a job in software engineering already, I don’t want another one. And that assuming web gui was opensource. And assuming duplicacy CLI was opensource. It isn’t. If I wanted to donate to a commercial company I would have donated money.
Is this enough to illustrate the ridiculousness of the “if you want it do it yourself” mantra?
I don’t think it’s related in any way to how ui manages user facing strings. But yes, I don’t practice 3-2-1. I’m just a customer who wants to protect family pictures. If I practice 1-1 it’s already an accomplishment. Don’t make this job harder than it needs to be.
two things have just occurred to me:
- I’m actually practicing 4-1-3, but definitely not in a single app, which essentially overlaps with “2” aka all eggs in one basket. Most of modern day users do: few computers with cloud sync easily gets you there, even with rudimentary versioning, and disaster recovery (including “halph I deleted all my files”). To compete with this (or to add value to that) the backup tool must be seamless and effortless. Ideally integratabtle to the OS and looking as native as possible, and with flat horizontal learning curve. That’s a whole separate discussion though
- “2” itself is very outdated. There is no reason to keep stuff on different media. It was applicable in the past maybe but today 1 is enough, if considering the original meaning of 2, if it referred to media types.
In which case, the ID need not be renamed at all, and the snapshot files can remain immutable. What you’re describing is a label, very similar to what Syncthing does. A relatively simple enhancement.
What do you mean by that?
Absolutely. Everything I’m suggesting is very simple to implement low hanging fruits. I’m concerned about the reasons why none of it is being done.
I’m not a lawyer, but per my understanding duplicacy license does not satisfy basic requirements of opensource: The Open Source Definition | Open Source Initiative
IIRC this is related to why gchen decided against making duplicacy available at various distributions (Linux, macOS, etc)
Now you’re splitting hairs. I don’t think Duplicacy ever claims to be open source by those definitions, but the CLI source code is available to modify and distribute, and free for personal use. You just can’t profit from the work, commercially, which is entirely fair enough.
How does that prevent you making a PR, or even forking it for your own purposes?
Yes, this is true, and is fair.
It does not, but it presents yet another, albeit minor, obstacle, provided I had time and skills to contribute in the first place: With open source there is well understood contribution model, drawbacks and benefits; with duplicacy’s different license it requires further analysis to decide where the limited amount of efforts will be best spent. Maybe it’s better to donate your time to some other project, with larger impact. I don’t know.
Again, this is minor point, it does not merit lengthy discussion, and either way – virtually all changes we talked about would be in web ui, so the point is moot. The CLI is mostly usable today as is (minus the interrupted prune bug. But I’m not interested in fixing that bug myself for various reasons, my contribution ends at pointing it out several times), and where it lacks – CLI users are capable or building around those limitations.