Use standard UI controls whenever possible

UX
,
#1

Continuing the discussion from Restore UI Options - perhaps explicit selectors instead of an unforgiving edit field?:

Example - Browse for a local destination dialog in the Restore workflow. The custom UI control looks cool for a first few seconds and then it becomes a source of constant frustration:

  1. All familiar gestures and shortcuts don’t work or work slightly differently. Moreover, those are different between OSes. (like dragging folder into open dialog on Windows copies contents there, and on macOS it just changes to that folder). It’s guaranteed to infuriate either one or the other set of users. Or force the developer to support different paradigms for different OSes, but why bother in the first place?
  2. It takes time to get used to it - do I click on an icon? on a title? Doublecklick? how do I enter directory? How do I paste path? Can I drag? I like dragging stuff around (especially in macOS you’d be surprised how much stuff is draggable onto how much other stuff).
  3. Developer will have to constantly maintain it in each OS separately to keep up with features and UI idioms. Support mounted drives? Support some interesting other feature that is in the new OS and that would have been free had the software just took advantage of the existing free file picker included in the OS? New OS update broke browsing in some cases? No, lets developers focus on duplicacy core functionality, not re-implementing file picker.

Now, one might argue that this was done for consistency across UI - after all, browse to a file in the revision history virtual file system looks exactly the same and perhaps it was not feasible to bolt custom virtual filesystem into standard file dialog.

There is an elegant solution to this. Which brings me to another linked topic below.

3 Likes
Mount duplicacy snapshot as a virtual filesystem
#2

I might have misunderstood your full point but I wonder if the real reason for the web-based file selector is the fact that, well, it’s web-based…

Most of my systems are Windows, I don’t use Mac, but I run Duplicacy on a couple of Linux Debian GUI-less systems. I haven’t tried running the Web Edition on Linux and have only just started playing around with it on Windows.

So I can imagine the scenario that you might want to manage a remote instance (bind to 0.0.0.0, password protect etc.), and that remote OS is a different platform. Indeed, even if it’s the same OS, the local file selector wouldn’t be able to show the remote file system without some severe hackery. I’m unsure if it’s possible to accomplish unless you put in an exception for local systems only?

Personally, I quite like the GUI file selector, although as I mentioned before, there needs to be some improvements. Line height is way too high imo. On the filters pane, the viewport size (width and height) needs to be much larger. Perhaps move the buttons and the selected filters from the side and put them underneath.

Also, I get no proper mouse cursor feedback in Firefox (dunno about other browsers). There needs to be. And double-clicking a folder should have the expected effect (same as single-click the icon).

2 Likes
#3

That’s a good point.

#4

Yes, you are right, the headless/remote use case completely slipped my mind.

I’m unsure if it’s possible to accomplish unless you put in an exception for local systems only?

That could be a reasonable compromise in fact.

#5

You can’t invoke standard OS dialogs from a browser. Most browsers would only allow a very limited file selection dialog. For example, you may be able to select a few files, but you can’t select a directory.

#6

You can’t invoke standard OS dialogs from a browser. Most browsers would only allow a very limited file selection dialog

I don’t think this is accurate. For example, One Drive’s Upload a Folder workflow:

49%20PM

Safari:

image
image.jpg2146×958 197 KB

Firefox:

image
image.jpg1972×814 213 KB

Chrome:

image
image.jpg2042×1060 226 KB

Aren’t these three the most used ones?

#7

With those dialogs, you can choose a directory and then all files under that directory will be returned. However, the browser won’t get the path of the directory, only the files that it contains.

3 Likes
#8

Maybe I’m missing something, but for headless installs of the web UI I’m not sure how a local native file browser could be used to navigate a remote host’s filesystem through a web application.

All of these examples are websites navigating the local filesystem rather than a remote one.

#9

Yes, this will only work for local server, see this comment Use standard UI controls whenever possible

1 Like
#10

Wow. This is absolutely unobvious! Thank you for clarifying.

#11

Basically you’re saying that the OS returns a list of files: {a,jpg, b.jpg, c.jpg} even though they are located in different folders ~/pics/a.jpg; ~/homework/copy-3/b.jpg; ~/catzpics/ilovethatcat/c.jpg?

Didn’t know that was the case

#12

…with paths

It will return what is equivalent of find . in the selected folder, as far as I understand.

#13

My reading was that it just returns the actual files.

#14

So 3 different people each with a different understanding :))